什么是Harness?
最近，我看了两篇关于 Agent 的文章，都来自 Anthropic：
2025 年 11 月 26 日，《Effective Harnesses for Long-Running Agents》
2026 年 3 月 24 日，《Harness Design for Long-Running Application Development》
前一篇讨论的是：如何让 Agent 真正能稳定地连续运行。
后一篇则进一步往前推，开始讨论：当 Agent 需要持续开发一个复杂应用时，Harness 应该长成什么样。
我越来越觉得，这两篇文章真正重要的地方，不是提出了某个具体技巧，而是在于它们共同指向了一件事：
Agent 的竞争力，正在从模型能力，转向模型外面的那层“操作系统”。
过去一年，很多人都在讨论：到底是 Claude 更适合做 Agent，还是 GPT 更适合；到底是模型推理能力重要，还是工具调用能力重要。
但如果真的做过一个需要连续运行半小时、一小时，甚至更久的 Agent，很快就会发现：
模型其实不是最大的瓶颈。
真正的问题，往往出现在模型之外。
例如：
任务跑到第 40 分钟，上下文已经乱掉了
模型忘了自己之前做过什么
同一个问题被重复修了三次
工具调用越来越偏
明明已经失败了，模型却还在说“应该已经完成”
一旦中断，就只能从头再来
这些问题，本质上都不是模型能力问题，而是缺少一套围绕模型的“运行系统”。
我越来越觉得，大模型更像 CPU，而真正决定 Agent 是否可靠的，是外面的那层系统。
我把它理解成 AI Agent 的“操作系统”。
这个东西，现在通常被叫做 Harness。
“Harness” 这个词现在其实很难直接翻译。
它原本的意思更接近“马具”或者“控制装置”——不是替马奔跑，而是负责把力量约束起来、引导到正确方向。
放在 Agent 里，我更愿意把它理解成：
一套围绕模型的运行框架
一层约束、调度和状态管理系统
或者更准确地说：AI Agent 的操作系统
模型负责产生能力，而 Harness 负责让这些能力真正能够长期、稳定、可恢复地运行。
很多人第一次看到 Harness，会以为它指的是：
一个 Agent 框架
一个工作流引擎
一个 SDK
一套 Anthropic 内部工具
但我觉得，这些理解都不够准确。Harness 更像是一种系统设计思路。
它真正回答的问题是：
如果一个模型需要连续工作几十分钟、跨多个上下文、不断调用工具、还能随时恢复，那么整个系统应该怎么设计？
因此，Harness 不是某一个具体功能，而是一整套围绕 Agent 的设计原则。
它通常会涉及：
如何保存状态
如何做任务拆解
如何管理上下文
如何做外部 Memory
如何调度多个 Agent
如何恢复与回滚
如何做权限与工具控制
所以，Harness 更像：
Web 开发里的 MVC
分布式系统里的事件驱动
Kubernetes 里的控制循环
操作系统里的进程调度与状态管理
这些都不是某一个产品，而是一种架构方式。
模型只是“会思考”，而 Harness 决定它“怎么活着”。
Agent 的瓶颈，已经从 Prompt 变成了状态管理
前两年，大家还在讨论 Prompt Engineering。
后来，大家发现 Prompt 不够了，于是开始讨论 Context Engineering：
如何组织上下文
如何给模型更多背景
如何做 Memory
如何压缩历史记录
但真正开始做长任务之后，又会发现，光会“组织上下文”依然不够。
因为一个长期运行的 Agent，本质上不是一次对话，而是一段持续的执行过程。
它会经历：
规划
执行
出错
修复
回滚
再继续
这已经不是聊天，而更像一个长期运行的软件系统。
所以，Agent 最重要的问题，不再是：
“这一轮 prompt 怎么写？”
而变成：
“任务现在进行到哪里了？哪些已经完成？哪些失败了？如果中断，如何继续？”
也就是说，真正重要的已经变成了状态管理。
我不再相信“一个 Agent 一路跑到底”
最开始做 Agent 时，很多人都会采用一种最简单的方式：
一个模型
一条对话
一直跑到结束
但这种方式很快就会失效。
因为模型很不擅长长期保持一致性。
它会：
忘记之前的决定
推翻自己
在错误方向上越走越远
即使已经发现问题，也会安慰自己“差不多了”
我越来越倾向于一种更像真实团队的结构。
至少应该拆成三层：
Planner
Generator
Evaluator
Planner 负责：
理解需求
拆解任务
定义目标
写出阶段性计划
Generator 负责真正执行：
写代码
调工具
修改文件
跑测试
Evaluator 则负责专门挑错：
检查结果是否真的符合目标
判断有没有遗漏
找 bug
否决错误结果
最关键的是，Evaluator 必须是独立的。
因为模型最不擅长的一件事，就是否定自己。
同一个 Agent，既负责干活，又负责验收，最后通常都会得出一个结论：
“虽然还有一点问题，但应该已经差不多了。”
这和真实的软件开发很像。
一个人写代码，一个人 Review，一个人做 QA。
未来真正可靠的 Agent，大概率也会是这种多角色协作，而不是单个模型一直跑到底。
真正的 Memory，不应该放在上下文里
一开始，大家都以为长任务的问题可以靠“压缩上下文”解决。
于是出现了很多办法：
Session Summary
Auto Compact
Context Collapse
Memory Compression
也就是不断把历史对话压缩，再塞回新的上下文。
但我后来越来越不相信这种做法。
因为无论怎么压缩，本质上都还是把状态存在模型脑子里。
而模型的记忆，本来就是不可靠的。
它会忘，会误解，会把旧信息重新编造成新的故事。
真正稳定的做法，应该是把状态写到模型之外。
例如：
FEATURES.md
TODO.md
CURRENT_TASK.md
PROGRESS.md
每执行一步，都更新这些文件。
这样，下一个 Agent 启动时，不需要继承上一段上下文，只需要重新读取这些状态文件。
它马上就知道：
任务目标是什么
已经做到了哪一步
哪些完成了
哪些还没完成
当前卡在哪里
我甚至觉得，未来 Agent 最重要的能力，不是“记住”，而是“持续写状态”。
因为只有外部状态，才是真正长期、稳定、可恢复的 Memory。
与其压缩上下文，不如直接重启 Agent
过去，大家总觉得上下文快满的时候，应该想办法继续压。
但实际运行久了之后，我发现另一件事：
上下文越长，模型越容易变得奇怪。
它会：
越来越保守
越来越焦虑
越来越想赶紧结束
开始忽略之前的重要信息
对错误越来越迟钝
所以我现在反而更倾向于一种更激进的方法：
不要继续压缩，而是直接换一个新的 Agent。
新的 Agent 只需要：
最新的状态文件
最新的 Git commit
当前目标
最近一次失败原因
然后从一个全新的上下文重新开始。
这样反而更稳定。
因为新的 Agent 没有背着几十页历史包袱，它只关注当前最重要的信息。
我把这种方式理解成 Context Reset，而不是 Context Compression。
未来很多长期运行的 Agent，可能都会变成一种不断“重启—继续—重启—继续”的形式。
Git 才是真正的 Checkpoint
很多人会把恢复机制理解成“保存对话”。
但我觉得，对长期 Agent 来说，真正可靠的 checkpoint 从来不是聊天记录，而是 Git。
如果每完成一个小步骤，就做一次 commit，那么整个任务就会变得非常稳定。
例如：
写完一个功能 → commit
修掉一个 bug → commit
测试通过 → commit
调整一个配置 → commit
这样一来，Agent 就有了明确的“历史节点”。
一旦后面开始跑偏，就可以：
回退到上一个稳定版本
重新生成后续步骤
对比哪一步开始出错
这其实和软件工程里的增量开发一模一样。
未来的 Agent，大概率会越来越像一个自动化的软件团队：
有计划
有任务单
有状态文件
有 Git 历史
有测试
有回滚
Agent 不再只是“会聊天”，而是在按照工程流程持续推进任务。
Harness 会逐渐替代 Prompt Engineering
如果把过去几年的 AI 发展放在一起看，我觉得可以明显看到一条演化路径：
2023：Prompt Engineering
2024：Context Engineering
2025 - 2026：Harness Engineering
过去大家比谁 prompt 写得更花。
后来大家比谁更会做 RAG、更会做 Memory、更会压缩上下文。
而接下来，真正决定 Agent 上限的，可能会变成：
有没有状态机
有没有任务拆解
有没有多 Agent 协作
有没有恢复机制
有没有外部状态
有没有 Git 与回滚
有没有独立 QA
换句话说，模型越来越像 CPU，而 Harness 越来越像操作系统。
CPU 再强，如果没有操作系统，也无法持续稳定地运行复杂程序。
同样，模型再强，如果没有 Harness，也很难真正承担长时间、复杂、可恢复的工作。
我越来越相信，未来真正有价值的 Agent 公司，拼的不会是谁拿到了最强模型。
而是谁先做出了属于 AI Agent 的“操作系统”。