⚡ Context Engineering is Dying：意图缺失

Context Engineering 的终点不是上下文——是意图。Klarna $6000 万 AI 部署揭示：上下文充足但意图缺失 = 高效地做错误的事。

🏦 Klarna 的教训：上下文充足 ≠ 产出正确

Klarna 的 AI Agent 部署是 2025-2026 年被引最多的案例之一。AI 做了 853 名员工的工作，节省了 \$6000 万。主流叙事：「AI 替代人力，规模效应。」Nate B Jones 的重新分析揭示了一个不同的故事：

• AI 确实高效完成了任务——但它优化的是「任务完成率」，不是「客户满意度」或「长期留存」。AI 被给足了上下文（客户数据、产品信息、政策条款），但没有被给足意图（「我们的目标是让客户感觉到被理解，即使这意味着处理时间更长」）。
• 上下文告诉 AI「这是什么、规则是什么」。意图告诉 AI「我们要达到什么、什么比效率更重要」。上下文充足但意图缺失 = 高效地做了错误的事。

这和正题篇的四个工程组件对照：五组件 Prompt 结构覆盖了「怎么告诉 AI 去做」，约束体系覆盖了「什么不能做」，但两者都没有覆盖「为什么做这件事比做那件事更重要」——那是意图层，不在 Context Engineering 的管辖范围内。

📊 74% 的数字：不是模型问题，是意图问题

Nate B Jones 引用数据：74% 的公司报告 AI 投资未产生实际价值。Microsoft Copilot 85% 的财富 500 强采购了，但仅 5% 实际部署。这些不是「模型不够好」的问题——这些是「组织不知道让 AI 瞄准什么」的问题。

• Copilot 有充足的上下文——它能看到你的代码、邮件、日历。但「帮我把工作做好」不是一个机器可读的意图。什么叫「好」？是「快」还是「对」？是「符合规范」还是「让老板满意」？
• Context Engineering 假设「给够上下文，AI 就能做对」。但如果「对」的定义没有被编码——如果意图只存在于人的脑子里——给再多上下文也无济于事。

🎯 Intent Engineering：Context Engineering 之后是什么

Nate B Jones 提出的三层演进模型：

• Layer 1: Prompt Engineering（2023-2024）→ 「我说了什么」。已被 Context Engineering 吸收。
• Layer 2: Context Engineering（2025-2026）→ 「AI 看到了什么」。正在被 Intent Engineering 挑战。
• Layer 3: Intent Engineering（2026-）→ 「AI 被要求达到什么」。

Intent Engineering 的核心区别：它不是优化 AI 的输入——它是将组织目标编码为机器可读的约束，让 Context 服务于 Intent，而不是 Context 自己成为目标。

• OKR 对 Agent 不适用——OKR 是为人类设计的，「提高客户满意度 10%」对 Agent 来说是不可操作的。Intent Engineering 需要的不是自然语言目标——是「可被 Agent 执行的验证条件」。
• Delegation Frameworks 和 Encoded Judgment：不是告诉 Agent「做什么」，是编码「在什么条件下选择路径 A 而非路径 B 的判断标准」。

这对实践层的四层架构意味着什么？「Context Engineering」这个名称可能已经是上一波了——不是因为四层架构错了，而是因为它的命名暗示「上下文」是终点。终点是意图——上下文只是实现意图的手段。

🔬 MAST 的平行证据

MAST 多 Agent 故障分类法中的「规约歧义」根因和 Intent Engineering 的缺失是同构的：Agent A 和 Agent B 都有充足的上下文，但它们对「任务成功的定义」不一致——A 认为成功 = 完成任务，B 认为成功 = 完成任务且不产生副作用。这不是上下文问题——是意图没有被共享编码。

_{实践层 · 第二篇 | antithesis sources: Nate B Jones 2026.02, Klarna case, MAST NeurIPS 2025 | dialectical position: Antithesis | next: Synthesis}