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 可以根据被驳回的记录来优化本身的处理逻辑——我希望未来不再是靠我手动改提示词，而是靠系统记录的历史反馈数据来主动迭代。
这就是我计划的三条原则：

• 写和审必须是差别的 Agent。有一个写的，就有一个审的；有一个运行的，就有一个测试的。对抗角色必须有。
  
• 容易幻觉，那就加门禁。与其指望 Agent 做对，不如在系统层面拦住它做错。不满足条件就不让过——这是代码级别的硬约束，Agent 的语言能力绕过不了。
  
• 自我进化靠审计记录。每条流水账都是养料。抱负的闭环是：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 之间的协作，欢迎交流。这不是一个教程，这是一个真实的制作记录——包括所有搞砸的部分。