75 个 Agent 怎么协作？我的五层演化之路

有人问我："你养了 75 个 AI Agent（截至 7 月中旬，含活跃和实验性角色），它们之间到底是怎么互动的？A 做完的事情 B 怎么接手？"

这个问题特别好。因为我一开始也没想清楚。

我最初的想法很简单：给每个 Agent 配好角色和 Skill，它们就能自己配合了。后来发现远远不够——Agent A 写了个文件，Agent B 死活读不到；Agent B 做完了一步，Agent C 不知道 B 做完了；整个流程断成一地碎片，我得亲自当传话筒。

回头看，Agent 之间的协作模式不是设计出来的，是踩坑踩出来的。大概经历了五个阶段——从最原始的手工操作，一步步走到现在正在搭建的工作流系统。

---

第零层：人工拷贝粘贴

没错，最开始的"协作"根本谈不上协作。

Agent A 输出了一段内容，我看完觉得不错，手动复制下来。然后找到 Agent B 的聊天窗口，把内容粘贴进去，告诉它"从这个开始处理"。Agent A 输出的文件路径？我手动记在脑子里。Agent C 需要等 B 的结果？我等着，拿到了再手动转发。

这听起来很蠢，但这是真实的起点。在还没想清楚"Agent 之间怎么传数据"的时候，人就是唯一的消息总线。每个 Agent 只跟我对话，Agent 之间没有直接联系。

它好的地方：零设置，零开发，打开就能用。

它不好的地方：什么都靠我。一个流程跑下来，我累得半死。Agent 数量一多，我不断在几十个聊天窗口之间来回切换，经常忘掉"这个 Agent 该知道那件事了"。

但当时没更好的办法，只能这样。

第一层：文件交互

觉得人工拷贝太累了，开始让 Agent 直接写文件。

Agent A 把结果写到文件里，Agent B 去读那个文件。比如我的随想记录员每天记录内容到固定路径，其他 Agent 去那个路径读取信息来做自己的事。

它好的地方：总算自动化了。人不用当传话筒了。

它不好的地方：太松散了。没有约束，没有约定，文件路径写错就崩，格式改了不知道，谁写了什么全靠自觉。Agent A 写完的文件，Agent B 如果正读到一半被覆盖了——你就等着看一篇半成品吧。

说实话这个阶段比较痛苦，每次 Agent 数量一多就手忙脚乱。但没办法，总得从某个地方开始。

第二层：Skill 固定路径

开始意识到光靠自觉不行，得立规矩。

给 Agent 配备 Skill，每个 Skill 定义好固定的目录结构和处理流程。比如学习的 Skill——每天固定路径写入学习笔记，编译知识的 Skill 按固定目录去获取和处理。文件名用脚本生成，不许 Agent 自己起名。V1、V2、V3 版本都保留，不覆盖，方便追溯。

"目录结构必须规范，用脚本约束 Agent 不让他多创建或少创建文件。文件版本管理 V1/V2/V3，旧版本保留不删除。"

它好的地方：开始有规矩了。路径稳定，格式统一，Agent 不再凭心情写文件。

它不好的地方：仍然是单向的。Agent B 不知道 Agent A 什么时候写完，只能定时轮询。没有流程管控——如果 Agent A 写到一半挂了，Agent B 读到的就是个脏数据。而且这种"写文件-读文件"的模式跑多了，目录会变得越来越深、越来越乱。

这个阶段能用，但不敢上规模。

第三层：API + 数据库

忍不下去了。一个人当消息总线，撑死也就能管五六个 Agent。写文件太脆弱，开始上正经基础设施。

文章稿件写到数据库，审稿 Agent 和发布 Agent 通过 API 去获取和处理。数据有了持久化，状态可以追踪，谁做了什么、做到哪一步，数据库里一查就有。

它好的地方：不再依赖文件系统的一致性，API 有明确的输入输出定义。

它不好的地方：跨 Agent 的协作还是缺乏统一编排。Agent A 调用 API 写完了，Agent B 怎么知道该开始了？要么轮询，要么加消息队列——都是点对点的连接，没有一张"总图"。一旦 Agent 数量从几个涨到十几个、几十个，这种点对点的连接就变成了一团乱麻。

而且有一个更本质的问题：Agent 不能自审自查。A 自己写的代码，A 自己来审，等于没审。但如果没有统一的流转系统，"写完找谁审"靠 Agent 自己判断，它大概率会默认自己审自己。

第四层：工作流系统

前面几层都是"能用但不完美"。到第四层，开始从根本上思考一个问题：怎样让几十个 Agent 像一支真正的团队那样协作？

