这两年 Multi-Agent 很火。

只要涉及复杂任务，很多方案似乎都会自然演变成：

一个 Planner，下面挂几个 Agent，大家各司其职、相互协作，最后再由 Supervisor 汇总结果。

从 Demo 上看，这种架构非常漂亮。

但真正放到企业项目里，很快就会发现一个问题：

Multi-Agent 最难的地方，从来不是“怎么做几个 Agent”，而是怎么让这些 Agent 在复杂任务里保持可控。

任务到底怎么拆？

谁应该执行？

Agent 之间怎么传递上下文？

一个 Agent 错了之后，怎么防止错误继续扩散？

多个 Agent 同时跑的时候，Token、模型并发、数据库连接、工具权限又由谁管理？

如果这些问题没有解决，那么 Agent 数量越多，系统反而越容易失控。

所以在我看来，真正适合企业落地的 Multi-Agent，不应该从“我要设计几个 Agent”开始，而应该从一个更基础的问题开始：

如何把复杂业务拆成明确的责任主体，并通过任务契约、共享状态、验证机制和统一 Runtime，把它们组织成一个可控系统。

---

一、Multi-Agent 首先应该是“场景型”的

我更倾向于一种相对保守的 Multi-Agent 设计：

先限定业务场景，再设计 Agent。

而不是一开始就试图做一个什么任务都能规划、什么 Agent 都能动态生成的“通用智能体社会”。

对于一个明确业务场景，核心结构其实可以比较固定：

用户任务
   ↓
Supervisor / Coordinator Agent
   ↓
任务拆解 + Agent选择 + 状态管理
   ↓
┌────────────┬────────────┬────────────┐
│ 专业 Agent A │ 专业 Agent B │ 专业 Agent C │
└────────────┴────────────┴────────────┘
       ↓           ↓
     Skill / Tool / MCP
       ↓
Shared State / Artifact / Evidence
       ↓
Review / Validation
       ↓
Supervisor 汇总
       ↓
最终结果

这里真正重要的不是 Agent 的数量，而是每一层的职责。

Supervisor 负责任务拆解、路由和状态控制。

专业 Agent 对特定业务结果负责。

Tool、Skill、MCP 提供底层能力。

Shared State 保存不同 Agent 之间需要共享的信息。

Validation Gate 负责阻断错误。

最后由 Supervisor 汇总。

这样整个系统才是一条明确的任务执行链路，而不是几个模型互相聊天。

---

二、先定义场景边界，再定义 Agent

真正开始设计之前，我认为第一件事情不是画 Agent 架构图，而是把场景边界讲清楚。

至少需要回答几个问题：

• 输入是什么？
• 最终输出是什么？
• 系统负责什么？
• 系统明确不负责什么？
• 哪些结果允许模型判断？
• 哪些结果必须程序验证？
• 哪些节点需要人工确认？

这是整个 Multi-Agent 架构最重要的前置条件。

因为如果业务边界本身都没有定义清楚，后面的 Agent 拆分一定会越来越混乱。

很多所谓 Multi-Agent 系统最后变得复杂，并不是 Agent 技术本身有多复杂，而是：

业务职责本来就没有划分清楚。

---

三、Agent 应该按照“责任”拆，而不是按照“工具”拆

一个很常见的误区是：

有一个搜索工具，就做一个搜索 Agent。

有一个 SQL 工具，就做一个 SQL Agent。

有一个 OCR，就做一个 OCR Agent。

最后形成：

Search Agent
SQL Agent
OCR Agent
RAG Agent
API Agent

这种设计本质上只是给 Tool 外面套了一层 LLM。

我更认可的方式是：

按照“谁对结果负责”划分 Agent。

比如一个企业风险分析场景，可以拆成：

材料分析 Agent
财务分析 Agent
政策风险 Agent
风险综合 Agent
报告生成 Agent

然后每个 Agent 自己拥有允许使用的能力。

例如：

财务分析 Agent
├─ SQL
├─ 财务知识库
└─ 计算工具

而不是：

SQL Agent
RAG Agent
Calculator Agent

前者是业务角色。

后者只是工具代理。

Agent 应该成为责任主体，Tool 才是能力。

这个区别非常重要。

---

四、每个 Agent 都应该有明确契约

Agent 一旦被当成一个独立执行单元，就不能只定义一句 Prompt：

“你是一个风险分析专家。”

这远远不够。

