> ## Content Index > Fetch the complete content index at: https://lucent.blog/llms.txt > Use this file to discover other available public pages before exploring further. # Prompt Engineering 已经过时，Harness Engineering 才是下一站 - URL: https://lucent.blog/hsxvgibx/ - Published: 2026-04-10T05:13:25.000Z - Updated: 2026-08-21T00:49:58.000Z - Author: Lucent - Tags: AI, 大模型 # 什么是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 时，很多人都会采用一种最简单的方式： - 一个模型 - 一条对话 - 一直跑到结束 但这种方式很快就会失效。 因为模型很不擅长长期保持一致性。 它会： - 忘记之前的决定 - 推翻自己 - 在错误方向上越走越远 - 即使已经发现问题，也会安慰自己“差不多了” 我越来越倾向于一种更像真实团队的结构。 至少应该拆成三层： 1. Planner 2. Generator 3. 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 的“操作系统”。 # 参考资料 1. [Anthropic, 《Effective Harnesses for Long-Running Agents》, 2025-11-26](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents?ref=lucent.blog) 2. [Anthropic, 《Harness Design for Long-Running Application Development》, 2026-03-24](https://www.anthropic.com/engineering/harness-design-long-running-apps?ref=lucent.blog) 3. [Simon Willison, 《Scaling long-running autonomous coding》, 2026-01-19](https://simonwillison.net/2026/Jan/19/scaling-long-running-autonomous-coding/?ref=lucent.blog) 4. [Simon Willison, 《Agentic Engineering Patterns》](https://simonwillison.net/tags/agents/?ref=lucent.blog) 5. [Ryan Lopopolo / Latent Space, 《OpenAI Frontier & Symphony》](https://www.latent.space/p/openai-frontier-and-symphony?ref=lucent.blog) 6. [Latent Space, 《Harness Engineering》专题讨论](https://www.latent.space/p/harness-eng?ref=lucent.blog)