DeepSeek Harness 工程解读与自进化探索实践

DeepSeek Harness 工程解读与自进化探索实践

OpenAI 首席科学家 Jakub Pachocki 近日在公开文章中给出了一个分量很重的判断：基于内部结果，他强烈预期，当前的进步速度可能延续到递归自进化（RSI）阶段。他进一步写道，OpenAI 正将研究重心朝 RSI 推进，因为他们认为，这是未来保持 AI 研究前沿地位的必经之路。

前沿竞争正在指向一个更深的问题：

今天的 AI，如何参与制造更强的下一代 AI？

受到社区广泛关注的 DeepSeek Harness（下文简称 DSH），为探索 Agent 如何改进自身运行方式提供了一个具体样本。它将 Agent 的运行机制开放为可替换、可组合的插件，连负责组织模型请求与工具执行的循环也可以调整。同时，DSH通过 Session Log 保存执行记录，为分析任务成败和后续的改进提供了依据。

两者结合，使它自然成为探索 Agent 自我改进的一种基础设施：Agent 可以利用自己的执行经验，参与修改驱动自身运行的 Harness，再用修改后的系统执行下一轮任务。

从 Agent = Model + Harness 的视角出发，AI 参与制造下一代 AI，既可以通过模型训练，也可以通过改进 Harness 展开。在我们看来，DSH 的设计让 Agent 能够在持续运行中，以更大的修改范围参与自身改进：无需重启或重新编译，就能动态调整工具、插件乃至执行循环，使 Harness 的运行与演化同步发生，为探索递归自进化提供了工程起点。

本文结合源码、社区中的设计讨论、实际编码实验和自进化研究，分析 DSH 如何组织 Agent 的运行，Harness 的调整怎样影响任务表现，以及组件替换与运行记录机制，如何为 Agent Self-Improvement 乃至 RSI 提供工程支持。

01

Agent Preset 的配置体系与执行模式

DSH 的 Web Profile 通过 Agent Preset 组织每个 Agent 的提示词、工具、Skill 和 Agent 侧插件配置。官方提供四种模式：Standard（标准模式）、Minimal（极简模式）、PTC 模式和 Creator（创造模式）。后文将详细介绍这四种模式的配置与执行方式。

· 公共运行环境与 Agent 配置

执行 dsh web 命令时，DSH 通过 Cordis 装载 Web Profile，加载会话、模型路由、沙箱、工具注册表与 Web 服务，形成 Host 运行环境；然后根据用户选择的 Preset 创建 Agent。多个 Agent 共用 Host 服务，各自保留 Preset 提供的提示词和工具范围。而作为一次性任务入口的 headless profile 同样通过 Cordis 装载预先组合的插件配置创建一个 Agent，执行命令行传入的任务后输出最终答案并退出；它不提供 Preset 选择功能。两种入口采用不同的插件组合，也体现了 DSH 通过 Cordis 按运行场景组织和装载组件的能力。

Standard 是 DSH 预置的一套完整 Agent 配置，提供 Shell、文件读写、代码搜索、图片与网页查看、后台任务、目标、计划、待办和子 Agent 等能力。

Minimal 采用固定提示词和双工具的极简配置：完整 persona 直接构成系统提示词，不追加运行时上下文，模型只获得持久 Shell 和文本编辑工具。在 DeepSeek 于 2026 年 7 月 31 日公布的官方评测中，V4-Flash 搭配 Minimal 模式，在 Terminal-Bench 2.1 和 DeepSWE 上的得分分别为 82.7 和 54.4。评测采用 max 推理档位，设置 top_p=0.95、temperature=1.0。

· PTC 模式的程序化工具调用

PTC 沿用 Standard 的能力配置，但改变工具的呈现方式：普通模式将工具名称、用途和参数直接交给模型；该模式只提供 run_code 入口，并根据当前 Agent 可见的工具生成 TypeScript SDK。插件新增工具进入可见范围后，也会自动生成对应的 SDK 方法。

