为什么 Agent 需要 Harness

如果把一个很强的语言模型接到电脑上，它是不是就自动变成了一个很强的 Agent？不一定。模型也许能解释代码、提出计划、写出一段看起来合理的脚本，但真正开始干活以后，问题很快就会出现：它怎么打开文件？执行失败以后怎么知道错在哪里？任务超过一个上下文窗口怎么办？哪些命令可以直接运行，哪些操作必须等人批准？做完以后，谁来检查结果？包围模型、回答这些问题的执行系统，就是我们今天要谈的 Harness。这个英文词原本有驾驭、连接和约束的意思。在 Agent 领域，可以把它理解成一套运行支架：它既给模型接上工具，也给模型系上安全带。

先抓住最重要的一句话：语言模型和 Agent 不是同一个东西。语言模型接收上下文，生成下一段输出；Agent 则要在一个环境里采取行动，观察行动结果，再决定下一步。Harness 就处在模型和真实环境之间。它把模型的判断翻译成工具调用，把工具返回的结果整理成模型可以继续理解的上下文，还要维护任务状态、实施权限策略、控制运行生命周期。换一种更口语的说法，模型负责想，Harness 负责让这个想法能够落地，而且别在落地过程中失控。微软、LangChain、Anthropic 和 OpenAI 对 Harness 边界的表述并不完全一致，但它们指向的是同一个核心：模型周围那套让 Agent 真正运转起来的东西。

为什么最近大家越来越强调 Harness？一个直接原因是，模型会写一段答案，和系统能完成一个复杂目标，中间隔着很长的距离。OpenAI 在二〇二六年二月介绍 Harness 工程实践时提到，早期瓶颈并不只是模型能不能生成代码，更在于运行环境是否提供了合适的工具、内部结构、仓库知识、自动检查和反馈循环。这个观察很关键。假设你对两个使用同一模型的 Agent 说：修复这个项目里的问题。第一个只能看到一小段代码，然后输出修改建议；第二个可以搜索仓库、编辑文件、运行测试、阅读错误日志、重新修改，并在完成后展示验证结果。两者底层模型一样，实际能力却完全不是一回事。差距不一定来自谁更聪明，而可能来自谁拥有更好的工作环境。

长时任务最能暴露这个问题。一次问答可以在一个上下文里结束，但真实工作往往要经过几十个步骤，甚至跨越多次会话。模型可能先调查资料，再建立计划，接着修改文件、运行代码、记录失败原因，最后继续处理剩余任务。如果没有 Harness 保存文件、任务状态和中间结果，每一次上下文切换都像让一个人失忆以后重新上班。Anthropic 在二〇二五年十一月讨论长时运行 Agent 时，重点介绍了初始化 Agent、增量工作的 Agent，以及跨会话持久化。这里的核心并不神秘：把已经完成的工作可靠地留在环境里，把下一步行动写清楚，让后来的上下文能够从现场继续，而不是每次重新猜测现场发生过什么。

这也解释了为什么上下文管理不是简单地把更多文字塞给模型。上下文窗口再大，也会被长日志、工具定义、搜索结果和历史对话慢慢占满。Harness 需要决定什么现在必须留在眼前，什么可以压缩，什么应该存到文件或记忆系统，什么等到需要时再加载。大型工具输出还可能先被卸载，只保留摘要和位置。二〇二六年九月公布的 OpenAI Agents API，就把长会话、工具搜索、程序化工具调用、子 Agent 并行和托管沙箱放进了同一套产品能力里。这里可以看到一个趋势：Harness 不再只是开发者随手写的几段循环代码，而是在逐渐成为独立的系统层。

不过，记忆本身不等于可靠。把所有历史都保存下来，可能只是把旧错误也永久保存下来。编辑部的判断是，好的 Harness 至少要区分三类东西：当前任务必须知道的现场信息，可以长期复用的稳定信息，以及只在审计时才需要追溯的原始记录。它们不应该全部挤在同一个提示词里。以一条音频生产流水线为例，研究来源和证据关系需要保留，节目现在走到研究、写稿、审核还是合成阶段，也要持久化；但一次网页抓取产生的冗长原文，没有必要每一步都重新灌给模型。Harness 的价值不是让模型记住一切，而是让系统在正确的时候想起正确的东西。

