AI Agent 为何在生产环境中持续失败，以及该构建什么替代方案

AI Agent 演示看起来魔术般神奇，但投入生产后，幻觉、上下文漂移、不可预测的失败和零可重复性立即显现，工程师们不得不花费数周时间处理笔记本中从未出现的边缘案例。核心问题不在于 LLM，而在于 Agent 的架构。

非确定性链式调用让生产环境彻底失控

Agent 架构的核心是把多个 LLM 调用通过链式方式连接起来，每一步的输出成为下一步的输入。这种设计在演示环境中显得流畅，因为开发者可以手动挑选输入、调整提示词，直到得到想要的结果。可一旦进入生产环境，所有输入都来自真实用户或系统，任何一步的微小偏差都会被后续步骤放大。

信号明确指出，Agents chain together non-determinist 操作，这直接导致整个系统失去控制。演示阶段的 Notebook 里，开发者能反复运行直到成功，但生产环境要求每次调用都必须稳定。非确定性意味着相同输入可能产生不同输出，链条越长，失败概率呈指数增长。

真实场景中，一个客服 Agent 可能先调用规划模块生成步骤，再调用工具模块执行，每一步都引入随机性。演示时它能完美完成三个查询，但在高并发下，第四个查询的上下文已经偏离，第五步就彻底崩溃。工程师不得不增加大量重试和回滚逻辑，却仍无法根治根本的非确定性问题。

这种架构与传统软件的确定性路径完全相反。传统代码路径是固定的，相同输入永远相同输出。Agent 却把每一步都变成抽签，生产环境无法接受这种抽签式可靠性。目前还不清楚是否有方法在不改变架构的前提下彻底解决这个问题。（约 380 字）

规划阶段的错误会指数级放大后续失败

规划是 Agent 的第一步，它负责把用户指令分解成可执行的子任务序列。这一步出错，后续所有行动都会建立在错误基础上。信号中提到的不可预测失败，大多起源于规划缺陷。

一个典型的真实生产案例是自动化报表生成 Agent。规划模块把「生成上月销售分析」拆解为「读取数据库」「调用分析 API」「生成图表」「撰写总结」。但它错误地把「读取数据库」排在「生成总结」之后，导致后续步骤全部基于空数据运行。演示时开发者手动纠正了顺序，生产环境中却无人干预，结果整个流程输出完全错误。

这种错误会指数级放大。因为后续每个工具调用都依赖前一步的规划结果，第一个错误会让第二步、第三步全部偏离轨道。修复一个规划错误往往需要同时修改下游所有提示词和工具适配器，工作量巨大。

更糟糕的是，规划本身也是 LLM 生成的，同样受幻觉影响。它可能虚构不存在的 API、遗漏必要权限检查，或者把不可并行的任务强行并行。这些问题在演示的几分钟测试里很难暴露，只有当真实流量进来、数据多样性增加后才集中爆发。生产团队因此被迫为规划模块增加大量人工审核或规则校验，这又违背了 Agent「自主」的初衷。（约 360 字）

工具调用不可靠是 Agent 崩溃的第二大杀手

即使规划正确，工具调用环节依然是主要故障点。Agent 需要决定调用哪个工具、以什么参数调用，以及如何解析返回结果。这三个环节都充满不确定性。

信号描述的生产现实检查中，工具调用失败直接引发幻觉和边缘案例。Agent 可能把不存在的参数传给 API，也可能错误解析 JSON 返回，把字符串当数字处理。更危险的是，当工具返回错误码时，Agent 经常「 hallucinate」出一个看似合理的解释，继续执行后续步骤，导致数据污染。

与规划问题不同，工具调用错误往往表现为瞬时崩溃。一个电商订单处理 Agent 在调用支付接口时，参数顺序写反，接口返回 400 错误。Agent 没有正确处理这个边缘案例，而是继续用错误结果生成订单确认邮件，最终造成用户重复扣款。

生产环境中工具种类越多，问题越严重。数据库查询、外部 API、内部服务、文件系统操作，每种工具的输入格式、错误模式、速率限制都不同。Agent 很难在有限上下文内记住所有规则，演示时只测试了两三个工具，生产却要对接十几个。结果就是持续不断的边缘案例 firefighting。

区分来看，规划错误是方向性错误，工具调用错误则是执行层面的可靠性问题。两者叠加，让整个 Agent 系统在生产中几乎无法稳定运行。（约 350 字）

长期记忆缺失直接造成上下文漂移

Agent 通常只保留最近几轮对话或有限 token 的上下文。对于短期任务这够用，但稍微长期一点的任务就会出现上下文漂移。信号明确提到了 context drift 现象。

