AI 工程的演进

过去两年，AI 工程其实经历了三次很明显的演进，它们分别对应了 AI 系统发展的三个阶段性问题，并且是一层一层往外扩张的 ：

1. Prompt Engineering（提示词工程）：解决表达问题

在大模型刚火的时候，大家发现换一种说法，模型给的结果就截然不同 。于是大家开始疯狂研究角色设定、约束、Few-shot 示例等 。

• 本质：用提示词工程塑造一个局部的概率空间 。
• 局限： 它擅长约束输出、激发模型已有能力，但它无法弥补缺失的知识，也处理不了长链路任务里的状态 。有些事不是你说清楚就行，而是模型得知道事实本身 。

2. Context Engineering（上下文工程）：解决信息问题

当 Agent 开始火了，模型需要进入真实环境做事，要多轮对话、调用 API、传递中间结果 。此时，仅靠一句提示词已经无法解决问题了。

• 核心： 这里的 Context 代表了所有影响模型当前决策的“信息总和”，包括用户输入、历史对话、检索结果、工具返回、系统规则等（Prompt 其实只是 Context 的一部分） 。
• 高级实践： 比如 RAG（检索增强生成）就是一种典型实践 。再比如现在很火的 Agent Skills，采用了渐进式披露的思路：不把所有工具参数一次性塞给模型（避免注意力涣散），而是按需给、分层给，这也是上下文优化的高级形态 。

3. Harness Engineering：解决执行与纠偏问题

就算信息给对了，模型也不一定能稳定执行 。它可能计划做得很好，但执行跑偏了，或者调用工具理解错了 。

• 核心痛点： 当模型开始连续行动时，谁来监督它、约束它、纠偏它？
• 本质： Analyze（Harness 原意是马具、约束装置），在 AI 系统里就是提醒我们：系统不仅要喂信息，还要能驾驭整个执行过程，跑偏了能拉回来 。

一个通俗的比喻：派一个新人去拜访重要客户 Prompt Engineering： 把任务讲清楚（先寒暄，再介绍方案，最后确认下一步）。重点是把话说明白 。 Context Engineering： 把资料准备齐全（客户背景、历史沟通记录、报价）。重点是把信息给对 。Harness Engineering： 给他一套执行机制（带上 Checklist，关键节点实时汇报，会后核实录音，发现偏差马上纠正）。重点是持续观测、纠偏和验收结果 。

Agent = Model + Harness（或者说 Harness = Agent - Model）。除了模型本身，几乎所有决定它能不能稳定交付的东西，都是 Harness 。

一个成熟的 Harness 到底包括哪六层？

如果把 Harness 拆开来看，一个成熟的工程化体系通常包含以下六个层面 ：

• 第一层：重新组织 Context（信息边界）
  • 明确角色目标和成功标准 。
  • 信息的裁剪和选择（越相关越好，不是越多越好）。
  • 结构化组织（固定的规则、当前任务状态、外部证据要分层清晰，避免模型自我污染）。
• 第二层：工具系统（挂载与管控）
  • 给什么工具（太多会乱用，太少能力不够）。
  • 控制调用时机（该查证时查，不该查时别乱查）。
  • 结果重写（工具返回的几十条结果要提炼筛选后再喂回模型）。
• 第三层：执行编排（任务轨道）
  • 解决模型下一步该做什么的问题，避免模型想到哪做到哪 。
  • 完整的轨道包括：理解目标 -> 判断信息 -> 补充信息 -> 采取行动 -> 检查输出 -> 重新修正 。
• 第四层：记忆和状态管理
  • 让 Agent 分清三类东西：当前任务状态、对话中间结果、长期记忆与偏好 。没有状态的 Agent 每一轮都会像失忆一样 。
• 第五层：评估和观测
  • 包含输出验证、自动化测试、日志指标和错误归因 。系统不仅要会做，还得知道自己做得好不好，避免陷入“自我感觉良好”的状态 。
• 第六层：约束、校验、失败与恢复（决定能否上线的关键）
  • 明确哪些能做、哪些不能做 。
  • 输出前后的检查机制 。
  • 失败后的恢复机制（比如 API 超时后如何回滚到稳定状态，而不是每次都从头再来）。

一线大厂是怎么做 Harness 的？

Anthropic：解决长文本焦虑与自评失真

• Context Reflection（应对上下文焦虑）： 任务执行时间长了，上下文满了，模型会丢细节甚至急于收尾。Anthropic 发现简单的上下文压缩不够用，于是采用了类似“内存泄漏后重启进程”的思路：换一个干净的、新的 Agent，把工作交接给它 。
• 生产与验收分离（应对自评失真）： 模型自己干活自己打分容易偏乐观。Anthropic 将干活的（Planer/Director）和验收的（Evaluator）分开。Evaluator 会像真实的 QA 一样去操作页面、检查交互，形成一个“生成 -> 检查 -> 修复 -> 再检查”的有效循环 。

OpenAI：重新定义工程师在 Agent 时代的工作

• 工程师只需设计“环境”： OpenAI 用 Agent 从零构建了超百万行代码的系统。工程师的工作变成了拆解小任务，当 Agent 失败时，不是让它“更努力一点”，而是排查环境里“缺了什么结构性能力”，并建立反馈链路 。
• 渐进式披露： 早期他们也犯过错，把所有规范塞进一个巨大的 Agent.md 里，结果 Agent 更糊涂了。后来改成了只有索引的目录页，详细规范拆到了子文档里，让 Agent 按需钻进去查看 。
• 让 Agent 拥有完整的观测环境： 给 Agent 接上浏览器、日志系统和监控指标，让它能够独立跑起来看结果、查 Log、修 Bug 再验证，这是一套极其完整的 Harness 观测约束系统 。

总结

• Prompt Engineering 解决的是怎么把任务讲清楚 。
• Context Engineering 解决的是怎么把信息都给对 。
• Harness Engineering 解决的是怎么让模型在真实的执行中持续作对 。

Harness 不是取代前两者，而是在更大的系统边界上把它们包含进来 。当模型真正进入了长链路、低容错的真实场景，Harness 是不可避免的。AI 落地的核心挑战，正在从让模型看起来更聪明，转向让模型在真实世界里稳定地工作 。