模型可以通过程序编排多个工具调用，把搜索文件、筛选路径、读取内容等步骤写入同一段程序，由程序处理中间结果并整理输出，再将结果交回模型。这样可以减少逐步调用时反复请求模型的次数；需要理解结果或调整方案时，仍由模型判断。

程序中的 SDK 调用仍由 DSH 原有工具注册表处理，沿用普通工具的参数校验、权限检查、取消处理和事件记录。PTC 模式只向模型开放 run_code 这一调用入口；模型若绕过该入口直接发起工具调用，DSH 会拒绝请求。

PTC 的实际表现取决于模型与 Harness 调用约定的匹配程度。模型对 SDK、参数和返回结构的理解，决定了这套程序化调用能否稳定运行；接口误用、程序错误或结果处理不当，会触发程序改写和重试，带来额外的 Token 消耗和执行时间。

· Creator 的插件开发与版本试装

Creator 以 Standard 为基础，增加 Cordis 开发工具和两份 Skill。Agent 可以查询 Host 的服务、事件、工具和界面插槽，编写并加载插件，再根据启动结果继续修改。

Creator 将动态 Cordis 插件的定义、版本和运行实例分开管理。四个生命周期工具分别负责登记、运行、停止和删除：cordis_define 对代码进行语法预检并登记不可变的 Package；cordis_run 激活指定版本，支持首次运行、版本更新、重启和回退，只有运行成功后才更新当前版本指针；cordis_stop 停止当前运行但保留插件定义及其所有版本；cordis_undefine 删除当前会话拥有的动态插件及其全部 Package。Inspect 系列工具用于查询 Host/Client 接口、动态插件、Package 和运行状态。

配套的两份 Skill 分别指导动态插件开发和 Preset 编写，涵盖接口查询、Host 与 Client 的职责划分、资源清理以及版本更新和回退。动态插件的 Host 侧代码由 node:vm 环境加载执行，Client 侧代码由浏览器加载。Host 侧运行环境会遮蔽或重定向部分 Node 全局能力，但这不构成安全隔离，因此动态插件应按受信本地代码对待。

动态 Package 只存在于当前进程内存中，不会自动变成持久化插件。经过验证、需要长期保留的修改，应按常规开发流程整理为正式插件，再由用户自己的 Preset 或组合文件引用。

DSH 的 Creator 模式通过插件开发、试装和版本切换，支持 Agent 根据运行反馈调整插件。与之相比，衔远科技的大观平台由 MA 驱动 Agent Package 的修改，实现 MAH 的能力扩展与运行策略优化，支持 Agent 的开发、评测与持续进化。这与前文讨论的自进化路径一致，也就是将运行经验转化为具体改进，经评测验证后形成可复用的版本，再在新的任务中持续验证和完善。

· 三种Preset 的任务表现

为了观察不同 Preset 在真实编码任务中的表现，我们固定使用 deepseek-v4-flash 和 DSH 0.1.2-alpha.1，分别采用 Minimal、Standard 和 PTC三种模式执行 Terminal-Bench 2.1 和 DeepSWE 中的任务。

在 Terminal-Bench 2.1 上，Standard 比 Minimal 高 5.62 个百分点；在 DeepSWE 上，Minimal 比 Standard 高 2.68 个百分点。结果随任务集变化，不能仅凭一项汇总分判断模式优劣，还要结合模型实际使用搜索、规划和上下文压缩等能力的方式理解差异。

PTC 在两项评估中的通过率均低于最佳配置，分别相差 8.99 和 15.18 个百分点。逐题结果显示，不同配置的优势会随任务变化，PTC 也完成了部分其他配置未完成的任务，汇总通过率不能单独说明一种模式对所有任务都更适用。接下来从 PTC 轨迹中的工具调用、程序执行和错误恢复入手，分析当前模型与程序化调用方式的适配情况。

· 程序化调用的收益与适配模型

PTC 允许模型把多个工具操作写入同一段程序，由程序连续执行并处理中间结果，因此有机会减少逐步调用时的模型请求。能否实现这一收益，取决于模型是否准确理解调用约定、生成可执行程序并处理返回结果；接口误用、参数遗漏和程序错误会触发改写与重试，增加额外开销。

