Agent Harness 是什么？让大模型真正干成事
大模型负责推理，Harness 负责工具、上下文、权限、状态与验证。本文讲清 Agent Harness，并介绍 DeepSeek Harness 的插件化架构与使用边界。
摘要： 大模型负责推理，Harness 负责工具、上下文、权限、状态与验证。它把一次文本回答变成可执行、可反馈、可审计的任务闭环。本文从一个修 Bug 的场景讲清 Agent Harness，并介绍仍处于开发者预览阶段的 DeepSeek Harness。
你让 AI 修一个 Bug。
它很快给出一段代码：分析合理、写法漂亮，甚至连注释都很完整。
但接下来，复制代码、找到文件、执行测试、阅读报错、继续修改……还是得你自己来。
问题不一定出在模型不够聪明，而是它只有“脑”，没有一套可以稳定行动的“身体”。
Agent Harness，就是包裹在大语言模型外面的工程运行层。它负责把模型的判断变成真实动作，再把动作结果送回模型，形成一个可持续的执行闭环。
用一个公式记住它：
Agent = Model + Harness
模型负责思考，Harness 负责让思考变成行动。
一、裸模型为什么“会回答，却完不成任务”
大语言模型最擅长的事情，是根据输入生成下一段内容。
它可以分析代码、提出方案、预测哪种修改更可能有效。但离开外部系统后，它并不能天然访问你的仓库、终端、数据库或浏览器，也无法自行确认答案是否正确。
这带来三个直接问题。
1. 没有手：知道怎么改，却不能真的改
裸模型可以告诉你：“请修改 login.ts 中的状态刷新逻辑。”
但读取文件、写回修改、执行命令，都是外部工具提供的能力，不属于模型本身。
2. 没有持续状态：长任务容易断片
一个真实工程任务可能要经历：理解需求、定位代码、修改实现、补测试、等待 CI、处理 Review。
模型的一次调用只处理当前输入和上下文。任务进度、历史决策、测试结果以及团队约定，需要由外部系统保存，并在合适的时候重新交给模型。
3. 没有可靠边界：能调用工具，不等于应该调用
当模型获得终端、文件系统或生产接口后，能力越强，风险也越大。
哪些命令可以自动执行？哪些操作必须人工确认？哪些目录只读？哪些凭证不能出现？这些都不能只靠一句提示词保证，而要由可执行的权限策略和隔离环境约束。
Harness 的价值，正是给模型补上工具、状态和边界。
二、Harness 更像操作系统，而不是一条超级提示词
把大模型想成 CPU，会更容易理解 Harness。
CPU 提供计算能力，但真正让程序稳定运行的，是操作系统：它管理进程、内存、文件、设备和权限。
同样，模型提供推理能力，Harness 管理的却是整个工作过程：
- 这一轮应该给模型哪些上下文；
- 模型可以调用哪些工具；
- 工具在哪个环境中执行；
- 失败之后要不要重试；
- 任务做到哪一步；
- 哪些操作需要人工批准；
- 什么证据才算任务完成。
LangChain 对它有一个很有传播力的概括：“如果你不是模型，那你就是 Harness。” 这句话强调的是一个广义边界：模型之外，为智能体提供代码、配置、工具、状态和执行逻辑的部分，都可以被视为 Harness。
三、一个成熟 Harness，至少要解决六件事
Harness 不是某一个工具，也不是某一个循环。它通常由六类能力共同组成。
1. 上下文管理：决定模型此刻应该看见什么
当前文件、项目规则、终端输出、Git Diff、历史记录，并不是越多越好。
给少了，模型只能猜；给多了，关键信息会被噪声淹没。Harness 要负责检索、筛选、排序、压缩，并在上下文窗口有限的情况下保留真正影响决策的信息。
2. 工具系统：把“建议”翻译成“动作”
读写文件、搜索代码、执行测试、访问 API、查询数据库，都是 Harness 暴露给模型的工具。
工具不只是一个函数。它还需要清晰的参数、返回结果、错误信息、超时策略和审计记录。模型只有看见真实反馈，才能决定下一步做什么。
3. 执行环境：让动作发生在可控空间
代码是在本机、容器、云端虚拟机，还是受限沙箱里执行？
执行环境决定 Agent 能访问什么、能消耗多少资源，也决定失败之后是否容易清理和恢复。对可能运行未知代码的 Agent 来说，隔离不是附加功能，而是基础设施。
4. 会话与状态：让任务跨回合继续
计划、待办、工具结果、中间文件、失败原因，都需要被持久化。
好的状态管理不是把全部聊天记录一直塞给模型，而是能恢复任务现场：做过什么、为什么这么做、当前卡在哪里、接下来验证什么。
5. 权限与审批：把安全规则变成系统行为
只读操作可以自动执行，高风险写操作需要确认，危险命令直接禁止——这类策略必须在工具执行前生效。
换句话说，模型可以提出动作，但最终是否放行，应由 Harness 裁决。
6. 验证与可观测性：用证据定义“完成”
代码“看起来正确”不等于任务完成。
Harness 应当运行测试、类型检查、Lint 和构建，并记录每一步输入、输出和状态。失败结果会再次进入上下文，驱动模型继续修正；通过的验证结果，则构成可审计的完成证据。
四、Harness 真正改变的，是任务的基本单位
没有 Harness 时，AI 的基本单位是一次回答。
有了 Harness，基本单位变成了一个循环：
观察 → 判断 → 行动 → 验证 → 根据结果继续行动
假设任务是：“修复登录成功后用户信息没有刷新的问题，并补上测试。”
一个具备 Harness 的 Agent，可能这样工作：
- 读取项目规则和目录结构，定位登录与用户状态相关代码；
- 搜索调用链，确认问题发生在令牌写入之后、用户信息刷新之前；
- 修改实现，并展示变更内容；
- 补充覆盖正常路径和失败路径的测试；
- 运行测试，读取真实报错；
- 根据失败原因继续修改；
- 再次运行测试和静态检查；
- 汇总改动、验证结果与仍然存在的风险。
这里最重要的变化，不是 AI 一次就写对了，而是系统允许它根据真实世界的反馈持续修正，直到满足完成条件。
五、Framework 和 Harness，不必强行画一条绝对边界
很多人会问：Agent Framework 和 Agent Harness 到底有什么区别？
业界并没有完全统一的术语边界。一个实用的理解是：
- Framework 更关注如何开发和组合 Agent，例如模型接口、工具定义、工作流编排；
- Harness 更关注 Agent 如何在真实环境中持续运行，例如上下文、状态、权限、沙箱、审批、验证和恢复。
两者会重叠，而且经常由同一个项目同时提供。
因此，判断一个产品是不是 Harness，不必只看名字。更应该看它是否真正解决了三个问题：能否行动、能否持续、能否受控。
六、DeepSeek Harness：把“可替换”做成核心架构
截至 2026 年 8 月 14 日，DeepSeek 已经开源 DeepSeek Harness（dsh）。它最值得关注的，不只是“DeepSeek 也做了 Harness”，而是它选择了一个非常鲜明的架构原则：
一切皆插件。
根据 DeepSeek Harness 的官方架构文档，模型适配器、工具注册表、会话日志，甚至 Agent Loop 本身都以插件形式挂载到共享上下文中。这意味着模型、工具、存储、沙箱、审批策略和界面可以通过配置组合，也可以替换某个能力的提供者，而不必修改一个不可触碰的核心。
它的会话日志也是关键设计：模型能看见的内容，需要能够从日志中重建。分叉会话、恢复任务、回放过程、持久化与遥测，都以这条事件流为基础。
这正好说明 Harness 的本质：它不是“再包一层聊天界面”，而是在管理 Agent 的整个生命周期。
不过，DeepSeek 官方也明确标注：DSH 当前仍处于开发者预览阶段，并且会出现破坏兼容性的变更。
因此，它现在更适合：
- 研究插件化 Harness 的架构；
- 快速尝试不同模型、工具和沙箱组合；
- 为内部 Agent 平台验证扩展点；
- 参与生态早期建设。
如果要直接承载关键生产流程，则还需要评估版本稳定性、安全策略、可观测性、故障恢复和团队维护成本。
七、为什么 2026 年大家开始集中讨论 Harness
当模型能力持续提升后，Agent 的瓶颈越来越多地出现在模型之外。
同一个模型，接入不同的上下文策略、工具描述、执行环境和验证循环，最终任务成功率可能完全不同。团队也开始发现：做出一个演示不难，难的是让 Agent 在长任务里保持状态，在真实权限下安全执行，并且拿出可以验证的结果。
这也是为什么 Harness 正从内部工程名词走到台前。
LangChain 把 Agent 概括为“Model + Harness”；微软的 Agent Framework 也已经提供 Harness，把函数调用、上下文、待办、审批、可观测性等能力组合成可用的运行脚手架；DeepSeek Harness 则进一步把可组合、可替换放到架构中心。
这不是说模型不再重要，而是竞争维度变了：聪明的模型决定上限，扎实的 Harness 决定这份聪明能否稳定兑现。
八、判断一个 Harness 是否靠谱，看这五个问题
当你准备选型或自建 Harness，可以先问五个问题：
- 上下文从哪里来？ 能否定位来源、控制长度，并避免把敏感信息送给模型？
- 工具如何约束？ 是否有参数校验、超时、重试、权限和审计？
- 执行是否隔离？ 未知代码运行在哪里，资源和网络边界是什么？
- 任务如何恢复？ 中断后能否从稳定状态继续，而不是重新聊天？
- 完成如何证明？ 是否有测试、评估、日志和人工审批，而不只是模型自报成功？
如果这五个问题都没有明确答案，那么它更可能是一个 Agent Demo，而不是可以长期依赖的 Harness。
结语：给聪明的大脑，配上一套能工作的系统
大模型解决的是“怎么想”，Harness 解决的是“怎么把想法可靠地做出来”。
它给模型提供工具，让模型能够行动；保存状态，让任务能够持续；设置权限与沙箱，让行动可控；建立验证循环，让“完成”有证据。
所以，Agent Harness 不是给 AI 加一个漂亮外壳，也不只是给它套上缰绳。
它更像是为模型造了一套操作系统：
模型负责思考，Harness 负责让思考变成行动。
下一次评估一个 Agent 时，除了问“它用了什么模型”，不妨再追问一句：
它的 Harness，究竟做得怎么样？