昨天给一家客户交付一个 HR 数字员工，交付物出乎对方意料：不是安装包，不是镜像，是一个配置文件。
对方技术负责人盯着屏幕看了半天，问了一句：「就这？」
就这。准确说，是一份 cordis.patch.yml——声明启用哪些插件、禁用哪些、端口开在哪、模型配哪个。客户自己改了一份，重启，一个财务数字员工就起来了。代码一行没动。
这让我确信一件事：上一篇讲的「Harness 自由，Contract 稳定」有了它的工程落地——DSH（DeepSeek Harness）的 profile 机制。而这背后是一套更像操作系统哲学的架构选择：微内核。
一、进程级沙箱 = 用户态服务隔离
dsh --profile hr 启动的不是一个「配置不同」的 web，而是一个 完全不同的进程。它通过 Cordis 插件系统实现能力裁剪——40+ 个插件被禁用，只保留 HTTP API + LLM + Shell + dingtalk-hr-plugin。
这很像微内核架构：Cordis 核心只管插件生命周期、事件路由、依赖注入，所有业务能力（UI、tools、skills、subagents、code-runtime）都是独立加载的「用户态服务」。
我核过 DSH 的实现：内置组合包分三层——dsh-base（共享核心）、dsh-web-app（浏览器宿主与 Web 运行时）、dsh-headless（直接叠在 base 上、不含 web-app 的最小运行时）。每个 profile 是 $DSH_HOME/profiles/<name> 目录下的一个组合声明：哪些 bundle 按什么顺序叠加，哪些插件打补丁。组合树在空根之上逐层应用：
dsh web = base + web-app + 用户 cordis.patch.yml
dsh --profile hr = base + headless + hr 的 cordis.patch.yml
│
└─ 禁用 40+ 插件
只留 HTTP API + LLM + Shell
+ dingtalk-hr-plugin
# generated by hugo AI
这和微内核「内核空转、服务外挂」的思路是同一个。
二、同一套代码，两个世界
dsh web 和 dsh --profile hr 共享同一套代码库，但运行时是两套完全隔离的进程：
dsh web (:3080) 完整 Web UI，开发者调试用 → 像开发环境
dsh HR agent (:3081) 裁剪后的最小化进程 → 像生产环境
# generated by hugo AI
从开发到上线，中间没有「打包」或「部署」步骤——只是换了一个 profile。
这一点值得停下来想一想。传统软件的开发态和生产态是两种制品：本地跑一套，打包、过流水线、再部署成另一套。两套制品之间永远有漂移的空间。而 profile 机制下，开发和生产跑的是 同一个二进制、同一份代码，区别只在启动时加载哪些插件。漂移的空间在架构上被消灭了。
这种进程级隔离与能力裁剪，正是 To B 交付的底层保障。
三、To B 场景的架构优势
1. 高可靠性
进程级隔离意味着一个插件的崩溃不会影响核心。每个 agent 是独立进程，挂了就重启，不影响其他 agent。
这和数字员工生产复盘里那次「健康检查全绿、员工失联 16 分钟」的事故互为镜像：那次暴露的是「监控容器不等于监控工作」；而微内核架构在更底层保证，就算一个员工的「大脑」真的失联，它也只是自己挂掉，不会拖垮隔壁的同事。
2. 低成本长期运行
裁剪掉不需要的能力 = 减少内存占用 = 减少攻击面 = 减少出错的概率。
HR agent 不需要 subagents、不需要 workflow、不需要 code-runtime、不需要 web-search，这些都被裁剪了，运行中的资源消耗降到最低。数字员工是要 7×24 常驻的——一个跑一年的进程，每省一份能力就是省一份事故概率和一笔云账单。
3. 自主优化
DSH 的目标不是「挂了自动重启」，而是 「越用越好」。常驻守护进程持续分析每个 agent 的执行轨迹——调用链、工具使用频率、失败模式、耗时瓶颈——主动发现并落地优化：裁剪低频插件、合并冗余调用、调整 prompt 策略、重配资源配额。
优化结果以 profile/插件形式生效，天然继承微内核的隔离性：一个 agent 的优化不影响其他 agent，回滚也只是换回旧配置。故障不再是终点，而是优化的输入。（注：执行轨迹分析守护进程为当前架构的演进方向）
4. 定制化交付
不同客户（HR、财务、IT）只需要不同的 profile 配置文件，不需要改代码。To B 交付就是给客户一个 cordis.patch.yml。
这就是昨天那个交付现场的完整解释：我们交付的不是一个产品，是 一个岗位的配置。换岗位，换配置；换客户，换配置。代码是公共的，配置是私有的——这恰好是上一篇文章说的 Spec/Code 分离，在交付层面的样子。
四、微内核 vs 宏内核
| 宏内核（传统 Agent） | 微内核（DSH + Cordis） | |
|---|---|---|
| 能力组织 | 全部能力打包在一个进程 | 插件按需加载 |
| 故障影响 | 一个模块崩溃全挂 | 进程级隔离，互不影响 |
| 交付形态 | 越大越重的整体包 | 按 profile 裁剪 |
| 定制方式 | 改代码 | 换配置文件即可交付 |
操作系统四十年前的选择，在 Agent 时代重演了一遍：Linux 走宏内核赢了性能，QNX 走微内核赢了汽车和航天——凡是要长期、可靠、安全运行的地方，历史总是选微内核。数字员工要 7×24 常驻在企业生产环境里，这是同一个选择题。
五、一句话总结
DSH 把 Agent 从「一个全能的程序」变成了「一个可定制、可自我进化的最小化运行时」。
在生产场景，少即是多——裁掉的不只是功能，是风险。
你的数字员工跑在什么架构上？欢迎留言讨论。