在 201 条有效 PTC 轨迹中，125 条出现直接调用 read 等普通工具的尝试，共产生 393 次接口拒绝；另有 47 条因遗漏 run_code 必填参数被拒绝 267 次。128 条出现程序语法错误，60 条出现运行异常，112 条出现执行完成但无返回内容的情况。各类计数存在重叠。这些错误会让模型重新生成程序、再次调用工具，或无法确认结果，因而增加执行开销。

105 条通过的轨迹中，88 条出现过失败工具结果；模型能够根据反馈调整参数或改写程序后继续完成任务。错误得到修正并不意味着没有成本，这些重试仍占用额外请求和执行时间。

与 Standard 相比，Terminal-Bench 中 PTC 的累计输入 Token 中位数少 14.68%，累计输出 Token 高 10.15%，执行时间从 598 秒升至 765 秒；DeepSWE 中，累计输入、输出 Token 分别高出 7.41% 和 4.95%，执行时间从 1,392 秒升至 1,458 秒。PTC 的输入量在两项任务中的变化方向不同，也没有同步带来更短的执行时间；程序生成和错误恢复会占用额外时间。

本轮结果不能简单归结为 PTC 模式本身更差：通过率、Token 和执行时间反映的是当前模型与 Harness 的配合。轨迹显示，模型更准确地理解调用约定、生成程序并处理返回结果时，PTC 的确有减少中间交互和输入量的空间；能否把这种空间转化为稳定的通过率与效率提升，还要结合模型能力和 Harness 实现的后续演进继续验证。

02

Cordis 的依赖管理与插件生命周期

DSH 以 Cordis 为核心插件框架，管理插件加载、服务依赖与生命周期，Preset 声明的插件也通过它运行。Cordis 在启动前检查所需服务，服务替换时重载相关插件，卸载时执行已登记的清理函数。

· 服务依赖决定插件的启动与重载

Cordis 在启动插件前，会检查它声明的必需服务是否全部就绪。负责推进模型请求和工具执行的 Agent Loop 是 Agent 运行的核心组件，也通过服务依赖声明约束自身的启动条件。

static inject = ['agents', 'sessions', 'llm', 'tools', 'systemPrompt']

这五项依赖对应 Agent 管理、会话、模型调用、工具注册表和系统提示词。Cordis 检查服务是否可用，再按依赖关系启动插件。

Cordis 为每次插件装载创建一个 Fiber，记录这次装载的状态、服务依赖和待清理资源。插件所需的服务尚未全部就绪时，对应的 Fiber 处于 PENDING 状态；服务就绪后，进入 LOADING 状态并启动插件；启动成功后，转为 ACTIVE。

插件运行期间，如果某项必需服务被撤回，依赖该服务的插件所对应的 Fiber 会进入 UNLOADING 状态，执行已登记的清理函数。清理完成后，如果依赖仍未满足，则回到 PENDING；所需服务重新就绪后，同一个 Fiber 可以再次启动插件。如果这次装载被移除，对应的 Fiber 最终转为 DISPOSED；如果插件入口执行失败，则转为 FAILED。

通过以上机制，组件可以在运行中替换，Cordis 会按依赖关系完成相关插件的退出、资源清理和重新启动。

· Context 与工具的可见范围

插件通过 Context 访问所需服务。以文件操作为例，Standard 的文件工具使用宿主提供的文件系统服务；Minimal 则在自己的插件组内配置本地文件系统实现，文本编辑器通过 Context 取得这份实现。这样，同一个进程中的插件可以使用不同的服务实现，局部替换也不会影响其他配置。

借助 Context 的服务共享机制，不同 Preset 的工具插件可以共用宿主提供的工具注册表。Standard 加载搜索、规划等工具插件后，这些工具不会自动出现在 Minimal 的工具列表里：按照官方配置，Minimal 的模型仍只获得持久 Shell 和文本编辑工具。DSH 通过 dsh-scope 记录工具注册的作用范围，为各个 Agent 分别生成可见的工具目录。PTC 模式生成 SDK 时也使用这份目录，未向当前 Agent 提供的工具，不会生成对应的 SDK 方法。

