【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
标题
204、【Agent】【OpenCode】TUI 内部：SDK 客户端与事件流
背景
上篇 blog
【Agent】【OpenCode】JS 语法：作用域链与 var 循环陷阱
收束了 JS 语法系列：闭包能访问什么看定义位置（自身 → 外层函数 → 全局），捕获的是可变环境而非值快照；var 循环陷阱 =var函数作用域共享一个i+ 闭包引用共享 + 定时器延迟执行，三条件叠加输出3 3 3，换let或第三参数传值即解；并回顾了 201-203 全系列（setTimeout 七种形式 / 闭包还是传参 / 作用域链与 var 陷阱）。JS 语法番外告一段落，本篇回到 opencode 主线，开启新系列“TUI 内部”——第一篇看 thread.ts 拉起的 transport（url/fetch/events）第一次被 TUI 消费的现场
OpenCode
192-200 拆完了 thread.ts 的启动链路：handler 精心拉起了 Worker、transport、RPC、config。但有一个问题一直悬着——这些服务最终交给了谁？答案在app.tsx的tui()里：SDKProvider。它正是"启动链路 → 界面内部"的交接点。
🧩交接点：app.tsx 的 SDKProvider
thread.ts 传给tui()的四样东西（url / fetch / events / directory），在 app.tsx:144-150 全数交给SDKProvider：
// app.tsx:144-150 <SDKProvider url={input.url} // transport.url directory={input.directory} // cwd（directory key） fetch={input.fetch} // 内部模式是 createWorkerFetch headers={input.headers} events={input.events} // 内部模式是 createEventSource >这四件套正是 thread.ts 里transport双形态的产物（193/198 篇）：内部模式fetch/events是 RPC 代理，外部模式两者为undefined。现在它们要被 TUI 真正用起来了。
🔌SDK 客户端：transport 变成 client
context/sdk.tsx的SDKProvider初始化时调用createSDK()（sdk.tsx:24-33）：
functioncreateSDK(){returncreateOpencodeClient({baseUrl:props.url,// transport.urlsignal:abort.signal,directory:props.directory,// 目录 keyfetch:props.fetch,// transport.fetch（内部模式为 RPC 代理）headers:props.headers,experimental_workspaceID:workspaceID,})}createOpencodeClient是 opencode 的 SDK 客户端工厂——它把 url/fetch/directory 包装成一个带类型的方法集（session/message/provider…）。TUI 之后所有对后端的调用，都走这个client（sdk.tsx:109-111 的get client()）。
⚠️internal/external 分支：事件从哪来
sdk.tsx 最关键的分支在onMount（sdk.tsx:93-100）：
onMount(()=>{if(props.events){// 内部模式：直接订阅 thread.ts 传来的 RPC 事件源constunsub=props.events.on(handleEvent)onCleanup(unsub)}else{// 外部模式：没有 RPC 事件源，走 SDK 自己的 SSEstartSSE()}})这正是 198 篇 transport 双形态在 TUI 侧的实际消费现场：
| 模式 | 事件来源 | 说明 |
|---|---|---|
内部（有events） | createEventSource的 RPCevent频道 | thread.ts:42-49 造的那个事件源，TUI 直接on()订阅 |
外部（无events） | startSSE()走真实 SSE | sdk.tsx:73-91 用sdk.event.subscribe拉流，失败自动重连 |
🧩事件批量合并：16ms 窗口一次渲染
handleEvent（sdk.tsx:59-71）不直接把事件发出去，而是先入队合并：
consthandleEvent=(event:Event)=>{queue.push(event)constelapsed=Date.now()-lastif(timer)return// 刚 flush 过（16ms 内）→ 合并到下一次；否则立刻处理避免延迟if(elapsed<16){timer=setTimeout(flush,16)return}flush()}flush（sdk.tsx:45-57）用 Solid 的batch()把队列里所有事件一次性派发给响应式 store：
batch(()=>{for(consteventofevents){emitter.emit(event.type,event)}})这样"同一时刻涌来的一批事件（比如一次会话的多个消息事件）"只会触发一次渲染，而不是每个事件各渲染一次——这是 TUI 流畅的关键。
🧩setWorkspace：切工作区重建 SDK
sdk.tsx:115-121 的setWorkspace在切换 workspace 时重建整个 SDK 客户端：
setWorkspace(next?:string){if(workspaceID===next)returnworkspaceID=next sdk=createSDK()// 用新的 workspaceID 重建 clientprops.events?.setWorkspace?.(next)// 内部模式：通知 RPC 事件源切流if(!props.events)startSSE()// 外部模式：重启 SSE}experimental_workspaceID会影响 SDK 后续请求（如消息作用域），所以切换时整套 client 重建；内部模式还要通过createEventSource的setWorkspace（thread.ts:45-47）让 worker 切换事件流。
📊总结对比
| 环节 | 内部模式 | 外部模式 |
|---|---|---|
| SDK 构造 | createOpencodeClient（fetch=RPC 代理） | 同上（fetch=标准 fetch） |
| 事件来源 | props.events.on()（RPC event 频道） | startSSE()（真实 SSE 流） |
| 切工作区 | 重建 SDK + RPC setWorkspace | 重建 SDK + 重启 SSE |
| 事件派发 | 入队 16ms 合并 →batch()一次渲染 | 同左 |
📌一句话记忆
thread.ts 拉起的 transport 在
app.tsx被SDKProvider接收，context/sdk.tsx用createOpencodeClient把它变成 TUI 的client；事件来源按 internal/external 分叉——内部订阅 RPC 事件源、外部走真实 SSE；所有事件先入队、16ms 窗口内合并、batch()一次渲染；切 workspace 时整套 SDK 重建。
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
)
