DeepSeek Harness 架构（五）：自由不会消灭复杂度，它会改变复杂度的归属

DeepSeek Harness 架构系列：1 · 系统全景 · 2 · 组合与生命周期 · 3 · 状态与上下文 · 4 · 执行与安全 · 5 · 深入思考

阅读时间为估计，包含图表理解；动手实验另计。

版本边界：本系列沿用官方源码快照 76fda72。它是 developer preview；以下解读不是稳定接口或生产安全承诺。

读到这里，最容易留下的印象是：DeepSeek Harness 把许多难题都做成了插件接口。但前四篇真正揭示的，是另一件事——每一种可替换能力，都带来一组必须持续成立的不变量。

卸载必须清理资源，历史必须可解释，审批参数必须与执行一致，模型上下文必须能追溯，子 Agent 的结果仍需验收。接口让变化成为可能，验证决定变化是否值得接受。

为什么这些机制最后指向同一问题

前文机制	它保护的不变量	仍由谁负责
Effect 与依赖生命周期	插件退出后不留受管幽灵资源	插件作者覆盖外部资源
Session 与投影	界面、模型、审计有共同事实源	存储、版本迁移与保留策略
冻结参数与 Guard	审批事实不被执行链改写	可信宿主与真实外层隔离
Capability Seam	换实现不要求消费者到处判断远端	接口兼容和语义测试
PTC 与子 Agent	控制流与上下文可按任务拆分	预算、协调、清理与结果验收

这张表没有“框架替你负责一切”这一行。可重组运行时把产品原先替用户做的选择，交给了平台团队，也把证明责任交了过去。

它目前还没有解决什么

架构新颖不等于产品成熟。当前至少有六个需要持续观察的问题。

接口稳定性

项目处于 Developer Preview，兼容性破坏是公开承诺。包边界、事件格式、配置行和持久化版本都不应直接当作企业长期 API。

复杂度预算

Cordis 的 Service、Effect、Fiber、Scope、Realm、Waterfall、Profile、Bundle、Preset 和 Seam 各自合理，但组合起来学习曲线很高。平台团队得到极强可塑性，普通团队也可能得到一套只有少数人敢改的运行时。

动态组合的运维成本

Preset 新代际不会自动回收；复制出来的 Preset 是会漂移的快照；部分 HMR 只跟踪组合文件，而不会感知旁边 Skill 或 Asset 的变化。这些限制已经记录在官方 Preset 文档中，说明运行期可组合仍有资源回收和版本治理问题。

安全仍依赖外层基础设施

文件 Sandbox 不等于网络隔离，Worker 不等于容器，Approval 不等于最小权限凭证。对生产多租户或不可信输入，仍需要容器、VM、网络策略和密钥 Broker。

缺少公开性能证据

PTC、不同 Preset、Compaction 和 Multi-Agent 都可能显著改变成功率、延迟与 Token 成本，但官方仓库尚未给出系统性对照结果。现阶段应把它当成可实验平台，而不是已经证明优于成熟 Coding Agent 的产品。

“所有东西都可替换”会削弱默认答案

Claude Code 和 Codex 的价值之一，是为大多数用户提供强而一致的默认工程制度。DeepSeek Harness 把选择权交给部署者，也把评测、安全、兼容和维护责任一并交了出去。自由度是平台优势，也可能是最终用户的负担。

如果要用它建设自己的 Agent，应该怎样分阶段

阶段一：固定组合，先证明单 Agent 闭环

从 standard 或 sdk-minimal 开始，不做运行时自修改。只保留少量高质量工具，建立明确的任务完成条件、测试和 Diff 审查。Session Persistence、取消、超时和失败恢复必须先于多 Agent。

成功标准不是 Demo 能调用工具，而是：任务中断后可以恢复，模型可见输入能够重构，所有外部修改都有验证证据。

阶段二：建立自己的 Capability Seams

把企业能力拆成 Definition / Provider / Consumer：例如“读工单”是稳定接口，Jira 或 Linear 是 Provider，模型 Tool 与后台 Workflow 是不同 Consumer。不要让模型工具直接绑死底层 SaaS SDK。

同时为每个 Tool 定义：输入 Schema、Canonical Output、模型投影、超时、并发属性、审批理由和最终 Guard。

阶段三：按风险划分 Preset

不要做一个拥有所有权限的万能 Agent。至少拆成：

只读分析 Preset；
Workspace Write 编码 Preset；
可访问生产 API、必须审批的运维 Preset；
仅供平台开发者使用的 Creator Preset。

Preset 决定模型看到的能力，外层 Sandbox、网络和凭证策略决定它实际上能影响什么。

阶段四：用评测决定是否启用 PTC 与 Multi-Agent

PTC 适合工具调用链长、中间结果大、控制流容易用代码表达的任务；Native Calling 更适合每一步都需要模型重新判断的任务。Subagent 适合上下文隔离和独立探索，Agent Team 只在共享任务图与持续通信确有价值时启用。

对照实验至少记录：任务完成率、测试通过率、模型请求次数、总 Token、墙钟时间、人工接管次数、越权请求和恢复成功率。架构允许替换只是起点，评测才能决定哪种组合值得保留。

阶段五：把插件发布当作供应链发布

插件拥有与宿主同进程的能力，Preset 甚至可能等同 Shell 权限。企业需要锁定版本、审查来源、生成 SBOM、签名发布，并为配置变更保留可回滚记录。不要把“插件市场”当成低风险 Prompt 分享站。

真正的复杂度预算，是允许多少种组合进入生产

假设三个模型、三种工具集、两种存储、两种执行环境都可以独立替换，理论组合已有 36 种。这个数字只是乘法示例，不是该项目的部署统计；重要的是每个组合还带着取消、恢复、升级和权限例外。

不需要测试所有想象中的组合。更实用的办法是区分“框架允许的组合”和“组织支持的组合”：后者是少量锁定版本、拥有负责人、通过契约测试、可回滚的配置。

flowchart LR
  P[所有可表达组合] --> C[组织批准的有限配置]
  C --> T[契约、恢复与权限验证]
  T --> R[版本化发布]
  R --> O[运行证据]
  O -. 证明收益后扩展 .-> C

图 1｜把可表达组合收敛成组织支持的有限配置。矩形表示模块或步骤，圆柱表示存储，菱形表示判断；实线表示主路径，虚线表示约束、信息支撑或反馈。图为教学抽象，不代表全部实现细节。

如果没有这层收敛，灵活性会变成配置漂移；如果收敛过早，又会把平台重新做成不可替换的固定产品。合理的边界由实际任务变化和维护能力决定。

最终判断：把变化当作需要发布的产品

DeepSeek Harness 值得研究的地方，是让 Agent 的组成成为显式对象，而不只是一份越来越长的 Prompt。但这不证明动态性越高越好。

对于流程稳定、缺少平台维护能力的团队，成熟默认产品可能更省心。对于需要比较 Loop、上下文和执行策略的研究者，可替换结构则能降低实验成本。选择应依据控制对象，而不是“所有东西都能插拔”的吸引力。

因此，前面所有机制最终可以收束为一条纪律：不只给代码做版本，也给运行组合、事实语义与权限边界做版本；不只验证一次任务，也验证系统在变化中仍然能解释自己。

开源运行时提供了材料，是否成为可靠工作系统，取决于部署者能否把这种材料组织成有限、可验证、可维护的默认答案。

上一篇：执行与安全。

本系列到此完成。可以与 Pi 架构深读对照：两者都重视可塑性，但把默认机制和产品策略放在了不同位置。