星澜

天接云涛连晓雾，星河欲转千帆舞

02. AI Agent 与 Harness：从 Prompt 到 Harness

mingzaily / Codex / 2026-03-29

这几年看 AI 相关讨论，一个很明显的变化是：大家聊的话题一直在往外扩。

最开始聊的是 prompt，后来开始聊 context、tool calling、workflow，再到这两年越来越常见的 harness engineering。

表面上看，好像只是名词越来越多。
但如果把这些讨论放回工程语境里，它们其实指向的是同一个变化：

任务越来越像真实系统问题，单次提示词已经不够解释 agent 的表现了。

这篇文章想回答的，就是下面这个问题：

为什么今天大家会从 prompt engineering，一路谈到 context engineering，最后谈到 harness engineering？

如果你更想继续往后读：

结论

harness engineering 之所以变成热词，不是因为大家突然发明了一个新名词，而是因为任务复杂度真的变了。

AI 讨论的重心，正在从“怎么让模型更会说”，转向“怎么让系统更稳定地做完”。

为什么今天大家会频繁谈 harness

过去很多讨论会把注意力放在：

这些当然都重要。
但一旦模型开始进入真实业务系统，大家很快就会撞上另一类问题：

这时你会发现，真正决定体验差距的，往往已经不是模型单点能力，而是模型外面那层运行环境和工程设计。

这也是为什么今天越来越多人开始谈：

AI 是怎么一步步走到这里的

如果把这几年的 AI 使用方式压成一条线，大概可以这样看。

第一阶段：网页版对话

最开始大家接触 AI，往往就是网页聊天。

你输入一句话，它回一句话。
这个阶段最核心的能力是：

那时候大家最在意的是：

这个模型聪不聪明，回答像不像人。

第二阶段：提示词工程

再往后，大家开始意识到：

同一个模型，提示词写得不一样，效果差别非常大。

于是开始出现：

这个阶段的关键词是：

怎么提问，模型才更听话。

第三阶段：API 和 Tool Calling

再下一步，模型不只是聊天，而是开始通过 API 接入业务系统。

这时大家发现：

也就是从“纯回答”走向“可以行动”。

Tool calling、function calling、插件、MCP 这类能力，都是这一阶段慢慢变重要的。

第四阶段：Workflow-First

当模型开始进入业务系统后，工程上第一个自然选择通常不是直接做高自治、强 agentic 的系统，而是先做 workflow-first。

原因很现实：

所以很多早期业务 AI，看起来很智能，本质上其实是：

工作流 + 模型节点

第五阶段：自主决策更多的 Agent 系统

接着人们开始想要更强的系统：

这时大家追求的，已经不只是“流程里挂一个模型节点”，而是让系统在运行时承担更多规划和决策。
焦点也从“回答得好不好”变成“能不能真的把事做完”。

这里最好把两个词拆开：

所以这一步不是说系统会突然变成“完全没有流程骨架”的形态。
更常见的现实是：

第六阶段：Harness Engineering

到了今天，大家越来越发现，真正拉开体验差距的，不只是模型本身，而是它外面那层运行环境和工程设计。

同一个模型，放在不同工具组合、不同 context 管理方式、不同验证闭环里，最后呈现出来的“智慧程度”真的会不一样。

于是讨论重心开始从：

慢慢转向：

也就是：

不是让模型更聪明，而是让模型在真实任务里更稳定地把事做对。

为什么 Workflow-First 往往比自主度更高的系统更早落地

很多人一听到 agent，就会自动联想到一个几乎能自己包办一切的系统。
但真实业务里，这种想象通常会先被流程、权限、审计和风控拉回地面。

所以这里对比的重点，不是“workflow 算不算 agent”，而是：

workflow-first 和“把更多决策交给运行时动态处理”的系统，谁更容易先落地。

这里也不要把“更 agentic”理解成“完全没有流程图”。
一旦系统要落实到真实业务里，几乎总会有某种 graph、状态机或 orchestration 骨架。

区别通常在于：

换句话说，graph 几乎总会有；真正变化的是图上有多少边是设计时固定的，又有多少边是运行时决定的。

原因并不神秘：

所以从落地角度看：

这不是谁更高级的问题，而是不同阶段的工程选择。

一个粗略的成熟度模型

为了方便记忆，可以先用一个粗糙但很好用的分层。
这里讲的是 agent harness 的成熟度，不是在引入另一种 harness。

V0：提示词工程

主要依赖 prompt。

V1：轻量 agent harness

开始有：

这个阶段的目标更像：

让 agent 更容易做事。

V2：验证型 agent harness

开始出现：

这个阶段的目标变成：

让 agent 做完之后真的过关。

V3：长时运行 agent harness

开始出现：

这时候的目标已经不是“让模型会回答”，而是“让它能连续工作很久，还不容易跑偏”。

这个分层当然不严格，但它有一个好处：
能帮我快速判断一个团队现在到底在补哪种能力。

也许未来，很多 harness 会被“吃进底层”

harness engineering 很像一个过渡时代的核心工程能力。

因为今天的模型还不够稳定：

所以我们才需要：

但也许未来，模型真的强到足以稳定完成长期规划、可靠执行、严格自检、自动管理上下文的时候，今天这些显式的 harness、规范和流程，很多都会慢慢下沉到底层平台或基础设施里。

那时我们也许不会再频繁讨论：

更准确地说，不是以后真的“不需要 harness”了，而是很多今天需要人手工搭建的工程层能力，可能会慢慢变成系统默认能力。

比如：

因为这些能力一旦下沉成功，就会像今天的网络重传、连接池、缓存淘汰一样，被默认做好。

今天的 harness 更像：

在模型还没有强到“天然可靠”之前，人类给它搭的临时工程外骨骼。

延伸阅读

如果你想先看概念总图：

如果你想看 Anthropic 和 LangChain 各自强调什么：

如果你更关心验证闭环和 Post-condition Validator：

如果你想继续把 agent harness 和 repo instructions / skills / workflow 继续拆开：

几句话总结

  1. prompt engineering 没过时，但它已经不够解释今天的 agent 系统。
  2. 只要任务开始跨多轮、多工具、多状态，系统设计的重要性就会上升。
  3. 很多业务场景真正先落地的，不是高自治 agent 系统，而是 workflow-first + 局部 agentic 能力。
  4. harness engineering 讨论的核心，不是模型会不会，而是系统能不能稳定做完。
  5. V0 -> V1 -> V2 -> V3 这条线，本质上是在描述系统可靠性要求的升级。
  6. 今天很多显式 harness，也许未来会越来越多地下沉进平台层和基础设施层。

参考