1. 从手搓流程到指挥交响乐Agent 编排到底在解决什么如果你最近在折腾大模型应用大概率经历过这样一个阶段一开始只是调个 API 问一句答一句感觉挺新鲜接着想让它干点正事比如查资料、算数据、写文件于是开始写 if-else 判断——如果用户问的是天气就调天气接口如果问的是数学题就调计算器。代码写到三百行的时候你发现分支已经多到自己都记不清了加一个新功能要改五个地方改完还得祈祷别把老逻辑弄崩。这就是没有编排的世界所有决策逻辑硬编码在代码里模型只是个被动的文本生成器。Agent 编排要干的事说白了就是把什么时候调什么工具、拿到结果之后下一步干什么、多个步骤之间怎么衔接这些决策从你的 if-else 里抽出来交给一套可配置、可复用、可观测的机制来管理。打个比方以前你是自己拿着扳手拧每一个螺丝现在你是坐在控制台前看着一张流程图哪个节点该亮灯、哪条管线该通水系统自己会调度。但这里有个常见的误解需要先澄清编排不等于工作流。工作流是步骤 A 完了必须走步骤 B的刚性管道而 Agent 编排的核心特征是决策权部分下放给模型——模型可以根据当前上下文选择调用哪个工具、是否要再调一次、什么时候给出最终答案。这个区别决定了你在设计系统时的根本思路工作流追求的是确定性和可预测性编排追求的是灵活性和适应性。那什么时候该用编排什么时候老老实实写工作流就行我的经验判断标准很简单如果你的业务流程能用一张流程图完整画出来且不需要任何如果模型觉得……的判断那就别上编排工作流更稳更便宜。反过来如果存在根据中间结果动态决定下一步的场景——比如客服机器人需要先判断用户意图再决定查订单还是查物流或者研究助手需要根据第一轮搜索结果决定要不要再搜一轮——那编排就是刚需。这篇文章面向的是已经用过大模型 API、想从单次调用进阶到多步骤自主决策的开发者。我会从核心概念拆起然后给出一套可落地的编排方案最后把我在实际项目中踩过的坑和盘托出。不堆术语不画大饼只讲能跑起来的东西。2. 拆开编排的黑盒四个核心构件与它们的分工2.1 规划器Agent 的大脑皮层规划器负责的是最顶层的决策当前这个任务应该拆成几步先做什么后做什么这是编排系统里最接近智能的部分也是最容易出问题的部分。我见过不少团队一上来就想搞一个全能规划器让模型一次性把整个任务计划列出来然后按计划执行。想法很美好现实很骨感——模型在规划阶段对后续步骤的难度和依赖关系往往估计不准计划列到第三步就偏离实际了。更稳妥的做法是滚动式规划每次只规划下一步执行完看结果再规划再下一步。代价是多几次模型调用但成功率会高很多。规划器的输出通常是一个结构化的动作序列比如 JSON 格式的{action: search, params: {query: ...}}。这里的关键是约束输出格式不能让模型自由发挥写一段自然语言说我觉得应该先搜索一下那样解析起来会要命。用 function calling 或者 JSON mode 强制结构化输出是工程上的基本要求。2.2 执行器把决策变成动作执行器拿到规划器的指令后负责实际调用工具或 API。听起来简单但有几个细节决定了系统的健壮性。第一是超时和重试。外部工具调用失败是常态不是异常。搜索接口可能超时数据库可能连接不上第三方 API 可能限流。执行器必须内置重试逻辑而且要区分可重试错误网络超时和不可重试错误参数格式错误——前者退避重试后者直接把错误信息返回给规划器让它重新决策。第二是结果截断。工具返回的内容可能非常长比如一次搜索返回二十条结果每条几百字。如果原封不动塞回给模型上下文窗口很快就爆了。执行器需要做一层预处理提取关键字段、截断超长文本、必要时做摘要。我一般会把单次工具返回控制在 2000 token 以内超出部分要么截断要么让模型先摘要再返回。第三是副作用管理。有些工具调用是有副作用的——发邮件、写数据库、下单。这类操作必须做幂等设计防止重试导致重复执行。一个简单的做法是给每次调用生成唯一 ID执行前先查这个 ID 是否已经执行过。2.3 记忆模块让 Agent 记住刚才发生了什么没有记忆的 Agent 就像金鱼每一步都是全新的开始。记忆模块要解决的是跨步骤的上下文传递问题。短期记忆通常就是一个消息列表记录每一步的输入输出。但这里有个坑不是所有历史信息都值得保留。早期步骤的详细工具返回结果到了后期可能只需要一个摘要就够了。我通常会把记忆分成两层一层是完整日志用于调试和审计另一层是压缩上下文用于喂给模型。压缩策略可以是滑动窗口只保留最近 N 轮、摘要压缩让模型把早期内容总结成一段话、或者关键信息提取只保留实体和结论。长期记忆则是跨会话的比如用户偏好、历史交互记录。这块涉及向量数据库和检索展开讲能写一整篇这里先按住不表。对于大多数编排场景把短期记忆做好就已经能解决 80% 的问题了。2.4 终止条件什么时候算做完了这是最容易被忽视但最致命的一环。Agent 编排系统如果没有明确的终止条件轻则陷入死循环反复调用同一个工具重则无限循环烧光你的 API 额度。终止条件通常有三类任务完成模型输出最终答案、步数上限比如最多执行 10 步、错误累积连续 3 次工具调用失败就放弃。我强烈建议同时设置多个终止条件尤其是步数上限——这是你的最后一道防线。见过太多案例是模型陷入搜索-不满意-再搜索的循环一晚上跑掉几百块。另外终止时的收尾也很重要。不要直接抛一个达到最大步数的错误给用户而是让模型基于已有信息生成一个尽力而为的回答同时标注哪些部分可能不完整。用户体验会好很多。3. 三种主流编排模式ReAct、Plan-and-Execute 与多 Agent 协作3.1 ReAct边想边做适合探索型任务ReAct 的核心循环是Thought → Action → Observation模型先想一下当前该干什么Thought然后调用工具Action拿到结果Observation再想下一步。这个模式最大的好处是每一步都基于最新信息做决策不会出现计划赶不上变化的问题。适合的场景信息检索、故障排查、需要多轮试探的任务。比如帮我查一下这个报错是什么原因模型可能需要先搜错误码根据搜索结果决定是查文档还是搜社区讨论每一步都依赖上一步的结果。不适合的场景步骤明确、依赖关系固定的任务。用 ReAct 跑这种任务属于杀鸡用牛刀多花好几倍 token 不说还容易因为模型的自由发挥引入不确定性。实现 ReAct 的关键在于提示词设计。你需要明确告诉模型你可以使用哪些工具、每个工具的参数格式是什么、什么时候应该停止思考并给出答案。一个常见的坑是模型想太多——在 Thought 阶段写了一大段分析但就是不调用工具。解决办法是在提示词里加一句如果你已经收集到足够信息请直接输出最终答案并且给 Thought 阶段设一个长度限制。3.2 Plan-and-Execute先谋后动适合流程化任务这个模式分两个阶段规划阶段让模型一次性生成完整的步骤列表执行阶段按顺序逐步执行。相比 ReAct它的优势是全局视野——模型在规划时能看到整个任务的全貌避免走一步看一步导致的短视决策。适合的场景步骤相对固定、依赖关系明确的任务。比如帮我写一份竞品分析报告可以规划成搜索竞品 A 信息 → 搜索竞品 B 信息 → 对比分析 → 生成报告。每一步的输入输出都很清晰。但 Plan-and-Execute 有个硬伤计划一旦生成就固定了执行过程中发现计划有问题很难调整。我的改进方案是加一个重规划触发器——如果某一步执行失败或者返回结果与预期严重不符就中断当前计划让模型基于新信息重新规划剩余步骤。这样既保留了全局视野的优势又有了一定的灵活性。3.3 多 Agent 协作分工明确但协调成本高多 Agent 模式是把一个复杂任务拆给多个专职 Agent每个 Agent 有自己的角色、工具集和提示词。比如一个内容创作团队可以拆成研究员 Agent负责搜集资料、写手 Agent负责撰写初稿、编辑 Agent负责润色校对。这种模式听起来很美好但实际落地时协调成本往往被低估。Agent 之间的通信协议怎么定一个 Agent 的输出格式另一个 Agent 解析不了怎么办某个 Agent 卡住了整个流程怎么处理这些都是实打实的工程问题。我的建议是除非任务确实需要不同领域的专业知识否则不要轻易上多 Agent。大多数场景下一个配置良好的单 Agent 加上合理的工具集效果不比多 Agent 差而且调试起来简单得多。如果非要用多 Agent先从两个 Agent 开始跑通了再考虑扩展。模式核心特征适合场景主要风险ReAct边想边做动态决策探索型、信息检索循环失控、token 消耗大Plan-and-Execute先规划后执行流程化、步骤明确计划僵化、难以适应变化多 Agent 协作角色分工各司其职需要多领域专业知识协调复杂、调试困难4. 从零搭一套可用的编排系统关键决策与代码骨架4.1 工具定义给模型一份菜单工具定义是编排系统的入口。你需要告诉模型有哪些工具可用、每个工具干什么、参数怎么传。这份菜单的质量直接决定了模型能不能选对工具。一个工具定义通常包含四个字段名称、描述、参数 schema、返回值说明。其中描述是最关键的——模型就是靠描述来判断什么时候该用这个工具的。描述要写得像给新员工交代工作一样清楚这个工具是干什么的、什么情况下用、什么情况下不要用。举个例子一个搜索工具的描述可以这样写{ name: web_search, description: 搜索互联网获取最新信息。适用于查询实时数据、新闻、产品信息等。不适用于查询已知的常识性知识或需要精确计算的任务。, parameters: { type: object, properties: { query: { type: string, description: 搜索关键词建议使用具体、明确的短语 }, num_results: { type: integer, description: 返回结果数量默认 5最大 10 } }, required: [query] } }注意描述里明确写了不适用于的场景这能有效减少模型误用工具的情况。我见过太多案例是模型拿搜索工具去算数学题结果搜出来一堆不相关的网页。4.2 主循环编排的心脏主循环的伪代码大概长这样def orchestrate(user_input, tools, max_steps10): messages [{role: user, content: user_input}] step 0 while step max_steps: response call_llm(messages, toolstools) if response.has_tool_call(): tool_name response.tool_call.name tool_args response.tool_call.args try: result execute_tool(tool_name, tool_args) messages.append({role: tool, content: truncate(result)}) except ToolError as e: messages.append({role: tool, content: f工具调用失败{e}}) else: return response.content step 1 return 达到最大步数限制基于已有信息给出回答 summarize(messages)这段代码看起来简单但每个环节都有讲究。truncate函数负责控制工具返回的长度execute_tool里要有重试和超时逻辑summarize是在达到步数上限时的兜底策略。4.3 提示词模板编排的操作手册系统提示词是编排系统的灵魂。它需要告诉模型你的角色是什么、你可以用哪些工具、决策的原则是什么、输出格式有什么要求。我常用的模板结构是这样的你是一个任务执行助手。你可以使用以下工具来完成任务[工具列表]工作原则每次只调用一个工具等待结果后再决定下一步如果已有信息足够回答问题直接给出最终答案不要多余调用工具调用失败时分析失败原因尝试其他方式或告知用户最终答案要基于工具返回的实际结果不要编造信息输出格式调用工具时使用指定的 JSON 格式给出最终答案时直接输出文本。这个模板的关键在于原则要具体、可执行。不要多余调用比尽量高效有用得多因为前者是明确的判断标准后者是模糊的感觉。4.4 错误处理编排的安全气囊错误处理做得好不好直接决定了系统是能用还是好用。我的经验是分三层处理第一层工具级重试。网络超时、限流这类临时性错误在执行器内部自动重试 2-3 次用指数退避策略。重试对模型透明模型不需要知道底层抖动了。第二层模型级恢复。工具最终失败后把错误信息返回给模型让模型决定怎么办——换个工具、换个参数、还是放弃。这里提示词要引导模型分析失败原因而不是简单重试同一个调用。第三层系统级兜底。如果连续多次失败或者达到步数上限系统接管基于已有信息生成一个尽力而为的回答并明确告知用户哪些部分可能不完整。def execute_with_retry(tool_name, args, max_retries3): for attempt in range(max_retries): try: return execute_tool(tool_name, args) except RetryableError as e: if attempt max_retries - 1: raise time.sleep(2 ** attempt) except NonRetryableError: raise这段代码区分了可重试和不可重试错误避免在参数错误这种重试也没用的情况上浪费时间。5. 实测中那些文档不会告诉你的坑5.1 模型假装调用了工具这是最隐蔽的坑之一。模型在输出里写了一段看起来像工具调用的 JSON但实际上并没有走 function calling 的通道只是普通文本。你的解析器如果不够严谨可能会把这段文本当成真的工具调用去执行结果参数是错的或者工具名根本不存在。排查方法检查模型返回的finish_reason字段。正常的工具调用应该是tool_calls如果是stop但内容里有 JSON那就是模型在演戏。解决办法是在提示词里强调必须通过 function calling 调用工具并且在解析时严格校验。5.2 上下文窗口的隐形杀手工具返回的长文本是上下文窗口的最大消耗者。一次搜索返回 5000 字三次搜索就是 15000 字再加上系统提示词和历史消息很快就逼近窗口上限了。更麻烦的是很多模型在上下文接近满的时候对早期信息的注意力会显著下降导致忘了之前的关键信息。我的应对策略是主动压缩每次工具返回后先让一个轻量模型做摘要只保留关键信息再塞回主上下文。摘要的提示词可以很简单用 100 字以内总结以下内容的关键信息保留具体数据和结论。这样虽然多了一次模型调用但省下来的上下文空间能让主循环跑更多步。5.3 工具选择的选择困难症当工具数量超过 10 个时模型选错工具的概率会明显上升。这不是模型笨而是工具描述之间的区分度不够。比如你同时有search_web和search_news两个工具描述都写搜索信息模型当然分不清什么时候用哪个。解决办法有两个一是合并相似工具把search_web和search_news合并成一个search用参数区分搜索类型二是在描述里明确边界比如search_web 用于通用信息查询search_news 仅用于查询最近 7 天的新闻事件。我倾向于第一种方案工具越少模型决策越准。5.4 死循环的三种典型形态死循环是编排系统最常见的故障模式我遇到过三种形态一反复调用同一个工具。模型对结果不满意反复搜索同一个关键词。解决办法是记录已调用过的工具和参数在提示词里告诉模型以下调用已经执行过不要重复。形态二在两个工具之间来回跳。比如先搜索觉得信息不够去查数据库数据库没有又去搜索。这种循环更隐蔽因为每次调用的工具确实不同。解决办法是设置无进展检测——如果连续三步没有产生新的有效信息强制终止。形态三参数微调循环。模型不断微调搜索关键词每次返回的结果都差不多但模型总觉得再试一次可能更好。解决办法是给工具调用加一个相同工具调用次数上限比如同一个工具最多调用 5 次。5.5 成本控制的隐形漏斗编排系统的成本不是线性增长的而是指数级的——每一步都要把之前所有历史消息发给模型token 消耗随步数平方增长。跑 10 步的成本可能是跑 5 步的 4 倍。控制成本的手段有几个限制步数上限最直接有效、压缩历史消息减少每步的输入 token、用便宜模型做简单决策比如用轻量模型判断是否需要调用工具用旗舰模型做复杂推理、缓存重复调用相同参数的相同工具调用直接返回缓存结果。我一般会把单次任务的成本预算定在 0.1-0.5 元之间超过这个范围就要检查是不是哪里出了问题。6. 编排系统的观测与调优让黑盒变透明6.1 日志设计记录什么才有用编排系统的日志不能只记成功/失败要记录完整的决策链路每一步的输入是什么、模型输出了什么、调用了哪个工具、参数是什么、返回了什么、耗时多久、消耗了多少 token。这些信息在排查问题时缺一不可。我习惯用结构化日志每条记录是一个 JSON包含step、thought、action、observation、tokens、latency这些字段。这样后期可以用脚本做聚合分析比如平均每步消耗多少 token哪个工具调用最频繁哪类任务最容易触发重试。6.2 关键指标盯住这几个数就够了编排系统不需要监控几十个指标盯住这几个核心的就够了任务成功率最终给出有效回答的比例平均步数完成任务平均需要几步突然升高说明有问题工具调用失败率按工具维度统计失败率高的工具要重点排查单任务平均成本token 消耗换算成金额超过预算要预警P95 延迟大部分任务很快但少数任务特别慢P95 能反映长尾情况这些指标不需要实时大屏每天看一次趋势就够了。突然的异常波动才是需要立即关注的。6.3 调优的优先级先改提示词再改架构遇到效果不好的情况很多人的第一反应是换个框架或者加个 Agent。但根据我的经验80% 的问题可以通过改提示词解决。模型选错工具在工具描述里加一句不适用于 XX 场景。模型不给出最终答案在提示词里强调信息足够时直接回答。模型输出格式不对给一个具体的输出示例。这些改动成本极低效果立竿见影。只有当提示词优化到极限、问题依然存在时才考虑调整架构——比如从 ReAct 换成 Plan-and-Execute或者引入重规划机制。架构调整的代价是代码重构和重新测试能不动就不动。7. 关于编排这件事我的一些个人体会折腾编排系统这一年多最大的感受是编排的本质不是让模型更聪明而是让系统更可控。模型的能力上限是固定的但通过合理的编排你可以让它在边界内稳定发挥而不是随机地超常或失常。另一个体会是简单方案往往胜出。我见过太多团队一上来就搞多 Agent 协作、动态规划、自适应重试结果系统复杂到没人能调试。反而是那些老老实实用 ReAct 循环、把提示词打磨到极致的方案跑得最稳。最后一个建议先跑通再优化。不要一开始就追求完美的错误处理、精细的成本控制、全面的监控指标。先用最简单的循环把主流程跑通看到实际效果之后再针对具体问题逐个优化。编排系统是迭代出来的不是设计出来的。如果你正在搭建自己的编排系统遇到卡住的地方不妨回到最基本的问题模型现在能看到什么信息它需要做什么决策决策的结果怎么反馈回去把这三个问题想清楚大部分难题都有了解法。