KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

03 · 场景选型：什么场景该用哪一类 — keel 龙骨

对比是手段，选型是目的。本章先给一张决策表，再对五个高频场景逐一展开「选哪类 + 为什么 + 代价」，再补三个不好归类的边界情形，最后收一份「从五家能抄走的 10 个设计」——无论你最终用哪家、自己写哪一种，这十件事都值得搬走。五家中四家的结论有解析课的源码级证据；E 平台 为定性对比、无公开源码级证据，涉及处逐条标注。

对比是手段，选型是目的。本章先给一张决策表，再对五个高频场景逐一展开「选哪类 + 为什么 + 代价」，再补三个不好归类的边界情形，最后收一份「从五家能抄走的 10 个设计」——无论你最终用哪家、自己写哪一种，这十件事都值得搬走。五家中四家的结论有解析课的源码级证据；E 平台 为定性对比、无公开源码级证据，涉及处逐条标注。

一、选型决策表

决策表只回答「形态」，不回答「产品」：同一形态下的具体项目各有成熟度差异，且本课的事实核对基于特定版本（Claude Code 2.1.88、dsh 0.1.7-rc.1、Hermes 0.20.4、OpenClaw 2026.8.1）。

读表的顺序是先看「一票否决项」再看「首选」：形态错配很少在第一天暴露（单进程也能跑渠道 webhook），但否决项命中后迁移成本远高于一开始选对。另外五个场景之间存在演化路径——个人编码助手用顺手后接上渠道就变成常驻助理，此时该换形态而不是给原形态打补丁；每个场景末尾的「切换形态的信号」就是给这条演化路径用的。

表中没有列出的第三维是运行环境约束，它经常一票否决掉形态本身：只有 Windows 的机器上，dsh 的沙箱后端是 windows-acl 且自认 partial enforcement（硬链接与读操作管不住），对安全要求高的场景等于没有沙箱；强离线环境里，E 平台 的队列与 Stream 栈、以及任何依赖云 provider 的形态都要重估；容器编排能力为零的小团队，Hermes 的 s6 监督树与 E 平台 的 worker 池都是隐性运维门槛。形态选择永远在「场景 × 环境」的交集里做。

二、个人编码助手（单机、单 operator、以编辑器/终端为中心）

选单进程交互式 CLI，参考 Claude Code。
为什么：编码任务的第一公民是「等模型」和「等工具 IO」，不是本地 CPU——单进程没有 IPC 序列化开销，ToolUseContext 40+ 字段直接共享引用，取消一个运行只需 abortController.abort()。显式 State + 10 终止 reason 让「这一轮为什么失败」永远可答，这对每天发生几十次的交互至关重要。三级工具结果预算保证「模型一口气发 10 个并行 grep」不会打爆上下文。

代价：一个工具崩溃可以带走整个会话；无多渠道——想在手机上继续对话就要换形态。此外它的扩展面刻意最小（无运行时插件总线），深度定制要走 MCP 与 hooks，而不是改内核。还有一条隐性成本：会话 JSONL 会无界增长（单文件可达数 GB），长期重度使用要自己安排归档。

什么时候考虑 dsh：如果你需要换沙箱实现（本地/容器/远程）而不动工具定义，「契约包 + 实现包」的接缝设计比 Claude Code 的编译期裁剪灵活；PTC 模式把 N 个工具折叠成一个 run_code，长工具目录下能省大量 token 与工具选择错误。

切换形态的信号：你开始在终端之外想用这个助手（手机上问进度、群里派任务）——单进程交互式的边界到了，该看场景三；你发现会话必须跨设备续跑且不能丢一行——append-only 事件流的恢复语义开始变得重要，该看 dsh 或 OpenClaw。

三、常驻个人助理（单 operator、多设备、随时在线）

选单例本地控制平面，参考 OpenClaw。
为什么：「一个 operator 一个控制面」被写进了文件系统语义——文件锁 + 端口 + uid 后缀锁目录保证状态有唯一属主，崩溃熔断防止「启动即崩」把渠道账号打成风控。20+ 渠道收敛成统一 inbound envelope，路由 binding → agent，配对（pairing）作为 DM 的前置守卫——这些都是「个人的」三个字在渠道层的落实：任何人私聊不等于能指挥它。五层记忆 + dreaming 让助理跨会话记住你，48h 超时 + 循环检测支撑长任务不被腰斩。

