Datawhale DeepSeek Harness 技术入门与架构原理 笔记4
Task4 合并版：拆解 DSH 的"一切皆插件"原则（下）
作业 A：概念地图
以 Harness 为中心，覆盖 11 个必含术语（Preset、Scope、Host Plane、Agent Plane、Tool Registry、Model Route、Tool Presentation、Cordis Kernel、Session、Trace、Composition），并标注 R1--R8 依赖/从属关系。所有标注均给出 Task2--4 的实测依据。
作业 B：短文《我理解的"一切皆插件"》
想象开连锁奶茶店：有的店卖全套饮品，有的店只做外卖打包，有的店是试新品的迷你档口。要是每家店都从头建一套厨房，光装修就得来好几遍。
做 AI 产品（Agent）也一样：写代码、批量处理数据、极简测试、让用户自己改 ------ 每种用法要的工具、提示词、规则都不一样。如果每种用法都单独造一套系统，就要同时维护 N 套 "长得差不多但又不完全一样" 的软件，又累又容易乱。
所以 DSH 的做法是：把 "不变的东西" 和 "会变的东西" 分开。
- 不变：模型怎么接入、沙箱怎么隔离、运行记录怎么存 ------ 这些是地基，必须稳定。
- 会变：工具清单、工具怎么呈现、上下文怎么处理、作用域（这个会话能用什么）------ 这些跟着需求走。
一个 Agent 最后表现成什么样 = 地基能力 + 底层规则 + 菜单（Preset 挂载）三层相加。同一套地基，换一张菜单，就能配出四种形态 ------ 我们实测模型能看到的工具数：standard 26 个、ptc 1 个（run_code，一个 "跑代码" 的入口）、minimal 1 个（pwsh，一个命令行工具）、cordis 34 个。做产品从 "改代码" 变成了 "改配置声明"，成本一下子降下来。
有人会问：既然什么都是插件，系统不是散架了吗？不会 ------ 因为有一层不属于任何菜单的规则把 "怎么组合" 定死了（教材 3.8）：
- 插件怎么装上去、怎么拆下来（挂载 / 卸载）；
- 新插件怎么找到它依赖的旧插件（能力发现与依赖）；
- 插件之间怎么传话（事件传递）；
- 插件退出时怎么把资源收拾干净（资源清理）。
这四件事就是 "内核"（Cordis Kernel）的职责。就像乐高的凸点：它不决定拼什么造型，但没有它，任何造型都拼不稳。
实验也印证了：在 "创造模式" 会话里用 cordis_inspect_query 检查运行时，发现 193 条配置项和各种服务的状态，换哪张菜单都一样 ；代码注释还写着：会话的预设树是程序跑起来之后才创建的，不在装载器（Loader）的管辖里。菜单是营业时才定的，承重墙是建楼时就定死的------ 内核比菜单更底层、更稳定。
这和"多注册几个工具" 是不同的，后者只是往仓库里多放几件东西；而 "一切皆插件" 改的是整个使用体验的每一个环节：角色提示词（persona）、工具怎么呈现（tool-presentation）、上下文策略（compaction）、怎么组织执行（subagent /workflow），连网页界面上的每个面板都是插件。
最有力的证据来自 Task 3：PTC 模式没有增删任何真实能力，只把 "工具呈现方式" 换了个开关，模型看到的工具就从 26 个变成 1 个 run_code------仓库（Tool Registry）纹丝没动，能力照样能用。
所以组合的最小单位从来不是 "工具"，而是 "切面"（体验的某个环节）。多注册几个工具，只是所有切面里最简单、最不用动脑的一种。正确的理解是：内核只留稳定的机制，具体能力全部交给插件和菜单去组合。
总结：① 做产品从改代码变改菜单；② 菜单营业时才定，承重墙建楼时就定死；③ 改的是体验的每个环节，不是多放几件工具。
实验记录（rc.2 实测）
实验 1：Runtime Inspection（创造模式的"观察"实证）
- 实验条件：在创造模式（cordis 预设）下，仅执行查询、不修改系统；
- 核心实测数据：一共查到 193 条 Config 配置项，包含两套插件清单；
- 核心论点："禁用"≠"不可用"；27 条被禁用项里，23 条只是把能力交给会话预设动态挂载，并没有彻底关闭功能。
实验 2：动态挂载实证（否定性结果，价值更大）
尝试下达指令：用cordis_mount装上临时工具echo_greeting，调用测试完成后再把它卸载。
Agent 做了三轮只读检查，全程没有改动系统：
- 当前这个创造模式会话一共 34 个可用工具，里面找不到
cordis_mount，也没有cordis_define、cordis_run、cordis_stop、cordis_undefine这些增删插件的工具。 - 在系统已安装的官方软件包内检索
cordis_mount，没有找到匹配内容。 - 查看
cordis_inspect_query的功能说明，它明确规定：不能调用业务服务、不能修改运行时环境。
事实真相：这套版本本身自带动态插件机制，依靠cordis_define + cordis_run / cordis_stop / cordis_undefine实现，由dsh-cordis-host-runner提供底层支持，也叫 "模型挂载双半包"。但是 rc.2 的网页端创造模式预设，只给模型开放了查看信息的只读工具，没有开放修改系统的入口。
得出结论：教材 3.6 写cordis_mount可以在运行时挂载、卸载插件，但 rc.2 实际版本只开放 "观察" 功能，不允许修改系统。这是我们发现的第二处版本差异（第一处是 Task3：教材写mode:code，实际是mode:ptc），两处变化趋势相同：rc.2 把创造模式的权限限制，设置得比教材描述更严格。Agent 没有编造虚假的执行结果，如实告知本次实验无法完成；这件事本身，也证明 Agent 的输出是可信的。
作业 C：学习目标对照 + 自测作答
学习目标 5 条逐条对照
| # | 课程页学习目标 | 自评 | 依据 |
|---|---|---|---|
| 1 | Creative 的"创造" = Agent 在授权范围内观察、修改 Runtime 本身 | 达成（含修正） | exp1 实证"观察"；exp2 修正：rc.2 未开放"修改"入口 |
| 2 | Creative 为什么是高信任能力、风险边界在哪 | 达成 | 教材 3.6"信任边界而非安全沙箱"；inspect 工具描述自带只读红线 |
| 3 | 用 4 套 Preset 反证"一切皆插件" | 达成 | Task2/3 数据 + B 短文第三节 + 自测第 4 题 |
| 4 | "一切皆插件" ≠ 没有内核（Kernel 四职责） | 达成 | B 短文第二节 + exp1 旁证 |
| 5 | 前 3 章综合输出，为第 4 章写 Skill/Tool/Hook 做准备 | 部分达成 | 已梳理插件声明结构；动手写插件留待第 4 章 |
自测 4 题作答
Q1：cordis_mount 做了什么？为什么说 Creative 让 Runtime 本身成为可操作对象？
教材 3.6 里写：cordis_mount 可以运行 AI 写出的 TypeScript 代码，在**正在工作的 Runtime（运行环境）**里安装、卸载插件。也就是说，Agent 不光能调用工具，还能改动承载它自身的插件组合。
但我们在 rc.2 版本实测后发现：这个版本里根本没有cordis_mount这个工具名，全盘检索都找不到。真正用来动态增删插件的是cordis_define + cordis_run/stop/undefine这套接口，由 host-runner 提供底层支持，叫做动态双半包。
而且网页端的创造模式预设，只开放了只读查询工具cordis_inspect_*。
"Runtime 能被操作" 这句话的真正含义：插件组合不再是出厂就固定死的配置，而是 Agent 在会话里可以处理的工作内容。rc.2 底层已经做好了修改的底层机制，但只开放读取权限，修改的入口没有对外开放。
Q2：Cordis Kernel 负责哪些"不属于任何 Preset"的规则？
教材 3.8 把底层规则分成四条核心机制：①插件的安装与卸载；②插件能力怎么被发现、互相依赖；③消息事件怎么在插件之间传递；④插件停止运行时，如何自动清理占用的资源。
这四条是运行环境（Runtime）的底层基础规则。四种预设配置都不会改写这套规则，只会直接调用使用它。正是因为内核规则固定不变，插件才能自由增减、启停替换，整个系统始终稳定不乱。
我们的实验也印证了这一点：在四种不同预设下，巡检查到的配置状态、服务列表完全一致。而且会话里的预设组合，是程序运行之后临时生成的，不在系统初始加载目录之内。这足以说明：内核（Kernel）是更深层、更稳定的底层，预设只是上层可变的配置。
Q3："DSH 就是微内核操作系统"的类比哪里对、哪里不对？
这个设计思路和微内核很像：内核只保留最核心的极简规则，具体功能全部做成插件，按需搭配使用。二者都认同：稳定的交互规则，远比堆很多功能更重要。
但二者不能直接划等号，有三处关键差别：
- DSH 不是计算机操作系统，它不管理硬件，没有进程、内存、硬件驱动这类底层硬件管理能力。
- 插件的有效期跟着单次对话（会话）走：每套预设在对话创建时加载好，之后就固定不变。不像操作系统服务，启动后就一直常驻后台。
- 教材本身也特意说明：它不是传统操作系统那种微内核，只是设计思路相近。
所以可以拿来类比方便理解，但不能认为它们完全是一回事。
Q4：Task 2 观察到的 4 套 Preset 差异，现在能用 Task 3/4 概念解释吗？
| Preset | Task2 实测 | Task3/4 解释 |
|---|---|---|
| standard | 26 工具、5958 字符系统提示词 | 完整 Agent composition：Agent Plane 的默认切面 |
| ptc | 1 工具 run_code、28.9KB 系统 JSON | 同一 Tool Registry + Tool Presentation(mode=ptc)：呈现分离，能力不增不减 |
| minimal | 1 工具 pwsh、46 字符提示词、技能零注入 | Preset 决定"组合哪些"，也能决定"几乎不组合"（Scope 裁到最小） |
| cordis | 34 工具（Task4 重测） | 在 standard 之上多挂 Runtime 自观察插件；Creative 的差异是"多挂哪类插件"，不是新物种 |
一句话总结：四套 Preset = 同一个 Kernel、同一个 Tool Registry 上的四个 Composition 切面（图 3-8）。