Withnoidea

外观

拆解DSH的“一切皆插件”原则（下）

约 4104 字大约 14 分钟

AIHarness插件开发

2026-10-08

🤖 说明：本文为个人在学习 DeepSeek Harness 架构过程中的阶段性笔记与测验实录，由 AI 助教配合共同研讨、点对点纠偏与排版整理而成。

本篇导读：本文为 DeepSeek Harness（简称 DSH）架构体系学习的第四阶段沉淀（第 3 章下半部分）。在上一篇厘清 Preset、ScopeContext 与 Host/Agent Plane 分层治理的基础上，本篇聚焦于最具突破性的 Creative（创造模式 / 运行时自修改），解析让 Runtime 成为 Agent 操作对象的底层逻辑、信任边界（Trust Boundary）的防御原则，并深度剖析 Cordis 微内核 如何通过克制而稳定的状态机守护“一切皆插件”的系统一致性。

一、Creative：让 Runtime 本身成为可操作对象

Creative 预设在官方代码库中的目录名为 cordis/，产品交互侧称为“创造模式”。

在 Standard 提供的全量基线能力之上，Creative 赋予了 Agent 一种全新的特权：不仅能使用现存的能力，还可以在授权范围内观察和修改承载自己的 Runtime 本身。

1. 核心扩展能力矩阵

在 Standard 的基础上，Creative 注入了四大维度的关键能力：

  • Runtime 检查能力（Runtime Inspection）：Agent 可以动态探测当前环境中已加载的 Service、Plugin、Context 树以及各个组件的健康状态。
  • Cordis 核心元工具：提供 cordis_mount（动态挂载插件）和 cordis_unmount（动态卸载插件）等运行时干预接口。
  • 插件实验与动态生成：允许 Agent 编写临时 TypeScript 脚本，并在当前会话的运行时中即时执行装配。
  • Preset 创作指导（Preset Authoring Guidance）：注入专门的元提示词，指导 Agent 如何按照规范编写符合生命周期的标准 Preset 与 Plugin。

2. Runtime Self-Modification（运行时自修改）执行流

传统 Agent 只能在静态配置的工具箱内选择工具；而在 Creative 下，Agent 可以根据任务上下文动态拓展能力载体：

flowchart TD
    subgraph SelfMod["Creative: Runtime Self-Modification 流程"]
        direction TB
        Step1["第一步: 识别复杂未决任务"] --> Step2["第二步: 检查当前 Runtime 状态<br/>(Runtime Inspection)"]
        Step2 --> Step3["第三步: 生成临时 Plugin 代码<br/>(编写 TypeScript 扩展)"]
        Step3 --> Step4["第四步: 动态挂载 (cordis_mount)"]
        Step4 --> Step5["第五步: 当前 Session 获得新能力<br/>(装配新工具/服务/运行时行为)"]
        Step5 --> Step6["第六步: 执行业务并验证结果"]
        Step6 --> Step7["第七步: 动态卸载 (cordis_unmount)<br/>(级联回收资源与作用域)"]
    end

3. 自修改的本质与高危信任边界（Trust Boundary）

⚠️ 核心工程认知：
所谓的 Self-modification（自修改），绝不是让大模型修改自己的模型权重或神经网络参数（Weights），而是让承载 Agent 的软件运行时组合结构（Runtime Composition）成为可被操作的对象。

这种设计模糊了“运行 Agent”与“设计 Agent”的界限，但官方架构明确指出：

  • 自修改是一条信任边界（Trust Boundary），而不是一种安全沙箱。
  • cordis_mount 运行在特权进程中，模型生成的代码若包含死循环、内存泄漏或恶意操作，将直接拖垮整个 Host。
  • Creative 绝不是“安全的自我进化”，工程落地必须依赖外部强力的代码静态分析、权限审查、人机协同审批（Human-in-the-Loop）以及快照一键回滚机制。

二、4 套 Preset 的全景差异与“插件化”广度

回顾 DSH 的 4 套 Preset，任何一个 Agent 的最终表现，均是由 Host 共享基础设施、Runtime 核心规则 与 当前 Session 挂载的局部插件 动态叠加形成的：