一个相对完整的 Agent Contract 至少应该定义：

Role
Goal
Scope
Boundary
Skill
Input
Output
Failure Type

例如：

Role:
企业风险分析 Agent

Goal:
基于企业材料和征信信息识别风险因素

Scope:
财务风险、经营风险、征信风险

Boundary:
不得做最终审批决策

Skill:
SQL / RAG / 征信查询 / 风险规则

Input:
企业信息、财务数据、征信数据

Output:
risk_factors / evidence / confidence

Failure:
DATA_MISSING
TOOL_ERROR
INSUFFICIENT_EVIDENCE
RULE_CONFLICT

这样 Supervisor 才知道：

什么任务应该派给它，

什么任务不应该派给它，

执行成功应该返回什么，

执行失败之后应该如何处理。

否则多个 Agent 很容易出现职责重叠。

---

五、Task 和 Result 必须标准化

Multi-Agent 很容易犯的一个错误，是 Agent 之间通过自然语言描述任务。

比如：

“你帮我看看这个企业有没有风险。”

然后另一个 Agent 再自己理解。

任务数量少的时候问题不明显，一旦开始并行、重试、依赖编排，系统马上变得不可维护。

更合理的方法是定义统一 Task Schema。

例如：

{
  "task_id": "task_1024",
  "parent_task_id": "task_1000",
  "goal": "分析企业财务风险",
  "owner": "financial_agent",
  "dependency": ["task_1010"],
  "priority": 2,
  "status": "PENDING",
  "timeout": 30,
  "retry": 2,
  "expected_output": "financial_risk_report"
}

至少需要包含：

task_id
parent_task_id
goal
owner
dependency
status
expected_output

同样，Agent 返回结果也应该统一。

例如：

{
  "status": "SUCCESS",
  "result": {},
  "evidence": [],
  "confidence": 0.91,
  "issues": [],
  "next_action": null
}

至少包含：

status
result
evidence
confidence
issues
next_action

做到这一步之后，Agent 才真正从“几个模型角色”变成了一个可以被调度的任务执行系统。

---

六、第一版一定要限制 Agent 的自治范围

Multi-Agent 很容易让人产生一种冲动：

既然 Agent 能规划，那为什么不让它无限拆？

既然它能调用其他 Agent，那为什么不让 Agent 之间自由协作？

理论上当然可以。

但第一版工程系统最好完全反过来。

应该主动限制：

Agent 集合
任务拆解深度
Agent 调用次数
LLM 调用次数
Token Budget
Tool 调用次数
Retry
Timeout

例如：

max_depth = 3
max_retry = 2
max_agent_calls = 10
max_token = 30000
timeout = 60s

Agent 并不是越自主越好。

企业场景真正需要的是：

有限自治。

也就是在确定的边界内允许 Agent 自己决策，而不是完全开放。

---

七、Agent 之间不要共享完整聊天记录

这是 Multi-Agent 最容易出现 Token 爆炸的地方。

假设 Agent A 有 20k 上下文。

然后传给 B。

B 再产生 10k。

接着整个上下文传给 C。

很快就会变成：

Agent A：20k
Agent B：30k
Agent C：45k
Agent D：60k

Agent 数量增加之后，上下文成本会快速膨胀。

所以我更倾向于引入一个 Shared Workspace。

               Shared Workspace
              /       |        \
          Agent A   Agent B   Agent C

Agent 不互相复制完整对话。

Workspace 里保存结构化信息：

{
  "task": "分析某企业风险",

  "artifacts": {
    "financial_analysis": "artifact://123",
    "policy_analysis": "artifact://456"
  },

  "facts": [],

  "evidence": [],

  "hypothesis": [],

  "decisions": [],

  "risks": [],

  "errors": []
}

Agent 每次只读取自己需要的信息。

这时候 Agent 之间传递的就不是“聊天历史”，而是任务状态与产物引用。

---

八、必须区分 Fact、Evidence、Hypothesis 和 Decision

这一点我认为尤其重要。

Multi-Agent 一个非常危险的问题是：

A 的推测，很容易在传递过程中变成 B 的事实。

例如 Agent A 输出：

“该企业可能存在现金流压力。”

Agent B 收到后可能变成：

“该企业存在现金流压力。”

到了 Agent C：

“由于企业现金流存在问题……”

一个概率判断经过几轮 Agent 之后，就变成了确定事实。

所以 Shared State 最好强制区分：

