下一代 Agent Harness 也许不该有一个永远不能被替换的核心

8 月 13 日，DeepSeek 在 GitHub 上公开了 DeepSeek Harness。

README 里有一句话很扎眼。

「Everything is a plugin。」

插件当然不新鲜。Claude Code 有 Skills、Hooks 和 MCP，Codex、OpenCode、Gemini CLI 也有各自的扩展方式。只看这句话，它很像又一套插件系统。继续翻 DeepSeek Harness 架构文档，差异出现在 Agent Loop 上。

模型适配器是插件，工具注册是插件，会话日志是插件。负责接收消息、调用模型、执行工具并判断任务是否继续的 Agent Loop，同样是插件。

DeepSeek Harness 已经采用 MIT 许可证开源，GitHub 源码和 npm 包都可以直接访问。2026 年 8 月 14 日读取到的 npm 版本为 0.1.0-rc.6。官方把项目标为 Developer Preview，并提醒后续会有破坏兼容性的改动。

当前最值得看的，是它把一个重要问题写进了代码。Agent 的运行核心是否必须永远固定？

Agent Loop 也能换，差异从这里开始

很多人每天都在使用 Claude Code 或 Codex，却不一定会专门提到 Harness。

你把一个修复任务交给 Codex。模型负责理解任务和决定下一步，但它不直接管理电脑。哪些文件能读，命令怎样执行，危险操作何时需要批准，工具结果如何放回上下文，对话太长以后怎样压缩，这些工作都由模型外面的系统处理。

这套把模型、工具、权限、记忆和执行过程组织起来的系统，就是 Harness。

同一个模型放进不同 Harness，长任务中的行为会出现明显差异。一套系统会在修改前读取文件，并在内容被外部进程改动后拒绝覆盖。另一套系统可能拿着旧版本直接写回。一套系统能在进程崩溃后区分命令没有开始和结果未知，另一套系统只能重新执行。

模型影响一轮推理能走多远，Harness 经常影响任务能否稳定做完。

多数 Agent 产品都有相对固定的运行核心。插件可以增加工具、接入数据，也能改变部分工作流。负责驱动整个 Agent 的循环通常不会交给插件系统。

DeepSeek Harness 继续往里拆。Agent Loop 不再拥有特殊地位，不同 profile 可以选择不同循环，新的工作流也不必修改一个全局核心才能接进来。

自由度提高以后，系统必须回答两个问题。替换在哪个范围生效，插件卸载以后又该回到什么状态？

插件可以替换服务，也必须收拾干净

DeepSeek Harness 底下的 Cordis 会把插件提供的服务、事件和副作用放进同一个共享上下文。

插件装上以后可以增加服务，也可以替换已有服务。卸载时，它注册的能力和造成的影响需要一起撤回，依赖这些能力的组件也会收到变化。

Cordis 论文把这套思路称为时空可组合性。代码里的含义更直接。一次替换要说明换了什么、在哪个范围有效、持续多久，以及撤回后恢复到哪种状态。

DeepSeek Harness 的 Web 模式和 headless 模式就是不同 profile。底下共用一组基础能力，上面继续叠 bundle、个人 patch 和命令行 patch。执行环境也能替换。本地文件系统和子进程可以由 E2B 远程环境接管，Bash、PTY 与 LSP 随底层 provider 一起移动，不需要各写一套远程版本。

这项 E2B 组合仍被官方称为 experimental POC。架构方向已经公开，成熟度需要单独判断。

会话系统更能说明这种设计如何落地。

用户看到的是聊天消息，DeepSeek Harness 保存的是一条只能向后追加的事件记录。用户输入、模型输出片段、工具调用、工具结果与 step 边界都会成为事件。模型下一轮看到的历史，再从这些事件中推导。

官方给了它一条很重要的约束。凡是模型能看见的内容，都必须能够从会话日志里重新构建。

上下文太长时，系统可以缩短巨大的工具结果，再压缩更早的内容。模型看到的表面变短了，原始事件仍然保留。会话恢复、分叉和转录都围绕同一份记录工作。

进程崩溃后，这份记录还能区分两种情况。工具没有开始执行，可以重新安排。工具已经发出但结果没有回来，系统会把它标成结果未知，提醒模型谨慎处理带副作用的动作。

读取操作多跑一次，通常只是多花时间。会修改外部状态的命令多跑一次，可能就要有人收拾结果。

仓库里的组件文档还会交代它们让模型看到什么，需要多少 token，是否影响 KV Cache。文档没有给出一组跨产品成本对照，但团队确实把上下文成本放进了组件契约。

Agent 开始检查承载自己的 Harness

沿着 Cordis 继续往下看，会遇到这个项目里更少见的一项能力。

DeepSeek Harness 给模型提供了几种 Cordis 工具。模型可以查看当前进程中的服务、插件、工具和事件，也能定义一个临时插件。这个插件可以注册工具、补充提示内容、监听事件，甚至增加浏览器界面插槽。

Agent 因而可以检查承载自己的 Harness，再为当前任务补上一小块能力。

这项能力有明确边界。临时插件写好以后，需要用户在界面中启动。它只存在于当前进程，重启后消失，也不会自动写回配置。官方还说明，内部 VM 隔离不构成安全边界，这项能力应按 Bash 权限对待。

运行时自检和临时扩展，是目前更准确的描述。模型过去只能使用预先准备好的工具，现在还可以先查看周围有哪些能力，再针对眼前任务提出扩展。

DeepSeek Harness 对其他 Agent 的处理也很开放。

