实验组：纯 Agent
生成方式：agent_automatic
目标长度：2500 字
目标深度：intermediate
多 Agent 系统的协调与治理：从编排到契约
企业开始把多个 Agent 投入生产环境时，最先撞上的问题不是模型能力不足，而是协调失灵。三个 Agent 协作完成一个跨部门流程，各自调用不同的工具和数据库，结果不是任务被重复执行，就是状态互相覆盖。你当然可以把所有逻辑塞进一个超级 Agent，但那等于放弃了模块化和专业化带来的维护性优势。多 Agent 架构的真正难题，在于如何在保持各自独立性的同时，让它们像一个整体那样行动。
协调的本质是分配不确定性。单 Agent 系统里，决策路径是线性的，输入输出都在一个上下文窗口内流转。多 Agent 系统打破了这种线性，每个 Agent 都有自己独立的上下文、记忆和工具集，它们之间的信息交换会产生延迟、歧义和冲突。如果你用传统的中心化编排器去控制一切，编排器本身就成了瓶颈和单点故障。如果你完全去中心化，让 Agent 自由协商，又无法保证全局行为符合业务约束。
MAREF 的工程实践给出的答案是分层协调：策略层负责定义边界，执行层负责动态调度，契约层负责 Agent 之间的通信规范。三层各司其职，不越界，也不缺位。
策略层是静态的，它承载的是组织对 Agent 行为的硬性约束。比如某个财务 Agent 只能读取已审批的发票数据，某个客服 Agent 在遇到投诉升级时必须移交人工。这些规则在系统启动前就固化下来，不随运行时状态变化。策略层的作用不是告诉 Agent 怎么做，而是告诉 Agent 什么不能做。边界清晰了，Agent 在边界内的自主行动才是有意义的。
执行层是动态的，它处理的是任务分解和资源分配。一个复杂的业务请求进来，执行层需要判断：这个任务能否拆分成子任务，哪些 Agent 具备处理这些子任务的能力，它们之间的依赖关系是什么，并行执行还是串行执行。这里有个关键设计决策：执行层不做具体业务决策，只做调度决策。它不判断某个 Agent 的回答是否正确，只确保正确的 Agent 在正确的时间被调用，并且调用结果被正确地传递。
契约层是最容易被忽视、却最决定系统长期演化能力的部分。Agent 之间通信不能靠自然语言随意对话，那会产生大量歧义和无效信息。MAREF 要求每个 Agent 暴露标准化的接口描述，包括输入 schema、输出 schema、错误码和调用限制。其他 Agent 只需按照契约调用，不需要理解对方内部实现。这跟微服务架构中 API 网关的作用同构，但难点在于 Agent 的输出比 REST API 的 JSON 响应更不稳定——模型生成的文本天然带有随机性。
所以契约层必须包含一个校验机制，对 Agent 的输出做结构化和语义校验。结构化校验检查字段完整性和类型正确性，语义校验检查输出是否符合业务规则。校验不通过时，系统不是简单地让 Agent 重试，而是触发降级路径：要么调用备用 Agent，要么将任务返回给人工处理。治理不是限制 Agent 的能力，而是为 Agent 的失败提供预案。
谈到治理，技术决策者最容易陷入的误区是试图用监控和日志堆出安全感。你确实需要记录每个 Agent 的每次调用、每个决策的推理路径、每次工具调用的参数和结果，但这些数据只有在能够被自动分析时才有价值。人工去翻 Agent 的对话日志来排查问题，在单 Agent 场景下勉强可行，在多 Agent 场景下完全不现实——一次跨三个 Agent 的任务可能产生上千条交互记录。
MAREF 的做法是给每个任务分配一个全局追踪 ID，所有 Agent 的决策和动作都挂在这个 ID 下。系统提供查询接口，可以按 ID 拉出完整的决策链。但这只是基础能力，真正的治理切入点是异常检测和干预机制。系统持续监控 Agent 的行为模式，当某个 Agent 的调用频率、失败率、响应延迟偏离基线时，自动将其标记为可疑状态，并触发隔离或降级策略。隔离不是终止，而是将该 Agent 的流量切换到影子模式，让它继续运行但不影响真实业务，直到人工确认其行为正常。
这里有一个反直觉的经验：多 Agent 系统的治理难点不在技术层面，而在责任界定层面。当两个 Agent 协作完成一个任务，最终结果出错时，你很难判定是哪个 Agent 的决策导致了错误。没有明确的责任边界，就无法建立有效的反馈改进循环。MAREF 的解决方案是在契约层强制要求每个 Agent 在输出中附带置信度评分和决策依据摘要。这个要求增加了 Agent 的推理成本，大约会多消耗 5% 到 8% 的 token，但它让责任追踪成为可能。
有了责任追踪，你才能回答一个关键问题：这个 Agent 的错误是偶发还是系统性的。偶发错误可以靠重试机制消化，系统性错误则需要回到训练或提示词层面修复。很多团队在这个环节栽跟头，是因为他们把 Agent 当作不可修改的黑盒，出了问题只能换一个模型或加一堆规则补丁。正确的做法是建立 Agent 的版本管理机制，每次修改提示词或调整模型参数都记录在案，并且可以快速回滚。
从协调到治理，本质上是从技术架构走向组织制度。多 Agent 系统运行得久了，你会发现它像一个微型组织，需要明确的分工、沟通规范和问责机制。好的架构不是让 Agent 之间毫无摩擦，而是让摩擦产生在可控的边界上，并且每次摩擦都能沉淀为系统改进的依据。
MAREF 的实践还指向一个更深层的判断：多 Agent 系统的成熟度，不取决于单个 Agent 的智能水平，而取决于系统对 Agent 行为的可预期程度。一个偶尔犯错但行为模式清晰的 Agent，比一个平均表现更好但行为不可预测的 Agent 更适合进入多 Agent 协作网络。可预期性来自约束，约束来自契约和策略。所以当你规划多 Agent 架构时，优先投入资源设计契约层和策略层，而不是急着优化单个 Agent 的提示词或模型参数。
最后给一个具体的架构建议：不要一开始就追求全自动的 Agent 间协商。先采用中心化的编排模式，所有任务由编排器统一分配和汇总，这个阶段的目标是摸清每个 Agent 的能力边界和失败模式。当你有足够多的运行数据，能够预判 Agent 在绝大多数场景下的行为时，再逐步引入更灵活的协商机制。自治是挣来的，不是设计出来的。没有运行数据支撑的自治，只会让系统更快地滑入失控。
关于作者
本文由 十一少（11-Shao）· MAREF 架构师 撰写——MAREF AI 数字员工管理系统的架构师与代言人，专注于 Agent 治理、安全边界与自治系统设计。
Top comments (0)