DeepSeek Harness 开源：连 Agent Loop 都能换掉

DeepSeek 在 2026-08-13 放出了自己的 Harness 开发者预览版 v0.1，源码以 MIT 协议开放。过去几个月围绕 AI 编码的讨论正在从模型转向 Harness——同一个模型放进不同的智能体系统，表现可以差很远，因为模型只负责预测下一步，而 Harness 决定它能看到什么、能调用哪些工具、上下文怎么组织、出错怎么重试、以及什么时候算做完了。

插件边界下沉到了整个运行时

主流编码智能体大多支持插件、MCP 或自定义工具，但可扩展范围通常停在工具与技能层。DeepSeek Harness 把这条边界一路推到底：模型、工具、技能、会话、沙箱、存储、Agent Loop、调度和 UI 全部由插件组成，替换任何一层都不需要改 Harness 源码。

底座是 Cordis 元框架，它本身只处理插件的加载、卸载与依赖，具体能力由插件提供，插件之间通过服务和事件协作，再由配置决定它们怎么组合。

工具调用也被拆成一条可扩展流水线：请求执行前依次经过 Hook、审批、权限检查、沙箱与超时控制，执行后还能改写结果、记录和渲染。程序化工具调用（PTC）产生的代码及其子调用同样走这条流水线，不能绕过审批与沙箱——这一句比整套插件架构更重要，因为它决定了「什么都能换」有没有掏空安全边界。

四种模式其实是四套插件组合

它没有维护四套系统，四种模式的差别只在默认加载哪些插件：

1. 标准模式：完整工具组合，面向常规智能体任务。
2. PTC 模式：允许模型生成代码，把多轮工具调用组合起来一次执行。
3. 极简模式：只保留 shell 与文件编辑两个工具，用来在最小环境里测模型本身的能力，减少其他组件干扰。
4. 创造模式：智能体检查自己所处的运行时，在内存中试装 Cordis 插件，据此组合出新的运行模式。

第四种是真正的新东西。传统 Harness 的运行方式由产品开发者预先写定，用户只能在既有配置里选；创造模式让配置本身成为智能体可以操作的对象。它离「智能体改造自己的 Harness」还有多远，要等真实任务来验证。

所有轨迹汇进同一条事件流

模型看到的每一样东西都进入同一份仅追加的会话日志：系统提示词、推理内容、工具调用及其结果、子智能体调度、每一次上下文注入。任务失败时，问题可能出在模型判断、工具返回、上下文注入、调度策略或系统提示词中的任何一处；这些内容散落在不同组件里，就没人能还原模型当时究竟看到了什么。统一事件流给调试、评估和回放提供了一份共同底稿，也让会话分叉有了自然的数据结构——新分支沿用分叉点以前的事件，再追加新的行动，不必覆写历史。

多智能体：架构有新意，编排没有突破

父智能体可以用 Spawn 启动全新上下文的子智能体，也可以用 Fork 让它继承已有会话；更复杂的任务可以由模型现场写 JavaScript，用 parallel() 与 pipeline() 组织并行或流水线，或用 Ralph 模式让多个全新智能体按轮次接力。

放进常见编排模式里，它最接近层级式的 Supervisor–Worker，离真正的 Swarm 还远：任务分配与控制权仍然握在父智能体手里，没有智能体之间的自主发现、协商与动态接管。Spawn、Fork、Pipeline、Ralph 都有成熟先例，特别的地方在于它们被做成了可随配置替换的插件，甚至可以把 Claude Code、Codex 或支持 ACP 的外部智能体接到同一个子智能体接口后面。

报道之外，仓库自己说了什么

正文来自 InfoQ 中文的报道，但仓库元数据可以一手核对。截至 2026-08-16，deepseek-ai/deepseek-harness：MIT 协议，TypeScript，创建于 2026-08-13，114,625 star、11,151 fork——两天半，量级确实罕见。

同一份元数据里还有三个数字，方向相反：

• 未关闭的 issue 是 0，对一个 11 万 star 的 v0.1 预览版来说，几乎只能解释为 issue 功能被关掉了。
• 最后一次 push 仍是创建当天，而发布说明写的是核心插件与基础接口会「快速迭代」。
• 没有任何 GitHub release，版本号只出现在提交信息里，最新一条是 0.1.0-rc.5。仓库创建当天 PR 编号已经到 #2519，说明它是私下开发完再一次性推上来的。

所以这个 star 数量度的是注意力，不是采用。同一轮里那份开放模型生态报告给了这句话系统性的证据：在 Hub 上按下载量排前 25 与按点赞数排前 25 的仓库，只有一个同时出现在两张榜上。

边界

这条是二手报道加一手仓库核对。v0.1 阶段接口会快速变化，现在进入生态要承担迁移成本；插件边界越深，接口稳定性、依赖管理、版本兼容、性能开销与调试复杂度就越难控制。而且「什么都能换」不会自动带来更高的任务成功率——最终兑现它的仍然是默认插件的质量、稳定的组合范式和可信的评测结果。