DeepSeek Harness ：Agent 自我改进之前，先让 Harness 可观察、可组合、可回滚

Agent 想修改自己的工具、记忆与工作流，难点不只是会写代码，而是改动能否验证、回滚并隔离风险。本文拆解 DeepSeek Harness 如何把自我改进落到运行时工程。

Agent 真正进入长期运行以后，一个绕不开的问题会浮出来：它能不能在工作过程中调整自己的 Harness？

不是换一句 Prompt，也不是临时多塞一个工具，而是更系统地修改上下文组织方式、工具能力、执行循环、记忆结构和验证流程。改完以后，系统还要知道这次修改有没有带来收益，失败时能不能回滚，哪些边界绝不能交给 Agent 自己动。

DeepSeek Harness，简称 DSH，最值得讨论的地方就在这里。它现在还不是一款成熟的消费级 Agent 产品，界面、交互和生态都处在早期。但如果把它当成 Agent Harness 的工程实验来看，它关心的不是“多一个好用工具”，而是一个更底层的问题：

当 Agent 的能力本身由一组可变组件构成时，运行时怎样承受持续改造？

图：自我改进需要在可观测、可回滚的运行时内发生

Harness 是 Agent 的工作环境，不只是模型外壳

DeepSeek 对 Agent 的拆法很直接：Agent = Model + Harness。

模型提供智能，Harness 负责把智能接到真实任务上。一个能做事的 Agent，通常需要这些东西一起工作：

模块	作用
模型适配器	把不同模型接入统一消息协议
System Prompt	定义身份、边界、工具说明和行为约束
上下文管理	决定模型当前应该看到哪些信息
工具系统	暴露文件、Shell、搜索、浏览器、代码执行等能力
Session	记录用户消息、模型输出、工具调用和结果
Agent Loop	推动“请求模型 → 调工具 → 回填结果 → 再请求模型”的循环
沙箱与审批	控制危险操作、权限和执行环境
UI 或 Headless 入口	让同一套运行时进入不同使用场景

传统产品容易把这些能力做成一条固定链路。DSH 的选择是把它们拆成插件。模型适配器是插件，工具注册表是插件，会话日志是插件，Agent Loop 自己也是插件。

这不是为了追求形式上的可扩展，而是为了让 Harness 成为可以被重新组合的对象。同一套系统，换一组插件和配置，可以是 Web 里的编程 Agent，也可以是后台跑完一个任务就退出的 Headless 执行器，还可以是开发者手动改造的实验环境。

DSH 的核心判断：先把可替换性做成系统能力

DSH 底层使用 Cordis 来管理插件。Cordis 不提供具体 Agent 能力，它做的是运行时协议：插件怎样声明依赖，怎样把服务注册到共享上下文里，卸载时怎样撤销自己留下的影响。

用工程语言说，它把三件事显式化了：

插件依赖哪些服务。
插件上线后改动了哪些运行时状态。
插件离开时怎样把这些改动还原。

这正是长期 Agent 会遇到的底座问题。一个 Agent 如果只是一次性跑完任务，重启成本还能接受；但如果它要持续执行、恢复历史、分叉任务、压缩上下文，甚至在运行时改造自己的工具和流程，就不能每改一个部件都把系统掀翻重来。

DSH 的“一切皆插件”实际是在为这种场景做准备。它先不承诺 Agent 一定能自己变聪明，而是先回答一个更基础的问题：如果某个组件被替换，系统能不能只影响相关部分，而不是把整套 Harness 一起拖下水？

四种 Preset 暴露了不同的 Harness 形态

DSH 的 Composer 里有模式选择器。它不是普通的“模型强弱档位”，而是一组 Agent Preset。选不同模式，意味着当前会话加载不同插件、工具、Prompt 和执行方式。

官方提供的几种模式，可以看成几种 Harness 设计立场：

模式	关注点	适合观察什么
标准模式	给模型一套完整编程 Agent 能力	文件编辑、Shell、检索、Skills、计划、子 Agent、Workflow 怎样协作
PTC 模式	让模型用 TypeScript SDK 批量组织工具调用	多步任务如何减少模型与工具之间的往返
极简模式	只保留终端和文本编辑能力	拿掉复杂 Harness 后，模型本身能走多远
创造模式	允许检查 Runtime 并组合新的 Preset	Agent 能否根据目标组装另一套 Agent 形态

PTC，Programmatic Tool Calling，特别能说明 Harness 的价值。传统 Agent 每调用一次工具，都要等结果回到模型，再决定下一步。五个动作往往意味着五轮模型往返。PTC 让模型把多个工具步骤写成一段程序，一次完成读取、筛选、分支和汇总，只把真正有用的结果送回上下文。

这不是单纯“加一个工具”，而是改变工具编排方式。任务步骤越多，中间数据越大，差异越明显。