graph TD
    subgraph PresetDiff["4 个 Preset 的核心架构差异"]
        direction TB
        subgraph P_Standard["Standard (标准预设)"]
            S_desc["完整 Agent Composition<br/>• 全量能力基线<br/>• 文件/Shell/检索/Subagent/Workflow"]
        end
        subgraph P_PTC["PTC (代码编排预设)"]
            T_desc["Standard + 切换 ToolPresentation<br/>• 保留 Standard 能力面<br/>• 呈现层改为 Code (TypeScript SDK)<br/>• 减少多轮往返 Round-trip 开销"]
        end
        subgraph P_Minimal["Minimal (极简预设)"]
            M_desc["大幅裁剪 Prompt / Tools / Context<br/>• 极薄 Persona 与 Context<br/>• 仅保留 Bash / str_replace_editor<br/>• 剔除辅助脚手架，专供学术 Benchmark"]
        end
        subgraph P_Creative["Creative (创造预设)"]
            C_desc["Standard + Runtime Self-reference<br/>• 加入 Runtime Inspection<br/>• 模型动态编写 mount / unmount<br/>• 运行时动态修改自身 Composition"]
        end
    end

“插件”概念的全面泛化

在 DSH 架构中，插件（Plugin）绝不仅仅是 Tool 的代名词：

  • Agent 人设（Persona） 是可插拔的；
  • 系统提示词切片（Prompt Sections） 是可插拔的；
  • 工具呈现形式（Tool Presentation: JSON vs Code） 是可插拔的；
  • 上下文压缩与清理策略（Context Strategy） 是可插拔的；
  • 底层执行与治理服务（Runtime Services） 同样是可插拔的。

三、“一切皆插件”背后的 Cordis 微内核底座

既然万物皆可插拔，系统如何保持长期的一致性与稳定性？答案在于其内嵌的 Cordis 微内核（Kernel）。

1. 微内核的绝对确定性职责

Cordis 内核坚决不碰具体的业务逻辑，它只专注维护插件世界的元规则：

  • 严格的状态机流转：管控插件从 UNLOADED、PENDING（依赖未满足挂起）、LOADING 到 ACTIVE（激活）及 DISPOSED（已注销）的完整状态机。
  • 声明式服务依赖发现：若某插件依赖底层基础 Service（如 PTC 依赖 codeRuntime），当底层未就绪时插件优雅停留在 PENDING，绝不会在执行期突发空指针崩溃。
  • 事件拦截与总线分发：统筹全局与局部的事件总线，支持中间件插桩与审批链拦截。
  • 级联资源清理：Session 结束或插件 unmount 时，内核负责安全释放文件描述符、事件监听与内存引用。

2. 微内核的设计哲学

内核越克制、越稳定，外围的插件与 Preset 组合就越自由、越健壮。

四、第 3 章 架构核心黄金法则总结

  1. Preset 的组合本质：Preset 决定了当前会话要组装哪些能力。依托局部 ScopeContext 挂载，既复用了 Host 单例设施，又杜绝了会话间污染。
  2. Host Plane 与 Agent Plane 的天条界限：模型看见什么属于 Agent Plane，底座怎么安全执行属于 Host Plane。
  3. Capability 与 Presentation 解耦：PTC 改变的是交互呈现与编排形式，而非底座能力本身。
  4. Minimal 模式的评测哲学：Minimal 故意把 Harness 压到极薄，用于控制变量以准确评测模型本身的原始智能。
  5. Creative 模式的防御红线：自修改是软件运行时的可塑性扩展，是高危的信任边界而非安全沙箱，必须依赖外层不可穿透的物理防护。

五、阶段架构测验与深度纠偏实录（第 4 阶段）

点击展开：第 4 阶段（第 3 章下）阶段架构测验与深度纠偏实录
  • 测验范围：拆解 DSH 的“一切皆插件”原则（下）（Creative 创造模式、Runtime Self-Modification 生命周期、Trust Boundary 信任边界 vs 安全沙箱、Cordis 微内核状态机与依赖治理）
  • 说明：包含学员作答及导师点对点纠偏、架构深度剖析。

【第 1 题：Creative 模式的本质与“自修改”的工程真相】

问题背景：
Creative 预设在产品层常被称为“创造模式”，支持 Agent 在运行期动态执行 cordis_mount 和 cordis_unmount。不少媒体或宣传将其吹捧为“Agent 能够自主进化与重塑自我”。