· Effect的资源登记与退出顺序

Cordis 通过 Effect 将插件创建的资源与其生命周期关联起来，使资源能够在插件卸载时一并释放。框架注册的监听器、服务和子插件自动纳入管理，开发者也可以通过 ctx.effect() 为连接、子进程等资源登记清理函数。Fiber 卸载时会执行这些函数，并等待异步清理完成。

清理顺序决定资源何时释放。Cordis 中的异步清理可以并发执行，存在先后依赖的操作可以放在同一个释放函数中，依次等待完成。DSH 将 Agent Loop 与会话的清理纳入一个复合 Effect，在 Loop 停止并完成 turn/end 等结束事件的发布后，再分离会话，让会话记录覆盖任务的整个收尾过程。

· Agent Loop 的插件化与任务编排

在 Cordis 的统一管理下，Agent Loop 同样以插件形式运行。dsh-agent 定义创建、恢复、收发消息和取消执行等接口，默认的 dsh-agent-loop 则负责组织模型输入、处理模型输出、调度工具，并按回合和步骤推进任务。开发者可以更换 Loop 插件，改变模型请求与工具执行的组织方式，Web 等上层组件仍通过统一接口使用 Agent。

例如，社区的 dsh-slice-agent-loop 替换默认 Loop，重新实现了模型请求的上下文组装。在默认的切片模式下，它把已结束回合中的请求、答复、文件内容与修改整理为结构化记录，在新回合开始时与当前请求、任务目标和文件状态一起组成模型输入。完整交互保存在会话日志中，模型需要查看细节时，可以通过历史检索工具取回原始内容。模型调用、工具执行和会话管理仍使用 DSH 的公共服务。

DSH 的 Workflow 插件采用 Claude Code 的动态工作流形式，让模型根据当前任务编写 JavaScript 编排脚本，将任务分工、协作和验证步骤落实为可执行的程序。脚本通过 agent() 启动子 Agent，用 pipeline() 和 parallel() 组合执行流程，并在变量中保存中间结果。例如，可以让多个 Agent 并行检查不同文件，再安排其他 Agent 验证发现的问题。循环、分支和结果传递由脚本控制，各子 Agent 内部仍由 Loop 推进模型请求与工具执行。

官方 Ralph 工具复用 Workflow 引擎，以固定脚本逐轮推进任务。每轮由新的子 Agent 接收上一轮的结构化交接报告，在共享工作目录中继续推进同一目标。父对话和此前子 Agent 的完整历史不会传入新一轮，实际成果保存在工作目录中，报告负责传递进展、证据和下一步行动。脚本根据子 Agent 报告的继续、完成或受阻状态安排后续执行，并在达到轮数上限时停止。

从替换 Agent Loop，到编写 Workflow 脚本，再到 Ralph 这样的固定策略插件，DSH 支持在不同层次调整任务的执行方式。开发者既可以修改单个 Agent 的执行逻辑，也可以组合已有的 Agent 与工作流能力，将新的任务编排方式实现为插件。

03 Session Log 的运行事实与使用

Session Log 是 DSH 记录运行事实的真源。会话延续、中断恢复、轨迹分析和回归验证都以其中的事件为依据，其他视图与统计也从这份记录中获取事实。

生产环境中的 Agent 会连续执行多轮模型请求和工具操作。模型当时收到的信息、采取的动作，以及提示词、工具说明和上下文的变化，共同构成了定位异常行为、恢复中断任务和复查执行结果的依据。DSH 通过 Session Event Log 保存这些过程，遵循 Model-visible ⟺ logged 的设计原则，即通过会话日志及其引用的附件重建进入模型请求的内容。这使每一步的行为都有对应的输入和执行记录可供检查。

· 请求快照与执行轨迹

在程序实现中，一次会话对应一个 Session 对象。它维护的事件数组（SessionEvent[]）按序号 seq 持续追加，构成 Session Event Log。会话头（SessionHeader）保存会话 ID、创建时间等基本信息，位于事件序列之外。持久化由独立的 SessionPersistence 服务负责，支持 JSONL、SQLite 等存储后端。

