Agent Harness 是 AI 编程从提示词走向工程系统的一步

过去两年，大家讲 AI 编程，最常见的词是 prompt engineering、context engineering。现在又冒出一个新词：agent harness。词一多，概念就容易乱。Caleb Writes Code 这期 8 分钟短视频，讲的其实不是一个新黑话，而是一个很现实的工程分层：当任务变长、上下文会溢出、验证不能靠嘴的时候，模型外面那层“怎么组织它干活”的系统，开始比 prompt 本身更重要了。原视频：https://www.youtube.com/watch?v=1a1VXDdIyrk

我看到这里，第一反应不是“又来一个 buzzword”，而是这个词终于把很多零散经验收了口。前面几天，我在知识库里已经连续记了几篇相关材料：一篇在讲 If you’re not the model, you’re the harness，一篇在拆 Claude Code 在大代码库里的 harness 七件套，还有一篇把 agent 说成一个 while 循环。它们本来像三堆零件，这个视频做的事，是把零件重新拼成一条更容易理解的演进线。

先把三个层级分开

视频里最有价值的一点，是把 prompt engineering、context engineering、harness engineering 放到了同一条线上看。

prompt engineering 解决的是“你怎么跟模型说话”。你给它什么角色、什么约束、什么目标，决定它第一步往哪走。

context engineering 解决的是“模型能看到什么”。上下文窗口不够大，就得想办法把仓库、文档、数据库和工具结果按需送进去。过去两年，工具调用、MCP、RAG 这些能力，本质上都在解决这一层的问题。

harness engineering 再往上一层。它解决的已经不是一句 prompt、一次检索，而是整个任务怎么被拆开、怎么循环、怎么保存状态、怎么在每一轮结束后重新开始。换句话说，它关心的是整个运行环境，而不是单次对话质量。

这和我知识库里那篇《Agent Harness 工程底座》的判断是对上的：Prompt Engineering ⊂ Context Engineering ⊂ Harness Engineering。前两层没有过时，只是变成了更大系统里的局部能力。

为什么 prompt 和 context 不够了

视频回顾了一段很典型的历史。早期模型上下文窗口很小，大家首先做的是把 prompt 写得更精确。后来发现不够，就开始做 context engineering：按需读文件、接工具、接数据库、动态缩上下文。

这一层在短任务上很好用。让 agent 搜几个文件、改一个函数、补一个脚本，通常已经够了。

问题出在任务一长，系统就开始露底。视频举的例子很直白：让 agent 克隆一个完整网站，或者做一个范围很大的功能，表面上它一直在跑，实际上中途可能已经开始自我欺骗。上下文快满的时候，它会做摘要；摘要一旦失真，后面所有判断都建在错误记忆上。于是你看到的结果就是：页面做了一半、按钮没连上、某些功能其实没测过，但 agent 以为自己已经完成了。

这件事很像人类写周报。你如果每隔两小时就把前面的工作压成一段模糊总结，再靠这段总结继续干 12 小时，最后一定会丢细节。模型也一样。上下文摘要不是免费的午餐，它只是把记忆债务往后挪。

这也是为什么我更认同知识库里那句判断：长期任务不能只靠聊天记录续命，文件系统、进度文件、状态持久化才是真正的连续性来源。

Harness 真正解决的，不是“更聪明”，而是“每轮都重来一次”

视频里最关键的转折，是对 loop 的强调。

很多人一听 harness，会先想到“外面包了一层环境”。这不算错，但还是太空。更准确的说法是：harness 通过循环，把一个会在长上下文里逐渐变钝的 agent，变成一个每次都带着新上下文重新上场的 agent。

这和以前的思路差别很大。以前是尽量把一次会话拉长，靠压缩、总结、续写，把任务硬撑完。现在更有效的办法，反而是故意把长任务切成很多轮。每一轮只做一小步，每一轮都从一个干净入口开始，再从文件、状态、需求列表里把必要信息拿回来。

视频提到 Ralph 这类系统，会先生成需求文档或任务清单，再进入循环，一次只挑一个任务做，做完就测试、记录、更新状态，然后再开始下一轮。这个架构一点都不华丽，但恰恰因为它简单，才适合长任务。

我觉得这里有个很重要的认识变化：agent 的持续性，不应该主要寄托在它“记得住”，而应该寄托在系统“留得下”。

这也是为什么 Claude Code、Ralph、LangGraph 这些看起来路线不同的系统，最后都在同一个地方收敛：不是拼命喂更多上下文，而是把任务状态外置，把循环规则写死，把验证步骤插进去。

这期视频里的广告，应该怎么处理

你特别提醒了 YouTube 提示里有广告，要注意屏蔽。我看了字幕和 description，确实有两处明显广告位：

• 开头第 3 行先做了一句 Quick shout out to Cursor. More on them later.
• 中段有一整段 Cursor sponsor，内容包括：本地跑 agent、cloud agents、Slack 集成、自动巡检网站更新

这段广告的特点是，它和主题不完全无关。它借着“agent 在云端继续运行”“接 Slack 自动触发”这些点，顺手把 Cursor 的能力塞进来了。所以如果只是按关键词机械删掉，很容易把“loop / cloud / automation”这些和正文真的有关的概念也一起删没。