Fact
Evidence
Hypothesis
Decision

例如：

{
  "facts": [
    {
      "content": "2025 年经营现金流为 -320 万",
      "source": "financial_report.pdf"
    }
  ],

  "hypothesis": [
    {
      "content": "企业可能存在现金流压力",
      "confidence": 0.72
    }
  ]
}

模型生成的判断不能自动升级成事实。

这是 Multi-Agent 系统保证上下文可靠性的关键设计之一。

---

九、Validation Gate 是阻止错误级联的关键

Single Agent 错一次，通常只是当前答案错了。

Multi-Agent 错一次，问题可能严重得多。

因为后面的 Agent 会建立在前一个 Agent 的结果上继续推理。

最终甚至会出现一种非常危险的情况：

整个答案结构完整、逻辑流畅，但全部建立在第一个错误之上。

所以关键任务之间必须设置 Validation Gate。

例如：

材料解析 Agent
      ↓
字段完整性校验
      ↓
财务分析 Agent
      ↓
数值一致性校验
      ↓
风险分析 Agent
      ↓
风险规则校验
      ↓
报告 Agent

验证可以有三种方式：

Rule Validation
Program Validation
LLM Review

优先级应该是：

程序校验 > 规则校验 > LLM Review

能够用程序验证的东西，不要交给另一个模型判断。

比如：

• 数字是否一致
• JSON 字段是否完整
• 引用是否存在
• 枚举是否合法
• 金额计算是否正确
• 必填字段是否缺失

这些完全可以程序化验证。

---

十、Multi-Agent 最值得测试的八个地方

Multi-Agent 测试不能平均用力。

真正应该深度测试的是几个高风险节点。

1. 任务拆解

这是第一优先级。

重点测试：

是否漏任务
是否重复拆任务
是否拆得过细
是否拆得过粗
依赖关系是否正确
是否错误并行

甚至可以专门构造一套“容易拆错”的复杂任务数据集。

因为第一步拆错，后面全部都会错。

---

2. Agent 路由

这里测试的重点不是：

Agent 会不会做？

而是：

这件事情到底该不该由它做？

尤其多个 Agent 能力存在重叠的时候，很容易出现：

Agent A 做一次
Agent B 又做一次
Supervisor 再做一次

既浪费 Token，又可能产生结果冲突。

---

3. 上下文传递

需要重点验证：

证据有没有丢失
旧数据有没有覆盖新数据
不同 Agent 是否看到不同版本
Hypothesis 是否被当成 Fact
上下文是否越来越大

这也是为什么结构化 Shared State 很重要。

---

4. 错误级联

必须专门构造：

上游 Agent 输出错误结果

看看下游 Agent：

是继续相信，

还是能够发现问题。

这是 Multi-Agent 和普通 Agent 最大的测试差异之一。

---

5. 终止与重试

一定要测试：

Agent 无限 Retry
无限拆任务
A → B → A
循环委托
Tool 一直失败
模型一直要求补信息

所以必须存在：

max_depth
max_retry
max_agent_calls
timeout
budget

这些其实就是 Agent Runtime 的安全阀。

---

6. Review

Review Agent 很容易退化成：

“这个结果总体不错，逻辑清晰。”

这种 Review 基本没有意义。

真正有效的 Review 必须有明确评分维度，比如：

事实一致性
字段完整性
引用覆盖率
数字准确性
规则命中率
证据充分程度

Review Agent 不是来“发表意见”的，而是执行一套明确的质量标准。

---

7. Shared State 一致性

只要多个 Agent 并行，就必须测试：

重复认领
并发写
旧结果覆盖新结果
失败恢复
任务状态错乱
幂等

做到这里的时候，其实会发现：

Multi-Agent 已经开始从 AI 问题变成分布式系统问题。

---

8. 成本与延迟

每个任务至少应该统计：

Agent 数量
LLM 调用次数
Token
Tool 调用次数
Retry 次数
总耗时
P95

Multi-Agent 最大的陷阱之一就是：

效果提升 5%，成本提升 300%。

所以效果永远不能脱离成本讨论。

---

十一、真正的多 Agent 管理，其实是资源管理

继续往工程层面走，会出现一个更重要的问题：

多个 Agent 到底怎么管理资源？

很多时候我们会下意识认为：

每个 Agent 自己管自己的一套资源。

但我认为更加合理的思路应该是：