事件序列记录模型请求所用的配置、交互消息、工具调用及其结果，以及步骤和回合状态。其中，请求快照（request/header）保存模型配置、系统提示词和工具定义，工具调用与执行结果通过调用编号配对，步骤和回合结束也有对应的事件记录。开发者可以据此还原任务的执行顺序，核对每一步使用的配置和收到的反馈。

早期日志曾遗漏请求配置，插件中途改写的请求也难以追溯。现在，配置变化、注入消息和工具定义先写入日志，再据此构建请求，落实 Model-visible ⟺ logged 原则。模型实际看到的内容应能从日志重建，比较快照便可定位提示词、工具说明或模型配置从何时开始变化。

· 历史记录与请求重建

Surface 是建立在 Session Log 之上、面向模型输入的消息视图，负责把用户消息、模型回复和工具结果整理成当前有效的消息列表。追加操作加入消息，替换操作更新指定范围，原始事件始终保留。开发者既能查看当前输入，也能追溯它如何从历史交互演变而来。

请求重建是指根据日志恢复某次历史请求的消息内容和配置，供开发者对照任务要求与预期配置，核查当时提交给模型适配器的消息、系统提示词和工具定义。DSH 会让 Surface 重新处理该请求之前的日志事件，得到对应的消息历史，再结合当时生效的请求快照，补齐模型配置、系统提示词和工具定义，重新组成交给 Provider Adapter 的逻辑请求。

· 会话延续与中断恢复

Session Log 保存的历史既能用于复查过去的请求，也能为继续执行恢复上下文。继续会话（Resume）会加载原会话的记录，由 Surface 恢复当前有效的消息历史，后续交互继续追加到原会话；创建分支（Fork）则从已结束的回合处分出新会话，复制截至该回合的历史并记录来源。两种方式都复用已有上下文，在当前环境中继续执行任务。

异常中断后的恢复以已经写入磁盘的日志为依据。启用执行检查点后，DSH 会在发起模型请求或执行顶层工具调用前，先保存相应的请求快照或调用开始记录；写入失败时，本次操作便不会启动。工具完成操作后，执行结果还需要写入日志。如果进程在此期间异常退出，文件修改或远端操作可能已经生效，日志却只留下调用开始记录。

对于这类缺少结果的调用，DSH 会在恢复时标记为结果未知。涉及文件修改或远端写入时，应先检查文件或查询远端任务，核实操作是否完成，再决定是否重试；支持幂等操作的工具可以沿用原操作标识，避免重复生效。如果日志中只有模型提出的调用，没有调用开始记录，DSH 会在恢复时向模型补充反馈，说明这次调用尚未被记录为开始执行，并提示模型在仍有需要时重新调用。

· 执行轨迹分析与回归验证

在 Session Log 之上，DSH 可以把事件整理成任务时间线，并按会话或事件查询记录，再生成标题和状态等视图。开发者先根据任务结果和耗时找到异常运行，再回到对应日志检查调用与反馈，确定下一轮修改对象。需要跨任务汇总耗时、Token 用量和错误时，可以启用遥测，将相关会话事件导出到外部系统分析。

修改运行代码后，可以用 LLM Replay 注入固定的模型输出，驱动真实的调度、工具和日志流程，验证运行行为是否符合预期。它回答的是“框架是否按约定工作”，提示词和工具说明是否改善模型表现，仍需通过真实模型实验判断。

Session Log 为任务延续、问题分析和回归验证提供了统一的执行记录。开发者可以据此追溯模型当时获得的信息、执行的操作和收到的反馈，定位问题，并检查修改后的运行行为。恢复会话时，Agent 沿用已有交互历史，在当前环境中继续执行；若要还原当时的工作目录和远端服务状态，需要另行处理。保留下来的运行记录，也为后续比较 Harness 的行为变化、整理可复用经验提供了依据。

04 Harness 优化与 Agent 的持续改进

