从“咒语”到“缰绳”：AI工程化范式演进的五个阶段

feasibility.

530人浏览 · 2026-04-01 21:38:38

feasibility. · 2026-04-01 21:38:38 发布

引言

2025年，AI行业正面临一场静默的危机。Gartner在2024年7月预测：至少30%的生成式AI项目将在概念验证后被放弃（https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025）。到了2025年6月，这一预测变得更加严峻：超过40%的agentic AI项目将在2027年前被取消（https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027）。

S&P Global 2025年的调研数据揭示了更残酷的现实：42%的企业在2025年放弃了大部分AI计划，较2024年的17%大幅上升（https://sethlevine.com/archives/2026/03/ai-the-great-equalizer-for-startups.html）。这意味着近半数的企业在投入巨资后，选择了战略性的全面撤退——不是调整方向，而是彻底放弃AI作为技术类别。

MIT的《2025年商业AI现状》报告（Project NANDA）进一步证实了这一危机：尽管企业在生成式AI上投入了300-400亿美元，95%的AI试点未能产生可衡量的P&L影响（https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/）。只有5%的企业成功将AI系统集成到生产环境并实现规模化价值。

这些失败不是技术失败，而是工程范式的代际错位——我们仍在用2022年的思维构建2025年的系统。

第一章：Prompt Engineering的黄昏（2020-2024）

1.1 黄金时代的幻觉

还记得2022年的那些"魔法咒语"吗？

"Take a deep breath and work on this problem step by step."
"Let's think step by step."
"You are an expert Python developer with 20 years of experience..."

这些被称为"提示工程"的技巧，曾经能让GPT-3.5的输出质量产生质的飞跃。企业开始招聘"提示工程师"，课程和认证如雨后春笋，甚至出现了"提示词黑客"（Prompt Hacking）这样的亚文化。

但这一切建立在一个脆弱的假设上：模型的输出质量主要取决于输入文本的措辞。

1.2 三重诅咒

到2024年，提示工程的局限性暴露无遗：

诅咒一：试错地狱
每一次任务调整都需要重新设计提示，A/B测试提示变体成为常态，但"完美提示"往往无法跨任务复用。

诅咒二：幻觉的温床
过度依赖提示技巧而非系统约束，导致模型在复杂推理中产生"看似合理但完全错误"的输出。MIT的研究显示，多步推理任务的输出分歧率高达20-30%。

诅咒三：不可维护性
提示词成为黑盒魔法，团队成员无法理解为什么某个特定的"深呼吸"指令有效，更无法在生产环境中稳定复现。

2025年的判决：提示工程没有死亡，但它从"核心技能"降级为"基础素养"——就像今天没人会把"会用搜索引擎"写在简历上一样。

第二章：RAG的崛起与幻觉（2020-2025）

2.1 知识外挂的革命

2020年，Meta提出RAG（检索增强生成），试图解决LLM的知识时效性问题（https://arxiv.org/abs/2005.11401）。这个架构如此优雅：

用户查询 → 向量化 → 向量数据库 → 重排序 → 注入上下文 → 生成

RAG承诺让模型"开卷考试"，不再胡编乱造。到2023年，"RAG架构师"成为最热门的岗位之一，向量数据库创业公司估值飙升。

2.2 生产环境的真相

但2025年的企业落地揭示了RAG的阿喀琉斯之踵：

真相一：检索即政治
检索什么、不检索什么，决定了模型能看到什么。一个配置错误的分块策略（Chunking Strategy），可以让关键信息永远沉在向量空间的"海底"。

真相二：上下文污染
即使检索准确，如何将海量文档压缩进有限的上下文窗口？粗暴的截断导致信息丢失，简单的拼接导致注意力涣散。

真相三：动态知识的诅咒
RAG解决了"知识更新"，但没解决"知识一致性"。当企业知识库在Agent执行过程中发生变化，系统如何感知？如何回滚？

2025年的共识：RAG不是架构，只是数据层的一个组件。真正的挑战在于"何时检索、检索什么、如何组织"——这正是Context Engineering的萌芽。

第三章：Context Engineering的觉醒（2025）

3.1 从"怎么说"到"给什么"

2025年初，Andrej Karpathy和Shopify CEO的一次对话引爆了技术圈："顶尖团队意识到，提示的措辞往往不如模型能看到什么信息重要。"

这标志着Context Engineering的正式登场。它不再是关于"怎么问"，而是关于：

What：什么信息应该被模型看到？
When：何时加载（预加载 vs 动态加载）？
How：如何结构化呈现？

