最近帮某集团做私有化智能体中台前后蹲守了大半年总结下来就一句话Agent 这东西能跑通 Demo 和能上生产线的差距基本等于玩具遥控车和真车之间的差距。很多人聊 Agent开口就是 ReAct 循环、工具调用、提示词工程但真正落到企业环境你要面对的是权限模型、过程审计、模型私有化、记忆共享、多 Agent 协作、故障恢复……这些没有系统级设计的 Agent往往跑不到两周就废在线上。所以这篇文章我不打算堆概念而是把一套企业级 Agent 架构拆开揉碎讲清楚五组件到底怎么划分、ReAct 循环在企业环境里怎么收敛、以及为什么我坚持要有一个私有可控的底座。很多团队把私有化当运维问题其实它是架构问题而且是决定 Agent 能不能长期稳定运转的根问题。适合谁看两类人。一类是已经在做 Agent 应用但发现 Demo 上线后问题不断的技术负责人另一类是准备从零搭建企业级智能体平台需要一套可落地架构参考的架构师。如果你只是用 Agent 写写文案、查查资料那这篇对你来说会偏重但里面关于循环控制和工具设计的思路对你也照样有借鉴价值。1. 先说结论Agent 不是写个循环那么简单1.1 标题里的三个关键词分别指什么先拆标题。“五组件”说的是 Agent 内部的工程组成。现在行业里对 Agent 的划分多种多样有按认知过程拆的感知、规划、行动、记忆、反思也有按产品能力拆的。我在这篇文章里用的是企业落地视角的工程划分规划、记忆、工具、执行、治理。这五个部分不是学术定义是我在实际项目里迭代出来的最小骨架少了任何一个生产环境都会出问题。“ReAct 循环”是推理与行动交替的闭环机制也是当前大多数 Agent 的核心运行逻辑。模型先推理下一步怎么做然后调用工具执行动作拿到观察结果后再推理下一步。这个循环本身不复杂复杂的是在企业场景里让循环稳定收敛、不出错、不跑飞。“私有可控底座”说的是模型、数据、权限、审计这些底层设施都要掌握在自己手里。企业数据不能出域模型行为要可解释操作过程要可追溯这是 Agent 能嵌入核心业务流程的前提。1.2 先确认你在哪个位置我把做 Agent 的团队粗略分成三个层次。第一层调用大模型 API 套提示词做点文本生成、总结摘要类功能这其实还没有进入 Agent 范畴。第二层实现了 ReAct 循环和工具调用能端到端完成一些简单任务比如查天气、查库存、报销填单。第三层开始把多个 Agent 组织起来接核心业务系统控权限、做审计、管记忆这时候才会碰到我这篇文章里讲的问题。我的建议是如果你在第二层往第三层过渡或者已经在第三层反复踩坑这篇文章的参考价值最大。如果你还在第一层也可以提前看一遍避免后面走弯路——我见过太多团队先写死流程等业务复杂了再返工做架构成本高得吓人。2. 五组件拆解一套能落地的 Agent 最少需要什么这一节是全文的核心骨架我会把五个组件逐个讲透包括每个组件解决什么问题、业界主流实现方式、以及我在实践中踩过的坑。2.1 规划组件把目标拆成可以执行的步骤规划组件负责一件事把用户给出的自然语言目标拆解成模型可以参考执行的动作序列或者子任务列表。最常见的实现方式有三种。第一种是让模型直接在大模型的上下文里逐步推理走一步看一步这就是 ReAct 的主要形态规划与执行交织在一起。优点是灵活缺点是中间步骤不可控。第二种是 Plan-and-Execute 模式模型先一次性生成一份完整的行动计划然后逐步执行执行过程中根据反馈修改计划。这种方式适合任务边界相对清晰的场景比如生成一份季度销售分析报告可以先规划成查询销售数据→整理关键指标→生成图表→撰写分析结论四步。第三种是代码式规划把计划用伪代码或者流程图描述结构来表达由程序而不是模型来控制分支跳转。这种方式最稳定但灵活性最差。我个人在企业项目里的经验是不要迷信纯模型规划。能先用规则和代码把流程骨架固定住的就先用代码固定住只在关键决策点让模型做选择。原因很简单——模型规划的自由度越大出错的可能性越高而企业场景最不能承受的就是不可控的自由。规划组件还需要考虑一个容易被忽略的问题目标重规划。当执行过程中出现异常比如某个数据拿不到、某个系统接口超时Agent 需要重新规划而不是傻傻地重复失败动作。这个能力必须在规划组件里预留否则一次异常就能卡死整个任务。2.2 记忆组件短期记忆与长期记忆不能混为一谈记忆组件是 Agent 最容易糊弄过去、也最容易在后期爆发问题的地方。我把记忆分成两层。短期记忆就是当前对话和任务执行过程中的上下文通常存在大模型的上下文窗口里。这块要注意的是长度管理——上下文窗口是有限的怎么在窗口被塞满时做截断、摘要、或者分段检索是需要认真设计的。长期记忆又分两类。一类是业务知识库比如企业的制度文档、产品手册、历史工单通过向量化后存进向量数据库任务开始时按照相关性检索出来灌入上下文。另一类是 Agent 自身的经验记忆比如以前处理过的类似任务、用户偏好、踩过的坑这类记忆可以让 Agent 越用越顺手。企业环境里记忆有个特殊要求权限隔离。张三的记忆不能让李四的 Agent 读到A 部门的数据不能让 B 部门的 Agent 检索到。很多团队做记忆的时候只考虑了能存能搜没考虑谁能搜到什么结果上线第一天就出了越权访问的严重事故。解决思路是给记忆数据打上权限标签检索阶段就做过滤而不是等检索出来再拦。关于向量检索的准确率我也多说一句TopK 不是越大越好检索相似度阈值要反复调。阈值设太严相关文档召回不够设太松大量无关内容灌进上下文反而拉低模型判断质量。后面实操部分我会给一组参考参数。2.3 工具组件Agent 能力的边界就是工具边界工具组件决定了 Agent 能做什么。一个 Agent 再聪明没有工具它就是一台只会说话、不能干活的问答机器。反过来说工具的质量直接决定了 Agent 完成任务的上限。我见过的最常见的问题是工具定义写得含糊。模型要靠工具的函数描述来理解什么时候该调用这个工具、参数怎么填。如果描述写不清楚模型就瞎猜猜错了系统就报错。我要求团队无论是用 OpenAPI 规范还是 JSON Schema都必须做到三个要素明确工具的服务范围、每个参数的含义与取值规范、返回结果的格式规范。工具注册与发现机制也要设计。早期我们所有工具一股脑挂在 Agent 的工具列表里后来工具超过 30 个上下文已经装不下全部工具描述了而且模型的选择准确率明显下降。后来改成了按标签分组的路由机制——根据任务意图先路由到某个工具域再让 Agent 在该域内选工具准确率大幅回升。再强调一点工具返回结果要做标准化。不同后端系统的返回格式千差万别有 JSON、有 XML、有纯文本Agent 直接解析很容易出错。我在中间加了一层适配器把工具返回值统一成状态 内容摘要 原始数据的结构化格式既方便模型理解也方便程序做判断。2.4 执行组件模型输出和真实动作之间的最后一道闸门执行组件是连接模型想做什么和系统实际做什么的那道闸门。它接收模型生成的决策解析成真实的函数调用执行后把结果写回上下文。执行层最麻烦的问题有两个。一个是格式解析。模型输出可能夹杂着解释、思考、甚至废话真正的工具调用信息往往嵌在其中。业界现在普遍让模型用 JSON 或函数调用专用格式输出动作但模型偶尔还是会输出非法 JSON。这时候不能只做最坏情况处理我建议做多级容错先尝试严格解析失败后用规则提取关键字段再失败就返回要求模型重新输出规范动作。另一个是动作校验与二次确认。对于高风险操作——比如删除数据、修改配置、转账、下发指令执行组件必须在实际执行前做二次确认。我们的做法是在执行组件里嵌一个确认队列这类动作不立即执行而是进入待确认状态等值班人员确认后再放行。这个机制看着保守但它防止过很多次模型过于自信导致的事故。执行组件还负责记录动作快照。每次执行了什么工具、传了什么参数、返回了什么结果全部记录到审计日志。这一步做扎实了后面定位问题会省下大量时间。说实话这个习惯我是吃了好几次数据对不上的亏之后才养成的现在执行组件不落审计日志我是不会放它上线的。2.5 治理组件企业级和玩具级的分水岭治理组件是我自己坚持加进去的第五个组件也是大多数讲 Agent 架构的文章不会重点展开的部分。但一套 Agent 要进企业核心业务流程治理就是生命线。治理组件管三件事。权限。Agent 执行每一个工具调用时都要校验发起者用户、代理者Agent、动作调用哪个工具是否被授权。权限判断不能只在对话入口做一次要在每一个动作上做因为这个 Agent 可能中途被注入指令引导去越权操作。审计。谁在什么时间让 Agent 做了什么、Agent 实际做了什么、结果是什么全程留痕。出了问题时能逐环回溯。企业采购 Agent 平台时经常明确要求这一步你自己做平台就更不能省。多 Agent 协作与调度。多个 Agent 同时处理任务时谁来分配任务、谁来决定 Agent 的优先级、任务之间有没有依赖关系这些都需要治理组件来统筹。前期可以用简单的任务队列加路由调度后期任务复杂度上来后就需要工作流引擎维度来管了。这块不用担心一步到位但要先预留接口。总之五组件之间不是孤立的。规划组件决定做什么记忆组件提供做事需要的背景工具组件提供做事的手段执行组件负责冲锋陷阵治理组件在旁边盯着别越界。我把它们比作一家公司的业务线、档案室、外部供应商、执行团队和风控合规部缺了任何一环这家公司都运行不顺。3. ReAct 循环推理与行动如何闭环以及怎么让它别跑飞3.1 ReAct 到底在循环什么ReAct 的全称是 Reasoning Acting核心机制一句话就能讲完让模型先思考再行动通过观察结果修正下一步思考如此循环往复直到得出最终答案。具体拆开看一轮循环包含三个阶段。Thought思考模型解释当前状态判断下一步该做什么比如用户想查 Q3 销售数据我需要先确认是否存在相关报表。Action行动模型输出一个具体的动作比如调用某个查询工具并传入参数。Observation观察系统执行动作后返回结果这个结果被拼回上下文作为新一轮思考的输入。这个过程跟我们人类解决问题的思路完全一致——遇到问题先想怎么办、动手试一下、看结果、根据结果调整思路、再动手。ReAct 相比纯思维链Chain of Thought的优势就在于模型不再光靠脑子里编造推理过程而是能通过与真实环境交互拿到反馈减少幻觉而且中途能改主意不会一条道走到黑。但要注意ReAct 本质上是一个自由发挥的机制。Demo 阶段它越自由越显得聪明生产阶段它越自由越容易出事。模型完全有可能陷入思考死循环在一个明显走不通的方案上来回打转也有可能一次把 100 步全走完就是不给用户一个最终答案。所以工程化的核心不是让循环跑起来而是给循环装上缰绳。3.2 一个最小可运行的 ReAct 伪代码贴一段我常用的最小实现框架它能帮你理解循环的骨架长什么样def react_loop(task, tools, max_steps8): # 初始化上下文包含任务描述、工具清单、初始观察为空 context build_initial_context(task, tools) for step in range(max_steps): # 推理让大模型决定下一步动作 response llm(context) action parse_action(response) # 如果模型判断任务完成则返回最终答案 if action.type finish: return action.answer # 校验动作工具是否存在、参数是否合法 validated validate_action(action, tools) if not validated.ok: context format_observation( f动作无效{validated.reason}请选择其他可行方案 ) continue # 执行动作前做风险校验高危动作需人工确认 if tools[validated.name].risk_level high: approved ask_for_approval(validated) if not approved: context format_observation( f高危操作已被人工拒绝请停止或调整方案 ) continue # 执行动作记录观察结果 result tools[validated.name].execute(validated.arguments) audit_log(step, validated, result) context format_observation(result) # 超出最大步数仍未完成强制终止并返回中间轨迹 raise AgentLoopTimeout(context)这段代码的关键点有四个。第一是 max_steps 强制上限它保证了循环一定会在有限步内收敛无论是正常结束还是报错超时。这个上限我建议根据任务类型单独设置简单查询类任务 3-5 步复杂分析类任务 8-15 步超过 20 步基本说明 Agent 在瞎转即使不报错也无意义。第二是对无效动作的处理方式。很多实现里模型一旦解析失败就直接让整个任务崩掉其实没必要——只要把失败原因作为观察结果塞回上下文再给模型一次重新选择的机会大多数情况它能纠正过来。这种温和地回退远比直接报错更能提高任务完成率。第三是高危动作的二次确认。我在执行组件那节已经提过这里再强调一遍确认逻辑要放在循环内部不要放在外层拦截因为模型规划下一步动作时会参考最新的观察结果人工拒绝后模型就有机会调整方案而不是机械地重试同一个危险动作。第四是超时后的中间轨迹保留。循环超时不代表任务全过程没有价值——它执行成功的中间步骤、拿到的数据、已经完成的子任务都是可复用的。把这些保存下来不仅便于排查也便于后续在超时基础上做断点续跑的高级功能。3.3 企业环境里 ReAct 的三个收敛手段最大步数限制是最基础的收敛手段但只用它是不够的。我在企业中普遍再加三道保险。第一道动作黑名单与白名单。在工具层明确哪些工具是 Agent 绝对不能碰的比如直接操作生产数据库的 DDL哪些工具是必须在特定条件下才能用的。Agent 如果试图调用黑名单里的工具执行组件直接拒绝并把拒绝原因返回给模型这能防住大量由工具误导和提示注入引发的问题。第二道中间检查机制。复杂任务不一定要一口气跑完可以在关键节点暂停把已经完成的部分和下一步计划同步给用户或者上位系统确认。这个机制在企业流程审批里尤其有用比如自动写邮件可以直接发但要外发之前先给主管确认一眼。第三道语义相似度无变化检测。我在实践中遇到过一种很隐蔽的跑飞——Agent 每一步动作都不同但它实际上只是在反复尝试获得同一个目标数据而工具一直返回未获取到。这时候从执行轨迹看是健康的每一步都在推进但其实就是原位打转。我的做法是对每一步观察结果做语义摘要如果连续三轮的摘要相似度超过阈值判定为无效循环触发系统介入决策要么终止、要么切换检索策略。这三道保险加上 max_stepsReAct 循环在企业环境里才算真正可控。记住一个原则循环的每一圈都必须产出可观测的价值增量没有价值增量就强制终止。4. 企业级 Agent OS为什么我们需要一层系统底座4.1 从“框架”到“OS”的变化发生在哪里现在业界喜欢把 agent 平台类比成操作系统这不是噱头。你仔细想操作系统管什么管进程生命周期、内存分配、文件系统、设备驱动、安全权限。一个企业级 Agent 平台管什么管智能体生命周期、上下文记忆、知识文件、工具设备、权限审计。两者一一对应。我用一个表格把这种类比讲清楚Agent OS 概念操作系统类比具体要解决的问题智能体生命周期管理进程管理Agent 的创建、调度、暂停、销毁、异常重启记忆与上下文管理内存管理短期上下文窗口的分配与压缩、长期记忆的读写知识库管理文件系统文档的入库、切分、索引、版本管理、权限控制工具适配与连接设备驱动工具注册、调用协议统一、接口限流与降级权限与审计安全内核动作授权、敏感操作拦截、全链路操作留痕为什么要套这个类比因为它能帮你建立一种思维转变你不是在写一个 Agent 应用而是在做一套运行 Agent 应用的基础设施。单 Agent 的循环逻辑写得再漂亮放到多 Agent 并行、多人共用、多系统集成的环境里缺少系统底座就寸步难行。举个具体例子。我们项目早期接入的第一个业务是自动生成法务审查意见单个 Agent 跑得很好。后来业务方要求同时在线的用户从 5 个提到 50 个还要跟 OA 审批系统做集成。第一个暴露的问题就是每个用户的会话到底占用多少资源上下文过大导致并发一高服务就扛不住。后来我们给系统加了会话隔离和上下文压缩策略闲置会话自动挂起、热点知识预热加载、长会话定期摘要化。这些都是 OS 层要考虑的事情单靠调大模型参数解决不了。4.2 私有可控底座的四层建设私有可控底座是我反复强调的部分不少团队觉得私有化无非就是把模型部署到内网一旦你这么想后面遇到问题一定是你没预料到的那种。我把底座拆成四层来建。第一层模型层。私有化的核心是运行在自己掌控的环境里不依赖外部接口。现在主流的开源大模型已经足够支撑多数企业内部场景配合微调和量化性能在内部任务上完全可用。选型考虑三点模型能力是否匹配任务复杂度、基础设施资源是否充裕、社区是否活跃可持续迭代。注意量化不是越激进越好——我试过把模型量化到 4bit 之后工具调用的 JSON 输出稳定性明显下降后来又调回了更高精度。第二层数据层。企业私有化的本质其实是数据可控。这一层要做三件事知识库统一纳管让所有 Agent 从一个带权限的数据目录里取数数据匿名化与脱敏日志和观察结果里涉及敏感信息时先做脱敏处理数据血缘追踪能回答Agent 这次回答里的数据是从哪份文档、哪个数据库字段里来的。没有血缘追踪模型给出的数字错了都没法查源头这是很大的隐患。第三层连接与控制层。企业内部有各种业务系统Agent 都要通过这一层统一接入。它负责协议转换、认证鉴权、限流熔断、重试降级。我建议在这一层引入 API 网关模式所有工具调用都走网关网关一侧对内接系统一侧对接 Agent 平台。好处是接新系统不用动 Agent 代码只需要在网关加一个适配器。第四层可观测与治理层。日志采集、链路追踪、指标监控、审计报表、人工审核台全部集中在这一层。每一轮 ReAct 循环的思考、动作、观察都要有 trace 可查每个 Agent 当前状态、调用延迟、成功率、平均步数都要有可视化大盘。一个企业级 Agent 平台如果没有这一层出了事故你连复盘都无从下手。4.3 通用框架与企业级 Agent OS 的差异对照很多团队直接用开源的通用框架起步确实开发效率高但通用框架解决的是让 Agent 能跑起来不是让 Agent 安全稳定地跑完业务。差异主要在五个维度工具管理。通用框架通常提供工具注册接口但企业级 OS 需要完整的工具生命周期管理包括版本、启停、灰度上线、路由规则、调用频控。记忆权限。通用框架的记忆是全局共享的企业级 OS 的记忆是分空间、分权限的每个人只能访问自己被授权的记忆切片。审计合规。通用框架记录日志的颗粒度只够开发调试用企业级 OS 需要满足过程可证明级别的记录每一步谁发起、谁授权、模型怎么思考、动作怎么执行完整可回溯。容错恢复。通用框架的 Agent 崩了就崩了企业级 OS 要有 Agent 异常心跳检测、任务断点续跑、会话迁移能力。运营治理。通用框架没有一个系统入口来管理 Agent 的发布、审核、下线企业级 OS 要有类似应用商店的机制agent 上线要审批运行要有评价下线要平滑。我见过不少团队早期贪图通用框架的上手速度结果到了真正接入核心生产环节时发现权限、审计、恢复机制都要重写最终花费的成本比一开始就自己做底座还要高。这不是说通用框架不好而是说架构选型时先想清楚你做的产品面向生产还是面向演示这个问题的答案决定了你和Agent OS之间的距离。5. 实操搭一个私有可控的 Agent 最小可运行版本5.1 选型建议与理由理论讲再多不如动手装一个。我给出我当前实践验证过的选型组合你可以直接参考也可以按自己的环境替换。模型侧选择一款主流开源大模型部署在内网 GPU 服务上。如果你主要做中文企业内部知识问答优先选中文语料强的基座如果你要做大量工具调用和结构化输出同一个模型可能要经过针对工具格式的微调。推理服务用兼容 OpenAI 协议的推理框架好处是之后换模型或者换服务对方都能复用同一套接口协议。向量库用开源向量数据库支持 HNSW 索引和元数据过滤就行。选它是因为轻量、易部署对中小规模知识库几百万条以内性能足够而且运维负担低。编排框架如果是内部系统我建议用编排开发框架做底座比如 LangGraph 或者自研的循环调度器但不要用它直接对接业务中间加上你自己的管控层。你需要控制的点只有两个工具注册与调用规约、循环终止策略。把这两个管控点做扎实替换或升级框架都很容易。审计存储直接用现有数据库加 JSON 字段存轨迹即可不用过度设计。单 Agent 任务的 trace 数据量并不大关键是索引设计要覆盖按用户查、按任务查、按时间查、按动作查四个维度。5.2 核心实现与关键参数一个最小但五脏俱全的 Agent 服务目录结构大概长这样agent_os/ ├── model/ # 模型调用封装统一 openai 协议 ├── agent/ # ReAct 循环、规划、上下文管理 ├── memory/ # 向量库封装、短期记忆与长期记忆 ├── tools/ # 工具注册、适配器、校验规则 ├── governance/ # 权限校验、审计日志、人工确认 ├── gateway/ # API 网关对外暴露 Agent 服务 └── config/ # 模型、检索、循环参数配置关键代码我挑两块说。第一块是上下文的构建逻辑第二块是检索参数的确定。上下文构建时我会把内容按角色和用途分成三个区块顺序拼接系统指令区包含 Agent 人格、行为边界、输出规范、工具定义区JSON Schema 格式、动态上下文区检索到的知识、历史对话、ReAct 观察结果。顺序不能变因为模型对不同位置的指令响应权重不同。检索参数我直接给一组经过验证的起始值参数建议值调整经验embedding 模型中文场景选国产开源 embedding 模型注意与查询词的语言一致性检索 TopK3-5知识块小于 500 字可取 5大于 1000 字取 3相似度阈值0.65-0.80阈值过高召回不足过低噪声过大按测试集调节上下文窗口上限保留 1/4 空间防止后续工具观察结果无处容纳循环最大步数5-12简单任务 5 步分析类任务放宽到 12 步模型温度0.1-0.3工具调用任务必须低温度越高越容易输出格式混乱top_p0.8-0.9与 temperature 配合使用不要同时拉满这里特别强调 temperature。很多人在做生成任务时习惯默认 0.7 甚至更高但放到 Agent 的工具调用场景它就很容易导致模型发挥——输出格式漂移、参数莫名变化。我所有生产 Agent 的温度都压到 0.2 以下如果发现任务需要更多创造性比如文案生成子任务我在工具层单独开一个高温度生成工具让低温度的调度循环去调用高温度的内容生成工具两者解耦各自可控。5.3 参数怎么调一组实测数据调参数的时候不要靠感觉建议用一组小样本任务集做回归。我当时的验证方法是准备 30 个典型任务10 个简单查询、10 个多步工具调用、10 个需要知识库检索的问答改一次参数跑一遍全集记录成功率、平均步数、超时次数。用这个方法我发现了一个有意思的现象检索 TopK 从 5 调到 8 之后知识问答类任务的成功率不但没有上升反而下降了因为 TopK 太大会把相似但不相关的内容混进来模型反而被带偏。后来我把 TopK 回到 4并且把相似度阈值从 0.7 提高到 0.75准确率反而上升了近 8 个百分点。循环步数也一样。早期我设了 20 步上限任务成功率没有明显提升倒是平均 token 消耗比 10 步上限版本高了一倍多很多任务明明前 5 步就能走完模型在后面的步数里是在反复核查和来回试探。压到 12 步之后成本降了成功率反而还高了一点——因为模型知道步数有限规划的时候会更收敛、更果断。所以调参的核心思路是每种限制都有一个合理的值域不是越大越好也不是越小越好。用一套小任务集反复测让数据替你说话。6. 踩坑排查Agent 上线的五个高频问题6.1 问题速查表把我在一线遇到的高频问题整理成一张速查表你现在可能用不到但踩坑的时候翻出来对照能少花半天时间排查。现象根因排查路径解决经验循环不终止反复执行相似动作观察结果没有给模型带来增量信息查看轨迹中连续三轮观察的相似度增加连续相似度检测超过阈值强制终止工具调用的 JSON 格式频繁解析失败温度过高或工具 Schema 描述含糊检查模型温度与工具字段描述压温度重写参数描述增加解析容错上下文越写越长消耗暴涨忽略上下文压缩观察结果全量拼接查看单任务 token 消耗曲线引入摘要压缩旧轮次内容替换为摘要Agent 检索到越权数据知识库未做权限过滤核查向量检索的元数据过滤条件入库时打权限标签检索时同步过滤多 Agent 协作互相等待任务依赖关系未声明查看任务调度 DAG 的依赖环引入执行计划校验检测循环依赖模型幻觉导致动作失误知识检索不充分或指令边界不清查看动作前的上下文是否足以支撑决策在系统指令里加重无依据不动作约束高危动作人工复核这六个问题里最常见也最难察觉的是第三个上下文膨胀。它不像报错那么明显但会一点一点拖慢系统、抬高成本最后等到某一天突然超时你才意识到问题已经积累很久了。建议从第一天起就在 trace 里记录每轮调用的 token 消耗周期性地检查有没有异常增长曲线。6.2 一条典型故障的完整排查过程挑一个我印象最深的案例展开说说。当时某业务线的 Agent 频繁出现任务超时用户投诉说问一个问题要等三分钟还没结果。我拉出 Trace 一看任务本身只规划了 6 步但总耗时异常长。逐环拆解后发现在第三步Agent 调用了一个查询客户合同的工具这个工具因为下游系统限流单次耗时 8 秒Agent 在等待中产生了困惑连续重试了四次同一个动作而每次重试都重新走一遍完整的工具调用链路累计耗时直接爆表。根因不是模型的问题而是工具层的重试策略缺失工具在失败后没有返回明确的系统繁忙请稍后重试语义而是返回了一个模棱两可的空结果模型把这个空结果理解成搜索范围不对于是换了关键词重新搜索越陷越深。当时的修复做了三件事。第一给工具适配器加了统一的降级语义——下游超时或限流时直接返回标准化的资源繁忙状态码并且附带建议间隔时间。第二限制单个工具在单个任务内的最大调用次数超过就强制换方案不让 Agent 在同一个工具上死循环。第三循环层增加观察结果分类标签把执行成功执行失败资源繁忙三类结果分门别类模型和程序都能一目了然。修完之后同一批任务的超时率从 23% 降到了 3% 以内。这件事也再次印证了我的一个观点Agent 的稳定性问题绝大多数不是模型笨而是工具层和循环层的工程防护没做到位。回头再看整个架构现在我评估一套 Agent 系统能不能上生产早就不是看它的准确率高不高而是先把五组件问一遍规划有没有边界、记忆有没有权限、工具有没有规约、执行有没有校验、治理有没有审计。五组件齐全再考察 ReAct 循环有没有收敛兜底底座是不是私有可控。这三点过关Agent 才真正从能做这件事走向能持续稳定地把这件事做下去。这套判断标准是我踩了无数坑之后沉淀下来的分享出来希望能帮你少走几段我走过的弯路。
