过去一年里被问得最多的问题不是“怎么用 LangChain 写一个 Agent”而是“写完 Demo 之后怎么办”。前后端联调跑通了Prompt 也调得挺顺但一放到生产环境各种奇怪问题全冒出来上下文错乱、工具调用超时、多个 Agent 互相踢皮球、token 成本直接爆表。这个从 Demo 到生产系统的跨越恰恰是 Agent 架构、多智能体协作真正见真章的地方。这篇文章我想以“智能数据分析助手”为例把 Agent 的架构设计、多智能体协作模式以及生产化改造的完整路径讲清楚。适合两类人看一类是已经写过 Agent Demo、准备往生产推的开发者另一类是在做技术选型、想搞明白多智能体到底值不值得用的架构师。全文不绕弯子直接讲我实际踩过的坑和验证过的方案。1. Agent 架构的基础认知与设计思路拆解1.1 一个 Agent 到底由哪几块构成聊 Agent 架构之前必须先建立一个共识Agent 不是一个“能自己思考的程序”而是一套把大模型编排进业务流程的工程系统。我习惯把它拆成六个层缺一个后面都会出问题模型层负责理解和生成是 Agent 的“大脑”。这里不只是选哪个大模型还包括模型分级策略——简单任务用轻量模型复杂任务才调用强模型。记忆层短期记忆会话上下文、当前任务状态和长期记忆用户偏好、历史结论、知识库索引。工具层Agent 能调用的外部能力比如 SQL 查询器、代码解释器、搜索服务、内部 API。工具层必须有统一的注册表和参数协议。规划层决定“先做什么、再做什么、做不了怎么办”。典型方案是 ReAct 或 Plan-and-Execute。执行层把规划结果落地的调度器负责调用工具、拼接上下文、处理错误、决定是否需要重新规划。安全策略层所有环节的守门员包括权限校验、输入检查、输出过滤、人工审批熔断。你可以把 Agent 想象成一个新来的实习生有脑子模型层能思考有便签记忆层记事情有工具箱工具层干杂活有主管规划层排优先级有行政执行层跑腿最后还有个合规经理安全策略层盯着别越界。Demo 阶段大部分人只关心前四层但真正线上出事的几乎都是后两层没设计好。1.2 单智能体是默认起点不要为了“多”而“多”我见过不少团队Demo 刚跑通就开始设计七八个 Agent 的协作网络原因是“多智能体听起来更高级”。这是最大的误区。单智能体的优势非常明确流程简单、延迟可控、易调试、token 消耗低。一个 Agent 内部通过“思考-行动-观察”循环就能完成大量任务。比如一个客服 Agent只需要接入订单查询、退换货规则、物流跟踪三个工具加上一套清晰的 Prompt就能覆盖 80% 的咨询场景。这种复杂度下硬拆成“意图识别 Agent 订单 Agent 物流 Agent 售后 Agent”纯粹是给自己找麻烦。多智能体的本质是解决单智能体解决不了的问题比如任务需要并行处理、不同环节需要不同的专业知识、结果需要交叉校验。判断标准很朴素如果拆成多个 Agent 之后任务完成质量明显提升、总耗时明显下降或者单个 Agent 的上下文长度明显不够用了这时候再拆。否则老老实实先用单 Agent。1.3 从 Demo 到生产架构上的本质差异实际投产过的同学都知道Demo 和生产系统是两个物种。我把差异整理成了一张对照表看完你就明白为什么要做架构改造维度Demo 阶段生产系统进程状态单进程内存态重启即丢状态持久化Redis、Postgres请求模式同步调用一次一问同步 异步混合长任务走队列可靠性失败就重试一次超时控制、降级、熔断、人工值班可观测性靠 print 和日志Trace Metrics Logs 三件套安全基本不设防鉴权、脱敏、审批、审计成本忽略不计token 预算、模型分级、缓存发布方式本地跑通就行灰度发布Prompt 和代码都要版本化这一段是我最想强调的Demo 验证的是“大模型能不能干这件事”生产系统解决的是“大模型这件事干砸了怎么办”。前者决定上限后者决定下限。很多项目死在从 Demo 到生产的半路上不是因为模型能力不行而是因为下限没兜住。2. 多智能体的协作模式与关键设计2.1 常见的协作模式如果评估后确实需要多智能体第一个问题就是它们之间怎么配合。目前业界被反复验证的模式就这么几种我按适用场景排个序主管-工人模式Orchestrator-Worker一个主 Agent 负责任务拆解和结果汇总多个子 Agent 各干各的活。这是最稳妥的模式适合任务边界清晰、可以并行拆分的场景比如数据分析、报告生成、代码审查。流水线模式Pipeline上游 Agent 的输出直接作为下游 Agent 的输入适合有明确先后顺序的流程比如“信息抽取 - 内容改写 - 风格润色”。辩论/评审模式Debate/Review多个 Agent 对同一任务给出不同方案由裁判 Agent 或规则模块选择最优解。适合高风险的决策场景但成本高、耗时久不建议作为默认方案。层级模式Hierarchical主管 Agent 下面还有中层调度者形成树状结构。适合超大规模任务但每一层都会增加延迟和出错概率能用前三种解决就别上这种。我在数据助手项目里用的是“主管-工人 评审”的组合主管负责拆解问题SQL 工人和代码工人并行干活最后评审 Agent 校验结果是否合理。这套组合的好处是容错率很高——评审 Agent 发现结果异常时可以打回给工人重新执行而不是直接把错误答案交付给用户。2.2 多智能体的通信与状态同步多智能体架构里最难的不是“让它们说话”而是“让它们记住说到哪儿了”。通信方式可以选同步直接调用也可以通过消息队列做异步事件驱动但无论哪种共享状态的设计才是地基。我用的是“黑板模式”所有 Agent 读写同一份任务状态表表里记录任务 ID、阶段、输入、输出、状态。主管 Agent 把拆解后的子任务写到黑板上工人 Agent 监听属于自己的任务项完成后回写结果评审 Agent 读取所有结果做校验。这样做有几个好处状态可恢复某个 Agent 挂了其他 Agent 不受影响。可观测性强每个环节的输入输出都有迹可循。天然支持人工介入运营人员可以直接修改黑板上的状态。这个模式本质上把多 Agent 的“协作问题”转化成了“数据一致性问题”思路和微服务架构里的 Saga 模式很接近。实现时不需要花哨的框架一张 Postgres 表 一个 Redis 队列就能跑起来。别一上来就是用分布式事务Agent 这种非确定性系统做不了强一致最终一致才是现实目标。2.3 多智能体不是微服务别把架构搞混写架构方案时经常看到有人把“多智能体”和“微服务”画等号这是个危险误解。微服务是部署单元的概念每个服务独立部署、独立扩容、通过 API 通信解决的是团队协作和系统弹性问题。多智能体是任务协作的概念每个 Agent 是一个大模型驱动的逻辑角色解决的是复杂任务分治问题。两者可以组合但不是一回事。正确的做法是Agent 跑在微服务之上。比如我的数据助手整个系统拆成了接入层、编排层、工具层三个服务编排层里面跑着主管、SQL 工人、代码工人、评审四个 Agent。某个 Agent 的并发压力大了我可以给编排层扩容但工具层的 SQL 服务独立伸缩互不干扰。这种分层设计让我吃到了两边的红利微服务给了我可独立部署和容灾的物理边界多智能体给了我可以灵活编排的逻辑边界。如果一开始就把每个 Agent 单独部署成一个服务集群运维成本和调试成本都会翻倍得不偿失。3. 从 Demo 到生产核心环节的实现与落地3.1 阶段一单人版 Demo验证核心链路我最初写的 Demo 很简单一个 Python 脚本 LLM API用户自然语言提问Agent 判断需不需要查库需要就调用一个 SQL 工具。核心代码的骨架大概是这样的from openai import OpenAI client OpenAI() tool def query_database(sql: str) - str: 执行只读 SQL 查询返回结果集。 # 这里只允许 SELECT禁止其他操作 return run_safe_query(sql) def run_agent(question: str) - str: messages [{ role: user, content: question }] # 循环上限防止死循环 for _ in range(MAX_STEPS): response client.chat.completions.create( modelgpt-4o, messagesmessages, tools[query_database.schema()] ) # 如果模型没要求调用工具直接返回 if not response.tool_calls: return response.content # 执行工具并回填结果 for call in response.tool_calls: result execute_tool(call) messages.append({ role: tool, tool_call_id: call.id, content: str(result) })这个 Demo 能跑但它的问题很明显状态全在内存里没有超时保护没有并发能力SQL 工具没有防注入。可以说它只验证了“大模型能理解用户问题并调用工具”这件事离系统还差得远。3.2 阶段二生产化的四板斧从 Demo 走向生产我按四个顺序做了改造每一步都有明确的理由第一板斧状态外置。会话状态、任务状态、记忆全部从内存搬进 Redis 和 Postgres。理由很简单生产环境是多实例部署的用户第一次请求打到 A 实例第二次可能就被负载均衡转发到 B 实例内存态意味着状态丢失。我把“任务状态表”做成了整个系统的中枢并将用户消息和 Agent 历史上下文都持久化到数据库。第二板斧异步化与队列。数据分析任务经常要跑几十秒甚至几分钟HTTP 同步调用的体验极差而且容易触发网关超时。我引入了任务队列用户提交请求后立刻收到“任务已受理”的响应后台 Worker 从队列取任务执行前端通过 WebSocket 轮询进度。生产实践中这个改动直接解决了两个问题——用户体验的等待焦虑和 LLM 延迟不稳定导致的超时重试。第三板斧可观测性三件套。这一步最容易被忽视但是线上排查问题的命根子。我把每一次 LLM 调用的 token 消耗、工具执行耗时、Agent 决策路径全部记录下来并接入分布式追踪链路。这样一旦任务出错我能清楚看到是规划错了、工具调失败还是结果校验没过而不是靠猜。没有可观测性之前线上 Agent 就是一只薛定谔的猫——你不打开日志就永远不知道它当时在想什么。第四板斧引入多智能体。任务复杂到一定阶段后单 Agent 的上下文越来越长经常出现“前脚说好的事后脚就忘”的情况。这时我拆成了四个角色agents: planner: model: gpt-4o temperature: 0.2 tools: [] role: 拆解用户问题生成执行计划 sql_worker: model: gpt-4o-mini temperature: 0.0 tools: [query_database] role: 将子任务转化为 SQL 并执行 code_worker: model: gpt-4o-mini temperature: 0.0 tools: [run_python] role: 执行数据分析代码生成图表 reviewer: model: gpt-4o temperature: 0.0 tools: [] role: 校验结果合理性异常则打回重跑这里有个关键的取舍模型分级。规划器和评审器用的是强模型因为这两步是“理解与判断”容错空间小执行器用的是轻模型它们主要是翻译任务到工具调用对推理能力要求没那么高。这个分级的成本优势非常明显总 token 成本大概降了四成而且几乎没有质量损失。3.3 阶段三安全、成本与可靠性的治理到了生产环境就要开始处理三类重点问题每一个都是掉过的坑换来的经验。安全治理方面首先做最小权限工具注册表里明确每个 Agent 能调什么SQL 工具直接禁止非 SELECT 语句Python 执行器跑在沙箱容器里不允许网络请求。其次做输入输出审计用户消息里可能带 Prompt 注入我在执行工具前加了指令冲突检测发现可疑模式直接转人工。最后是审批熔断涉及删除、修改类的高危操作让 Agent 自动停下来等管理员确认宁可不自动也不要乱自动。成本治理方面token 的消耗是生产系统躲不掉的大山。我的方案是三层控制第一层是缓存相同问题的分析结果直接复用不做重复计算这一步能挡掉约 30% 的重复请求第二层是模型分级像前文那样简单任务永远不调用强模型第三层是设置预算上限每个用户每天限制调用次数单次任务限制最大循环步数防止 Agent 进入死循环把成本吃光。可靠性治理方面Agent 是概率系统不是确定性系统所以“失败重试”是最基本的手段。更关键的是超时控制LLM 调用设 30 秒超时工具调用设 10 秒超时超时后把失败信息给 Agent 决定是继续还是放弃。此外当整个编排链路连续失败两次以上就触发降级策略——不再让 Agent 死磕而是转交给人工客服处理。生产系统不是追求每次全自动成功而是追求“自动搞不定时还能体面地交给人工”。4. 常见问题与排查技巧实录写到这里我把实际生产中遇到过、并且被反复问到的排查经验总结成一张速查表供大家当参考手册用现象可能原因排查思路与解决方案Demo 正常生产环境频繁超时LLM 延迟波动、工具调用串行、网关超时设置过短先看 Trace 定位瓶颈再做异步化改造工具调用尽量并行合理设置超时时间多智能体互相等待或重复执行编排逻辑不清晰、状态未同步检查黑板状态表确认每个 Agent 的输入输出是否一致给编排层画状态机明确每个阶段由谁负责LLM 返回的 JSON 频繁解析失败输出格式不稳定模型被复杂指令干扰使用结构化输出模式在 Prompt 里给一个标准范例解析失败时带错误信息让模型重新生成一次Agent 被 Prompt 注入执行了危险操作工具权限过大、缺乏输入校验贯彻最小权限工具参数白名单校验高危操作强制人工审批token 成本环比暴涨死循环、上下文无限增长、未做缓存设置最大迭代步数定期裁剪历史上下文引入结果缓存设置预算告警离线评测分数高线上用户却骂难用评测集与真实分布偏差大做线上 A/B 对比收集真实用户反馈进入评测集关注“任务成功率”而不是单一分数多 Agent 流水线整体延迟很高Agent 之间串行等待太多把无依赖的子任务改为并行执行只保留必要的协作环节砍掉多余的“评审官”排查这类问题我个人的核心心法就一句话人脑记不住 Agent 的随机行为必须靠系统日志和状态表还原现场。所以任何时候都不要省 Trace 和审计日志它们不是开发的成本是生产环境的逃生索。还有一个很值得分享的小技巧给关键环节设置“显式的错误出口”。Agent 在不知道该怎么办时默认会硬着头皮编一个答案。我要求每个 Agent 在输出中都带一个confidence字段低于阈值时直接触发人工流程。这个设计让系统在“不知为不知”时能够自动停住避免把幻觉结果直接交给用户效果非常好。我个人在实际推进 Agent 项目时的体会是先单后多、先可观测后优化、先人工介入后全自动。很多人一上来就追多智能体和高自动化其实是本末倒置。先跑通一个单 Agent 的闭环加上日志和审计再逐渐拆出协作角色每一步都有数据支撑再往前走。架构这种东西最适合的是“长出来”的系统而不是“画出来”的系统。如果你也在做 Agent 落地拿这个思路去对照一下自己的项目大概率能少走好几周的弯路。尤其是那套“状态表 消息队列 多角色分工”的组合是我目前为止在成本和稳定性之间找到的最优解照着搭一遍基本就能把 Demo 抗到生产环境了。
过去一年里被问得最多的问题不是“怎么用 LangChain 写一个 Agent”而是“写完 Demo 之后怎么办”。前后端联调跑通了Prompt 也调得挺顺但一放到生产环境各种奇怪问题全冒出来上下文错乱、工具调用超时、多个 Agent 互相踢皮球、token 成本直接爆表。这个从 Demo 到生产系统的跨越恰恰是 Agent 架构、多智能体协作真正见真章的地方。这篇文章我想以“智能数据分析助手”为例把 Agent 的架构设计、多智能体协作模式以及生产化改造的完整路径讲清楚。适合两类人看一类是已经写过 Agent Demo、准备往生产推的开发者另一类是在做技术选型、想搞明白多智能体到底值不值得用的架构师。全文不绕弯子直接讲我实际踩过的坑和验证过的方案。1. Agent 架构的基础认知与设计思路拆解1.1 一个 Agent 到底由哪几块构成聊 Agent 架构之前必须先建立一个共识Agent 不是一个“能自己思考的程序”而是一套把大模型编排进业务流程的工程系统。我习惯把它拆成六个层缺一个后面都会出问题模型层负责理解和生成是 Agent 的“大脑”。这里不只是选哪个大模型还包括模型分级策略——简单任务用轻量模型复杂任务才调用强模型。记忆层短期记忆会话上下文、当前任务状态和长期记忆用户偏好、历史结论、知识库索引。工具层Agent 能调用的外部能力比如 SQL 查询器、代码解释器、搜索服务、内部 API。工具层必须有统一的注册表和参数协议。规划层决定“先做什么、再做什么、做不了怎么办”。典型方案是 ReAct 或 Plan-and-Execute。执行层把规划结果落地的调度器负责调用工具、拼接上下文、处理错误、决定是否需要重新规划。安全策略层所有环节的守门员包括权限校验、输入检查、输出过滤、人工审批熔断。你可以把 Agent 想象成一个新来的实习生有脑子模型层能思考有便签记忆层记事情有工具箱工具层干杂活有主管规划层排优先级有行政执行层跑腿最后还有个合规经理安全策略层盯着别越界。Demo 阶段大部分人只关心前四层但真正线上出事的几乎都是后两层没设计好。1.2 单智能体是默认起点不要为了“多”而“多”我见过不少团队Demo 刚跑通就开始设计七八个 Agent 的协作网络原因是“多智能体听起来更高级”。这是最大的误区。单智能体的优势非常明确流程简单、延迟可控、易调试、token 消耗低。一个 Agent 内部通过“思考-行动-观察”循环就能完成大量任务。比如一个客服 Agent只需要接入订单查询、退换货规则、物流跟踪三个工具加上一套清晰的 Prompt就能覆盖 80% 的咨询场景。这种复杂度下硬拆成“意图识别 Agent 订单 Agent 物流 Agent 售后 Agent”纯粹是给自己找麻烦。多智能体的本质是解决单智能体解决不了的问题比如任务需要并行处理、不同环节需要不同的专业知识、结果需要交叉校验。判断标准很朴素如果拆成多个 Agent 之后任务完成质量明显提升、总耗时明显下降或者单个 Agent 的上下文长度明显不够用了这时候再拆。否则老老实实先用单 Agent。1.3 从 Demo 到生产架构上的本质差异实际投产过的同学都知道Demo 和生产系统是两个物种。我把差异整理成了一张对照表看完你就明白为什么要做架构改造维度Demo 阶段生产系统进程状态单进程内存态重启即丢状态持久化Redis、Postgres请求模式同步调用一次一问同步 异步混合长任务走队列可靠性失败就重试一次超时控制、降级、熔断、人工值班可观测性靠 print 和日志Trace Metrics Logs 三件套安全基本不设防鉴权、脱敏、审批、审计成本忽略不计token 预算、模型分级、缓存发布方式本地跑通就行灰度发布Prompt 和代码都要版本化这一段是我最想强调的Demo 验证的是“大模型能不能干这件事”生产系统解决的是“大模型这件事干砸了怎么办”。前者决定上限后者决定下限。很多项目死在从 Demo 到生产的半路上不是因为模型能力不行而是因为下限没兜住。2. 多智能体的协作模式与关键设计2.1 常见的协作模式如果评估后确实需要多智能体第一个问题就是它们之间怎么配合。目前业界被反复验证的模式就这么几种我按适用场景排个序主管-工人模式Orchestrator-Worker一个主 Agent 负责任务拆解和结果汇总多个子 Agent 各干各的活。这是最稳妥的模式适合任务边界清晰、可以并行拆分的场景比如数据分析、报告生成、代码审查。流水线模式Pipeline上游 Agent 的输出直接作为下游 Agent 的输入适合有明确先后顺序的流程比如“信息抽取 - 内容改写 - 风格润色”。辩论/评审模式Debate/Review多个 Agent 对同一任务给出不同方案由裁判 Agent 或规则模块选择最优解。适合高风险的决策场景但成本高、耗时久不建议作为默认方案。层级模式Hierarchical主管 Agent 下面还有中层调度者形成树状结构。适合超大规模任务但每一层都会增加延迟和出错概率能用前三种解决就别上这种。我在数据助手项目里用的是“主管-工人 评审”的组合主管负责拆解问题SQL 工人和代码工人并行干活最后评审 Agent 校验结果是否合理。这套组合的好处是容错率很高——评审 Agent 发现结果异常时可以打回给工人重新执行而不是直接把错误答案交付给用户。2.2 多智能体的通信与状态同步多智能体架构里最难的不是“让它们说话”而是“让它们记住说到哪儿了”。通信方式可以选同步直接调用也可以通过消息队列做异步事件驱动但无论哪种共享状态的设计才是地基。我用的是“黑板模式”所有 Agent 读写同一份任务状态表表里记录任务 ID、阶段、输入、输出、状态。主管 Agent 把拆解后的子任务写到黑板上工人 Agent 监听属于自己的任务项完成后回写结果评审 Agent 读取所有结果做校验。这样做有几个好处状态可恢复某个 Agent 挂了其他 Agent 不受影响。可观测性强每个环节的输入输出都有迹可循。天然支持人工介入运营人员可以直接修改黑板上的状态。这个模式本质上把多 Agent 的“协作问题”转化成了“数据一致性问题”思路和微服务架构里的 Saga 模式很接近。实现时不需要花哨的框架一张 Postgres 表 一个 Redis 队列就能跑起来。别一上来就是用分布式事务Agent 这种非确定性系统做不了强一致最终一致才是现实目标。2.3 多智能体不是微服务别把架构搞混写架构方案时经常看到有人把“多智能体”和“微服务”画等号这是个危险误解。微服务是部署单元的概念每个服务独立部署、独立扩容、通过 API 通信解决的是团队协作和系统弹性问题。多智能体是任务协作的概念每个 Agent 是一个大模型驱动的逻辑角色解决的是复杂任务分治问题。两者可以组合但不是一回事。正确的做法是Agent 跑在微服务之上。比如我的数据助手整个系统拆成了接入层、编排层、工具层三个服务编排层里面跑着主管、SQL 工人、代码工人、评审四个 Agent。某个 Agent 的并发压力大了我可以给编排层扩容但工具层的 SQL 服务独立伸缩互不干扰。这种分层设计让我吃到了两边的红利微服务给了我可独立部署和容灾的物理边界多智能体给了我可以灵活编排的逻辑边界。如果一开始就把每个 Agent 单独部署成一个服务集群运维成本和调试成本都会翻倍得不偿失。3. 从 Demo 到生产核心环节的实现与落地3.1 阶段一单人版 Demo验证核心链路我最初写的 Demo 很简单一个 Python 脚本 LLM API用户自然语言提问Agent 判断需不需要查库需要就调用一个 SQL 工具。核心代码的骨架大概是这样的from openai import OpenAI client OpenAI() tool def query_database(sql: str) - str: 执行只读 SQL 查询返回结果集。 # 这里只允许 SELECT禁止其他操作 return run_safe_query(sql) def run_agent(question: str) - str: messages [{ role: user, content: question }] # 循环上限防止死循环 for _ in range(MAX_STEPS): response client.chat.completions.create( modelgpt-4o, messagesmessages, tools[query_database.schema()] ) # 如果模型没要求调用工具直接返回 if not response.tool_calls: return response.content # 执行工具并回填结果 for call in response.tool_calls: result execute_tool(call) messages.append({ role: tool, tool_call_id: call.id, content: str(result) })这个 Demo 能跑但它的问题很明显状态全在内存里没有超时保护没有并发能力SQL 工具没有防注入。可以说它只验证了“大模型能理解用户问题并调用工具”这件事离系统还差得远。3.2 阶段二生产化的四板斧从 Demo 走向生产我按四个顺序做了改造每一步都有明确的理由第一板斧状态外置。会话状态、任务状态、记忆全部从内存搬进 Redis 和 Postgres。理由很简单生产环境是多实例部署的用户第一次请求打到 A 实例第二次可能就被负载均衡转发到 B 实例内存态意味着状态丢失。我把“任务状态表”做成了整个系统的中枢并将用户消息和 Agent 历史上下文都持久化到数据库。第二板斧异步化与队列。数据分析任务经常要跑几十秒甚至几分钟HTTP 同步调用的体验极差而且容易触发网关超时。我引入了任务队列用户提交请求后立刻收到“任务已受理”的响应后台 Worker 从队列取任务执行前端通过 WebSocket 轮询进度。生产实践中这个改动直接解决了两个问题——用户体验的等待焦虑和 LLM 延迟不稳定导致的超时重试。第三板斧可观测性三件套。这一步最容易被忽视但是线上排查问题的命根子。我把每一次 LLM 调用的 token 消耗、工具执行耗时、Agent 决策路径全部记录下来并接入分布式追踪链路。这样一旦任务出错我能清楚看到是规划错了、工具调失败还是结果校验没过而不是靠猜。没有可观测性之前线上 Agent 就是一只薛定谔的猫——你不打开日志就永远不知道它当时在想什么。第四板斧引入多智能体。任务复杂到一定阶段后单 Agent 的上下文越来越长经常出现“前脚说好的事后脚就忘”的情况。这时我拆成了四个角色agents: planner: model: gpt-4o temperature: 0.2 tools: [] role: 拆解用户问题生成执行计划 sql_worker: model: gpt-4o-mini temperature: 0.0 tools: [query_database] role: 将子任务转化为 SQL 并执行 code_worker: model: gpt-4o-mini temperature: 0.0 tools: [run_python] role: 执行数据分析代码生成图表 reviewer: model: gpt-4o temperature: 0.0 tools: [] role: 校验结果合理性异常则打回重跑这里有个关键的取舍模型分级。规划器和评审器用的是强模型因为这两步是“理解与判断”容错空间小执行器用的是轻模型它们主要是翻译任务到工具调用对推理能力要求没那么高。这个分级的成本优势非常明显总 token 成本大概降了四成而且几乎没有质量损失。3.3 阶段三安全、成本与可靠性的治理到了生产环境就要开始处理三类重点问题每一个都是掉过的坑换来的经验。安全治理方面首先做最小权限工具注册表里明确每个 Agent 能调什么SQL 工具直接禁止非 SELECT 语句Python 执行器跑在沙箱容器里不允许网络请求。其次做输入输出审计用户消息里可能带 Prompt 注入我在执行工具前加了指令冲突检测发现可疑模式直接转人工。最后是审批熔断涉及删除、修改类的高危操作让 Agent 自动停下来等管理员确认宁可不自动也不要乱自动。成本治理方面token 的消耗是生产系统躲不掉的大山。我的方案是三层控制第一层是缓存相同问题的分析结果直接复用不做重复计算这一步能挡掉约 30% 的重复请求第二层是模型分级像前文那样简单任务永远不调用强模型第三层是设置预算上限每个用户每天限制调用次数单次任务限制最大循环步数防止 Agent 进入死循环把成本吃光。可靠性治理方面Agent 是概率系统不是确定性系统所以“失败重试”是最基本的手段。更关键的是超时控制LLM 调用设 30 秒超时工具调用设 10 秒超时超时后把失败信息给 Agent 决定是继续还是放弃。此外当整个编排链路连续失败两次以上就触发降级策略——不再让 Agent 死磕而是转交给人工客服处理。生产系统不是追求每次全自动成功而是追求“自动搞不定时还能体面地交给人工”。4. 常见问题与排查技巧实录写到这里我把实际生产中遇到过、并且被反复问到的排查经验总结成一张速查表供大家当参考手册用现象可能原因排查思路与解决方案Demo 正常生产环境频繁超时LLM 延迟波动、工具调用串行、网关超时设置过短先看 Trace 定位瓶颈再做异步化改造工具调用尽量并行合理设置超时时间多智能体互相等待或重复执行编排逻辑不清晰、状态未同步检查黑板状态表确认每个 Agent 的输入输出是否一致给编排层画状态机明确每个阶段由谁负责LLM 返回的 JSON 频繁解析失败输出格式不稳定模型被复杂指令干扰使用结构化输出模式在 Prompt 里给一个标准范例解析失败时带错误信息让模型重新生成一次Agent 被 Prompt 注入执行了危险操作工具权限过大、缺乏输入校验贯彻最小权限工具参数白名单校验高危操作强制人工审批token 成本环比暴涨死循环、上下文无限增长、未做缓存设置最大迭代步数定期裁剪历史上下文引入结果缓存设置预算告警离线评测分数高线上用户却骂难用评测集与真实分布偏差大做线上 A/B 对比收集真实用户反馈进入评测集关注“任务成功率”而不是单一分数多 Agent 流水线整体延迟很高Agent 之间串行等待太多把无依赖的子任务改为并行执行只保留必要的协作环节砍掉多余的“评审官”排查这类问题我个人的核心心法就一句话人脑记不住 Agent 的随机行为必须靠系统日志和状态表还原现场。所以任何时候都不要省 Trace 和审计日志它们不是开发的成本是生产环境的逃生索。还有一个很值得分享的小技巧给关键环节设置“显式的错误出口”。Agent 在不知道该怎么办时默认会硬着头皮编一个答案。我要求每个 Agent 在输出中都带一个confidence字段低于阈值时直接触发人工流程。这个设计让系统在“不知为不知”时能够自动停住避免把幻觉结果直接交给用户效果非常好。我个人在实际推进 Agent 项目时的体会是先单后多、先可观测后优化、先人工介入后全自动。很多人一上来就追多智能体和高自动化其实是本末倒置。先跑通一个单 Agent 的闭环加上日志和审计再逐渐拆出协作角色每一步都有数据支撑再往前走。架构这种东西最适合的是“长出来”的系统而不是“画出来”的系统。如果你也在做 Agent 落地拿这个思路去对照一下自己的项目大概率能少走好几周的弯路。尤其是那套“状态表 消息队列 多角色分工”的组合是我目前为止在成本和稳定性之间找到的最优解照着搭一遍基本就能把 Demo 抗到生产环境了。
