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 之间的协作欢迎交流。这不是一个教程这是一个真实的建造记录——包括所有搞砸的部分。