DeepSeek Harness 架构: Cordis 与插件运行时

要理解 DeepSeek Harness，最短路径不是先学界面和命令，而是看它怎样把模型、工具、会话、循环、沙箱和 UI 组合成一个运行时。Cordis 是这套组合模型的底层，它决定了插件怎样挂载、依赖怎样替换，以及卸载后副作用怎样被撤销。

本篇属于 DeepSeek Harness 系列。系列不重复追逐插件快讯，而是从成熟度、运行时、记忆、安全和评测五个层面判断它能否成为长期基础设施。

撰写说明：本文使用 DeepSeek Harness 辅助撰写，并由人工编辑校对。

DeepSeek Harness 系列

技术架构、能力边界与当前缺口

DeepSeek Harness 最值得你学习的并不是它的 UI，而是它下面的 Cordis composition model。

Cordis 论文把自己的问题定义成“时空可组合性”：组件不仅能够动态加入，还要能移除并撤销 side effects；依赖发生变化时，组件能够响应式重新组合。论文把它概括为 revertible effects + reactive coeffects，并实现为 Cordis meta-framework；论文目前仍明确标记为 active revision 的 preprint。

DSH 在此之上构建出的结构大致是：

Profile
  └── Bundles
       └── Cordis Plugins
            ├── LLM Adapter
            ├── Agent Loop
            ├── Tool Registry
            ├── System Prompt
            ├── Session
            ├── Storage
            ├── Sandbox
            ├── Approval
            ├── Skills
            ├── Subagents
            ├── Workflow
            ├── Web
            └── UI

官方 architecture 文档显示，profile 是按顺序叠加 bundle 和 patch 形成的 plugin tree；dsh-base 提供 model adapters、tools、persistence、sandbox/approval、settings、credentials、telemetry，而 Web profile 再加浏览器应用，headless profile 则提供没有 server 的 one-shot runner。核心 session、system prompt、tools、agent、agent-loop 和 LLM adapter 本身也都是清晰分离的能力。

这是一种非常适合 Digital Twin 的哲学，因为你可以做到：

我的身份 ≠ DeepSeek
我的记忆 ≠ DeepSeek
我的工具 ≠ DeepSeek

DeepSeek / OpenAI / Anthropic / local model
             ↓
      interchangeable model
             ↓
       stable twin runtime
             ↓
    stable identity + memory

技术能力矩阵

层面	DeepSeek Harness 当前能力	对数字分身的意义
架构	Cordis；Everything-is-a-plugin；profile/bundle/patch composition	非常适合把 Persona、Memory、Connector 做成独立模块
Agent runtime	Standard / PTC / Minimal / Creator	可针对低成本、开发、执行场景使用不同 harness
Agent loop	独立 plugin / service seam	可替换、拦截、治理 agent 行为
Tools	scoped registry + guarded execution pipeline	适合数字分身 Actions
Session	append-only event log	极适合审计和 trajectory
Subagents	原生 subagent；Claude Code/Codex bundles	可以做研究者、记忆管理员、执行者等角色
Workflow	workflow seam、并发子任务控制	可以编排长任务
Model	DeepSeek adapter + 可扩展 adapter / compatible provider 路径	数字分身避免被单模型锁定
MCP / ACP	已进入正式 runtime/SDK 生态	非常适合外接个人数据/工具
Headless	one-shot headless profile	可作为 backend worker 使用
UI	Web UI 本身也是 composition 的一部分	可换成你自己的数字分身 UI
Storage	session persistence / storage seams	能换 backend，但不代表完整数字分身 memory
Sandbox	sandbox + approval policy	有基础能力，但还不能当绝对安全边界
Observability	append-only trajectory、resume/fork/search/replay	是 DSH 最适合数字分身的一项能力

官方的 append-only session log 很有价值：system prompts、reasoning、tool calls/results、subagent scheduling、context injection 都可以记录；Trajectory 可以按来源检查，而 resume、fork、search、replay 都基于同一 event stream。

这对数字分身非常关键，因为真正的数字分身不应该只有“回答”，而应该具有：

为什么它这么认为？
它用了我的哪条记忆？
谁授权它执行这个动作？
它调用了什么数据？
结果是什么？
之后它因此学到了什么？

DSH 的 trajectory 已经覆盖了其中相当大的一半。

官方 config catalog 也暴露出了大量值得学习的 capability seam，包括 FileSystem、SessionPersistence、SessionQuery、Credential Provider、Shell/Subprocess、Sandbox、Spill Store、Code Runtime、Workflow Engine、Attachment Store 等，并提供 API gateway/remotes 等组件。用户 approval 默认可设置成 ask 或 fail-closed 的 never；workflow worker 也有 child agent concurrency 和 total-call ceilings。

但这里有三个容易误解的地方。

第一，Session Log 不等于 Long-Term Memory。

Session 更像：

这次 Agent 做了什么

数字分身记忆则是：

我是谁
我经历过什么
我认识谁
什么信息现在仍然有效
我过去是怎么决定的
什么只是推测
什么已经被我要求忘掉

因此不能简单地：

所有聊天记录
    ↓
Vector DB
    ↓
Digital Twin

真正的数字分身至少需要：

episodic memory + semantic facts + preferences + relationships + temporal validity + provenance + confidence + deletion policy

DSH 目前没有替你解决完整的这一层。

第二，Persona Prompt 不等于 Identity。

DSH 的 system-prompt/plugin architecture 足够让你注入 persona，但生产级 digital identity 还需要：

stable person_id
identity version
source provenance
preference strength
belief confidence
effective_from / effective_to
private/public scope
consent
who may read
who may act

这些应该是外部 canonical model。

第三，Plugin Extensibility 不等于 Plugin Security。

第三方 plugin 是代码供应链。社区甚至已经在构建 capability manifest、workflow isolation、plugin-reducer 等治理工具，这反过来说明插件越强，治理越重要。社区项目 dsh-capmark-gate 的作者特别指出，它能治理 agent 可调用的 tools，却不能 sandbox plugin 自己的代码，因为 plugin 本身在宿主进程运行。这是社区分析而不是 DeepSeek 官方安全保证，但对于架构设计很重要。

此外，PTC / run_code 的 worker-thread runtime 官方代码/社区讨论本身也强调 containment 不等同于 hard security boundary；已有讨论建议真正的安全边界需要 container 类 backend。

所以对于数字分身：

不要让“Agent 能力插件”和“用户个人数据权限”共用一个隐式信任域。

数据层应该比 Agent 层更可信。

在 Scalability 上，我没有在本次审阅的第一方材料中发现 DeepSeek 已经给出多节点 HA、tenant isolation、distributed session sharding、生产级 cluster scheduler 的明确架构保证。相反，官方明确把产品描述为 local-first，默认把 input/output/session、tool records、attachments、路径、API keys 等数据保存在用户本地；headless profile 也是 one-shot runner。因而把它理解为单用户/单 runtime 优先的 agent kernel，比把它理解为 Kubernetes 上成熟的多租户 Agent Platform 更稳妥。这是根据目前官方材料做出的架构推断。