创造模式则把问题再往前推一步：如果 Agent 可以检查当前 Runtime，也可以在内存里试验插件组合，那它就不只是执行任务，还开始触碰“构造另一个 Agent”的能力。

这就接上了 Lilian Weng 关于 Self-Improving Harness 的讨论。

自我改进先发生在模型外部

Lilian Weng 在《Harness Engineering for Self-Improvement》中提出一个很关键的视角：AI 的自我改进不一定先发生在模型权重里，也可能先发生在包裹模型的 Harness 中。

优化对象会一层层向外移动：

Instruction Prompt
→ Structured Context
→ Workflow
→ Harness Code
→ Optimizer Code

最早的优化是调 Prompt。后来系统开始调整结构化上下文，决定哪些历史保留，哪些经验写进记忆。再往后，Workflow 本身也变成优化对象：谁先执行，谁负责验证，失败后回到哪一步。

当工具描述、工具实现、子 Agent 配置、长期记忆、执行策略都能被代码描述时，Harness 就变成了一块可编辑的能力表面。Agent 可以根据运行轨迹发现问题，提出一个有限修改，再用任务回归验证效果。

一个相对完整的 Self-Improving Harness 闭环大致是：

图：修改只有同时通过原问题验证和 held-out 回归检查后才会被接受

这条路线的吸引力在于，它不需要立刻训练新模型。Agent 今天发现某个工具不好用，明天就能替换；某条 Workflow 反复失败，就能调整编排方式。模型权重没变，但模型工作的环境变了，任务表现也可能随之改变。

不过这里有一个现实限制：能写出修改，不等于能从修改里获益。

研究里常把它拆成 Harness Updating 和 Harness Benefit。较小模型可能也能生成结构合理的 Skill 或配置改动，但要在长程任务中准确调用新能力、遵守复杂约束、持续完成工作，仍然需要更强的模型能力。Harness 给模型提供改进表面，但不能替代模型本身的判断力。

为什么 DSH 重视事件日志

自我改进最怕凭感觉改系统。一次任务失败以后，系统必须能回答几个问题：

失败发生在哪个组件附近。
当时模型看到了什么上下文。
工具集是谁注入的。
哪次修改改变了运行路径。
这次判断基于哪些可复查证据。

DSH 把 Session 建在 append-only event log 上。用户消息、模型回复、工具调用、工具结果、上下文注入、流式输出都会作为事件保存。模型下一步看到的上下文，也从这条事件流重新推导。

这和传统 Trace 的关注点不一样。

观测方式	主要回答
Trace	一次调用经过了哪些节点，耗时和错误在哪里
Event Log	一个 Agent 怎样随时间变成当前状态，哪些事实构成了模型上下文

短任务里，两者差别不大。长期 Agent 会经历上下文压缩、恢复、分叉、子 Agent 调度和插件变化，此时一棵调用树很难解释完整状态。事件日志则能保留“事情是怎样一步步发生的”。

这也解释了 DSH 为什么要求模型可见信息能从日志中重建。如果信息只进入模型请求，却没有进入日志，后续就无法重放、审计或归因。对于准备修改自身 Harness 的 Agent，这种缺口会直接破坏自我改进的可信度。

时空可组合性解决的是运行时安全问题

Self-Improving Harness 描述了“为什么要改”和“怎样验证改动”。但真正把改动装进运行中系统时，还有一个更底层的问题：组件怎样在运行过程中安全加入、退出和替换？

DeepSeek Harness 背后的 Cordis 论文《A Programming Paradigm for Spatiotemporal Composability》讨论的就是这个问题。论文把动态组合拆成两个维度：

维度	问题	机制
时间可组合性	组件卸载后，怎样完整撤销它造成的副作用	Revertible Effects
空间可组合性	组件依赖哪些能力，依赖变化后谁要暂停、重连或继续运行	Reactive Coeffects

时间可组合性关心“拆得干不干净”。插件上线后可能注册工具、监听事件、打开连接、启动后台任务。卸载时，Runtime 要能按记录把这些影响撤回。如果旧工具已经不存在，模型还看得到它的说明，系统就进入了脏状态。

空间可组合性关心“连得对不对”。Memory 可能依赖 Storage，任务调度器又依赖 Memory。Storage 被替换以后，Memory 要重新连接，任务调度器可能需要短暂停止；无关的 Web provider 则不该被打扰。

这两个维度合在一起，才让热替换成为可信工程动作。换模型时，受影响的是模型适配器和依赖 llm 的 Agent Loop；会话日志、工具注册表和搜索 provider 不必跟着重启。换搜索源时，工具对模型暴露的 web_search 形状不变，只替换 provider。

合流性：系统不能背着历史包袱继续跑

论文里还有一个更隐蔽但很重要的性质，Confluence，合流性。

