Agent Harness 深度解析：模型负责想，它负责让事情继续往前走（附 148 行可运行实现）-开发者社区

摘要：2026 年 9 月，AI 圈发生了一件容易被忽略、却极其重要的事：OpenAI 把 Codex 背后的 Harness 开源并做成了托管服务，Anthropic 把 Claude Code 的循环开放成 Agent SDK，腾讯开放了 WorkBuddy 的基座——三家公司不约而同地打开了自家 Agent 的"引擎舱"。本文讲透 Harness 这个概念：它是什么、六个核心部件是怎么被模型一步步"逼"出来的、学界关于"Harness 该不该自我进化"的最新争论，以及笔者用 148 行 Python 从零写一个可运行的 mini-harness 的完整实录（含权限守卫、上下文裁剪、观测回灌三个关键机制的验证截图）。读完你会明白：大模型时代真正的护城河，可能不在模型里，而在模型外面那套"操作系统"。

一、这个 9 月，三家巨头同时打开了"引擎舱"

先看三条时间线。

9 月 2 日，腾讯开放 WorkBuddy 基座，金融、法律、医疗等行业伙伴可以直接在上面搭建行业 Agent，首批伙伴超过一百家；9 月 10 日，OpenAI 把 Codex 背后的 Harness 做成托管服务开放公测——而就在一个月前，这套系统的核心代码刚被开源；再往前，Anthropic 早已把 Claude Code 的 SDK 扩展成通用 Agent SDK，把"读代码、调工具、看结果、再修改"的工作循环交给开发者。

三家打法不同，动作却出奇一致：把原本只供自家产品运转的系统，变成别人开发 Agent 的起点。

要理解这个动作的分量，得先看两组数字。Anthropic 在 9 月披露：公司 80% 的代码由 Claude 编写，内部研发平台上任意时刻有约 3 万个 Agent 在并行工作，自研工作中"AI 主导"的比例半年内从不到 1% 冲到 26%。而另一边，汹涌而来的 AI 代码让自家的 CI 系统半年内任务量暴涨 25 倍，连续三次打补丁都没扛住。

这两组数字放在一起，指向同一个结论：**当下制约 Agent 产能的，已经不是模型聪不聪明，而是模型外面那套让它能持续、安全、可验证干活的系统。**这套系统，就是本文的主角——Harness。

二、Harness 到底是什么：一句话、一个公式、一张图

Harness 本义是"马具"，把马力转化为拉车的那套挽具。放到 Agent 语境里，它指的是模型之外的一整套运行时系统：上下文怎么装配、工具怎么暴露、错误怎么处理、任务做到什么程度算结束、记忆写在哪里、危险操作怎么拦截。

一句话概括：模型负责想，Harness 负责让事情继续往前走。

如果非要写成公式，2026 年越来越多 AI 系统接近的是这个形态：

Agent = 模型（大脑） + Harness（操作系统） AI System = Model + Runtime + Environment + State/Memory + Verification + Learning Loop

上图两侧的对比，就是"聊天机器人"和"Agent"的分界线。左边是裸模型：一句话进、一段话出，转头就忘、说得出口落不了地。右边是模型加上 Harness 之后的形态——模型还是那个模型，但它的每一次"思考"都被一套系统接住：上下文经过装配和裁剪，行动通过工具注册表出去，高危操作被权限守卫拦下，每一步的观测结果回灌给模型决定下一步，任务有明确的停止条件。

一个容易被忽略的事实是：**同一个模型，参数一个不动，仅仅换一套 Harness，表现就可能出现数量级的差异。**这也是为什么 2026 年"Harness 工程"开始从幕后走到台前，成为和提示词工程、RAG 并列的一等公民。

把这条边界画清楚，很多争论就有了答案。有人说"Agent 就是提示词写得好"，可提示词只影响单次推理，管不了第 37 步的上下文溢出，也拦不住一次危险的删除操作；也有人说"Agent 就是模型够强"，可再强的模型如果没有停止条件，遇到一个任务就会无限重试烧穿预算。提示词、模型、Harness 三者的关系，更像是"战略、参谋、后勤"：决定打不打得赢的是前两者，决定会不会在路上饿死的是后者。这条认知在 2026 年已经不再是圈内的冷知识——各大公司招聘 AI 工程师时，"Agent 系统设计"已经从加分项变成了必答题。

三、六个部件，全是被模型"逼"出来的

