上周刷到一条消息：Anthropic给Claude Managed Agents加了动态工作流，主Agent能自主调度最多1000个子Agent并行干活。数字很震撼。但我看到这条新闻的第一反应是------1000个Agent同时跑完之后，谁来保证这1000个交付物能要？
这个问题不是抬杠。因为就在两周前，我让两个Agent协作写一个数据管道脚本，一个负责写代码，一个负责做Code Review。跑完打开输出目录，写代码的Agent在commit message里写了句"Implemented full pipeline with error handling"，做review的Agent回了句"LGTM"。
我打开代码一看，错误处理就是把异常直接print出来了，数据库连接甚至没做超时。两个Agent互相点赞，活干得一塌糊涂。
我翻了一圈框架，发现大家都在解决"通信"问题
踩了这个坑之后，我花了一个周末翻市面上的多Agent框架。
- LangGraph 走的是graph-based控制流
- AutoGen 走的是对话式协调
- CrewAI 走的是角色委派
每个框架的文档都写得很好，示例跑起来也很丝滑------Planner拆任务，Coder写代码，Reviewer提意见，一气呵成，像一支微型研发团队。
但真把这些东西放到实际项目里跑，你会发现另一个问题。有开发者复盘过CrewAI的代码审查流水线：一个审代码质量、一个扫安全漏洞、一个写测试。理论上流水线协作，结果审代码的Agent改了一段逻辑，安全扫描的Agent根本不知道代码变了，拿着旧版本扫出一堆"不存在的漏洞"。
另一个更隐蔽的坑是状态覆写。Agent A和Agent B同时读了一份共享上下文，Agent A先写回新版本，Agent B基于旧版本写回，Agent A的工作被静默覆盖------不报错、不告警，最后交付的东西就是错的。
这些问题有个共性：单Agent架构反而不容易出。
单Agent是你跟一个"人"对话，所有状态在同一个上下文里，不用协调。多Agent引入的"协作税"，远比你想象得高。
我意识到缺的东西是什么
让Agent能对话，这层已经被解决了。AutoGen的GroupChat、CrewAI的Hierarchical模式，都能让Agent之间传递消息。
但消息传过去之后，"收到消息"和"基于消息做出正确的动作"之间隔着一整套工程机制。
我在翻Markus的文档时看到一段话，大意是它不是在解决"Agent怎么协作"，而是在解决"Agent团队怎么像真的团队一样运转"。我一开始觉得这有点营销话术。但用了两周之后，我大概理解它想表达什么了。
它做了一个很朴素的设计：Agent干完活不能直接交付，必须先submit ，由另一个Agent审查通过，才能merge。
听起来很简单对吧？但上面那个"两个Agent互相点赞"的事故，如果有这个门禁，根本不会发生。审代码的Agent改完逻辑之后，安全扫描的Agent必须基于最新版本重新扫描，否则merge不会通过。
记忆系统比通信协议更重要
在翻框架的过程中，我还发现了一个反直觉的事：Agent的持久记忆比通信协议重要得多。
原因很直接。假设你的团队里有个Developer Agent，第一次写接口时被Reviewer指出了缺少输入验证。如果Developer没有跨会话记忆，第二次写接口照样犯同样的错误。这个团队每次干活都像第一天入职。
学术界的共识也在往这个方向走：
- 有研究提出了双组件记忆架构，把事实性知识（语义记忆）和经验性信息（情景记忆）主动分离
- 另有研究提出了统一的记忆框架，同时维护语义向量记忆和关系图记忆
Markus的实现思路是三层持久记忆------程序性记忆、语义性记忆、情景性记忆，跨会话自动巩固。我配了Developer和Reviewer两个Agent之后，第一次Reviewer指出了三个问题，Developer改了。第二次写另一个接口的时候，Developer直接按上次Reviewer的要求来写，输入验证加上了。
这才是"团队"和"临时工"的区别。
一个临时工被纠正了，下次换个项目照样犯。一个团队成员被纠正了，这个纠正会沉淀进团队的肌肉记忆里。
关于1000个Agent的一些思考
回到Anthropic那条新闻。1000个Agent并行调度，在特定场景下确实有用------代码库扫描、文档批量审阅、多角度交叉验证。Claude的动态工作流文档里也提到，工作流脚本可以让独立代理在报告之前对彼此的发现进行对抗性审查，或从多个角度起草计划并相互权衡。
但有一个问题绕不开：Token消耗。
1000个Agent同时跑，API账单不会骗人。业内的建议是把这种能力优先用于天然可拆分的任务，比如文档审阅和代码扫描。
另一个问题是质量控制。1000个Agent产出的东西，如果没有一套交付审查机制，你面对的不是1000份成果，而是1000份需要你人工审核的素材。那还不如自己写。
Gartner在10月初的一份报告里有个判断：
到2027年底，40%的Agentic AI项目会被取消，原因不是Agent能力不够，而是成本失控、业务价值不清晰、风险控制不到位。
这个判断值得琢磨。Agent会不会干活，已经不是2026年开发者最关心的问题了。
关键是干完之后，你怎么知道活干好了。
我目前的工作流
说回我自己的实践。
我现在用Markus管日常的代码任务和文档工作。配置不算复杂：Developer负责写，Reviewer负责审，走 submit → review → merge 的流程。复杂架构设计还是自己来，Agent团队负责执行层面的并行推进。
用了两周的感受是------质量下限被拉高了。
以前代码里的低级错误全靠自己细心，现在有个"同事"在帮你把关。但它带来的Token开销也是真实的，心跳机制让Agent在你不盯的时候也在跑。我后来调了心跳间隔，把一些不紧急的任务改成了手动触发，账单才降下来。
最后
如果你也在折腾多Agent协作，我的建议是先想清楚一个问题：
你是缺一个能同时跑1000个Agent的调度器，还是缺一套能让Agent交付物合格的质量控制机制？
这两个问题的答案，决定了你该往哪个方向投入时间。