当 AI Agent 真正开始修代码、跑命令、改配置，跨越几十轮工具调用去完成一个长任务时，问题会迅速从「模型能不能做」变成「系统能不能让它稳定、安全、可恢复地做完」。这就是 Harness 开始变得重要的原因。

Harness 不是一个新框架，也不只是 prompt 外面包一层工具调用，而是 Agent 外部那套负责运行、约束、验证、记录、审批和恢复的工程系统。本文借 10 篇来自 Anthropic、OpenAI、LangChain 和 Inngest 的 Harness 相关博客，梳理 Agent 从 Demo 走向生产系统时绕不开的一条主线。

01 什么时候需要 Agent，什么时候只需要 Workflow？

判断是否需要 Agent，关键不在技术新旧，而在任务本身是否真的需要自主决策。Anthropic 在《Building Effective AI Agents》中强调：不要一上来就把系统做成高度自治的 Agent。很多任务其实更适合 Workflow，也就是提前设计好的流程。

真正需要 Agent 的任务，通常具备几个特征：任务路径无法提前完全枚举、模型需要根据中间结果继续决策、任务需要调用多个工具并根据反馈调整下一步、任务可能跨越较长时间且状态不断变化。

Agent 的工程化第一步，不是让模型更自由，而是先判断任务到底需不需要自由。Harness 的复杂度应该和任务复杂度匹配。

02 工具不是 API，而是 Agent 的操作界面

Agent 能否可靠行动，很大程度上取决于工具是否被设计成它真正看得懂、用得准的操作界面。Anthropic 在《Writing effective tools for AI agents》中指出：给 Agent 设计工具，不是在暴露内部 API，而是在设计模型可理解、可选择、可恢复的行动接口。

一个好工具应该做到：名称清晰、参数少而明确、返回结构稳定、错误反馈可行动、权限边界清楚、工具粒度合适。工具不是外设，而是 Agent 改变外部世界的手。工具设计得越差，Agent 的行动空间就越混乱。

03 Harness Engineering：把「模型会做」变成「系统能交付」

OpenAI 在《Harness engineering》中讨论的重点，不是单纯调 prompt，也不是给模型接更多工具，而是如何通过约束、验证和反馈，构建可靠的 agent-first 软件。

Harness Engineering 的本质，是把大模型的不确定性装进可检查、可回滚、可复现的工程闭环。模型负责提出动作，Harness 负责让动作可控、可查、可修。所谓 agent-first software，也不是推翻传统软件工程，而是把传统工程里的测试、权限、回滚、观测性，前移到 Agent 的运行过程中。

04 Harness 不是 Framework：一个管抽象，一个管运行

Inngest 在《Your Agent Needs a Harness, Not a Framework》中提醒：真正把 Agent 推向生产时，最先崩的往往不是抽象层，而是运行层。Framework 解决的是「怎么写 Agent」，Harness 解决的是「Agent 怎么稳定地跑完任务」。

该博客更愿意把 Harness 理解成 Agent 的生产运行时。尤其是长任务场景，真正关键的是 durable execution：任务中断后能继续，工具失败后能重试，外部事件到来后能恢复上下文。

05 长任务 Agent 的关键是状态，而不是更长上下文

Anthropic 在《Effective harnesses for long-running agents》中强调：长任务需要外部状态管理。短任务 Agent 拼的是推理质量，长任务 Agent 拼的是状态纪律。

一个可靠的长任务 Harness，至少要考虑：Session log（记录全过程）、Checkpoint（保存可恢复状态）、State summary（压缩成摘要）、Workspace（维护工作产物）、容错策略（失败后如何继续）、Validation loop（判断是否完成）。更长上下文不是长任务 Agent 的全部答案，结构化状态管理才是。

06 Meta-harness：把 Brain、Hands、Logs 拆开

Anthropic 在《Scaling Managed Agents: Decoupling the brain from the hands》中提出：不要让模型直接背负整个运行系统。可以把 Agent 拆成 Brain（模型）、Hands（工具层）、Session Log（记录）、Harness Loop（调度）和 Sandbox（隔离环境）。

这种拆分的好处是 Brain 可以换模型，Hands 可以换工具，Session log 可以独立审计，Sandbox 可以独立控制风险。Session log 不是聊天记录的美化版，它应该记录目标、动作、工具结果、关键决策和失败原因。

07 应用开发 Agent 是 Harness 的压力测试

应用开发几乎把长任务 Agent 的问题都集中到了一起：需求模糊、文件多依赖复杂、修改互相影响、必须运行验证、UI 需预览、用户可能中途变卦。这类任务不是「让模型生成一段代码」就结束了，它更像一个持续循环。

因此，应用开发 Agent 的 Harness 至少要提供：稳定的项目工作区、文件读写能力、命令执行环境、预览或测试反馈、错误日志管理、变更记录、用户确认与中断机制、失败恢复能力。

08 Claude Code auto mode：自治度越高，审批越要系统化

当 Agent 能执行真实操作后，哪些动作可以自动执行，哪些必须问用户？Claude Code auto mode 尝试走中间路线：用分类器和策略系统来判断操作风险。审批不再只是一个人类按钮，而变成 Harness 里的一层安全能力。

危险操作通常包括删除文件、安装依赖、访问网络、修改环境变量等。它们不一定都要禁止，但必须被识别、分级和记录。真正可靠的 auto mode，不能只靠一次风险判断，还需要 sandbox 限制影响范围，用日志留下证据，用撤销或恢复机制兜底。

09 不换模型，只改 Harness，也可能提升 Agent 表现

LangChain 在《Improving Deep Agents with harness engineering》中指出：Harness 改进本身，也可能显著改变 Agent 的基准表现。Deep Agent 的最终表现，取决于上下文组织、任务拆分、工具好用程度、执行循环稳定性、错误恢复能力等。

同一个模型，换一套 Harness，表现可能完全不同。工具描述更清楚，模型就少走弯路；状态摘要更稳定，长任务就不容易丢目标。Agent benchmark 的提升未必都来自模型升级，很多时候，真正变强的是模型外面的执行系统。

10 评测 Deep Agents，必须评测轨迹、状态和恢复能力

LangChain 在《Evaluating Deep Agents: Our Learnings》中强调：Deep Agent 的评测要复杂得多。Agent 不是一次输出，而是一段轨迹。最终答案当然重要，但过程同样重要。

Deep Agent 的评测至少应该覆盖三层：Final result（最终任务是否完成）、Trajectory（中间步骤是否合理）、Runtime state（状态、工具、权限和恢复机制是否可靠）。未来讨论 Agent 能力时，只说模型版本是不够的；Harness 设定、工具环境和评测协议同样应该被披露。

总结：Agent 是一套运行系统

把这 10 篇文章放在一起看，它们都在指向同一个方向：Agent 正在从「模型能力展示」进入「系统工程竞争」。

当模型已经足够强，Agent 产品还差好的工具接口、稳定的执行环境、状态管理、日志、检查点、权限系统、sandbox、自动审批、可观测性和评测协议。把这些东西加起来，就是 Harness。

下一阶段的 Agent 竞争，可能不会只发生在模型参数、上下文长度和 benchmark 排名上，它也会发生在 Harness 上：谁能更好地组织长任务状态？谁能更安全地放大自治能力？谁能在失败后恢复，而不是从头再来？

模型让 Agent 看起来聪明，Harness 让 Agent 真的能干活。