有没有大佬分享一下做 Agent 的经验？

做Agent最容易踩的坑：Demo能跑，生产就崩

做过Agent的人大概都有过这种经历：演示的时候一切正常，上了生产就开始出各种诡异的问题。工具调用失灵、检索结果跑偏、对话越到后面越离谱、出了问题没人知道、最后成本还炸了。

很多人把这归结为"调试不够"或者"模型不够强"。但做了几个Agent项目之后我越来越觉得，这不是调试的问题。Demo和生产之间存在一条结构性的裂缝，而大多数团队是在Demo阶段就把这块裂缝埋下了。

下面这条因果链，是我在实际项目中反复踩坑之后总结出来的。五个环节不是五个独立的问题，而是同一个根源的递进症状——前一环的果是下一环的因。

Demo阶段看起来知识完备，其实是因为开发者在背后补全了所有缺口。检索不到的文档，手动塞进prompt；格式不对的，临时写个转换；边界情况，直接硬编码。用户看不到这些补丁，只看到流畅的输出——于是产生了一种错觉：系统已经完备了。

生产阶段的现实是：企业真正关键的知识散落在运行规程里、调度员脑子里、供电所档案柜里，不在互联网上。模型训练数据对这类专业领域的覆盖度极低。RAG检索到的往往是"相关但不准确"的内容，而模型的输出足够流畅，让人误以为检索到了正确知识。

这里面有个反直觉的现象：模型越强大，错误的伪装越完美。 一个实习生写错了你能看出来，GPT-5写出来的错误方案你看不到问题——语言流畅、术语准确、步骤清晰，只是关键参数错了。RAG检索到"相关文档"不等于检索到"正确知识"，但输出的流畅性掩盖了这个差距。

这是第一个裂缝：系统看起来在工作，实际上已经在某些地方失败了，只是没人发现。

Demo阶段，没人期待Agent评估自己的输出质量——错了人改就行。Agent只需要输出结果，不需要判断"我对这个结果有多大把握"。

生产阶段恰恰相反。Agent最需要能力的地方，是知道自己的知识边界在哪。"我知道自己什么时候不知道"这件事，是Agent的核心属性，没办法外置成一个工具或者插件——你可以把评估规则做成可加载的模块，但那个"我应该评估一下"的意识本身必须内建在Agent里。

问题在于，LLM在它训练数据最稀疏的领域表现最差。在通用场景下，模型能力已经够用；真正出问题的是那些长尾专业领域。Demo阶段这些领域被精心挑选过了，Agent不会碰到知识边界。生产阶段用户会问任何他们想问的问题，Agent在知识边界处犯最严重的错误，同时完全不知道自己已经越界。

这是第二个裂缝：Agent不仅在犯错，而且不知道自己正在犯错。每一轮交互都在错误的基础上叠加。

Demo阶段对话短、任务简单，三五轮就结束了，Context Window里的内容都是有效的，感知不到资源压力。

生产阶段的任务是复杂的、长链路的，动辄几十轮交互，调用多个工具，处理各种异常。当错误的工具调用、不准确的检索结果、失败的执行记录逐渐累积，有效信号就被噪声淹没了。Context Window是所有Agent环节共享的资源，一旦被污染，后续所有决策的输入质量都在下降。

这里有个关键机制：自由度与任务脆弱性必须匹配。 高自由度任务需要更多约束来保证可靠性，但Demo阶段给了Agent最大的自由度——因为任务简单、容错高，不需要约束。到了生产阶段，任务复杂度上来了，Agent却在用Demo阶段继承的自由度运行，没有任何约束机制来防止上下文进一步恶化。

上下文崩溃不是一次性发生的——是一个渐进的退化过程。前几轮还正常，中间开始出错，后面越来越离谱。不是模型突然变差了，是模型的输入已经变质了。

这是第三个裂缝：错误的执行记录污染了Agent的"记忆"，后续所有决策都基于一个已经失真的上下文。

在安全关键领域——比如电力调度——AI的推理结果必须经过潮流计算、稳定校核等物理验证，不能直接执行。这是一条硬约束。

但大多数通用Agent系统的输出就是最终结果，后面没有校验层。Demo阶段有开发者盯着屏幕，发现问题即时修正——人就是那个校验层。生产阶段没有这个人在回路里，错误就在系统内部静默传播。

更深层的问题是：Demo阶段往往根本没有设计校验层，因为不需要——有开发者兜底就够了。到了生产阶段需要校验层的时候，发现架构里没有这个位置。这不是加一个检查模块就能解决的，是架构层面的缺失。

这是第四个裂缝：错误发生了，但没有机制捕获它。

前四个环节叠加，产生连锁反应：

错误的检索 → 错误的判断 → 错误的执行 → 错误的执行记录污染上下文 → 下一轮更严重的错误 → 需要重试 → 重试消耗更多Token → 重试过程本身又产生更多错误上下文 → 恶性循环。

每次重试不只是消耗Token，还在生成新的上下文，而这些上下文里包含了错误的推理过程，进一步恶化后续决策的质量。失败的概率随着重试次数上升，而不是下降。

Demo阶段一次失败就重置，成本趋近于零。生产阶段的连锁失败是滚雪球式的。等到成本超支被发现的时候，问题已经不是单个环节的错误，而是整条链条失控了。

回头看这五个环节，根源在于Demo阶段和生产阶段之间存在三个结构性差异：

期望差异。 Demo允许出错，人工兜底，用户期望低。生产零容错，没有人在回路里，用户对可靠性的要求是刚性的。

范围差异。 Demo只需要跑通核心路径。生产需要同时考虑可靠、稳定、易用、可维护——这些维度的要求往往和Demo阶段的设计选择直接冲突。

设计冲突。 Demo选择开放对话让Agent自由交互，但生产需要规则隔离防止错误相互污染。Demo选择跳过知识梳理直接接RAG快速上线，但生产需要系统性的知识工程。Demo把Context当临时资源随便用，但生产里Context是稀缺的共享资源需要精细管理。

这些冲突的本质是：Demo的设计选择是为"快"优化的，生产的要求是为"稳"优化的。为快做的每一个妥协，到了生产环境都变成了结构性债务。

解决路径不是"Demo做完再改"——而是从一开始就用生产思维设计。设底线，不设上限。先确保在异常情况下系统不崩溃，再追求在正常情况下的效率提升。

更多AI Agent实战经验，在我的公众号「SG AI实验室」，专注AI技术应用的一手记录。