今天一个成熟的 Harness——管理子 Agent、维护记忆文件、处理权限隔离——看起来像一套小型操作系统。但它的起点朴素得只有一行代码：answer = LLM(question)。

复杂性不是架构师一次设计出来的，而是被模型一次次"越界"逼出来的。每一代 Harness 都在补上一代暴露的真实短板：

模型暴露的短板	被逼出来的部件	对应 mini-harness 中的实现
记不住上一轮说了什么	上下文装配（Context）	每轮重新装配 + 超窗自动裁剪
没法改变真实世界	工具注册表（Tools）	`ToolRegistry.register()`
一次调用搞不定任务	主循环（Loop）	`run()`里的循环 + 观测回灌
历史越滚越长装不下	记忆/裁剪（Memory）	窗口裁剪，窗口外落盘
循环开始删文件、跑命令	权限守卫（Guard）	danger 工具默认拦截 + 路径越界校验
一个循环不够快	子 Agent（SubAgent）	任务拆解并行派发

这张表值得多看一眼的地方在第三列：上面每一个概念，落到代码里都只是一小段朴素的逻辑。Harness 工程的门槛不在单点技术，而在把十几个小机制组合成一个彼此咬合的闭环。第五节的实录会验证这句话。

把这张演化表展开看，还有一条更深的主线：每个部件的出现，都对应着模型一次"从能说到能做"的跨越，而每次跨越都会立刻暴露出下一层的问题。上下文装配解决了"记得住"，紧接着就暴露出"记得多但分不清重点"，于是有了分层保留和自动裁剪；工具注册表解决了"够得着"，紧接着就暴露出"够得着的东西太危险"，于是有了权限守卫和操作分级；主循环解决了"做得完"，紧接着就暴露出"做得快但不一定做得对"，于是有了验证和评估环节。今天大家热议的子 Agent 并行，本质上是同样的故事再演一遍：单循环的串行速度成了新的瓶颈，于是把任务拆给多个带独立上下文的子循环。**每一次部件的补齐，都是上一代方案在真实任务里摔跟头摔出来的。**理解这条主线，比记住任何一个具体框架的名词都重要——框架会过时，这个"短板驱动演化"的规律不会。

四、前沿之争：Harness 该手写、该搜索，还是该自己进化

Harness 成为热词之后，学界的争论也跟着来了。2026 年下半年有三条路线值得关注，它们的分歧点在于：这套系统应该由人来写、由算法来搜，还是让 Agent 自己进化。

**路线一：WHALE，权重与 Harness 交替优化。**8 月底这篇论文提出了一个足够锋利的判断：模型权重和运行它的 Harness 才共同构成 Agent，两者必须交替进化——先在当前 Harness 下更新权重，再基于新模型搜索更好的 Harness，循环往复。在数学推理等任务上，这种交替方案比只练权重或只搜 Harness 高出 4 到 24 个百分点的准确率。但它同时也暴露了风险：联合优化很容易变成对特定任务的"条件过拟合"，搬到生产环境要格外小心。

**路线二：Harness Evolution，让 Agent 改自己的挽具。**更激进的思路是让 Agent 分析自己的失败轨迹，自动修改提示词、工具集和控制逻辑。但 AI2 和华盛顿大学的一项研究给这股热潮泼了盆冷水：把 Harness Evolution 和最朴素的"多跑几遍"放在相同推理预算下公平对比，复杂的自我进化并没有稳定胜出；而且进化出来的 Harness 拿去解决没参与过优化的新任务时，提升只剩零头。

**路线三：工程化分层，把进化限制在笼子里。**这是目前工业界更务实的选择——把持续改进拆成模型层、Harness 层、Agent 层三层，各层独立演进。有实测数据显示，模型完全不变，仅把"脚手架"升级，效果可以提升 1.8 倍。代价最小、可控性最强，这也是为什么它成了企业落地的默认路线。

这三条路线的争论本质上是在回答同一个问题：**Harness 的价值既然已被证实，那它的迭代权应该交给谁？**现阶段务实做工程的人，答案通常是"人定框架、算法搜索、Agent 只做受限的微调"。

对一线开发者来说，这场争论还有一个更直接的读法：路线一和路线二是研究者的游戏，需要算力、评测集和大量失败轨迹做燃料；路线三才是普通人今天就能落地的。而且路线三并不排斥前两条——你完全可以在自己的 Harness 里留一个"实验开关"，让 Agent 在受限范围内调整提示词模板，但每一次调整都要过评测关卡才能生效。这样既保留了自动进化的好处，又把它可能带来的不可控性锁在了评测的笼子里。事实上，本文第五节的 mini-harness 就预留了这种扩展空间：run()的循环结构不变，把固定提示词换成可配置模板，就是一个最小化的"受限进化"实验台。

