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

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

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

python

def agent_loop(task, tools, max_steps=20): context = init_context(task) for step in range(max_steps): action = llm_decide(context, tools) # 模型决定下一步 if action.type == "finish": return action.answer result = execute_tool(action) # 执行工具 context = update_context(context, action, result) raise StepLimitExceeded() # 兜底，防止无限循环

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

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

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

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

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

python

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

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

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

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

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

python

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

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

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

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

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

python

def agent_loop(task, tools, max_steps=20): context = init_context(task) consecutive_failures = 0 for step in range(max_steps): action = llm_decide(context, tools) if action.type == "finish": if verify(action.answer, context): # 收尾前做一致性校验 return action.answer context = add_hint(context, "结论与中间数据不符，请复核") continue result = execute_tool(action) context = update_context(context, action, result) # 连续失败说明陷在死循环里，主动跳出策略 consecutive_failures = consecutive_failures + 1 if not result.success else 0 if consecutive_failures >= 3: context = escalate(context) # 换策略 / 拆解任务 / 转人工 consecutive_failures = 0 return fallback(context) # 触顶不是崩溃，要有兜底产物

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

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

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

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

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

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

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

至于上文反复提到的控制循环、上下文压缩、重试与追踪，这类成熟平台一般也会下沉到框架层，开发者不必每个 Agent 都手写一遍。但要强调