问题：

  1. 在 DSH 架构中，Creative 模式下的“Self-modification（自修改）”究竟是在修改什么？它与大语言模型本身的“自我修改”有何本质边界？
  2. 试述一个典型的 Runtime Self-Modification 闭环生命周期（从遇到任务到释放能力至少包含 5 个关键步骤）。

【我的回答】：

1.1

  • 自修改修改的对象：修改的是承载 Agent 的软件运行时组合结构（Runtime Composition），即当前 Session 所挂载的插件、工具集、动态提示词和运行时服务行为。
  • 与模型自修改的本质边界：它绝对不是在修改底层大模型的神经网络参数、权重或注意力机制（Weights/Tensors），模型本身的概率图和基座能力是不可变的。改变的是模型能够感知和操控的软件环境与外围脚手架。

1.2 完整的自修改生命周期闭环：

  1. 检测与识别：Agent 在执行某项特定复杂任务时，通过 Runtime Inspection 探测当前加载的插件和服务，发现缺少针对该任务的高阶工具。
  2. 代码生成：根据 Cordis 规范，编写一段临时的 TypeScript 插件脚本代码（定义新的 Tool / Service 逻辑）。
  3. 动态挂载：调用 cordis_mount 元工具，将生成的代码实时装配进当前 Session 的运行时作用域。
  4. 任务执行与校验：当前会话立即感知到新暴露的能力，Agent 调用新工具完成实际业务操作，并验证其执行结果。
  5. 动态卸载与资源回收：任务完成后，调用 cordis_unmount 卸载临时插件，内核级联释放占用的内存、上下文和临时句柄，保持 Runtime 干净。

【导师纠偏与深度解析】：

🎯 亮点评定：

  • 回答极其通透！清醒地划清了“软件工程意义上的插件热插拔”与“科幻意义上的神经网络权重自演化”的鸿沟，没有被噱头概念带偏。
  • 五步生命周期的概括非常规范，特别强调了最后的“动态卸载与清理”，具备工业级系统资源的严谨性。

💡 架构进阶视角（为什么需要元提示词 Preset Authoring Guidance）：

  • 模型并不是生来就知道如何编写符合 Cordis 微内核规范的 Plugin 的。Creative 模式之所以能跑通，核心就在于它向 Agent 注入了 Preset Authoring Guidance。
  • 这是一套高度结构化的元上下文，向模型清晰定义了 Plugin 的生命周期接口、Service 声明规则以及类型约束，本质是把“系统开发规范”编码为了 Agent 可以理解的行动准则。

【第 2 题：信任边界（Trust Boundary）vs 安全沙箱（Sandbox）】

问题背景：
官方在架构文档中郑重警示：“官方配置明确把自修改视为一条信任边界（Trust Boundary），而不是一种安全沙箱”。

问题：

  1. 为什么说 Creative 的自修改机制“不能作为安全沙箱”？如果任由 Agent 自由 mount 任意代码，在没有任何外力约束下，系统面临哪些毁灭性的工程与安全风险？
  2. 在工业级落地中，如果必须开放类似 Creative 的动态扩展能力，我们在架构外围必须构建哪些防御机制（至少列出 3 项）？

【我的回答】：

2.1

  • 为什么不是安全沙箱：
    因为沙箱的目标是“即使运行不受信任的代码，也能通过物理隔离防止其危害系统”；而 cordis_mount 运行在 Host/Runtime 相同的进程与特权上下文中，本质是让模型向宿主直接注入并执行可执行代码。
  • 系统面临的毁灭性风险：
    1. 进程级崩溃与内存泄漏：模型生成的插件若包含无限递归、未捕获的全局异常或内存死锁，会直接导致整个 DSH Host 进程崩溃退出。
    2. 权限越界与横向提权：动态注入的插件可能绕过 Agent 会话的局部作用域限制，直接访问或篡改底层共享的数据库、持久化连接乃至宿主机敏感环境变量。
    3. 不可逆的数据破坏：缺乏回滚机制的自修改可能覆写关键的核心注册表，导致系统陷入无法自愈的永久损坏状态。

