拆开 DeepSeek Harness：插件图如何变成一次 Agent 运行

CLI 启动 Node 进程，解析 profile、home 和 patch 等配置来源，创建 Cordis Context，再挂载特权 Loader/Include。Loader 根据配置文件所在位置解析模块并加载插件。研究实验已经证明：插件装在错误 package root 时会直接 ERR_MODULE_NOT_FOUND。

因此“配置内容相同”不等于“运行环境相同”。企业级 Runtime receipt 需要记录 artifact identity、完整依赖闭包、配置解析根的安全摘要、合成后的 effective config digest，以及 Loader 版本。仅固定一个 npm 入口 SRI，无法说明其大量依赖解析结果。

这也是为什么 Lumi 应拥有 Runtime Admission：先验证闭包、配置、模型能力、repo mode 和权限，再允许 spawn。Harness 自己的包管理命令不能成为平台的发布权威。

模型 Provider 注册可用模型与能力；工具插件提供搜索、文件、命令等执行接口；Agent preset/loop 决定如何组装上下文、何时调用工具；Session 插件保存事件与投影；Web 插件把部分状态呈现出来。

这张图的价值在替换性。你可以更换模型 Provider 或 Agent Loop，而不重写全部宿主。但替换必须满足能力合同：上下文窗口、reasoning effort、工具支持、视觉输入等模型能力会影响同一 session 是否能继续恢复。

Lumi 的 Control Center 可以显示这张内部图的摘要：组件版本、来源、健康、声明能力和缺失依赖。它不应该把 Harness 内部 100 多个 rows 展平成 Lumi 的 Pack 或主导航，也不能从一个 active fiber 推断企业任务可用。

模型先看到工具 schema，再决定调用；运行时需要验证参数、权限和沙箱策略，然后执行子进程或外部 API，把结果转换回模型可理解的内容。任何一步都可能失败，且不同工具的副作用等级不同。

Agent tool sandbox 只约束被它启动的工具子进程，不自动约束 Cordis 宿主插件、MCP executable 或 npm install script。把“工具在 sandbox 中”显示成“整个 Runtime 完全隔离”，会给企业用户造成危险的安全错觉。

Lumi 的协议应该把 Capability、Permission 和 Enforcement 分开：能力说明能做什么，权限说明批准了什么，EnforcementReceipt 说明实际由哪个后端强制了哪些 effect class。

推荐路线是 Adapter + optional Runtime。Lumi 先创建 TaskRun，Adapter 完成 admission 并独占启动一个 Harness 进程，保存 ExecutionSessionRef 和事件证据；Harness 结束后，产物仍进入 Core Artifact 与 Acceptance。

如果让 Lumi 自己变成 Harness，Core IA 会被 session/plugin graph 取代，宿主权限爆炸半径增大，客户交付对象变得模糊，且平台会被一个快速变化的 prerelease 依赖闭包绑住。战略收益不足以覆盖这种重构风险。

可选 Runtime 路线保留了最重要的可逆性：今天可以使用 dsh，明天也可以接其他 Harness 或纯 CLI；业务数据、成果和验收不随 Runtime 消失。