它的 subagent 接口可以连接不同 provider。本进程能启动新的子 Agent，也能从父会话已经完成的历史分叉。进程外可以通过 ACP 接入其他 Agent，还能启动 codex app-server --stdio，或者通过 Anthropic Agent SDK 调用 Claude Code。

dsh 可以把 Codex 和 Claude Code 当成两种外部子 Agent。

当前实现的限制不少。这两个 provider 默认关闭，不会继承父 Agent 的完整对话和全部工具，只会拿到一项独立任务与同一个工作区。父 Agent 最后只能收到最终回答，看不到连续进度，也没有恢复、池化和交互式审批。

这些限制没有被藏起来。很多组件 README 都保留了 Known Limitations and Deferred Work，哪些还是 POC，哪里缺少验证器，什么情况下会丢中间进度，都写得很具体。

野心很大，边界也写在旁边。这是项目目前很难得的一点。

和 Claude Code、Codex、OpenCode 放在一起看

同类产品都在处理工具、权限、记忆和多 Agent，固定下来的东西却不一样。

Claude Code 是一款完成度很高的产品。CLAUDE.md、Skills、Hooks、MCP 和 Subagents 已经形成成熟的使用方式。扩展面很丰富，产品内部哪些部分允许彻底替换，仍由 Anthropic 决定。

Codex CLI 采用 Apache 2.0 开源。它把本地 Agent、沙箱、审批和 App Server 协议做成了一套完整运行系统，现在还连接桌面应用、IDE 与云端任务。Codex 的扩展接口围绕这套产品系统展开。

OpenCode 采用 MIT，支持大量 provider 与本地模型，TUI 和客户端直接面向日常使用。开发者可以自由选择模型，这是它很明确的优势。

Gemini CLI 把 Gemini、多模态、搜索和 Google 生态放进一个 Apache 2.0 的终端 Agent。LangChain Deep Agents 更接近面向 Python 开发者的框架，提供基于 LangGraph 的子 Agent、文件系统 backend、记忆和 tracing。

Claude Code、Codex 与 Gemini CLI 优先交付完整产品。OpenCode 让开发者更自由地选择模型。Deep Agents 方便开发者把 Agent 嵌进应用。DeepSeek Harness 更关心运行时怎样组合，连 Agent Loop 也没有永久席位。

这种选择不会自动带来更好的体验。

多数用户只想让 Agent 修好 bug，并不关心 session log 由哪个 provider 实现，也不想理解 profile、bundle、scope 与 patch。可以替换的部分越多，配置、兼容和排错的成本也越高。经过长期打磨的固定核心，通常更容易提供连贯体验。

DeepSeek Harness 的安全能力也在早期。它提供 read-only、workspace-write 和 danger-full-access 三种模式，默认使用 read-only。Linux、macOS 与 Windows 分别接入不同隔离机制，需要的隔离能力不可用时，设计目标是直接失败，不自动退回无限制执行。

网络和完整进程策略还没有进入同一套 sandbox vocabulary，Windows 隔离被官方标为部分能力。Approval 目前只有一次性的 ask 与 never，没有长期授权记录。Plan Mode 提供行动指导，执行限制仍由 sandbox 和 approval 承担。

DeepSeek Harness 也没有公开横向 benchmark。官方的 BENCHMARK.md 主要说明怎样准备独立工作区和 session，没有证明它比 Codex、Claude Code、OpenCode 或 Gemini CLI 更快、更准或更省 token。

现在能够确认的是架构边界和实现选择。生产成熟度要等后续版本与部署证据。

没有永久核心，系统靠什么保持连续

过去两年，我们习惯按照模型名字理解 Agent。Claude Code 背后是 Claude，Codex 背后是 OpenAI，Gemini CLI 背后是 Gemini。模型几乎成了产品的身份，Harness 负责把它送到用户面前。

DeepSeek Harness 把这层绑定放松了一些。

模型可以换，执行环境可以换，子 Agent 可以来自其他产品。整理会话的实现能够替换，Agent Loop 也能够替换。模型正在使用的能力，甚至可以在当前进程中临时增加。

这些部分都能变化以后，一个 Agent 靠什么保持连续？

忒修斯之船的木板被一块块换掉。原来的木板全部消失以后，它还是原来那艘船吗？

DeepSeek Harness 给出的回答很工程化。系统不用把连续性寄托在某一块永远不动的代码上。服务之间的契约、可以重新构建的会话事件，以及插件卸载时必须遵守的规则，共同保证系统在组件变化后仍然知道自己做过什么。

稳定性被放在契约、事件语义和卸载规则上。具体模块可以更换，模块之间怎样交换信息必须写清楚。缺少这些约束，「一切皆插件」很快就会变成「哪里都可能出问题」。

固定核心越少，契约越重要。仓库里那些异常详细的 README，都在回答相似的问题。一个组件提供什么，能看到什么，卸载后留下什么，连 token 与 KV Cache 的变化也要交代。

同一原则也会落到更窄的工具结果层。LIU/lennney 维护的 MCP Slim Guard 把上游执行与模型看到的结果视图分开，让结果变短时仍能精确恢复原文。它没有改造整个 Harness，只处理可替换组件之间容易含糊的一条边界。实现与限制可以在 lennney/mcp-slim-guard 核对。

DeepSeek Harness 还没有证明这套设计会成为行业未来。它已经把一个可以继续验证的选择公开出来。

下一代 Agent Harness 也许不该有一个永远不能被替换的核心。

它仍然需要清晰的契约、可追踪的历史，以及人随时叫停的权力。模型、工具、记忆实现和执行环境则可以由任务决定。