2.2 外围必建的防御纵深机制：

  1. 代码静态分析与权限审查（AST / Linter & Permission Gate）：对模型生成的插件代码做 AST 语法与敏感 API 扫描，高危操作强制触发人类介入审批（Human-in-the-Loop）。
  2. 独立受限的代码沙盒执行（Isolate / Worker Sandbox）：将 cordis_mount 的执行环境剥离出主进程，放入独立的 Node.js VM/Worker 线程或轻量级 WASM 容器中隔离运行。
  3. 快照与一键回滚机制（Runtime Snapshot & Fallback）：在每次 mount 之前自动对当前 Runtime 的配置和上下文生成快照；一旦新插件运行出错或崩溃，内核能够一键原子化回滚至挂载前状态。

【导师纠偏与深度解析】：

🎯 亮点评定：

  • 满分分析！深刻理解了“代码注入”与“沙箱隔离”的对立关系。
  • 给出的防御纵深三件套（静态审查/人机审批、隔离执行容器、快照原子回滚）正是大型工业系统（如微服务网关热插拔、Plugin OS）的标准设计范式。

💡 安全工程哲学（防御不依赖模型的自觉性）：

  • 任何依赖“在 System Prompt 中叮嘱模型不要写恶意代码”的安全设计都是纸牌屋。越是给 Agent 赋予强特权（如 Creative），越必须把防御壁垒建立在代码执行引擎和操作系统层，把模型视为随时可能发疯但受到绝对物理束缚的执行单元。

【第 3 题：“一切皆插件”背后的 Cordis 微内核底座哲学】

问题背景：
原书指出：“‘一切皆插件’并不等于没有内核……更适合把它理解为一种类似微内核的设计思路”。

问题：

  1. 在 DSH 中，插件不仅限于 Tool，还包括哪些系统维度？
  2. Cordis Kernel 既然不负责具体的 Agent 业务逻辑，那它最核心的不可动摇的确定性职责是什么？为什么说“内核越克制，外围越自由”？

【我的回答】：

3.1 在 DSH 中，“插件化”的维度被拓展到了系统的方方面面：

  • Agent 角色设定（Persona）：如专家人设、风格设定。
  • 动态提示词（Prompt Sections）：不同阶段注入的系统规约与指导切片。
  • 工具呈现层（Tool Presentation）：Native JSON Calling 或 PTC TypeScript SDK 呈现方式。
  • 上下文治理（Context Strategy）：上下文压缩、滑动窗口清理策略。
  • 底层服务能力（Runtime Services）：如沙箱执行、持久化 Provider、代码运行时等。

3.2

  • Cordis Kernel 的确定性核心职责：
    内核不关心当前会话在干什么，它的职责是维护整个插件生命周期系统的运行规则与秩序，包括：
    1. 统一的状态机规范：管理插件从 PENDING 到 ACTIVE 再到 DISPOSED 的状态迁移。
    2. 依赖注入与服务发现：确保组件之间的依赖强校验（缺少基础 Service 时挂起等待，绝不崩溃）。
    3. 事件总线与生命周期清理：负责跨作用域通信、插件卸载时的资源级联释放与上下文隔离。
  • “内核越克制，外围越自由”的内涵：
    如果内核把 Standard、PTC 或特定提示词逻辑硬编码在自己体内，整个系统就会变成难以维护的单体巨石架构；当内核保持极简和中立，只定义最抽象的生命周期与通信规则时，上层的业务开发者和 Agent 才能毫无包袱地通过编写 Preset 组合出千万种形态各异的智能体。

【导师纠偏与深度解析】：

🎯 亮点评定：

  • 归纳得极其精辟！对 Cordis 状态机管理（特别是 PENDING 的优雅挂起）与解耦特性的阐述展现了极高的系统架构理解力。

💡 终极升华（从宏观视角贯穿第 3 章全貌）：

  • 第 3 章的整个脉络正是通过 Standard（全量基线）-> PTC（呈现解耦）-> Minimal（薄治理）-> Creative（自修改特权），层层递进地展现了 Cordis 微内核架构的弹性极限。
  • 真正的工业级 Agent 框架不是去定义一个万能的通用 Agent，而是提供一套能让能力按需编排、安全隔离、随用随销的工程底座。