多 Agent 不是万能的！搞懂这 5 个原则，少走 1 年弯路！

这两个月，我看到了一个现象，只要任务一复杂，大家做AI系统设计，脑子里第一个冒出来的就是多Agent。

一个负责规划，一个负责检索，一个负责执行，一个负责审查，整套方案立刻显得完整、先进、专业。

市面上，很多团队在讨论多 Agent 时，聚焦的是"结构上是不是更像一个组织 "；好像并不重视这几件事：状态怎么保持一致、上下文怎么避免失真、中间结果怎么交接、异常怎么定位、责任怎么划分、复杂度到底有没有换来真实收益。

我先说一下，多 Agent 系统，我不是特别的专业，所以这篇文章，基于我对单 Agent 的经验，和市面上的一些多 Agent 产品。从工程稳定的角度，把几个核心问题讲清楚：什么是多Agent、为什么它在今天的大多数业务里还不够稳、什么项目适合做Agent、什么项目别急着上、如果一定要做，路径应该怎么走。

为什么很多人一看到复杂任务，就想上多Agent？

说白了，大家都太需要一个"银弹"了。

现实里，复杂问题本来就是靠分工推进的：产品做规划，研发做实现，测试做验证，运营做落地。大家对这套组织结构太熟悉了，所以当AI能开始做事之后，很自然就会联想：人类靠分工搞定复杂任务，AI系统应该也一样吧？

这个联想很正常，但也特别危险。因为技术系统和人类组织，有个根本区别：人类分工，首先是解决"能力分散 "的问题；技术系统拆分，更多是为了"工程控制"。看着像一回事，落到实际设计上，差得太远了。

什么是多Agent？

Agent是什么？

从工程视角，Agent更像一个带目标、带状态、带工具、带反馈闭环的执行单元。它至少要具备这几件事：接收任务目标、基于上下文决定下一步动作、调用工具/系统/接口/知识源、根据工具返回结果继续推进、在任务未结束前维持状态、在必要时调整路径。

说得再直接一点：Agent 是一个以模型为决策核心、以工具为执行手段、以状态为粘合层的任务执行系统。

什么是多Agent？

有了上面的前提，多Agent的定义就很清晰了：在同一个目标下，存在多个具备相对独立决策能力的执行单元，它们通过串行、并行、分层或者自由裁决的方式协同完成任务。

常见的形态大致有以下几类，各自的优劣和适用场景也很明确：

路径	设计思路	优势	劣势	适用场景
单Agent	一个执行体负责理解、规划、调用工具、输出	上下文连续，责任集中，链路易追踪	长链路任务上下文负担会变重	中短链路、需要统一判断的任务
串行多Agent	前一个Agent的结果交给后一个Agent	步骤边界清楚	交接损耗明显，错误容易级联	规则清晰的信息处理链
并行多Agent	多个Agent同时处理不同子任务，再汇总	吞吐高，适合并发	合并复杂，冲突处理难	多路检索、多候选方案生成
分层多Agent	上层负责调度，下层负责执行	适合治理和权限分层	调度层容易失败	平台型系统、复杂任务编排
自由多Agent	Agent间自由判断下一个节点	适合高不确定性输出	评价标准难设计，成本高	创意脑暴

这里要特别提醒一句：很多系统虽然名字上叫多Agent，但本质上只是"同一个底层模型、换了几个Prompt、换了几个角色名、换了不同输出模板"。这种设计不一定有真正的系统意义，很多时候更像"一个执行器的多视角"。

真正有价值的差异，应该体现在这些边界上：工具是否不同、权限是否不同、输入上下文是否不同、评价标准是否不同、责任边界是否不同、失败模式是否不同 。如果这些都没变，只是角色名字变了，那么系统复杂度很可能已经涨上去了，能力结构却没有真正拉开。

为什么多Agent现在普遍不太行？

我说"不太行"，不是说它没用，而是在多数真实业务系统里，它还没成熟到可以优先选。问题不是某一个点出了问题，而是一堆系统问题堆在一起，很难理顺。

1. 任务一旦拆开，决策连续性也跟着断掉了

很多人拆分任务的时候，总觉得任务就是一段段可以独立传递的文本，但实际根本不是这样。一个真实的业务任务推进中，会产生很多局部判断：哪个约束更重要、哪条路已经试过走不通、当前信息够不够做下一步。

这些东西，很少会完整写进任务说明里，大多散落在历史状态、工具调用记录、执行路径和中间决策里。单Agent虽然有局限，但至少有个好处：这些内容都在同一个执行体的上下文里，整体是连贯的。

多Agent一拆分，麻烦就来了。后一个Agent看到的，不是最原始的任务信息，而是前一个Agent处理过的"二手信息"------可能是摘要、标签、结论，也可能是被截断的任务目标。问题不在于信息少了，而在于那些关键的语境、隐性的判断，传个几次就变味了