Agent 只是任务执行单元，资源统一收口到 Runtime / Scheduler。

Agent 本身不应该真正拥有资源。

它使用的是系统分配给它的：

模型额度
Token
并发槽位
上下文
数据库连接
RAG
Tool
API
缓存
权限
任务队列

所以真正应该做资源管理的不是 Agent。

而是 Runtime。

---

十二、任务资源：Task Queue + Scheduler

所有 Agent 不应该随便启动。

统一流程应该是：

用户任务
   ↓
Planner
   ↓
Task Queue
   ↓
Scheduler
├─ Agent A
├─ Agent B
└─ Agent C

Scheduler 根据：

priority
dependency
resource
load
timeout
budget

决定任务何时运行。

Task 中至少需要保存：

task_id
parent_task_id
priority
dependency
timeout
retry
status

这样才能真正处理：

任务抢占
重复执行
依赖等待
失败重试
任务恢复
死循环

换句话说，Multi-Agent 后面一定会自然演变成一个任务调度系统。

---

十三、模型资源：统一 Model Gateway

Multi-Agent 最贵的资源通常不是 CPU，也不是数据库。

而是模型。

所以我不会允许每个 Agent 随便直接调用模型。

所有调用统一经过：

Agent
  ↓
Model Gateway
  ↓
Qwen / DeepSeek / GPT / Small Model

Model Gateway 管：

全局并发
Agent 并发额度
Token Budget
RPM
TPM
模型路由
Timeout
Retry
熔断
降级

例如一个任务最多允许：

Total：30k Token

Planner：5k
Research Agent：15k
Reviewer：10k

如果 Research Agent 已经消耗完 15k，那么后续就必须：

压缩上下文
切换小模型
减少检索
降级策略
或停止任务

而不是让 Agent 继续无限调用。

---

十四、上下文也是一种资源

上下文管理其实也是资源调度的一部分。

如果 Agent A、B、C 各自维护一套完整上下文：

Agent A Context
Agent B Context
Agent C Context

然后彼此复制，成本会非常高。

所以更合理的是：

Shared Workspace

Workspace 保存：

Task
Fact
Evidence
Artifact
Decision
Risk
Error

Agent 只按需读取。

也就是说：

Context 不应该属于 Agent，而应该属于任务。

Agent 只是任务上下文的一个消费者。

这个思路一旦建立起来，Multi-Agent 的上下文管理就会清晰很多。

---

十五、Tool 也必须经过 Gateway

企业场景下还有一个非常重要的原则：

Agent 有调用意图，不代表 Agent 有执行权限。

比如：

SQL
RAG
CRM
征信
OCR
外部 API

都不应该让 Agent 直接连接。

可以增加：

Agent
  ↓
Capability Gateway
  ↓
SQL / RAG / CRM / OCR / API

Gateway 负责：

连接池
QPS
Timeout
幂等
权限
限流
审计
熔断

例如：

风险 Agent → 征信 Tool √
风险 Agent → SQL Tool  √

报告 Agent → 征信 Tool ×

不是说报告 Agent 技术上不能调用。

而是业务上没有必要给它这个权限。

---

十六、Agent 之间最好不要自由互相调用

很多 Multi-Agent 架构喜欢画成：

A ↔ B ↔ C ↔ D ↔ E

看起来非常智能。

但是工程管理成本会迅速增长。

因为很快你就会不知道：

谁调用了谁
为什么调用
谁产生的 Token
哪里产生了循环
谁修改了状态

更容易控制的是：

           Planner
        /     |      \
       A      B       C
        \     |      /
         Shared State

或者做成明确层级：

L4 Planner
     ↓
L3 Domain Agent
     ↓
L2 Workflow
     ↓
L1 Tool

并通过白名单限制调用关系。

比如：

Planner → 风险 Agent   √
Planner → 报告 Agent   √

风险 Agent → SQL Tool  √
风险 Agent → 征信 Tool √

报告 Agent → SQL Tool  ×
报告 Agent → 征信 Tool ×

调用图越明确，系统越容易治理。

---

十七、最终会形成一个 Agent Runtime

