为什么你的 AI Agent 总是失败——而且这不是 Model 的错
关于为什么聪明的 AI 系统在生产环境中依然会崩溃的令人不适的真相——以及那个最终能修复它的工程学科。
我在凌晨 2 点终于认输了。过去三周我一直在打磨 prompt、切换到最新旗舰 Model、并且执着地调 RAG chunking 方法。我的 AI agent 在沙盒环境里表现很棒。但一上生产？一团糟。它会忘记两步之前自己定下的决定；在交付一个坏结果前，还会自信地宣布“成功”。任务成功率顽固地卡在 68%。无论我怎么折腾 Model，都推不动到 70% 以上。
是不是很熟悉？ 最后我才意识到：我遇到的不是一个 model 问题，而是一个 systems 问题。在分清这两者之前，一切都不会改变。
AI Engineering 的三个阶段——以及为什么大多数团队停在第二阶段
LLM 应用的成熟悄然把我们带过了三个不同的思维阶段。我接触过的大多数团队都停在第一或第二阶段，却不断被第三阶段的问题“反咬”。
阶段 1：Prompt Engineering（Model 理解我了吗？）
大家都是从这里起步。你会发现 LLM 是极其敏感的“概率整形”机器——精心设置的 role、few-shot 示例、合适的 format 约束，输出瞬间变样。看起来像魔法，而且确实很强。对于封闭、单轮的任务，好的 prompting 不可或缺。
但我很快撞上了天花板。无论我把指令写得多漂亮，我都无法凭空给 Model 添一条它没有的知识；我也让它记不住三次 tool 调用之前发生的事；当真实世界不如人意时，我也没法阻止它自信地编造数据。
⚠️ Gotcha： 以为更复杂或更花哨的 prompt 能弥补事实根基缺失或实时上下文不足。它做不到。
阶段 2：Context Engineering（Model 拥有事实吗？）
认清那个局限后，我一头扎进了 context：RAG pipelines、动态检索、tool 输出回流、精心注入的对话历史。我开始执着于 Model 在做决策时“看得到什么”。
这的确是一次突破——客观地说没错。在合适的时间给到合适的信息，Agent 变得聪明太多。
但 Context Engineering 依然解决不了一件事：execution drift（执行漂移）。
Agent 会先制定一个绝妙的计划，完美执行第一步，却在第二步误解了 tool 的返回值，随后悄悄偏航，在接下来的十二步一路走偏。最可怕的是？系统毫无察觉。它只是继续，自信地执行一个早在很久之前就悄然变错的计划。
⚠️ 常见误区：把 Context Engineering 等同于基于 vector database 的 RAG。真正的上下文管理远不止如此——包括动态 state 注入、tool 响应总结、策略性的历史截断。RAG 只是起点。
阶段 3：Harness Engineering（Model 能否持续做对的事？）
从这里开始，事情变得有趣——同时也会让那些以为“更好的 Model 就是答案”的人感到谦卑。
Harness Engineering 是在 Model 周围搭建“脚手架”的工程学科——用确定性的系统去监督 Model 的行为、捕捉失败、强制约束，并在它漂移时把它拉回正轨。
这个名字来自物理世界的“安全带/缰绳”（harness）：缰绳、安全绳、控制的基础设施。说的正是这个意思。
改变我一切的心智模型：Agent = Model + Harness
这是那个来自 LangChain 的重构视角，彻底解锁了我的思考：
Agent = Model + Harness
你代码库里几乎所有能让 Agent 真正在生产可用、又不是“调用基础 Model API 本身”的东西，都是 Harness。
我总用这个类比：想象你派一位初级员工去主持一场关键的客户会议。
-
Prompting 是告诉 TA 会议议程：“先问好、介绍产品、收集需求。” -
Context 是给 TA 一份资料包：“这是客户背景、价目表和会议目标。” -
The Harness 是其他一切：随身清单、强制的中途与你对齐、全程录音、越界纠偏机制、以及会议纪要的严格验收标准。
再好的“事前交底”，也代替不了“问责与控制”的基础设施。
意识到前两个阶段让 Model“想得更好”，而 Harness Engineering 让它“可靠地行动”，这件事终于把我从 70% 拉了出来。通过重构 task decomposition、state management、critical step validation、failure recovery，在不换 Model、不改 prompt 的前提下，我把任务成功率拉到了 95%+。
成熟 Harness 的六个架构层
Harness 不是一个文件、也不是一个巧妙的 wrapper。它是分层架构，每一层对应一种失败类型。我的思考框架如下：
Layer 1：Information Boundaries（Cognitive Scope）
Model 在“即时上下文里看见什么”，几乎比任何因素都更决定它的表现。
冗余数据不会让 Model 更聪明——只会让它分心。更糟的是，当你把不同信息类型（系统规则、当前任务状态、外部证据）混成一坨非结构化内容时，Model 会丢掉约束；关键规则会被淹没成它不再关注的噪声。
Harness 必须显式定义并分类 Model 能“看到”的东西：它的 role、当前目标、成功标准，以及不同信息类型的结构化隔离。
Layer 2：Tool System（Actuation）
没有 tools，LLM 就只是文本预测器；配上合适的 tool system，它才是能与真实世界互动的 Agent。
但我早期犯过一个关键错误：给了太多 tools。十五个 tool 加详尽文档听上去很强，实际上只会分散注意力，让 Model 幻造不存在的参数，或误用它几乎没理解的 API。
Harness 必须控制“什么时候用 tool”，而不仅仅是“给哪些 tool”。当该搜索时要阻止 Model 盲猜；当答案已在手时要阻止它乱搜。
还有这一点是不可协商的：永远不要将原始的 tool 输出直接回灌到 LLM。来自某个 API 的 50 项 JSON 响应会污染你的上下文。Harness 必须在反馈给 Model 前对 tool 返回做过滤、解析与总结。
Layer 3：Execution Orchestration（Planning & Routing）
LLM 常常不是输在“单点技能”，而是输在“把这些技能线性串起来”。我称之为“意识流式执行”——在步骤之间跳来跳去、跳过校验、没凑齐材料就提前生成最终输出。
Harness 会铺好严格的轨道：
Understand Goal → Assess Information → Fetch Missing Info → Analyze → Generate → Verify → Output
这不只是脚手架，而是把项目管理的责任从“概率模型”移交给“确定性系统”。步骤的先后不该由 Model 决定；那套结构该属于 Harness。
Layer 4：Memory and State（Continuity）
无状态的 Agent 每一轮都在“失忆”。如果没有显式的 state 管理，你基本上在多步任务的每一步都在“从零开局”。
我会维持三种严格分隔的 memory：
-
-
Current Task State——我们走到哪一步了？什么在等待？什么已确认？ -
-
Conversational Intermediate Results——本轮会话中我们已经得出的中间结论是什么？ -
-
Long-Term Memory / User Profiles——跨会话持久化的全局偏好与上下文。
Layer 5：Evaluation and Observability（Self-Awareness）
⚠️ 曾狠狠坑到我的点：把 task state 和对话历史混为一谈。结果就是无限膨胀且非结构化的上下文窗口，任务越往后 Model 表现越差。务必严格分离。
原始的 Agent 会在这一层“壮观地”失效。它生成输出、宣布成功，但完全没有机制去判断输出是否真的正确。
让 Agent 自评自己的工作，等于给它装了“乐观偏差放大器”。它会把坏掉的代码评成“能跑”，会把并未回答到点子的回复评为“满意”。
Harness 需要独立、自动化的验证机制。不是事后的人审——那太慢，也不具备规模化。自动化输出验证、集成测试环境、细致的 logging、指标追踪与错误归因，统统属于这一层。
系统必须持续“向自己证明”它的行为是正确的，而不是“想当然地以为”。
Layer 6：Constraints, Validation, and Recovery（Resilience）
在生产里，失败是默认态。API 会超时、JSON 会裂开、搜索会不准。没有恢复机制的 Agent，等于每次出错都要人来“全量重启”。
这里 Harness 需要三样东西：
-
Constraints：用硬规则明确 Agent 绝对禁止做的事。 -
Validation：输出前/输出后的闸门检查（schema 校验、格式检查、约束验证）。 -
Recovery：重试逻辑、回退路径、以及回滚到上一次稳定状态的能力。
隐秘的敌人：Context Anxiety
当任务拉长到几十个步骤，会发生一件怪事。Anthropic 的研究者把它称为 Context Anxiety。
当上下文窗口逼近极限，Model 会开始丢细节、忘大目标，表现得像是在“赶工”。它会幻造本不曾得到的结论、跳过校验步骤，呈现出一种“迫不及待”而导致草率的状态。
天真的解法是 context compression（上下文压缩）：总结历史、把总结塞回去、继续。我试过了，它确实能减 token，但并不能重置 Model 的“认知状态”或“注意力稀释”。真正有效的解法反而激进：彻底重启 Agent。
Anthropic 把它叫做 Context Reflect。当上下文变得过大时，你把压缩总结交给一个全新的 Agent 实例——干净的上下文，不带任何累积的困惑。这就像处理内存泄漏时，与其疯狂做垃圾回收，不如直接重启进程。
同样地，我也不再一开始就把整个 tool 库丢给 Agent。Harness 使用 progressive disclosure：起初只给最小的 tool stub；当 Model 表达要用某个能力的意图时，Harness 再动态注入详细文档与参数 schema。所谓“上下文优化”，不是给更多信息，而是按需、在恰当的时机给到对的信息。
分离 Generation 与 Evaluation：支撑自治的架构
我遇到过的最重要的架构洞见之一，来自 Anthropic 如何构建“真正自治”的 Agent——它们能在无人审阅的情况下，连续数小时产出完整可用的成果。
诀窍是严格的“三分法”：
-
The Planner：把模糊的人类请求翻译成严谨的工程规格说明。 -
The Generator：拿着规格，一步步去执行实现。 -
The Evaluator：作为完全独立的 QA 实体——在功能上与 Generator 解耦。
Evaluator 不只是读 Generator 的代码。它要与“渲染后的输出”互动。在 UI 工作里，它会点击界面、检查视觉布局、核对交互状态。它是对“真实世界”做验证，而不是对 Generator 的“世界表征”做验证。
OpenAI 走得更远。随着 Agent 写代码的速度超过了工程师审 PR 的速度，他们给 Agent 搭了一个全自动的 CI/CD pipeline。Agent 在隔离的沙盒里运行自己的代码、用 headless browsers 截图、读取自己的执行日志，并反复迭代，直到它能在无人参与的情况下验证部署是正确的。
“Done” 不再意味着“我把文本生成完了”，而是“我跑过代码、看过日志、找到 bug、修好它，并在沙盒里验证过部署”。
结论
关于生产级 AI 系统的真相，可浓缩为我在实战中学到的一切：
基础 Model 的聪明才智，决定它在基准榜单上的理论上限；而 Harness Engineering 的扎实程度，决定这些智能能否在混沌的真实世界里“活下来、修得好、交付价值”。
Model 不是你的瓶颈。过了某个点之后，它从来都不是你的瓶颈。
把 70% 成功率拉到 95%，把 demo 变成产品——差的就是 Harness。
如果这些内容对你有启发，我长期写作 AI systems engineering、实用 ML 基础设施，以及把 demo 和生产系统区分开的那些真实世界模式。若这是你的兴趣，欢迎关注。