资讯动态

Firstmate 与 Codex Desktop 可见线程协调指南:宿主工具编排、状态返回通道与后端边界

发布时间:2026/9/29 8:49:20 来源:尧图企业网站定制
【免费下载链接】firstmateTalk to one agent. Ship with a crew.项目地址https://gitcode.com/gh_mirrors/fi/firstmate点击查看免费下载导读本文基于 Firstmate 仓库中的 agent-only playbookfirstmate-codexapp系统讲解如何在 Firstmate 的舰队工作流中协调Codex Desktop 可见线程何时使用、如何创建与投递指令、如何通过state/id.status状态文件建立可验证的返回通道、如何观察协调与归档线程以及为什么 Codex App 至今仍是受阻的后端边界而非可选择的运行时后端。读完本文你将掌握一套可直接落地的宿主工具编排流程并能准确区分可见伴随线程与完整 Firstmate 后端的技术边界。一、角色定位Codex Desktop 线程是伴随工作流不是后端Firstmate 对 Codex App 的定位有一句非常明确的总纲见 SKILL.md 与 docs/codex-app-backend.mdCodex Desktop 可见线程是伴随宿主工具工作流companion host-tool workflows不是可选择的 Firstmate 运行时后端。当前唯一受支持的工作形态是Desktop 宿主工具编排host-tool choreography即由运行在 Codex Desktop 内的 Firstmate 会话直接调用create_thread、read_thread、send_message_to_thread等宿主工具外加一条显式的状态文件返回通道检查status-file return-channel check即线程向 Firstmate 的state/id.status追加生命周期行并由 Firstmate 侧验证该写入真实发生。这不是FM_BACKENDcodex-app这种后端取值。代码层面对此有双重铁证bin/fm-backend.sh 头注释明确写着 Codex App is intentionally not in the known set yet且第 70 行的已知后端集合与可 spawn 集合都是FM_BACKEND_KNOWNtmux herdr zellij orca cmux、FM_BACKEND_SPAWNtmux herdr zellij orca cmuxcodex-app刻意缺席docs/configuration.md 配置文档同样声明 codex-appis not an accepted runtime backend yet。为什么不能把一个能写状态文件的手工线程台账当作后端因为手工线程台账不是后端——Firstmate 的后端契约要求完整的生命周期控制能力而不仅仅是记录存在性。这一点在下一节展开。二、验收契约未来 Codex App 后端必须满足的五项条件docs/codex-app-backend.md 给出了未来 Codex App 后端必须满足的验收契约与终端型适配器terminal-backed adapters完全一致创建任务端点并返回一个持久的线程 id发送初始指令以及后续操作者消息到该端点读取足够的实时状态或有界 transcript 以监督任务归档、终止或以其他方式停止该精确端点让线程追加Firstmate 正常的生命周期行到state/id.status。其中第 5 条——状态返回通道是强制的mandatory。文档原话是一个无法向 Firstmate 正常生命周期汇报的可见线程不是一个完整的后端A visible thread that cannot report into Firstmates normal lifecycle is not a complete backend。三、当前阻塞点缺少受支持的 shell 可调用桥接为什么 Codex App 至今仍处于受阻边界状态docs/codex-app-backend.md 给出了非常具体的技术归因Firstmate 的后端脚本是shell 入口点可以径直调用 tmux、Herdr、Zellij、Orca、cmux而Codex Desktop 宿主工具只对 Desktop 会话conversation可用不对任意 Firstmate 子进程可用因此缺失的组件是一个Codex Desktop 支持的、可被 shell 调用的传输通道而不是另一个本地台账。文档还记录了一个真实的探测结论codex app-server --stdio确实暴露了部分有用的 JSON-RPC 片段如线程启动、turn 启动、线程读取、线程归档一个单进程探针甚至能创建并归档一条线程记录但没有任何受支持的桥接能让 Firstmate 在同一可见 Desktop 端点上完整地创建、继续、读取并归档其全生命周期。原始 Desktop 控制 socket 代理同样不是受支持传输。这些零散片段并不足以把codex-app加入已知后端注册表或可 spawn 后端注册表——这也正是 bin/fm-backend.sh 中 codex-app remains deliberately absent 的工程原因。四、所需桥接与未来落地路径docs/codex-app-backend.md 规定了桥接的启用条件与语义。当 Codex Desktop 暴露以下任一受支持接口时实现才可开始一个封装 create/send/read/archive 宿主工具操作的CLI 包装器一个有稳定帧协议的、文档化的JSON-RPC 或 MCP 传输或一个受维护的辅助程序能说该受支持传输并向 shell 适配器返回纯 JSON。桥接必须提供如下语义create: task id, worktree request, initial instructions - thread id, cwd, state send: thread id, text - accepted or rejected read: thread id, bounded cursor - transcript and live state archive: thread id - archived or stopped return: thread appends state/id.status lifecycle lines一旦桥接可用Firstmate 的计划是新增真正的bin/backends/codex-app.sh持久化backendcodex-app与codex_app_thread_id并让 spawn、send、peek、watch、cleanup 全部走共享调度器shared dispatcher。分阶段推出的顺序也很明确ship 与 scout 任务先行在 create、send、read、status return、archive 全部通过正常后端调度器验证之前Secondmate 支持保持范围外。五、宿主工具清单与预检流程使用本 playbook 前必须完成四项预检见 SKILL.md确认会话运行在 Codex Desktop 内且宿主工具已暴露。按精确名称检索以下工具create_thread、list_threads、read_thread、send_message_to_thread、archive、set_thread_archived。注意当前没有任何宿主工具能为 agent 创建 Codex App 项目因此目标仓库必须已由人类在 Desktop 中保存为项目。确认目标仓库已保存为 Codex Desktop 项目。由于缺少创建项目的宿主工具人类必须先在 Desktop 中添加项目新建线程才能可靠地落到该项目下。不要为仓库工作创建无项目线程。若项目不存在应停下并要求添加项目或改用普通 Firstmate 后端。判定这是真正的 Firstmate 托管任务还是可见伴随线程。真正的任务需要任务 id、隔离的 worktree 或 Desktop 自有的 cwd、分支计划以及可写的state/id.status路径。这条无项目线程禁止约束在 docs/codex-app-backend.md 的验证记录中同样成立可复用的 Desktop 宿主工具 smoke 第一步就是list a saved project。六、创建与投递必须用宿主工具禁止 shell 模仿创建可见线程时必须使用 Desktop 宿主工具而不是 shell 模仿use the Desktop host tool, not shell imitation。创建后先让 worker 报告初始环境指令文本如下pwd git rev-parse --show-toplevel git branch --show-current git log --oneline --max-count3对可写仓库工作应指示 worker 使用 Codex 创建的当前目录Desktop-owned cwd不要让它cd进已保存的项目 checkout 去做编辑、提交、no-mistakes、push 或 PR 工作——这既是隔离要求也直接对应 AGENTS.md 中项目工作必须从隔离的 disposable worktree 开始绝不在主 checkout 中的 spawn 断言。后续跟进指令一律通过send_message_to_thread发送。若用户直接在可见线程里输入内容应将其视为权威输入并通过read_thread协调reconcile而非撤销。七、状态返回通道可验证的汇报要求Desktop 自有的 Codex 线程只有在两种条件同时成立时才能向 Firstmate 状态文件追加内容提示词给出绝对路径且 Desktop 权限上下文可以写入该 checkout。因此 SKILL.md 强调状态写入是经验证的返回通道要求verified return-channel requirement而不是默认成立的事实。对于 Firstmate 托管任务必须包含显式状态指令Append supervisor-visible status lines to absolute-firstmate-home/state/task-id.status. Use only these prefixes for status changes: working:, needs-decision:, blocked:, paused:, done:, failed:. Follow the task briefs status-reporting rule for declaring and resolving waits; bin/fm-brief.sh owns that rule. Before doing substantive work, append working: Codex Desktop thread started.注意前缀白名单working:/needs-decision:/blocked:/paused:/done:/failed:正是 Firstmate 状态协议的规范集合。底层语义在 bin/fm-brief.sh 中有精确定义paused:用于主动等待预计会自行消除的外部条件并可用until YYYY-MM-DDTHH:MMZ标注消除时间而blocked:用于卡住且需要 Firstmate 介入working:只是稀疏的、监督者可行动的事件禁止仅仅用它确认收到消息或宣布已开始。Firstmate 状态协议还规定被打开的决策/阻塞项只有在携带其精确 key 的resolved行落地后才会关闭后续的done:或working:行不能关闭它。在将线程视为已受监督之前必须验证返回通道read_thread显示 worker 确实尝试了状态写入本地state/task-id.status文件包含预期行若可用transcript 包含该状态文件的 file-change 条目。若线程无法写入状态文件则只能保留为可见伴随线程不得宣称它是完整 Firstmate 后端。八、观察与协调以 read_thread 为事实来源观察阶段的规则非常克制用read_thread获取线程事实thread truthlist_threads只用于查找或恢复可见线程 id不能替代阅读 transcript。Firstmate 协调reconciliation时应优先使用具体证据而非转述大段对话线程 id 与项目当前 Desktop 自有 cwd分支名最近一个有意义的线程状态最新状态文件行存在 PR 时的 PR URL禁止把冗长 transcript 重复进 Firstmate 文档或 PR 正文只需概括宿主工具调用、状态文件结果与归档结果。向船长captain汇报 Desktop 线程结果时必须把状态前缀与返回通道证据翻译成船长用语——这条翻译契约由 AGENTS.md 第 9 节Escalation and captain etiquette管辖谈结果而非机制不得把working:/blocked:/done:等内部标签、任务 id、status 文件路径原样抛给船长而要转成正在处理/等待批准/已完成这类具体结果与下一步决策。九、归档通过宿主工具完成归档同样走 Desktop 宿主工具暴露的是archive原语就用archive暴露的是工具名就用set_thread_archived(threadIdid, archivedtrue)。需要理解归档的语义边界归档可能把线程从正常的 sidebar/项目视图移除但不应抹掉 transcript 或已落地的成果it should not erase the transcript or landed work。这在实际验证中也有对应记录归档后读取已归档 transcript状态为notLoaded但内容仍在。对伴随线程归档线程并报告持久成果落在哪里若存在真正的 Firstmate 任务记录则清理决策留给正常 Firstmate 任务流不由本 skill 决定。十、失败信号与处置清单SKILL.md 给出五类典型失败及其处置失败信号处置缺少 Desktop 项目请人类在 Codex Desktop 中添加目标项目或改用普通后端缺少宿主工具禁止用 shell 文件模拟宿主工具改用终端后端状态文件未更新在返回通道被证实之前将线程视为未受监督worker 编辑已保存的项目 checkout 而非其 Desktop cwd停下先决定是否挽救分支再继续生产环境codex-app后端请求阅读 docs/codex-app-backend.md不得自造本地适配器其中禁止用 shell 文件模拟宿主工具与 AGENTS.md 的验证纪律一脉相承已验证 harness 集合之外的一切都要 fail-closed缺失依赖、认证失败、不支持后端、版本拒绝都是阻塞项绝不静默换后端重试。十一、实证记录Desktop 宿主工具 smokeverification/runtime-backends.md 的 Codex App host tools 一节保存了可复用的实测记录2026-07-06 针对 Codex Desktop bundle 26.623.101652build 4674bundle idcom.openai.codex执行的宿主工具 smoke。本地路径与任务级 id 刻意不留存在该文档中。smoke 覆盖的宿主工具序列为列出已保存项目创建 Desktop 自有的 worktree 线程在线程活动期间与完成后恢复并读取线程验证线程追加了 Firstmate 状态行并写入了报告向同一线程发送跟进读取已完成的跟进归档该精确线程读取归档后的 transcript状态notLoaded。记录给出的已验证保证是当提示词提供授权的绝对路径时Desktop 自有线程可以写入 Firstmate 生命周期文件且 create/send/read/archive 在 Desktop 宿主工具层都能工作。未验证的保证仍是不存在受支持的 shell 可调用桥接让 Firstmate 对同一可见 Desktop 端点执行这些操作——app-server 的部分方法与原始 socket 实验均不满足该桥接契约。十二、边界速查什么可以、什么不可以可以不可以用宿主工具创建/读取/发送/归档可见 Desktop 线程把codex-app当作FM_BACKEND取值或已知后端线程在获授权限下追加state/id.status生命周期行在没有返回通道证据时宣称线程已受监督把线程当作伴随工作流配合 Firstmate 使用用 shell 文件模拟宿主工具或自造本地适配器在可见线程中为可写仓库工作使用 Desktop 自有 cwd让 workercd进已保存项目 checkout 做提交/PR 工作用list_threads找回线程 id用list_threads替代read_thread作为事实来源配置层面同样适用此边界docs/configuration.md 中FM_BACKEND的说明明确指出 tmux/herdr/zellij/orca/cmux 支持 ship/scout spawn而 codex-app is not accepted。结语firstmate-codexapp这份 playbook 的价值在于把想要让 Codex Desktop 参与 Firstmate 工作这一模糊诉求收敛为一条纪律严明、可验证、不越界的操作路径可见线程永远只是伴随工作流宿主工具编排 状态文件返回通道验证是当前唯一受支持形态而真正的codex-app后端必须在 shell 可调用桥接出现、并通过共享调度器的完整生命周期验收之后才会进入后端注册表。对实践者而言记住三句话即可创建走宿主工具汇报走状态文件且必须验证边界归docs/codex-app-backend.md管辖。赞分享【免费下载链接】firstmateTalk to one agent. Ship with a crew.项目地址https://gitcode.com/gh_mirrors/fi/firstmate点击查看免费下载相关推荐DSH Desktop 架构解析薄 Electron 宿主、Generation 生命周期与双发行通道协议DSH Desktop 架构解析薄 Electron 宿主、Generation 生命周期与双发行通道协议 导读本文以 docs/architecture.人工智能AI 应用AI Agent桌面应用插件系统DeepSeekdsh-pluginFirstmate 的 Codex App 后端边界为什么它尚不可选以及成为正式运行时后端所需的桥接契约Firstmate 的 Codex App 后端边界为什么它尚不可选以及成为正式运行时后端所需的桥接契约 Codex AppCodex Desktop 宿OpenHuman scheduler_gate 深度解析:基于宿主状态为后台 AI 工作构建协同调度闸门OpenHuman scheduler_gate 深度解析:基于宿主状态为后台 AI 工作构建协同调度闸门 本文以 scheduler_gate 模块 READ人工智能AI 应用本地部署AI Agent交互助手深度研究上一篇PowerShell 跨平台快速上手10分钟装好并写出第一个自动化脚本下一篇为什么选择AIRS科学智能研究者不可错过的开源工具集创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