从 Prompt Engineering 到 Harness Engineering：AI 系统竞争，正在从“会写提示词”转向“会搭执行框架”
从 Prompt Engineering 到 Harness Engineering：AI 系统竞争，正在从“会写提示词”转向“会搭执行框架”
摘要
过去两年，很多团队把 AI 应用效果的提升寄托在 Prompt Engineering 上：修改 system prompt、叠加 few-shot、重写指令模板，期待模型“更聪明一点”。这在早期是有效的，因为单轮问答产品的核心变量确实集中在 prompt 本身。
但一旦进入工程化场景——例如 coding agents、DevOps copilot、内部自动化助手、带工具调用的 agent 平台——问题就迅速暴露：决定结果上限的，已经不只是 prompt，而是整套 harness。
我把 harness engineering 理解为：围绕模型构建一层可执行、可观测、可审计、可治理的运行框架。它不只是“包装壳”，而是 AI 系统真实能力的组织方式。Prompt 只是其中一个组件；真正决定稳定性、成本、可控性与安全边界的，是 orchestration、context packing、tool interface、validation loop、governance、human-in-the-loop，以及 runtime/provider/cache/cost 等一整套机制。
如果说 prompt engineering 解决的是“怎么把话说清楚”，那么 harness engineering 解决的是：怎么让模型在真实世界里可靠地做事。
一、Prompt Engineering 的价值，和它的边界
先说结论：Prompt Engineering 没过时，但它不再是主战场。
它仍然重要，因为 prompt 负责定义任务边界、角色设定、输出格式、工具使用倾向和行为约束。一个差的 prompt，往往会让系统在起跑线就偏航。但问题在于，很多团队高估了 prompt 的决定性，低估了系统工程的影响。
在工程场景里，prompt 至少有三类局限：
1. Prompt 无法独立解决状态管理问题
真实任务不是一次性 completion，而是多步执行。
一个 coding agent 需要读文件、调用工具、规划步骤、处理失败、回滚变更、再次尝试。这里决定质量的，不是某一句“请谨慎思考”，而是：
- 上下文是否被分层组织
- 历史步骤是否被压缩
- 错误状态是否被显式建模
- 工具结果是否被结构化回灌
换句话说，prompt 只能描述意图，不能替代状态机。
2. Prompt 无法独立解决工具使用质量问题
很多 agent 失败，不是模型不会想，而是不会“安全且正确地操作外部系统”。
例如同样是调用 shell、Git、浏览器、MCP server：
- 参数 schema 是否清晰
- 工具描述是否过长或误导
- 工具返回值是否经过裁剪和归一化
- 是否有限权执行与批准机制
- 错误是否可重试、可分类
这些都不是 prompt 自己能兜住的。
工具系统设计得差，模型再强也会被喂出坏行为。
3. Prompt 无法独立解决可重复性与治理问题
当一个团队把“效果调优”主要寄托在 prompt 上时，系统会很快进入一种玄学状态：
A 改了一句提示词，B 换了一个工具描述，C 调整了上下文裁剪策略，线上结果突然变化，但谁也说不清根因。
这意味着系统缺乏：
- 可观测的执行轨迹
- 可回放的输入输出
- 可审计的策略层
- 可版本化的 spec
于是优化就退化成“手工炼丹”。
二、为什么 Context Engineering 比 Prompt Engineering 更接近现实问题
很多人已经开始谈 Context Engineering，这其实是一个重要过渡。
因为模型表现的核心，往往不是“你写了什么 prompt”，而是你最终给了模型什么上下文。
这里的上下文不是简单拼接文本，而是信息选择、排序、压缩、去噪与结构化。
一个成熟的 context engineering，至少要回答这些问题：
- 哪些信息应该进上下文，哪些不该进
- 什么内容放在 system 层，什么放在 task 层
- 历史轨迹如何摘要，避免上下文污染
- 工具结果如何裁剪，避免日志淹没关键信号
- 安全策略与审批状态如何显式注入
- 不同任务阶段是否使用不同 context packing 策略
这也是为什么同一个模型，在不同产品里的表现差异巨大。
很多时候，差别不在“模型智商”，而在“上下文供给链”。
不过，Context Engineering 仍然不是终点。因为上下文只是输入层。
真正的问题是：谁来决定什么时候收集上下文、怎么调用工具、何时验证、何时终止、何时升级到人类审批？
这就进入 Harness Engineering 的范畴了。
三、Harness Engineering：下一阶段的重点，不是更会提示，而是更会组织执行
我认为，未来一段时间里，AI 工程能力的差异会越来越集中在 harness 上。
原因很直接：底层模型在快速收敛，通用能力差距依然存在，但对于大量工程任务而言，系统外层的执行框架已经足以显著放大或压制模型能力。
同模型不同 harness，结果常常像换了一个产品；不同模型但 harness 极强，实际体验甚至可能反超“参数更强”的对手。
所谓 harness，不应被理解成一个简单 wrapper。更准确地说，它是模型与外部世界之间的执行控制平面。
一个可落地的 harness，通常包括以下组成：
1）Workflow / Orchestration
定义任务如何分阶段推进：规划、检索、执行、验证、汇总。
是否允许并行、何时重试、何时中断、何时切换子 agent，都是 orchestration 问题。
2）Spec
把“要求”从自然语言口头约定，变成可版本化的行为契约。
包括输出 schema、工具权限、失败策略、审批条件、停止条件等。
没有 spec，系统只能靠 prompt 暗示；有 spec，系统才有工程边界。
3）Context Packing
把正确的信息，以正确形式，在正确时机送进模型。
这往往决定系统是“清醒工作”还是“信息中毒”。
4）Tool Interface
工具不是给人看的，而是给模型用的。
因此接口设计要强调：短、准、结构化、可验证。
参数 schema、返回 schema、错误码、权限提示都要为 agent 设计，而不是为 demo 设计。
5）Validation Loop
不是让模型“一次答对”，而是让系统“可发现错误并纠偏”。
例如：编译检查、单测、lint、schema validation、约束校验、dry run、diff review。
这比在 prompt 里写“请仔细检查”有效得多。
6）Governance
谁能调什么工具、谁能读什么数据、哪些操作必须审批、日志保留多久、如何回溯异常行为。
没有治理，agent 很容易从“自动化助手”滑向“高权限风险源”。
7）Human-in-the-loop
真正可落地的企业系统，不是追求完全无人，而是追求在关键节点让人介入。
例如写代码可以自动，发版前要审批；读文档可以自动，删库必须阻断。
好 harness 的目标不是取代人，而是把人放在高杠杆决策位。
8）Runtime / Provider / Cache / Cost
同样一套 agent 逻辑，在不同 runtime、provider、缓存策略和成本约束下，行为会明显不同。
是否支持长上下文、工具调用延迟如何、是否命中 cache、是否做 response reuse、失败重试成本如何，这些都直接影响线上体验。
四、为什么“同模型不同 harness，结果不同”会越来越明显
这在 coding agents 领域已经非常直观。
很多开发者都观察到：OpenCode、Claude Code、以及各种 IDE agent，哪怕底层调用的是相近模型，最终体验也差很多。原因并不神秘，核心就在 harness。
同一个模型，差异可能来自：
- 任务拆解方式不同
- 文件读取与摘要策略不同
- 工具暴露面不同
- shell / git / editor 接口设计不同
- 是否有强约束的 patch 流程
- 是否做了 validation loop
- 是否有人类批准节点
- 上下文截断与记忆压缩策略不同
所以，“某某模型在 A 工具里很好用，在 B 工具里很笨”，不一定是在评价模型本身，很多时候是在评价它背后的 harness。
这也是我认为行业接下来值得关注的一点：
Agent 产品竞争，会从模型接入能力，转向 harness 设计能力。
五、Harness Engineering 的安全重点：别只防用户输入，也要防工具层注入
工程团队常见的误区是，把 prompt injection 主要理解为“用户在输入框里塞恶意文字”。
这当然重要，但还不够。
在 agent 系统里，MCP、tool metadata、API description、文件内容、网页结果、命令输出，都是潜在的 prompt injection attack surface。
尤其是工具元数据，常被默认视为“可信系统信息”，这是危险的。
我建议至少做这些安全控制：
1. 明确安全边界与权限分层
- 读、写、执行、外发分层授权
- 高风险动作默认 deny
- 敏感操作必须审批
2. 审计与可追踪
- 记录 prompt、context packing 结果、工具调用、审批决策、最终输出
- 保证关键行为可回放、可归因
3. 批准机制
- 对 shell、生产环境、外部写操作建立 approval gate
- 把“模型建议执行”和“系统实际执行”明确分离
4. Schema Filtering
- 工具输入输出严格按 schema 过滤
- 丢弃无关字段、超长文本、可疑 instruction-like 内容
- 避免把不可信 metadata 原样注入 system prompt
5. 把工具描述和 MCP 元信息当成不完全可信输入
- 不要默认相信服务端返回的自然语言描述
- 必要时做白名单映射、字段裁剪、模板重写
- 将 control plane 与 data plane 分离
本质上，agent 安全不是“加一句不要被骗”，而是把信任边界做成系统结构。
六、对工程团队的实际建议：别再只调 prompt，开始建设 harness
如果你在做 AI 平台、内部 agent、DevOps assistant 或 coding agent，我建议优先补这几件事：
- 先定义 spec，再写 prompt
- 把 context packing 视为独立模块
- 工具接口统一 schema，别让模型猜参数
- 为关键任务建立 validation loop
- 对高风险操作加入 human approval
- 建立 execution trace，支持回放与审计
- 把 provider/runtime/cache/cost 当作一等设计变量
- 将 MCP/tool metadata 纳入安全审查范围
这些事情看起来不如“写出一个神 prompt”性感，但它们决定系统能不能上线、能不能稳定跑、能不能过安全审查。
结论
Prompt Engineering 仍然重要，但它更像是 AI 系统的“语言层优化”；
Context Engineering 进一步解决了“信息供给”问题；
而 Harness Engineering，才是在真实生产环境中把模型能力转化为可靠结果的关键。
我认为，下一阶段真正拉开差距的，不是哪个团队更会写 prompt，而是哪个团队更会设计 harness：
谁能把 workflow、spec、context、tool、validation、governance、approval、runtime/cost 组织成一个稳定系统，谁就更有机会把 agent 从 demo 做成基础设施。
当模型逐渐商品化，harness 才会成为工程壁垒。