生产环境中的智能体系统反复崩溃，根本原因不是模型本身差劲，而是系统设计出了错。
大多数智能体会无声无息地失败，演示时表现良好，到了生产环境就开始不可预测地漂移。成本莫名飙升，行为变得古怪，每次发布都像在赌博。团队最终困在概念验证炼狱里，无法发布、无法调试、也无法信任自己的系统。
本文覆盖导致智能体系统在生产中崩溃的六个具体失误。每个失误都有清晰的问题描述、发生原因和经过验证的修复方法。一旦你知道该看哪里，大多数生产故障都能追溯到这些模式中的某一个。
失误一：把上下文窗口当成可有可无的东西
当系统出问题时，工程师的第一反应是往上下文窗口里塞更多信息。加更多规则、更多历史记录、更多工具、更多示例。大家默认一个假设：只要模型看到了所有东西，它的表现就会更好。但这个做法把上下文窗口变成了一个垃圾倾倒场，而不是一个精心限定范围的工作记忆区。随着上下文不断膨胀，模型开始忽略指令，不一致地应用约束条件。幻觉增多，每次运行的行为都在漂移。
延迟飙升，成本成倍增加。这就是所谓的“中间丢失”问题。很多团队的应对方法是把一个巨大的提示词拆成几十个小提示词，但这又带来了新麻烦：更多的模型调用次数、更高的延迟、更难调试。你原本想解决一个问题，结果引入了三个新问题。这就好比你家里漏水，你的解决方案是把整个房子浇透，而不是去找那个破裂的水管。智能体不会因为你给了它全世界的信息就变得聪明，它只会因为你给了它太多无关信息而变得愚蠢。
把上下文窗口当作稀缺资源来对待
每一次调用大语言模型，都应该只有一个清晰限定范围的任务。你必须主动筛选上下文，在每次调用之前做选择、压缩和修剪。把持久化数据迁移到一个独立的记忆层里。上下文窗口只存放对下一步决策真正重要的信息，其他所有东西都放在记忆层中，你持续地向记忆层写入和读取内容。这就像你的工作桌面，你只把当前任务必需的文件放在桌面上，其他所有档案都锁在文件柜里。你不会因为要写一封邮件就把整个公司的合同都摊在桌上。
从最简单的方式开始，逐步调优
一个实用的经验法则是：从一个单独的提示词开始。如果它能工作，就停下来。如果它失败，不要立刻跳到智能体架构。引入少量专门化的步骤，不断调优直到达到平衡。上下文工程的核心是有意识地选择和舍弃，而不是无脑堆积。
很多团队的做法正好相反：一个提示词搞不定，就上三个智能体；三个搞不定，就上三十个。结果你花了两周时间搭建了一个分布式系统，解决的是你本来可以用一个if语句搞定的事情。一旦你把上下文窗口管好了，下一个陷阱就是在问题还没提出要求之前，就开始过度设计架构。
失误二：一上来就搞复杂方案
你有一个清晰的问题，然后你立刻拿起了多智能体架构或者重型框架。你搭建检索增强生成管道、混合检索、多个数据库，或者采用像模型上下文协议这样的新协议。你这么做的原因不是问题本身需要这些，而是你觉得这才是正经做AI的正确方式。这就像你要去街对面的便利店买瓶牛奶，结果你决定先考个赛车驾照、改装一辆拉力赛车、再雇一个领航员。每一层抽象都带来隐藏的代价。
更多的依赖项、更高的延迟、更高的成本、更难的调试。复杂性会放大运维的痛苦。团队最终花了几个月搭建基础设施，却什么也没发布出去。你的老板问你项目进度怎么样，你说“我们在评估三个向量数据库的混合检索召回率”。老板的表情就像你告诉他你花了六万块钱给你的自行车装了一个涡轮增压器。问题是，你的自行车连链条都还没装好。
真实案例：ZTRON的多索引检索增强生成系统
在我们自己的创业公司ZTRON，我们搭建了一个多索引检索增强生成系统。我们有光学字符识别管道、独立的嵌入管道、混合检索和智能体化的检索增强生成循环。它确实能工作，但一个简单的查询就要花十到十五秒。成本不断攀升，调试成了噩梦。当我们终于问自己“我们真的需要所有这些吗”的时候，答案是：不需要。我们的数据完全装得进现代上下文窗口。
我们针对大部分工作流，用缓存增强生成替换了智能体化的检索增强生成。结果就是更少的模型调用次数、更低的延迟、更少的错误，以及一个更容易调试的系统。你猜怎么着？用户根本不在乎你的架构图有多漂亮，他们只在乎搜索结果是不是在五秒内出来。你给他们看一个十秒钟才返回结果但架构图美得像梵高画作的系统，他们会直接把你的应用卸载掉。
先证明核心任务能跑通
从最简单的可行方案开始。先证明核心任务是能跑通的。只有当问题真正需要时，才去添加记忆、工具、检索或者多个智能体。生产级的AI是那些先把简单系统发布出去、再有意识地扩展复杂性的工程师们建造出来的。赢得使用复杂性的权利，往往意味着你要意识到：你根本不需要一个智能体。这就引出了第三个失误。
失误三：明明工作流就够了，却非要建个智能体
像数据注入、摘要生成或者报告生成这类可预测的任务，需要的是可预测的执行方式。这叫工作流。而像深度研究或者不确定性下的动态决策这类开放式的任务，才可能需要自主性。智能体就是用来处理这些开放式场景的。但大多数团队把可预测的问题当成需要智能体来处理。当你为一个结构化任务使用智能体时，你为你根本不需要的自主性付了代价。这就像你请了一个诺贝尔奖得主来帮你算这个月的水电费账单。
他会算对，但代价是他会先给你写一篇关于流体力学和电价波动关系的三万字论文。你得到的是一份精美的报告，而你需要的就是“本月电费三百二十块”这八个字。不可预测的行为、变化的延迟、更高的令牌用量和不一致的输出。系统百分之八十的时间能工作，但在最关键的时刻却失败。你的演示日永远选在百分之八十的那一天，而客户验收永远撞上百分之二十的那一天。
采用工作流优先的方法
工作流和智能体不是二选一的选项。它们位于一个叫做“自主性滑动条”的光谱上。自主性越高，灵活性越好，但可预测性、成本可控性和可调试性都会变差。你必须有意地设置这个滑动条。从提示词链式调用、路由、并行化或者编排器-工作器模式开始。只有当系统必须自主规划、探索未知路径或者动态地从故障中恢复时，才引入智能体。
对于垂直领域的智能体，采用混合方法：把已知模式路由给工作流，把开放式请求路由给智能体。你的智能体系统应该像一个优秀的助理：他知道什么时候该自己做决定，什么时候该说“老板，这事儿我得问你”。而不是像一个刚毕业的实习生：对什么事情都充满热情地乱搞一气，最后把客户数据库删了还笑着说“我在学习”。
失误四：对大语言模型输出做脆弱解析
你让模型输出某种结构化内容，它返回了一个看起来像结构化的东西。你用正则表达式、字符串切分或者自定义逻辑去解析。在预发布环境里它工作得很好。然后某一天，一个缺失的逗号或者不同的列表样式就让生产环境崩溃了。大语言模型是非确定性的。即使提示词完全相同，输出也可能因为上下文变化、模型更新或者工具输出的差异而发生漂移。
脆弱解析就是一颗定时炸弹。很多团队的应对方法是让模型输出JSON格式。这比自由文本要好，但它仍然不是一个合约。你仍然会遇到缺失键、错误的类型和不断漂移的嵌套字段。你的代码就像是在走钢丝，而钢丝下面是一群等着看笑话的用户。你写了二十行正则表达式来提取日期，然后模型某一天把“2024年1月2日”写成了“January the second, twenty twenty-four”。恭喜你，你的系统崩了，而用户看到的错误消息是“服务器忙，请稍后再试”。
把输出当成数据，而不是文本
停止把大语言模型的输出当成文本来处理，要把它当成数据。定义一个模式，在生成时就强制执行它，在运行时验证它，出错时快速失败。用Pydantic作为概率生成和确定性代码之间的桥梁。但只在真正需要结构化输出时才使用结构化输出。如果你只需要一个普通字符串，那就接受字符串，并且保持模式尽量浅层和最小化。你的解析逻辑应该强壮到能承受一个喝醉了的模型在凌晨三点输出的结果。因为实际上，模型不会喝酒，但它会在凌晨三点因为负载均衡器的一个奇怪配置而输出完全不可预测的内容。
失误五：忘记智能体需要规划能力
你给模型一些工具，让它选一个，把工具的输出反馈回去，然后重复。乍一看，这很像智能体，但它只是一个带随机性的工作流。系统只是在响应上一个工具的输出，而不是在朝着一个目标前进。这就像你让一个机器人去厨房做早餐，它看到冰箱门开了就关上，看到面包机热了就跳进去，最后给你端上来一个烤糊了的冰箱把手。没有内嵌的规划，这个循环就无法把任务分解成有意义的步骤。
它无法评估进展，也无法有意识地选择下一个动作。结果就是随机行为、不必要的工具调用、无限循环和浅薄的推理。直接复制博客文章里的ReAct或规划-执行模式而不针对你的领域做适配，只会让情况更糟。你的智能体会花十步做一个两步就能完成的任务，然后在第五步的时候开始调用天气查询工具，因为它觉得“也许了解一下湿度有助于我做数学题”。你看着调用日志，感觉自己在看一个三岁小孩玩你的专业工具箱：拿起扳手拧螺丝，觉得无聊了又拿起电钻去戳沙发。
把规划嵌入到循环里
在调用工具之前，要求有一个推理步骤。问一问目标是什么、下一个最佳动作是什么、需要什么证据。添加进度检查和停止条件，比如最大步数、令牌预算，以及在卡住时的升级机制。让规划针对你的具体用例，因为通用的ReAct不是一个产品。针对你的工具、数据、约束条件和故障模式来定制规划。你的智能体应该像一个经验丰富的项目经理，而不是一个刚看完三篇Medium博客就觉得自己无所不能的程序员。即使是一个规划良好的智能体，如果你不持续衡量它的表现，它也会随着时间而退化。
失误六：没有从第一天就开始做AI评估
你构建功能，却不追踪AI的行为表现。你没有测试、没有评估指标、也没有定义好的成功标准。每一个新功能都是一场赌博，团队在无声无息地发布倒退。AI系统不是一下子全盘崩溃的，它们会逐渐退化。一个提示词的改动、一个新工具、或者一次模型升级，都会引起细微的行为漂移。你就像一个闭着眼睛开车的司机，你以为自己在直行，实际上你已经开进了对面车道，而你的用户正在对面惊恐地按喇叭。
没有评估，没有人能回答“这次改动让系统变好了还是变差了”。团队最终只能依赖“感觉评估”，也就是手动、凭直觉的测试，这种方式无法规模化。很多团队以为自己做了评估，但实际上依赖的是像“有帮助程度”或者一到五星评分这样的通用指标。一个三点七分的“有帮助程度”分数，根本告诉不了你应该修复什么。这就像你去看医生，医生说“你的健康指数是七点二分”，然后就把你赶出去了。你甚至不知道是肝出了问题还是脚趾头骨折了。
把评估当作北极星
从第一天起，就定义跟真实系统行为和业务需求绑定的、针对具体任务的二元指标。用评估来驱动优化飞轮。把评估集成到你的开发工作流中，在用户发现之前就捕捉到倒退。你的评估应该像你的单元测试一样严格。你绝对不会在没有跑单元测试的情况下提交代码，那为什么你可以在没有任何评估的情况下把一个新的提示词推送到生产环境？认识到这六个失误，是逃离概念验证炼狱的第一步。
结论
这六个失误并不是什么稀奇古怪的边缘情况。它们是那些反复搞垮真实智能体系统的确切模式。单独看，每个失误都很小，但在生产环境中，它们会叠加成灾难。就像你往一个背包里一个一个地放小石子，每一颗你都不觉得重，但走到半路你会发现你的肩膀已经断了。每一个失误都值得用真实案例和生产验证过的修复方案做更深入的拆解。
这就是为什么我们把它做成了一门免费的六天邮件课程。每天讲一个失误，附上我们在生产环境中使用的确切模式和解决方案。你不用自己去踩一遍我们踩过的所有坑。我们已经帮你把坑的位置标好了，甚至帮你填上了一些。你只需要做一件事：别再假装你的智能体系统很稳定了。去检查一下你的上下文窗口、你的架构复杂度、你的自主性层级、你的输出解析逻辑、你的规划能力和你的评估体系。你大概率会发现，你的系统正踩在这六个失误中的至少三个上面。好消息是，现在你知道怎么修了。