1. 从单兵作战到团队协同AI Agent 架构到底在演进什么第一次接触 ReAct 范式是在做一个内部知识问答工具的时候。当时的需求很朴素用户问一个问题模型能自己判断要不要查资料、查完再回答。我按照 ReAct 的思路搭了一版跑通的那一刻确实挺兴奋——模型会输出“思考、行动、观察”这样的循环看起来真的在“推理执行”。但真正上线之后问题就来了一个稍微复杂的任务比如“帮我对比三份文档里的关键指标并生成结论”单 Agent 就开始顾此失彼要么忘了中间结果要么在工具调用上反复横跳最后给出的答案东拼西凑。这就是我想聊这个话题的起点。从 ReAct 到多 Agent 协作本质上不是“模型变聪明了”而是工程上对“复杂任务如何拆解、如何分工、如何收敛”的一次系统性回答。ReAct 解决的是“单个 Agent 怎么边想边做”多 Agent 协作解决的是“一群 Agent 怎么像团队一样把一件大事干完”。前者是个人能力问题后者是组织协作问题。这篇文章适合三类人看一是已经用过大模型 API、想进一步做 Agent 应用的开发者二是正在被单 Agent 的“健忘、跑偏、死循环”折磨的工程同学三是对多 Agent 架构好奇、但还没找到落地切入口的技术负责人。我会把 ReAct 的核心机制、它的天花板在哪、多 Agent 的几种主流协作模式、以及我自己在工程化过程中踩过的坑尽量讲透。不堆概念重点讲“为什么这么设计”和“实际怎么落地”。需要先说明一点Agent 这个领域变化极快很多细节没有唯一标准答案。我下面提到的架构选型、参数配置、协作模式都是基于常见工程实践和我个人项目经验的合理总结不是某种“官方标准”。你完全可以按自己的场景调整。2. ReAct 范式拆解它为什么好用又为什么不够用2.1 ReAct 的核心循环思考、行动、观察ReAct 这个名字来自 Reasoning Acting 的组合核心思想是让模型在一个循环里交替进行“推理”和“行动”。用最直白的话说就是让模型不要一上来就给答案而是先想一步、做个动作、看看结果、再想下一步。它的典型循环是这样的Thought思考模型分析当前状态决定下一步要做什么。Action行动选择一个工具并给出调用参数比如搜索、计算、查数据库。Observation观察拿到工具返回的结果。回到第 1 步直到模型认为可以给出最终答案。这个循环看起来简单但它解决了一个很关键的问题模型的知识是静态的而任务是动态的。通过引入工具调用模型可以在推理过程中主动获取外部信息而不是硬编在参数里。这就像一个人做菜不是背下所有菜谱而是边做边尝、边查资料。我用一个实际例子说明。假设任务是“计算某产品三个季度的环比增长率并判断趋势”。ReAct 的执行过程大致是Thought我需要先拿到三个季度的数据。Action调用数据查询工具参数为产品 ID 和时间范围。Observation返回 Q1120、Q2150、Q3135。Thought现在计算环比增长率。Action调用计算工具计算 (150-120)/120 和 (135-150)/150。ObservationQ2 环比 25%Q3 环比 -10%。Thought数据齐了可以给出结论。Final AnswerQ2 增长明显Q3 出现回落整体趋势先升后降。这个流程清晰、可解释而且每一步都有据可查。这也是 ReAct 最大的优点过程透明便于调试。2.2 单 Agent 的天花板在哪里ReAct 跑通之后我一度觉得“一个 Agent 打天下”就够了。但项目越做越复杂问题就暴露出来了。总结下来单 Agent 的天花板主要体现在四个方面。第一是上下文膨胀。ReAct 的每一步思考、行动、观察都要塞进上下文。任务一长上下文里全是历史记录模型注意力被稀释容易忘记最初的目标。我遇到过最夸张的一次一个任务跑了 20 多轮模型最后完全跑偏开始回答一个跟原问题无关的东西。第二是工具选择混乱。当工具数量超过十个单 Agent 在“该用哪个工具”上就开始犹豫。它可能反复调用同一个工具或者选了一个不合适的工具还硬着头皮往下走。这不是模型笨而是决策空间太大了。第三是错误累积。ReAct 是串行循环前面一步错了后面会沿着错误路径继续。比如第一步查错了数据源后面所有计算和结论都是错的但模型自己很难发现。第四是职责不清。一个 Agent 既要理解需求、又要规划步骤、还要调用工具、最后还要组织语言输出。角色太多每个角色都做不精。这就像让一个人同时当产品经理、程序员和测试最后哪样都做不好。提示如果你现在的单 Agent 任务经常超过 8 到 10 轮工具调用或者需要同时协调 5 个以上工具那基本可以考虑往多 Agent 方向演进了。2.3 从“一个人干活”到“一个团队干活”的思维转变多 Agent 协作的核心思路其实就是把单 Agent 身上的多重职责拆开交给不同的 Agent 分别负责。这跟公司里组建项目团队是一个道理有人负责拆需求有人负责执行有人负责审核有人负责汇总。这个思维转变的关键在于不要指望一个 Agent 既聪明又全面而是要让每个 Agent 在自己的职责范围内做到可靠。单 Agent 追求的是“全能”多 Agent 追求的是“分工明确 协作顺畅”。举个生活化的类比。单 Agent 像一个全能型自由职业者什么都能干但精力有限大项目容易崩。多 Agent 像一个工作室有策划、有执行、有质检每个人只干自己最擅长的事通过流程把成果串起来。工作室不一定每个人都是顶尖高手但整体产出往往比一个全能选手更稳定。3. 多 Agent 协作的主流架构模式与选型逻辑3.1 四种常见协作模式对比多 Agent 不是只有一种玩法。根据任务特点常见的协作模式大致可以分成四类。我用一个表格先做个总览再逐个展开。协作模式核心特征适用场景主要风险流水线式Agent 按固定顺序接力步骤明确的流程任务单点阻塞前一步错后全错主管调度式一个调度 Agent 分配任务任务可拆解、需动态分配调度 Agent 成为瓶颈辩论式多个 Agent 互相质疑需要高可靠性的判断成本高可能陷入僵局黑板式Agent 共享一块公共状态复杂、非线性协作状态管理复杂易冲突流水线式最简单Agent A 做完交给 Agent BB 做完交给 C。适合那种步骤天然固定的任务比如“抽取信息 → 校验格式 → 生成报告”。它的优点是流程清晰、容易调试缺点是缺乏灵活性中间任何一环卡住整条线就停了。主管调度式是我个人最常用的模式。有一个调度 Agent 负责理解总目标、拆解子任务、分发给执行 Agent最后汇总结果。它像一个项目经理不亲自干活但负责协调。这种模式灵活度高适合任务边界不太固定的场景。辩论式比较有意思让多个 Agent 对同一个问题给出不同答案然后互相挑刺最后收敛出一个更可靠的结论。适合对准确性要求极高的判断类任务。但它的成本是普通模式的几倍而且如果设计不好Agent 之间可能无限争论下去。黑板式借鉴了经典的多智能体系统思路所有 Agent 共享一块“黑板”公共状态区谁有需要就往上写谁需要信息就从上面读。它适合那种协作关系复杂、没有固定流程的任务但状态一致性很难保证工程实现也最重。3.2 选型时我实际考虑的三个维度面对一个具体项目怎么选协作模式我一般看三个维度。第一个维度是任务的可拆解程度。如果任务能清晰地拆成几个独立子任务主管调度式最合适。如果任务本身就是一条直线流程流水线式更省事。如果任务拆不开、需要多个视角反复验证才考虑辩论式。第二个维度是对可靠性的要求。普通的信息整理任务流水线或主管调度就够了。但如果是涉及关键决策的分析比如财务数据核对、合规审查那辩论式的交叉验证就很有价值多花点成本换可靠性是值得的。第三个维度是工程复杂度预算。这一点经常被忽略。辩论式和黑板式的实现复杂度远高于前两种调试难度也大。如果团队人手有限、上线时间紧我建议先从主管调度式入手它性价比最高。注意不要一上来就追求最复杂的架构。我见过不少项目明明一个主管调度式就能解决非要上黑板式结果状态同步的 bug 修了两周还没修完。3.3 一个主管调度式的架构草图既然主管调度式最常用我把它展开讲一下。一个典型的主管调度式多 Agent 系统通常包含这几类角色调度 AgentOrchestrator理解用户目标拆解任务决定调用哪些执行 Agent最后汇总。执行 AgentWorker每个负责一类具体能力比如检索、计算、写作、代码执行。审核 AgentCritic对执行结果做质量检查不合格就打回重做。记忆模块Memory存储中间结果和长期知识供所有 Agent 读写。它们之间的数据流大致是用户请求 → 调度 Agent 拆解 → 分发给执行 Agent → 执行结果写入记忆 → 审核 Agent 检查 → 调度 Agent 汇总输出。这个架构的关键设计点在于调度 Agent 不直接干活只做决策和协调。这样它的上下文不会被具体执行细节污染能更专注地做全局规划。执行 Agent 则各自保持精简只关心自己那一小块。4. 工程化落地的核心细节与实操要点4.1 Agent 之间的通信协议怎么定多 Agent 系统最容易出问题的地方就是 Agent 之间的通信。如果每个 Agent 都用自己的格式说话整个系统就会乱套。我的经验是一定要提前定义一套统一的消息结构。一个实用的消息结构通常包含这些字段{ sender: orchestrator, receiver: retrieval_agent, task_id: task_20240101_001, intent: retrieve_documents, payload: { query: 某产品的季度销售数据, top_k: 5 }, constraints: { timeout_seconds: 30, max_tokens: 2000 }, status: pending }这里有几个字段值得说明。task_id用于追踪一个任务的全链路方便排查问题。intent是意图标识接收方根据它决定怎么处理。constraints是约束条件防止某个 Agent 无限消耗资源。status用于状态流转比如 pending、running、done、failed。我踩过的一个坑是早期没定义task_id结果多个任务并发时日志混在一起根本分不清哪条是哪条。后来加上统一 ID排查效率提升了一大截。4.2 状态管理与上下文传递的取舍多 Agent 系统里状态管理是个绕不开的难题。核心矛盾在于Agent 之间需要共享信息但又不能把所有信息都塞给每个 Agent。我的做法是分层管理状态全局状态任务目标、总体进度、最终约束所有 Agent 都能读。局部状态每个 Agent 自己的中间结果默认不共享需要时才通过消息传递。持久状态跨任务需要保留的知识写入外部存储比如向量库或数据库。这样做的好处是每个 Agent 的上下文保持精简不会被无关信息干扰。代价是需要额外的状态同步逻辑。具体实现上我一般用一个中心化的状态管理器所有 Agent 通过它读写状态。状态管理器负责版本控制避免并发写入冲突。如果任务对实时性要求不高也可以用消息队列异步传递状态。提示状态管理最忌讳的是“隐式共享”。如果 Agent A 偷偷改了全局状态Agent B 却不知道这种 bug 极难排查。所有状态变更都要走显式接口并且记录日志。4.3 工具调用的隔离与权限控制单 Agent 时代工具调用相对随意。多 Agent 时代工具必须做隔离。原因很简单不是每个 Agent 都需要所有工具给多了反而增加误用风险。我的做法是按 Agent 角色分配工具集Agent 角色可用工具权限级别调度 Agent任务拆解、状态查询只读检索 Agent向量检索、关键词搜索只读计算 Agent计算器、代码执行受限写写作 Agent文本生成、格式化只读审核 Agent规则校验、对比分析只读这样设计之后每个 Agent 的工具选择空间变小决策更聚焦误用概率明显下降。同时权限控制也提升了系统安全性比如计算 Agent 的代码执行权限被限制在沙箱内不会影响其他模块。4.4 成本与延迟的平衡技巧多 Agent 系统最大的现实问题就是成本和延迟。多个 Agent 串行或并行调用token 消耗和响应时间都会成倍增加。我总结了几个实用的平衡技巧。第一能并行就并行。如果几个子任务之间没有依赖关系就让它们并行执行。比如检索和计算可以同时进行最后再汇总。这能显著降低总延迟。第二给每个 Agent 设置 token 上限。不要让某个 Agent 无限生成。我一般给执行 Agent 设 1000 到 2000 token 的输出上限调度 Agent 稍微宽松一点。第三缓存高频结果。很多任务里检索结果、计算结果是可以复用的。加一层缓存能省下大量重复调用。第四按需唤醒 Agent。不是每个任务都需要所有 Agent 参与。调度 Agent 应该根据任务复杂度动态决定唤醒哪些 Agent。简单任务可能只需要一个执行 Agent复杂任务才启动完整团队。实测下来做好这四点多 Agent 系统的成本能控制在单 Agent 的 1.5 到 2 倍左右而不是想象中的好几倍。延迟方面并行化做得好甚至可能比单 Agent 串行循环更快。5. 完整实操流程从零搭一个多 Agent 协作系统5.1 需求拆解与角色设计假设我们要做一个“行业研究报告生成器”。用户输入一个行业名称系统自动检索资料、分析数据、生成一份结构化报告。这个任务用单 Agent 做很容易在检索和写作之间顾此失彼。我们用多 Agent 来拆。第一步是角色设计。我把它拆成四个角色调度 Agent接收行业名称规划报告结构分配任务。检索 Agent负责搜集该行业的资料包括市场规模、主要玩家、趋势。分析 Agent对检索结果做归纳提取关键数据和结论。写作 Agent把分析结果组织成一份完整报告。审核环节我先不单独设 Agent而是让调度 Agent 在汇总时做一次自检降低初期复杂度。5.2 核心代码骨架与关键配置下面是一个简化的调度逻辑骨架用 Python 伪代码表示重点是展示协作流程不是完整可运行代码。class OrchestratorAgent: def __init__(self, workers, memory): self.workers workers # 执行 Agent 字典 self.memory memory # 共享记忆模块 def run(self, user_request): # 第一步拆解任务 plan self.decompose(user_request) self.memory.set(plan, plan) # 第二步分发检索任务 retrieval_result self.workers[retrieval].execute( queryplan[search_query], top_k5 ) self.memory.set(retrieval, retrieval_result) # 第三步分发分析任务 analysis_result self.workers[analysis].execute( contextretrieval_result, focusplan[analysis_focus] ) self.memory.set(analysis, analysis_result) # 第四步分发写作任务 report self.workers[writing].execute( contextanalysis_result, templateplan[report_template] ) # 第五步自检并返回 return self.self_check(report) def decompose(self, request): # 调用模型生成任务计划 prompt f请把以下需求拆解为检索、分析、写作三个子任务{request} return call_llm(prompt, output_formatjson)关键配置方面有几个参数需要特别注意每个 Agent 的模型选择调度 Agent 用能力强的模型执行 Agent 可以用更轻量的模型平衡成本和效果。超时设置每个 Agent 调用设置 30 到 60 秒超时避免单个环节卡死整个流程。重试策略检索和分析环节失败可以重试 2 次写作环节失败直接返回错误避免生成半成品。记忆容量共享记忆设置上限超过就做摘要压缩防止上下文无限膨胀。5.3 一次完整运行的现场记录我用“新能源汽车行业”做了一次实测。整个过程大致如下调度 Agent 先输出计划检索市场规模和增长率、检索主要厂商、检索政策趋势然后分析竞争格局最后生成报告。检索 Agent 并行跑了三路检索返回了 12 条相关资料。这里我用了并行三路检索同时发起总耗时约 8 秒。分析 Agent 拿到资料后提取出关键数据市场规模、同比增长率、前五大厂商份额。这一步耗时约 6 秒。写作 Agent 根据分析结果按“市场概况、竞争格局、趋势判断”三段式生成报告耗时约 10 秒。整个流程端到端约 25 秒token 消耗大约是单 Agent 方案的 1.8 倍。但报告质量明显更稳定数据引用完整结构清晰没有出现单 Agent 常见的“前面查了后面忘”的问题。5.4 效果评估与迭代方向评估多 Agent 系统的效果我一般看三个指标任务完成率、结果准确率、平均耗时。上面这个案例任务完成率 100%准确率抽样检查约 90%平均耗时 25 秒。迭代方向上我下一步打算加一个审核 Agent专门检查报告里的数据引用是否和检索结果一致。另外检索环节可以引入缓存相同行业的重复请求直接复用结果进一步降本。6. 常见问题与排查技巧实录6.1 Agent 之间互相等待怎么办这是多 Agent 系统最典型的死锁问题。A 等 B 的结果B 等 A 的结果谁也动不了。我遇到过两次都是因为任务依赖关系没理清。排查思路是先把所有 Agent 的依赖关系画成有向图检查有没有环。如果有环说明任务拆解本身有问题需要重新设计。如果没有环那就是超时设置不合理某个 Agent 等太久。解决方法有两个一是给每个等待设置超时超时就跳过或降级处理二是引入异步消息机制Agent 不等结果先把能做的做完结果到了再处理。6.2 调度 Agent 决策跑偏怎么修调度 Agent 跑偏的表现是拆解出的子任务和用户需求对不上或者分配了错误的执行 Agent。这个问题通常出在调度 Agent 的提示词上。我的修复经验是给调度 Agent 的提示词里明确列出可用的执行 Agent 及其能力边界并且要求它输出结构化的任务计划。结构化输出能大幅降低跑偏概率。另外可以在调度后加一道校验检查子任务是否覆盖了用户需求的所有关键点。6.3 结果不一致时的收敛策略多个 Agent 给出不一致的结果这在辩论式架构里很常见在主管调度式里也可能出现比如检索 Agent 返回了两条矛盾的数据。收敛策略我一般分三步先看数据源可信度再看时间新鲜度最后看多数一致性。如果两条数据来自不同可信度的源取高可信度的。如果可信度相当取更新的。如果还分不出来就让审核 Agent 介入或者直接标注“存在争议”返回给用户而不是强行编一个答案。6.4 常见问题速查表问题现象可能原因排查方向解决建议任务卡住不动Agent 互相等待检查依赖图是否有环加超时改异步结果偏离需求调度拆解错误检查调度提示词结构化输出校验成本异常高重复调用或上下文膨胀看调用日志和 token 统计加缓存设上限结果自相矛盾多源数据冲突检查数据源和时间按可信度和新鲜度收敛响应特别慢串行执行过多分析任务依赖关系能并行的改并行提示多 Agent 系统的调试日志是命根子。每个 Agent 的输入、输出、耗时、token 消耗都要记录最好带上统一的 task_id。没有日志排查基本靠猜。6.5 几个我踩过的坑第一个坑是过早优化。一开始就想着做完美的架构结果花了两周设计代码没写几行。后来改成先跑通最小闭环再逐步加 Agent效率高多了。第二个坑是忽视提示词的版本管理。多 Agent 系统里提示词很多改了一个忘了另一个导致行为不一致。后来我把所有提示词集中管理加了版本号问题少了很多。第三个坑是没有降级方案。某个 Agent 挂了整个流程就断了。后来我给每个关键环节都加了降级逻辑比如检索失败就用缓存分析失败就返回原始资料保证系统不会完全不可用。7. 多 Agent 协作的边界与我的实际体会聊了这么多架构和实操最后说点实在的。多 Agent 不是银弹它有明确的适用边界。任务足够复杂、单 Agent 确实搞不定的时候多 Agent 才值得上。如果任务本身简单硬套多 Agent只会增加成本和维护负担。我在实际项目里的体会是多 Agent 系统的价值不在于“用了多个 Agent”这个形式而在于它强迫你把任务拆解清楚、把职责定义明确、把接口约定好。这个拆解和约定的过程本身就是对业务理解的一次深化。很多时候把架构设计清楚了问题已经解决了一半。另外一个小技巧初期不要追求 Agent 数量多两三个角色跑通闭环比五六个角色互相打架强得多。等流程稳定了再按需增加角色。多 Agent 协作的工程化本质上是一个“先跑通、再优化、后扩展”的渐进过程急不得。
1. 从单兵作战到团队协同AI Agent 架构到底在演进什么第一次接触 ReAct 范式是在做一个内部知识问答工具的时候。当时的需求很朴素用户问一个问题模型能自己判断要不要查资料、查完再回答。我按照 ReAct 的思路搭了一版跑通的那一刻确实挺兴奋——模型会输出“思考、行动、观察”这样的循环看起来真的在“推理执行”。但真正上线之后问题就来了一个稍微复杂的任务比如“帮我对比三份文档里的关键指标并生成结论”单 Agent 就开始顾此失彼要么忘了中间结果要么在工具调用上反复横跳最后给出的答案东拼西凑。这就是我想聊这个话题的起点。从 ReAct 到多 Agent 协作本质上不是“模型变聪明了”而是工程上对“复杂任务如何拆解、如何分工、如何收敛”的一次系统性回答。ReAct 解决的是“单个 Agent 怎么边想边做”多 Agent 协作解决的是“一群 Agent 怎么像团队一样把一件大事干完”。前者是个人能力问题后者是组织协作问题。这篇文章适合三类人看一是已经用过大模型 API、想进一步做 Agent 应用的开发者二是正在被单 Agent 的“健忘、跑偏、死循环”折磨的工程同学三是对多 Agent 架构好奇、但还没找到落地切入口的技术负责人。我会把 ReAct 的核心机制、它的天花板在哪、多 Agent 的几种主流协作模式、以及我自己在工程化过程中踩过的坑尽量讲透。不堆概念重点讲“为什么这么设计”和“实际怎么落地”。需要先说明一点Agent 这个领域变化极快很多细节没有唯一标准答案。我下面提到的架构选型、参数配置、协作模式都是基于常见工程实践和我个人项目经验的合理总结不是某种“官方标准”。你完全可以按自己的场景调整。2. ReAct 范式拆解它为什么好用又为什么不够用2.1 ReAct 的核心循环思考、行动、观察ReAct 这个名字来自 Reasoning Acting 的组合核心思想是让模型在一个循环里交替进行“推理”和“行动”。用最直白的话说就是让模型不要一上来就给答案而是先想一步、做个动作、看看结果、再想下一步。它的典型循环是这样的Thought思考模型分析当前状态决定下一步要做什么。Action行动选择一个工具并给出调用参数比如搜索、计算、查数据库。Observation观察拿到工具返回的结果。回到第 1 步直到模型认为可以给出最终答案。这个循环看起来简单但它解决了一个很关键的问题模型的知识是静态的而任务是动态的。通过引入工具调用模型可以在推理过程中主动获取外部信息而不是硬编在参数里。这就像一个人做菜不是背下所有菜谱而是边做边尝、边查资料。我用一个实际例子说明。假设任务是“计算某产品三个季度的环比增长率并判断趋势”。ReAct 的执行过程大致是Thought我需要先拿到三个季度的数据。Action调用数据查询工具参数为产品 ID 和时间范围。Observation返回 Q1120、Q2150、Q3135。Thought现在计算环比增长率。Action调用计算工具计算 (150-120)/120 和 (135-150)/150。ObservationQ2 环比 25%Q3 环比 -10%。Thought数据齐了可以给出结论。Final AnswerQ2 增长明显Q3 出现回落整体趋势先升后降。这个流程清晰、可解释而且每一步都有据可查。这也是 ReAct 最大的优点过程透明便于调试。2.2 单 Agent 的天花板在哪里ReAct 跑通之后我一度觉得“一个 Agent 打天下”就够了。但项目越做越复杂问题就暴露出来了。总结下来单 Agent 的天花板主要体现在四个方面。第一是上下文膨胀。ReAct 的每一步思考、行动、观察都要塞进上下文。任务一长上下文里全是历史记录模型注意力被稀释容易忘记最初的目标。我遇到过最夸张的一次一个任务跑了 20 多轮模型最后完全跑偏开始回答一个跟原问题无关的东西。第二是工具选择混乱。当工具数量超过十个单 Agent 在“该用哪个工具”上就开始犹豫。它可能反复调用同一个工具或者选了一个不合适的工具还硬着头皮往下走。这不是模型笨而是决策空间太大了。第三是错误累积。ReAct 是串行循环前面一步错了后面会沿着错误路径继续。比如第一步查错了数据源后面所有计算和结论都是错的但模型自己很难发现。第四是职责不清。一个 Agent 既要理解需求、又要规划步骤、还要调用工具、最后还要组织语言输出。角色太多每个角色都做不精。这就像让一个人同时当产品经理、程序员和测试最后哪样都做不好。提示如果你现在的单 Agent 任务经常超过 8 到 10 轮工具调用或者需要同时协调 5 个以上工具那基本可以考虑往多 Agent 方向演进了。2.3 从“一个人干活”到“一个团队干活”的思维转变多 Agent 协作的核心思路其实就是把单 Agent 身上的多重职责拆开交给不同的 Agent 分别负责。这跟公司里组建项目团队是一个道理有人负责拆需求有人负责执行有人负责审核有人负责汇总。这个思维转变的关键在于不要指望一个 Agent 既聪明又全面而是要让每个 Agent 在自己的职责范围内做到可靠。单 Agent 追求的是“全能”多 Agent 追求的是“分工明确 协作顺畅”。举个生活化的类比。单 Agent 像一个全能型自由职业者什么都能干但精力有限大项目容易崩。多 Agent 像一个工作室有策划、有执行、有质检每个人只干自己最擅长的事通过流程把成果串起来。工作室不一定每个人都是顶尖高手但整体产出往往比一个全能选手更稳定。3. 多 Agent 协作的主流架构模式与选型逻辑3.1 四种常见协作模式对比多 Agent 不是只有一种玩法。根据任务特点常见的协作模式大致可以分成四类。我用一个表格先做个总览再逐个展开。协作模式核心特征适用场景主要风险流水线式Agent 按固定顺序接力步骤明确的流程任务单点阻塞前一步错后全错主管调度式一个调度 Agent 分配任务任务可拆解、需动态分配调度 Agent 成为瓶颈辩论式多个 Agent 互相质疑需要高可靠性的判断成本高可能陷入僵局黑板式Agent 共享一块公共状态复杂、非线性协作状态管理复杂易冲突流水线式最简单Agent A 做完交给 Agent BB 做完交给 C。适合那种步骤天然固定的任务比如“抽取信息 → 校验格式 → 生成报告”。它的优点是流程清晰、容易调试缺点是缺乏灵活性中间任何一环卡住整条线就停了。主管调度式是我个人最常用的模式。有一个调度 Agent 负责理解总目标、拆解子任务、分发给执行 Agent最后汇总结果。它像一个项目经理不亲自干活但负责协调。这种模式灵活度高适合任务边界不太固定的场景。辩论式比较有意思让多个 Agent 对同一个问题给出不同答案然后互相挑刺最后收敛出一个更可靠的结论。适合对准确性要求极高的判断类任务。但它的成本是普通模式的几倍而且如果设计不好Agent 之间可能无限争论下去。黑板式借鉴了经典的多智能体系统思路所有 Agent 共享一块“黑板”公共状态区谁有需要就往上写谁需要信息就从上面读。它适合那种协作关系复杂、没有固定流程的任务但状态一致性很难保证工程实现也最重。3.2 选型时我实际考虑的三个维度面对一个具体项目怎么选协作模式我一般看三个维度。第一个维度是任务的可拆解程度。如果任务能清晰地拆成几个独立子任务主管调度式最合适。如果任务本身就是一条直线流程流水线式更省事。如果任务拆不开、需要多个视角反复验证才考虑辩论式。第二个维度是对可靠性的要求。普通的信息整理任务流水线或主管调度就够了。但如果是涉及关键决策的分析比如财务数据核对、合规审查那辩论式的交叉验证就很有价值多花点成本换可靠性是值得的。第三个维度是工程复杂度预算。这一点经常被忽略。辩论式和黑板式的实现复杂度远高于前两种调试难度也大。如果团队人手有限、上线时间紧我建议先从主管调度式入手它性价比最高。注意不要一上来就追求最复杂的架构。我见过不少项目明明一个主管调度式就能解决非要上黑板式结果状态同步的 bug 修了两周还没修完。3.3 一个主管调度式的架构草图既然主管调度式最常用我把它展开讲一下。一个典型的主管调度式多 Agent 系统通常包含这几类角色调度 AgentOrchestrator理解用户目标拆解任务决定调用哪些执行 Agent最后汇总。执行 AgentWorker每个负责一类具体能力比如检索、计算、写作、代码执行。审核 AgentCritic对执行结果做质量检查不合格就打回重做。记忆模块Memory存储中间结果和长期知识供所有 Agent 读写。它们之间的数据流大致是用户请求 → 调度 Agent 拆解 → 分发给执行 Agent → 执行结果写入记忆 → 审核 Agent 检查 → 调度 Agent 汇总输出。这个架构的关键设计点在于调度 Agent 不直接干活只做决策和协调。这样它的上下文不会被具体执行细节污染能更专注地做全局规划。执行 Agent 则各自保持精简只关心自己那一小块。4. 工程化落地的核心细节与实操要点4.1 Agent 之间的通信协议怎么定多 Agent 系统最容易出问题的地方就是 Agent 之间的通信。如果每个 Agent 都用自己的格式说话整个系统就会乱套。我的经验是一定要提前定义一套统一的消息结构。一个实用的消息结构通常包含这些字段{ sender: orchestrator, receiver: retrieval_agent, task_id: task_20240101_001, intent: retrieve_documents, payload: { query: 某产品的季度销售数据, top_k: 5 }, constraints: { timeout_seconds: 30, max_tokens: 2000 }, status: pending }这里有几个字段值得说明。task_id用于追踪一个任务的全链路方便排查问题。intent是意图标识接收方根据它决定怎么处理。constraints是约束条件防止某个 Agent 无限消耗资源。status用于状态流转比如 pending、running、done、failed。我踩过的一个坑是早期没定义task_id结果多个任务并发时日志混在一起根本分不清哪条是哪条。后来加上统一 ID排查效率提升了一大截。4.2 状态管理与上下文传递的取舍多 Agent 系统里状态管理是个绕不开的难题。核心矛盾在于Agent 之间需要共享信息但又不能把所有信息都塞给每个 Agent。我的做法是分层管理状态全局状态任务目标、总体进度、最终约束所有 Agent 都能读。局部状态每个 Agent 自己的中间结果默认不共享需要时才通过消息传递。持久状态跨任务需要保留的知识写入外部存储比如向量库或数据库。这样做的好处是每个 Agent 的上下文保持精简不会被无关信息干扰。代价是需要额外的状态同步逻辑。具体实现上我一般用一个中心化的状态管理器所有 Agent 通过它读写状态。状态管理器负责版本控制避免并发写入冲突。如果任务对实时性要求不高也可以用消息队列异步传递状态。提示状态管理最忌讳的是“隐式共享”。如果 Agent A 偷偷改了全局状态Agent B 却不知道这种 bug 极难排查。所有状态变更都要走显式接口并且记录日志。4.3 工具调用的隔离与权限控制单 Agent 时代工具调用相对随意。多 Agent 时代工具必须做隔离。原因很简单不是每个 Agent 都需要所有工具给多了反而增加误用风险。我的做法是按 Agent 角色分配工具集Agent 角色可用工具权限级别调度 Agent任务拆解、状态查询只读检索 Agent向量检索、关键词搜索只读计算 Agent计算器、代码执行受限写写作 Agent文本生成、格式化只读审核 Agent规则校验、对比分析只读这样设计之后每个 Agent 的工具选择空间变小决策更聚焦误用概率明显下降。同时权限控制也提升了系统安全性比如计算 Agent 的代码执行权限被限制在沙箱内不会影响其他模块。4.4 成本与延迟的平衡技巧多 Agent 系统最大的现实问题就是成本和延迟。多个 Agent 串行或并行调用token 消耗和响应时间都会成倍增加。我总结了几个实用的平衡技巧。第一能并行就并行。如果几个子任务之间没有依赖关系就让它们并行执行。比如检索和计算可以同时进行最后再汇总。这能显著降低总延迟。第二给每个 Agent 设置 token 上限。不要让某个 Agent 无限生成。我一般给执行 Agent 设 1000 到 2000 token 的输出上限调度 Agent 稍微宽松一点。第三缓存高频结果。很多任务里检索结果、计算结果是可以复用的。加一层缓存能省下大量重复调用。第四按需唤醒 Agent。不是每个任务都需要所有 Agent 参与。调度 Agent 应该根据任务复杂度动态决定唤醒哪些 Agent。简单任务可能只需要一个执行 Agent复杂任务才启动完整团队。实测下来做好这四点多 Agent 系统的成本能控制在单 Agent 的 1.5 到 2 倍左右而不是想象中的好几倍。延迟方面并行化做得好甚至可能比单 Agent 串行循环更快。5. 完整实操流程从零搭一个多 Agent 协作系统5.1 需求拆解与角色设计假设我们要做一个“行业研究报告生成器”。用户输入一个行业名称系统自动检索资料、分析数据、生成一份结构化报告。这个任务用单 Agent 做很容易在检索和写作之间顾此失彼。我们用多 Agent 来拆。第一步是角色设计。我把它拆成四个角色调度 Agent接收行业名称规划报告结构分配任务。检索 Agent负责搜集该行业的资料包括市场规模、主要玩家、趋势。分析 Agent对检索结果做归纳提取关键数据和结论。写作 Agent把分析结果组织成一份完整报告。审核环节我先不单独设 Agent而是让调度 Agent 在汇总时做一次自检降低初期复杂度。5.2 核心代码骨架与关键配置下面是一个简化的调度逻辑骨架用 Python 伪代码表示重点是展示协作流程不是完整可运行代码。class OrchestratorAgent: def __init__(self, workers, memory): self.workers workers # 执行 Agent 字典 self.memory memory # 共享记忆模块 def run(self, user_request): # 第一步拆解任务 plan self.decompose(user_request) self.memory.set(plan, plan) # 第二步分发检索任务 retrieval_result self.workers[retrieval].execute( queryplan[search_query], top_k5 ) self.memory.set(retrieval, retrieval_result) # 第三步分发分析任务 analysis_result self.workers[analysis].execute( contextretrieval_result, focusplan[analysis_focus] ) self.memory.set(analysis, analysis_result) # 第四步分发写作任务 report self.workers[writing].execute( contextanalysis_result, templateplan[report_template] ) # 第五步自检并返回 return self.self_check(report) def decompose(self, request): # 调用模型生成任务计划 prompt f请把以下需求拆解为检索、分析、写作三个子任务{request} return call_llm(prompt, output_formatjson)关键配置方面有几个参数需要特别注意每个 Agent 的模型选择调度 Agent 用能力强的模型执行 Agent 可以用更轻量的模型平衡成本和效果。超时设置每个 Agent 调用设置 30 到 60 秒超时避免单个环节卡死整个流程。重试策略检索和分析环节失败可以重试 2 次写作环节失败直接返回错误避免生成半成品。记忆容量共享记忆设置上限超过就做摘要压缩防止上下文无限膨胀。5.3 一次完整运行的现场记录我用“新能源汽车行业”做了一次实测。整个过程大致如下调度 Agent 先输出计划检索市场规模和增长率、检索主要厂商、检索政策趋势然后分析竞争格局最后生成报告。检索 Agent 并行跑了三路检索返回了 12 条相关资料。这里我用了并行三路检索同时发起总耗时约 8 秒。分析 Agent 拿到资料后提取出关键数据市场规模、同比增长率、前五大厂商份额。这一步耗时约 6 秒。写作 Agent 根据分析结果按“市场概况、竞争格局、趋势判断”三段式生成报告耗时约 10 秒。整个流程端到端约 25 秒token 消耗大约是单 Agent 方案的 1.8 倍。但报告质量明显更稳定数据引用完整结构清晰没有出现单 Agent 常见的“前面查了后面忘”的问题。5.4 效果评估与迭代方向评估多 Agent 系统的效果我一般看三个指标任务完成率、结果准确率、平均耗时。上面这个案例任务完成率 100%准确率抽样检查约 90%平均耗时 25 秒。迭代方向上我下一步打算加一个审核 Agent专门检查报告里的数据引用是否和检索结果一致。另外检索环节可以引入缓存相同行业的重复请求直接复用结果进一步降本。6. 常见问题与排查技巧实录6.1 Agent 之间互相等待怎么办这是多 Agent 系统最典型的死锁问题。A 等 B 的结果B 等 A 的结果谁也动不了。我遇到过两次都是因为任务依赖关系没理清。排查思路是先把所有 Agent 的依赖关系画成有向图检查有没有环。如果有环说明任务拆解本身有问题需要重新设计。如果没有环那就是超时设置不合理某个 Agent 等太久。解决方法有两个一是给每个等待设置超时超时就跳过或降级处理二是引入异步消息机制Agent 不等结果先把能做的做完结果到了再处理。6.2 调度 Agent 决策跑偏怎么修调度 Agent 跑偏的表现是拆解出的子任务和用户需求对不上或者分配了错误的执行 Agent。这个问题通常出在调度 Agent 的提示词上。我的修复经验是给调度 Agent 的提示词里明确列出可用的执行 Agent 及其能力边界并且要求它输出结构化的任务计划。结构化输出能大幅降低跑偏概率。另外可以在调度后加一道校验检查子任务是否覆盖了用户需求的所有关键点。6.3 结果不一致时的收敛策略多个 Agent 给出不一致的结果这在辩论式架构里很常见在主管调度式里也可能出现比如检索 Agent 返回了两条矛盾的数据。收敛策略我一般分三步先看数据源可信度再看时间新鲜度最后看多数一致性。如果两条数据来自不同可信度的源取高可信度的。如果可信度相当取更新的。如果还分不出来就让审核 Agent 介入或者直接标注“存在争议”返回给用户而不是强行编一个答案。6.4 常见问题速查表问题现象可能原因排查方向解决建议任务卡住不动Agent 互相等待检查依赖图是否有环加超时改异步结果偏离需求调度拆解错误检查调度提示词结构化输出校验成本异常高重复调用或上下文膨胀看调用日志和 token 统计加缓存设上限结果自相矛盾多源数据冲突检查数据源和时间按可信度和新鲜度收敛响应特别慢串行执行过多分析任务依赖关系能并行的改并行提示多 Agent 系统的调试日志是命根子。每个 Agent 的输入、输出、耗时、token 消耗都要记录最好带上统一的 task_id。没有日志排查基本靠猜。6.5 几个我踩过的坑第一个坑是过早优化。一开始就想着做完美的架构结果花了两周设计代码没写几行。后来改成先跑通最小闭环再逐步加 Agent效率高多了。第二个坑是忽视提示词的版本管理。多 Agent 系统里提示词很多改了一个忘了另一个导致行为不一致。后来我把所有提示词集中管理加了版本号问题少了很多。第三个坑是没有降级方案。某个 Agent 挂了整个流程就断了。后来我给每个关键环节都加了降级逻辑比如检索失败就用缓存分析失败就返回原始资料保证系统不会完全不可用。7. 多 Agent 协作的边界与我的实际体会聊了这么多架构和实操最后说点实在的。多 Agent 不是银弹它有明确的适用边界。任务足够复杂、单 Agent 确实搞不定的时候多 Agent 才值得上。如果任务本身简单硬套多 Agent只会增加成本和维护负担。我在实际项目里的体会是多 Agent 系统的价值不在于“用了多个 Agent”这个形式而在于它强迫你把任务拆解清楚、把职责定义明确、把接口约定好。这个拆解和约定的过程本身就是对业务理解的一次深化。很多时候把架构设计清楚了问题已经解决了一半。另外一个小技巧初期不要追求 Agent 数量多两三个角色跑通闭环比五六个角色互相打架强得多。等流程稳定了再按需增加角色。多 Agent 协作的工程化本质上是一个“先跑通、再优化、后扩展”的渐进过程急不得。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