3.2 动态上下文的革命

Context Engineering的核心是Just-in-Time信息组装：

传统RAG：启动时加载所有可能相关的文档
Context Engineering：根据对话状态、用户意图、任务阶段，动态组装上下文

这要求系统具备：

意图识别：理解用户当前处于任务流的哪个阶段
记忆管理：区分短期工作记忆与长期事实记忆
信息优先级：在上下文窗口有限时，知道什么该保留、什么该丢弃

但Context Engineering仍有一个致命盲区：它管理的是"信息输入"，却不管"执行环境"。

第四章：MCP与Skills——连接层的标准化（2024-2025）

4.1 MCP：AI的USB接口

2024年11月25日，Anthropic正式发布Model Context Protocol（MCP），试图解决AI与外部世界连接的"巴别塔困境"（https://www.anthropic.com/news/model-context-protocol）。

MCP的核心洞察：工具集成不应该每次都重新发明轮子。

传统方式：每个Agent单独适配每个API（Slack、GitHub、数据库...）
MCP方式：统一协议，一次接入，到处使用

这类似于USB标准化了外设连接，MCP标准化了AI与数据、工具的连接方式。MCP采用客户端-服务器架构，使用JSON-RPC 2.0协议进行通信，暴露三种核心原语：资源（Resources）、工具（Tools）和提示（Prompts）（https://arxiv.org/html/2508.02979v1）。

4.2 Skills：从"有手"到"有手艺"

但MCP解决的是"连接"，不是"能力"。Skills的概念由此诞生（https://arxiv.org/html/2602.12430v3 ）：

Function Calling	Agent Skills
执行能力——"手"	领域知识——"训练/经验"
API接口、工具函数	可复用的领域知识包、最佳实践模板
无状态、确定性	有上下文、可动态加载/组合

Skills的典型构成：

领域特定的System Prompt模板
工具使用指南（何时用、怎么用）
输出格式规范
错误处理策略
最佳实践示例（Few-shot）

关键区别：Function Calling让模型知道"可以调用什么"，Skills让模型知道"在什么场景下用什么、怎么用"。

2025年12月：MCP被捐赠给Agentic AI Foundation，成为Linux Foundation项目，标志着其从企业标准向开放标准的转变（https://arxiv.org/html/2602.12430v3）。

第五章：Harness Engineering——2025-2026年的终极范式

5.1 为什么Context Engineering还不够？

2025年底，OpenAI Codex团队的一个实验震惊了业界：同样的模型、同样的数据、同样的提示，仅改变运行环境（Harness），编程基准测试成功率从42%飙升至78%。

这揭示了一个残酷真相：AI的可靠性不取决于模型，而取决于"缰绳"（Harness）。

5.2 Harness Engineering的定义

Harness Engineering是构建AI可靠运行所需的完整工程环境，包括约束、反馈、评估、记忆的系统性学科。

它回答了一个根本问题：如何让AI从"能用"变成"可控、可测、可观测、可回归"？

5.3 Harness的七大支柱

根据2025-2026年的最佳实践，一个生产级Harness必须包含：

支柱	功能	2025年的失败案例
1. 场景驱动（Scene-based）	每个场景有独立的Prompt、工具、模型、输出结构	通用Agent试图用同一套提示处理所有任务，导致边界情况崩溃
2. 工具优先	用工具约束模型，而非仅靠Prompt想象	让模型"心算"复杂计算，而非强制调用计算器工具
3. 可观测性	记录完整调用链（Prompt→Tool→Output）	生产环境故障无法复现，因为不知道模型当时"看到了什么"
4. 评估驱动	用测试集量化改进，而非主观感觉	"感觉更快了"但无法证明，导致优化方向错误
5. 渐进式自治	从"问答→建议→半自动→全自动"逐步演进	直接部署全自动Agent，导致不可逆的错误决策
6. 记忆与状态	长期任务的状态持久化与恢复	多步骤任务中断后无法续传，用户被迫重新开始
7. 沙箱与约束	限制Agent的行动边界，防止危险操作	Agent误删生产数据库，因为没有权限沙箱

5.4 范式对比：从Prompt到Harness

2022: Prompt Engineering
      "写一段优雅的咒语，让模型输出正确答案"
      
2023: RAG + Prompt Chaining
      "给模型查资料的能力，并把任务拆成多步"
      
2024: Agent + Function Calling
      "让模型能调用工具，自主决策"
      
