【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
标题
206、【Agent】【OpenCode】TUI 内部：装配层与 context 工厂
背景
上篇 blog
【Agent】【OpenCode】TUI 内部：.tsx 与 .ts 的分界线
讲了 .tsx = TypeScript + JSX（编译器靠后缀决定 < 当标签还是泛型）；TUI 里 .tsx 属组件/渲染层（app、context 组件、component），.ts 属纯逻辑层（thread/worker/win32）；判据是"是否进组件树 "而非"是否写了 JSX"------sdk.tsx 几乎没 JSX 也是 .tsx，directory.ts 提供数据不渲染所以 .ts；TUI 用的是 Solid.js。205 从文件系统看出了"组件层/逻辑层"的分层，本篇再从架构看两个关键 .tsx 的分工：app.tsx 是装配层（组合根），sdk.tsx 是 context 工厂的产物------一个当主板，一个当网卡
OpenCode
app.tsx 和 sdk.tsx 都属于 .tsx 组件层（205 篇），但抽象层次完全不同：一个决定"整棵树怎么拼"，一个只是树里的"一块通信模块"。要理解这个分工，先看它们共用的地基------createSimpleContext 工厂。
🧩 地基：context 工厂 createSimpleContext
context/helper.tsx:3-25 定义了一个生成"上下文提供者"的工厂，TUI 里 12 个 context 文件都靠它：
它一次产出两样东西：provider （一个 Solid 组件，用 <ctx.Provider> 向下提供值，还带 ready 门控）和 use() （取值的钩子，没在 provider 内用就抛错）。context/ 下 exit/prompt/args/sdk/tui-config/sync/theme/kv/route/keybind/local 全都由这个工厂生成。
🧩 sdk.tsx：工厂的一个实例------通信模块
sdk.tsx:11 就是工厂的一次调用，生成 SDKProvider 与 useSDK：
ts
// sdk.tsx:11
export const { use: useSDK, provider: SDKProvider } = createSimpleContext({
name: "SDK",
init: (props) => { /* createOpencodeClient + 事件分发（204 篇已拆） */ },
})sdk.tsx 的职责很单一：造 SDK client、管事件流 （204 篇讲的 createSDK / internal-external 分支 / 16ms 合并 / setWorkspace 全在里面）。它对上游接收 transport，对下游通过 useSDK() 把 client/event/directory/url 交给18+ 个组件（session 页、permission、question、prompt 自动补全、各 dialog...）。
🧩 app.tsx：组合根------把 18 个模块装配成树
app.tsx 的角色完全相反：它不用工厂、不造模块 ，而是把 context 工厂产出的所有 provider 按依赖顺序层层嵌套，组装成整棵树（app.tsx:138-161）：
tsx
render(
() => (
<ErrorBoundary fallback={...}>
<ArgsProvider {...input.args}>
<ExitProvider onExit={onExit}>
<KVProvider>
<ToastProvider>
<RouteProvider>
<TuiConfigProvider config={input.config}>
<SDKProvider url={...} directory={...} fetch={...} events={...}>
<SyncProvider>
<ThemeProvider mode={mode}>
...
<PromptRefProvider>
<App />
每一层"包"都对应 context 工厂的一个实例；<App /> 在最内层，真正渲染页面。而 tui()（app.tsx:107）是这棵树的入口------thread.ts 把 transport 交给它，它负责把 transport 分发给对应的 provider（SDKProvider 拿 url/fetch/events、TuiConfigProvider 拿 config）。
🔄 数据流向：一个接上游，一个供下游
thread.ts（启动链路）
│ transport: url / fetch / events / directory / config
▼
app.tsx tui() ← 接住上游，做装配（组合根）
│ 把 transport 喂给各 provider
▼
SDKProvider（sdk.tsx 的工厂产物）
│ createOpencodeClient 造出 client
▼
18+ 组件 useSDK() ← 从下游取 client / event（通信闸口）方向完全相反：app.tsx 向上接 thread.ts（入口/装配），sdk.tsx 向下供组件取数据（闸口/通信）。
📊 对比总结
| 维度 | app.tsx | sdk.tsx |
|---|---|---|
| 角色 | 组合根 / 装配层 | context 工厂的单个实例 |
| 职责 | 18 层 provider 嵌套 + <App /> |
造 SDK client + 管事件流 |
| 生成方式 | 手写 tui() + JSX 树 |
createSimpleContext 工厂 |
| 对上游 | 接 thread.ts 的 transport（入口） | 收 app 分发的 transport |
| 对下游 | 无（只管装配） | useSDK() 供 18+ 组件取 client |
| 类比 | 主板 | 通信网卡 |
📌 一句话记忆
helper.tsx的createSimpleContext是 context 工厂（TUI 12 个 context 都由它生成 provider/use）；sdk.tsx是它的一个实例------只管通信，useSDK()供 18+ 组件取 client；app.tsx是组合根------不造模块，只把 18 层 provider 按依赖顺序嵌套成树，向上接住 thread.ts 的 transport。一个是主板，一个是网卡。
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog