【声明】本博客所有内容均为个人业余时间创作所述技术案例均来自公开开源项目如GithubApache基金会不涉及任何企业机密或未公开技术如有侵权请联系删除标题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 拉起的 transporturl/fetch/events第一次被 TUI 消费的现场OpenCode192-200 拆完了 thread.ts 的启动链路handler 精心拉起了 Worker、transport、RPC、config。但有一个问题一直悬着——这些服务最终交给了谁答案在app.tsx的tui()里SDKProvider。它正是启动链路 → 界面内部的交接点。交接点app.tsx 的 SDKProviderthread.ts 传给tui()的四样东西url / fetch / events / directory在 app.tsx:144-150 全数交给SDKProvider// app.tsx:144-150 SDKProvider url{input.url} // transport.url directory{input.directory} // cwddirectory key fetch{input.fetch} // 内部模式是 createWorkerFetch headers{input.headers} events{input.events} // 内部模式是 createEventSource 这四件套正是 thread.ts 里transport双形态的产物193/198 篇内部模式fetch/events是 RPC 代理外部模式两者为undefined。现在它们要被 TUI 真正用起来了。SDK 客户端transport 变成 clientcontext/sdk.tsx的SDKProvider初始化时调用createSDK()sdk.tsx:24-33functioncreateSDK(){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 之后所有对后端的调用都走这个clientsdk.tsx:109-111 的get client()。⚠️internal/external 分支事件从哪来sdk.tsx 最关键的分支在onMountsdk.tsx:93-100onMount((){if(props.events){// 内部模式直接订阅 thread.ts 传来的 RPC 事件源constunsubprops.events.on(handleEvent)onCleanup(unsub)}else{// 外部模式没有 RPC 事件源走 SDK 自己的 SSEstartSSE()}})这正是 198 篇 transport 双形态在 TUI 侧的实际消费现场模式事件来源说明内部有eventscreateEventSource的 RPCevent频道thread.ts:42-49 造的那个事件源TUI 直接on()订阅外部无eventsstartSSE()走真实 SSEsdk.tsx:73-91 用sdk.event.subscribe拉流失败自动重连事件批量合并16ms 窗口一次渲染handleEventsdk.tsx:59-71不直接把事件发出去而是先入队合并consthandleEvent(event:Event){queue.push(event)constelapsedDate.now()-lastif(timer)return// 刚 flush 过16ms 内→ 合并到下一次否则立刻处理避免延迟if(elapsed16){timersetTimeout(flush,16)return}flush()}flushsdk.tsx:45-57用 Solid 的batch()把队列里所有事件一次性派发给响应式 storebatch((){for(consteventofevents){emitter.emit(event.type,event)}})这样同一时刻涌来的一批事件比如一次会话的多个消息事件只会触发一次渲染而不是每个事件各渲染一次——这是 TUI 流畅的关键。setWorkspace切工作区重建 SDKsdk.tsx:115-121 的setWorkspace在切换 workspace 时重建整个 SDK 客户端setWorkspace(next?:string){if(workspaceIDnext)returnworkspaceIDnext sdkcreateSDK()// 用新的 workspaceID 重建 clientprops.events?.setWorkspace?.(next)// 内部模式通知 RPC 事件源切流if(!props.events)startSSE()// 外部模式重启 SSE}experimental_workspaceID会影响 SDK 后续请求如消息作用域所以切换时整套 client 重建内部模式还要通过createEventSource的setWorkspacethread.ts:45-47让 worker 切换事件流。总结对比环节内部模式外部模式SDK 构造createOpencodeClientfetchRPC 代理同上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