人工智能AI AgentAI 應(yīng)用移動開發(fā)CLI后端【免費下載鏈接】happyMobile and Web client for Codex and Claude Code, with realtime voice, encryption and fully featured項目地址https://gitcode.com/gh_mirrors/happy20/happy點擊查看免費下載本文是 Happy 項目針對 OpenCode 做的一輪協(xié)議層運行時追蹤從源碼啟動 OpenCode 服務(wù)、復(fù)制全局認證到隔離臨時根目錄、驅(qū)動真實樣例項目只相信「發(fā)給 OpenCode 的請求體、OpenCode 返回的 JSON、/event的原始 SSE 日志、以及 OpenCode 源碼」四類證據(jù)從而回答一個核心問題——OpenCode 的實時同步與轉(zhuǎn)寫模型到底是什么樣Happy 的轉(zhuǎn)寫與同步層又該從中借鑒什么。讀完本文你將掌握 OpenCode 目錄路由、權(quán)限詢問、媒體輸入、子會話四類真實協(xié)議的完整載荷與事件序列并理解docs/plans/provider-envelope-redesign.md中「消息 部件」改造方案的證據(jù)來源。一、追蹤背景與證據(jù)邊界這份追蹤記錄撰寫于 2026-03-21是較早一輪競品分析缺失的協(xié)議級補充。其方法非常直接運行 OpenCode 源碼把全局安裝里的認證復(fù)制進一個隔離的臨時根目錄驅(qū)動一個真實的小項目并且只信任以下證據(jù)發(fā)送給 OpenCode 的精確請求體OpenCode 各端點返回的精確 JSON 響應(yīng)OpenCode/event的原始 SSE 日志OpenCode 源碼本身。在 Happy 一側(cè)這份文檔只信任 Happy 倉庫內(nèi)的代碼。換言之這是一份「用真實運行軌跡說話」的對照文檔而不是紙面推測。1.1 實際使用的環(huán)境項值OpenCode 源碼檢出../happy-adjacent/research/opencode作者本地外部檢出目錄檢出版本commit2e0d5d230893dbddcefb35a02f53ff2e7a58e5d0樣例項目倉庫內(nèi)的 environments/lab-rat-todo-project純前端靜態(tài)小項目index.html、app.js、styles.css、README.md隔離運行時根/tmp/opencode-trace-dev.ptZAVJ認證來源~/.local/share/opencode/auth.json復(fù)制到/tmp/opencode-trace-dev.ptZAVJ/share/opencode/auth.json復(fù)制后的認證文件中僅保留了openai一個 provider key1.2 服務(wù)端啟動命令XDG_DATA_HOME/tmp/opencode-trace-dev.ptZAVJ/share \ XDG_CACHE_HOME/tmp/opencode-trace-dev.ptZAVJ/cache \ XDG_CONFIG_HOME/tmp/opencode-trace-dev.ptZAVJ/config \ XDG_STATE_HOME/tmp/opencode-trace-dev.ptZAVJ/state \ OPENCODE_CONFIG_DIR/tmp/opencode-trace-dev.ptZAVJ/profile \ OPENCODE_DB/tmp/opencode-trace-dev.ptZAVJ/share/opencode/opencode.db \ bun run --cwd packages/opencode --conditionsbrowser src/index.ts \ serve --hostname 127.0.0.1 --port 4098 --print-logs --log-level DEBUG這套命令的要點在于通過XDG_*系列環(huán)境變量把 OpenCode 的數(shù)據(jù)、緩存、配置、狀態(tài)全部隔離到/tmp/opencode-trace-dev.ptZAVJ下OPENCODE_CONFIG_DIR指定獨立配置目錄OPENCODE_DB顯式指定 SQLite 數(shù)據(jù)庫路徑服務(wù)監(jiān)聽127.0.0.1:4098并以 DEBUG 級別打印日志。這樣既能復(fù)用全局認證只含 openai key又不會污染真實環(huán)境。支撐這套實測的關(guān)鍵 OpenCode 源碼文件作者本地檢出路徑從../happy-adjacent/research/opencode起packages/opencode/src/auth/index.tspackages/opencode/src/server/server.tspackages/opencode/src/server/routes/experimental.tspackages/opencode/src/session/message-v2.tspackages/opencode/src/session/prompt.tspackages/opencode/src/tool/task.tspackages/opencode/src/permission/index.ts二、什么是「真實」證據(jù)分散在四個面追蹤得出的第一個重要結(jié)論是OpenCode 有用的協(xié)議證據(jù)并不是一個大的隱藏 RPC 信封而是分散在四個面上發(fā)送到POST /session/:id/prompt_async的請求體從GET /session/:id/message讀到的持久化消息行從GET /event獲得的實時補丁流控制面端點如/path、/permission、/session/:id/children、/experimental/worktree、/experimental/workspace的響應(yīng)。這個區(qū)分對 Happy 至關(guān)重要。OpenCode 并沒有一條「一次性提供給 UI 全部所需」的 append-only 轉(zhuǎn)寫流而是由四類機制協(xié)同帶類型部件的穩(wěn)定消息行stable message rows with typed parts針對這些行的實時補丁事件live patch events權(quán)限與會話狀態(tài)的一等旁路事件first-class side-channel events轉(zhuǎn)寫之外的獨立 workspace / worktree 路由。三、Flow 0目錄路由、worktree、workspace 與「sandbox」的真實含義在觸碰任何 prompt 之前先驗證服務(wù)端如何限定請求范圍。關(guān)鍵路由輸入是請求頭x-opencode-directory: /Users/kirilldubovitskiy/projects/happy/environments/lab-rat-todo-project真實的GET /path響應(yīng){ home: /Users/kirilldubovitskiy, state: /tmp/opencode-trace-dev.ptZAVJ/state/opencode, config: /tmp/opencode-trace-dev.ptZAVJ/config/opencode, worktree: /Users/kirilldubovitskiy/projects/happy, directory: /Users/kirilldubovitskiy/projects/happy/environments/lab-rat-todo-project }當前項目對應(yīng)的真實空列表GET /experimental/worktree - [] GET /experimental/workspace - []這意味著項目限定是請求路由問題不是轉(zhuǎn)寫問題當前項目位于一個更寬的worktree根目錄之下以及一個更窄的directory之內(nèi)worktree 與 workspace 是顯式的控制面資源這些內(nèi)容不會以type: sandbox或type: workspace之類的轉(zhuǎn)寫部件出現(xiàn)。所以當 OpenCode 的產(chǎn)品語言說「sandbox」時落在具體實現(xiàn)上主要是三件事目錄限定、可選的 workspace 路由、可選的 git worktree 管理。它不是Happy 已經(jīng)擁有代碼的那種 OS/文件系統(tǒng)/網(wǎng)絡(luò)沙箱策略——后者可以參考 packages/happy-cli/src/sandbox/config.ts 中的buildSandboxRuntimeConfig它按sessionIsolationstrict/workspace/custom構(gòu)造文件系統(tǒng)allowWrite/denyRead/denyWrite白名單并按networkModeblocked/allowed/custom配置allowedDomains/deniedDomains/allowLocalBinding等網(wǎng)絡(luò)策略。這是兩種完全不同的「沙箱」語義。四、Flow 1圍繞apply_patch的權(quán)限詢問——最完整的一條真實鏈路這是整個追蹤中最干凈的一條鏈路因為它一次跑通了用戶 prompt 創(chuàng)建 → 助手步驟生命周期 → reasoning → 工具調(diào)用 → 權(quán)限請求 → 權(quán)限回復(fù) → 文件編輯副作用 → 助手最終跟進。4.1 會話創(chuàng)建強制詢問的編輯權(quán)限規(guī)則POST /session { title: trace permission ask, permission: [ { permission: edit, pattern: *, action: ask } ] }會話創(chuàng)建時顯式帶上權(quán)限規(guī)則把edit的*模式設(shè)為ask從而強制觸發(fā)權(quán)限詢問。4.2 實際發(fā)送的 Prompt 請求體POST /session/{sessionID}/prompt_async { agent: build, model: { providerID: openai, modelID: gpt-5.4-mini }, parts: [ { type: text, text: Create a new file named TRACE_PERMISSION.md in the current directory with exactly one line: rat permission trace. Then reply with one short sentence. } ] }注意prompt 本身就是「帶類型部件的數(shù)組」agent與model在消息外層顯式聲明。4.3 用戶消息被持久化{ info: { role: user, id: msg_d0f8263b50016s8bKlZ36Te52c, sessionID: ses_2f07d9c71ffeikGiLoOKqF2Evb }, parts: [ { type: text, text: Create a new file named TRACE_PERMISSION.md in the current directory with exactly one line: rat permission trace. Then reply with one short sentence. } ] }消息被持久化為info角色、id、會話 idparts有序類型部件兩層結(jié)構(gòu)與請求體形態(tài)一致。4.4 實時權(quán)限事件SSE真實 SSE 事件{ type: permission.asked, properties: { id: per_d0f826ef60011FReJ16cM2d0MK, sessionID: ses_2f07d9c71ffeikGiLoOKqF2Evb, permission: edit, patterns: [ environments/lab-rat-todo-project/TRACE_PERMISSION.md ], always: [*], tool: { messageID: msg_d0f8263b9001UcnDrNrnbyYeyT, callID: call_uJj6gIQfIPpSoBV9oOWBT7cF }, metadata: { filepath: environments/lab-rat-todo-project/TRACE_PERMISSION.md, files: [ { relativePath: environments/lab-rat-todo-project/TRACE_PERMISSION.md, type: add, after: rat permission trace\n, additions: 1, deletions: 0 } ] } } }這是追蹤里最重要的發(fā)現(xiàn)之一OpenCode 的權(quán)限不是簡單的「工具 X 想要批準」。這個請求攜帶了權(quán)限種類edit精確路徑模式patterns穩(wěn)定的請求 idper_...與工具調(diào)用的回鏈tool.messageIDtool.callID一份可直接渲染的 diff 載荷metadata.files帶type、after、additions、deletions。也就是說權(quán)限事件本身就為 UI 準備好了審批界面的全部素材。4.5 工具調(diào)用前后的助手消息批準后持久化的助手消息{ info: { role: assistant, finish: tool-calls, id: msg_d0f8263b9001UcnDrNrnbyYeyT }, parts: [ { type: step-start, snapshot: dfd3f0873ec51c2ddbf0b6b79acc154e5ab15c5d }, { type: reasoning, text: **Creating a file**\n\nI need to create a file..., metadata: { openai: { itemId: rs_..., reasoningEncryptedContent: gAAAAA... } } }, { type: tool, callID: call_uJj6gIQfIPpSoBV9oOWBT7cF, tool: apply_patch, state: { status: completed, input: { patchText: *** Begin Patch\n*** Add File: TRACE_PERMISSION.md\nrat permission trace\n*** End Patch }, output: Success. Updated the following files:\nA environments/lab-rat-todo-project/TRACE_PERMISSION.md } }, { type: step-finish, reason: tool-calls } ] }隨后 OpenCode 又發(fā)出第二條助手消息承載最終可見文本{ info: { role: assistant, finish: stop }, parts: [ { type: step-start }, { type: text, text: Done. }, { type: step-finish, reason: stop } ] }關(guān)鍵點工具調(diào)用攜帶自己的狀態(tài)機state.statuspending → running → completed且step-start/step-finish是獨立部件reasoning 也是獨立部件最終文本又落在單獨的 assistant 消息里。整條鏈在持久化層是自解釋的。4.6 實際看到的實時事件序列原始 SSE 流的順序18 步session.createdmessage.updated用戶消息message.part.updated用戶text部件session.status→busymessage.updated助手消息殼message.part.updated→step-startmessage.part.updated→reasoning大量message.part.delta塊流式推送 reasoning 文本message.part.updated→ 工具部件status: pendingpermission.askedpermission.repliedfile.editedfile.watcher.updatedmessage.part.updated→ 工具部件status: runningmessage.part.updated→ 工具部件status: completedmessage.part.updated→step-finish第二條助手消息攜帶最終textsession.status→idle文件確實在磁盤上被創(chuàng)建TRACE_PERMISSION.md: rat permission trace五、Flow 2媒體輸入失敗路徑——provider 拒絕前的誠實存儲失敗場景很有價值因為它展示了 provider 拒絕請求之前 OpenCode 到底存了什么。5.1 Prompt 請求體{ agent: build, model: { providerID: openai, modelID: gpt-5.4-mini }, parts: [ { type: text, text: Describe the attached image in one short sentence. Do not use any tools. }, { type: file, mime: image/png, filename: tiny.png, url: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/x8AAwMCAO7Z0XQAAAAASUVORK5CYII } ] }5.2 用戶消息被持久化原樣{ info: { role: user }, parts: [ { type: text, text: Describe the attached image in one short sentence. Do not use any tools. }, { type: file, mime: image/png, filename: tiny.png, url: data:image/png;base64,iVBORw0K... } ] }5.3 助手錯誤被持久化{ info: { role: assistant, error: { name: APIError, data: { message: The image data you provided does not represent a valid image. Please check your input and try again., statusCode: 400, isRetryable: false, metadata: { url: https://api.openai.com/v1/responses } } } }, parts: [] }實時流同時發(fā)出了session.error。這是一個 OpenCode「誠實」的好例子用戶側(cè)的file部件被原樣存儲失敗則成為助手/會話的錯誤狀態(tài)而沒有被「規(guī)范化」掉。對 Happy 而言這意味著消息層必須能表達失敗而不是把失敗折疊進某個模糊的文本里。六、Flow 3媒體輸入成功路徑——本地文件被 OpenCode 自行解析成功路徑完全不同因為輸入 URL 是本地file://...由 OpenCode 自己解析。6.1 Prompt 請求體{ agent: build, model: { providerID: openai, modelID: gpt-5.4-mini }, parts: [ { type: text, text: Describe the attached image in one short sentence. Do not use any tools. }, { type: file, mime: image/png, filename: logo.png, url: file:///Users/kirilldubovitskiy/projects/happy/logo.png } ] }6.2 規(guī)范化后的用戶消息{ info: { role: user }, parts: [ { type: text, text: Describe the attached image in one short sentence. Do not use any tools. }, { type: text, synthetic: true, text: Called the Read tool with the following input: {\filePath\:\/Users/kirilldubovitskiy/projects/happy/logo.png\} }, { type: file, mime: image/png, filename: logo.png, url: data:image/png;base64,iVBORw0K... } ] }這是session/prompt.ts的真實行為原文檔明確標注非猜測OpenCode 注入一條synthetic: true的文本部件描述這次讀取再把媒體本身作為file部件存儲且本地文件被解析成具體的data:URL。6.3 助手響應(yīng)被持久化{ info: { role: assistant, finish: stop }, parts: [ { type: step-start }, { type: reasoning, text: , metadata: { openai: { itemId: rs_..., reasoningEncryptedContent: gAAAAA... } } }, { type: text, text: A cute cartoon otter is lounging in water while using a laptop. }, { type: step-finish, reason: stop } ] }6.4 實時流證明了什么/event日志顯示message.part.updated合成讀取文本→message.part.updatedfile部件→ reasoning 創(chuàng)建 → 流式message.part.delta助手文本→session.status回到idle。所以真實的媒體故事是三段式用戶側(cè) prompt 部件type: file內(nèi)部轉(zhuǎn)寫展開synthetic text 具體file助手側(cè)回答普通文本輸出。七、Flow 4子任務(wù) / 子會話 / 權(quán)限約束——與 Happy 對照最重要的一環(huán)這是四類追蹤里與 Happy 做并排對照最重要的一條。7.1 Prompt 請求體含 agent 部件{ agent: build, model: { providerID: openai, modelID: gpt-5.4-mini }, parts: [ { type: text, text: Find the main files in this tiny project and report back briefly. }, { type: agent, name: explore } ] }7.2 用戶消息被改寫OpenCode沒有只存原始的agent部件而是把用戶消息重寫為{ info: { role: user }, parts: [ { type: text, text: Find the main files in this tiny project and report back briefly. }, { type: agent, name: explore }, { type: text, synthetic: true, text: Use the above message and context to generate a prompt and call the task tool with subagent: explore } ] }同樣是session/prompt.ts的真實行為追加一條合成文本把「派生子代理」這件事顯式寫進轉(zhuǎn)寫。7.3 父會話的助手消息與task工具部件{ info: { role: assistant, finish: tool-calls, id: msg_d0f855de2001b0RbgA3JGA5lzk }, parts: [ { type: step-start }, { type: reasoning, text: **Generating a task prompt**\n\nI need to call the task tool with the subagent explore... }, { type: tool, callID: call_OqUEr7ccnf3zEb2rgLYDp5uR, tool: task, state: { status: completed, input: { description: Find main project files, prompt: Inspect the repository and identify the main files in this tiny project. Focus on the key entry points, config files, and any top-level files that define how the project runs. Return a brief list of the most important files with one short note each about what they appear to do. Keep it concise and do not modify anything., subagent_type: explore }, output: task_id: ses_2f07a8dd6ffeRc23sIIgM4ZpMT (for resuming to continue this task if needed)\n\ntask_result\nMain files:\n\n- .../index.html ...\n- .../app.js ...\n- .../styles.css ...\n- .../README.md ...\n\nNo build/config files are present; it looks like a simple frontend-only static app.\n/task_result, metadata: { sessionId: ses_2f07a8dd6ffeRc23sIIgM4ZpMT, model: { modelID: gpt-5.4-mini, providerID: openai } } } }, { type: step-finish, reason: tool-calls } ] }兩個關(guān)鍵點父轉(zhuǎn)寫存儲task工具調(diào)用及其結(jié)果可恢復(fù)性由子會話 id 提供以task_id形式返回ses_2f07a8dd6ffeRc23sIIgM4ZpMT即子會話 id可用于續(xù)跑該任務(wù)。7.4 子會話真的被創(chuàng)建了真實GET /session/{parentID}/children響應(yīng)[ { id: ses_2f07a8dd6ffeRc23sIIgM4ZpMT, parentID: ses_2f07aa25affeqiZHSnBiN8pSyG, title: Find main project files (explore subagent), directory: /Users/kirilldubovitskiy/projects/happy/environments/lab-rat-todo-project, permission: [ { permission: todowrite, pattern: *, action: deny }, { permission: todoread, pattern: *, action: deny }, { permission: task, pattern: *, action: deny } ] } ]這是「OpenCode 子代理就是子會話」最干凈的證明子會話擁有自己的 id、自己的parentID指向父會話、自己的標題、繼承的目錄以及自己的權(quán)限規(guī)則這里顯式 deny 了 todo 寫入/讀取與再派生子任務(wù)防止無限遞歸。7.5 跨父子的實時流原始/event流父會話用戶消息創(chuàng)建父會話助手step-start父會話 reasoning 增量父會話task工具部件 →pending子會話session.created父會話工具部件 →running子會話內(nèi)出現(xiàn)子會話用戶消息子會話助手消息開始子會話 reasoning 增量流式推送子會話達到idle父會話工具部件 →completed結(jié)論OpenCode 并沒有在一條扁平消息泳道里「假裝」子代理而是使用父會話轉(zhuǎn)寫 子會話轉(zhuǎn)寫 父工具元數(shù)據(jù)鏈接到子會話 id。八、與 Happy 當前代碼的逐項對照以下對照只使用 Happy 代碼不做 Happy 運行時追蹤表中 OpenCode 側(cè)結(jié)論由日志/源碼證明主題OpenCode日志/代碼證明Happy代碼證明外層信封消息行已有頂層info 有序類型化partspackages/happy-wire/src/messages.ts 仍把較新格式包裝為role: session 內(nèi)層content: sessionEnvelope事件判別部件用頂層type如text、reasoning、tool、file、agent、subtask、step-startpackages/happy-wire/src/sessionProtocol.ts 仍把事件類型嵌套在ev.t之下sessionEventSchema是t判別聯(lián)合權(quán)限實時permission.asked/permission.replied事件攜帶工具回鏈與 diff 元數(shù)據(jù)packages/happy-app/sources/sync/reducer/reducer.ts 仍需通過合并類轉(zhuǎn)寫消息與加密agentState來重建權(quán)限狀態(tài)子代理帶parentID的真實子會話task_id是可恢復(fù)的子會話 idpackages/happy-wire/src/sessionProtocol.ts 的信封只有可選的subagent字段cuid2 校驗沒有子會話身份 轉(zhuǎn)寫級鏈接媒體用戶file部件 合成輔助text成功的本地文件變成具體data:URLpackages/happy-wire/src/sessionProtocol.ts 只有一種file事件形態(tài)計劃文檔提出直接采用photo/video/file變體沙箱 / 隔離路由靠 directory/workspace 與可選 worktree「sandbox」大多是 worktree/workspace 語言packages/happy-cli/src/sandbox/config.ts 已有具體的文件系統(tǒng) allow/deny 規(guī)則與網(wǎng)絡(luò)模式客戶端復(fù)雜度OpenCode 的 reducer 把實時補丁合并進已類型化的消息行packages/happy-app/sources/sync/typesRaw.ts 與 packages/happy-app/sources/sync/reducer/reducer.ts 仍保留多個 legacy 載荷族系agentEvent、session 事件、tool-call 等及復(fù)雜的重建邏輯對照結(jié)論非常直白OpenCode 擁有更干凈的轉(zhuǎn)寫形態(tài)Happy 擁有更強的真實沙箱配置Happy 當前的 reducer 復(fù)雜度是「不再保留多個明文載荷族系」的最強論據(jù)。關(guān)于沙箱這一點可以進一步說明Happy 的buildSandboxRuntimeConfig在sessionIsolation: strict時只允許寫入會話目錄 額外寫入路徑 共享 agent 狀態(tài)路徑~/.codex、~/.claude在workspace模式放寬到 workspace 根網(wǎng)絡(luò)側(cè)blocked模式把allowedDomains與deniedDomains都清空allowed模式則放行。這套文件系統(tǒng) 網(wǎng)絡(luò)的策略能力是 OpenCode 目錄路由式「沙箱」所不具備的。九、對provider-envelope-redesign.md的啟示當前規(guī)劃上下文來自 docs/plans/provider-envelope-redesign.mdDRAFT v2OpenCode 衍生現(xiàn)有判斷仍然成立p6 信封重設(shè)計工作位于 dirty worktree尚未進入已提交的分支歷史該工作已經(jīng)驗證了若干有價值的清理動作type放頂層、去掉外層role: session、引入parentId/agentId、轉(zhuǎn)寫級權(quán)限、直接媒體變體該計劃文檔中的現(xiàn)有提案仍是「記錄的方案」plan of recordOpenCode 的原始協(xié)議形態(tài)仍是鎖定 Happy 新穩(wěn)態(tài) schema 前最值得評估的外部參照Claude 更舊的類轉(zhuǎn)寫格式如果最終證明最簡單穩(wěn)定的模型更接近那段歷史仍是合理的回退選項。原文檔特別強調(diào)OpenCode并不主張照抄 ACP 包裝器行為而是主張照抄原始轉(zhuǎn)寫形態(tài)穩(wěn)定的消息行stable message rows類型化部件typed parts顯式的權(quán)限對象explicit permission objects顯式的子會話身份explicit child-session identity轉(zhuǎn)寫狀態(tài)與實時補丁傳輸?shù)那逦蛛x。這與provider-envelope-redesign.md的取舍一致該計劃采納 messageparts 形態(tài)但拒絕OpenCode「權(quán)限/問題走旁路 SSE 事件」的做法——計劃在工具部件狀態(tài)機中加入顯式blocked狀態(tài)讓權(quán)限請求與決策永久落在工具部件上block字段 decision: once | always | reject并拒絕以原始message.part.delta回放作為持久化同步模型改為可打補丁的規(guī)范消息pending → blocked → running → completed 原地演進同步發(fā)完整更新消息refetch 拿最新狀態(tài)。十、Happy 最難的部分加密存儲下的三個落地方案這是 OpenCode 與 Happy 分歧最大的地方。OpenCode 之所以能長期維持規(guī)范消息行 部件補丁是因為它的存儲層能看到明文會話狀態(tài)SQLite 明文行可隨意打補丁。而Happy 存儲的是不透明加密 blob。因此直接照抄 OpenCode 就必然要做一個存儲決策。以下是三個候選方案。方案 Aappend-only 規(guī)范轉(zhuǎn)寫事件存儲已規(guī)范化的、自身可持久化的加密記錄。示例心智模型{ kind: agent-event, type: tool-start, ... } { kind: agent-event, type: permission-request, ... } { kind: agent-event, type: tool-end, ... }優(yōu)點存儲不可變refetch 簡單匹配 Happy 當前的傳輸假設(shè)避免重放原始 delta 來重建可用轉(zhuǎn)寫。缺點不是對 OpenCode 補丁模型的字面照搬要么 start/end 事件永遠分離要么客戶端必須為 UI 便利推導(dǎo)「最新狀態(tài)」視圖。方案 B給規(guī)范加密消息行打補丁保留穩(wěn)定加密消息 id但當部件獲得新狀態(tài)時重寫加密載荷使 refetch 返回最新的規(guī)范快照。示例心智模型初始{ messageId: msg_123, parts: [ { type: tool, state: { status: pending } } ] }之后被重寫為{ messageId: msg_123, parts: [ { type: tool, state: { status: completed, input: { ... }, output: ... } } ] }優(yōu)點最接近 OpenCode 的服務(wù)端模型refetch 直接拿到最新規(guī)范狀態(tài)客戶端重建問題更少。缺點加密消息行變得可變同步/版本控制更微妙除非同時保留影子事件日志否則失去純 append-only 歷史。方案 C追加原始補丁事件客戶端重建存儲原始流客戶端重建消息狀態(tài)。示例心智模型{ type: message.updated, ... } { type: message.part.updated, ... } { type: message.part.delta, ... } { type: permission.asked, ... }優(yōu)點最接近 OpenCode 實時流只要每個補丁都被追加就是完全不可變的。缺點這恰恰是最可能復(fù)刻 Happy 當前 reducer 之痛的路線refetch 需要回放/物化加密存儲 遺留格式支持使其成為復(fù)雜度最高的選項。推薦結(jié)論如果 Happy 要向 OpenCode 借鑒應(yīng)該借形態(tài)shape而不是整套持久化策略。最強的兩個選項是append-only規(guī)范事件方案 A可打補丁的規(guī)范消息快照方案 B。最弱的選項是把原始補丁流重建作為主要持久化格式方案 C——那會保留太多我們正試圖消除的復(fù)雜度。方案 B 也正是docs/plans/provider-envelope-redesign.md選定的方向消息 id 穩(wěn)定、工具部件狀態(tài)演進時整體重加密并同步完整消息、refetch 直接拿最新狀態(tài)、不以 append-only 事件日志作為主存儲而 DB 行、seq排序、localId、v3 HTTP 消息 API、Socket.IO 失效通知與加密 blob 格式均保持不變。小結(jié)以真實運行軌跡為唯一證據(jù)可以確認 OpenCode 的協(xié)議核心是「穩(wěn)定消息行 類型化部件 顯式權(quán)限對象 顯式子會話身份 轉(zhuǎn)寫與實時補丁分離」。它對 Happy 的最大價值不是可照抄的傳輸層而是可作為穩(wěn)態(tài) schema 的參照形態(tài)而 Happy 真正的差異化優(yōu)勢文件系統(tǒng)/網(wǎng)絡(luò)級沙箱策略、端到端加密存儲決定了它必須把 OpenCode 的形態(tài)改造進自己的加密存儲約束之內(nèi)——這正是docs/plans/provider-envelope-redesign.md正在做的事。建議繼續(xù)閱讀同一研究系列中的 docs/competition/opencode/message-protocol.md 與 docs/competition/opencode/sources.md以及 docs/plans/provider-envelope-redesign.md 的完整方案。贊分享人工智能AI AgentAI 應(yīng)用移動開發(fā)CLI后端【免費下載鏈接】happyMobile and Web client for Codex and Claude Code, with realtime voice, encryption and fully featured項目地址https://gitcode.com/gh_mirrors/happy20/happy點擊查看免費下載相關(guān)推薦Happy Provider Envelope 重構(gòu)設(shè)計以 OpenCode messageparts 模型統(tǒng)一多 Provider 會話協(xié)議Happy Provider Envelope 重構(gòu)設(shè)計以 OpenCode messageparts 模型統(tǒng)一多 Provider 會話協(xié)議 本文基于 d人工智能AI AgentAI 應(yīng)用移動開發(fā)CLI后端OpenCode 消息協(xié)議深度剖析happy 項目借鑒的 Envelope Typed Parts 轉(zhuǎn)寫模型OpenCode 消息協(xié)議深度剖析happy 項目借鑒的 Envelope Typed Parts 轉(zhuǎn)寫模型 導(dǎo)讀 本文基于 happy 倉庫 docs/人工智能AI AgentAI 應(yīng)用移動開發(fā)CLI后端Happy 競品協(xié)議矩陣解析OpenCode、Codex、Claude、Superset 的傳輸、轉(zhuǎn)錄、權(quán)限與沙箱設(shè)計對照Happy 競品協(xié)議矩陣解析OpenCode、Codex、Claude、Superset 的傳輸、轉(zhuǎn)錄、權(quán)限與沙箱設(shè)計對照 本文基于 docs/competi人工智能AI AgentAI 應(yīng)用移動開發(fā)CLI后端上一篇Medusa 開源電商框架完整指南從零搭建可定制的 Commerce 后端下一篇開源項目推薦mir_eval創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考