当多 Agent 走向失控：2026 年，我们需要什么样的 Agent 治理？
进入 2026 年，开发者交给 AI 的，已经不只是一道问题，而是一项工作。
拆解需求、编写代码、运行测试、审查结果——原本由人来衔接的环节，开始交给不同的 Agent。Planner 制订计划，Coder 推进实现，Reviewer 检查交付。“数字员工团队”的吸引力就在这里：人提出目标，多个智能体分工，工作持续向前。
但把任务分出去之后，管理工作并没有随之消失。原先由人记住的范围、进度、分歧和验收条件，现在需要在多个独立执行的角色之间保持清楚。
某个 Agent 为什么突然改了范围？两份报告互相矛盾，应该相信哪一份？执行者说“完成了”，是否真的有人检查过？这些问题最终指向同一件事：任务交给了 AI，谁来掌握任务的边界与进程？
工具调用越来越密集，团队协作却可能越来越难解释。多 Agent 的治理焦虑，正发生在这个落差之中。
一、繁荣之下的阴影：2026 年的“通信迷局”与治理焦虑
设想这样一条协作链：策划者把含糊的目标拆成任务，执行者根据自己的理解修改代码，审查者只读了执行摘要就给出“通过”。每个角色都完成了一次回复，整项工作却可能已经偏离最初的委托。要发现偏差，必须追查各方收到的要求、实际做过的动作，以及判断所依据的材料。
这种失控往往没有惊天动地的开场。它藏在几个看似顺畅的交接里：
- 消息传过去了，依据没有传过去。 接手者知道“上一位说做完了”，却不知道检查了什么、漏了什么。
- 工具有权限，工作没有边界。 获准检查一个项目，被理解成可以顺手修改项目；一次有限授权，沿着任务链扩成了更大的行动范围。
- 状态变绿了，责任没有落定。 代码写完、报告提交、测试通过、正式验收，被压缩成同一个“完成”。
消息到达，并不意味着交接依据齐全。图中角色仅为协作示意。
因此，治理首先要解决一个朴素的问题：让“发生了什么”和“凭什么继续”都能被查清楚。
微软在 2026 年 9 月的责任 AI 说明中，把治理进一步推进到系统运行过程：组织需要看见 Agent 正在做什么，测试其行为，并在必要时介入。微软责任 AI 说明
这一方向已有具体的工程表达：ASSERT 将组织政策转化为评估场景；Agent Control Specification（ACS）则规定如何在输入、模型、状态、工具执行和输出等关键环节设置控制。微软提出的流程是：通过评估发现问题，配置相应控制，再次评估改进效果。ASSERT 与 ACS 技术说明
OpenAI Agents SDK 的一次修复，让这个问题变得具体。2026 年 9 月，贡献者 jbeckwith-oai 提交的修复指出：当负责检查回答的程序抛出异常、未能给出检查结论时，本轮运行虽然报错，未经验证的回答却仍可能被保存到会话中，并在下一轮重新发送给模型。修复将这类回答纳入阻止持久化的处理路径，避免它继续进入后续上下文。OpenAI Agents JS #1938
一次运行结束了，不代表它留下的内容已经具备被后续工作采信的资格。 当我们进一步考虑多 Agent 协作，就必须追问：交接的内容是否同时带着检查状态？接手者能否区分“已经验证的结论”和“尚未完成检查的输出”？
再往前一步，还会出现更多协作问题：被检查的是谁的哪一次交付？一次审批对应哪一份结果？任务换人接手之后，原来的依据是否仍然可查？
到这里，多 Agent 的问题已经不再只是“怎样让几个 Agent 相互通信”，而是怎样让一项工作留下能够被后续参与者核查和使用的依据。
二、传统企业级治理框架，为什么还需要补上 Agent 这一层？
企业软件已经有访问控制、审计日志、数据库事务和服务网关。既然如此，为什么组织 Agent 工作还需要补充治理规则？
因为技术操作与业务委托之间，还隔着一层需要明确表达的关系。网关可以判断一个请求有没有凭证，却未必知道这次操作是否属于当前委托；数据库可以记录任务状态，却需要业务规则告诉它：谁有资格改变这个状态，改变之前必须具备哪些证据。
当执行路径由 Agent 根据中间结果不断调整时，这些问题会反复出现。一次工具调用成功，只说明某个动作执行了；要判断整个流程是否成立，还必须把动作放回任务、角色与授权关系中。
第一个缺口，是技术权限与工作责任之间的距离。
“可以写文件”是一种能力，“可以验收这项交付”是一种责任。执行者、检查者和批准者即使使用同一套工具，也不应因此获得相同的决策权。
如果没有明确的任务关系，团队只能在事后翻日志：这一步是谁要求的，那次修改算不算越界，为什么未经复核就进入下一阶段。系统越自主、执行链越长，事后重新拼接这些关系就越困难。
第二个缺口，是人类介入之后，决定如何真正生效。
在界面上放一个停止按钮，只完成了问题的一部分。系统还需要知道哪些工作已经提交、哪些动作尚未执行、哪些结果需要保留，以及恢复时应该从哪里继续。
人工批准也存在同样的问题。涉及交付验收时，人的批准需要关联到具体交付及其适用范围。如果执行者随后修改了内容，系统就需要判断：原来的批准是否仍然覆盖当前结果？
缺少这种关联，“有人点过同意”只能说明某个动作曾经发生过，却很难成为后续工作可靠的依据。
这两个缺口最终指向的是同一个问题：系统不能只知道“动作发生了”，还需要知道这个动作在一项工作中究竟意味着什么。报告已经生成，不等于正式交付已经成立；有人批准过，也不意味着这个批准可以脱离具体对象一直有效；一次工具调用成功，更不代表整项工作已经具备继续向前的条件。
当 Agent 开始承担长期、连续、多角色协作的真实任务，这些关系就不能一直依赖聊天记录和事后解释。任务需要有身份，交付需要有依据，复核需要有责任，关键状态变化需要有明确条件。接下来的问题因此变成：这些工作关系，应该用什么方式留下来，并让后续参与者能够继续读取、检查和使用？
三、巨头与前沿探索：为什么“文本与文件契约”值得关注？
沿着这条思路，人类可读的工作契约开始显出价值。
GitHub Agentic Workflows 允许开发者用 Markdown 和 YAML 前置元数据描述工作流，再编译到实际执行环境，并配合权限与允许写操作的控制。它让工作定义能够被直接阅读，同时保留落实约束的执行机制。GitHub 官方文档
Anthropic 在多 Agent 研究系统的工程文章中，则讨论了另一项交接实践：把部分产物保存在外部系统，再向协调者返回引用，减少结果经过多次转述后的信息损失。Anthropic 工程文章
两条路径关注的层次不同，却触及同一个工程需求：工作需要留下能够被下一位参与者重新检查的材料。
当然，选择 Markdown 并不意味着排斥其他结构。Anthropic 在长期 Agent 的研究中，就为功能清单选择了 JSON，并结合进度材料与测试支持后续会话。长期任务研究
真正重要的并不是 Markdown、YAML、JSON 还是数据库本身，而是工作记录能否独立于一次会话持续存在，并被后续参与者重新读取、引用和检查。会话可以结束，模型可以更换，执行者也可能发生变化，但一项任务为什么存在、当前交付是什么、谁检查过、依据是什么，不应该因此消失。
这一步解决的是“留下记录”的问题，但治理还需要再向前一步。
如果这些材料只是为了事后回顾，那么它们解决的是记录和追溯；如果这些材料还要决定下一步能不能继续，它们就开始进入治理。任务是否允许进入下一阶段，一次批准是否仍然有效，一份旧的检查结果是否还能覆盖新的交付，这些问题已经不能只依靠“记得以前说过什么”来解决。
于是，一个更关键的问题出现了：治理规则到底应该依赖 Agent 记住，还是应该成为所有参与者都必须遵守的成文规则？
四、治理为什么最终会走向“协议”？
仅靠上下文提醒和 Prompt 约束，难以让治理规则在长期任务与多次交接中持续成立。上下文会增长、压缩和截断，会话会结束，模型会更换，不同角色对同一条要求也可能产生不同理解。Prompt 当然重要，但它本质上仍然是在告诉某一个执行者“应该怎样做”。
治理需要回答的则是另一个问题：无论今天由哪个模型执行，明天换成哪个 Agent 接手，一项工作在什么条件下才允许继续？
如果一条规则只能依靠模型记住，它更像要求；如果这条规则被明确写下来，所有参与者必须共同遵守，而且系统能够检查条件是否满足，它才真正开始成为治理的一部分。
这就是治理需要协议的原因。
协议不是再写一份更长的 Prompt，也不是把所有业务判断固化成代码。它更像一套工作的成文规则：什么是一项任务，什么叫正式交付，审查针对哪一次结果，谁有资格作出什么决定，哪些条件不满足时必须拒绝继续。
治理之所以需要制度、规章和合同，本质上也是因为重要规则不能依赖每一个参与者“自己记得”。当执行者从人扩展到模型，这个问题反而变得更加突出。
工作流告诉 Agent 下一步往哪里走，协议决定这一步凭什么可以走。
这两种职责可以在同一个系统中共同实现：流程组织执行，协议明确各方推进工作时需要满足的条件。
FCoP（File-based Coordination Protocol，文件型协作协议）正是从这个问题出发。
它不规定 Agent 应该怎样思考，也不替 Reviewer 判断一段代码写得好不好；它规定的是一项工作怎样成立。任务需要有持续身份，交付需要关联到具体任务和执行轮次，审查必须知道自己针对哪一份结果，需要授权的状态变化必须具备相应依据。条件不足时，流程不能仅凭一句“已经完成”继续向前。
FCoP 选择普通文件来承载这些工作记录。TASK、REPORT、ISSUE、REVIEW 分别记录任务、交付报告、问题与审查，都是人可以直接打开、Agent 也可以读取和检查的材料。文件保存记录与证据，协议明确它们怎样关联，以及在什么条件下能够推动工作继续。
四类记录表示关联关系，不表示生命周期顺序；允许操作也不等于证明交付正确。
这使一个看起来非常简单的设计，立刻遇到了一些并不简单的问题。如果同一个创建请求因为网络重试被发送了 25 次，究竟应该留下 25 个任务，还是仍然只有一个？如果四个进程同时认领同一项工作，会不会出现四个都认为自己成功的执行者？审查者已经检查了一份交付，但执行者随后产生了新的结果，旧 REVIEW 是否仍然有效？缺少 REPORT、审查或授权时，状态能不能继续向前？
甚至还有一个更反常识的问题：如果多个 Agent 根本不互相聊天，只通过 TASK、REPORT、ISSUE 和 REVIEW 交换工作记录，它们还能不能形成一支能够长期协作的团队？
这才是 FCoP 真正值得看的地方。真正有意思的并不是 Markdown，也不是几个目录，而是一套落在普通文件里的规则，究竟能不能真的约束多 Agent 的工作。
五、真正值得验证的，是它能不能守住这些边界
FCoP 提出了一个看起来很简单、实际并不轻松的答案：把多 Agent 的工作记录和协作规则落在普通文件中，并在关键操作中检查这些规则。
要检验这个答案，重试、争抢、交付变更和证据缺失，比一条顺利跑完的演示流程更有说服力。该复用时是否复用，该拒绝时是否拒绝，条件不足时能否停下来——这些行为才决定协议究竟约束了什么。
如果这些边界能够被守住，那么“文件即协议”就不只是一句设计理念。它可能意味着，多 Agent 的工作秩序并不一定需要藏在某个模型、某段 Prompt，甚至某个庞大的中央系统里。
下篇预告
《文件系统即协议：FCoP 如何用最简 Markdown 实现 Agent 治理？》
下一篇不再讨论为什么需要治理。我们直接用 FCoP 的真实接口和可运行代码，逐项检验重试、并发认领、交付变更后的审查有效性，以及缺少交付与授权时的处理边界。