同一套最终配置，可能通过不同路径抵达。一个插件先安装后卸载，另一个插件更新失败后回滚，某项依赖消失后又重新出现。每一步单看都合理，但多走几轮以后，系统可能留下旧监听器、旧连接或旧服务引用。

对普通插件系统来说，这已经足够麻烦。对自我改进 Agent 来说，问题会更严重。Agent 每完成一次修改，都可能给下一次修改留下隐患。修改次数越多，系统越难解释。

合流性追问的是：只要最终配置相同，系统能否回到稳定、可解释、没有历史污染的状态？

这就是 Cordis 这类运行时的价值。它不负责判断哪个 Harness 改动更聪明，但它要保证改动失败不留下幽灵状态，组件卸载不留下悬空依赖，局部替换不会拖垮无关组件。

DSH 把 Cordis 放进 Agent Harness，本质上是在说：未来 Agent 的自我改进不能只靠模型会写代码，还需要一个能承受动态变化的运行时。

可观测性和缓存，是两个容易被低估的细节

DSH 里有两个工程细节值得单独看。

第一个是可观测性。很多 Agent Trace 产品沿用了 LangSmith Thread 的思路，以一次会话或一次运行为主轴，展开模型调用、工具调用、耗时、Token 和错误。这对 Chain 和 Workflow 很有效，因为执行路径相对稳定。

Harness 时代的调试对象更复杂。我们不只想知道某次模型调用为什么失败，还想知道当时工具集是谁注入的，上下文从哪里来，压缩后保留了什么，子 Agent 的结论怎样回到父会话，恢复以后系统是否仍然处在同一个可解释状态。

DSH 的事件日志把观测对象从“调用经过哪些节点”推进到“Agent 状态怎样连续演化”。这对长期 Agent 调试很关键。

第二个是 Prompt Caching。Agent 每次请求模型时，都会携带 System Prompt、工具定义、历史消息和当前任务状态。随着任务变长，如果每轮都从头处理全部上下文，响应时间和成本都会上升。

DSH 的上下文组织方式天然适合缓存。事件日志只追加，历史顺序稳定；工具和 Prompt 由插件配置生成，稳定部分容易形成可复用前缀。只要前缀不变，缓存就能持续命中。长 Session 里 TTFT 变短，往往不是模型突然更快，而是 Harness 把可缓存结构组织得更好。

自我改进必须有不可编辑边界

把 Harness 做成可编辑对象，并不意味着所有东西都该交给 Agent 改。

如果一个自我改进程序可以任意修改评估器、权限系统、日志和测试集，它就能制造出“看起来进步”的假象。比如关掉 Verifier，放宽权限，增加推理预算，或者迎合 held-out 任务里的模式。结果变好，不代表能力真的变强。

因此，自我改进系统必须先划出 不可编辑边界：

不应随意交给 Agent 修改的部分	原因
Evaluator	否则系统可以通过改评分标准获得虚假收益
权限与审批	否则风险控制会被优化目标绕开
只读事件日志	否则失败证据和归因链会被污染
安全沙箱	否则一次错误改动可能越过执行边界
回归测试集合管理	否则容易出现对测试数据的迎合

可编辑范围内，Agent 可以调整工具、Prompt、Workflow、记忆策略和局部 Harness 代码；边界之外，仍需要人类审查、Trace Audit 和独立评估。

DSH 目前还没有给出完整的自我改进治理方案。它更像是先补上运行时基础：插件边界、事件日志、可撤销副作用、依赖重连和可观测轨迹。

图：可编辑能力与不可编辑安全边界必须分开

今天应该怎样理解 DSH

如果用成熟 Coding Agent 的标准看 DSH，很容易失望。它还处在开发者预览阶段，产品体验、交互细节和生态完整度都没到稳定状态。

但从 Agent Harness 开发者角度看，它已经给出一套很清晰的系统观：

能力应该被拆成插件，而不是揉进固定应用。
Session 应该是可重放的事件流，而不是只保留当前消息列表。
工具编排可以进入程序化执行，而不是每一步都消耗模型往返。
组件副作用和依赖关系应该由 Runtime 显式管理。
Harness 的未来问题不只是“给模型更多工具”，而是“让系统能长期存在并安全变化”。

这套系统还不能证明 RSI 已经到来。怎样评估一次 Harness 修改真的带来长期收益，怎样避免 Reward Hacking，怎样把非参数化改进和模型权重更新放进同一套归因框架，这些问题都还很难。

但 DSH 至少把问题推到了工程层面。下一代 Agent 需要的不只是更强模型，还需要一个能记录自身历史、承受局部替换、识别失败来源、并在错误修改后恢复稳定状态的 Harness。

换句话说，Agent 的“自我改进”如果要从口号变成系统能力，第一步不是让它随便改自己，而是先让它的工作环境变得可观察、可组合、可回滚。DeepSeek Harness 的意义正在这里。