于是系统开始出现一种典型状态：每个局部步骤都看起来合理，每个Agent都有自己的判断依据，但整个链路却越来越难保持一致。这就是很多多Agent系统最早暴露出来的问题：上下文精度容易丢失。

2. 多Agent最大的成本，很多时候不在模型，而在交接

很多团队评估多Agent，先看这些指标：模型调用次数、平均延迟、Token成本、并发吞吐。

更大的成本，通常在交接里：任务拆分、中间结果压缩、状态同步、摘要生成、结果合并、冲突裁决、失败重试、链路排障。

举个企业里常见的例子：一个节点负责读合同条款，一个节点负责对照公司制度，第三个节点生成审批意见。架构图看着很漂亮，但一放进真实流程，问题就全出来了：条款节点压缩摘要时，会不会删掉关键信息？制度节点用的是最新规则还是旧版本？审批节点拿到的，是完整的风险情况，还是几个静态的字段？

这些问题，在架构图上根本看不到，只有当任务链拉长，才会一点点拖垮系统的稳定性。所以说，多Agent真正重要的，可能不只是模型推理能力，而是协同的接口设计。

3. 复杂度涨得飞快，收益却没跟上

从单Agent改成多Agent，不只是多几个节点那么简单。很快你就会发现，系统多了一整套新问题：子任务怎么定义、路由逻辑怎么写、谁来管上下文、每个Agent能看到多少历史信息、中间状态存在哪、冲突谁来判、线上出问题怎么定位、到底是生成环节错了还是调度环节错了、怎么建立统一的监控。

这已经不是"把Prompt写得更 好"能解决的问题了，这是一个新的运行时系统问题。

多Agent很容易进入这种状态：系统越来越像一个复杂协同平台，团队主要精力却花在维持协同本身。

4. 很多团队真正缺的，不是更多Agent，而是更扎实的基础层

这条我特别想强调，单Agent效果不稳定，第一反应就是：要不要再加几个Agent。我通常会反过来问：任务目标是否被精确定义、输入边界是否足够收敛、工具权限是否明确、中间状态是否持久化、执行结果是否可验证、失败时是否能回滚、长链路历史是否被正确压缩、人工接管条件是否清楚。

这些问题没解决，多Agent不仅不能让系统变稳，反而会把原本就存在的问题，分摊到更多节点上。一个模糊的任务，交给一个Agent，结果可能不稳定；拆成五段交给五个Agent，只会得到五段更难追责的不稳定结果。

所以在我眼里，今天很多团队最缺的不是"角色设计"，而是这几层东西：任务建模、状态管理、验证闭环、边界控制。这些东西没做好，多Agent往往会成为复杂度放大器。

Claude Code：真正值得借鉴的，不是多Agent本身

前段时间 Claude code 源码泄漏了，是一个很好的学习来源，Claude code 不是停留在"聊天式演示"的 AI，而是直接进入代码、文件系统、工具链和执行环境的 agentic coding system。Anthropic对外介绍里明确把它定义成一种能在终端里执行真实开发工作的产品，而且它已经支持subagents、agent teams、并行任务。

但更值得看的，不是"它支持多Agent"，而是"它怎么把系统做稳"。Anthropic自己总结长链路Agent的工程实践时，反复强调几件事：让Agent把进度写进progress file、让Agent频繁做git commit便于回退、用初始化脚本保证环境一致、用端到端测试或浏览器自动化做验证、让工具链承担更多确定性工作，而不是让模型去猜系统状态。

这说明什么？说明真正难的，从来不是"有没有多个Agent"，而是：任务执行过程中，状态能不能保存？上下文乱了，系统能不能发现？动作做错了，能不能退回到安全位置？

换句话说，Claude Code这个例子真正说明的，不是"角色越多越强"，而是另一件更底层的事：Agent一旦进入生产，决定上限的是模型，决定下限的是执行系统。

这才是Claude Code最值得借鉴的地方：不是表面的"多个agent协作"，而是背后的执行系统设计。

AI 形态的对比

如果站在负责系统建设的位置上，最值得问的问题是：这个任务的复杂性到底来自哪里、这些复杂性能不能由单Agent + 更好的状态层吸收、多Agent带来的收益，能不能覆盖交接和治理成本、这套系统能不能被团队长期维护、它是否具备足够的可观测性和可回滚能力。

我把常见路线放在一起看，通常是下面这个顺序更稳：

路径	成本	实现复杂度	落地可行性	工程判断
规则系统	低	低	高	规则明确时优先采用
Workflow + LLM	中	中	高	多数企业场景最先适合落在这里
单Agent	中高	中高	中高	适合长链路、持续决策型任务
多Agent	高	高	中	只有在拆分收益非常明确时才值得进入