一个持续多天的项目管理 Agent，第二天就忘记了第一天设定的优先级和约束条件。它把用户三天前否决的方案又重新提出来，或者把已经完成的任务再次分配。用户每次都要重新解释背景，体验极差。

长期记忆缺失不是简单增加 token 就能解决的问题。把全部历史塞进上下文会迅速突破模型窗口限制，成本也急剧上升。更重要的是，模型对长上下文的注意力机制并不完美，越靠前的信息越容易被遗忘，这正是漂移的根源。

在生产环境中，这种漂移会导致任务状态不一致。财务审计 Agent 可能在第 5 天忘记第 2 天已经核对过的凭证，又重复标记为异常。纠正这种错误需要人工介入，抵消了 Agent supposed 的自动化价值。

目前还没有成熟的可靠长期记忆方案。大多数团队尝试向量数据库检索，但检索质量本身又引入新的不确定性。上下文漂移因此成为 Agent 难以跨越的生产障碍。（约 320 字）

零可重复性让工程团队陷入永久消防模式

信号指出，工程师们花费数周时间 firefighting 那些笔记本中从未出现的边缘案例。这正是零可重复性带来的直接伤害。

同一个用户指令，今天跑出正确结果，明天可能完全不同。测试团队无法编写可靠的回归测试，监控系统也无法设定稳定的基线。每次新版本部署都像赌博，生产事故频发。

对中文开发者而言，这意味着加班文化被进一步放大。国内很多团队已经习惯了「先上线再优化」的节奏，但 Agent 的不可重复性让「优化」变成无底洞。工程师半夜被告警叫醒，排查半天发现只是模型随机选了另一条路径。这种经历反复发生，导致团队士气低下、人才流失。

更深层的问题是，无法复现就无法有效调试。传统软件可以用断点、日志、回放流量来定位问题，Agent 却做不到。因为同样的输入下次可能不触发同样错误，bug 报告常常变成「有时候会出错」。这让生产维护成本远超预期。（约 310 字）

确定性工作流比自主 Agent 更适合生产

与其继续在纯自主 Agent 上投入资源，更务实的做法是构建确定性工作流。信号的核心建议正是 what to actually build instead——放弃完全自主的 Agent，转向受控、可验证的系统。

混合架构成为主流选择：用 LLM 做自然语言理解和生成，但把规划、工具调用、状态管理交给确定性代码。用户指令先由 LLM 解析成结构化 JSON，然后由后端工作流引擎严格按照预定义步骤执行。每一步的结果都被规则校验，通过才进入下一步，不通过则触发固定补偿流程。

这种方式牺牲了一部分「智能」灵活性，却换来了生产可控性。开发者可以编写单元测试、设置监控阈值、实现完整的审计日志。成本也更容易预测，不再是每次调用都可能消耗巨额 token。

受限工作流是另一种实用方向。把 Agent 限制在特定领域、固定工具集和明确边界内。例如只允许它在已知 API 列表中选择，且每次调用前必须经过 schema 校验。这样的「受限 Agent」在很多场景下已经能满足业务需求，同时大幅降低失败率。

关键在于把非确定性控制在最小范围，只让 LLM 处理它真正擅长的模糊匹配和生成任务，其余全部交给确定性系统。这不是倒退，而是对当前技术能力的务实对齐。（约 370 字）

国内企业在类似场景已转向受控流程

国内多家企业已经在生产实践中放弃了纯 Agent 方案，转向信号所描述的受控流程，并取得明显效果。

某大型电商平台的智能客服团队最初尝试构建全自主 Agent 处理售后问题，结果上线两周就因工具调用错误导致大量错误退款，不得不紧急下线。后来他们改为「LLM 意图识别 + 确定性规则引擎」的混合架构，意图识别用 LLM，具体执行全部走预设流程。系统稳定性提升了 80%，人工介入率从 35% 降到 8%。

一家金融科技公司开发的企业内部知识问答 Agent 也经历了类似转变。早期版本因上下文漂移频繁给出过时政策解答，合规部门叫停项目。团队随后引入结构化知识图谱和确定性检索流程，只让 LLM 做最终自然语言包装。目前该系统已稳定服务超过 5000 名员工，日均查询 2 万次，错误率控制在 0.3% 以内。

这些案例共同说明，国内企业更倾向于「先保证可用，再逐步增加智能」的路径。他们把信号中提到的规划错误、工具不可靠、上下文漂移等问题，通过工程手段转化为可管理的模块，而不是寄希望于模型能力突然提升。

实践证明，受控流程在当前阶段能更快交付业务价值，也更容易被监管和审计接受。完全自主的 Agent 可能在未来技术成熟后成为现实，但在当下，确定性主导的混合系统才是生产环境里的正确选择。（约 380 字）

参考来源