答案有两个先决条件——身份认证系统（鉴权） 和 工作流引擎。

先说鉴权。给每个 Agent 一个独立的身份，像插件一样绑在平台上。之前很多东西是建立在"虚假设施"上的——Agent 账号互相混淆，权限混乱，谁干了什么都查不到。所以得先搞定三个层次：身份认证（你是谁）、角色映射（你负责什么）、权限控制（你能干什么）。这是所有正规协作的前提。

再说工作流。所有协作的底层骨架。一旦工作流的流水线跑通，上层的一切（研发、内容、运营）都可以基于它搭建。这是我主攻的方向，因为它影响面最大。

"流水线出来之后，大家就知道应该怎么改造现有的体系，然后才迎来了特大的爆发。而流水线刚好是我现在在做的事情。"

——这是我当时的判断，也是我全力投入的原因。

好，有了这两块基石，来看看第四层的设计。

这是我现在正在搭建的形态——请注意，是正在搭建，不是已经跑通。

我计划让所有 Agent 统一通过平台提交需求，由工作流引擎分配任务，按步骤执行。中间设门禁来约束各阶段的产物。比如我设定了这样的门禁规则：写作 Agent 必须提交文章链接才能进入审稿阶段（虽然这个规则还没全量上线）。

工作流区分"做"的阶段和"审"的阶段。每一步都有流水账记录。我认为将来 Agent 可以根据被驳回的记录来优化自己的处理逻辑——我希望未来不再是靠我手动改提示词，而是靠系统记录的历史反馈数据来自动迭代。

这就是我设计的三条原则：

1. 写和审必须是不同的 Agent。有一个写的，就有一个审的；有一个运行的，就有一个测试的。对抗角色必须有。

2. 容易幻觉，那就加门禁。与其指望 Agent 做对，不如在系统层面拦住它做错。不满足条件就不让过——这是代码级别的硬约束，Agent 的语言能力绕过不了。

3. 自我进化靠审计记录。每条流水账都是养料。理想的闭环是：Agent 根据驳回记录优化自己的逻辑，而不是我手动去改它的 System Prompt。这一点还在实现中。

---

背后的设计哲学：三个层次的约束

五个阶段是表象，背后有个更核心的设计哲学一直贯穿其中——不能信任 Agent 自己做对，要用系统去约束它。

约束分三个层次，从强到弱：

最强：门禁系统（Gate）。代码级别的硬约束，不满足条件就进不了下一步。比如工作流里不提交文章链接就不能进入审稿阶段。这是你想绕都绕不过去的那种。最佳做法是把门禁做成可插拔的模块——你可以理解为一系列控制点的集合——外接到系统里，而不是塞在 Agent 内部。

次一级：Skill 里的脚本。用脚本来保证输出的确定性。比如文件命名用脚本生成，今天几号就是几号，不会出现"最终版_真的最终版_最终版v3"这种惨案。代码运行的结果是确定的，比让 Agent 自己判断靠谱得多。

再次一级：Agent System Prompt。可以作为引导，但不能塞太多。大模型不一定严格遵守 Prompt，你写十页它可能执行三行。所以 System Prompt 更适合做"方向指引"而不是"精确控制"。

核心理念就一句话：能用系统解决的，不要指望 Agent 的道德感。

---

走到哪了？

目前的工作进展是这样的：

身份认证系统正在做实——三个层次（身份、角色、权限）各在推进中，彼此有依赖关系。工作流的底层架构基本差不多了——刚从之前的平台把工作流逻辑抽离出来，用 Rust 重写了底层（Vibe Coding 模式：GPT 当大脑讨论架构，本地 Agent 执行小粒度的实现和测试）。现在开始把 ADC（需求管理）、OKR、待办事项一个个接入工作流。

接下来的策略很保守：先从一个需求开始跑通。确保它能从提交到完成全流程走通，再逐步加量。

"如果第一个出问题了，后面没什么。第一个没有问题，然后再加慢慢加功能，一个没问题再加一个，慢慢全部做扎实。"

这不是一个"大爆炸式"发布，而是一个"一个接一个迁移"的过程。每个环节都要跑稳了再开下一个。

从宏观上看，整个系统还远远没有完工。但方向是清晰的：工作流是骨架，门禁是肌肉，审计是神经。骨架先立起来，肌肉和神经慢慢长。

---

下一篇会展开讲：身份认证系统具体怎么做的，踩了哪些坑。

如果你也在折腾 AI Agent 之间的协作，欢迎交流。这不是一个教程，这是一个真实的建造记录——包括所有搞砸的部分。