Agent现在适合什么项目？哪些项目需要拆多Agent？

适合Agent的业务

如果今天非要问"Agent适合用在哪"，我会把范围收得很窄，主要是三类项目：

适合长链路、半结构化、需要工具调用的任务。这类任务通常有几个特征：目标明确、中间步骤不固定、需要根据反馈持续调整、需要调用外部系统或工具、结果能够被验证。例如：工单自动处理、内部运营流程代办、CRM / ERP 跨系统任务执行、发布前自动检查与处理、分析结果生成后的后续动作执行。这类任务的核心，不是"生成一段话"，而是"把流程真正推进下去"。
适合验证闭环清楚的项目 。今天Agent最容易创造价值的地方，很多时候不是"特别聪明"，而是"做完以后能立刻检查"。例如：代码修改之后能跑测试、SQL生成之后能对结果集、工单路由之后能看是否被正确接收、合同信息抽取之后能看字段完整性、运营活动配置之后能跑规则校验。为什么这类项目更适合？因为输出一旦产生，就有外部机制判断它对不对，有这个闭环，系统才有稳定迭代的基础；没有闭环，系统就很容易停留在"看起来能做事"。
适合信息密集、但可以隔离处理的知识型项目。还有一类适合Agent的场景，重点不在"执行动作"，而在"管理信息"。例如：招投标文档分析、企业内部制度问答、合同条款归纳与比对、多来源研究资料整理、大型项目资料证据汇编。这类场景适合Agent，前提是信息能被切成相对稳定的片段，最后再进入统一判断和校验链路。

不适合 Agent 的业务

开放度太高、评价标准模糊的任务。比如模糊的战略规划、高不确定性的业务创新方向、复杂的人事和组织判断、没有统一正确答案的长期决策。这些任务可以让Agent做辅助分析，但别让它直接承担主要执行工作，风险太高。
高耦合、高风险、隐含约束多的核心工程任务。比如复杂遗留系统的整体改造、核心财务链路的自动变更、复杂权限系统的自主调整、多业务域强耦合的核心流程改写。这类任务的难点，不只是模型能不能理解，更在于上下文和历史约束太重。状态管理、审计链、权限边界没成熟，Agent很容易做出"局部合理、全局危险"的动作。
责任要求极高、不能脱离人工审计的场景。比如高风险法务签署、核心财务记账、医疗关键判断、大额交易执行。这些领域可以用Agent做辅助，但直接把自主执行权交出去，风险会大到不可控。

Agent 是否需要拆成多 Agent ?

我一般只在下面三种情况下，才会考虑多 Agent：

上下文已经开始污染

信息量过大
不同子任务之间互相干扰
单 Agent 上下文开始混乱

👉 这时候拆分，是为了"信息隔离"

子任务可以并行

多路检索
多方案生成
多模块检查

👉 这时候多 Agent 的本质是"并发执行"，不是"组织协作"

存在明确的职责边界

一个只负责检索
一个只负责执行
一个只负责验证

👉 工具、权限、评价标准明显不同

案例拆解：企业采购审批协同系统的Agent选择

光讲原则还是不够，我举一个更完整、也更贴近企业内部系统的案例，看看什么时候适合用Agent，什么时候别急着上多Agent。

场景背景

角色：业务申请人（提交采购需求）、采购系统（接收申请单）、Agent系统（理解申请、校验规则、推动审批）、人工采购/财务/法务（处理异常和升级审批）。

工具：预算系统、供应商库、合同模板库、审批流引擎、风险规则引擎。

核心目标：自动处理标准化采购申请，减少人工来回沟通，提高审批效率，同时控制合规风险。

输入：申请单内容、采购品类、预算信息、供应商信息、合同模板、历史采购记录、部门权限、风控规则。

两种方案对比

方案A：单Agent + 工具链

在一个上下文内执行下面的一系列操作

读取采购申请；
查询预算、供应商、历史记录；
判断采购类型；
匹配审批规则和合同模板；
生成审批建议或自动流转动作；
调用审批流或补充资料接口；
记录日志；

伪代码大致像这样：

python 复制代码

# 1. 加载当前任务的状态（上下文入口）
# 包括：申请单信息、历史操作、当前阶段等
state = load_request(request_id)

# 2. 构建"事实层"（Facts Layer）
# 这里是所有后续决策的基础输入，尽量用"外部系统真实数据"而不是模型猜测
facts = {
  # 查询预算系统：当前部门是否有足够预算
  "budget": query_budget(state.department, state.amount),
  
  # 查询供应商系统：供应商是否合规、是否在白名单
  "vendor": query_vendor(state.vendor_id),
  
  # 查询历史采购记录：用于判断是否重复采购、异常模式等
  "history": query_purchase_history(state.department),
  
  # 查询制度规则：当前采购类型对应的审批/合规策略
  "policy": retrieve_procurement_policy(state.category)
}

