近两年 Agent 项目的热度一直没降过但真正能把 Agent 从“能跑通的 Demo”推到“稳定服务用户的生产系统”的团队少之又少。我见过太多项目卡在同一个地方单轮对话表现惊艳多轮一跑就乱精心设计的 CoT 提示词在 Demo 数据上效果很好换一波真实用户请求就频繁出错单智能体勉强可用一上多智能体协作就会出现互相覆盖状态、重复调用工具、成本翻倍的问题。这篇文章不讲花哨概念只讲我从实际项目里拆出来的东西Agent 的架构分层、多智能体系统的协作模式以及从 Demo 走向生产时要补齐的工程化能力。适合已经在做 Agent 应用、正准备做多智能体改造、或者想把原型推向生产的开发者看。1. Agent 的架构先看清那套“无人驾驶”的隐喻很多人聊 Agent 架构喜欢拿“自动驾驶”类比说 Agent 就是让大模型像司机一样自主决策。这个类比有道理但不完整——自动驾驶有明确的交通规则、传感器融合和冗余设计Agent 生产系统同样需要这套东西只是我们把“传感器”换成了工具调用把“交通规则”换成了状态机和权限控制。1.1 Agent 的四个基础模块拆解我在实际项目里习惯把一个 Agent 拆成四层来看感知层、决策层、行动层、记忆层。这四层不只是一个概念框架它直接决定了代码怎么组织、异常往哪里抛、日志在哪里打。感知层负责接收用户输入并完成意图识别和实体抽取。这一层最容易犯的错误是直接把原始用户输入扔给大模型缺少结构化的意图解析。我见过一个客服场景的 Agent用户说“我要退换货”模型直接去调用退款接口结果用户其实是想问退货政策——这就是感知层没有做意图分类导致的连锁错误。正确的做法是在感知层先做一次轻量分类搞清楚用户是咨询、操作还是投诉再进入后续决策链路。决策层是 Agent 的“大脑”负责规划任务、选择工具、拆分步骤。这里最核心的机制是 ReAct 循环也就是“思考-行动-观察”的循环。规划不是一次性的Agent 需要在执行过程中不断根据中间结果修正计划。我在早期实现中吃过亏——用了一次性规划就让 Agent 按部就班执行结果中间一步失败后整个任务就死了。后来改成逐步规划、逐步校正成功率明显提升。行动层就是工具调用的执行层。这一层要解决的不仅是“调不调得动”更是“调得对不对”。工具的参数校验、权限校验、超时控制、结果解析都应该在这一层做标准化处理。我建议把工具调用封装成统一协议输入一个结构化的 JSON输出一个结构化的 JSON哪怕是调用一个内部 HTTP 接口也走同一套包装。这样后续有多智能体协作时工具层可以无缝复用到不同 Agent 上。记忆层分为短期记忆和长期记忆。短期记忆是当前会话的上下文长期记忆是用户偏好、历史事实这类跨会话信息。很多项目把记忆简单理解成“把历史聊天记录塞进上下文”这是误区——短期记忆要做摘要压缩长期记忆要做向量检索加事实校验。1.2 架构选型背后的关键取舍选 Agent 架构时要先想清楚一个问题你需要的是一把刀还是一套厨房单体 Agent 适合任务路径明确、工具数量少的场景多智能体系统适合子任务可并行、角色边界清晰的场景。单 Agent 的优势是状态管理简单所有上下文都在一个对话链路里不会出现消息传递丢失的问题。但它的天花板也很明显当工具数量超过 20 个时工具描述和调用记录的 token 开销会迅速膨胀而且单点故障是致命的一旦决策错误就是整体失败。多 Agent 的优势是角色隔离和故障隔离但它引入了一个新的问题——通信协议设计。Agent 之间用什么语言交流共享内存还是消息传递这些问题在 Demo 阶段可以含糊在生产阶段必须白纸黑字定清楚。我建议的生产落地策略是渐进式的先跑通单 Agent确认单 Agent 的瓶颈具体在哪再决定是否拆分成多 Agent。如果是上下文长度不够导致的问题优先做记忆压缩而不是拆 Agent如果是任务类型差异太大导致指令冲突才考虑拆。1.3 状态机Agent 循环的隐藏骨架这是我特别想强调的一点——Agent 循环本质是一个状态机而不是一段无限的 while 循环。生产系统里最危险的就是让大模型自由决定“什么时候结束”模型可能会陷入死循环也可能在任务没完成时就过早收尾。我在项目中定义了五个核心状态INIT、PLANNING、EXECUTING、OBSERVING、FINISHED加上两个异常态TIMEOUT 和 ERROR。Agent 就在这些状态之间流转每一步都记录状态迁移日志。这让调试变得直接可追踪——用户投诉说 Agent 反应不对我拉出状态机日志一看就知道卡在哪一步。状态设计的关键是要显式定义“终止条件”。一个任务什么时候算完成是用户确认了还是工具执行成功了还是达到最大步数了这三个条件的优先级是什么我踩过的坑是让 Agent 自己判断“是否完成”结果它经常觉得“差不多了”就提前结束用户根本还没确认。后来改成强约束只有用户明确确认或人工审核通过任务才允许进入 FINISHED 状态。2. 多智能体协作从单兵作战到团队协作单 Agent 做不了的事多智能体不一定就能做。但在某些特定场景下多 Agent 的收益是实实在在的。这章节我用实际经验聊聊什么时候该拆、怎么编排、以及协作时最容易掉进去的坑。2.1 为什么需要多智能体我最早做多 Agent 是被一个实际需求逼的一个企业知识库问答系统原本只有单个 Agent既要做意图识别又要做知识库检索还要做权限过滤提示词越写越长模型越来越“精神分裂”——回复咨询时带着操作味处理操作时又忍不住解释。拆分的核心动力不是“多智能体听起来更高级”而是角色冲突的不可调和性。“操作员 Agent”需要简洁直接、快速调工具“会话 Agent”需要礼貌周全、解释清楚“审查 Agent”需要严格挑剔、不轻易放行。三种角色塞进同一套提示词谁都会内耗。多 Agent 的收益第一是上下文隔离。每个 Agent 只需关注自己角色的指令和工具上下文更干净决策噪声更少。第二是故障隔离。某个 Agent 出问题不会连带整个链路崩溃可以有重试和降级空间。第三是并行能力。检索、分析、生成这类无依赖的子任务可以分头执行延迟从串行相加变成并行取最大。2.2 常见的协作编排模式多 Agent 协作的编排模式我根据自己的项目经验总结出四种常用且易落地的主管-下属模式一个主管 Agent 负责任务拆解和结果汇合多个下属 Agent 分别处理子任务。适合任务类型多样、需要统一调度的场景稳定性高但主管可能成为瓶颈。流水线模式任务按固定顺序依次经过多个 Agent每个 Agent 只处理自己擅长的一环。适合流程固定、顺序依赖强的场景比如说内容审核流水线初筛、深度审查、格式校验三道关卡。市场模式多个 Agent 争抢任务根据匹配度或报价决定谁来处理。这种模式最灵活但也最难控制我建议除非必要否则不要轻易上。辩论模式多个 Agent 分别提出方案并互相质询最后投票或由裁决者拍板。适合高风险决策场景比如大额审批、内容合规判断但 token 开销巨大。这四种模式可以嵌套使用比如主管下属模式中的某个下属本身是一个小型辩论团队。但嵌套越多链路越复杂越难排查问题。我的建议是控制深度——两级嵌套是上限超过两级的系统一定要先把基础的可观测性和重试机制做扎实再上。2.3 协作通信消息协议与共享状态多 Agent 之间怎么通信这个问题在 Demo 阶段经常被忽略但它是生产系统最先爆炸的地方。我见过两种极端做法一种是什么都走共享全局状态所有 Agent 都能读写同一个大 JSON结果一个 Agent 改坏了字段其他 Agent 全崩另一种是 Agent 之间直接传自然语言消息靠大模型理解结果消息越传越偏一轮过后任务就跑题了。我的做法是结构化消息加开放接口。Agent 与 Agent 之间不发自然语言句子而是发结构化的任务对象包含任务 ID、输入参数、预期输出 schema、截止时间。这样每个 Agent 只需要按 schema 解析输入、填充输出不依赖自然语言理解也能协作。自然语言描述只作为人可读的调试辅助字段存在。共享状态不是完全不能有但必须分级。全局共享的只有角色无关的、只读的公共信息可写状态必须归属于某个 Agent其他 Agent 只能通过接口去读。这样才能理清出问题时到底是谁改坏了数据。2.4 多 Agent 协作容易踩的坑多 Agent 系统的坑个个都是生产事故级别的。通信开销膨胀是我最先撞上的坑。多个 Agent 来回传递消息每一步都在消耗 token一轮任务下来开销比单 Agent 高三四倍。优化方向是能并行就并行能精简就精简主管只做拆解和汇合不要干预下属的每一步细节。死循环是第二个坑。两个 Agent 互相等待对方确认或者 A 把 B 的输出当作自己的输入反复处理这种问题用人工检查很难发现因为对话看起来还挺合理。我的做法是全局统一的步数上限和超时中断每个任务最多执行 N 步超时强制走降级流程。第三个坑是角色退化。多个 Agent 跑久了会互相同化——下属 Agent 开始模仿主管的口吻和策略审查 Agent 开始放松标准当老好人。这和提示词里角色设定不够强有关也和行为反馈机制缺失有关。解决思路是定期用评估集测试每个 Agent 的独立表现不只看整体链路效果。3. 从 Demo 到生产真实的工程化差距Demo 和生产之间的差距可以用一句话概括Demo 证明“能跑”生产要求“能扛、能查、能修、能评估”。3.1 Demo 看着能跑生产却总出错的原因很多人以为 Demo 到生产只是部署环境的区别实则不然。我拆过自己的项目也帮朋友排查过类似问题发现几个共性的错位。Demo 的测试数据是挑过的。不管有意无意Demo 用的都是我们自己准备的数据覆盖的是“理想场景”用户的真实输入往往是含糊的、带情绪的、有错别字的、省略上下文的。生产环境里这些杂音才是常态。Demo 是单轮验证生产是多轮长期运行。单轮问答表现好不代表多轮对话状态能保持住。用户有可能中途改口、撤回请求、追问半年之前的某个细节——这些在 Demo 里都不会出现生产里全都会来。Demo 的成功标准是“看起来有道理”生产的成功标准是“精确完成任务”。比如信息查询类 AgentDemo 里答得不完整用户可能还能忍生产环境里手续费算错一分钱就是事故。这种容错的消失要求 Agent 的每一步都有可量化的正确性保障。另外一个隐蔽的错位是工具的真实状态。Demo 里工具都是 mock 的返回值干净整洁生产里工具是真实系统有网络延迟、有返回超时、有数据异常、有并发冲突。Agent 调工具失败后如何重试、如何降级、如何向用户交代——这是工程化必须要回答的问题。3.2 六个必须补齐的工程化能力从我的实践出发一个 Agent 要从 Demo 走到生产至少需要补齐下面六个能力。第一是可靠的执行环境。Agent 不能直接裸跑在 request 里要有一个受控的执行环境支持超时熔断、内存限制、并发配额。每一轮 Agent 循环都要有明确的时间盒超过设定时间就要中断或降级。第二是可观测性。大模型是不确定的这意味着 Agent 的行为天然比传统程序更难排查。必须从一开始就埋好全链路的 trace用户的原始输入、模型每一步的思考、工具调用的入参出参、中间状态迁移全部留痕。我之前在一个客服 Agent 项目里靠完善的 trace 定位到 80% 以上的问题没有 trace 那这些问题的排查根本无从下手。第三是评估体系。没有评估体系Agent 的迭代就是盲改。要建设“离线评估集 在线指标 回归测试”三层防护。离线评估集至少要准备几百条真实分布的问题覆盖正常、边缘、异常三类输入在线指标关注任务成功率、用户反馈率、平均耗时每一次改动都要跑回归看是否引入了新问题。第四是权限与安全控制。Agent 能调用的工具必须经过权限校验高危操作必须有二次确认或人工审批。这个在 Demo 里可以省略生产环境里省略的后果可能是直接事故。第五是成本控制。生产环境里 token 费用是真实的运营成本。要做的优化包括模型分级、缓存命中、批量推理、上下文压缩。我见过不加控制的项目单次任务消耗几十万 token成本完全不可持续。第六是兜底降级方案。Agent 肯定会失败。生产系统必须要预设失败的兜底路径模型超时了直接转人工客服工具失败后给用户一个明确的错误说明而不是让模型编一个结果这些兜底逻辑必须提前写好。3.3 案例拆解为什么同一个 Demo 在两个项目里差这么多我朋友做过一个内部知识库问答 Agent同样的技术架构基本一样的提示词在 A 公司跑得很顺在 B 公司却问题频发。刚开始以为是大模型的问题后来排查发现根因在数据层。A 公司的知识库是结构化的问答对检索命中率高B 公司的知识库是大量非结构化的技术文档很多问题根本检索不到答案。模型在检索不到答案时会“试图”凑一个答案出来这在 Demo 里不显眼但在生产里就是严重的信任问题。这个案例给我的启发是Agent 系统的上限往往不取决于模型多强而取决于数据层、工具层、业务层的支撑能力。工程化改造不能只关注 Agent 内部的算法链路还要打通上下游的数据质量和工具稳定性。这个链条上任何一环薄弱Agent 都会在生产环境里暴露出来。4. 落地实操渐进式迁移路线与关键步骤理论说完了说点能直接上手的。以下是我在一个客服 Agent 项目里验证过的落地路线四步走锁定边界、改造调度、建立可观测、优化迭代。每一步都有关键动作和要避开的雷区。4.1 第一步从 Demo 锁定能力边界落地做的第一件事不是写代码是画能力边界。拿一张大白纸把“这个 Agent 在第一个生产版本里必须要做的事”和“绝对不碰的事”分别列出来。必须要做的事列的是核心高频场景比如客服 Agent 的订单查询、物流查询、常见问题解答。绝对不碰的事列的是高风险或低确定性场景比如情绪化投诉处理、大额退款决策、多轮复杂协商——这类场景先转人工等 Agent 跑稳了再逐步灰度接入。这一步的逻辑是生产系统上线不是证明 Agent 多能干而是先证明 Agent 在受控范围内可靠。我见过很多项目死在“想一次解决所有问题”上模型一遇到边界外场景就胡说用户信任度瞬间归零。反过来能力边界清晰、拒绝果断的 Agent 反而更容易赢得用户信任。关键动作是定义清晰的“拒答”策略。明确什么场景下 Agent 必须说“这个我处理不了转人工”拒绝本身不是失败乱答才是。4.2 第二步改造调度与状态管理Demo 里的 Agent 循环通常是“模型自己决定下一步”生产环境里要把这套改造得更受控。我推荐的做法是接入可编排的调度框架把任务的运行方式从“模型自驱”变成“平台可控”。在自研场景下实现思路是多加一道调度层调度层规定 Agent 每一步可选的操作范围、每步最大耗时、全局最大步数一旦越界调度层强制切断。这样即使模型推理出错也只会执行调度层允许范围内的动作风险被限制在一定幅度内。多 Agent 场景下状态管理更是重中之重。要有一个全局的运行时状态存储记录每个任务的状态迁移轨迹。每个 Agent 的消息收发都要经过这个运行时方便观察全局而不是一个黑盒。另外工具层同步做统一注册和鉴权。工具清单集中管理工具的入参和出参 schema 注册在案调用要过权限校验。不要允许 Agent 自由调用任何内部接口这是生产安全的基本底线。4.3 第三步建立可观测性和评估体系没有可观测性谈生产就是空话。我在 Agent 项目里至少接入三类遥测数据日志、指标、追踪。日志至少要覆盖每一次模型调用的请求与响应摘要、每一次工具调用的入参与出参、每一条状态迁移记录。指标至少包括全局任务成功率、平均轮数、平均延迟、token 消耗分布、工具调用失败率。追踪要能把一个用户请求全链路串起来看它经过了哪些 Agent、哪些工具、在哪一步耗时最长或出错。评估体系建设分三步走先准备一批高质量测试集覆盖正常、边缘、异常三类再制定打分标准并安排人工评估最后把评估固化进发布流程任何 Prompt 或代码改动必须通过回归评估才允许上线。在客服场景里我制定的评估指标包括任务完成率用户问题得到有效解决的比例、工具调用准确率实际调用是否正确、拒绝率不确定时正确拒答的比例、用户满意度回访或评分。这套指标定期跑每次改造都有数据对照。4.4 第四步成本与性能的持续优化生产环境的成本是动真格的。下面是几个亲测有效的优化手段。模型分级策略简单意图用轻量模型识别复杂推理用强模型。在客服场景意图分类完全可以用轻量模型只有真正需要多步推理的任务才调用强模型。实测下来这样最多能省去一半以上的“模型税”。缓存策略对常见问题的标准答案做精确缓存对相似问题做语义缓存。语义缓存要注意阈值控制相关性不足时宁可不命中也不要把错误答案返回给用户。上下文压缩策略不是每次请求都把全部历史塞给模型而是把历史摘要化只保留关键事实与用户明确确认过的信息。设计一套摘要更新机制让新对话自动覆盖旧信息防止 token 无限膨胀。性能优化方面关注两个指标首 token 延迟和端到端完成时间。前者受模型推理速度影响后者受工具调用链路影响。可以适度并行化工具调用、缩短不必要的中间步骤、用流式输出来提升用户的等待体验。5. 常见问题与排查技巧实录模型的不确定性决定了 Agent 类系统的排障和普通后端系统完全两个套路。任何 Agent 系统都会遇到同类的诡异问题这一章把我踩过的坑和排查思路整理成了一份速查表顺便拆一个实际的死循环案例。5.1 典型故障速查表现象可能原因排查思路任务反复不完成一直调用工具终止条件设计缺失模型眼里没有“完成”边界检查状态机迁移日志确认是否存在包含循环的路径补全局步数上限回答看似流畅但信息是编的检索/工具未命中时模型“脑补”不肯承认失败检查工具返回是否为空观察模型是否有“猜测式回答”倾向引导在拿不到数据时明确说明工具调用参数频繁错误工具描述模糊、入参 schema 过于复杂简化和标准化工具描述把参数映射做进执行层必要时用正则约束枚举值长对话开始“忘事”或混淆细节上下文长度超限、早期信息被截断或压缩失真检查实际发送给模型的上下文长度优化摘要压缩策略关键事实单独置顶多 Agent 互相等对方任务卡住通信协议存在二义性双方都在等一个不存在的信号查消息队列中的未消费消息检查是否存在环状依赖统一消息超时策略请求量一大接口频繁限流模型 API 配额耗尽、并发请求过多做用量分级和流量整形为高优任务预留配额非核心场景排队或降级这些坑偶发性都很强日志和追踪不到位时尤其难排查。我的经验是先保证异常分支有日志每个“不该发生但模型做了”的行为都要留痕后续才能通过日志回放来分析。5.2 排障实例Agent 陷入死循环一个具体案例最能说明问题——一次客服 Agent 上线后某类退款咨询总会长时间不结束。从用户角度看表现就是一直回复“让我再确认一下”却迟迟不给出结论。随后我拉出它的状态机日志发现它始终在调用退款规则查询工具、拿到结果、准备回答、又认为需要再核实。查对应的工具调用记录发现它反复用相同参数调用同一个查询接口返回结果几乎一致但模型每次都会选择再次查询而不是基于已有结果完成回答。根因有两层。第一层是终止条件设计软弱——提示词里只说“确认无误后回答”但对“什么算确认无误”没有给出可判定的标准。模型没有明确的规则可依据自然无法收敛。第二层是该场景缺少全局最大步数兜底模型想查多少次就能查多少次没有外力打断。修复方案分两步。第一步是给该场景加上“最多查两次查到结果后直接基于结果回答查询失败则转人工并说明“这种情况需要人工处理”的硬规则。第二步是补上全局兜底任何任务超过五步即强制终止并记录告警。修复后这类问题的发生频率基本归零。这个案例典型的点在于死循环未必是模型的“Bug”更多时候是系统设计没有给模型足够的收敛信号。Agent 排障时不要总想着“换更强的模型”先审视状态机、终止条件和兜底逻辑是否闭环。5.3 一套可复用的排障方法论总结几次排障经历我沉淀了一套对 Agent 系统尤其对症的排障方法论可以分成四步。第一步叫“回放”。从追踪系统里拉出完整链路——输入、思考、动作、观察按时间轴展开。大部分问题的线索都会在回放里显露出来。第二步叫“定位”。把问题归类到架构四层里是感知层意图识别错了还是决策层规划出问题了还是行动层工具调错了或是记忆层上下文丢了。归层之后再看模型以外有没有工程原因比如超时、并写、缓存策略很多问题根源不在模型而在工程侧拼图缺失。第三步叫“最小化复现”。用一个最简单的输入在测试环境里复现问题。复现不出来就说明问题大概率跟特定上下文或状态有关会进一步缩小排查范围。能稳定复现反而好办逐个消解变量就能找到触发条件。第四步叫“加防护而非改提示词”。排查清楚后先不急着调 Prompt先想清楚该加哪个硬性防护比如状态约束、超时熔断、权限硬校验再考虑用示例或规则去引导模型行为。硬性防护兜底提示词做引导两者缺一不可只靠提示词猜次数是治标不治本。ChatGPT来了。 我并不是指某个具体的模型而是指Agent应用已经处在从“玩具”走向“工具”的阶段。我对这个阶段的体会是Agent的工程化深度决定了它最终的落地高度。Demo 里只能看到模型有多聪明生产环境里才能看出一套系统到底有多抗造。如果你正打算把一个 Agent 原型推向生产我的建议是先冷静地画清楚能力边界、再扎扎实实把状态机、可观测性、评估体系和兜底逻辑四件事做好。这四件事听着不性感做起来也确实辛苦但它们是 Agent 从炫技变成服务的分水岭。等你的 Agent 可以在没有人工盯着的情况下稳定完成 95% 的常规任务剩下 5% 能对用户诚实地说“请稍等转人工”你就真正跨越了从 Demo 到生产的那道坎。 
长河君 · 2026/10/14 23:54:48 · 阅读 1.2k Agent从Demo到生产：架构分层、多智能体协作与工程化落地
近两年 Agent 项目的热度一直没降过但真正能把 Agent 从“能跑通的 Demo”推到“稳定服务用户的生产系统”的团队少之又少。我见过太多项目卡在同一个地方单轮对话表现惊艳多轮一跑就乱精心设计的 CoT 提示词在 Demo 数据上效果很好换一波真实用户请求就频繁出错单智能体勉强可用一上多智能体协作就会出现互相覆盖状态、重复调用工具、成本翻倍的问题。这篇文章不讲花哨概念只讲我从实际项目里拆出来的东西Agent 的架构分层、多智能体系统的协作模式以及从 Demo 走向生产时要补齐的工程化能力。适合已经在做 Agent 应用、正准备做多智能体改造、或者想把原型推向生产的开发者看。1. Agent 的架构先看清那套“无人驾驶”的隐喻很多人聊 Agent 架构喜欢拿“自动驾驶”类比说 Agent 就是让大模型像司机一样自主决策。这个类比有道理但不完整——自动驾驶有明确的交通规则、传感器融合和冗余设计Agent 生产系统同样需要这套东西只是我们把“传感器”换成了工具调用把“交通规则”换成了状态机和权限控制。1.1 Agent 的四个基础模块拆解我在实际项目里习惯把一个 Agent 拆成四层来看感知层、决策层、行动层、记忆层。这四层不只是一个概念框架它直接决定了代码怎么组织、异常往哪里抛、日志在哪里打。感知层负责接收用户输入并完成意图识别和实体抽取。这一层最容易犯的错误是直接把原始用户输入扔给大模型缺少结构化的意图解析。我见过一个客服场景的 Agent用户说“我要退换货”模型直接去调用退款接口结果用户其实是想问退货政策——这就是感知层没有做意图分类导致的连锁错误。正确的做法是在感知层先做一次轻量分类搞清楚用户是咨询、操作还是投诉再进入后续决策链路。决策层是 Agent 的“大脑”负责规划任务、选择工具、拆分步骤。这里最核心的机制是 ReAct 循环也就是“思考-行动-观察”的循环。规划不是一次性的Agent 需要在执行过程中不断根据中间结果修正计划。我在早期实现中吃过亏——用了一次性规划就让 Agent 按部就班执行结果中间一步失败后整个任务就死了。后来改成逐步规划、逐步校正成功率明显提升。行动层就是工具调用的执行层。这一层要解决的不仅是“调不调得动”更是“调得对不对”。工具的参数校验、权限校验、超时控制、结果解析都应该在这一层做标准化处理。我建议把工具调用封装成统一协议输入一个结构化的 JSON输出一个结构化的 JSON哪怕是调用一个内部 HTTP 接口也走同一套包装。这样后续有多智能体协作时工具层可以无缝复用到不同 Agent 上。记忆层分为短期记忆和长期记忆。短期记忆是当前会话的上下文长期记忆是用户偏好、历史事实这类跨会话信息。很多项目把记忆简单理解成“把历史聊天记录塞进上下文”这是误区——短期记忆要做摘要压缩长期记忆要做向量检索加事实校验。1.2 架构选型背后的关键取舍选 Agent 架构时要先想清楚一个问题你需要的是一把刀还是一套厨房单体 Agent 适合任务路径明确、工具数量少的场景多智能体系统适合子任务可并行、角色边界清晰的场景。单 Agent 的优势是状态管理简单所有上下文都在一个对话链路里不会出现消息传递丢失的问题。但它的天花板也很明显当工具数量超过 20 个时工具描述和调用记录的 token 开销会迅速膨胀而且单点故障是致命的一旦决策错误就是整体失败。多 Agent 的优势是角色隔离和故障隔离但它引入了一个新的问题——通信协议设计。Agent 之间用什么语言交流共享内存还是消息传递这些问题在 Demo 阶段可以含糊在生产阶段必须白纸黑字定清楚。我建议的生产落地策略是渐进式的先跑通单 Agent确认单 Agent 的瓶颈具体在哪再决定是否拆分成多 Agent。如果是上下文长度不够导致的问题优先做记忆压缩而不是拆 Agent如果是任务类型差异太大导致指令冲突才考虑拆。1.3 状态机Agent 循环的隐藏骨架这是我特别想强调的一点——Agent 循环本质是一个状态机而不是一段无限的 while 循环。生产系统里最危险的就是让大模型自由决定“什么时候结束”模型可能会陷入死循环也可能在任务没完成时就过早收尾。我在项目中定义了五个核心状态INIT、PLANNING、EXECUTING、OBSERVING、FINISHED加上两个异常态TIMEOUT 和 ERROR。Agent 就在这些状态之间流转每一步都记录状态迁移日志。这让调试变得直接可追踪——用户投诉说 Agent 反应不对我拉出状态机日志一看就知道卡在哪一步。状态设计的关键是要显式定义“终止条件”。一个任务什么时候算完成是用户确认了还是工具执行成功了还是达到最大步数了这三个条件的优先级是什么我踩过的坑是让 Agent 自己判断“是否完成”结果它经常觉得“差不多了”就提前结束用户根本还没确认。后来改成强约束只有用户明确确认或人工审核通过任务才允许进入 FINISHED 状态。2. 多智能体协作从单兵作战到团队协作单 Agent 做不了的事多智能体不一定就能做。但在某些特定场景下多 Agent 的收益是实实在在的。这章节我用实际经验聊聊什么时候该拆、怎么编排、以及协作时最容易掉进去的坑。2.1 为什么需要多智能体我最早做多 Agent 是被一个实际需求逼的一个企业知识库问答系统原本只有单个 Agent既要做意图识别又要做知识库检索还要做权限过滤提示词越写越长模型越来越“精神分裂”——回复咨询时带着操作味处理操作时又忍不住解释。拆分的核心动力不是“多智能体听起来更高级”而是角色冲突的不可调和性。“操作员 Agent”需要简洁直接、快速调工具“会话 Agent”需要礼貌周全、解释清楚“审查 Agent”需要严格挑剔、不轻易放行。三种角色塞进同一套提示词谁都会内耗。多 Agent 的收益第一是上下文隔离。每个 Agent 只需关注自己角色的指令和工具上下文更干净决策噪声更少。第二是故障隔离。某个 Agent 出问题不会连带整个链路崩溃可以有重试和降级空间。第三是并行能力。检索、分析、生成这类无依赖的子任务可以分头执行延迟从串行相加变成并行取最大。2.2 常见的协作编排模式多 Agent 协作的编排模式我根据自己的项目经验总结出四种常用且易落地的主管-下属模式一个主管 Agent 负责任务拆解和结果汇合多个下属 Agent 分别处理子任务。适合任务类型多样、需要统一调度的场景稳定性高但主管可能成为瓶颈。流水线模式任务按固定顺序依次经过多个 Agent每个 Agent 只处理自己擅长的一环。适合流程固定、顺序依赖强的场景比如说内容审核流水线初筛、深度审查、格式校验三道关卡。市场模式多个 Agent 争抢任务根据匹配度或报价决定谁来处理。这种模式最灵活但也最难控制我建议除非必要否则不要轻易上。辩论模式多个 Agent 分别提出方案并互相质询最后投票或由裁决者拍板。适合高风险决策场景比如大额审批、内容合规判断但 token 开销巨大。这四种模式可以嵌套使用比如主管下属模式中的某个下属本身是一个小型辩论团队。但嵌套越多链路越复杂越难排查问题。我的建议是控制深度——两级嵌套是上限超过两级的系统一定要先把基础的可观测性和重试机制做扎实再上。2.3 协作通信消息协议与共享状态多 Agent 之间怎么通信这个问题在 Demo 阶段经常被忽略但它是生产系统最先爆炸的地方。我见过两种极端做法一种是什么都走共享全局状态所有 Agent 都能读写同一个大 JSON结果一个 Agent 改坏了字段其他 Agent 全崩另一种是 Agent 之间直接传自然语言消息靠大模型理解结果消息越传越偏一轮过后任务就跑题了。我的做法是结构化消息加开放接口。Agent 与 Agent 之间不发自然语言句子而是发结构化的任务对象包含任务 ID、输入参数、预期输出 schema、截止时间。这样每个 Agent 只需要按 schema 解析输入、填充输出不依赖自然语言理解也能协作。自然语言描述只作为人可读的调试辅助字段存在。共享状态不是完全不能有但必须分级。全局共享的只有角色无关的、只读的公共信息可写状态必须归属于某个 Agent其他 Agent 只能通过接口去读。这样才能理清出问题时到底是谁改坏了数据。2.4 多 Agent 协作容易踩的坑多 Agent 系统的坑个个都是生产事故级别的。通信开销膨胀是我最先撞上的坑。多个 Agent 来回传递消息每一步都在消耗 token一轮任务下来开销比单 Agent 高三四倍。优化方向是能并行就并行能精简就精简主管只做拆解和汇合不要干预下属的每一步细节。死循环是第二个坑。两个 Agent 互相等待对方确认或者 A 把 B 的输出当作自己的输入反复处理这种问题用人工检查很难发现因为对话看起来还挺合理。我的做法是全局统一的步数上限和超时中断每个任务最多执行 N 步超时强制走降级流程。第三个坑是角色退化。多个 Agent 跑久了会互相同化——下属 Agent 开始模仿主管的口吻和策略审查 Agent 开始放松标准当老好人。这和提示词里角色设定不够强有关也和行为反馈机制缺失有关。解决思路是定期用评估集测试每个 Agent 的独立表现不只看整体链路效果。3. 从 Demo 到生产真实的工程化差距Demo 和生产之间的差距可以用一句话概括Demo 证明“能跑”生产要求“能扛、能查、能修、能评估”。3.1 Demo 看着能跑生产却总出错的原因很多人以为 Demo 到生产只是部署环境的区别实则不然。我拆过自己的项目也帮朋友排查过类似问题发现几个共性的错位。Demo 的测试数据是挑过的。不管有意无意Demo 用的都是我们自己准备的数据覆盖的是“理想场景”用户的真实输入往往是含糊的、带情绪的、有错别字的、省略上下文的。生产环境里这些杂音才是常态。Demo 是单轮验证生产是多轮长期运行。单轮问答表现好不代表多轮对话状态能保持住。用户有可能中途改口、撤回请求、追问半年之前的某个细节——这些在 Demo 里都不会出现生产里全都会来。Demo 的成功标准是“看起来有道理”生产的成功标准是“精确完成任务”。比如信息查询类 AgentDemo 里答得不完整用户可能还能忍生产环境里手续费算错一分钱就是事故。这种容错的消失要求 Agent 的每一步都有可量化的正确性保障。另外一个隐蔽的错位是工具的真实状态。Demo 里工具都是 mock 的返回值干净整洁生产里工具是真实系统有网络延迟、有返回超时、有数据异常、有并发冲突。Agent 调工具失败后如何重试、如何降级、如何向用户交代——这是工程化必须要回答的问题。3.2 六个必须补齐的工程化能力从我的实践出发一个 Agent 要从 Demo 走到生产至少需要补齐下面六个能力。第一是可靠的执行环境。Agent 不能直接裸跑在 request 里要有一个受控的执行环境支持超时熔断、内存限制、并发配额。每一轮 Agent 循环都要有明确的时间盒超过设定时间就要中断或降级。第二是可观测性。大模型是不确定的这意味着 Agent 的行为天然比传统程序更难排查。必须从一开始就埋好全链路的 trace用户的原始输入、模型每一步的思考、工具调用的入参出参、中间状态迁移全部留痕。我之前在一个客服 Agent 项目里靠完善的 trace 定位到 80% 以上的问题没有 trace 那这些问题的排查根本无从下手。第三是评估体系。没有评估体系Agent 的迭代就是盲改。要建设“离线评估集 在线指标 回归测试”三层防护。离线评估集至少要准备几百条真实分布的问题覆盖正常、边缘、异常三类输入在线指标关注任务成功率、用户反馈率、平均耗时每一次改动都要跑回归看是否引入了新问题。第四是权限与安全控制。Agent 能调用的工具必须经过权限校验高危操作必须有二次确认或人工审批。这个在 Demo 里可以省略生产环境里省略的后果可能是直接事故。第五是成本控制。生产环境里 token 费用是真实的运营成本。要做的优化包括模型分级、缓存命中、批量推理、上下文压缩。我见过不加控制的项目单次任务消耗几十万 token成本完全不可持续。第六是兜底降级方案。Agent 肯定会失败。生产系统必须要预设失败的兜底路径模型超时了直接转人工客服工具失败后给用户一个明确的错误说明而不是让模型编一个结果这些兜底逻辑必须提前写好。3.3 案例拆解为什么同一个 Demo 在两个项目里差这么多我朋友做过一个内部知识库问答 Agent同样的技术架构基本一样的提示词在 A 公司跑得很顺在 B 公司却问题频发。刚开始以为是大模型的问题后来排查发现根因在数据层。A 公司的知识库是结构化的问答对检索命中率高B 公司的知识库是大量非结构化的技术文档很多问题根本检索不到答案。模型在检索不到答案时会“试图”凑一个答案出来这在 Demo 里不显眼但在生产里就是严重的信任问题。这个案例给我的启发是Agent 系统的上限往往不取决于模型多强而取决于数据层、工具层、业务层的支撑能力。工程化改造不能只关注 Agent 内部的算法链路还要打通上下游的数据质量和工具稳定性。这个链条上任何一环薄弱Agent 都会在生产环境里暴露出来。4. 落地实操渐进式迁移路线与关键步骤理论说完了说点能直接上手的。以下是我在一个客服 Agent 项目里验证过的落地路线四步走锁定边界、改造调度、建立可观测、优化迭代。每一步都有关键动作和要避开的雷区。4.1 第一步从 Demo 锁定能力边界落地做的第一件事不是写代码是画能力边界。拿一张大白纸把“这个 Agent 在第一个生产版本里必须要做的事”和“绝对不碰的事”分别列出来。必须要做的事列的是核心高频场景比如客服 Agent 的订单查询、物流查询、常见问题解答。绝对不碰的事列的是高风险或低确定性场景比如情绪化投诉处理、大额退款决策、多轮复杂协商——这类场景先转人工等 Agent 跑稳了再逐步灰度接入。这一步的逻辑是生产系统上线不是证明 Agent 多能干而是先证明 Agent 在受控范围内可靠。我见过很多项目死在“想一次解决所有问题”上模型一遇到边界外场景就胡说用户信任度瞬间归零。反过来能力边界清晰、拒绝果断的 Agent 反而更容易赢得用户信任。关键动作是定义清晰的“拒答”策略。明确什么场景下 Agent 必须说“这个我处理不了转人工”拒绝本身不是失败乱答才是。4.2 第二步改造调度与状态管理Demo 里的 Agent 循环通常是“模型自己决定下一步”生产环境里要把这套改造得更受控。我推荐的做法是接入可编排的调度框架把任务的运行方式从“模型自驱”变成“平台可控”。在自研场景下实现思路是多加一道调度层调度层规定 Agent 每一步可选的操作范围、每步最大耗时、全局最大步数一旦越界调度层强制切断。这样即使模型推理出错也只会执行调度层允许范围内的动作风险被限制在一定幅度内。多 Agent 场景下状态管理更是重中之重。要有一个全局的运行时状态存储记录每个任务的状态迁移轨迹。每个 Agent 的消息收发都要经过这个运行时方便观察全局而不是一个黑盒。另外工具层同步做统一注册和鉴权。工具清单集中管理工具的入参和出参 schema 注册在案调用要过权限校验。不要允许 Agent 自由调用任何内部接口这是生产安全的基本底线。4.3 第三步建立可观测性和评估体系没有可观测性谈生产就是空话。我在 Agent 项目里至少接入三类遥测数据日志、指标、追踪。日志至少要覆盖每一次模型调用的请求与响应摘要、每一次工具调用的入参与出参、每一条状态迁移记录。指标至少包括全局任务成功率、平均轮数、平均延迟、token 消耗分布、工具调用失败率。追踪要能把一个用户请求全链路串起来看它经过了哪些 Agent、哪些工具、在哪一步耗时最长或出错。评估体系建设分三步走先准备一批高质量测试集覆盖正常、边缘、异常三类再制定打分标准并安排人工评估最后把评估固化进发布流程任何 Prompt 或代码改动必须通过回归评估才允许上线。在客服场景里我制定的评估指标包括任务完成率用户问题得到有效解决的比例、工具调用准确率实际调用是否正确、拒绝率不确定时正确拒答的比例、用户满意度回访或评分。这套指标定期跑每次改造都有数据对照。4.4 第四步成本与性能的持续优化生产环境的成本是动真格的。下面是几个亲测有效的优化手段。模型分级策略简单意图用轻量模型识别复杂推理用强模型。在客服场景意图分类完全可以用轻量模型只有真正需要多步推理的任务才调用强模型。实测下来这样最多能省去一半以上的“模型税”。缓存策略对常见问题的标准答案做精确缓存对相似问题做语义缓存。语义缓存要注意阈值控制相关性不足时宁可不命中也不要把错误答案返回给用户。上下文压缩策略不是每次请求都把全部历史塞给模型而是把历史摘要化只保留关键事实与用户明确确认过的信息。设计一套摘要更新机制让新对话自动覆盖旧信息防止 token 无限膨胀。性能优化方面关注两个指标首 token 延迟和端到端完成时间。前者受模型推理速度影响后者受工具调用链路影响。可以适度并行化工具调用、缩短不必要的中间步骤、用流式输出来提升用户的等待体验。5. 常见问题与排查技巧实录模型的不确定性决定了 Agent 类系统的排障和普通后端系统完全两个套路。任何 Agent 系统都会遇到同类的诡异问题这一章把我踩过的坑和排查思路整理成了一份速查表顺便拆一个实际的死循环案例。5.1 典型故障速查表现象可能原因排查思路任务反复不完成一直调用工具终止条件设计缺失模型眼里没有“完成”边界检查状态机迁移日志确认是否存在包含循环的路径补全局步数上限回答看似流畅但信息是编的检索/工具未命中时模型“脑补”不肯承认失败检查工具返回是否为空观察模型是否有“猜测式回答”倾向引导在拿不到数据时明确说明工具调用参数频繁错误工具描述模糊、入参 schema 过于复杂简化和标准化工具描述把参数映射做进执行层必要时用正则约束枚举值长对话开始“忘事”或混淆细节上下文长度超限、早期信息被截断或压缩失真检查实际发送给模型的上下文长度优化摘要压缩策略关键事实单独置顶多 Agent 互相等对方任务卡住通信协议存在二义性双方都在等一个不存在的信号查消息队列中的未消费消息检查是否存在环状依赖统一消息超时策略请求量一大接口频繁限流模型 API 配额耗尽、并发请求过多做用量分级和流量整形为高优任务预留配额非核心场景排队或降级这些坑偶发性都很强日志和追踪不到位时尤其难排查。我的经验是先保证异常分支有日志每个“不该发生但模型做了”的行为都要留痕后续才能通过日志回放来分析。5.2 排障实例Agent 陷入死循环一个具体案例最能说明问题——一次客服 Agent 上线后某类退款咨询总会长时间不结束。从用户角度看表现就是一直回复“让我再确认一下”却迟迟不给出结论。随后我拉出它的状态机日志发现它始终在调用退款规则查询工具、拿到结果、准备回答、又认为需要再核实。查对应的工具调用记录发现它反复用相同参数调用同一个查询接口返回结果几乎一致但模型每次都会选择再次查询而不是基于已有结果完成回答。根因有两层。第一层是终止条件设计软弱——提示词里只说“确认无误后回答”但对“什么算确认无误”没有给出可判定的标准。模型没有明确的规则可依据自然无法收敛。第二层是该场景缺少全局最大步数兜底模型想查多少次就能查多少次没有外力打断。修复方案分两步。第一步是给该场景加上“最多查两次查到结果后直接基于结果回答查询失败则转人工并说明“这种情况需要人工处理”的硬规则。第二步是补上全局兜底任何任务超过五步即强制终止并记录告警。修复后这类问题的发生频率基本归零。这个案例典型的点在于死循环未必是模型的“Bug”更多时候是系统设计没有给模型足够的收敛信号。Agent 排障时不要总想着“换更强的模型”先审视状态机、终止条件和兜底逻辑是否闭环。5.3 一套可复用的排障方法论总结几次排障经历我沉淀了一套对 Agent 系统尤其对症的排障方法论可以分成四步。第一步叫“回放”。从追踪系统里拉出完整链路——输入、思考、动作、观察按时间轴展开。大部分问题的线索都会在回放里显露出来。第二步叫“定位”。把问题归类到架构四层里是感知层意图识别错了还是决策层规划出问题了还是行动层工具调错了或是记忆层上下文丢了。归层之后再看模型以外有没有工程原因比如超时、并写、缓存策略很多问题根源不在模型而在工程侧拼图缺失。第三步叫“最小化复现”。用一个最简单的输入在测试环境里复现问题。复现不出来就说明问题大概率跟特定上下文或状态有关会进一步缩小排查范围。能稳定复现反而好办逐个消解变量就能找到触发条件。第四步叫“加防护而非改提示词”。排查清楚后先不急着调 Prompt先想清楚该加哪个硬性防护比如状态约束、超时熔断、权限硬校验再考虑用示例或规则去引导模型行为。硬性防护兜底提示词做引导两者缺一不可只靠提示词猜次数是治标不治本。ChatGPT来了。 我并不是指某个具体的模型而是指Agent应用已经处在从“玩具”走向“工具”的阶段。我对这个阶段的体会是Agent的工程化深度决定了它最终的落地高度。Demo 里只能看到模型有多聪明生产环境里才能看出一套系统到底有多抗造。如果你正打算把一个 Agent 原型推向生产我的建议是先冷静地画清楚能力边界、再扎扎实实把状态机、可观测性、评估体系和兜底逻辑四件事做好。这四件事听着不性感做起来也确实辛苦但它们是 Agent 从炫技变成服务的分水岭。等你的 Agent 可以在没有人工盯着的情况下稳定完成 95% 的常规任务剩下 5% 能对用户诚实地说“请稍等转人工”你就真正跨越了从 Demo 到生产的那道坎。