Agent 自进化的一条路径，是利用任务经验持续改进 Harness，并通过训练让模型学会更有效的执行方式。围绕这条路径，相关研究从运行配置的效果评估，延伸到候选的生成与选择、模型与 Harness 的联合更新，以及改进方法和评价规则自身的更新。

· Harness 的效果评估与反馈改进

同一个模型搭配不同的 Harness，任务表现与执行开销也会发生变化。Harness-Bench 在统一的任务环境、预算和评价规则下，对 106 个任务、8 个模型和 6 套 Harness 进行交叉评估。六套 Harness 的跨模型汇总分最多相差 23.8 分，平均每次运行的 Token 用量为 6.87 万至 17.51 万。

LangChain 对 Deep Agents 的优化进一步展示了如何利用任务反馈改进 Harness。团队固定使用 gpt-5.2-codex，将轨迹分析整理为 Skill，让 Agent 汇总失败原因并提出修改建议。针对模型写完代码便结束任务、遗漏测试的问题，团队据此调整提示词，并通过 Middleware 在任务结束前提醒模型按照任务要求完成验证。结合环境信息补充和推理预算安排等调整，团队将 deepagents-cli 在 Terminal-Bench 2.0 上的得分从 52.8% 提高到 66.5%。

以上研究与实践说明，Harness 的设计会影响 Agent 的任务表现，执行反馈也能够指导这些设计的改进。 在此基础上，自进化研究进一步探索 Agent 如何参与这些改进，包括能够修改哪些对象，以及有效修改如何被选择和持续使用。

· 自进化的修改对象与持续使用

Agent 自进化的核心，是让 Agent 根据任务反馈参与改进自身，并把经过验证的改进用于后续任务。在 Harness 层，这个过程可以从分析执行轨迹开始，由 Agent 总结有效做法与失败原因，提出提示词、Skill 或工具的修改方案，再通过对照实验筛选候选。被采用的修改进入后续任务，新的执行结果继续用于检验已有经验、发现新的问题，推动下一轮更新。

有效操作可以整理为 Skill，也可以改写工具实现、上下文处理逻辑或模型参数。不同对象改变 Agent 获取信息、执行动作和作出判断的方式，独立任务评测则检验这些变化能否带来收益。

本文借用腾讯混元与浙江大学、北京大学、清华大学研究者共同撰写的综述《Diving into Reliable Self-Evolving Agents: A Survey》中的 L0 到 L4 分类，梳理不同自进化方法的修改对象。L0 对应当前任务中的输出或执行过程，L1 更新模型权重或可训练策略，L2 更新 Prompt、Memory、Skill、Tool、Plugin 或 Harness，L3 更新生成和选择候选的方法，L4 更新评价器、奖励或评分规则。这一分类以一次更新中实际生效的最深修改对象为依据，用于区分任务内调整与影响后续任务的持续更新。

对于 DSH，最直接的研究入口是 L2。开发者可以把轨迹中反复出现的错误整理为提示词、Skill 或工具实现的修改，通过 Preset 装入后续任务。Creator 可以参与生成和试装候选修改，Cordis 负责管理相关插件的运行，Session 负责保存执行过程。外部实验系统可以保存候选版本，并在未参与修改过程的任务上比较新旧配置。反复围绕同一批任务调整规则，可能让改动越来越依赖已有样例。通过独立评测，团队可以检查改动在新任务中是否仍然有效、原有能力是否退步，再结合任务通过率与执行成本决定是否采用新版本。

· 候选选择与历史最佳版本

RHO、RHI 和 SkillOpt 是利用任务经验持续改进 Harness 的三项代表性研究。微软亚洲研究院与香港城市大学的 RHO 根据历史轨迹生成 Skill 或工具的修改方案，再依据模型自身的成对偏好筛选候选。Sakana AI 与加州大学伯克利分校的 RHI 比较相邻版本的输出，持续改写文本形式的 Harness；微软研究院开源的 SkillOpt 则在独立选择集上检验 Skill 修改，仅在成绩提高后采用。这些研究为 DSH 的后续实验提供了参考：从执行经验中提出修改，通过候选比较或独立评测检验效果，再将选定的版本用于后续任务。