代价：多用户只做归因不做隔离——群聊共享同一 transcript，互不信任的人放进一个群是产品边界之外的场景；横向扩展只能「拆 Gateway」；同会话吞吐被 per-session lane 钉死为 1。记忆与上下文引擎都是单槽位，想组合多种记忆实现只能在一个插件内部编排。

什么时候考虑 Hermes：它的 gateway 宿主 + 22 渠道插件覆盖更广（telegram/discord/feishu/dingtalk/wecom 等），且 s6 监督树让 gateway 与 dashboard 独立重启。但它的安全姿态是「唯一边界是操作系统」——作为常驻助理运行时，你必须自己提供 OS 级隔离（容器/整进程包裹），否则进程内的审批门只防事故不防对手。

切换形态的信号：助理开始处理别人的请求（家人、同事、客户）——归因模型的隔离上限到了；你想要「多个人各自独立的记忆与会话」——单例 Gateway 的进程内分区做不到，要么拆 Gateway 要么换多租户形态。

四、多渠道客服与运营（多接入源、内容不可信、要审计）

选插件化多渠道网关，参考 Hermes。
为什么：客服场景的渠道是运营变量——这个月接 feishu、下个月接 wecom，渠道必须是插件而非内核代码。Hermes 的 plugin.yaml 数据驱动配置（requires_env 带 prompt/url/password，配置向导自动生成）让新增渠道接近零代码；命令单一来源扇出到 CLI 与所有渠道，避免「CLI 有 / 渠道没有」的漂移。更关键的是 webhook 收窄清单（_HERMES_WEBHOOK_SAFE_TOOLS）：来自不可信第三方的事件默认只给 4 个只读工具，防 prompt injection 触发本地执行——这正是客服内容的特点。

代价：「有哪些能力可用」静态阅读看不出来，必须跑一次发现流程（CLI 启动为此付出 500–650ms）；审批三模式在无人值守的 cron/webhook 场景必须 fail closed，YOLO 之外的中间态运维成本高；进程内防护不是安全边界，高对抗环境仍需终端后端隔离。

OpenClaw 的备选价值：bundled 渠道同样 20+ 且有 Ed25519 阈值签名的插件目录，但它的单 operator 假设使「多个客服共享一个实例」天然别扭——归因不是隔离。

切换形态的信号：客服开始需要「同一渠道上多个租户各自的机器人」——插件化网关没有租户模型，该看场景五；审计要求从「有日志」升级到「合规留存与权限分离的审计库」——Hermes 的会话库是运营存储不是审计存储，该看 E 平台 的租户隔离或自建审计层。

五、平台化企业部署（多租户、SLA、审计合规）

选 HTTP/执行彻底解耦的多租户平台形态，参考 E 平台（定性对比，无公开源码级证据）。
为什么：企业部署的第一道题不是 agent 循环怎么写，而是「一次 HTTP 请求的生命周期与一次 agent 运行的生命周期解绑」。E 平台 的答案是把 HTTP 落 ARQ 队列、由 worker 执行、事件写 Redis Stream：worker 崩溃重启不丢运行、客户端断线按 offset 续传、协作式取消（stop_triggered → RunCancelledEvent）不需要杀 HTTP 连接。多租户 workspace scope 让工具可见性、记忆、事件流按租户隔离。四家解析课里没有任何一家原生提供这档——Claude Code 单进程无租户概念，OpenClaw 明确「多用户是归因不是隔离」。

代价：定性对比看不到沙箱与工具执行的源码级实现，企业采购/自研前必须补安全评估；队列化引入延迟底线（HTTP 即刻返回的是受理不是结果）；运维面包含 Redis、ARQ worker 池、多租户数据隔离三层基础设施。

dsh 的备选价值：api/ 九包的 HTTP/JSON 控制器 + agent-preset-registry 按会话选 preset + append-only 事件流的天然审计性，是自建平台最值得借鉴的内核形状；但它同样没有租户模型，隔离要自己在外层做。

切换形态的信号：反向信号同样值得记——如果团队只有几个内部用户、没有 SLA 压力，直接上队列化平台是过度设计，OpenClaw 或 Hermes 的单实例运维面小一个数量级；等否决项出现（内存上限、无租户隔离、无 SLA 观测）再升级不迟。

六、需要 self-improving 的长期任务（运行数周、任务形态会演化）

选带自改进闭环的常驻 agent，参考 Hermes。
为什么：五家里唯一有完整闭环的是 Hermes——模型在对话中直接调 skill_manage 创建技能；每轮结束后台 fork 复盘（白名单仅 memory + skill，预算 16 轮，命中同一份 prompt cache 所以全量重放便宜）；curator 定期治理，两条不变量（只动 agent 自建技能、只 archive 不 delete）保证 AI 自治不可能造成不可逆损失。OpenClaw 的五层记忆 + DREAMS.md dreaming 是弱一档的替代——有沉淀、无「技能被模型主动改写」的闭环。

