曾经有段时间，只要对AI智能体说"帮我做这个"就够了。这是两年前的事。但现在，智能体出错时修复的是系统而不是智能体，这已成为常识。提示词工程 → 上下文工程 → Harness工程。4年间范式变了3次。
这是什么？
AWS Korea数据科学家金英敏整理的"AI智能体模式4年记录"在开发者社区引发热议。这不仅仅是趋势整理，更像是追踪每个时代为何失败的解剖报告。
核心是这样的：2022年我们在思考"该说什么？"，相信只要写好提示词AI就会搞定一切。2025年变成了"该放入什么信息？"，意识到上下文窗口里放什么比提示词本身更重要。到了2026年，变成了"该构建什么系统？"。
有趣的是这一转变的起源。"Harness工程"这个词是2026年2月Terraform创始人Mitchell Hashimoto首次使用的。他的原则很简单："每当智能体出错，就修复环境，让同样的错误不再发生。"不是修改提示词，而是改变围绕智能体的系统——规则、工具、约束、反馈循环。
令人惊讶的是此后发生的事。在两周内，OpenAI、Martin Fowler（ThoughtWorks）和Ethan Mollick（沃顿教授）各自独立发布了相同的结论。没有事先协调，因为所有人都撞上了同一堵墙，才产生了这种"同时发现"。
核心公式
智能体 = 模型 + Harness
Harness是"从智能体中去掉模型后剩下的一切"。模型是引擎，Harness是操作系统。再强大的引擎没有操作系统也没用。
有什么不同？
Chad Fowler（Honeycomb CTO）用一句话总结了这一变化："严谨性不会消失，只会迁移。" XP运动主张"用测试代码代替设计文档"时，动态语言声称不用编译器就能部署时，旧阵营都批评"严谨性消失了"。每次都错了。严谨性只是迁移到了更高的抽象层次。
| 维度 | 提示词工程 (2022) | 上下文工程 (2025) | Harness工程 (2026) |
|---|---|---|---|
| 核心问题 | "说什么？" | "展示什么？" | "构建什么系统？" |
| 类比 | 写邮件技巧 | 收件箱管理 | 邮件系统设计 |
| 失败原因 | 盲目提示、非确定性 | 上下文污染、信息过载 | 编排bug |
| 核心指标 | 响应质量（主观） | KV-cache命中率 | 任务完成率、成本/任务 |
| 所需能力 | 语言感觉 | 信息架构 | 系统设计+安全 |
最重要的一点是：每个时代不是取代前一个时代，而是包含它。Harness工程包含上下文工程，上下文工程包含提示词工程。"提示词工程已死"是错误的。它没有死，而是晋升了——成为更大系统的子模块。
看实践案例会更清晰。OpenAI用Codex将100万行代码库的手动代码降至0行。7名工程师5个月没写一行代码，而是设计了让代码能稳定生成的环境。Anthropic用3智能体架构分离了创建智能体、评估智能体和规划智能体。
核心总结：如何马上开始
- 将AGENTS.md作为"目录"
创建一张100行的地图，而不是庞大的指令手册。让智能体自己去找所需信息。这就是OpenAI强调"给地图，不要1000页手册"的原因。 - 每次出错时更新Harness
智能体重复执行错误命令时修改AGENTS.md，出现结构性错误时添加lint或测试。Hashimoto的核心原则——"不要责怪智能体，改进Harness"。 - 引入机械性约束
仅靠文档是不够的。用自定义lint、结构性测试来强制执行架构规则。让智能体为了通过lint而自己修改代码。 - 设计"可剥离"的Harness
模型进化时，现有错误恢复逻辑的一半会变得不必要。Harness必须是可剥离的（rippable）。过度工程化会拖累下次模型更新。 - 保持智能体持续运行
Hashimoto的目标是"始终有智能体在运行"。从每天最后30分钟启动智能体、第二天早上查看进度的模式开始。
安全警告：Lethal Trifecta
Simon Willison警告的三件事同时存在时，安全事故就是必然：(1) 处理不可信的外部输入 (2) 访问敏感数据 (3) 改变状态的能力。Meta的"Rule of Two"——最多同时给智能体其中两项权限。
