同一个错误，为什么永远改不掉
一个你一定经历过的场景：
你让AI写一份竞品分析报告。第一版，格式对，但把某公司产品定位搞反了。你纠正了。
第二版，定位对了，但又犯了同样的格式错误。你耐着性子改了Prompt，加了三行说明。
第三版，格式和定位都对了。但你发现它把你一周前在另一个对话里明确说过的数据引用错了。你盯着屏幕，深吸一口气，关掉窗口，自己写了。
然后你跟所有人说：“AI就这样，Demo惊艳，干活不靠谱。”
这个循环，如果你用AI超过一周，一定经历过。
但问题真的出在模型身上吗？
让我们把镜头拉远。你每一次纠正AI，本质上是在做同一件事：在这一次的输出里修复了一个错误。 你修复的是“症状”，这段文字的措辞，那条数据的来源。但你没有修复“病因”：
是什么让AI一次又一次地犯这些错？
每次AI犯错，你停下、纠正、重试。这个“停下-纠正-重试”本身就是问题。它把你变成了AI的人工校验员，而你每次的纠正，都没有被“记住”。
这里的“记住”不是指现在AI产品中的“记忆功能”。就算你开了记忆、就算你写了详细的系统提示词，AI还是会在你没预料到的地方翻车。
因为这根本不是“记忆”的问题。
这是你没有给AI搭过一个“不能犯错”的环境。
从修Bug到建护栏
一个新手司机开车，总是压线。你可以每次在旁边提醒他“靠左一点”“打灯”“减速”。他可能今天听了，明天忘了。但你也可以给他装一套辅助系统：车道保持（偏离了就自动纠正）、碰撞预警（危险时自动刹车）、限速提醒（超速时主动降速）。
这个新手还是那个新手。但装了辅助系统后，他能犯的错误的种类和严重程度，被大幅缩减了。
同理，与其反复纠正AI的每一次错误输出，不如设计一套让它天然不太可能犯错的工程体系。
这个思路有一个名字，但名字不重要，重要的是它的核心原则：
每次AI犯错，不要只修正这一次的输出。要工程化一个方案，让它以后永远不再犯这个错。
它的核心不是“修一句话”，而是“建一堵墙”。建墙比修话难得多。但一旦建好，它就一直在那里。
三层防错体系
把上面这句话落地，你会得到一个三层结构：
图1：好的AI Agent应该有三层防错体系
第一层：约束——画红线
约束层的核心问题是：哪些错误，我们根本不想让它有“可能”发生？
这些错误应该有硬限制，不是“建议AI不要这么做”，而是“系统层面就不允许”。
约束的类型
- 操作边界约束。
一个文件操作Agent，不能访问系统目录。一个邮件Agent，不能群发超过50人。一个支付Agent，单笔金额不能超过阈值。这些约束写在代码里，不管AI生成什么调用指令，如果越界就直接拒绝。
- 格式约束。
如果你需要AI输出JSON，就在工具层加一个JSON Schema校验器。如果AI输出了不合法的JSON，不进入下一环节，直接要求重试。
- 权限约束。
不是所有操作都应该自动执行。高风险的如发送邮件、执行数据库写操作、调用付费API，应该要求人类确认。确认机制本身就是一个强大的约束：AI知道它做的操作要经过人类审核，这会影响它的“行为策略”（更倾向于生成可解释、可验证的输出）。
- 规则约束。
“不要编造数据”写在Prompt里是不够的。如果你要的东西是专业的报告或者别的，你需要规则引擎：比如一个正则表达式匹配器，检测输出中是否包含“据X报告”“根据XX数据”这类引用句式，如果有，就检查引用的来源是否在输入材料中存在。不存在，就打回重写。
约束层的设计原则
约束应该硬，而不是软。
“软约束”写在Prompt里：“请不要编造数据。”
“硬约束”写在代码里：检测到未经确认的“据XX统计”句式时，输出被自动拦截。
软约束有用，但不可靠。硬约束才可靠，这是代码层面的确定的东西。
原因很简单：对AI来说，一段Prompt里的“请不要”和一段论文里的“请不要”，在概率意义上没有本质区别，因为都是在某些上下文中被“覆盖”的文本模式。当上下文足够强时（比如前文有大量编造数据的示例），软约束被“冲掉”的概率不低。
一些tips：在Prompt中对重要的内容用**包裹加粗，或者用大写英文强调，可能会让LLM更关注一些信息；此外，将你的提问重复多次，有时也能起到强行关注的效果。
硬约束不需要AI“听话”。它在模型外面，和你写不写Prompt无关。
第二层：校验——发现错误
约束层挡住的是“绝对不能犯”的错误。但还有大量错误，不可能在约束层全部拦截，它们需要被“发现”。
校验层的核心问题：你怎么知道AI这次输出是错的？
校验的层次
- 格式校验。 最简单的。输出是不是合法JSON？XML标签是否闭合？字数是否在范围内？这些可以在代码里自动检查，毫秒级完成。
- 一致性校验。 AI说“根据报告第X部分”，但报告里真的有这个部分吗？AI列了三条结论，这三条结论之间有没有矛盾？这些需要规则引擎或另一个大模型来交叉验证。
- 事实校验。 AI引用了“2024年市场规模为850亿美元”，这个数字存在吗？能用搜索工具找原文核实吗？这是最难的校验，但也是最有价值的。事实校验的方案通常有三种：
工具回溯。 让Agent在输出事实性内容后，自动调用搜索工具查找原始来源，对比一致性。
双模型校验。 用一个独立的、更小更快的模型检查主模型的输出中是否有明显的事实错误。
人工抽检。 对高风险场景（例如医疗、法律、金融），建一个人工审核环节。
校验层的核心原则
校验必须是自动的。 你不能靠“我看看输出对不对”来验证，那你就回到了“人工校验员”的角色。
校验必须快。 如果校验比AI生成还慢，这个系统没法用。所以校验策略应该是分层的：格式校验毫秒级、一致性校验秒级、事实校验可能需要更长但只在关键场景触发。
校验的覆盖范围决定了系统的可信度。 你校验了格式，只能保证“看起来对”。你校验了事实，才能保证“真的对”。
第三层：恢复——错误不扩散
即使有约束和校验，错误仍然会发生。
因为在概率预测系统中，错误是必然的。约束缩小了错误的可能性，校验发现了已经发生的错误，但错误发生了之后，怎么办？
这就是恢复层：让错误的影响被“圈禁”，不会扩散成更大的灾难。
恢复策略
重试。 最基础的恢复。输出不合格式？自动重试，并附上“上次你输出了不合法的JSON，请严格遵守格式”。大多数格式错误，重试一到两次就能解决。
降级。 工具调用失败了？不是直接报错退出，而是降级到一个“安全模式”，这就要求更完备的兜底策略，给工具加“替补”，如果A搜索失效，则仅使用B搜索，在ToC时优先保证用户体验。
回滚。 对于严格的任务来说，在工具链中，如果第三步出错，不应该“继续硬走第四步”，应该回滚到出错前的状态。这需要你的工具设计支持事务性操作（要么全做，要么全不做）。
隔离。 Agent在一个子任务里翻了车，不应该影响其他子任务。每个子任务应该有独立的上下文，错误不跨任务污染。但你必须保证主Agent尽可能正确。
现在，很多AI产品在做Multi-Agent（多智能体）时，将主Agent用高级模型，子Agent用快速的小模型，既可以节约成本又可以让小模型“不想太多”。
恢复层的核心原则
假设错误一定会发生。设计系统时，起点不是“如果一切顺利”，而是“当某一步出错时”。
这个心态转变，是把Agent从“好像能用”升级到“真的可靠”的关键。
上下文工程：三层体系的“地基”
回顾一下。
约束、校验、恢复——这三层能运转的前提，是你把上下文管好了。我们在前面提到过Context Engineering。这里把它和防错体系结合起来。上下文工程要管的四件事，映射到防错上：
给什么 → 只给准确、经过验证的信息。不要把未经验证的搜索结果直接喂给Agent，要先过滤一下来源。
不给什么 → 清理上下文污染。发现Agent上一次输出有误？不要只说“错了，重来”，要把错误的对话从上下文中移除，防止它“学习”自己的错误。
什么时候给 → 信息按阶段注入，不一次性全倒进去。第一阶段：任务定义+范例。第二阶段：检索到的相关资料。第三阶段：工具返回的实时数据。每个阶段只增加必需的信息，避免注意力稀释。
什么格式给 → 用结构化格式传递规则和约束。规则写成YAML或者列表，比写成一段话更可能被精确遵循，因为结构化格式在训练数据里有非常固定的Token关联。
上下文工程，本质上是信息卫生。就像手术室要保持无菌环境，Agent要处理的信息环境也需要“去污染”、“分层”、“编码”。
一个真实的启示：源码泄露教会我们什么
2026年3月，某个被意外公开的AI Agent系统源码，超过50万行、近2000个源文件，被社区逐行拆解分析。这份代码没有泄露模型权重。模型本身还是在云端的。泄露的是“壳”，即它如何组织工具、如何管理上下文、如何处理错误、如何在长任务中保持状态。
社区分析后的结论出奇一致：这个系统的稳定性，绝大部分来自“壳”的设计，而非模型本身。
具体来说：
- 每一个工具调用都有一个对应的安全校验函数
- 上下文被精细分成多个“槽位”：任务槽、工具槽、记忆槽——各自独立，互不污染
- 长任务的上下文管理有一套“压缩-展开”机制：不重要的历史被压缩成摘要，关键事实被保留原样
- 每一步操作都有“置信度评分”：当AI自己对输出不确定时，它会主动请求人类确认
这些设计，和模型“聪明不聪明”无关。它们是纯粹的工程。
而且这些设计是可以迁移的：你用GPT还是DeepSeek，都可以搭这套壳。
这就是为什么“选哪个模型”是重要的问题，但不是最重要的问题。更重要的是：你给这个模型搭了一个什么样的环境。
稳定性公式
如果我们用一个粗暴但有用的公式来总结这一章（并不专业）：
系统可靠性 = 模型能力 × 约束密度 × 校验覆盖率 × 恢复鲁棒性
模型能力是这个乘式的第一个因子。但它不是唯一的因子。
一个中等模型 + 高密度约束 + 全覆盖校验 + 健全恢复机制，其系统可靠性可能远超一个顶级模型 + 无约束 + 无校验 + 无恢复。
因为模型能力改善的是“平均输出质量”。约束、校验、恢复改善的是“最差输出质量”。
而一个系统的可靠性，不是由它的平均表现决定的，而是由它的最差表现决定的。
本章小结
这一章是全书工程思维的核心。
我们建立了三层防错体系：
- 约束层：让AI不能犯某些错误（硬限制，不仅靠Prompt）
- 校验层：让错误能被发现（自动检查，不全靠人眼）
- 恢复层：让错误不会扩散（重试、降级、回滚、隔离）
这三层的地基是上下文工程，管理AI“看到”的信息的卫生状况。
核心心态转变：
- 不再问“AI为什么又错了”
- 开始问“我怎么设计，让这个错误下次不可能再发生”
接下来，我们要解决一个更具体但同样重要的问题：你怎么知道你的Agent真的好用？不是“感觉”，而是“数据”。
自查清单
- 我能解释为什么“纠正AI的输出”不等于“防止AI再犯同样的错”
- 我理解三层防错
- 我能说出至少两种“硬约束”
- 我能解释上下文工程和防错体系的关系
- 我理解为什么系统可靠性由最差表现决定，不由平均表现决定
参考链接
- Dify 工作流编排平台. https://dify.ai/
- Coze 智能体构建平台. https://www.coze.com/
- Anthropic, "Claude's System Prompts", 2025.
- OpenAI, "GPT-4o System Card", 2024. https://openai.com/index/gpt-4o-system-card/
有了防错体系，下一个问题：你怎么判断它真的防住了？靠感觉？靠运气？不，靠评估。