代价：复盘 prompt 鼓励「大多数会话至少产出一条更新」，低价值技能是系统性的，必须接受 curator 的持续治理；闭环意味着 AI 在写你自己要长期执行的代码（技能），skills_guard 扫描与 OS 级隔离从「建议」变成「前提」；遥测、账本、归档恢复三套 sidecar 都是运维面。

如果不接受 AI 自治写入：退化到 Claude Code 的「人工维护记忆文件」或 OpenClaw 的「记忆插件单槽位」——两者都有沉淀、无自主改写。

切换形态的信号：任务的形态开始随时间漂移（新工具、新流程每周出现）而你的迭代节奏跟不上——这正是闭环要解决的问题；反之，任务高度固定，闭环产出的大多数技能会被 curator 归档，成本大于收益。

七、从五家能抄走的 10 个设计

十个设计按「可移植性」排列前后的隐含顺序：1、2、4、7、8 是纯机制（常量、默认值、错误码、冻结点、阈值），任何语言一周内可落地；3、5 是架构决策（事件流、接缝），必须在项目早期定型；6、9、10 是产品与运维形态（自治闭环、边界纪律、队列解耦），改起来最贵。如果你只来得及抄一个，抄第 2 条——它最小，也最能在事故里还债。

1. 三级工具结果预算 + 落盘预览（Claude Code）：单工具 50K / token 100K / 单消息聚合 200K，超限落盘回喂 2000 字节预览。任何 harness 都该有「任何一轮工具输出总量有上界」这条不变量。落地要点：预算检查放在消息组装层而不是各工具内部，否则新增工具必然漏防。
2. 保守的工具默认值（Claude Code）：isConcurrencySafe 默认 false、isReadOnly 默认 false——「忘记声明」的结果永远是更安全、更慢，而不是更快更危险。落地要点：默认值与工具注册入口放在同一层（Claude Code 的 buildTool），让声明者绕不过默认值。
3. append-only 事件流 + 投影层（dsh）：日志是唯一真相、消息历史是派生结果。一次投入同时解决审计、fork/resume/replay、压缩不改历史三件事。落地要点：先定事件 schema 与兼容标记（dsh 的 ignorable），投影层可以后补。
4. abort 时补合成工具结果（dsh）：用户取消要伪造、调度器故障不伪造——replay 合法性优先于日志「诚实」。落地要点：合成结果必须带专用错误码，且与真实失败的文案区分。
5. 能力接缝「契约包 + 实现包」（dsh）：换沙箱/存储/子代理实现不动工具定义与提示词。自建系统的每一处 if (platform) 都是一个未拆的接缝。落地要点：接缝接口先定错误语义（dsh 的 ConfinedArgv 携带 enforcement 与拒绝方言），实现可以慢慢补。
6. 后台复盘 fork + curator 只 archive 不 delete（Hermes）：自改进的安全阀不是「产出高质量」，而是「下游有恢复手段 + 治理层只做可逆操作」。落地要点：fork 的工具白名单与主循环隔离，治理层的状态机里必须有「复活」路径。
7. hardline 命令永不可绕 + YOLO 导入期冻结（Hermes）：危险操作的拦截与「免打扰模式」正交；授权语义在运行期内冻结，不被环境变量热改。落地要点：冻结时机选在进程启动点，且冻结后的配置读取要走同一份快照。
8. 循环检测替代 maxTurns（OpenClaw）：六个检测器 + 两级判级 + 二次命中终止。长任务系统里，「卡住」必须做成可判定、可归因的问题。落地要点：检测阈值与准入路径共用同一个常量，不给策略覆盖留口子。
9. bundled 插件守第三方边界（OpenClaw）：内置能力也走公开 SDK seam、禁止深导入核心。这是防止扩展 API 因「自己人要用」而腐化的唯一可持续手段。落地要点：CI 里加一条「bundled 目录不许 import 核心 internals」的静态检查，靠约定守不住。
10. HTTP 与执行解耦 + 事件流 offset 续播（E 平台，定性）：把「受理请求」与「执行运行」拆到队列两端，用可续播的事件流面对客户端断线。凡是要过长连接与移动端的产品，这一课都逃不掉。落地要点：取消必须做成协作式事件（E 平台 的 stop_triggered → RunCancelledEvent），杀连接不等于取消运行。