接下来是行动边界。模型一旦可以调用工具，错误就不再只是说错一句话。它可能改动文件、运行程序、访问网络，或者触发一个会影响外部世界的操作。因此 Harness 必须回答：工具能看到什么？能改什么？网络是否开放？运行环境是不是沙箱？哪些操作可以自动执行，哪些必须审批？任务结束后进程和临时资源如何回收？OpenAI、LangChain 和微软关于 Harness 的资料都把沙箱、工具权限或生命周期控制放在重要位置。这里的原则不是让 Agent 什么都不敢做，而是让行动能力与风险相匹配。读一个文件和公开发布内容，不应该拥有相同的授权门槛。

Harness 还承担另一个经常被忽略的职责：把失败变成可以观察和修正的信息。没有反馈循环时，模型生成一次结果，系统就只能祈祷它是对的。有了执行和验证工具，过程会变成：提出行动，运行行动，读取真实结果，根据结果修正，然后再次验证。写代码时，反馈可能来自测试、静态检查和运行日志；制作节目时，反馈可能来自来源审计、结构检查、文本与分段的一致性检查。OpenAI 在 Harness 工程实践中强调可观测性、自动检查和反馈循环，原因就在这里。可靠性通常不是来自模型第一次永远正确，而是来自系统能够尽早发现错误，并给模型一条清晰的改正路径。

计划、并行化和子 Agent 委派也属于这一层。复杂目标通常不能靠一次工具调用完成，Harness 可以帮助模型拆分任务、安排依赖关系，并把相互独立的工作并行处理。不过，这些能力很容易被神化。多写一份计划，不代表计划就更正确；多开几个子 Agent，也不代表结果必然更好。并行任务可能重复劳动，子 Agent 可能带回互相冲突的信息，最后仍然需要一个明确的汇总和验证机制。所以编辑部的判断是，计划与委派只有在降低遗漏、缩短等待或隔离上下文时才有价值。否则，它们只是让流程图看起来更热闹。

到这里，我们可以重新理解 Agent 评估。Anthropic 关于 Agent 评估的讨论支持一个重要结论：实际被评估的对象，是模型与 Harness 共同组成的系统。只报底层模型名称，往往不足以解释一个 Agent 为什么好用。工具是否可靠，工具描述是否清楚，上下文如何裁剪，失败是否重试，验证是否覆盖关键风险，都会改变最终表现。反过来，一套为某个模型精心设计的 Harness，也不一定能原封不动地适配另一代模型。Anthropic明确提醒，Harness 编码中隐含的假设可能随着模型能力提升而过时。今天为了防止模型迷路而写下的强制步骤，未来也可能妨碍更强模型自主解决问题。

这带来一个很现实的问题：Harness 是不是越复杂越好？答案是否定的。Anthropic 的建议是从最简单的方案开始，只在任务确实需要灵活决策、工具使用或持续行动时，才增加 Agent 系统的复杂度。如果需求只是改写一段文字，或者根据固定输入生成固定格式，一次模型调用加上基本校验可能已经足够。硬要加入长期记忆、多 Agent、复杂计划和层层审批，不仅增加成本，也会创造新的故障点。Harness 应该由任务风险和任务长度驱动，而不是由功能清单驱动。

我们还需要保留一个证据上的克制。现有公开案例经常同时改变模型、提示词、工具和运行环境，因此很难普遍证明某一个 Harness 组件对所有任务都有独立的因果收益。不同资料对 Harness 的定义也尚未统一：有人强调运行时脚手架，有人把模型以外的代码、配置和执行逻辑全部算进去，还有人主要从长时任务和软件开发套件的实践来描述。与其争论哪个边界最正确，不如问一个更可操作的问题：在这个任务里，究竟是什么机制负责状态、工具、安全、反馈和恢复？只要这些责任没有消失，它们就必须被某个系统承担。

