人工智能AI AgentAI 应用移动开发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 做的一轮协议层运行时追踪从源码启动 OpenCode 服务、复制全局认证到隔离临时根目录、驱动真实样例项目只相信「发给 OpenCode 的请求体、OpenCode 返回的 JSON、/event的原始 SSE 日志、以及 OpenCode 源码」四类证据从而回答一个核心问题——OpenCode 的实时同步与转写模型到底是什么样Happy 的转写与同步层又该从中借鉴什么。读完本文你将掌握 OpenCode 目录路由、权限询问、媒体输入、子会话四类真实协议的完整载荷与事件序列并理解docs/plans/provider-envelope-redesign.md中「消息 部件」改造方案的证据来源。一、追踪背景与证据边界这份追踪记录撰写于 2026-03-21是较早一轮竞品分析缺失的协议级补充。其方法非常直接运行 OpenCode 源码把全局安装里的认证复制进一个隔离的临时根目录驱动一个真实的小项目并且只信任以下证据发送给 OpenCode 的精确请求体OpenCode 各端点返回的精确 JSON 响应OpenCode/event的原始 SSE 日志OpenCode 源码本身。在 Happy 一侧这份文档只信任 Happy 仓库内的代码。换言之这是一份「用真实运行轨迹说话」的对照文档而不是纸面推测。1.1 实际使用的环境项值OpenCode 源码检出../happy-adjacent/research/opencode作者本地外部检出目录检出版本commit2e0d5d230893dbddcefb35a02f53ff2e7a58e5d0样例项目仓库内的 environments/lab-rat-todo-project纯前端静态小项目index.html、app.js、styles.css、README.md隔离运行时根/tmp/opencode-trace-dev.ptZAVJ认证来源~/.local/share/opencode/auth.json复制到/tmp/opencode-trace-dev.ptZAVJ/share/opencode/auth.json复制后的认证文件中仅保留了openai一个 provider key1.2 服务端启动命令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_*系列环境变量把 OpenCode 的数据、缓存、配置、状态全部隔离到/tmp/opencode-trace-dev.ptZAVJ下OPENCODE_CONFIG_DIR指定独立配置目录OPENCODE_DB显式指定 SQLite 数据库路径服务监听127.0.0.1:4098并以 DEBUG 级别打印日志。这样既能复用全局认证只含 openai key又不会污染真实环境。支撑这套实测的关键 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二、什么是「真实」证据分散在四个面追踪得出的第一个重要结论是OpenCode 有用的协议证据并不是一个大的隐藏 RPC 信封而是分散在四个面上发送到POST /session/:id/prompt_async的请求体从GET /session/:id/message读到的持久化消息行从GET /event获得的实时补丁流控制面端点如/path、/permission、/session/:id/children、/experimental/worktree、/experimental/workspace的响应。这个区分对 Happy 至关重要。OpenCode 并没有一条「一次性提供给 UI 全部所需」的 append-only 转写流而是由四类机制协同带类型部件的稳定消息行stable message rows with typed parts针对这些行的实时补丁事件live patch events权限与会话状态的一等旁路事件first-class side-channel events转写之外的独立 workspace / worktree 路由。三、Flow 0目录路由、worktree、workspace 与「sandbox」的真实含义在触碰任何 prompt 之前先验证服务端如何限定请求范围。关键路由输入是请求头x-opencode-directory: /Users/kirilldubovitskiy/projects/happy/environments/lab-rat-todo-project真实的GET /path响应{ 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 }当前项目对应的真实空列表GET /experimental/worktree - [] GET /experimental/workspace - []这意味着项目限定是请求路由问题不是转写问题当前项目位于一个更宽的worktree根目录之下以及一个更窄的directory之内worktree 与 workspace 是显式的控制面资源这些内容不会以type: sandbox或type: workspace之类的转写部件出现。所以当 OpenCode 的产品语言说「sandbox」时落在具体实现上主要是三件事目录限定、可选的 workspace 路由、可选的 git worktree 管理。它不是Happy 已经拥有代码的那种 OS/文件系统/网络沙箱策略——后者可以参考 packages/happy-cli/src/sandbox/config.ts 中的buildSandboxRuntimeConfig它按sessionIsolationstrict/workspace/custom构造文件系统allowWrite/denyRead/denyWrite白名单并按networkModeblocked/allowed/custom配置allowedDomains/deniedDomains/allowLocalBinding等网络策略。这是两种完全不同的「沙箱」语义。四、Flow 1围绕apply_patch的权限询问——最完整的一条真实链路这是整个追踪中最干净的一条链路因为它一次跑通了用户 prompt 创建 → 助手步骤生命周期 → reasoning → 工具调用 → 权限请求 → 权限回复 → 文件编辑副作用 → 助手最终跟进。4.1 会话创建强制询问的编辑权限规则POST /session { title: trace permission ask, permission: [ { permission: edit, pattern: *, action: ask } ] }会话创建时显式带上权限规则把edit的*模式设为ask从而强制触发权限询问。4.2 实际发送的 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 本身就是「带类型部件的数组」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有序类型部件两层结构与请求体形态一致。4.4 实时权限事件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 } ] } } }这是追踪里最重要的发现之一OpenCode 的权限不是简单的「工具 X 想要批准」。这个请求携带了权限种类edit精确路径模式patterns稳定的请求 idper_...与工具调用的回链tool.messageIDtool.callID一份可直接渲染的 diff 载荷metadata.files带type、after、additions、deletions。也就是说权限事件本身就为 UI 准备好了审批界面的全部素材。4.5 工具调用前后的助手消息批准后持久化的助手消息{ 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 又发出第二条助手消息承载最终可见文本{ info: { role: assistant, finish: stop }, parts: [ { type: step-start }, { type: text, text: Done. }, { type: step-finish, reason: stop } ] }关键点工具调用携带自己的状态机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文件确实在磁盘上被创建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: [] }实时流同时发出了session.error。这是一个 OpenCode「诚实」的好例子用户侧的file部件被原样存储失败则成为助手/会话的错误状态而没有被「规范化」掉。对 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 规范化后的用户消息{ 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 助手响应被持久化{ 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 创建 → 流式message.part.delta助手文本→session.status回到idle。所以真实的媒体故事是三段式用户侧 prompt 部件type: file内部转写展开synthetic text 具体file助手侧回答普通文本输出。七、Flow 4子任务 / 子会话 / 权限约束——与 Happy 对照最重要的一环这是四类追踪里与 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的真实行为追加一条合成文本把「派生子代理」这件事显式写进转写。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 } ] }两个关键点父转写存储task工具调用及其结果可恢复性由子会话 id 提供以task_id形式返回ses_2f07a8dd6ffeRc23sIIgM4ZpMT即子会话 id可用于续跑该任务。7.4 子会话真的被创建了真实GET /session/{parentID}/children响应[ { 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指向父会话、自己的标题、继承的目录以及自己的权限规则这里显式 deny 了 todo 写入/读取与再派生子任务防止无限递归。7.5 跨父子的实时流原始/event流父会话用户消息创建父会话助手step-start父会话 reasoning 增量父会话task工具部件 →pending子会话session.created父会话工具部件 →running子会话内出现子会话用户消息子会话助手消息开始子会话 reasoning 增量流式推送子会话达到idle父会话工具部件 →completed结论OpenCode 并没有在一条扁平消息泳道里「假装」子代理而是使用父会话转写 子会话转写 父工具元数据链接到子会话 id。八、与 Happy 当前代码的逐项对照以下对照只使用 Happy 代码不做 Happy 运行时追踪表中 OpenCode 侧结论由日志/源码证明主题OpenCode日志/代码证明Happy代码证明外层信封消息行已有顶层info 有序类型化partspackages/happy-wire/src/messages.ts 仍把较新格式包装为role: session 内层content: sessionEnvelope事件判别部件用顶层type如text、reasoning、tool、file、agent、subtask、step-startpackages/happy-wire/src/sessionProtocol.ts 仍把事件类型嵌套在ev.t之下sessionEventSchema是t判别联合权限实时permission.asked/permission.replied事件携带工具回链与 diff 元数据packages/happy-app/sources/sync/reducer/reducer.ts 仍需通过合并类转写消息与加密agentState来重建权限状态子代理带parentID的真实子会话task_id是可恢复的子会话 idpackages/happy-wire/src/sessionProtocol.ts 的信封只有可选的subagent字段cuid2 校验没有子会话身份 转写级链接媒体用户file部件 合成辅助text成功的本地文件变成具体data:URLpackages/happy-wire/src/sessionProtocol.ts 只有一种file事件形态计划文档提出直接采用photo/video/file变体沙箱 / 隔离路由靠 directory/workspace 与可选 worktree「sandbox」大多是 worktree/workspace 语言packages/happy-cli/src/sandbox/config.ts 已有具体的文件系统 allow/deny 规则与网络模式客户端复杂度OpenCode 的 reducer 把实时补丁合并进已类型化的消息行packages/happy-app/sources/sync/typesRaw.ts 与 packages/happy-app/sources/sync/reducer/reducer.ts 仍保留多个 legacy 载荷族系agentEvent、session 事件、tool-call 等及复杂的重建逻辑对照结论非常直白OpenCode 拥有更干净的转写形态Happy 拥有更强的真实沙箱配置Happy 当前的 reducer 复杂度是「不再保留多个明文载荷族系」的最强论据。关于沙箱这一点可以进一步说明Happy 的buildSandboxRuntimeConfig在sessionIsolation: strict时只允许写入会话目录 额外写入路径 共享 agent 状态路径~/.codex、~/.claude在workspace模式放宽到 workspace 根网络侧blocked模式把allowedDomains与deniedDomains都清空allowed模式则放行。这套文件系统 网络的策略能力是 OpenCode 目录路由式「沙箱」所不具备的。九、对provider-envelope-redesign.md的启示当前规划上下文来自 docs/plans/provider-envelope-redesign.mdDRAFT v2OpenCode 衍生现有判断仍然成立p6 信封重设计工作位于 dirty worktree尚未进入已提交的分支历史该工作已经验证了若干有价值的清理动作type放顶层、去掉外层role: session、引入parentId/agentId、转写级权限、直接媒体变体该计划文档中的现有提案仍是「记录的方案」plan of recordOpenCode 的原始协议形态仍是锁定 Happy 新稳态 schema 前最值得评估的外部参照Claude 更旧的类转写格式如果最终证明最简单稳定的模型更接近那段历史仍是合理的回退选项。原文档特别强调OpenCode并不主张照抄 ACP 包装器行为而是主张照抄原始转写形态稳定的消息行stable message rows类型化部件typed parts显式的权限对象explicit permission objects显式的子会话身份explicit child-session identity转写状态与实时补丁传输的清晰分离。这与provider-envelope-redesign.md的取舍一致该计划采纳 messageparts 形态但拒绝OpenCode「权限/问题走旁路 SSE 事件」的做法——计划在工具部件状态机中加入显式blocked状态让权限请求与决策永久落在工具部件上block字段 decision: once | always | reject并拒绝以原始message.part.delta回放作为持久化同步模型改为可打补丁的规范消息pending → blocked → running → completed 原地演进同步发完整更新消息refetch 拿最新状态。十、Happy 最难的部分加密存储下的三个落地方案这是 OpenCode 与 Happy 分歧最大的地方。OpenCode 之所以能长期维持规范消息行 部件补丁是因为它的存储层能看到明文会话状态SQLite 明文行可随意打补丁。而Happy 存储的是不透明加密 blob。因此直接照抄 OpenCode 就必然要做一个存储决策。以下是三个候选方案。方案 Aappend-only 规范转写事件存储已规范化的、自身可持久化的加密记录。示例心智模型{ kind: agent-event, type: tool-start, ... } { kind: agent-event, type: permission-request, ... } { kind: agent-event, type: tool-end, ... }优点存储不可变refetch 简单匹配 Happy 当前的传输假设避免重放原始 delta 来重建可用转写。缺点不是对 OpenCode 补丁模型的字面照搬要么 start/end 事件永远分离要么客户端必须为 UI 便利推导「最新状态」视图。方案 B给规范加密消息行打补丁保留稳定加密消息 id但当部件获得新状态时重写加密载荷使 refetch 返回最新的规范快照。示例心智模型初始{ messageId: msg_123, parts: [ { type: tool, state: { status: pending } } ] }之后被重写为{ messageId: msg_123, parts: [ { type: tool, state: { status: completed, input: { ... }, output: ... } } ] }优点最接近 OpenCode 的服务端模型refetch 直接拿到最新规范状态客户端重建问题更少。缺点加密消息行变得可变同步/版本控制更微妙除非同时保留影子事件日志否则失去纯 append-only 历史。方案 C追加原始补丁事件客户端重建存储原始流客户端重建消息状态。示例心智模型{ type: message.updated, ... } { type: message.part.updated, ... } { type: message.part.delta, ... } { type: permission.asked, ... }优点最接近 OpenCode 实时流只要每个补丁都被追加就是完全不可变的。缺点这恰恰是最可能复刻 Happy 当前 reducer 之痛的路线refetch 需要回放/物化加密存储 遗留格式支持使其成为复杂度最高的选项。推荐结论如果 Happy 要向 OpenCode 借鉴应该借形态shape而不是整套持久化策略。最强的两个选项是append-only规范事件方案 A可打补丁的规范消息快照方案 B。最弱的选项是把原始补丁流重建作为主要持久化格式方案 C——那会保留太多我们正试图消除的复杂度。方案 B 也正是docs/plans/provider-envelope-redesign.md选定的方向消息 id 稳定、工具部件状态演进时整体重加密并同步完整消息、refetch 直接拿最新状态、不以 append-only 事件日志作为主存储而 DB 行、seq排序、localId、v3 HTTP 消息 API、Socket.IO 失效通知与加密 blob 格式均保持不变。小结以真实运行轨迹为唯一证据可以确认 OpenCode 的协议核心是「稳定消息行 类型化部件 显式权限对象 显式子会话身份 转写与实时补丁分离」。它对 Happy 的最大价值不是可照抄的传输层而是可作为稳态 schema 的参照形态而 Happy 真正的差异化优势文件系统/网络级沙箱策略、端到端加密存储决定了它必须把 OpenCode 的形态改造进自己的加密存储约束之内——这正是docs/plans/provider-envelope-redesign.md正在做的事。建议继续阅读同一研究系列中的 docs/competition/opencode/message-protocol.md 与 docs/competition/opencode/sources.md以及 docs/plans/provider-envelope-redesign.md 的完整方案。赞分享人工智能AI AgentAI 应用移动开发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 Provider Envelope 重构设计以 OpenCode messageparts 模型统一多 Provider 会话协议Happy Provider Envelope 重构设计以 OpenCode messageparts 模型统一多 Provider 会话协议 本文基于 d人工智能AI AgentAI 应用移动开发CLI后端OpenCode 消息协议深度剖析happy 项目借鉴的 Envelope Typed Parts 转写模型OpenCode 消息协议深度剖析happy 项目借鉴的 Envelope Typed Parts 转写模型 导读 本文基于 happy 仓库 docs/人工智能AI AgentAI 应用移动开发CLI后端Happy 竞品协议矩阵解析OpenCode、Codex、Claude、Superset 的传输、转录、权限与沙箱设计对照Happy 竞品协议矩阵解析OpenCode、Codex、Claude、Superset 的传输、转录、权限与沙箱设计对照 本文基于 docs/competi人工智能AI AgentAI 应用移动开发CLI后端上一篇Medusa 开源电商框架完整指南从零搭建可定制的 Commerce 后端下一篇开源项目推荐mir_eval创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考