DeepSeek Harness 新玩法：Agent 监督 Agent 的自进化实验

一个「左脚踩右脚」的自进化设想

近期一位 B 站 UP 主分享了基于 DeepSeek Harness（下文简称 DSH）的实验性玩法：让一个 Agent 去监督、调试并进化另一个 Agent 软件。用他自己的话说，这是「左脚踩右脚」式的自我迭代——用官方原版 DSH 当稳定的监督者，去驱动自己开发的 Agent 完成真实任务，再自动记录问题、下发修复，形成闭环。

整套流程的核心提示词几乎全部由 AI 生成，作者一共开了三个实例协同运转。目标很直接：晚上睡觉前把任务交给这套系统，让它尽可能自主跑一整夜。这种「无人值守的软件自进化」思路，正是这个实验最吸引人的地方。

三个实例的分工架构

作者用绘图工具拆解了整个系统的构成，三个实例各司其职：

监督 Agent：DSH 官方原版

这是整个流程的驱动者，使用 DeepSeek Harness 的官方原版。它有意「不参与任何实际开发」，运行的也不是被开发中的那套代码，因此保持了足够的稳定性。它负责派活、监控执行轨迹、归档结果，并在必要时重新编译打包被开发的 Agent。

执行 Agent：自研的 Cotine（Crum）

作者自己开发的 Agent 名为 Cotine，简写为 Crum，跑在 CDP debug 端口 9222 上，是一个编译好的 debug 版应用。它有两种模式：一种是任务模式，由自身决策是否并行；另一种是指挥模式，只负责调度子 Agent 并行执行。开发这套并行能力是否达到预期，正是本次实验要验证的目标。

CDP（Chrome DevTools Protocol）是 Chrome 浏览器暴露的一套调试协议，允许外部程序通过 WebSocket 连接，以编程方式控制浏览器或基于 Chromium 的应用——包括读取 DOM、执行 JavaScript、监听网络请求等。Electron 应用本质上是用 Chromium 渲染的桌面程序，因此天然支持以 --remote-debugging-port 参数启动 CDP debug 端口。9222 和 9333 两个端口即通过这种方式分别暴露给监督 Agent 和验证实例，使外部程序可以像操控网页一样操控这两个 Agent 应用的界面与逻辑。

验证实例：Crum Debug（9333 端口）

第三个实例跑在 9333 端口，与 9222 完全隔离，专门用于独立验证。执行 Agent 完成任务后，监督 Agent 可以在这个隔离环境里单独跑一轮核验，最终评估执行效果。

台账机制：让闭环真正「不停下来」

这套系统能自主运转的关键，是一个台账机制。作者把所有要解决、要思考的问题都以台账形式记录，交由监督 Agent 管理和派活。

真实业务下发到执行 Agent，做完后评估效果：OK 就进入下一条；不 OK 就把会话中的堵点、卡点和不合理情况转化为 bug，重新记回台账继续处理。原则上，只要台账里还有任务，系统就不会停下来。

值得一提的是，作者用来测试的「真实业务」恰好就是修复这套程序自身开发中的问题——用一个 Agent 去进化另一个 Agent 软件，形成了名副其实的自我迭代循环。

台账机制在工程上本质是一种持久化任务队列，类似于生产环境中常见的消息队列或工单系统（如 Jira、Linear）。它的关键价值在于将「任务状态」从易失的会话上下文中剥离出来，写入外部存储。这样即便 Agent 会话因上下文压缩、超时或重启而中断，任务进度也不会丢失——重新拉起后只需重新读取台账即可恢复工作。在 AI Agent 场景中，这种设计还能天然应对「幻觉式完成」问题：任务只有经过评估确认后才能出队，否则转化为 bug 重新入队，形成有状态的闭环，而非靠模型自我报告进度。

一夜实验的复盘：空转 bug 与自我修复

