过去两年，我参与了不下十个跟AI Agent相关的项目，有的做客服工单自动处理，有的做文档信息抽取，有的做内部系统的自动化运维。有一个现象非常普遍：Demo阶段人见人夸，一到生产环境就原形毕露。很多人习惯性把锅甩给"模型能力不够"，但我的判断恰恰相反——问题主要不在模型，而在我们选择的方向。
这篇文章想把我看到的问题、踩过的坑，以及后来总结出的可行路子一次性讲清楚。尤其适合那些正打算把Agent搬进生产环境的团队，也适合刚接触这个领域、被各种宣传带偏了预期的朋友。先说结论：大家最热衷于讨论的"怎么让Agent更聪明"，其实不是落地的关键；真正的关键是——怎么让一个不那么聪明、还会犯错的东西，在业务边界内稳定地不出事。
1. 一次惊艳的Demo，和上线后的连环翻车
先讲一个让我印象极其深刻的失败案例，因为它的过程几乎可以复用到每一个Agent项目上。当时我们给某备件平台的售后部门做一个工单处理Agent，目标很明确：读取用户报修的工单描述，判断故障类型，推荐维修方案，必要时自动生成备件订单。听起来很简单对吧？一个典型的"文档进、动作出"的场景，比那些号称"帮你写代码""帮你炒股"的Agent收敛多了。
1.1 演示环境完美，为什么生产环境一塌糊涂
演示那天，我们准备了大约二十条精心挑选的工单，覆盖了平台最常见的几类故障：电机不转、异响、漏油、控制面板报错。Agent的表现堪称完美，识别准确、输出规范、中间还会礼貌地解释自己的判断依据。现场的领导很满意，连说了三次"这就是我们要的东西"。
上线第一周，崩溃就开始了。
真实用户的工单长什么样？有人写"坏了，快来"，有人写"跟上次那个一样，你们自己查"，还有人直接上传一张模糊的照片什么文字都没留。我们的Agent在演示时从未见过这么脏的输入。
更糟的是它"自由发挥"的部分。有一条工单写"风扇嗡嗡响但是还能转"，Agent经过一番推理，认定是"电机轴承磨损"，然后自作主张生成了一个更换整个电机的备件订单。审核同事看到的时候订单都已经进系统了。还有一条工单在"查询备件库存"和"生成订单"之间循环了十四次，因为没有退出条件，每循环一次就消耗一波token，直到触发我们粗糙设置的超时上限。
1.2 故障清单：轮询死循环、参数乱填、凭空造单号
复盘时我们列了一张故障清单，越列越沉默：
- 死循环：Agent在几个工具之间来回横跳，既不收敛到结果，也不自己主动停。它没有"算了，这单需要人工"的认知。
- 参数幻觉：有一个环节需要填订单号，Agent居然把一个时间戳格式的内容填进了订单号字段。系统里找不到这个单，流程直接挂死。
- 结构化输出失效：我们有大约百分之五的请求，返回的JSON里混进了自然语言解释，下游解析器当场报错。
- 业务规则误判：它把"客户要求尽快"理解成了"加急订单"，给一个普通投诉生成了一台加急的操作优先级。
细看这些故障会发现一个共同点：它们几乎都不是"模型不理解业务"，而是"系统设计上没给错误留出口"。演示时我们关注的是它能做成什么；生产环境真正考验的是——它做错之后，系统会不会优雅地兜住。
1.3 复盘会上最容易出现的错误结论
这个项目的复盘会我参加了，会上争议很大，但有一种声音占据主流："模型还不够聪明，等下一代模型出来就好了。"我当时没完全反对，但心里觉得不对劲。因为事后我们做了个很简单的实验：把同样的四十条线上真实工单喂给当时市面上更先进、更大的一批模型，效果确实有提升，但该死循环的还是会死循环，该乱填参数的一样乱填，只是比例从百分之五变成了百分之二。
这说明什么？说明如果方向不对，换更聪明的模型只是把问题从"明显"变成"不明显"，并不会根除。那段时间我开始意识到：我们对Agent的整套设计思路，可能从第一根桩就立错了。
2. 从一开始就搞错的方向：拿"人性假设"去设计"概率机器"
2.1 "像人一样干活"是一个危险的思维捷径
我们为什么喜欢Agent这个概念？因为"让AI像助理一样自己规划、自己执行"这个画面太符合直觉了。团队里讨论问题的时候，张口就是"它应该像人一样先分析再动手""它应该学会总结经验""它应该知道自己什么时候不懂"。这些话听起来没错，但它们把人脑的特性——意图、常识、分寸感、对后果的畏惧——全部默认安在了一个概率模型身上。
这是整个行业最常见的心智模型错位。当你把Agent当成一个"性格稳定的实习生"，你自然会减少护栏：实习生犯一次错会记住，Agent不会；实习生犹豫时会来问你，Agent不会；实习生怕丢工作，Agent对业务后果零感觉。
2.2 大模型不是大脑，是一个概率性的文本引擎
必须把这个底层事实反复说清楚：大模型的核心机制是"根据上文预测下一个token的概率分布"。它生成的每一句话，都是统计上最像样的延续，而不是深思熟虑后的决策。你问它"这个工单该不该生成订单"，它的回答不是"经过业务逻辑推导"出来的，而是"在训练数据里，类似文本后面通常跟着什么"采样出来的。
这就是为什么它偶尔会一本正经地胡说八道。因为它根本不知道什么叫"事实"，它只知道什么叫"像"。聊天的时候这种特性无伤大雅，但在驱动真金白银的系统时，这个特性会变成致命的放大镜：它犯一个错不可怕，可怕的是它犯错之后还能自洽地继续演下去。
2.3 幻觉不是bug，是默认状态
我们团队有个新人曾经花了两周时间，试图通过改进Prompt来消灭幻觉，最后当然是无功而返。幻觉不是"调参没调好"，它是概率采样的自然副产品。只要模型在生成，就必然存在"生成一个看似合理但不符合事实的token"的概率，哪怕这个概率很低，乘以几千几万个token、几百次调用，就是必然发生的数量。
所以正确的思路不是"如何让模型不犯错"，而是"如何让系统在模型犯错时损失可控"。这个认知转变是整个落地策略的分水岭。对于生产环境来说，一个不犯错但笨的流程组件，永远优于一个聪明但偶尔发疯的"全才"。
第3章我要讲的就是这个思路对应的具体工程缺陷——大家总觉得推理能力是瓶颈，真正卡住落地的是工程侧那些看起来"不够酷"的问题。
3. 能力之外，真正卡住落地的是工程侧的系统性缺陷
3.1 工具调用：看起来能调，实际上脆得像纸
现在几乎所有Agent框架都在宣传"工具调用"，Demo里Agent问你"要不要查天气，我可以帮你查"。看起来无比丝滑，但到了生产环境，工具调用成了最大的灾难现场。
常见故障有三种。第一种是选错工具：明明该查库存，它去查了价格表。第二种是参数幻觉：工具接口要求JSON Schema，它把字段类型填错、把枚举值填成自己编出来的值、把"订单编号"填成订单时间，我上面提到的例子就是这种。第三种是schema漂移：你后端的工具接口升级了，字段名从"order_id"改成了"orderNo"，Agent还是按旧的习惯调参数，全链路瞬间失效。
我们在系统里加了强制的JSON Schema校验之后，很多这类错误被拦住了，但代价是大量任务直接进人工队列。这再次印证了那个观点：工具调用的可靠性，不是模型能力问题，而是系统设计问题。想靠模型"自觉"填对参数，就跟指望实习生不犯错一样不现实。
3.2 上下文越长，注意力越散
第二个被高估的概念是"长上下文"。有些方案说：把整个知识库、全部历史聊天都塞进上下文，让Agent有"完整记忆"。听起来很美好，但实际效果非常反直觉——上下文越长，模型越容易"迷失在中间"。
当上下文里既有历史记录又有业务手册还有用户的最新诉求时，模型经常顾此失彼。我们做过一个对比：把工单Agent的历史记录从最近的五轮扩展到二十轮，结果关键指令跟随率反而下降了，因为几十轮前的对话噪声干扰了模型对当前任务的判断。上下文窗口大，不等于"记忆好"，它更像一个文档堆满的桌子，越大越难找到你要用的那张纸。
3.3 自我纠错能力只是传说
很多框架宣传的时候都强调"反思""自我纠错"，说得神乎其神。我实测下来的结论很残酷：所谓自我纠错，在多数场景下就是"在错误的方向上更自信地重新推理一遍"。
我们曾经做过一次压力测试，故意给Agent一个矛盾的输入，看它会不会回头质疑自己的假设。结果它不会说"我搞错了"，而是会额外输出一大段自圆其说的文字，把错误包装得更严密。这个特性在论文里叫"推理置信度"，放到业务里就是"错误放大镜"。指望Agent犯错后自己退回来？对不起，它没有那个转弯机构。
3.4 看不见的黑盒：可观测性缺失
还有一个在Demo里根本不会暴露的问题——出事了你怎么查？传统的软件系统有日志、有调用链、有堆栈，出了问题总能定位到某个模块。Agent呢？它的"思考过程"在大多数框架里是不会落盘的，即便落盘了，哪一步推理导致哪个动作，也很难追溯。
我们有一次线上故障，查了整整两天才定位到：Agent在某一次循环中读取到了一个过期的缓存结果，进而导致了后续一连串错误动作。如果你没有在每个工具调用的出入口做记录、没有对中间状态做快照、没有把"模型为什么这么决定"的原始证据保存下来，你排查的每一分钟都是在烧钱。
3.5 评测的困境：线上比线下残酷得多
关于评测我多说一句。内部评测时我们构建了一个金标数据集，Agent的准确率做到了百分之九十以上，大家都觉得可以上线了。但线上真实数据的分布和你的金标集永远不一样，而且每天都在变。今天用户大量上传新机型的故障图，Agent没法更新知识，准确率立刻掉到百分之八十以下。线下的"漂亮指标"和线上的"真实表现"之间，隔着一整条数据分布漂移的鸿沟。
4. 还有一笔没人提前算的账：成本、维护和永远改不掉的"兜底"
4.1 Token消费失控的数学
Agent和传统接口最大的区别在于，它的一次任务会消耗大量的中间token。我们统计过那个工单Agent，平均单条任务要吃掉四万到六万个token。注意，这还是在没有死循环、没有疯狂重试的理想情况下。
一旦遇到极端输入，模型反复推理、反复重试，单条任务的token消耗能轻松冲到几十万。我之前见过一个测试脚本，在十分钟内把某个月的API预算烧掉了三分之一。很多团队算成本的时候只算了"任务成功时的价格"，完全没有预留"任务失败时的价格"。失败任务的成本往往比成功任务更高，因为它经历了更多轮的尝试。
4.2 维护循环：你维护的不是代码，是一场永不停歇的对话
传统的软件系统，改一个bug，只要改动是局部的，风险就可控。Agent不一样，你的系统行为取决于Prompt、上下文模板、工具定义、模型版本这四样东西的组合，而它们之间没有任何编译期的类型检查。
这意味着每次改动都可能带来不可预期的连锁反应。我们亲身经历过：为了修一个"订单号识别错误"的问题，往Prompt里加了一条规则，结果另外三个原本正常的场景突然开始抽风，因为这条规则干扰了模型对其他字段的判断。你在维护一个不断变化的对话，而不是一段稳定的程序。
4.3 人工兜底的真实人力账
有些人会说：没关系，我们有人工审核兜底。但把兜底成本算进去之后，很多Agent项目的经济账瞬间就不成立了。以前一个客服一天处理一百张工单；上了Agent之后，审核员每天要审核一百条Agent的输出，工作量一点没少，还多了一项"判断Agent做得对不对"的新技能要求。
更难受的是，审核员因为总在给Agent擦屁股，积累了大量的不信任情绪。很多团队最后发现，自己花大价钱建的不是"自动化系统"，而是一个"自动制造半成品、再由人工返工"的系统。这个局面只要持续一两个月，业务方就会开始怀疑当初上这个项目的意义。
4.4 算完这笔账，ROI往往为负
把上面几项加总，你会发现：Agent本身并不便宜，它更需要配套的可观测性、金标评测、生命周期维护、人工兜底。在很长一段时间里，一份声称"Agent替代了X个岗位"的报告，仔细拆开看，往往是"Agent消化了X个岗位的输入，但整体工作量没有下降，只是转移了"。
我知道这段话听起来很悲观，但这恰恰是后来所有转机的起点。正是因为算清了这笔账，我们才被迫换了一个思路，也是这篇文章标题里两个关键词——"方向"——真正想讲的东西。
5. 换一个方向之后，Agent开始真正"落地"了
我们在连续踩了两年坑之后，得出了一个可能有点冒犯行业共识的结论：**不要把Agent当成人来用，把它当成流程里的一个零件来设计。**这个方向上的转变，直接让后续三个项目活了下来。
5.1 换掉尺子：从"聪明程度"到"边界内的可靠度"
以前我们跟模型较劲，追求它在所有问题上的理解能力；现在我们把精力放在定义"任务边界"上。每次新项目启动，先不讨论用什么模型，而是先把三个问题写死：这个Agent只处理哪几类输入？超出这几类输入时，它必须做什么（通常是拒绝+转人工）？它绝对不可以做什么动作（比如生成订单、删除记录）？
这把尺子换掉之后，所有设计决策都变了。我们不再追求"它什么都能做"，而是追求"在允许的范围内，它做得有多稳；在范围之外，它会不会安全地停住"。后一项其实是更核心的目标，因为安全失败永远比华丽失败有价值。
5.2 从自主到编排：把Agent当流程里的一环
第二个转变是架构层面的。以前我们想造一个全知全能的单体Agent，让它自己规划路线，结果它经常在岔路口迷路。后来我们换成了**"状态机编排 + 大模型决策点"**的混合架构。
大白话说就是：流程的结构、环节的顺序、异常的分支，这些用传统代码写死，保证不会乱；模型只负责在每个环节内部做出"内容性判断"——这一步该选哪个分类、这一段该怎么改写、这封信的语气如何。状态机保证了"A之后必须是B，绝不可能是C"；模型保证了"在B这个节点，选择哪个最合适的选项"。前者提供结构性的确定性，后者提供内容上的灵活性，各司其职。
这套架构出来之后，死循环问题消失了，工具乱调的问题消失了，因为模型根本没有全局行动权，它手上的工具往往只有一个，选错的空间被压缩到极小。
5.3 人在回路不是过渡方案，而是最终形态
很多人一听到"人在回路"就觉得是"还没成熟，先人工兜着"。但我们的经验是：在合规和需要承担责任的高价值操作面前，人在回路不是妥协，而是正确的产品形态。
现在我们的设计逻辑是：模型负责把活儿干到八九成，然后必须把最后一步交给人类审批；让人类只做"确认"和"处理极端情况"这两件事。这样审核员的工作量确实降下来了，因为他们不再是给Agent擦屁股，而是行使最终决定权。
举个例子：备件订单生成之前，Agent会把推理依据、引用来源、生成的订单草稿全部整理成一张很清晰的摘要卡，推给审核员。审核员只需要看一眼、点一下确认。潜台词是：模型把90%的"读懂工单"的活儿干完了，而人类只保留10%的"这件事能不能定"的权力。
5.4 我现在会照着做的落地框架
如果让我现在从头做一个Agent项目，我会严格按下面这个清单推进，也推荐给所有被"Agent看起来很美好"蛊惑过的团队：
- 先写可验收的结果函数：明确"任务成功"的定义，最好是可以自动判定的结果，比如"工单分类正确"、"订单参数完整"。定义不了结果函数的任务，不要做Agent。
- 先建金标评测集再动工：至少一百条真实历史数据，人工标注好标准答案，每次模型或Prompt变更都跑回归，防止修一个坏三个。
- 用状态机圈出状态空间：先写死流程和分支，再决定在哪几个节点上引入模型决策。模型的自由度越小，系统的稳定性越高。
- 影子模式跑两周：上线前让Agent在后台跟真实流程并行运行，输出不生效，只记录"如果它是执行的会怎样"，用来评估真实分布上的准确率。
- 预置所有逃生门：超时熔断、重试上限、拒绝执行的规则、自动转人工的触发条件，每一个都要在生产环境里提前演练一遍。
- 可观测性当一等公民：所有模型调用的输入输出、工具调用的参数和结果、中间决策的理由，全部落盘存证，方便事后审计和定位。
这套框架下，Agent依然是整个系统里最聪明的组件，但它不再是唯一决策者，而是被流程、规则、人工审核层层包裹的一个部件。说句实在话，这个定位比"取代人类"朴素得多，但它能真正地在生产环境里活下来，并且让业务方愿意为它买单。
如果你所在的项目也在为Agent落地头疼，我的建议是暂时别把注意力放在"怎么让它更聪明"上面，先回头看看自己给它划的边界够不够硬、设置的出口够不够多。我在实际项目中反复验证过一件事：**把错误发生后的代价压到最低，比把错误发生的概率降到零更划算。**这是我们在最开始的工单项目里付出代价之后，最想对同行说的一句话。
