从 Prompt Engineering 到 Harness EngineeringAI 系统竞争正在从“会写提示词”转向“会搭执行框架”摘要过去两年很多团队把 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通常包括以下组成1Workflow / Orchestration定义任务如何分阶段推进规划、检索、执行、验证、汇总。是否允许并行、何时重试、何时中断、何时切换子 agent都是 orchestration 问题。2Spec把“要求”从自然语言口头约定变成可版本化的行为契约。包括输出 schema、工具权限、失败策略、审批条件、停止条件等。没有 spec系统只能靠 prompt 暗示有 spec系统才有工程边界。3Context Packing把正确的信息以正确形式在正确时机送进模型。这往往决定系统是“清醒工作”还是“信息中毒”。4Tool Interface工具不是给人看的而是给模型用的。因此接口设计要强调短、准、结构化、可验证。参数 schema、返回 schema、错误码、权限提示都要为 agent 设计而不是为 demo 设计。5Validation Loop不是让模型“一次答对”而是让系统“可发现错误并纠偏”。例如编译检查、单测、lint、schema validation、约束校验、dry run、diff review。这比在 prompt 里写“请仔细检查”有效得多。6Governance谁能调什么工具、谁能读什么数据、哪些操作必须审批、日志保留多久、如何回溯异常行为。没有治理agent 很容易从“自动化助手”滑向“高权限风险源”。7Human-in-the-loop真正可落地的企业系统不是追求完全无人而是追求在关键节点让人介入。例如写代码可以自动发版前要审批读文档可以自动删库必须阻断。好 harness 的目标不是取代人而是把人放在高杠杆决策位。8Runtime / 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 prompt5. 把工具描述和 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 才会成为工程壁垒。