从Prompt到Harness：AI Agent工程的三次范式迁移

先说几个核心判断：过去两年里，AI应用的工程范式这场进化的大戏，大家应该都看在眼里。从最初的Prompt Engineering，到后来被频繁讨论的Context Engineering，再到最近越来越多人挂在嘴边的Harness Engineering——这些名词轮换可不是为了标新立异。它们的背后，是AI系统自身复杂度指数级提升之后，行业不得不做出的必然选择。

如果你最近正在做Agent，或者想让AI在真实的业务场景里真正跑起来，那你大概率遇到过这个灵魂拷问：为什么同一个模型，放到别人手里就能稳定完成复杂任务，而搁自己系统里，怎么调、怎么试，成功率就是上不去？

很多团队一开始会把矛头指向模型本身，要不就是嫌提示词没写好，要不就是怀疑参数配置有问题。但一遍遍踩坑下来，结论变得越来越清晰——真正决定系统能否稳定运行的，往往不是那个大模型，而是模型外面那一整套“运行环境”。这个体系，行业里现在统一叫它：Harness。

AI工程的三次迁移

从纯工程视角去复盘AI这几年的发展，能看到非常清晰的三个阶段，每个阶段对应的核心问题都不一样。

Prompt Engineering：模型到底有没有听懂你的问题？

大模型刚火起来的时候，一个特别直观的现象是：同一个模型，你只不过是换了个问法，输出结果就能天差地别。所以当时大家的共识很简单——模型不是不会，是你压根没把问题说清楚。

Prompt Engineering就是在这样的背景下火起来的。开发者通过角色设定、风格约束、甩几个示例、控制输出格式这些手段，试图把模型往一个更有利的“概率空间”里去推。

往本质上说，提示词工程不是在做“命令模型”，而是在“塑造模型局部概率分布”。这个阶段的核心能力，其实是语言表达能力，跟系统设计没啥关系。

但很快，Prompt Engineering就撞上了墙。因为很多问题，光靠“说清楚”是解决不了的，你得让模型真正“知道”才行。

Context Engineering：模型有没有拿到正确的信息？

当任务从简单的问答，升级成需要执行的复杂任务时，问题性质就变了。比如：分析企业内部文档、结合历史数据给出决策建议、调用好几个工具串成一个完整流程……

这时候，光靠提示词已经撑不住了。模型表现的好坏，开始越来越取决于它能不能拿到、拿全、拿对信息。

需要强调的是，这里说的Context不只是一两段背景资料，而是所有影响模型决策的信息总和。它包括：用户输入和历史对话、检索结果（RAG）、工具调用返回的内容、当前任务状态和中间产物、系统规则和安全约束。

所以你看，Prompt只是Context的一个子集。成熟的Context Engineering关注的是整条链路：文档怎么切、怎么排？长文本怎么压缩？历史信息什么时候保留、什么时候做摘要？工具返回的结果怎么筛选、怎么结构化？

Harness Engineering：模型能不能持续做对？

到了真实环境，就算模型理解对了、信息也给足了，也未必能稳定完成任务。常见的坑包括：执行到一半就跑偏了、工具用错了、长链路任务里状态搞得一团糟、犯了错误自己还发现不了。

这些问题，本质上已经超出了“输入侧优化”的范畴。Prompt和Context解决的是“输入”问题，但这里需要解决的是“执行过程”问题。这就是Harness Engineering登场的背景。

Harness，原意是“缰绳”，用来约束和控制。在AI系统里，它代表的就是对整个执行过程的控制、约束和纠偏机制。有句话说得挺透彻：AI Agent = LLM + Harness，也就是说，除了那个大模型，剩下的全都可以归到Harness里。

Harness Engineering的系统结构

从工程实现的角度，一个成熟的Harness大体可以拆成六个层次。

上下文控制（Context Control）

模型能不能稳定发挥，很大程度上取决于它“看到了什么”。

这一层的核心在于三件事：明确角色和任务目标、精准裁剪上下文信息、对拿到的信息做结构化组织。记住，上下文不是越多越好，而是越相关越好。

工具系统（Tooling）

没有工具的模型，本质上就是个文本生成器。

Harness不光要负责接入工具，还得解决：工具怎么选、数量如何控制、什么时候该调用、返回的结果怎么筛选和重构。关键就一句话：让模型“合理使用工具”，而不是“随心所欲地乱调用”。

执行编排（Orchestration）

这一层解决的是：模型下一步到底该干什么。

一个完整的任务通常是这样走的：理解目标 -> 判断信息够不够 -> 信息不够就补 -> 动手执行 -> 校验结果 -> 不行就重试。这其实就是在搭建一条很接近人类工作流程的执行轨道。

状态与记忆（State & Memory）

没有状态管理的Agent，每一轮都在“失忆”。

系统需要分清楚三类信息：当前任务做到哪一步了、中间产出了什么、以及用户的长期偏好和历史。清晰的状态管理，是所有稳定协作的大前提。

评估与观测（Evaluation & Observability）

很多系统的问题不是“做不出来”，而是“做完了也不知道对不对”。

这一层通常包含这四个方面：输出结果校验、自动化测试、日志和指标监控、错误归因分析。系统不光要能做，还得能自己判断有没有做对。

约束、校验与恢复（Guardrails & Recovery）

在真实环境里，失败是常态，不是例外。

所以系统必须要有这些能力：行为约束（什么能做什么不能做）、关键步骤的校验机制、以及失败后的重试和恢复能力。这一层，往往决定着你的系统到底能不能上线。

一线公司的实践启示

目前，Harness Engineering的思路已经在不少头部公司真正落地了。

Anthropic：上下文重置与角色分离

Anthropic发现，长时间运行之后，上下文会变得非常混乱。所以他们的做法是引入“Context Reset”机制——在必要的时候把Agent重启一下，然后迁移关键状态。

同时，他们把系统拆成了三个角色：Planner（规划）、Generator（执行）、Evaluator（评估）。通过把“生成”和“验收”分开，做出一个闭环的反馈机制。

OpenAI：渐进式信息披露与自动化治理

OpenAI的实践强调了几点：把庞大的规则体系拆成分层文档、按需加载信息而不是一股脑全塞进去、让Agent能操作真实环境（比如浏览器、日志、监控）、把工程经验沉淀为系统规则，实现自动化治理。核心思路非常干脆：让Agent不只是“会写代码”，而是能“跑起来、验证、再修好”。

总结：从“聪明”到“可靠”的转变

回头看整个演进过程，一句话就能说明白：

• Prompt Engineering解决表达问题
• Context Engineering解决信息问题
• Harness Engineering解决执行问题

三者不是替代关系，是逐层扩展、层层包含的关系。任务简单，Prompt够用；任务依赖信息，Context是必须的；而当任务进入真实世界、需要长期稳定执行时，Harness就成了决定成败的关键。

AI落地的核心挑战，正在从“让模型更聪明”转向“让系统更可靠”。模型决定上限，而Harness决定你能不能真的落地。