什么是 Agent Harness?揭秘 Claude Code、DeepSeek Harness 与 Hermes 背后的架构
2026年8月13日,DeepSeek 在 GitHub 上发布了名为 deepseek-harness 的代码仓库。短短两天内,该仓库便收获了 95,386 个 Star 和 8,826 个 Fork。尽管 Star 数和 Fork 数本身只是虚荣指标,但如此迅猛的增长速度暗示着其背后的价值远超运气成分。这是 2026 年开发工具在 GitHub 上增速最快的案例之一(Flowtivity,deepseek-ai/deepseek-harness)。
而在九个月前,一位名叫 Mario Zechner 的奥地利独立工程师发布了几乎截然相反的产品:一个名为 Pi 的编程 Agent,内置仅有四个工具,其他配置极少。Pi 花了大约一年时间通过自然增长才突破 91,600 个 Star,没有发布时的爆发期,只有那些尝试过并留下来使用的工程师们带来的缓慢复利式攀升(earendil-works/pi)。
因此,我们看到了两条截然不同的增长曲线,以及两种截然不同的设计理念。而在它们底层,却有着同一个词:harness。
如果你在任何层面上构建 AI Agent,这个词如今已无处不在。而市面上大多数关于它的解释,要么是营销文案,要么是箭头多到令人困惑的架构图。
本文首先定义什么是 Agent harness,随后将目前最流行的十款 Agent harness 放在一起,从 Claude Code、DeepSeek Harness 到 Pi,基于同一套五层架构进行比较。
阅读完本文,你将明白为何“harness”一词今年取代了“framework”成为开发者讨论中的常用语,以及 2026 年最受关注的几款 harness 在品牌包装之下有着怎样的本质差异。此外,你还能获取一个 60 行的 Python harness 示例用于自行运行,了解其周围堆栈层级(MCP、编排、可观测性)的拆解,以及为团队选型时的决策指南。
目录
什么是 Agent Harness?
Harness 是包裹在 LLM 模型外层的运行时外壳。模型本身只做一件事:接收文本流和可用工具列表,预测下一步该说什么或调用哪个工具。其余工作均由 Harness 负责。
这些枯燥乏味的底层管道包括:调用模型的循环逻辑、执行工具的代码、管理 40 轮以上上下文的内存系统,以及保护文件系统的沙箱。它是决定 Agent 在工具调用失败时能否恢复,还是直接挂起的基础设施。
图1:每个 Agent Harness 必须实现的五个部分,以围绕模型核心的循环形式呈现。模型位于中心,仅预测下一条消息或工具调用。其外围包括:负责将调用分发至文件系统、Shell 或外部 API 的工具路由器;决定哪些上下文保留至下一轮的内存层;在执行开始前将大任务拆解为步骤的规划层;以及约束工具可访问范围的沙箱边界。
循环箭头表示模型输出反馈为下一轮输入,正是这一机制将单次预测转化为持续工作直至任务完成的 Agent。
一位从业者从另一个角度给出了定义,本质上说的是同一件事:harness 负责补齐模型自己做不到的所有事——驱动目标从计划走向执行的循环、访问终端和文件系统等工具的能力、跨多轮对话持续存在的记忆层、对其派生的 subagent 的协调,以及约束它能触碰什么范围的权限规则(CellCog)。
具体来说,当你在 Claude Code、Cursor 或 Aider 里输入一个请求时,会发生以下流程:
Harness 组装提示词:包含你的请求、系统指令,以及模型可以调用的工具 schema 列表。
模型响应,通常是推理文字加一个或多个工具调用(
read_file、run_bash、edit,或 harness 提供的其他工具)。Harness 执行每个工具调用——理想情况下在沙箱中运行——并捕获输出。
Harness 把工具输出追加到对话中,再次调用模型。
循环往复,有时会持续几十轮,直到模型给出最终答案,或者 harness 达到轮次上限、成本上限,或被人工打断。
这个五步循环,有时被称为 agent loop 或 ReAct loop(得名于 2022 年那篇首次把推理和行动描述为交织过程的论文:Yao et al.),是市面上所有 harness 共有的部分。
真正拉开差距、决定一个 harness 好不好用的,是围绕第 3 步和第 4 步包裹的那些东西:执行前的规划质量、随着上下文膨胀记忆如何取舍内容、沙箱的隔离程度,以及 harness 能否派生一个更小的自身版本来处理子任务,而不污染主对话。
这四个环节任何一个出问题,外部表现都是一样的:agent 卡住、忘记自己正在做什么,或者在一个本该五轮完成的任务上把你的上下文窗口烧光。
从 Agent 框架到 Agent Harness:什么变了
2023 至 2025 年间,“框架”一词主导了智能体领域的讨论:LangChain、AutoGen 和 CrewAI 等工具代表了那一时期的主流。那时的框架本质上是库:你导入组件,自行选择模型调用,并亲手编写编排逻辑。它们提供的是构建模块。
而 Harness(执行外壳)是另一种产品形态。它直接交付了一个已构建好的循环,且这个循环在记忆、规划和安全方面有着明确的预设。你只需运行一条命令即可与之交互。
在 2025 年,Anthropic 的 Claude Code 让这种转变变得不可否认:它是一个原生于终端的智能体,能规划、编辑文件、运行测试并提交代码,全程无需你编写任何编排逻辑。
到 2026 年,“交付循环”这一模式已普遍出现在下文表格列举的十种 Harness 中,从 Claude Code、DeepSeek Harness 到 Cline 皆如此。“Harness”一词也开始被广泛用来描述这种形态,以区别于需要自行组装的框架。
从命名就能看出端倪:DeepSeek 的仓库名为 deepseek-harness,这呼应了由 Claude Code 引领的从“框架”到“Harness”的转变。
LangChain 的 Deep Agents 表明,行业现在将 “Harness” 视为一个独立的架构层。该项目旨在逆向工程 Claude Code Harness 的高效机制,并将其重构为一个开放且模型无关的库。
LangChain 团队对该项目的回顾将其归结为一个核心问题,用 Harrison Chase 的话说就是:“Claude Code 的哪些特质让它具备了通用性?我们能否将这些特质抽象并泛化?”
LangChain 在此也有其商业动机:它正在推销一个用于替代其所研究对象的方案,尽管命名权在于谁,但它提及的四种机制依然经得起推敲。
Deep Agents 封装了 Claude Code Harness 依赖的四个具体机制:
规划工具:强制模型在触碰文件前先写出步骤。这能减少模型在长会话中悄悄偏离任务的情况。
虚拟文件系统与沙箱:为智能体提供对代码库的结构化、隔离式读写访问权限。
子智能体委派:主智能体启动一个拥有独立干净上下文窗口的小型智能体来处理隔离的工作单元,完成后主智能体接收摘要报告。
上下文与记忆管理,包括压缩对话历史和中转大型工具输出的中间件,防止长会话撑爆模型的上下文窗口(LangChain)。
值得把这份清单记下来,因为这四大机制(规划、沙箱、委托、上下文管理)是每一套严肃的 Harness 都必须解决的工程难题,无论 Deep Agents 是否仍是业界提及的代表。其余的不过是品牌包装。
Agent Harness 方案一览
下表汇总了截至 2026 年 8 月最受开发者关注的 Harness 及其架构侧重。
| Harness | 开发方 | 优化目标 | 显著特点 |
|---|---|---|---|
| Claude Code | Anthropic | 端到端编码会话:规划、编辑、测试、提交 | 普及了“规划工具+子智能体”模式,现已被竞品效仿 |
DeepSeek Harness (dsh) |
DeepSeek AI | 全运行时模块化 | 两天内突破 95,000 GitHub stars。每个组件(模型、工具、沙箱、UI)都是可替换插件(GitHub)。 |
| Deep Agents | LangChain | 模型无关地复现 Claude Code 的 Harness 模式 | 提供开源库及 CLI,兼容任意支持工具调用的模型(LangChain) |
| Hermes Agent | Nous Research | 跨渠道持久化的自我改进助手 | 单一进程即可接入 Telegram、Slack、Discord、WhatsApp 和邮件等平台,并拥有不断增长的共享技能公共中心(Nous Research, GitHub) |
| Pi | Mario Zechner / Earendil Inc. | 极致极简:内置仅四个工具,其余均为可选的 TypeScript 扩展 | 非发布期内自然增长获得超过 91,600 GitHub stars(GitHub) |
Oh-My-Pi (omp) |
Can Bölük | Pi 的一个“大而全”分支,内置了整套 IDE 能力:LSP 诊断、基于 DAP 的调试器、持久化执行内核 | 用 Rust 重写了 Pi 的引擎,支持 60 多个模型提供商和 31 个内置工具(GitHub) |
| CellCog | CellCog | 面向广义知识工作的通用超级 Agent Harness | 截至 2026 年 8 月位居 DeepResearch Bench 榜首(得分 55.78),同一引擎原生支持视频、图像和文档输出(CellCog) |
| OpenHands | All Hands AI | 开源、Docker 化的自主软件工程师,内置 bash、浏览器和测试执行环境 | 前身为 OpenDevin。Docker 是默认沙箱,将每次会话的 shell 命令和文件写入与宿主机隔离(OpenHands Docs) |
| Aider | Paul Gauthier 及社区贡献者 | 以 Git 为核心的结对编程工具,Agent 的每一步都对应一次干净、可审查的提交 | 深受希望保持紧凑 diff 审查循环的工程师喜爱,长期口碑良好 |
| Cline | Cline Bot Inc. 及社区贡献者 | 模型无关、需人工审批的 VS Code 扩展 | 默认情况下,每次文件编辑和命令执行都会暂停,等你确认后才运行 |
其中一部分专攻编程场景,另一部分(尤其是 CellCog 和 Hermes Agent)则在尝试把 Harness 模式从代码推广到更广泛的知识工作领域。
面向编程的 Harness 可以默认有代码仓库、测试套件,以 diff 作为工作单元。而面向通用知识工作的 Harness 则必须为研究、写作和多步骤业务任务设计出等价的结构——这是一个更难、也远未标准化的问题。
如果你在为代码之外的用途评估 Harness,先问一个问题:它的“工作单元”是什么?是有人为其打造了 diff 的等价物,还是只是想当然地假设它已经存在?
Harness 应如何运作:三种相互竞争的设计理念
抛开营销话术,2026 年 Agent Harness 热潮的背后其实站着三种不同的工程押注。
图 2:构建框架的三种赌注,以三列并行展示。第一列 DeepSeek Harness 以插件内核为中心,模型、沙箱、记忆和 UI 均为可互换模块。
第二列 Claude Code 和 Deep Agents 以四大固定机制为中心:规划、虚拟文件系统、子智能体和上下文压缩。
第三列 Hermes Agent 以复利型技能库为中心,每次解决新问题都会让库变得更强大。这三列仅共享图 1 中的基础循环,循环之上的部分则是对“如何使智能体在长会话中保持可靠”这一问题的不同赌注。
赌注一:一切皆插件
DeepSeek Harness 基于名为 Cordis 的元框架构建,其设计在 DeepSeek 的论文《面向时空可组合性的编程范式》中有详细说明,核心思想归结为一点:所有组件均可在运行时替换(deepseek-ai/deepseek-harness)。
在实践中,这意味着模型、沙箱、会话存储、调度循环,甚至 UI 主题都是可互换的模块。该框架还附带一种“创作者模式”,用于检查运行中的系统、在内存中测试 Cordis 插件,并将它们组合成新的配置(DeepSeek)。
这里的赌注在于:没有任何单一架构能永远胜出,因此取胜之道是将架构本身变成配置文件。
赌注二:少量固定机制,执行到位
Claude Code 及随后的 LangChain 的 Deep Agents 押注相反:选定四种机制(规划、沙箱文件系统访问、子智能体委托和上下文压缩),并在确保每种机制可靠上下功夫。
清单中的每一项机制都足够成熟,以至于竞争者会直接照搬:上表将“规划加子智能体”这一模式的普及归功于 Claude Code,如今其他框架也纷纷效仿。这种设计之所以行得通,是因为这四项机制在每个任务中协同运行。漏掉其中一项,其他几项能在一段时间内弥补,直到长会话暴露出这一缺口。
第三注:复利式记忆。
Hermes Agent 押注认为,最大的未解问题在于会话之间发生了什么。大多数框架在每次新对话开始时都会重置为空白上下文。Hermes 则相反,当解决了非平凡问题时,它会提供将该方法保存为可复用技能的功能。之后,在面对类似的后续请求时,它会在从头推理之前先检查该技能库,从而随着使用时间的推移,在处理重复任务时变得更快(Nous Research)。
这既是优势,也是风险:如果技能库不加控制地增长,最终会变成一种债务,其存续时间远超当初编写它的理由。结合对 Telegram、Slack 和 Discord 等平台的原生调度和通道集成,其设计目标更接近一个驻留在服务器上的常驻助手,而非一个打开用一次就关掉的工具。
第四注位于其他三注之下:Pi 和 Oh-My-Pi 主张,其他框架内置的许多功能都是不必要的负担,对于清楚自己想要什么内容的工程师来说,四个工具加一个扩展系统胜过功能完备的平台。
Pi 的 GitHub 星数突破 91,600,主要得益于有机的口碑传播而非发布宣传活动,表明这一押注具有持久性。
这四个押注都有据可依。它们针对不同的失效模式进行优化:DeepSeek Harness 针对架构锁定,Claude Code 和 Deep Agents 针对不可靠的长会话行为,Hermes 针对跨会话的重复工作,而 Pi 针对臃肿。
因此,在你选择一个之前,先问自己哪种失效模式在当下消耗你的时间。答案将帮助你选择正确的智能体框架。
用不到 60 行 Python 构建一个最小化框架
以下示例使用 Anthropic 的 Messages API 构建了图 1 中的五步循环:一个模型、三个工具,以及一个不断调用模型的循环,直到它停止请求工具调用。你会发现本节讨论的所有失效模式都潜伏在这 60 行代码之中。
import subprocess
from anthropic import Anthropic
client = Anthropic()
TOOLS = [
{
"name": "read_file",
"description": "Read a UTF-8 text file from the working directory.",
"input_schema": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"],
},
},
{
"name": "write_file",
"description": "Write content to a file, overwriting it if it exists.",
"input_schema": {
"type": "object",
"properties": {
"path": {"type": "string"},
"content": {"type": "string"},
},
"required": ["path", "content"],
},
},
{
"name": "run_bash",
"description": "Run a shell command inside the sandbox directory and return its output.",
"input_schema": {
"type": "object",
"properties": {"command": {"type": "string"}},
"required": ["command"],
},
},
]
def execute_tool(name, tool_input):
if name == "read_file":
return open(tool_input["path"]).read()
if name == "write_file":
with open(tool_input["path"], "w") as f:
f.write(tool_input["content"])
return f"wrote {len(tool_input['content'])} bytes to {tool_input['path']}"
if name == "run_bash":
result = subprocess.run(
tool_input["command"],
shell=True,
cwd="./sandbox",
capture_output=True,
text=True,
timeout=30,
)
return result.stdout + result.stderr
raise ValueError(f"unknown tool: {name}")
def run_harness(task, max_turns=15):
messages = [{"role": "user", "content": task}]
for _ in range(max_turns):
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=4096,
tools=TOOLS,
messages=messages,
)
messages.append({"role": "assistant", "content": response.content})
if response.stop_reason != "tool_use":
return response.content[0].text
tool_results = []
for block in response.content:
if block.type == "tool_use":
output = execute_tool(block.name, block.input)
tool_results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": output,
})
messages.append({"role": "user", "content": tool_results})
return "stopped: hit max_turns without a final answer"
运行 run_harness("Write a Python script in sandbox/hello.py that prints the first 10 Fibonacci numbers, then run it and show me the output."),你会看到多轮交互的展开过程:模型先写入文件,调用 run_bash 执行,读取输出,最后才生成最终的文字回复。上表中的每一个生产级 harness 都是这种基本形态的工程化增强版。
Claude Code 在第一轮之前增加了规划步骤,并在每个等效的 run_bash 调用前设置了权限门槛。Deep Agents 引入了虚拟文件系统,以及一层中间件,用于在消息超出模型上下文窗口前进行压缩。DeepSeek Harness 则允许在运行时动态替换 TOOLS 列表和模型客户端。
这个玩具示例与严肃生产系统之间的差距,完全取决于可靠性工程:当工具调用失败时如何响应、到了第 50 轮会发生什么、以及什么机制能阻止沙箱触碰 ./sandbox 之外的任何内容。
execute_tool 中没有任何机制来捕获格式错误的响应或报错的工具,因此一个失败的工具调用可能导致模型在后续每一轮中重复陷入相同的错误结果。需要自行添加重试逻辑,否则 harness 默认会持续陷入这种循环。
这个例子中有两个细节值得深入探讨。首先,cwd="./sandbox" 是一条关键的安全边界:没有它,run_bash 就能执行宿主用户所能运行的一切命令。这就是为什么所有严肃的 harness 都会在容器或受限目录中执行工具。这一行代码在重构时很容易误删,且失去它极其危险。
其次,max_turns=15 的存在是因为当前没有任何机制告诉模型自行停止。如果跳过这一项,既无轮数限制又无成本上限的 harness 将随着模型不断请求工具而持续循环并消耗 token。如果在重构时遗漏了这一行,外部表现将与之前的失败完全相同:任务永不返回,token 账单不断攀升,直到有人手动杀死进程。
Agent Harness 解决方案栈
harness 不会独立运行。几乎每个生产级 Agent 部署中都包含三个相邻的层次,明确每个层次的职责边界,可以避免让 harness 去解决本该由另一层负责的问题。如果跳过这一梳理,你可能花上一周时间调试 harness,结果发现真正的 bug 出在 sandbox 里。
图 3:四个水平层,自下而上堆叠。最底层是协议层,即 Model Context Protocol(MCP)。这是一套共享标准,让任何 harness 都能以统一方式连接任意外部工具或数据源。第二层是 harness 本身,也就是图 1 中的循环。
第三层是编排框架,位于单 Agent harness 之上,负责协调多个 Agent 或长时运行的有状态工作流:LangGraph、CrewAI、AG2、Mastra 和 DSPy 都包含在这一层。
顶层画成了两个侧面面板,而非第四个水平带状层,包含可观测性和沙箱化:Langfuse 和 LangSmith 等工具监控下方所有层,而 E2B 和 Modal 提供隔离执行环境,供 harness 的沙箱在其内运行。
协议层:MCP
Model Context Protocol(MCP)是一个开放标准,最初由 Anthropic 于 2024 年 11 月提出,旨在以一致的方式将模型连接到外部工具、文件和数据源(Anthropic)。到 2025 年底,MCP 已移交至 Linux 基金会下属的 Agentic AI Foundation,由 Anthropic、OpenAI 和 Block 支持(Wikipedia)。
harness 通常从 MCP 配置文件中加载工具列表,而不是通过手写代码实现:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/project"]
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
}
}
}
在这里添加的每个 MCP server 都会自动变成 TOOLS 里可用的工具,你不用写任何新的 execute_tool 分支。集成只需写一次,任何兼容 MCP 的 harness——无论是 Claude Code、Deep Agents、DeepSeek Harness,还是你自己搭的——都能直接使用。协议层的价值,一句话就说完了。
编排层
一个 harness 只驱动单个 agent 在单一循环中运行。一旦你需要多个 agent 协作完成一个有状态、长时间运行的工作流,并且各自承担 planner、researcher、reviewer 等专职角色,就进入了编排框架的领域。这里如果选错框架,代价可能是几个月,而不是几行代码。
LangGraph:把多 agent 工作流建模为一张图,支持 checkpoint 和时间旅行调试,在受监管企业的生产环境有状态工作流中被广泛使用(GitHub)
CrewAI:围绕“按角色定义 agent、让它们协作完成共享任务”的理念构建
AG2:微软原 AutoGen 项目的社区维护后继者,2026 年转向了以可组合中间件为核心的异步、事件驱动运行时(GitHub、pickaxe.co)
Mastra:TypeScript 优先的 agent 框架,2026 年 1 月发布 1.0 版后,GitHub star 突破 2.2 万,npm 周下载量超过 30 万(pickaxe.co、GitHub)
DSPy:来自斯坦福 NLP,把 prompt 工程从手工编写变成更接近编译的过程——针对某个指标自动优化 prompt(GitHub)
可观测性与沙箱
当 Agent 开始自主发起工具调用时,你就必须看清它具体做了什么、在哪里做的,否则调试只能靠盲猜。Langfuse 和 LangSmith 追踪整个会话中的每一次模型调用、工具调用和 Token 成本,这正是排查第 34 轮失败的原因所在(GitHub,LangChain)。
Braintrust 和 Arize Phoenix 在追踪之上增加了严格的评估机制,让你可以像测试代码库一样对 Harness 的行为进行回归测试(Braintrust,Arize-ai/phoenix)。而对于沙箱本身——即 run_bash 这类工具调用的隔离执行环境——E2B 和 Modal 提供了一次性的微型虚拟机(micro-VM),让 Harness 能够运行不受信任的代码而不影响宿主机(GitHub,Modal)。
为什么炒作曲线与采用曲线走向背离
图 4:两条 GitHub star 增长曲线绘制在同一坐标系中,时间跨度约 400 天。DeepSeek Harness 的曲线近乎垂直:起点为零,在 2026 年 8 月 13 日发布后的前两天内瞬间飙升至 95,000+ stars,随后趋于平缓。
Pi 的曲线形状则相反:从 2025 年 8 月发布起,呈现浅而稳定的近直线式攀升,一年后达到 91,600+ stars,全程没有任何单一激增点。两条曲线最终停在大致相同的位置。
将这两条曲线放在同一张图上的要点在于:它们到达终点的路径形态截然不同。一条曲线反映了协调一致的发布和精准的宣传时机;另一条曲线则反映了一年里工程师们逐个自行判断、决定值得保留该工具的过程。
发布初期的流量峰值只能说明项目吸引了关注。真正的考验在于六个月后,这款工具是否还留在开发者的终端里。这是两个不同的问题,成因也各不相同。
DeepSeek Harness 两天内斩获 9.5 万颗星,这个数字有据可查(来源:Flowtivity),但这在很大程度上是时机、分发渠道以及知名模型实验室既有用户群共同作用的结果。
Pi 达到类似的星标数量,释放的信号截然不同:一年前没有任何人为它协调发布活动。它的增长源于工程师之间的口耳相传——他们试用了这款只有四个工具编码智能体,坚持使用,并向其他工程师推荐。
仅凭发布周的峰值增长挑选工具,初期可能显得功能强大,但如果维护者随后转向下一个新项目,团队在三个月后仍可能陷入被动。两项指标互不绝对优越,但若你想让团队的工作流押注在某款 Harness 上,应研究增长曲线的形态,而不仅仅是它当前的高度。
陡峭的峰值伴随趋平的后尾,说明项目正在形成活跃社区,值得在生产环境全面投入前持续观察。而长期、平缓且不间断的增长,则表明工程师在热情褪去后仍保留该工具,这是一个更强劲(尽管更缓慢)的信号。
如何为团队选择合适的 Harness
要根据你当前面临的具体故障模式来选择 Harness,而非追随本周的热度。依据星标数而非瓶颈痛点做决策,最终代价将是团队数周的迁移工作量。
若你需要单个智能体可靠地完成一项编码任务(端到端):如果追求最紧密、最易审查的“每次提交对应最小差异(diff-per-commit)”循环,可从 Claude Code、Deep Agents 或 Aider 入手。这三者都出色地实现了图 1 中所述的“规划+沙箱”模式。
若你担心供应商或架构锁定,且预期会频繁更换模型:DeepSeek Harness 的“全插件化”设计和 Deep Agents 的模型无关性直接针对这一顾虑。在此场景下,将某一家供应商的 SDK 硬编码在核心架构中的 Harness 都是错误选择,无论该供应商的模型当前多么强大。
同类任务在数周或数月里反复出现,你希望 agent 能基于已有经验越做越快:Hermes Agent 的技能复利库正是为这种场景设计的,尤其当你还希望通过团队日常使用的聊天平台直接访问它时。
你希望审计面尽可能小,并且愿意为缺失的功能自己写扩展:那就选 Pi 的四工具核心;如果你特别需要 IDE 级工具、LSP 诊断和调试器,可以在同样的极简底座上叠加 Oh-My-Pi。
你需要多个 agent 在长时间运行的有状态流程中协同:这个问题已经超出 harness 的范畴,往上走一层,考虑 LangGraph、CrewAI、AG2 或 Mastra。
无论选哪个,都要从第一天起就把可观测性层当作必备项。无人值守运行到第 30 轮才失败的 harness,如果没有 trace,排查起来是场噩梦;而接入了 Langfuse 或 LangSmith 的同样故障,五分钟就能修好。为了省下一个下午的配置时间而跳过这一步,等 agent 运行中途失败却没人说得清原因时,代价就来了。
无论哪个 harness 胜出都通用的东西
本文提到的具体工具名称,一年后可能就过时了,因为这个领域迭代太快。真正能长期有用的是图 1 的五步循环、LangChain 从 Claude Code 架构中总结出的四种机制,以及图 3 的分层技术栈。
拿着这三个参照去审视下个月冒出来的任何新 harness,一小时内你就能判断它到底有结构性创新,还是把同样的循环换了个插件系统、配上一篇声势更大的发布公告重新包装而已。
这才是值得掌握的能力:读架构而不是读营销文案——无论工具名称更替得多快,这一点都不会过时。
结语
Agent harness 并不是什么神秘的新软件类别。它就是那个运行时外壳,把模型的下一个词预测变成一个会规划、会行动、会自我检查、并且坚持到任务完成的 agent。
所有 harness 都由五个部件构成:循环、工具路由、记忆、规划和沙箱边界。2026 年改变的,只是规模。
随着越来越多的团队推出各具特色的实现方案,它们之间的架构差异已经值得深入研究了。当前格局横跨多个极端:从 DeepSeek 的“插件即内核”理念和 Pi 的极致极简主义,到 Hermes Agent 的技能复利模式,再到 Claude Code 与 Deep Agents 采用的四种固定机制。
上一部分的数据也印证了这一点:两天内收获 95,000 星,一年内积累 91,600 星,证明了不同的路径最终都能得出相同的结论。
自己动手构建一个 60 行的版本吧,观察它如何循环运转。做完之后,市面上所有的 harness 就不再显得神秘莫测,而是变成一种可以用其工程价值来客观评估的技术决策。
接下来探索什么
DeepSeek Harness on GitHub:阅读其 README,了解 Cordis 插件架构在项目原话下的描述。
LangChain 的 Deep Agents 上下文工程文档:深入了解上述自动压缩和卸载中间件在底层是如何工作的。
Model Context Protocol 规范:本文介绍的所有 harness 均可接入的协议层。
Hermes Agent 的技能文档:了解复利技能库是如何编写和复用的。
LangGraph:当单个 agent 不够用时,上一层的进阶方案。
E2B:在宿主机器之外沙盒化运行工具执行的具体起步点。
访问我的 GitHub,探索我利用这套 agentic AI 原生工程流程构建并分享的 30 多个开源软件解决方案和开发者工具。