五、动手实录：148 行写一个 mini-harness

概念讲一万遍，不如真跑一遍。笔者照着上面第三节的六个部件，用 Python 写了一个最小可用的 Harness，全程不到 150 行，不依赖任何框架，装好 Python 就能跑。这里只贴最核心的三段，完整代码随文附带。

**第一段：工具注册表 + 权限守卫。**这是整个 Harness 里安全含量最高的部分，做了两件事：所有文件操作锁死在工作区内（防路径越界），高危工具默认拒绝执行：

classToolRegistry:def__init__(self,workspace:str):self.workspace=workspace self.tools,self.log={},[]def_safe(self,rel):"""路径守卫：一切文件操作锁死在工作区内"""p=os.path.realpath(os.path.join(self.workspace,rel))ifnotp.startswith(os.path.realpath(self.workspace)):raisePermissionError("路径越界: "+rel)returnpdefcall(self,name,**kwargs):tool=self.tools.get(name)iftoolisNone:return{"error":f"未知工具{name}"}iftool["danger"]:self.log.append(("DENY",name))return{"error":f"权限拒绝:{name}属高危操作，需人工在终端确认"}try:out=tool["fn"](**kwargs)self.log.append(("OK",name))return{"result":out}exceptExceptionase:return{"error":f"{type(e).__name__}:{e}"}# 错误回灌而非崩溃

**第二段：上下文窗口与自动裁剪。**真实 Agent 的上下文永远有限，Harness 必须决定"模型此刻能看见什么"：

MAX_TURNS=2# 演示用小窗口，模拟真实上下文限制defassemble(system,history):kept=history[-(MAX_TURNS*2):]# 只保留最近 N 轮trimmed=len(history)-len(kept)note=f"\n[system] 上下文已自动裁剪{trimmed}条旧观测"iftrimmedelse""returnf"{system}{note}\n[task]{history[0]}\n"+"\n".join(kept)

**第三段：主循环。**观测结果回灌给模型、步数上限兜底，这两个机制缺一不可——前者让模型"看见"工具的真实结果（包括报错），后者防止循环失控烧穿预算：

defrun(llm,registry,task,max_steps=10):history,budget=[task],{"steps":0,"calls":0}forstepinrange(1,max_steps+1):prompt=assemble("你是巡检 Agent，只能使用提供的工具。",history)out=llm.respond(prompt,observation=Noneifstep==1elsehistory[-1])ifout.get("final"):returnout["final"],budget# 模型主动收工obs=registry.call(out["tool"],**out["args"])history.append(f"call{out['tool']}{out['args']}")history.append(f"obs{json.dumps(obs)[:80]}")return"达到步数上限，强制停止",budget# 停止条件：防失控

给它的任务是巡检一个演示目录：统计 Python 文件、生成报告。为了输出可复现，代码里内置了一个脚本化的 MockLLM（接真实模型只需要实现同样的respond接口，代码里附了完整的 OpenAI 兼容适配器，填上 Key 就能跑）。运行方式只有一行：python mini-harness.py --mock，切换真实模型则加--base-url、--api-key、--model三个参数。实际运行结果如下：

这次运行把三个关键机制全部验证了一遍：第 3 步模型试图删除config.py（里面故意放了"密钥"），权限守卫直接拦截，错误信息回灌给模型后它没有崩溃、没有重试，而是把"已拦截"写进了最终报告——这就是"错误是观测而不是异常"的 Harness 哲学；上下文窗口每轮自动裁剪，模型始终只看见最近 4 条记录；budget统计显示 5 步 4 次工具调用完成任务，循环正常终止。

四条实战经验，是这次动手最值钱的收获：

**第一，权限守卫必须做在 Harness 里，而不是写在提示词里。**提示词是"请求"，Harness 是"强制"。这次故意让模型去删带密钥的文件，如果拦截逻辑只写在系统提示词里，换个模型、换轮对话就可能失效。

**第二，上下文裁剪的粒度比算法更重要。**演示里粗暴地"保留最近 N 条"，生产上要按"系统指令 > 任务目标 > 最近观测 > 历史轨迹"的优先级分层保留。但无论哪种策略，裁剪动作本身必须由 Harness 自动完成，不能指望模型自己"记得看重点"。