在持续改写 Harness 的过程中，后续版本也可能出现性能退步，因此需要比较各轮候选的表现。RSIBench-Data 显示，在 58.33% 的实验设置中，后续候选得分超过首个有效版本；在达到峰值后仍继续搜索的运行中，最后一次尝试低于历史最佳的比例为 78.26%。因此，最终采用的版本需要依据评测选择。新尝试出现退步时，较好的旧版本仍可作为运行基线，失败记录则帮助分析原因、调整下一轮搜索。

· 模型与 Harness 的联合更新

Harness 改进会改变训练时采集的 Rollout。工具接口、错误反馈和上下文处理影响模型的执行过程，经过验证的轨迹再用于训练，模型便有机会学会更有效的执行方式。更新后的模型继续执行任务，新的行为为下一轮 Harness 修改提供依据，使运行方式与模型学习相互影响。 围绕这一思路，Co-Harness、HELIX 和 HarnessX 三项研究探索了联合优化的具体实现方式。

Co-Harness 采用交替更新的方式，先固定模型，根据失败反馈改进 Harness，通过验证后，再利用新配置下的执行经验微调模型，随后围绕更新后的模型继续优化 Harness。HELIX 提出了相近的循环，着重探索如何通过组件重组构建和比较不同 Harness，并将候选方案产生的执行差异整理为训练数据。按照其设计，模型学习这些经验后，再重新组合和评估 Harness，使运行方式适应模型能力的变化。Co-Harness 已完成包含模型训练的交替更新实验；HELIX 的实验完成了候选验证和数据准备，尚未实际训练更新后的模型。

HarnessX 则将两侧更新安排在同一轮中。它依据共同的执行经验，分别改进 Harness、通过强化学习更新模型参数，本轮更新不依赖对方刚产生的新结果。待两侧完成后，再由新的模型与 Harness 组合执行下一轮任务，新的运行反馈继续用于后续优化。

借鉴这些方法，DSH 的 Session 轨迹可以与 Harness 版本、代码修改、任务结果和测试记录对应起来，提取经过验证的操作与纠错过程，交给外部流程训练模型。新模型回到 DSH 执行任务，新的轨迹再参与 Harness 改进。

· 改进方法与评价规则的更新

L3 关注的是改进方法本身。使用固定优化器修改 Harness 属于 L2；当候选生成器、选择器或搜索策略也被更新，并影响后续修改时，就进入了 L3。论文《Harness RL is Meta-Learning: Training to Self-Improve at Test Time》研究如何通过强化学习训练 Harness 优化器。它保持任务执行模型的参数不变，让 Proposer 在内层根据执行轨迹改写 Harness，外层再根据采用新 Harness 后的任务奖励训练 Proposer。训练得到的修改策略可以用于后续任务，使“怎样改进 Harness”也成为学习的对象。

L4 进一步修改评价器、奖励或评分规则。评价条件变化后，同一个候选可能得到不同分数，历史结果不能直接横向比较，需要同时记录候选版本与评价器版本。Red Queen Gödel Machine（RQGM）是一个探索 Agent 与评价器共同进化的研究框架。它在每个搜索阶段内固定评价器，在阶段结束时，用固定的留出数据比较新旧评价器，只有新评价器按预设统计标准胜出时才替换旧版。替换后，系统会移除依赖旧评价器的评分统计，并在后续搜索中重新评估受影响的候选，避免混用不同评价条件下的结果。

L3 和 L4 会改变“谁提出修改”和“什么算改进”，因此实验必须记录模型、Harness、候选生成器、选择器和评价器的版本，并保留独立任务与评分依据。现有研究多集中在特定任务域和有限轮次，候选的长期跨任务收益、搜索策略的稳定性和评价器的可靠性仍需要更多验证。

05 让 Agent 在 DSH 中参与自身研发

前述研究将 Harness 修改、候选选择与模型学习联系起来，为 Agent 参与自身研发提供了不同方法。结合 DSH 与 RSI，可以让 Agent 从任务轨迹中发现问题，参与改写影响自身表现的工具、规则与上下文处理方式，再由通过评测的新版本承担后续任务，并继续参与下一轮研发。随着这条反馈链反复运行，Agent 的执行经验就能用于改进产生下一代 Agent 的过程，递归自进化也有了具体的研究对象。

