日常-阅读 How we built our multi-agent research system

今天抽空阅读了 Anthropic 的 How we built our multi-agent research system，其中有不少过去就已经了解熟知的知识，也提到了不少能够激发我思考的点，来总结总结。
首先先说说之前就了解的：

1. 一个非常聪明的规划者。Anthropic 用的自然是 Opus，规划任务、决策都是 Opus 来做的，越聪明的 AI 做规划者越能提高执行者的效率和效果，目前第一梯队的规划者只有 3 个，Anthropic 4-Opus、OpenAI O3、Gemini-2.5-Pro，排名有先后。
2. 执行者的能力不能太低。Anthropic 的执行者使用的是 Sonnet，而不是 Haiku，执行者要能正确的使用工具，正确的遵循格式来输出，并且最重要的是能够理解任务的要点。
3. 使用记忆。PreAct 的要点就是提前计划并且生成 TODO，需要记住 TODO 完成的状态；在每轮迭代任务的过程中，都会产生新的结果，都需要进行记录；长时间执行的任务，会产生巨长无比的上下文，通常经过总结后也需要保存到记忆中。文章中配了两张图都提到了 Memory 可以看出它的重要。 之所以不把记忆归类到工具，是因为记忆可以算作一个基础设施，是必须要使用的，而工具是根据任务的不同可以选择用或者不用。
4. 使用工具。给予丰富的工具才能让 Agent 的智能发挥作用，最近看的最典型的例子就是，ChatGPT 网页上的 O3 在工具加持下能够通过非常普通的照片定位到照片拍摄位置。过去我倾向于看模型的 Aider 评分来看模型的能力，因为这个评测集通常反应了模型编写代码和指令遵循的能力，但发展到现在的阶段，Aider 的评分已经无法反应出模型真正解决问题的能力，现在我更喜欢看模型的 SWE-bench Verified 评分，这是一个经过筛选的现实问题集，考验模型使用各种工具来解决现实问题的能力，不过通常强的模型这两者的分数都不会低。

再来谈谈新的收获：

1. 巨量的 Token 消耗。Anthropic 提到 Multi Agent 是普通聊天的 15 倍 Token 消耗，所以应该让 Multi Agent 作用在能产生高价值的地方，而不是普通的任务。我之前有想过为什么 AI IDE 不搞一个这种 Multi Agent 模式，能够又聪明又快速的完成任务，从这篇文章中可以一窥原因，现在的 AI IDE 不约而同的让自己的工具在尽量少的 Token 消耗的情况下来解决问题，但基本都是事与愿违，有时候看着 AI 50 行 50 行代码的 read，真的哭笑不得。想必这就是 AI 提供商巨头的护城河，他们的 Token 基本上是 Free 的，通过烧 Token 来提高效果这是一般的应用公司没法做到的。
2. Agent 调试。之前从没有想过来做一个工具像断点代码一样调试 Agent，Anthropic 做了一个工具，能够逐步的观看 Agent 如何进行处理，这使得在 Agent 优化的过程中能够直观的、不停的 减少 不必要的工具调用、生成冗长的搜索词等。这也让我想到了可以把 传统编程中的很多调试方法都带到 AI 应用开发，除了断点，还有像日志（做个 MCP 来让 AI 自动输出日志到指定的地方）、Mock（假设模型的前置返回或者 MCP 的返回来进行测试调试）等等，对于 AI 这种黑盒开发有不小的帮助。
3. 智能体自我进化。像 Cursor 中的 Agent 自动调用测试获取报错信息或者是获取 Lint 报错一样，如果任务执行的不好，Anthropic 会让 Sonnet 自己来修改提示词再次进行尝试，直到获取到更好的结果。甚至当提供的 MCP 工具有问题时，Sonnet 会去修复这个工具然后继续。之前看信息流里有 OpenAI 的老哥说 O3 的降价也来自于 Codex 对系统的自我进化开发。这相当于强化学习训练出来的 AI 来用强化学习的方法来训练一个应用？
4. 并行处理。不光是把任务分解后多个 Agent 同时去完成所有的任务，还有 Agent 同时调用多个工具来解决一个任务。这个想法其实我之前也想到了，并且在一个 Side Project 中也实践过了，效果非常好，这个 Project 是一个小说编辑器，在对小说进行润色的过程中，会让规划者先标记出来哪些句子需要润色，再让多个执行者并行的对每个句子来进行润色。原来这个任务在润色一篇 3000 字的文章时，起码要等待 40 秒（使用的是 gemini 2.5 pro），使用了这种方式之后，大约 10 秒内就能看到结果了。
5. 提示词优化。Anthropic 提到一个微小的提示词修改，使得任务成功率从 30% 提高到 80%，这让我想到之前听的播客中的一个观念：如果我修改16 次提示词最终完成了比较难的问题，那么这个过程中，到底是我太菜了还是 AI 太菜了？Anthropic 很大方的开源了自己的提示词，可以去 Anthropic 的仓库里看看。
6. 工程化。Anthropic 提到了很多工程化的问题，包含了 恢复状态、容错、可调试可观测可测试、部署更新、执行与并发 等各种挑战，这也是每个做 AI 应用的开发者都可能会碰到的问题，所以 AI 应用并不是写个提示词那么简单，涉及到的编码和传统软件工程的知识都非常多。在目前，至少是 2025 年 6 月这个节点，根本不可能有真的0编程知识的人能够使用 AI 开发上线运营一个应用。

想法：
我曾经花了一个小时，和 AI 对谈让它来不停的问我问题了解我，最终总结出了一大篇关于模仿我的提示词，然后我就可以与“我”对话了。不过这个“我”的上下文还是太少，比如我正在写的项目和完成的进度，比如我的朋友同事们的性格和我们之间的经历，比如我还有一些并不符合 AI 政策的想法无法输入进去。同时“我”的能力还是太少了，抛开能影响现实中的能力不谈，在电脑中的能力也少的可怜，虽然我也配置了很多 MCP 但 AI 任然不能用我的电脑做任何事，比如聊微信、写 Word、刷信息流等等。但如果我提供了某个特殊领域的所有工具，比如程序员或者产品经理，它能够写代码、执行命令、获取错误、截图看效果、写 Markdown 文件、发飞书通知、查看禅道 Bug 情况、跟进飞书多维表格的任务进度，那他是不是真的可以成为某个领域中的我，然后再用 Multi Agent 技术来模拟许多个我，让我的效率得到千百倍的提高。这件事我会去做，不过估计做的会比较慢，我相信随着模型智力的提高，最终的那个“我”肯定比现在的我要更胜任我的工作，那时候我应该可以躺着了。
最近一直被安利 Claude Code，不过没抽时间去试，昨天偶然看到了一个 MiniJinja 的作者使用 Claude Code 修复现实中的 Issues 的视频，可以看到的是，Claude Code 并不能真正“完美”的完成任务，改动的方案并不是最佳的，也没有遵循用户的指令先进行方案讨论不要立马实现代码，修复这两个 Issue 都是需要资深开发者来介入的。所以我一直偏向 Cursor 这类 AI IDE，纯 Agent 很容易把原来优雅的代码改成屎山，然后又要花时间去把屎山做优雅。不过如果是 Vibe 一个简单的 Side Project 用这种方式应该还是很舒服的，等我下一个 Side Project 启动的时候我会开一个 100 刀的 Claude Code 试试。