这是学习笔记的第 2525篇文章
最近把一些项目迭代之后，开始琢磨A2A的一些实现效果，说实话看起来挺美好，但是实际落地的过程中发现效果打折比较明显，我觉得应该还是在一些方式方法上有问题。
A2A的方式的出发点是希望项目A的agent和项目B的agent能够形成一种比较自然的交互和协同，比如项目A在代码同步中发现磁盘空间有风险，就可以直接和一个运维agent直接协同，让运维agent来自动进行分析诊断和自动化处理。整个的过程应该是不需要人工刻意介入的。
我参考了claude agent teams的实现方式，同时也学习了一些行业的开源方案。自己写了一套agent邮件系统，就开始对接了，初期的过程感觉还挺顺利，我让一个统筹的agent来去做整体的管理和分析，尤其是通过全局的问题视角，能够自动拉起cli进程，并且还能够实现任务的返工处理，我感觉loop engineering指日可待。好像达到了一种心流的状态。
所以如果是这样一种状态，那可能是过于乐观了，我想我们看到的绝大多数的案例都是从0到1的居多，而真正要把一些问题从1到10，从1到60的过程，其实得花不少功夫，而且很可能走不少的弯路。这些在现在AI如火如荼的发展中似乎有些格格不入。
首先发现的问题就是claude最近降智比较明显，尽管我设定了各种约束和限制，在处理一些问题的时候还是出现了故障，因为这是一个探索性的实验，所以这个故障对我没有直接影响。如果是更高要求和更大规模的业务迭代，那可真是灾难了。
然后我启用的统筹agent也发现了明显的质量下滑，我觉得和使用方式方法的关系更大一些，就比如统筹的agent通常会安排一些全局，整体的任务，这种角色可能目标感没有那么清晰，我就明显感觉到大模型在分析中出现了大量的幻觉，有些问题我一追问，就会发现反转，甚至数据是错误的。
我的直观感受就好比你让deepseek按照10个维度写5000字的文章，可能写出来的内容就偏简略，但是如果让它就某一个视角写2000字，应该效果要好很多。
所以我这几天的明显体感是，token消耗更快了，但是目标的执行效果反而有些打折。
甚至有些时候我感觉这个统筹agent不知道自己要干嘛，很多方案和建议有时候会带偏，如果你不断同意，可能带来的结果就是一个完全偏离的方向。
期望越高，带来的失望反而越大，急火攻心，欲速则不达，超越了基本的预期，通过极速追求快捷路径，目前来看可能是一种徒劳。
所以反复测试之后，我就先把这个统筹agent先停掉了。使用专有的agent处理，只要解决的问题足够具体和明确，效果立竿见影。
所以A2A的这条路上我觉得上来就从上向下解决，应该是不对的，至少在我现在实践的阶段来说。
下午我去首都图书馆去看书，一去吓了一跳，这么大的图书馆，整整九层楼，下午的时候竟然没有一个空位，坐的满满当当，看来大家的学习热情高涨。
我下午认真看了曹老师写的mcp的书，突然有点醍醐灌顶的感觉，我越发觉得没有完整知识体系，只靠自己琢磨解决问题，很大程度上会有局限性。
带给我的很大启示，其实回顾到基本，就是对于基础知识体系和原理的部分还是需要掌握扎实，如果很多基础的底子没有打好，后面的碎片化会越来越明显，而不断的返工，消耗更多的token，同时对于质量和细节的把控越来越模糊，可能会陷入一种漩涡。
所以我觉得今天基于mcp去夯实基础的方式还是挺有收获的，晚上在遛弯的时候边散步边琢磨，脉络突然清晰了起来。
各大平台都可以找到我
热文：
呼伦贝尔游记第二篇
呼伦贝尔游记第一篇
山西大同云冈石窟一日游
新数据库时代，DBA 发展之路该如何选择
我们为什么在MySQL中几乎不使用分区表
《大江大河2》最触动我的一段经典对话
如何优化MySQL千万级大表，我写了6000字的解读
一道经典的MySQL面试题，答案出现三次反转
换个角度看人生
个人视频号：