2025: Context Engineering + MCP + Skills
      "管理系统性信息输入，标准化工具连接，封装领域知识"
      
2025-2026: Harness Engineering
      "构建完整的执行环境，让AI可靠地、可观测地、可回滚地运行"

第六章：生产级AI的可靠性危机

6.1 多Agent系统的14种失败模式

2025年，UC Berkeley等机构的研究者首次系统性地分类了多Agent LLM系统的失败模式，提出MAST（Multi-Agent System Failure Taxonomy）（https://arxiv.org/pdf/2503.13657）。

FC1. 规范与系统设计失败（41.8%）

违反任务规范：如要求输入国际象棋记谱"Ke8"，系统却要求坐标(x,y)
角色混淆：CPO代理擅自承担CEO角色做最终决策
步骤重复：无意义地重复已完成的步骤

FC2. Agent间失调（36.9%）

对话重置：意外丢失上下文
信息隐瞒：知道正确答案却不分享
任务脱轨：逐渐偏离初始目标

FC3. 任务验证与终止失败（21.3%）

过早终止：任务未完成就结束
验证缺失：代码只检查是否编译，不检查是否正确运行

核心洞察：这些失败并非源于基础模型能力不足，而是源于系统级设计缺陷——包括不充分的规范定义、Agent间协调机制缺失，以及验证与终止逻辑不完善。这与2026年提出的Harness Engineering理念高度呼应：可靠的AI系统需要工程化的约束、验证和回滚机制。

6.2 生产级AI的韧性要求

一个生产级AI Agent必须满足以下基本要求：

集成韧性：不仅能读取，还能在遗留系统中执行复杂操作
上下文连续性：跨越多天、多步骤的任务保持业务逻辑
自主恢复：识别并修复错误，而不触发系统级崩溃

第七章：工程师的新角色

7.1 从"写代码"到"设计缰绳"

2026年的AI工程师不再只是写代码，而是设计控制流与反馈循环：

传统软件工程：输入 → 处理逻辑 → 输出（确定性）
AI Harness工程：意图 → 检索/工具/推理 → 验证 → 输出（概率性+约束）

7.2 新技能栈

旧技能	新技能	为什么
提示工程	Harness架构	单点优化→系统设计
API集成	MCP协议设计	标准化连接层
单元测试	Eval驱动开发	概率系统的评估体系
日志监控	可观测性工程	追踪AI的"思维链"
异常处理	优雅降级设计	AI失败时的兜底策略

7.3 2026年的工程格言

"Agents aren't hard; the Harness is hard."

"Everyone can now ship code. Not everyone can ship systems that survive."

结语：五次重心转移，一次范式跃迁

AI工程范式经历了五次关键的重心转移：

第一次：Prompt Engineering → 基础素养（2022-2025）
从“核心技能”降级为“基础素养”。提示词的措辞技巧不再决定系统成败，但仍是每个AI工程师的基本功。

第二次：RAG → 数据层组件（2023-2025）
从“万能架构”降级为“数据接入组件”。RAG没有消失，而是在更复杂的系统中找到了自己的准确位置。

第三次：Agent → 渐进式自治（2024-2026）
从“完全自主”的幻想转向“人在回路+渐进自治”。自主性不是非黑即白，而是可以根据场景调节的光谱。

第四次：Context Engineering → 信息架构的内核（2025-2026）
从“静态检索”升级为“动态组装”。按需加载、意图驱动、记忆分层——这些成为Harness的底层能力。

第五次：MCP + Skills → 标准化应用层（2025-2026）
从“各自为政的工具集成”走向“统一协议”。MCP成为AI与外部世界的USB接口，Skills封装了“怎么用”的领域知识。

五次转移汇聚成一个结论：
AI的可靠性不取决于模型有多聪明，而取决于Harness有多坚固。Prompt Engineering已然蜕变——从关注“一句话怎么说”，进化为关注“整个系统如何可靠运行”。

这就是Harness Engineering的崛起——它不是一个新阶段，而是前五个重心转移的集大成者。

参考与延伸阅读

Unified Tool Integration for LLMs: A Protocol-Agnostic Approach to Function Calling (arXiv:2508.02979)
MCP: Model Context Protocol (Anthropic, Nov 2024)
Agent Skills for Large Language Models (arXiv:2602.12430)
Why Do Multi-Agent LLM Systems Fail? (arXiv:2503.13657)
Why do Multi Agent LLM Systems Fail? The Scaling Myth Exposed (Hakuna Matata Tech, Jan 2026)