三个情形的共同点是「决策表的行覆盖不了它们」，处理思路也都是从五家现成机制里拼装，而不是发明新机制。

八、三个不好归类的边界情形

无人值守的 CI/自动化里的 agent。 没有人在终端前，交互式 CLI 的审批链全部失效。落点是「无人值守原则」：dsh 托管外部 agent 时把交互回调全部换成确定性拒绝（canUseTool 一律 deny、默认权限压到 dontAsk），Hermes 的 cron/webhook 场景无人可问时必须 fail closed。共性结论是：无人值守时权限默认值必须比有人在场时更紧，而不是更松。

同机多实例与团队共享。 OpenClaw 的锁目录带 uid 后缀——不同用户各持自己的 Gateway 没问题，同一用户想跑两个就要显式换状态目录。团队共享的最低成本形态是「每人一个单例实例 + 共享的技能/配置仓库」，而不是改造成多用户系统——改造成本见场景四、五的代价栏。

长任务与交互式任务混跑。 OpenClaw 的 per-session lane 保证同会话串行，靠插话（steering）实现「立刻响应」；Hermes 用 redirect drain 把用户中途纠正并入本轮。两者共同说明：混跑的正确解法是「会话内排队 + 插话注入」，而不是并行跑两个循环写同一份 transcript。

代码地图

关键取舍

选型首先要对齐「进程模型」而不是功能清单。
五个场景的首选差异全部落在第一槽位：单进程交互（Claude Code）、单例常驻（OpenClaw）、多宿主网关（Hermes）、队列化平台（E 平台）。功能可以后补，进程模型几乎不可重构——从 OpenClaw 拆出多租户、给 Claude Code 加渠道层，工作量都远大于换一个产品。

「代价」栏比「为什么」栏更有信息量。
每个场景列出的代价都是该形态的结构性成本，不会随版本迭代消失（单进程崩溃域、单例吞吐上限、插件发现的启动开销、队列化的延迟底线）。选型时假设这些代价一定会落在你的场景上。

self-improving 是唯一「能力与风险同源」的选项。
闭环的产出（AI 写的技能）同时是效率来源与攻击面——Hermes 用扫描、白名单、curator 不变量与 OS 隔离四层把它兜住，但兜底成本是持续性的。不接受这个成本就选「沉淀但不自治」的形态，不要试图只要一半。

「抄设计」比「抄实现」便宜得多。
十个设计里没有一个依赖特定语言或框架：三级预算是常量 + 一个替换函数，事件流投影是 fold + 缓存代数，配对守卫是一条入站前置检查。自建 harness 时按此清单逐项自查，比对照任何一家源码起步都快。

运行环境是决策表之外的一票否决维度。
Windows-only、强离线、零运维三种约束各能毙掉一个形态（dsh 沙箱 partial、E 平台 全栈云原生、Hermes/E 平台 的监督树与 worker 池）。环境约束比场景需求更硬——需求可以妥协，环境不能。

五个场景不是互斥的目录，而是同一条演化链上的站点。
个人编码助手 → 常驻助理 → 多渠道网关 → 平台化部署，每一步的触发信号都是「上一形态的一票否决项出现」；self-improving 则是正交轴，任何形态都可能长出这个需求。用这条链做容量规划，比按功能列表堆需求更能预判重构点。

自测题

1. 决策表把「多渠道客服」的首选给了 Hermes 而不是渠道同样多的 OpenClaw。请从「单 operator 假设」与「归因不是隔离」两条证据出发，重构这个判断的完整链条。
2. 场景二说 dsh 的 PTC 模式「长工具目录下省 token」。请给出一个具体的工具数量阈值估计（推断），并说明 PTC 的代价（模型要理解生成的类型文本、失败走 ToolCallError）在什么工具规模下开始得不偿失。
3. 场景五里 dsh 被列为平台化的备选。请指出从 dsh 到真正的多租户平台，缺的至少三层能力是什么，以及其中哪一层可以借 E 平台 的队列化思路补上（定性）。
4. 「从五家能抄走的 10 个设计」里，哪几个在你自己的项目里可以一个下午落地？请挑三个并写出各自的落地顺序约束（例如「保守默认值」必须在「工具并发」之前定）。
5. 假设你的场景是「两三个互相信任的同事共享一个助理」。请论证 OpenClaw 的归因模型够不够用（提示：配对、sender allowlist、binding 拆 agent 三件工具的组合），以及什么时候会越过边界需要拆 Gateway。

进入 keel 阅读