也聊聊 AI Harness

我之前对它的感受比较零散，正好借这个机会把思路整理一下。先说结论：我理解的 Harness，不只是把几个 Agent 编排起来，也不是再包一层工作流工具。它更像是一套让人可以稳定驾驭 AI 的工程系统。

为什么会需要 Harness

过去一段时间，我们一直在追求 AI 带来的提效。

最早大家聊 Prompt Engineer，重点是怎么把问题问清楚，怎么让模型一次回答得更好。这一层能带来提升，但更多还是 2x 级别。

后来开始聊 Context Engineer，重点变成怎么给模型准备更好的上下文：项目背景、代码结构、历史决策、工具说明、约束条件。这一层的价值明显更大，因为模型不再只是“会回答”，而是更接近“知道自己在什么环境里回答”。我理解这里可能有 5x 左右的提效空间。

再往后看，就是 Harness。它有机会把提效推到 10x，甚至 100x。

原因也很直接：Prompt 和 Context 优化的，仍然是“人一次次驱动 AI”的协作方式。只要链路里每一步都要人来判断、复制、粘贴、确认、再推进，人就会成为瓶颈。

Harness 解决的是另一个问题：能不能减少链路里的人工节点。

通过 loop、多 Agent、预设 skill、工具连接、自动反馈和任务调度，把那些已经跑通的流程逐渐固化下来。链路越长，人参与得越少，提效就越可能跨一个数量级。

Harness 更像马具，而不是马

我觉得 Harness 这个词本身就很妙。

它不是马，也不替代马。它是一套马具，让人可以更稳定地驾驭马。

对应到 AI 里，Harness 不是让模型突然变聪明。模型本身还是模型，它会犯错、会遗漏上下文、会高估自己的答案。Harness 真正做的，是把模型外面的规则、工具、技能文件、环境信息和反馈循环包起来，让人可以把模型放进一个更可控的系统里使用。

所以它一定会超过单个 Agent。

单个 Agent 更像一个执行个体，而 Harness 关心的是：这些执行个体怎么拿到上下文、怎么调用工具、怎么互相校验、怎么在失败后改进、怎么把一次经验沉淀成下次默认会做的事情。

Harness 的几种形态

我现在会把 Harness 粗略分成三类：Loop、流、连接。

1. Loop：让系统自己长记性

Loop 最好理解，就是把“做事、观察结果、修正策略”这件事循环起来。

比如各种 self-improve loop。一个很有启发的原则是：当 Agent 出错时，不要只手动把这一次修掉，而是追问一句：“怎么让它以后不再犯同样的错？”

这个答案可以被固化成很多形态：

• 写进 skill，让下一次执行时自动遵守。
• 写进 memory，让系统保留长期经验。
• 写进检查流程，让 coding 阶段多一次自检。
• 写成自动化任务，让产品上线后收集日志，再由 AI 分析问题、生成修复 PR。

Loop 的关键不是“这次修好了”，而是“系统因为这次错误变得更不容易再错”。

2. 流：把一次次手工推进变成系统推进

流的形态更多，比如 Workflow、Agent Team、Cron Tasks 等。

这里需要和传统自动化区分一下。n8n、Zapier 或很多 Workflow 平台，本质上也能把节点串起来，但传统自动化的节点通常是确定性的：如果发生 A，就执行 B；如果字段等于 C，就走 D。

Harness 的区别在于，节点里可以放模型判断。

这会让流程从“固定脚本”变成“带判断能力的执行系统”。它可以读上下文、做总结、比较方案、写代码、做 Review、判断是否需要继续推进。这也是为什么 Harness 的提效空间可能比传统自动化大得多。

举几个例子：

• GitHub 有新 PR 时，自动做 Review；后续有新增提交时，再做增量 Review。
• 保存一个新的 X bookmark 后，自动读取内容，做详细总结，再分别用不同模型和写作 skill 生成几版可选文案。
• 每天早上抓取国内多个渠道新闻，再结合 X List，生成一份 AI 新闻摘要。
• 项目依赖需要长期跟进时，比如某个 SDK 升级，第一次手动跑通后，就配置成定时流：检查更新、升级依赖、跑验证、提 PR。

流真正有价值的地方，是把“我已经知道怎么做，但每次都懒得做”的事情，从人的待办里移出去。

3. 连接：让 AI 真的进入工作环境

连接指的是把 AI 接进各种真实环境。

比如 GitHub 的 Issue、PR、Action 日志；比如本地电脑里的代码、文档、浏览器、终端；比如远程服务里的数据、监控、告警、后台系统。

没有连接，AI 很容易停留在聊天窗口里。它能给建议，但不能直接触达现场。

有了连接，AI 才能看到上下文，才能执行动作，才能把建议变成变更。很多时候，连接本身就是提效的起点。

不要做一次性工作

Harness 里有一个原则很容易被低估：不允许长期做一次性工作。

如果同一件事被问第二次，就说明系统还没有长出记忆。如果一个操作已经手动跑过 3 到 10 次，就应该考虑把它固化成 skill、脚本、workflow 或 cron。

这不是为了追求自动化洁癖，而是因为“流”只有在不断沉淀后才会越用越厚。

今天沉淀一个 PR Review 流，明天沉淀一个发版检查流，后天沉淀一个依赖升级流。时间长了，个人和团队的工作方式会被这些流重新塑形。

AI 主导，不等于一个 AI 包办一切

这里还有一个容易误解的点：AI 主导，并不等于让一个 AI 从头做到尾。

单个 AI 自评很容易高估自己。让它给自己的产出打分，它常常会对一个平庸结果过于自信。任务越主观，这个问题越明显，比如写作、设计、架构取舍、产品判断。

所以更合理的方式，是把生成和评估拆开，让多个 AI 互相制衡。

比如 Planner 负责拆任务，Generator 负责产出，Evaluator 负责审查。必要时再加一个 Critic 或 Reviewer，专门从反面找问题。这样 AI 才不是一个人在自说自话，而是在一个有分工、有反馈的系统里工作。

这也是我理解 Harness 必须超越单 Agent 的原因。

人的角色会变化

如果 Harness 要达到 10x 到 100x 的提效，它一定得让 AI 承担更多主导执行的部分，人的占比要下降。

但这不是把人踢出局。

人的角色会从“一行行看、一处处点、一遍遍手动推进”，转向更高层的设计和把关：

• 设计任务结构。
• 定义评价标准。
• 决定哪些流程值得沉淀。
• 在关键节点做取舍。
• 为系统的失败兜底。

换句话说，AI 主导执行，人主导方向、边界和质量。

下一步

所以我接下来想做的事情也很明确：搭各种流。

不是为了把工具堆得更复杂，而是把那些已经重复出现、已经有稳定判断标准、已经验证过价值的工作，慢慢从手工流程里拿出来。

如果说 Prompt 是让 AI 回答得更好，Context 是让 AI 更懂现场，那 Harness 就是让 AI 真正进入系统，持续执行、持续反馈、持续进化。

这可能也是接下来一段时间，AI 工程实践里最值得投入的方向。