夜雨聆风拆解 opencode 源码 · 第二章 CLI 入口与启动流程 · 总结篇
如果你要设计一个 CLI 入口层，你会先做什么？
大部分人从框架选型开始：yargs 还是 commander.js？但 opencode 的第二章揭示了另一个顺序——技术栈选型先于框架选型。因为整个 CLI 层的形状，是由 Effect-ts 运行时决定的，不是由 yargs 决定的。
第二章拆了三个模块（effectCmd 桥接、InstanceStore 生命周期、bootstrap 就绪协议），但它们不是三个独立的设计决策，而是一条因果链上的三个节点：选择 Effect-ts 运行时 → 需要桥接 async/await 和 Effect 世界 → 桥接需要生命周期管理 → 生命周期管理的"就绪"部分自然形成了 bootstrap 的分层协议。
本文不重复三篇正文的技术细节——它们已经在 02-01 到 02-03 里了。本文做三件事：揭示这条因果链、提炼跨模块的设计权衡、定位第二章在整个 opencode 中的角色。
因果链：yargs → effectCmd → InstanceStore → bootstrap
起点：为什么选了 yargs
CLI 框架选型不是一次独立的技术评审——它受到了上游技术栈的约束。opencode 的 CLI 层有 22 条子命令，每条命令需要参数解析、类型推导、-- 分隔符支持。这些需求 yargs 和 commander.js 都能满足。
真正的决定因素是：谁对 Effect-ts 运行时友好。yargs 的 CommandModule 是一个纯对象接口，它只约束 {command, describe, builder, handler} 四个字段。纯对象意味着可以"包装"——即在不改变 yargs 框架代码的前提下，在 handler 外层包裹 Effect 运行时的初始化和释放逻辑。Commander.js 的 .command('sub').action(handler) 链式调用则更难插入中间层包装。
所以 yargs 不是因为"功能更强"被选中的，而是因为它的接口风格允许在外面套一层 effectCmd 而不侵入框架内部。这是一个细微但关键的差别：框架选型有时不是因为框架本身的优劣，而是因为它给"非框架代码"留了多少改造空间。
传导：effectCmd 的诞生意味着什么
effectCmd 的 27 行核心代码（packages/opencode/src/cli/effect-cmd.ts:69-96）做了三件事：创建 Effect 运行时、注入 InstanceContext、确保 dispose。这三件事之所以被封装到一个函数里，不是因为代码量（27 行不值得封装），而是因为这三件事必须同时发生、且只发生一次。
这条规则导致了一个下游设计约束：InstanceStore 必须提供 load() 和 dispose() 两个对称接口，而且 load() 必须是幂等的——同一个目录调用多次不会重复创建 InstanceContext。于是 instance-store.ts 内部维护了一个 Map<string, Entry> 缓存池，用 Deferred<InstanceContext> 实现"先到先 boot，后到等结果"的去重机制。
汇聚：bootstrap 就绪协议的成因
bootstrap.run（packages/opencode/src/project/bootstrap.ts:32-46）的三行代码不是设计者拍脑袋想出来的，而是被 InstanceStore 的接口设计倒逼出来的。
因为 InstanceStore.load() 必须返回一个 InstanceContext，而 InstanceContext 需要包含配置、插件、服务——所以 bootstrap 必须编排它们。因为编排的顺序有依赖（plugin 可以改 config），所以 config.get() 必须在 plugin.init() 之前。因为 6 个服务没有相互依赖，所以它们可以并发 init。
bootstrap.ts 只有 76 行——它本身不做任何初始化，而是协调 8 个 Service（Config、Format、LSP、Plugin、Project、ShareNext、Snapshot、Vcs）的组合。这种极简的编排层是因果链的终点：框架选型 → 桥接层 → 生命周期管理 → 就绪协议，每一个节点都是前一个节点的逻辑产物，而不是独立的设计选择。
两条跨模块的设计权衡
权衡一：桥接代码 vs 纯 async 方案
如果 opencode 选择纯 async/await 运行时，CLI 层可以去掉 effectCmd、AppRuntime.runPromise、Effect.provideService 三层桥接代码，每条命令的 handler 直接写 async (args) => { ... }。
opencode 没有这么做。代价是显性的：每调用一次 AppRuntime.runPromise 都要创建完整的 Effect 运行时环境。但收益是隐性的：20+ 条命令共享同一套 dispose 保障。手写 async handler 时，每条命令的 finally { dispose(ctx) } 是一个记忆负担——只要有一条命令忘了写，就在生产环境留下一个资源泄漏点。
所以这条权衡的精确表述是：用 27 行桥接代码（加上每命令一行 instance: true/false），换了 20+ 条命令 × 5 行模板 = 100+ 行潜在风险代码的消除。这不是代码量上的胜负（27 行 vs 100 行），而是风险集中化的胜利——所有 dispose 逻辑在一处，出错概率从 20 个点降到 1 个点。
权衡二：缓存粒度 vs 无状态 CLI
InstanceStore 选择了基于 Map<directory, Entry> 的缓存池。这意味着同一个目录第二次调用 load() 不需要重新 bootstrap，直接从 Deferred<InstanceContext> 中取结果。
替代方案是无状态 CLI：每次 load() 都重新构建一次 InstanceContext，用完就丢。无状态方案代码更少（不需要缓存 map、不需要去重逻辑），但有两个硬伤：第一，同一目录的并发 load() 可能需要并行 boot 两次（浪费）；第二，Server 模式下需要为每个入站请求独立 bootstrap 和 dispose，而缓存池允许跨请求共享同一个 InstanceContext。
opencode 的 Server 功能（opencode serve）是这条权衡的关键因素——如果只有 CLI 模式，无状态方案就够了。但 Server 模式下多个 HTTP 请求需要共享 InstanceContext，缓存池就成了必要条件。
第二章的全局定位
核心产出：不是配置，不是插件，是 InstanceRef
把第二章的三个模块串起来看，它们共同构建了一个核心产物：InstanceRef。它是一个 Effect 上下文中的服务标签，任何模块可以通过 yield* InstanceRef 拿到当前 InstanceContext 的引用。
这个设计意味着：opencode 的"上下文传播"不靠参数传递（每个函数都传 ctx），不靠全局变量（global.ctx），而是靠 Effect-ts 的依赖注入系统。第二章的正文章节已经展示了这条链上的每个环节：effectCmd 通过 Effect.provideService(InstanceRef, ctx) 注入，下游代码通过 yield* InstanceState.context 获取。
如果一定要用一句话概括第二章做了什么，那就是：把一条 process.argv 中的字符串，变成 Effect 上下文中的一个 InstanceRef。
被哪些后文章节消费
没有第二章的 InstanceContext，第三章的 VCS 不知道当前在哪个 git 仓库，第四章的 agent 不知道用什么配置，第五章的 session 不知道关联哪个项目，第六章的工具不知道读哪个目录的文件。