对方方编辑部这样的私人音频工作流来说，Harness 的作用尤其直观。模型可以判断选题、整理材料和撰写内容，但从研究到脚本、审核、语音合成再到发布，中间需要来源记录、阶段状态、失败重试、工具边界和必要的人工审批。课程和长期研究还需要跨会话记忆、计划、证据链与阶段性验证。这里真正可靠的分工是：模型负责需要语义理解和判断的部分，Harness 负责把过程变成可恢复、可审计、可约束的执行链。模型不必假装自己是数据库、权限系统和任务调度器，可靠代码也不必假装自己会做编辑判断。

设想一个看起来并不复杂的失败：你让 Agent 给一个代码仓库增加功能。模型先读需求，改了几个文件，跑测试时发现依赖缺失；它尝试补环境，又遇到上下文窗口将满，于是压缩了此前对仓库结构的理解。下一轮继续工作时，它只记得“测试没过”，却不再清楚哪些修改已经完成、失败发生在哪一步，也无法判断工作区里的文件是原始状态还是自己的半成品。模型每一轮可能都回答得通顺，但整个任务开始原地打转，甚至覆盖已经正确的结果。这里暴露的不是单纯的推理能力不足，而是执行系统没有可靠保存文件状态、中间结果、计划和验证记录。对长时任务来说，能够跨窗口续作，本身就是能力的一部分。

Harness 解决这类问题，可以拆成一个闭环。第一步是把目标转成计划，并决定哪些资料、工具和权限此刻需要加载；第二步是真正执行，比如读文件、运行代码或调用外部工具；第三步是观察，把工具返回、测试结果和异常记录下来；第四步是验证，判断结果是否满足目标，失败就修正计划再来一轮。上下文不够时，Harness 还要压缩历史、卸载庞大的工具输出，并把长期状态留在文件系统或记忆机制里。这样，模型不必在每次对话中重新背诵整个世界，只要拿到当前决策真正需要的信息。计划、执行、观察、验证，再加上持久化，才构成可以持续推进的工作循环。

但“能行动”必须和“行动受约束”同时设计。Harness 可以用沙箱限制代码影响范围，用工具权限和网络隔离控制模型能接触什么，再用审批节点拦住高风险步骤，并在任务结束、失败或超时后管理运行环境的生命周期。子 Agent 和并行化也是同一套逻辑：它们能加快资料搜集和任务拆解，却必须有清楚的输入、输出和汇总机制，否则只是把一个混乱任务复制成多个混乱任务。真正可靠的 Harness，不是替模型预写所有动作，而是给每次动作留下边界、反馈和可追踪的结果，让错误能够被发现、定位和纠正。

实际判断时，可以先问三个问题。第一，这项工作能否在一次上下文里完成，而且不需要调用工具？如果能，普通提示词往往更合适。第二，任务是否要跨会话保存进度、处理文件、运行代码，或者根据中间结果继续决策？只要答案是肯定的，就需要状态、工具和反馈循环这些最小 Harness。第三，行动失败会不会造成不可逆或对外影响？风险越高，沙箱、审批、审计和生命周期控制越不能省。这里没有统一的标准配方，而且今天针对模型弱点设计的流程，可能随着模型能力提升而过时。所以不要把编排层层叠加当成先进；更稳妥的原则，是从最简单的系统开始，只为已经出现的任务复杂度和风险增加结构，并持续检查哪些控制仍然必要。

所以，为什么 Agent 需要 Harness？因为智能如果不能被接入环境、保存进度、限制权限、观察结果并纠正错误，就还只是一次性的生成能力。Harness 把这种生成能力变成持续行动的系统能力。但最后也别把 Harness 当成新的万能词。它不是给模型套上的功能越多越先进，而是要用最少、最清楚的结构，解决任务中真实存在的状态、工具、安全和验证问题。判断一个 Agent 时，不妨少问一句它用了什么模型，多问几句：它怎样知道自己做到哪了？失败以后怎样恢复？行动边界在哪里？结果由什么验证？这些问题的答案，往往比模型名称更接近 Agent 的真实能力。