多 Agent 如何才能成功？

多 Agent 只是解决复杂问题的手段，而不是目的。

实现业务价值，覆盖工程成本，才是架构设计的终极目标。

一、场景决策

• 非必要不上智能体 能用提示词工程搞定的绝不上智能体，不行再加工具，只有当单体能力触及天花板且业务价值足以覆盖增加的成本和延迟时，才采用多智能体架构。

• 识别黄金场景 MAS 仅适用于长链路复杂 SOP、需要多视角验证、复杂工具调度、以及需要大规模并行搜索或上下文隔离保护的场景。

二、架构硬化

• 三层分离架构 将系统分为调度层、执行层、推理层，实现职责清晰、边界明确。
• 物理解耦 将模型推理与沙箱环境物理分离。沙箱应采用容器技术（如 Docker）实现全隔离，可随时销毁。

• 权限物理拦截 在系统中间件实现工具访问控制（TAC），而非仅靠 Prompt 约束。如果智能体尝试越权，系统层应直接物理拦截。

三、流程锁定

• 按上下文边界拆分：不要按工作类型（开发、测试）拆分任务，而应按上下文边界拆分。例如，负责功能的智能体也应负责其测试，因为拆分高度耦合的任务会导致严重的“传声筒效应”和信息损耗。

• 拓扑锁定：放弃不可控的纯对话驱动，改用图状态机（如 LangGraph）预设确定的路由，实现“化死条件路由”，强制任务按 SOP 路径流转，严防死循环。

• 选择合适的模式：
  • 顺序流：用于明确的步骤依赖。
  • 并行流：用于扩大搜索空间（如多路市场研究）。
  • 评估-优化流：用于对产出质量要求极高的场景。

四、状态治理

• 状态外置持久化：严禁将任务进度存在模型内存里。应将任务清单、经验日志（记录踩过的坑）和成果快照（Git Commit）物理存入硬盘。

• 全新上下文滚动（RALPH Loop）：每一轮任务开始前，清空全量对话历史，开启一个全新的上下文窗口，仅从硬盘重载 State JSON。这能实现“大脑清洗”，确保智能体始终清醒且无历史冗余信息的干扰。

五、质量保证

• 引入确定性的外部判据：验证不能全靠 LLM 互粉。必须接入代码编译器、Linter 或单元测试生成器。只有工具返回 Success 信号才判定验证通过。

• 任务微型化与硬验收标准：将大需求拆解为单次循环可完成的 User Story，并固化验收标准，如：响应延迟 ≤ 200ms。验收标准写得越死越好，防止模型偷懒或画饼。

• 红蓝对抗机制：引入功能对立的角色（如激进派 vs 保守派），让对抗派专门找茬，最后由具有本体论约束的大法官裁决，以此压制模型的幻觉。