# 3. 决策阶段（核心：Agent 推理）
# Agent 基于目标 + 事实 + 约束，决定下一步动作
decision = agent.decide(
  # 当前任务的最终目标
  objective="process_procurement_request",
  
  # 输入上下文（事实层）
  context=facts,
  
  # 强约束（必须遵守的规则）
  constraints=[
    "follow_policy",        # 必须符合采购制度
    "respect_risk_rules",   # 必须通过风控规则
    "preserve_auditability" # 必须可审计（不能做不可追溯操作）
  ]
)

# 4. 执行阶段（Action）
# 把 Agent 决策转成真实系统动作，比如：
# - 提交审批
# - 补充资料
# - 拒绝申请
result = execute(decision.action)

# 5. 校验阶段（Verification）
# 验证执行是否成功，以及是否符合预期
# 例如：
# - 审批是否成功触发
# - 数据是否写入成功
# - 是否违反规则
verify(result)

# 6. 持久化（State Persistence）
# 把这一步的状态记录下来，用于：
# - 后续继续执行
# - 出错回滚
# - 审计追踪
persist(state, decision, result)

方案B：多Agent

Classification Agent：识别采购类型；
Budget Agent：判断预算可用性；
Vendor Agent：校验供应商资质；
Policy Agent：解释制度要求；
Decision Agent：给出最终流转建议；
Audit Agent：检查风险和合规。

这套设计画在图上，那是相当完整，但一放进生产环境，问题很快就暴露出来：分类Agent如果把采购类型归错了，后面整条链都会跑偏；预算Agent的结论里，有没有包含临时冻结的额度？制度Agent用的是最新政策还是旧版本？决策Agent拿到的是完整事实，还是被压缩后的几个结论？审计Agent看到的是全链路过程，还是最终结果的快照？

这时候系统很容易进入一种常见状态：各个节点都在正常工作、日志量很多、表面上每一步都可解释，但一旦结果不符合预期，定位根因却很慢。

输出与校验要求

成熟系统输出的，不应该只是给申请人一句回复，至少要包括：当前审批动作、处理依据、触发的规则、风险等级、是否需要补材料、是否需要转人工、全链路操作日志。

校验指标至少要盯这些：自动处理率、人工接管率、错误流转率、平均审批时长、规则命中准确率、合规拦截准确率。

如果今天必须做多Agent，建议遵循这5个原则

按系统边界拆，不按角色名字拆。不要先想Planner、Researcher、Reviewer、Supervisor，更值得先看：哪部分需要不同权限、哪部分需要不同工具、哪部分需要不同输入视角、哪部分适合并行、哪部分需要独立验证。系统边界先成立，角色设计才有实际意义。
高耦合决策尽量放在一个连续执行体里。下面这些事情，我通常不建议拆得太早：全局策略判断、高风险动作选择、风格一致性控制、强依赖历史状态的决策、例外路径处理。这些内容拆散之后，系统里最容易长出看不见的冲突。
中间态尽量结构化，不要全靠自然语言转述。Agent之间如果只是用长文本互相传话，上下文乱几乎是迟早的事。关键中间态更适合结构化保存，例如：

python 复制代码

TaskState {
  task_id
  objective
  constraints[]
  verified_facts[]
  unresolved_questions[]
  candidate_actions[]
  selected_action
  execution_log[]
  risk_level
  rollback_point
}

有了这种结构，系统至少知道：哪些事实已经确认、哪些问题还没解决、当前动作依据是什么、风险点停留在哪一层。

生成与验证分离。一个节点负责生成动作，另一个节点负责验证结果，这种设计通常更稳。流程大致可以像这样：生成、执行、验证、裁决。关键是职责隔离，不是角色越多越好。
系统必须可观测、可追踪、可回滚。这三件事不成立，多Agent放到生产环境里就会非常危险。你至少要能还原：某个决定是谁做的、它基于什么上下文、调用了哪些工具、为什么走到当前路径、出错后能不能退回到安全状态。这些能力如果缺失，系统越复杂，排查成本越高。

总结：系统建设，要克制复杂度

真正适合Agent的项目，其实有很明确的特征：任务链路长、需要持续决策、需要调用工具、有清晰的验证闭环、状态可以管理、风险可以约束。

而在今天的大多数企业场景里，更现实的建设顺序通常还是：把Workflow + LLM打牢、把单Agent做深、只在确实有收益的地方引入多Agent。

最后我留一个问题给大家：当我们急于拆分角色、搭建多 Agent 体系时，不妨停下来想一想：当前的业务痛点，真的需要用更高的工程复杂度来换取吗？

欢迎大家关注我的公众号：深入浅出AI