同一个 Agent 怎样服务 CLI、IDE 与桌面端？
教学案例：用户在桌面端发起登录超时修复，在 IDE 里检查 Diff，又在手机上批准是否继续运行耗时测试。三个入口看到的是同一任务，而不是三份互不相干的聊天。
多端产品应复用任务、事件、权限和终态，再按场景设计不同界面。入口是用户在哪儿看和操作，运行环境是代码与工具真正在哪台机器执行；两者必须分开。
能在手机上看到本地测试进度，不等于手机获得了项目文件或本机凭证。跨端同步状态，不应顺便复制能力。
稳定的双向协议把 Harness 的线程、事件和审批能力暴露给客户端。不同入口复用执行逻辑，同时针对终端效率、IDE Diff、桌面并行和 Web 长任务设计界面。
多个端怎样看到同一个任务事实？
任务线程（Thread）保存长期任务，工作回合（Turn）保存一次用户驱动的工作单元，事件项（Item）保存按序发生的消息、工具、审批与结果。客户端只是渲染这些事实。
- 事件项 01（Item）用户消息
- 事件项 02（Item）搜索工具调用
- 事件项 03（Item）搜索结果
- 事件项 04（Item）写入审批
- 事件项 05（Item）改动对比
- 事件项 06（Item）测试结果
- 客户端 A（Client A）
收到事件 128 后断线
- 运行环境（Runtime）
任务继续等待审批，没有重复启动
- 客户端 B（Client B）
提交事件项 04 的批准结果
- 任务服务（App Server）
持久化事件 129–135 与终态
- 客户端 A（Client A）
用游标 cursor=128 补取缺失事件并恢复
恢复结果：两个客户端看到同一工作回合（Turn）；工具没有重复执行。
核心语义一致，入口有意分工
CLI 强调快速输入和脚本组合，IDE 强调代码、Diff 和错误位置，桌面端适合监督多个任务，移动端适合轻量审批和查看结果。
同一 Item 在各端可以采用不同展示，但 completed、failed、awaiting_approval 等状态语义必须一致。
官方事实查看这一结论的依据与边界＋
OpenAI 将 App Server 公开为让不同客户端复用 Codex Harness 能力的接口案例。
OPUnlocking the Codex harness: App Server官方工程文章 · 核验 2026-07-14Runtime 决定任务真正在哪里发生
任务路由要检查数据位置、依赖、网络、时长、算力和合规。公司 VPN 内资料无法被任意云 Runtime 访问，本地依赖也不会因为线程可见而自动迁移。
身份、配置、历史、凭证和授权要分别定义同步边界。便利的跨端可见性不能默认为跨设备复制敏感能力。
官方事实查看这一结论的依据与边界＋
OpenAI Codex 文档呈现 Codex 的具体产品入口与使用方式；这些入口属于 Codex 产品形态。
OPCodex CLI documentation官方文档 · 核验 2026-07-14一次登录超时修复的三个入口
桌面端接收任务并显示搜索过程；IDE 打开待改的两个文件，让用户逐行检查 Diff；移动端只展示“准备运行相关测试”的影响、预计时长和允许或拒绝。
项目文件和命令始终留在本地运行环境。手机同步的是审批事件和测试摘要，不下载源码，也不继承本机权限。
本站推演查看这一结论的依据与边界＋
本站的多端能力矩阵和 Runtime 路由规则是通用产品推演，不代表 OpenAI 内部完整架构。
OPUnlocking the Codex harness: App Server官方工程文章 · 核验 2026-07-14端能力协商与优雅降级
不同端不会永远同步升级。旧版移动端遇到新事件时可以忽略未知字段，不支持 Diff 的端可以退回文件级摘要；但完成、失败和等待批准的语义必须一致。
把这些约定写进验收清单，多端才算同一个产品：新增事件类型时旧端不崩溃；任何端展示的终态都与服务端事实一致；敏感数据只在授权的 Runtime 内流动，跨端同步的是状态，不附带能力。
本站推演查看这一结论的依据与边界＋
登录超时修复的三端协作情节为本站教学案例，用于演示核心状态复用与端侧分工，不来自 OpenAI 的产品文档。
OPUnlocking the Codex harness: App Server官方工程文章 · 核验 2026-07-14有术语没听懂？在这里用人话再看一遍4 个词＋
- Surface
- 用户与 Agent 协作的产品入口，例如 CLI、IDE、桌面、Web 或移动端。
- Runtime
- 工具和任务实际执行的计算环境，可以位于本地、企业网络或云端。
- 任务路由
- 根据数据、依赖、资源和风险把任务分配到合适 Runtime。
- 端能力协商
- 客户端与服务端声明各自支持的事件、控制和展示能力。
本章依据与证据边界1 条补充结论 · 7 份原始材料＋
下面补充本章的其他依据，并说明每份材料能证明什么、不能证明什么。
- [5]
旧客户端忽略未知字段、终态语义跨端一致等验收条目是本站教学推演。
本站推演OPCodex CLI documentation官方文档 · 核验 2026-07-14
查看全部一手材料与源码证据 7 条
这份材料说明 Codex App Server 如何以双向 JSON-RPC/JSONL 协议把同一 Harness 暴露给 CLI、IDE、桌面与 Web 客户端。它定义 Thread、Turn、Item 及流式事件、审批暂停、持久化和重连语义，是课程讲解 Agent 客户端协议与多端复用的直接实现依据。
证据边界：官方文档不能单独证明未公开内部实现、长期可靠性或真实用户收益。官方产品实现 · 核验 2026-07-16Grok Build is Now Open SourcexAIxAI 官方说明本次公开的是 Grok Build 编码 Agent 与终端 TUI，并明确列出 Agent Loop、代码交互工具、终端 UI，以及 Skills、Plugins、Hooks、MCP Servers、Subagents 等扩展系统。它让课程可以用真实实现核对 Harness 责任，而不是让产品经理通读源码。
证据边界：官方公告没有说明 Grok Build 的服务端实现，也不能证明托管产品的完整架构、真实任务成功率或这些设计适用于所有 Agent。固定提交源码 · 核验 2026-07-23Grok Build repository map（固定提交）xAI固定提交 README 将公开范围界定为 grok CLI/TUI 与 Agent Runtime 的 Rust 源码快照，并标出 TUI、Agent Runtime、工具、Workspace、MCP、Sandbox 等主要 crate；仓库由 xAI 内部 monorepo 定期同步且不接受外部贡献。
证据边界：这个快照不是 Grok Build 服务端源码，也不能代表后续线上版本、内部 monorepo 的全部模块或每项功能的运行效果。固定提交源码 · 核验 2026-07-23Hermes Agent repository and architecture guidanceNous Research这份固定提交的仓库说明展示 Hermes Agent 如何用同一个窄腰核心服务 CLI、TUI、桌面与消息入口，并优先通过 Skills、Plugins 与 MCP 扩展。它还把 Prompt Cache、核心工具数量和扩展 Footprint 当成真实架构约束，说明工具越多并不自动更强。
证据边界：固定提交只能证明该版本的公开实现，不能代表现行私有产品、真实任务质量或行业统一架构。官方产品实现 · 核验 2026-07-23The evolution of agentic surfaces: building with Claude Managed AgentsClaude by Anthropic这份官方材料定义 Agent、Environment 与 Session 三类生产资源，并说明 Brain/Hands 分离、持久事件、凭证代理、可恢复状态和自托管执行环境。
证据边界：官方自测延迟和客户案例不能直接外推为所有 Agent 产品的 ROI。官方产品实现 · 核验 2026-07-14Hermes Agent SessionsNous Research当前文档说明 Hermes 将完整消息与工具历史保存在 SQLite，会话可恢复和跨端检索，但恢复历史不等于把所有旧字节持续塞回模型上下文。
证据边界：持久会话不自动保证恢复无副作用，也不是隐私删除或长期语义记忆。官方产品实现 · 核验 2026-07-23Use Claude Code DesktopClaude by Anthropic官方桌面端文档说明 Code tab 与 CLI 使用同一底层引擎，并明确展示权限模式、可中断会话、可视 Diff 与行级评论、Preview 自动验证、终端、CI 状态和 PR 监控等用户可见流程。
证据边界：桌面端产品文档只能证明当前可见功能与交互合同，不能证明闭源客户端内部模块、线上默认效果或所有版本行为。