实验并没有完全按设想跑通，但过程本身很有价值。作者复盘发现，凌晨 2 点左右系统因「静默 903 秒提前退出」停了下来。

原因是一个典型的并发协调问题：从业策略在干活，主业策略在等待，而守护 Agent（作者称为 Gone）退出去查看时发现事情「没有被驱动」，于是进入休眠——但休眠时并没有挂上新的等待，导致整个循环空转。加上作者为了省 token 暂停了新 turn 的开启，问题被进一步放大。

早上重新拉起后，系统先复盘了这个问题，随后加强了循环和等待逻辑：守护 Agent 唤醒执行 Agent 后，会给自己上一个 loop，采用分块等待，每十分钟检查一次。这样既大幅降低了 token 消耗，又保证任何情况下都能被重新唤醒。修复之后，系统一直持续运转到录制视频时仍未中断。

为什么要用官方原版当监督者

作者特别解释了架构设计的一个关键取舍。DSH 官方虽然提供了热启动（HMR）功能，但如果只在单个实例里开发并 debug 自己，一旦修改涉及 host 端重启，就可能把自己的实例停掉，导致整个 Agent loop 断裂。

因此他选择用官方原版作为稳定的外部驱动者：由它来解释需求、更新 Crum Debug Release，等关键 bug 开发验收成功后，再由原版重新打包发布最新版本、拉起实例并下发新指令。需要验证时，则单独编译出 9333 的 debug 实例做隔离测试。这种「监督者与被开发者物理隔离」的设计，是保证长时间无人值守运转的核心。

前端可操控：Chrome DevTools MCP 的接入

由于 DeepSeek Harness 的前端——无论桌面版还是 Web 版——都是基于前端技术、可用 Chrome 引擎渲染的应用，作者给系统配置了 Chrome DevTools MCP，并集成进 Electron 应用中，使 Agent 能够直接访问和操作界面。

监督 Agent 正是通过 CDP 操纵执行 Agent 去解决真实任务，再监控其完成效果。9333 验证实例的启动命令也很简单：在本地回环打开 9333 端口，应用启动时便开启 debug 关口供编程助手使用。

MCP（Model Context Protocol）是 Anthropic 提出并逐渐被多个 AI 框架采用的一套开放协议，旨在为大模型提供标准化的「工具调用」接口，让 Agent 能够以统一方式接入外部能力——文件系统、数据库、浏览器控制等均可封装为 MCP Server。Chrome DevTools MCP 即是将 CDP 协议包装成 MCP 工具集，使 Agent 无需手写底层 WebSocket 通信，即可通过标准工具调用指令完成「点击按钮」「读取页面内容」「执行脚本」等操作。将其集成进 Electron 应用后，监督 Agent 实际上获得了对整个桌面应用 UI 层的完整编程控制权。

多轮上下文压缩会不会「失忆」

长时间运转必然带来上下文膨胀问题。作者的会话经历了多次 context 压缩，但他认为台账机制正好解决了「失忆」隐患：整个上下文提示词、目标注入都能让 Agent 从台账里重新拉回「现在要做什么」。视频中就出现过一次被压缩后又「救回来」的情况，验证了这套机制的鲁棒性。

不过实验也暴露了现实约束——作者当时使用的 KP3 通道吞吐量偏低，导致执行明显变慢，他表示后续会换回更快的方案。

这套玩法的启发

这个实验展示了一个颇具想象力的方向：用一个稳定、隔离的监督 Agent，去自动驱动、验证并进化另一个正在开发中的 Agent 软件，配合台账机制实现近乎无人值守的持续迭代。

尽管目前仍是个人探索阶段，存在空转、吞吐等实际问题，但它对想开发 DeepSeek Harness 插件的开发者提供了一条清晰的思路：把不稳定的被测系统与稳定的调度系统解耦，用持久化的任务台账维持闭环，用隔离实例做验证。这三点组合起来，才让「Agent 监督 Agent 自进化」从概念变成了可以跑起来的工程实践。