啥是Harness？从agent loop到deepseek harness，探究 Harness 的演化之路
最近一年，AI Agent 领域里有一个词出现得越来越频繁：
Harness。
2025 年 11 月，Anthropic 在研究 Long-Running Agent 时，专门讨论怎样设计 Harness，让 Agent 能够跨多个 Context Window 持续工作。
2026 年 1 月，OpenAI 在拆解 Codex 内部工作原理时，直接把支撑 Codex 的核心 Agent Loop 和执行逻辑称为 Codex Harness。
2 月，OpenAI 又发表了《Harness engineering》，讨论怎样通过环境、工具、知识和反馈机制，让 Codex 能够长期可靠地工作。
3 月，LangChain 专门发表《The Anatomy of an Agent Harness》，开篇就用一句话概括：
Agent = Model + Harness。
4 月，OpenAI 更新 Agents SDK，提出 model-native harness，把文件系统、Memory、Sandbox 等能力进一步纳入 Agent Runtime。
随后，字节把 DeerFlow 2.0 从原来的 Deep Research Framework 重构成 Super Agent Harness；DeepSeek 则开源 DeepSeek Harness，把 Everything is a Plugin 作为核心架构原则。
到了 7 月，Microsoft Agent Framework Harness 正式发布，Harness 已经成为 Agent 基础设施中一个越来越明确的概念。
短短不到一年，Anthropic、OpenAI、LangChain、Microsoft、字节和 DeepSeek 都开始密集使用 Harness 这个词。
那么，Harness 到底是什么？
简单来说：
模型负责决定下一步做什么，Harness 负责提供工具、环境、上下文和运行机制，让模型真的能够一步一步把事情做完。
比如你让一个 Coding Agent：
检查这个项目，
找到 Bug，
修改代码并跑测试。
模型判断应该先查看项目目录，但模型本身不会真的执行 ls。
Harness 去执行。
模型判断应该读取 user.py，Harness 去读取文件；模型发现 Bug，决定修改代码，Harness 写入文件；模型决定运行 pytest，Harness 调起 Shell；测试失败以后，Harness 再把结果交回模型，模型继续判断下一步。
因此可以把一个 Agent 简单理解成：
Agent
│
├── Model
│ └── 推理、判断、决定下一步
│
└── Harness
└── 让这些决策真正执行起来
今天一个完整的 Harness 可能已经包括 Agent Loop、Tools、Filesystem、Shell、Sandbox、Context Management、Memory、Session、Permission、Sub-agent、Persistence 等很多东西。
但 Harness 并不是突然出现的。这些能力是在过去几年 Agent 的发展过程中，一层一层长出来的。如果沿着时间往回看，就会发现它的演化路线其实非常清楚。
2022：Agent Loop 出现，Harness 有了最初的骨架
2022 年，ReAct 提出把 Reasoning 和 Acting 结合起来。
在此之前，LLM 最典型的工作方式是：
Prompt
↓
Model
↓
Answer
用户问一个问题，模型生成一个答案。但现实中的很多任务不是生成一次文本就能完成的。
比如：
帮我查一下今天的天气，
再决定要不要带伞。
模型首先需要判断：
我不知道实时天气
↓
查询天气
↓
得到结果
↓
根据结果继续判断
于是 ReAct 把模型的工作过程变成：
Reason
↓
Action
↓
Observation
↓
Reason
↓
Action
↓
...
ReAct 当时并没有讨论今天意义上的 Harness，但它建立了一个非常重要的基础：
Agent Loop。
把这个过程压缩成代码，其实只有几行：
while not done:
action = model(context)
result = execute(action)
context = update(context, result)
模型决定下一步，外部环境执行，执行结果重新交给模型，模型继续决定下一步。
今天再看，这就是 Harness 最原始的骨架。
有意思的是，到了 2026 年，OpenAI 在解释 Codex 的工作原理时，最核心的结构仍然是这个循环：模型推理，需要工具时发起 Tool Call，Harness 执行工具，再把结果放回 Context，直到模型认为任务完成。OpenAI 将负责协调用户、模型和工具之间交互的核心逻辑称为 Agent Loop。
所以 Harness 后来虽然变得越来越复杂，最里面那个“发动机”其实一直没有发生根本变化：
决策
↓
行动
↓
反馈
↓
再决策
↺
2023：Tool Calling 普及，模型开始真正“动手”
只有 Agent Loop 还不够，因为模型本身只能生成 Token，它不会真的：
搜索网页
查询数据库
运行 Python
调用 API
修改文件
所以接下来最重要的一步，就是给模型 Tools。
2023 年 6 月，OpenAI 正式在 GPT-4 和 GPT-3.5 Turbo 中加入 Function Calling，让开发者可以把函数定义告诉模型，再由模型判断什么时候需要调用哪个函数。
于是 Agent 的基本结构变成：
Model
↓
选择 Tool
↓
外部系统执行
↓
Tool Result
↓
Model
这一步看起来简单，但意义很大，因为从这里开始，LLM 不再只是：
“告诉你应该做什么。”
而开始变成：
“决定做什么，然后让外部系统真的去做。”
此时一个最简单的 Harness 已经初具雏形：
Agent Loop
+
Tool Registry
+
Tool Execution
+
Context Update
不过这个阶段，行业关注的重点仍然是 Tool Calling，因为很多 Agent 任务还比较短：调用搜索，拿到结果；调用数据库，拿到数据；最后生成答案。只要几轮就结束了。真正让 Harness 开始迅速变复杂的，是 Agent 开始真正操作计算机。
2024：Agent-Computer Interface 出现，开始给 Agent 一台“电脑”
到了 2024 年，一个很重要的变化发生了。
人们开始意识到：
如果 Agent 真要像人一样工作，只给它几个专用 API 可能是不够的。
比如 Coding Agent。
写代码不是：
调用一个 Tool
↓
完成
而是：
查看项目
↓
搜索代码
↓
读取文件
↓
修改代码
↓
执行命令
↓
运行测试
↓
发现错误
↓
重新修改
↓
再次测试
于是模型真正需要的开始变成：
Filesystem
Shell
Editor
Git
Test Runner
2024 年，SWE-agent 提出了一个很重要的概念：
Agent-Computer Interface，ACI。
它的核心观点是：就像人类需要设计良好的计算机界面一样，Agent 也需要专门为它设计的计算机接口。
SWE-agent 因此没有只给模型几个简单 API，而是专门设计了代码浏览、文件编辑、搜索和命令执行等接口。
它的实验还说明了一件很重要的事情：
模型不变，仅仅改变模型与计算机之间的接口设计，也可能明显影响 Agent 的任务表现。
这意味着 Agent 能力开始不再只是：
Model
而越来越像：
Model
+
Environment
+
Interface
+
Execution Logic
这其实已经非常接近今天 Harness 的思想，Agent 身边的基础设施也开始从：
Model + Tools
逐渐变成：
Model
+
Agent Loop
+
Filesystem
+
Shell
+
Editor
+
Git
+
Tests
换句话说，这个阶段真正发生的变化是：
我们不再只是给 Agent 几个工具，而是开始给它一个完整的工作环境。
SWE-agent 后来把这套 ACI 设计公开成了完整的官方文档，包括文件查看、编辑、搜索以及执行反馈等机制。
2025：Long-Running Agent 出现，Harness 开始真正成形
Agent 有了 Loop，有了 Tools，也有了 Filesystem 和 Shell。
接下来一个问题自然出现：
如果它需要连续工作很久怎么办？
一个任务如果只需要五次 Tool Call，前面的东西已经够用了。但如果 Agent 要连续工作几十分钟甚至几个小时，就会迅速碰到新的问题：
Context 满了怎么办？
前面做过的事情忘了怎么办？
Agent 中途退出怎么办？
新的 Session 怎么知道之前做到哪里？
Shell 命令有危险怎么办？
模型说完成了，
但实际上测试没通过怎么办？
这时候问题已经从：
“模型会不会调用工具？”
变成：
“怎么让 Agent 长时间稳定运行？”
2025 年 11 月，Anthropic 专门发表《Effective harnesses for long-running agents》，研究的就是这个问题。
Anthropic 当时使用 Claude Agent SDK，让 Agent 完成需要跨多个 Context Window、持续数小时甚至数天的软件任务。
他们发现，单纯依赖 Context Compaction 仍然不够。
一个新的 Session 启动以后，并不会天然知道：
之前做了什么？
哪些功能已经完成？
现在项目是什么状态？
下一步应该做什么？
于是 Anthropic 设计了一套 Harness 策略：
让初始化 Agent 建立工作环境和进度文件，让后续 Agent 每完成一部分工作就保存状态、运行测试并提交 Git，让下一次 Session 可以从这些外部信息中恢复工作。
这里发生了一个很关键的变化，Harness 开始不再只是：
帮模型执行 Tool
而开始负责：
让 Agent 的工作过程能够持续下去
于是很多后来成为现代 Harness 核心能力的东西开始变得重要：
Session
Persistence
Context Management
Compaction
Recovery
Verification
Harness 开始真正像一个 Runtime 了。
2026：Harness 从工程实践变成独立的 Agent Runtime
到了 2026 年，变化开始明显加速。
1 月，OpenAI 在《Unrolling the Codex agent loop》中直接讨论 Codex Harness。
Codex 的 Agent Loop 在运行过程中可能进行数百次 Tool Call，随着交互不断增加，Prompt 会越来越大，因此 Harness 还需要负责 Context Window Management，并在达到阈值以后进行 Compaction。
2 月，OpenAI 又发表《Harness engineering》。
这篇文章有一个很重要的观察：
当 Codex 无法完成某项任务时，团队并不是简单地告诉模型“再试一次”，而是反过来检查：
环境里是不是缺少某个工具、抽象、文档、反馈机制或者可执行约束？
这已经很能说明 2026 年 Agent Engineering 的变化。
以前大家更关心：
Model 能不能做？
现在开始越来越关心：
Environment 能不能让 Model 做？
3 月，LangChain 在《The Anatomy of an Agent Harness》中直接给出：
Agent = Model + Harness
并把 System Prompt、Tools、Skills、MCP、Filesystem、Sandbox、Sub-agent、Hooks、Middleware 和 Compaction 等都纳入 Harness 的讨论范围。
4 月，OpenAI 更新 Agents SDK，提出 model-native harness，进一步把 Filesystem、Memory、Sandbox Execution 等能力整合进 Agent Runtime。
7 月，Microsoft Agent Framework Harness 正式发布，官方把 Loop、Planning、Memory、Context Management、Human Approval 和 Telemetry 等能力直接打包成一个 batteries-included Harness。
走到这里，Harness 的边界已经比几年前清楚很多，它不再只是一个 Agent Loop，也不只是 Tool Calling 的封装，一个现代 Harness 大致已经变成：
Model
│
决定下一步
↓
┌────────────────────────┐
│ Harness │
│ │
│ Agent Loop │
│ Tools / Skills │
│ Filesystem │
│ Shell │
│ Sandbox │
│ Context Management │
│ Memory │
│ Session │
│ Permission │
│ Sub-agents │
│ Persistence │
│ Verification │
│ Observability │
└────────────────────────┘
│
执行
↓
Real World
当然，这不是一个行业标准，不同项目对 Harness 的边界划分并不完全相同，但它们已经越来越集中地在解决同一个问题：
怎样给模型提供一套运行环境，让它能够在真实世界中持续、可靠、安全地完成任务。
这也是 Harness 和传统 Agent Framework 在关注点上的一个区别。
Framework 更偏向：
怎么搭建 Agent。
Harness 更偏向：
Agent 搭好以后怎么真正跑起来。
两者并不是互斥关系，一个 Agent Framework 完全可以包含自己的 Harness。
现在看两个例子：DeerFlow 和 DeepSeek Harness
理解了前面的演化，再来看目前国内两个比较有代表性的 Harness，就容易很多了，它们其实代表了两种不同的设计思路。
DeerFlow：先解决复杂任务怎么持续做完
DeerFlow 最初并不是 Harness，它原本是一个
Deep Research Framework。
但字节团队后来发现，社区拿 DeerFlow 做的事情越来越超出 Research，包括数据处理、PPT、Dashboard、内容工作流等，于是 DeerFlow 2.0 被从头重写。官方现在把它定义成：
open-source super agent harness。
核心目标就是让 Agent 能够处理 Long-Horizon Task。
因此 DeerFlow 默认提供了一套适合复杂任务的 Runtime 能力：
Sub-agents
+
Skills
+
Tools
+
Filesystem
+
Sandbox
+
Context Engineering
+
Persistent Memory
它的 Lead Agent 可以根据任务需要把工作交给 Sub-agent。
Sub-agent 拥有独立 Context。
需要执行代码时进入 Sandbox。
大量中间结果可以留在 Filesystem。
长期需要保存的信息进入 Persistent Memory。
Context 则只保留当前模型真正需要看到的内容。
所以 DeerFlow 更像是在回答：
如果一个 Agent 要连续工作几十分钟甚至几个小时，我们应该给它配一套怎样的运行环境？
它代表的是一种比较典型的 Opinionated Harness：
先把 Long-Horizon Agent 经常需要的能力组合好，让开发者可以直接使用。
DeepSeek Harness：再进一步，把 Harness 本身插件化
DeepSeek Harness 问的问题不太一样。
它更关注：
Harness 里面这些能力，本身应该怎样组织？
DeepSeek 给出的答案非常鲜明：
Everything is a Plugin。
截至 2026 年 9 月，DeepSeek Harness 仍处于 Developer Preview，官方也明确提醒接口还在快速演进。
它底层使用一个叫 Cordis 的插件框架。
Cordis 负责插件的挂载、卸载、依赖、事件和共享 Context，而真正的 Agent 能力由插件提供。
官方目前列出的范围包括：
Models
Tools
Skills
Sessions
Sandboxes
Storage
Loops
Scheduling
UI
甚至 Agent Loop 本身也是插件。
DeepSeek 官方架构文档明确写道：
Model Adapter、Tool Registry、Session Log，包括 Agent Loop 本身，都是插件，因此可以通过配置替换。
把它压缩成一张图，大概是：
Cordis Context
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Model Tools Session
Plugin Plugin Plugin
│ │ │
├────────── Sandbox ────────────┤
│ │ │
├────────── Skills ─────────────┤
│ │ │
└──────── Agent Loop ───────────┘
所以 DeepSeek Harness 的重点并不是：
“我提供了多少 Agent 功能。”
而是：
这些能力能不能被自由组合和替换。
一个简单 Coding Agent 可以使用：
Model
↓
Tool
↓
Model
↓
Tool
↓
Done
复杂 Research Agent 则可以组合成：
Plan
↓
Sub-agents
↓
Parallel Research
↓
Summary
↓
Verification
两种工作模式都可以建立在同一个 Harness 底座上，因此可以把 DeerFlow 和 DeepSeek Harness 的区别简单理解成：
DeerFlow
先面对 Long-Horizon Task
↓
把适合复杂任务的一套 Runtime
直接组合好
DeepSeek Harness
先面对 Harness 本身
↓
把 Runtime 中的各种能力
全部做成可组合插件
前者更强调：
复杂任务怎样开箱即用地跑起来。
后者更强调：
Agent Runtime 本身怎样做到通用和可替换。
两条路线并不冲突，反而很好地说明了 Harness 发展到今天以后，已经开始出现不同的架构流派。
最后理解 Harness
现在重新看这条时间线：
2022
Reason + Act
↓
Agent Loop
2023
Tool Calling
↓
模型开始操作外部世界
2024
Agent-Computer Interface
↓
Filesystem / Shell / Editor
↓
Agent 开始拥有完整工作环境
2025
Long-Running Agent
↓
Session / Persistence
Context Management / Recovery
2026
Modern Agent Harness
↓
Sandbox / Memory / Skills
Sub-agents / Permission
Verification / Observability
↓
Composable Agent Runtime
就会发现 Harness 并不是什么突然出现的新技术，它更像是 Agent 一路发展以后自然形成的结果。
最早，模型只需要回答问题。
后来，它需要调用工具。
再后来，它需要操作一台计算机。
再往后，它需要连续工作几个小时。
每向前走一步，模型周围就必须增加一层新的工程能力。
这些能力不断积累：
Agent Loop
Tools
Filesystem
Shell
Sandbox
Context
Memory
Session
Permission
Sub-agent
Persistence
Verification
...
最后，人们发现：
这些东西本身已经值得被当成一个独立的系统来设计。
这个系统，就是 Harness。
参考资料
- Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, 2022。
- OpenAI, Function calling and other API updates, 2023。
- SWE-agent, Agent-Computer Interfaces Enable Automated Software Engineering, 2024。
- Anthropic, Effective harnesses for long-running agents, 2025 年 11 月。
- OpenAI, Unrolling the Codex agent loop, 2026 年 1 月。
- OpenAI, Harness engineering: leveraging Codex in an agent-first world, 2026 年 2 月。
- LangChain, The Anatomy of an Agent Harness, 2026 年 3 月。
- OpenAI, The next evolution of the Agents SDK, 2026 年 4 月。
- ByteDance, DeerFlow 2.0 官方 README、Core Concepts 与 CHANGELOG，核验至 2026 年 9 月。
- Microsoft, The Microsoft Agent Framework Harness is now released, 2026 年 7 月。
- DeepSeek, DeepSeek Harness 官方页面、GitHub README 与 Architecture 文档，核验至 2026 年 9 月。
小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用
更多推荐
28
0- 0
已为社区贡献1条内容
所有评论(0)