比较好的处理方法，不是简单按品牌名通杀，而是按功能角色区分：

• 凡是介绍 Cursor 产品能力、购买导流、使用场景演示的段落，全部视为广告素材，不进正文证据链。
• 凡是广告段里顺带提到的通用概念，比如云端继续运行、异步执行、外部触发，只能保留为“行业现象”或“常见 harness 能力”，不能写成这期视频的核心论证证据。

所以这篇文章里，我不会把“Slack 发请求给 Cursor 自动起 cloud agent”当成作者证明 harness 的关键例子。那是 sponsor 在借题发挥。真正该留下来的，是他后面对 loop、fresh context、task iteration、requirement file 的解释。

这件事和前面几篇知识沉淀，刚好能拼成一个完整图

如果只看这期视频，你会觉得 harness 主要是在讲“循环”。这没错，但还不够完整。结合知识库里前面几篇材料，图会更完整一点。

第一篇是《AI 代理 while 循环模型》。它把 agent 拆成 Brain / Planning / Tools / Memory / Loop / Guardrails 六件套。那篇更像骨架，告诉你 agent 至少有哪些器官。

第二篇是《Agent Harness 工程底座》。那篇往前又走了一步，把 harness 细化成 orchestration loop、tools、memory、context management、state persistence、error handling、guardrails、verification loops 等一整套生产组件。它回答的是：这些器官真正落地时，工程上长什么样。

第三篇是《Claude Code 大型代码库最佳实践》。那篇给了一个很现实的产品视角：CLAUDE.md、hooks、skills、plugins、MCP、LSP、subagents，这些东西加起来，对效果的影响不比模型小。它回答的是：在真实代码库里，harness 不只是概念，而是一组具体扩展点。

这期视频的价值，恰好在于它把这三件事串起来了：

• 为什么会从 prompt 走到 context
• 为什么 context 再往前走，会撞上长任务天花板
• 为什么 loop + external state + orchestration 会成为下一层答案

如果说前几篇笔记是在拆零件，这期视频更像是在讲“为什么这些零件会一起出现”。

我自己的判断：Harness 不是替代 prompt，而是把 prompt 降级成一个零件

视频里有一句我很认同：harness engineering 并不会淘汰 prompt engineering，也不会淘汰 context engineering。

这句话看起来像和稀泥，其实很关键。因为很多新概念流行时，最容易犯的错就是把旧层级整个判死刑。现实不是这样。prompt 还在，只是它不再是主角。context 还在，只是它不再承担全部连续性。真正的变化是：这两者从“决定成败的核心能力”，变成了“更大系统里的必要组件”。

这就像做 Web 系统。SQL 很重要，缓存也很重要，但没有人会说一个大型系统的核心竞争力只是“SQL 写得好”或者“缓存做得巧”。当复杂度上来以后，真正决定上限的，是整个系统的分层、状态流向、错误恢复、验证和部署方式。AI agent 现在走到的，就是这个阶段。

所以我更愿意把 harness 理解成一个信号：AI 编程正在从“会不会写 prompt”转向“会不会搭系统”。

边界也要说清楚：不是所有任务都值得上厚 harness

不过这里还有一个很容易被忽略的边界。

并不是只要听见 harness，就该马上上多 agent、任务树、状态机、十几个子进程。知识库里另一篇材料说得很实在：先把单 agent 做到极限，工具超过 10 个、任务边界明显分离、或者单轮上下文已经持续失真，再考虑拆。

我认同这个口径。很多人现在做 agent，最大的风险不是 harness 太薄，而是 harness 太厚。问题还没复杂到那个程度，就先上编排、路由、子 agent、长期记忆、工作流平台，最后系统自己变成了主要负担。

这期视频真正该拿走的，不是“每个 agent 都要上 harness 大工程”，而是下面这句更朴素的判断：当任务跨小时、跨阶段、跨验证回路时，单次会话已经不是合适的抽象。 到了那一步，你就该考虑 loop、state、checkpoint、verification 这些东西了。

我的补充：以后看 AI 编程产品，别只问模型，用这四个问题更有用

看完这期视频，我会更想用下面四个问题去看一个 AI 编程产品，而不是先问“你家接的是哪个模型”：

1. 它怎么拆任务？是一次性生成，还是有明确循环。
2. 它怎么存状态？是靠摘要续命，还是靠文件、进度、外部状态。
3. 它怎么验证结果？有没有测试、检查、回读、重试。
4. 它怎么处理长任务中的失真？是压缩上下文，还是重开干净回合。

这四个问题，基本比“prompt 写得漂不漂亮”更接近真实能力上限。

如果再往前走一步，我觉得未来几年最值钱的工作，可能不是继续发明更多 prompt 技巧，而是把 harness 做得更薄、更稳、更不打扰人。最好薄到用户感觉不到它存在，但它已经把 loop、状态、验证、权限都安排好了。

模型会越来越强，这几乎是确定的。真正拉开差距的，还是模型外面那层系统设计。

就这些。