DSH 提供了运行这条反馈链所需的组件。Session 保存模型输入、工具反馈和上下文变化，Creator 可试装插件，Cordis 管理其运行。外部系统再把修改、版本与任务结果对应起来，经独立评测决定是否进入后续任务。

筛选后的轨迹还可以进入外部训练流程，使模型学习有效的工具使用和纠错方式；训练后的模型再回到 DSH，参与下一轮 Harness 修改。随着模型、运行方式和候选评价方法一起迭代，RSI 的观察对象也从单次任务成绩扩展到多轮研发收益。

06 结语

DSH 展示了一种值得继续探索的 Harness 范式。可替换的运行组件与可追溯的执行记录，让开发者能够修改 Agent 的工作方式，并通过真实任务检验结果。进一步结合评测与模型训练，这些实践也为研究模型与 Harness 的共同演进提供了具体依据。

衔远科技长期深入研究 Agent 自进化，并持续开展相关实践。与清华大学联合发布的自进化综述，关注任务经验如何转化为后续可用的能力，讨论了经验如何写入 Skill、记忆、环境配置或模型参数，以及这些更新如何经过检验、持续影响后续任务。Agent 自进化关键是经验落点

环境提供任务执行的条件与反馈，Harness 组织模型与环境之间的交互，并支持经验的保存、调用和更新。在此基础上，研究进一步将改进过程本身作为优化对象，探索系统如何根据以往的改进结果，调整经验筛选、候选生成与评测方法，让积累的经验既用于完成下一次任务，也用于改进下一轮学习的方式。

衔远科技已经构建了以 AI4AI 为核心的企业级 Agent 自进化基础设施，通过 MetaAgent 元智能体进化层支持 Agent 发布后的持续评测与改进。企业的真实业务提供长期任务，也提供判断改进是否有效的依据。将研究方法与业务实践结合，目标是让经过验证的专业经验用于后续工作，并随着新的任务反馈继续完善，使企业积累的经验能够持续改善 Agent 的判断与行动。

随着模型能力与 Harness 设计共同发展，Agent 有望更可靠地承担复杂任务，也更深入地参与研究与工程创新。我们期待这些探索逐步提高 Agent 学习和改进自身的能力，并让改进后的系统参与下一代系统的构建。让 AI 参与创造更好的 AI，将持续进化的能力带入企业的研究、决策与创新，是衔远科技长期投入的方向。

JOTO 企业落地观察

• 企业部署需关注Harness的动态可替换性对系统稳定性的影响：DSH允许在不重启进程的前提下更换Agent Loop、工具插件甚至执行策略，但Cordis依赖检查机制要求服务就绪状态严格对齐，团队需建立配套的依赖健康监测与灰度切换流程，避免因服务重载引发会话中断或状态不一致。
• 智能体工程中，PTC模式揭示了程序化工具调用与模型能力匹配的关键约束：模型需准确理解SDK接口、参数结构与错误返回格式，否则将触发高频改写与重试；企业若采用类似设计，须将接口契约文档化、嵌入训练数据，并在Harness层增加结构化校验与渐进式降级机制，而非仅依赖模型自主纠错。
• RAG知识工程可借鉴DSH的Session Log设计原则：Model-visible ⟺ logged要求每条模型输入均可从日志完整重建，这对企业构建可审计的AI应用至关重要；团队可将该原则延伸至RAG流水线，确保检索源、重排序逻辑、上下文截断策略等全部参与生成决策的环节均被事件化记录，支撑效果归因与合规回溯。
• AI安全治理需正视动态插件带来的执行边界模糊风险：DSH Creator模式允许运行时加载Node.js VM中的动态插件，虽有基础能力遮蔽，但未构成强隔离；企业若引入同类机制，必须将插件签名验证、资源配额限制与沙箱逃逸检测纳入运行时防护栈，不能仅依赖开发阶段的信任假设。