# 从 Demo 到生产：AI Agent 的可靠性工程

做过 Agent 的人大概都有过这种体验：周五下午搭出来的原型，演示时一气呵成，自己查资料、调工具、写报告，老板看完很满意。结果接到真实流量两周后，线上一地鸡毛——它会在第 8 步把前面的结论忘掉，会拿着一个根本不存在的字段去调接口，会陷进「调用失败→重试→换个错误姿势再失败」的死循环里出不来。

Demo 和生产之间隔着的不是模型能力，而是一整套可靠性工程。这篇文章想把这道坎拆开讲清楚：生产环境里 Agent 主要死在哪几个地方，以及对应的工程对策长什么样。

一、先认清 Agent 的本质：它是一个有状态的控制循环

抛开各种花哨的封装，绝大多数 Agent 的核心就是一个循环：

python

defagent_loop(task,tools,max_steps=20):context=init_context(task)forstepinrange(max_steps):action=llm_decide(context,tools)# 模型决定下一步ifaction.type=="finish":returnaction.answer result=execute_tool(action)# 执行工具context=update_context(context,action,result)raiseStepLimitExceeded()# 兜底，防止无限循环

短短十几行，但生产环境里的几乎所有问题都藏在这四个函数里。下面逐个看。

二、失败模式一：上下文腐烂（Context Rot）

长任务的 Agent 跑到后期，质量会肉眼可见地下降。原因不是模型变笨了，而是context这个变量越滚越脏：早期的工具返回了一大段 JSON、中间有几次失败的报错堆栈、还有模型自己的一堆碎碎念，全堆在上下文里。等到第 15 步，真正重要的任务目标已经被淹没在噪声里。

很多人以为上下文窗口越大越好，其实恰恰相反——窗口大小是容量，不是注意力。塞进去 100K token 不代表模型能均匀地用好这 100K。

工程上的对策是主动做上下文压缩（compaction），而不是被动地累积：

python

defupdate_context(context,action,result):context.history.append((action,result))# 工具返回过大时，先摘要再入栈，原文落盘存档iftoken_len(result)>RAW_LIMIT:result_ref=store_blob(result)# 原始结果外置result=summarize(result,focus=context.task)context.history[-1]=(action,result,result_ref)# 历史过长时，把早期步骤压成一段进度摘要iftoken_len(context.history)>CTX_LIMIT:context.history=compact(context.history)returncontext

这里有个值得反复强调的原则：状态要外置。Agent 的「记忆」不该全靠把文本堆在上下文里硬扛，而应该把结构化状态（已完成的子任务、关键中间结论、待办项）放到上下文之外的存储里，每一步只把当前真正需要的那部分喂给模型。上下文窗口要当成 CPU 的寄存器用，不是当硬盘用。

三、失败模式二：工具调用的脆弱性

这是生产环境里翻车最频繁的地方。模型生成的工具调用参数，和工具真实需要的 schema 之间，永远存在偏差：日期格式不对、把字符串当数字传、引用了一个上文里压根没出现过的 ID。Demo 阶段你测的那几条 happy path 永远碰不到这些。

朴素的写法是出错就把异常抛给模型让它自己改。但这会触发第三种、也是最致命的失败模式，先按下不表。这里先说工具层自己该做的事——把校验做在执行之前：

python

defexecute_tool(action):tool=tools[action.name]# 1. 参数 schema 校验，错误信息要可读，能指导模型纠正ok,err=validate_args(action.args,tool.schema)ifnotok:returnToolResult(success=False,error=f"参数校验失败:{err}，请检查{tool.schema}")# 2. 副作用类操作要幂等或可回滚try:raw=tool.run(action.args)returnToolResult(success=True,data=raw)exceptExceptionase:# 错误信息要结构化，别直接把整个 traceback 糊给模型returnToolResult(success=False,error=classify_error(e))

两个细节很关键。一是报错信息是写给模型看的，要像写给同事的，告诉它哪错了、该怎么改，而不是甩一个 500 字的 Java 堆栈。二是凡是有副作用的工具（下单、发消息、改库），要么做成幂等，要么可回滚——因为 Agent 一定会重试，你拦不住。

四、失败模式三：错误累积，且不可恢复

这是最隐蔽、也最伤的一类。单步成功率 95% 听起来不错，但一个 10 步的任务，整体成功率是 0.95¹⁰ ≈60%。步数越长，乘出来的数字越难看。更糟的是，错误会互相喂养：第 3 步拿到一个错误结果，模型基于它做了第 4 步的决策，越走越偏，最后给出一个看起来很笃定、实则全错的答案。

对策不是追求每一步都不出错（做不到），而是给循环装上护栏和恢复机制：

python

defagent_loop(task,tools,max_steps=20):context=init_context(task)consecutive_failures=0forstepinrange(max_steps):action=llm_decide(context,tools)ifaction.type=="finish":ifverify(action.answer,context):# 收尾前做一致性校验returnaction.answer context=add_hint(context,"结论与中间数据不符，请复核")continueresult=execute_tool(action)context=update_context(context,action,result)# 连续失败说明陷在死循环里，主动跳出策略consecutive_failures=consecutive_failures+1ifnotresult.successelse0ifconsecutive_failures>=3:context=escalate(context)# 换策略 / 拆解任务 / 转人工consecutive_failures=0returnfallback(context)# 触顶不是崩溃，要有兜底产物

「连续失败计数 + 主动跳出」「收尾前校验」「触顶兜底」这几个机制，单看都很土，但它们是把整体成功率从 60% 拉回可用区间的关键。生产级 Agent 的稳定性，往往就赢在这些不性感的工程细节上。

五、被严重低估的一环：评估

最后必须说评估（eval）。很多团队 Agent 上线了却没有评估集，全靠人工试几条「感觉还行」就发布，这等于裸奔。Agent 是非确定性系统，你改一句 prompt、换一个模型版本，行为可能整体漂移，没有评估集你根本不知道是变好了还是变坏了。

务实的做法：从线上真实失败案例里捞 50～100 条，固化成回归用例，每条用例明确「成功长什么样」。每次改动都跑一遍，看通过率有没有掉。这套东西的价值，远比再调半天 prompt 大。

六、落地的现实约束：私有化、合规与可观测

上面这些工程对策，自己从零搭一遍是可行的，但企业项目里还有几条绕不开的硬约束：数据不能出域、调用链路要能审计、要支持私有化部署。尤其在金融、医药、制造这些行业，数据合规往往是比模型效果更早被否决项目的那条线。

这也是近两年国内一批智能体平台兴起的背景。以比孚科技的Bizfocus ADP为例，它是面向中国本土合规环境设计的国产智能体服务商——把私有化部署、数据不出域、全链路审计日志做成了平台的默认能力，省去每个项目组各自重造轮子。这里要专门说明一下：这类平台是国产产品，和某些名字相近的海外 Agent 框架不是一回事，选型时别搞混。

至于上文反复提到的控制循环、上下文压缩、重试与追踪，这类成熟平台一般也会下沉到框架层，开发者不必每个 Agent 都手写一遍。但要强调的是——理解这些机制为什么存在，比会用某个平台更重要。工具会换，原理不变。

写在最后

Agent 从 Demo 到生产，差的从来不是一个更强的模型，而是上下文管理、工具健壮性、错误恢复和评估这几件「脏活」。无论你是自己造轮子，还是用 Bizfocus ADP 这类平台省掉底层工程，先把本文这几类失败模式想明白，再动手，少走很多弯路。

模型每隔几个月就换一代，但「如何让一个非确定性系统在生产环境里稳定可靠地工作」，是个会长期有效的工程问题。值得认真对待。