第三，报错信息是给模型看的，要按"可行动"的标准写。权限拒绝: delete_file 属高危操作，需人工确认这条观测让模型立即调整了行为；如果只返回Error 403，模型大概率会盲目重试。

第四，预算和停止条件从第一行代码就要有。max_steps=10看着简陋，它对应的是生产系统里的 token 预算与熔断机制——Anthropic 的 Agent 之所以能 3 万个并行不失控，靠的正是每个循环都有硬性边界。

六、Harness 定型之后：能力从哪里来

跑通 mini-harness 之后会发现一个清晰的分工：Harness 解决"Agent 怎么干活"，Skill 解决"Agent 会干什么"。工具注册表里注册的是原子能力，而把领域知识、操作流程、脚本模板打包成可插拔的模块，靠的是这两年已经形成事实标准的 Skill 机制。

最后把三层关系画清楚，这是很多人容易混的地方：**Harness 是运行时，管的是"怎么干活"——循环、预算、权限、裁剪；MCP 是工具协议层，管的是"工具从哪来"——它规定了模型和外部服务之间的标准接口，让任何一个工具写一次就能被所有兼容的 Harness 调用；Skill 是知识与流程层，管的是"这种活该怎么干"——它把领域经验、操作步骤、脚本模板打包成可插拔的模块。三层各司其职又彼此嵌套：Harness 调用 Skill，Skill 内部可以调 MCP 工具，MCP 工具最终执行真实世界的操作。拿做菜打比方，Harness 是厨房的水电气和流程制度，MCP 是标准的锅碗刀叉接口，Skill 是菜谱。这个分工也解释了为什么 2026 年各大 Harness 都在猛扑 Skill 生态：循环、权限、上下文机制是通用的，不同行业、不同岗位的差异，全部沉淀在 Skill 层。想给自己的 Agent 装能力，可以从 DeepSkill 的作品展厅逛起，里面有两百多个创作者晒出的真实作品：有人开源了一套"艺术家元 Skill"，让 Codex 一句话学会韦斯安德森的海报风格；有人把 100 条动效规范打包成 Skill，让前端 Agent 生成带"手感"的交互动画；还有人把一本书转换成可长期调用的知识 Skill——每一个都附了源码和使用效果。

动手写 Harness 的读者，笔者的建议是在 mini-harness 的基础上按这个顺序加东西：先接真实模型（代码里的OpenAICompatLLM适配器填上 Key 就能用），再加记忆落盘，然后把工具注册表从"文件三件套"扩到你的真实业务——写到这一步，你就拥有了一个完全可控、完全可审计的私人 Harness。工具注册表每加一个真实业务工具，就值得去作品展厅看一眼有没有人已经把同类经验封装成了 Skill，能省掉大量从零摸索的成本。

最后照例是验收。判断一个 Harness（或一个 Skill）是不是真的能用，别看介绍页写得多漂亮，用这三个任务过一遍：典型任务，给它一个你每天真实在干的活，看一次成功率；边界任务，故意制造权限不足、文件缺失、网络超时，看它是报错清楚还是编造结果；缺参任务，模糊地下指令，看它会不会先确认口径再动手。三关全过才算真的能用，任何一关靠"自由发挥"混过去的，都要降权使用。

七、总结

回到开头那三家公司打开"引擎舱"的动作。它们的潜台词其实是一致的：模型能力的竞争会继续，但 2026 年胜负手已经转移到了系统层——谁能把模型安全、稳定、可验证地接进真实世界，谁就掌握下一代的分发入口。

对普通开发者，这件事反而是利好：当 Codex Harness、Claude Agent SDK 都成为公共设施，写一个 Agent 的门槛从"训模型"降到了"攒 Harness"。本文那不到 150 行的代码就是证明——循环、守卫、裁剪、回灌，每个机制都朴素到不像"前沿技术"，但组合起来就是一个能跑、能拦、能停的 Agent 骨架。剩下的，交给 Skill 层去长出血肉。

模型负责想，Harness 负责让事情继续往前走。这句话，值得写进 2026 年每一个 AI 工程师的备忘录。模型能力的边际收益在递减，系统工程的边际收益才刚刚开始；当所有人都在盯着下一个模型的发布日期时，真正的机会藏在模型外面那套越来越精密的挽具里。引擎舱已经打开，接下来比的就是谁装进去的东西更结实。