把前面的设计合起来，整个架构最后大概会变成：

                    Planner
                       │
                       ▼
                Task Scheduler
             ┌─────────┼─────────┐
             ▼         ▼         ▼
          Agent A   Agent B   Agent C
             │         │         │
     ┌───────┴─────────┴─────────┴───────┐
     │            Agent Runtime           │
     │                                    │
     │   Task Budget / Token Budget       │
     │   Concurrency / Timeout / Retry    │
     │   Context / State / Permission     │
     └───────┬────────────┬───────────────┘
             │            │
             ▼            ▼
       Model Gateway   Tool Gateway
             │            │
          LLM Pool    DB/RAG/API/OCR

到了这里，其实 Agent 已经不再是整个系统的核心。

真正的核心变成了：

Agent Runtime。

---

十八、Multi-Agent Runtime 很像一个小型操作系统

我觉得这是一个很好理解 Multi-Agent 的类比。

操作系统里：

Process
↓
申请 CPU / 内存 / IO
↓
OS Scheduler
↓
决定资源如何分配

Agent 系统也应该类似：

Agent
↓
申请 Token / Model / Tool / Context
↓
Agent Runtime
↓
决定是否允许执行

进程不能说：

我要 100GB 内存。

操作系统就直接给它 100GB。

同样，Agent 也不应该说：

我要调 5 次模型、访问数据库、再启动 3 个 Agent。

系统就全部执行。

真正成熟的 Multi-Agent Runtime 最终应该包含：

Scheduler
Budget Manager
Context Manager
Model Gateway
Tool Gateway
Policy Engine
State Store
Tracing

分别负责：

Scheduler        → 管任务
Budget Manager   → 管成本
Context Manager  → 管上下文
Model Gateway    → 管模型
Tool Gateway     → 管工具
Policy Engine    → 管权限
State Store      → 管状态
Tracing          → 管全过程

从这个角度看，所谓 Multi-Agent Framework，做到最后，其实已经越来越像一个：

Agent 操作系统。

---

十九、Multi-Agent 第一阶段最值得做的只有三件事

如果真的要从零搭一个企业级 Multi-Agent 系统，我反而不会一开始研究那些复杂的 Agent 协商协议、自主谈判、动态角色生成。

第一阶段我认为最值得做好的只有三件事情：

统一调度。

所有任务通过 Scheduler。

统一预算。

所有 Agent 消耗经过 Runtime。

统一状态。

所有 Agent 围绕 Shared State 协作。

这三件事情稳了之后，再往上增加：

动态规划
复杂协作
Agent Reflection
Agent Debate
动态 Agent
长期 Memory

才有意义。

否则 Agent 数量一多，很快就会变成：

谁都能调谁，谁都在吃 Token，出了问题也不知道是谁造成的。

---

二十、最终一定要和 Single Agent 做对比

还有一个非常容易忽略的问题：

Multi-Agent 不能只和自己比。

上线前一定应该准备 Single-Agent Baseline。

然后对比：

任务完成率
准确率 / 业务指标
错误发现率
平均耗时
P95
Token 成本
模型调用次数
人工介入率
Retry Rate
稳定性

如果 Single Agent：

准确率：87%
耗时：8 秒
成本：1

Multi-Agent：

准确率：89%
耗时：25 秒
成本：3

那 Multi-Agent 是否值得，就必须重新考虑。

Multi-Agent 应该解决 Single Agent 真正解决不了的问题。

比如：

复杂任务完成率
专业准确性
任务可解释性
容错能力
并行处理能力
复杂业务编排

如果这些地方没有明显提升，那就没有必要为了 Multi-Agent 而 Multi-Agent。

---

最后

我现在越来越觉得，Multi-Agent 真正值得研究的并不是：

怎样让几个 Agent 像人一样开会。

而是：

怎样把多个不完全可靠的智能执行单元，组织成一个可靠的工程系统。

这两种思路差别非常大。

前者关注的是 Agent 有多聪明。

后者关注的是：

责任
任务
状态
资源
权限
成本
错误
验证

而在真正的企业系统里，后面这些东西往往比 Agent 本身更加重要。

所以如果让我用一句话总结场景型 Multi-Agent，我会这么说：

Multi-Agent 的核心不是“做几个 Agent”，而是把复杂业务拆成明确的责任主体，再通过任务契约、共享状态、验证门和运行边界，把这些不完全可靠的智能单元组织成一个可控系统。

而如果只选三个最值得花时间验证的问题，我认为是：

任务拆解是否正确，上下文是否可靠，错误是否能够被及时阻断。

如果再往工程层面进一步浓缩，那就是：

统一调度、统一预算、统一状态。

这三个东西稳了，Multi-Agent 才真正具备落地价值。