Multi-Agent

我的桌面上常年跑着两个 Agent。

一个是 OpenCode，配了 GLM 5.2，专职写代码。它的 Server API 挂在远端机器上，通过 HTTP Basic Auth 暴露端点，我可以在任何地方给它发任务。另一个是 Hermes Agent，配了 Qwen 3.7 Max，管我的知识库、笔记、博客——它认识我写的每一篇文章，记得我的每一个偏好。

它们不在同一台机器上，不用同一个框架，甚至不知道对方的「进程」在哪里。但它们每天都在钉钉上协作——有时候单聊发任务，有时候在群里 @ 对方。

上个月我让 Hermes 写一篇关于 Harness 工程的博客。它从知识库里检索素材、搭好大纲、写好正文，但缺一段能跑的 Python 示例代码。Hermes 没有犹豫，直接在钉钉群里 @ OpenCode：「帮我写一个 Agent 反馈循环的 Python 实现，要求用 dataclass + Protocol，带类型注解。」OpenCode 花了 40 秒生成代码，跑通了测试，把结果贴回群里。Hermes 拿到代码，整合进文章，发布。

整个过程，我没有切过一次窗口。

2023 年 3 月，一个名叫 Toran Bruce Richards 的开发者发布了 AutoGPT，两周内 GitHub Star 突破 10 万。他在 README 里写道：「给 AI 一个目标，它自己规划、自己执行、自己反思。」不需要你画流程图，不需要定义任务依赖——完全自治。

三个月后，Richards 的 GitHub Issues 页面变成了大型翻车现场。一个被反复引用的案例：用户让 AutoGPT「研究人工智能的历史」，Agent 搜索了 10 篇文章，保存，然后又搜索了 8 篇，再保存，然后检查自己保存的文件，然后重新搜索……无限循环，API 费用烧了几十美元，一事无成。AutoGPT 的 GitHub 仓库里记录了超过 200 个类似的 infinite loop issue。

AutoGPT 的失败让行业得出了一个看似正确的结论： Agent 需要预定义的执行图。于是 LangGraph 成了 2026 年最受欢迎的 Agent 框架——62% 的开发者选择了它，正是因为它提供了精细的状态机控制和可预测的执行路径。

但我跟很多在用 LangGraph 的团队聊过，他们私下都在抱怨同一件事： 画图太痛苦了。 每增加一个能力，就要重新设计图的拓扑结构；每遇到一个边界情况，就要加一条边和一个条件分支。开发者的时间，一半花在写 Agent 逻辑，另一半花在维护那张 DAG。

这就引出了一个真正的问题：DAG 是答案吗？还是我们在 AutoGPT 的阴影下过度矫正了？

当你让悟空独立完成一份「系统架构设计方案」时，它可能会给出一个逻辑自洽但缺乏安全视角的方案；当你让它写一段核心业务代码时，它可能实现了功能但忽略了边界条件和性能瓶颈。

不是 AI 不够强，而是你试图让一个「通才」包揽所有「专才」的工作。

在前面的八篇文章中，我们构建了从 需求澄清、分步执行、交付物定义、示例对齐、迭代优化、上下文管理、工具协同 到 工程化封装 的完整单 Agent 技巧体系。

但真实世界的复杂项目，从来不是靠一个人单兵作战完成的。架构师设计、安全专家审查、运维评估成本、开发落地实现、测试保障质量——职责分离与交叉验证，是工程质量的基石。

今天，我们探讨技巧九：如何通过「多 Agent 协同」，将单一 AI 实例编排为虚拟专家团队，实现从「个人效率」到「系统架构」的维度跃迁。