📄 一句话概括
Agent Runtime 的四个特点(会话生灭/能力动态/权限收口/长会话热修)恰好一一对应 Cordis 的四件机制;实测两个平面各有一个 Cordis runner。
📝 本节和前面几节的关系
讲了一章机制,这一节回答为什么偏偏是 Cordis——把需求和机制摆到一张表上对齐。
一、四个特点对四件机制
- 会话频繁生灭 → 生命周期机制 + Fiber 账本:每次会话就是一次完整的装卸循环。
- 能力随任务动态变化 → 动态装卸 + Effect 声明: Creative 那种会话中途换工具(3.6)全靠它。
- 权限必须收口 → isolate / Coeffect:依赖显式、边界明确,管线(4.4)的关卡有据可依。
- 长会话需要热修 → HMR:不重启换实现。
不是 Cordis 碰巧能用,是需求逐条对上了机制。
二、实测:两个平面各一个 runner
配置里有两个 runner:
@deepseek-ai/dsh-cordis-host-runner——宿主平面用。@deepseek-ai/dsh-cordis-client-runner——会话平面用。
3.2 的两平面设计,在运行时层面就是这样落地的——进程一份的账本与会话一份的账本,各归各的 runner 管。
三、反过来想:别的方案差在哪
- 静态框架(编译期定死):会话生灭这种动态场景直接没辙。
- 事件总线(发布订阅):能通知变化,但没有生命周期账本——撤下全靠自觉。
- 手动管理:能跑,但【能撤下】【处境明确】这些硬要求全变成【希望开发者记得】。
Cordis 的差异点一句话:它把动态的代价机制化了——不指望谁都小心,指望账本不漏。
四、给学习者的定位建议
读到这里, Cordis 在全书的角色可以立起来:
- 第 3 章说的【无特权内核】,就是 Cordis 本体。
- 第 4 章的管线、规则插件,挂在 Cordis 的组合机制上。
- 第 6、7 章要讲的运行过程与 Runtime,跑在两个 runner 上。
它不是众多细节之一,是全书技术的承重墙。
五、动手 Demo:为什么 Cordis 特别适合 Agent Runtime
需求与机制逐条对齐,加双 runner 实测:
pairs = [
("会话频繁生灭", "生命周期 + Fiber 账本"),
("能力动态变化", "动态装卸 + Effect 声明"),
("权限必须收口", "isolate / Coeffect 显式依赖"),
("长会话需要热修", "HMR 不重启换插件"),
]
for a, b in pairs:
print(" %-12s -> %s" % (a, b))
print()
print(" 双 runner: host-runner(宿主) / client-runner(会话)")
实跑输出:
--------------------------------------------------------------------
为什么 Cordis 特别适合 Agent Runtime
--------------------------------------------------------------------
Agent Runtime 的四个特点,恰好一一对应 Cordis 的四件机制:
Agent Runtime 的特点 Cordis 的对应机制
-------------------------------------------------------
会话频繁地生灭 生命周期机制 + Fiber 账本
能力随任务动态变化 动态装卸 + Effect 声明边界
权限必须收口 isolate / Coeffect 让依赖显式
长会话需要热修 HMR 不重启换插件
-------------------------------------------------------
实测再补一条:配置里有两个 runner——
@deepseek-ai/dsh-cordis-host-runner 宿主平面用
@deepseek-ai/dsh-cordis-client-runner 会话平面用
**两个平面各有一个 Cordis runner**——3.2 的两平面设计,
在运行时层面就是这样落地的。
需求逐条对上机制——适配不是巧合,是设计目标。 双 runner 是 3.2 两平面在运行时层的落地——前后的伏笔在这里接上。 对比三种替代方案后更清楚:Cordis 把动态的代价机制化了。
30 秒实验
- 把四个【特点 → 机制】的对应关系复述一遍。
- 解释:为什么事件总线方案撑不住【能撤下】这条硬要求?
- 在配置树里找到两个 runner,确认它们各在哪个段落。
常见误区
- 错误:Cordis 是众多技术选型之一,换一个也行。——纠正:它是全书技术的承重墙——生命周期、组合、HMR 全在它上面。
- 错误:事件总线也能实现动态组合。——纠正:能通知变化,但没有生命周期账本——撤下靠自觉。
- 错误:两个 runner 是重复设计。——纠正:两个平面各管各的账——进程级与会话级本来就是两种寿命。
自测三问(点开对答案)
1. Agent Runtime 的哪四个特点正好对上 Cordis? —— 会话生灭、能力动态、权限收口、长会话热修。 2. 实测里两个 runner 分别服务哪个平面? —— host-runner 服务宿主平面、client-runner 服务会话平面——**3.2 两设计的运行时落地**。 3. Cordis 与替代方案的本质差异是什么? —— **把动态的代价机制化了**——靠账本不漏,不靠人人都小心。- ☐ 下一节(5.10 本章小结)
相关笔记
- 【一切皆插件】不等于没有内核 —— 无特权内核就是 Cordis
- Creative:让 Runtime 本身也成为可操作对象 —— 动态装卸的用户侧入口
- 动手实验:让依赖出现,消失,再回来 —— 机制的实测版
- 🐳 DeepSeek Harness · 索引