[RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198

Owner: Dev

目标

让基于不同运行时的 Agent 能在 FlyBot 中相互对话、追问、交接任务和返回结果，同时保留各自的运行环境、上下文和权限边界。

先验证 同一个 FlyBot 房间内，Bot A（DSH）与 Bot B（OpenCode）协作，再评估 openJiuwen。基线是同房间、同任务的 Bot A（DSH）+ Bot B（DSH）。希望验证的是“一起完成一个可验收的任务”，不只是两个接口互相发一句 hello。

2026-10-17 补充：同房间协作是首期验收要求；只做 Bot Social 私聊转发或外部 DM bridge 不满足这项验收。

本 issue 先讨论目标、需求和两种方案，不代表实现方案已定，也不授权开启生产访问或付费测试。

当前基础与缺口（2026-10-17 核对）

• FlyBot 本地 Bot 当前是 DSH Session，执行仍走 DSH agent loop；tree/social 是其插件。增加外部 Agent 不等于把 OpenCode 嵌入为第二套 FlyBot 内核运行时。
• Bot Social 已提供 REST、Bot 侧 MCP 和消息/授权机制，是跨运行时接入的基础；其 roadmap 中 A2A interop 仍未完成。已有 MCP 接口不等于已经实现标准 A2A。
• OpenCode 官方提供 headless HTTP server、SDK、session/message/event/abort 等接口，具备做外部适配器的入口；本次没有执行互通实验。
• Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149 的责任人/任务镜像、[Team] Recover task handoffs without duplicate work #55 恢复去重、[Team] Bound agent loops and resource consumption #56 预算、[Team] Add a human-readable authorization and task audit trail #57 审计和 [Team] Verify the real two-human team pilot end to end #58 双人试点仍是相关工作。本 issue 增加“异构运行时”维度，不另起一套团队权限或任务状态机，不提前宣布 team-mode gate 通过。

首个用户场景与对照

在同一 FlyBot 房间内，先跑 DSH + DSH 基线，再将 Bot B 换成 OpenCode，任务及验收条件不变：

1. 人给 Bot A 一个隔离 fixture 中的小代码修改任务，并指定独立测试和最终验收条件。
2. Bot A 向 Bot B 委派；fixture 中刻意保留一个必须澄清的需求，Bot B 必须在该房间追问，不能自行猜测。
3. Bot A 补充答案；Bot B 在隔离工作区实现，返回变更与实际测试证据。
4. Bot A 独立检查结果、运行或核对独立验收测试；不能仅复述 Bot B 的“已完成”。
5. 人看到完整归属、追问、审批、结果与证据，并明确接受或拒绝。

这是待实现、待验证的验收设计，不是已执行结果。使用合成输入和隔离 fixture；不修改真实项目、不读取私人数据。真实 API 试跑前另行明确模型与预算。

架构图：现有基础与拟议增量（2026-10-18）

查看 / 下载 SVG 源图

本图是源码对照与设计示意，不是论文原图。上方为已核实的 DSH/Cordis 与 FlyBot 基础；同房间跨运行时薄桥接、独立执行域和完整生命周期验收属于拟议增量，尚未通过端到端验收。图中 ctx.subagents 复用是优先评估方向，仍须核验常驻会话、追问、审批和取消能力；不表示现有 ACP 已满足这些要求。运行时、工作目录和安全沙箱分别定义，文件、进程、网络与凭据边界分别验证。

源码基线：DSH 0.2.0-rc.2 / Cordis、SandboxMode、ACP 后端、FlyBot hooks、工作目录规则。

同房间接入的共同基础（拟议）

当前 core/src/host/groups.js 的 groupSessionFor（148–165 行）通过现有 runtime 创建、配置群会话；runRound（约 337–370 行）按房间成员调度，再调用 roomTurn。本次读取 blob 为 57b0f8d7bcfb327c2c712b2a834b4d164ea47c17，不是已经存在通用多运行时接口的证据。

建议讨论一个房间参与者驱动接口 ParticipantDriver：

• 候选能力：open / runTurn / cancel / snapshot / decidePermission，方法名和数据类型仍待设计。
• 用 runtime.kind = dsh | opencode 选择后端；显式维护 roomId + botId + taskId → runtimeSession 的关联和持久化，避免串会话。
• 房间层负责成员资格、消息归属、可见范围、顺序与轮次、任务验收；driver 负责后端会话、执行事件、权限请求、取消及恢复。
• OpenCode 可以保持独立进程；此接口不要求把它的内核嵌入 DSH，也不修改 DSH 内部实现。

这层是同房间试点的共同基础。以下 A/B 比较主要决定外部接入/传输怎么做，不能用选择一种协议代替同房间调度与权限接缝。

必须满足的需求

• 身份与授权：区分 human owner、Bot、运行时和服务身份；显示名/消息中的“主人同意了”不能授予权限。按 Bot/收件方/任务范围默认拒绝，投递、重试、恢复和执行时重新校验。插件也不能绕过。
• 上下文隔离：各自保留私有历史、记忆、工具和工作目录；只共享显式选择的任务输入/产物。对端文本是未信任数据，不能升级成系统指令。传输身份不能自动继承本机文件、Shell 或外发权限。
• 审批：绑定实际批准人、动作、内容版本、接收方和范围；内容或对象改变、撤销、离群后失效。发送许可与远端工具执行许可分别判断，不能把 A2A 状态或普通聊天回复当作人工批准。
• 会话与任务：明确 Bot Social conversation、FlyBot task、OpenCode session 的映射；追问能回到同一任务，平行任务不串上下文。统一展示运行中、待输入、待批准、结果待验收、失败、取消及状态不确定，保留原始状态供诊断。
• 可靠性与停止：重复投递不重复执行副作用；持久化关联 ID、去重键与进度。断线/重启后先对账再恢复；取消要区分已请求、已确认和无法确认，迟到事件不能复活已取消任务。不承诺撤销已经发生的外部副作用。
• 资源边界：限制往返轮数、并发、时间、模型请求数和费用；重启不能重置预算。令牌/费用不可观测时明确标记未知，不能按零处理。发现互相唤醒的循环须暂停并可由人处理。
• 可观察性：能沿任务查看发送者、接收者、运行时、状态变化、审批和结果证据；日志脱敏，不记录密钥或默认复制全部私有对话。离线、拒绝、不支持的能力必须显式呈现。

两个可讨论的实现方案

A. 直接运行时适配 + 按需接入 Bot Social

首期由同房间 ParticipantDriver 对接 OpenCode server/SDK，保持 DSH driver 的基线行为。需要跨 home/外部 Bot 时，再复用现有 FlyBot social 路径，增加 Bot Social 消息与本地任务的映射。MCP 可作为主动发消息的工具入口，但不会自动提供群调度、收件唤醒、恢复或任务映射。

优点

• 复用已有身份、好友/房间、审批和 UI，首个试点改动较集中。
• 可以先验证跨运行时对话的产品价值与边界，不必先做完整通用协议栈。
• OpenCode 保持独立进程；不要求修改 DSH 或 OpenCode 内核。

代价/风险

• 与 Bot Social 的消息及任务约定耦合，未来每种运行时仍需适配器。
• 需要自行定义稳定、版本化的任务/事件映射；不能仅包装 prompt API。
• 跨层审批、取消与重试可能出现两套状态，需要明确唯一责任方。
• 接 openJiuwen 时可复用契约和测试，但不能直接假设接口兼容。

B. A2A 桥接层 + 各运行时适配器

在同房间参与者驱动之下，通过 A2A 桥接端点连接 OpenCode；外部接入也沿用标准 A2A 的 Agent Card、Message、Task、Artifact 等语义。运行时适配器仍负责映射本地 session/工具/取消，房间成员及发言调度仍由 FlyBot 负责。后续 openJiuwen 可评估接入同一边界。

优点

• 面向多个运行时的发现、任务与产物交换更统一，有机会复用标准 SDK 和互操作测试。
• 运行时替换与扩展更清晰，不必让所有对端理解 FlyBot 私有消息格式。

代价/风险

• 首期多一层服务与协议映射，要固定版本、传输绑定、支持的能力和兼容性策略，开发及测试面更大。
• 标准不会替我们实现人类审批、私有记忆隔离、预算或真实工具取消；这些仍要落在各端。
• A2A 的完成/取消语义与本地状态不完全相同，必须避免把“收到取消请求”当作“工作已停止”。
• 仍需 OpenCode、DSH、openJiuwen 的运行时 adapter；采用标准不等于免适配或已经互通。

初步建议（待讨论）：先用 A 的同房间 driver 完成一个受限试点，同时把消息、任务、权限及事件契约独立出来；若需要对接第三方 A2A Agent，或第二个运行时接入暴露重复工作，再按实测成本选择 B。也可以直接选 B，但应先限定一个协议版本、一种绑定和最小能力子集，避免首期变成通用平台重构。

“插件化”是组织适配代码的一种方式，不是跨运行时通信的必要条件；独立桥接进程同样可行。关键是明确且可验证的协议与权限边界。

实现进度与下一步 TODO（2026-10-18 Asia/Shanghai 刷新）

以下完成项只表示已合并的限定切片；本次核对了 PR 状态及当前源码，未重新运行测试。离线 fixture、主机任务 API、真实运行时接通和同房间用户验收分别记录。同房间 DSH + DSH / DSH + OpenCode 验收尚未完成。

已合并的基础

• 初版 OpenCode 试点契约：Specify the OpenCode pilot contract #199，合并提交 a63309f7069e73c77948d5fa51ee1dc68b21563b。是设计文档，不是已实现 adapter；其跨 owner 私聊、文本分析、no-tools 范围需要与本 issue 的同房间代码任务重新对齐。
• 离线确定性协作 harness：Build the offline cross-runtime collaboration harness #200 / Add the offline cross-runtime collaboration harness #201，合并提交 4470c1ef8bfcf0f8dab4f5d422e633a20ca144a5。仅脚本化 mock；没有接通真实 FlyBot 房间、OpenCode 或模型。
• requester 可取消尚未验收的结果：Allow requesters to cancel unaccepted task results #202 / Allow requesters to cancel unaccepted task results #203，合并提交 dd2dea4b1b3c89cb91369e0b25e772a6cfa07daf。记录任务处置，不证明外部执行已停止。
• requester 控制的追问/回答等待：Track requester-controlled task clarification waits #207 / Track requester-controlled task input waits #212，合并提交 175328de750074a7abee73310c5140f88d7f385c。已提供持久化输入等待、当前问题绑定和独立审批等待；不自动投递模型请求，不授予远端执行权限。

开发中的独立 PR（待 review / 合并）

以下均未计入“已合并的基础”，也未勾选本 issue 的完整验收：

• Extract the DSH room participant driver #216 / Extract the DSH room participant driver #218：抽取薄的 DSH 房间参与者执行边界，保留调度、会话链接和权限语义，并对齐同房间与历史 DM 范围。提交 39346e8147a3e3fb371234c96063e3a5f3c72b5a 全量 1,082 测试及 42 步 mock smoke 通过；CI tests-ok 通过。
• Exercise the same-room collaboration acceptance fixture without a model #219 / Exercise the same-room collaboration acceptance fixture #220：通过实际房间 relay 的确定性代码任务 fixture，覆盖委派、房间内追问、后台完成回帖、独立执行测试、模拟 requester 接受/拒绝；包括“Writer 自测通过但独立验证失败”。提交 ada52abb0dc896205e088c5af5a8fe36f3977730 全量 1,077 测试通过；CI tests-ok 通过。会话事件与 requester 操作由脚本驱动，不能记作真实模型或人工验收。
• Record runtime reuse and probe the offline isolation deployment boundary #221 / Audit runtime reuse and probe the offline isolation boundary #223：核对固定 DSH 版本的 Cordis/subagent/sandbox 复用范围，补充离线部署边界及显式 opt-in Docker 探测。提交 cf73b0dfa96cf2701e3283cf037b5cd8efadec78 全量 1,079 测试、CI tests-ok 和真实合成容器探测通过；检查自身写入、私有标记/根目录访问拒绝、无网络、干净环境和固定产物交接。资源值仅核验配置；未接通真实 DSH/OpenCode、在线凭据或执行审批，不能声称完成整个隔离门槛。

三个 PR 的描述均列明准确 tip、运行命令、未测边界和作者侧证据；独立 review 仍待安排。

P0：先收窄设计，复用现有能力

• 对齐本 issue、docs/interop/opencode-pilot.md 和离线用例的首期范围：以同房间协作为验收；跨 owner Bot Social 私聊作为已有独立测试切片保留。不能把私聊 mock 完成勾成同房间集成完成，也不为本试点改变同 owner 交友限制或跨 owner 授权门槛。
• 明确复用清单：Cordis 已有 context/service、依赖注入、事件和 effect/disposer 生命周期；FlyBot 已有房间调度、bot.send、grants、审批、transport 和任务状态。新增内容只补房间参与者到外部执行的接缝，不再造插件框架、任务状态机或第二套调度器。
• 在 FlyBot 当前测试依赖 DSH 0.2.0-rc.2 上核验适配能力。DSH 已有 ctx.subagents 和 ACP/Codex/Claude Code/DSH SDK provider；先评估可复用范围，再确定 ParticipantDriver 是否仅为薄的房间接口。现有 ACP 是每次新进程的一次性委派，不提供长期会话续接、中间对话/工具轨迹和人工权限 UI，不能直接视为已满足房间 Bot 的多轮澄清与审批需求。
• 固定隔离部署契约：分别记录 Bot 身份、runtime/session、工作目录、OS 执行边界、网络和凭据权限。Cordis context/realm、独立 Session、独立进程或不同目录本身都不等于完整安全沙箱。为试点的两个执行方明确独立可写工作区与实际强制边界；若使用容器/VM 或其他后端，注明选型与未覆盖风险。DSH 的 SandboxMode 只约束文件系统效果，网络/进程可见性不能据此宣称已隔离；拒绝把 partial enforcement 当作 full。
• 规定受控产物交接：双方仅交换显式输入、变更/产物引用和测试证据，不共享私有历史、凭据或默认共用可写目录；审核方在独立工作区验收同一产物。当前 FlyBot 房间 workDir 可被成员共用，不能据此声称每个 Bot 已有独立沙箱。

P1：实现最薄的同房间接入

• 在现有 FlyBot hooks/types 和房间调度边界确定最小执行接口及 capability 探测；不修改 DSH 内核。保留现有 DSH 路径建立同房间 DSH + DSH 基线，再替换 Bot B 为 OpenCode。
• 固定 OpenCode server/SDK 版本及实际 API 契约，接通独立进程/会话；持久化 room / bot / task → runtime session 关联。明确进程由谁启动、终止和回收；现有 provider 不支持的能力必须显式阻塞。
• 将真实执行观察接入既有任务/审批机制：审批绑定主体、动作、输入版本和接收方；发送批准与工具执行批准各自校验。追问绑定当前 task/question，结果待验收与人类接受分开。
• 实现并验证重启对账、重复/乱序事件去重、取消 generation 和迟到事件处理；分别展示取消已请求、后端已确认停止、状态不确定。插件卸载、房间关闭/离开和审批撤销应停止新调度并清理其拥有的资源，不能复活任务或盲目重试副作用。
• 在实际执行入口落实并发、往返轮数、时间、请求及费用边界；重启不能重置预算。缺失 usage 标记 unknown；不能将 mock 的零费用或一次性 provider 的能力当作真实运行时预算证明。

P2：按同一场景验收与做性能基线

• 先通过真实房间入口的确定性测试：委派 → 必须澄清 → 补充需求 → 隔离修改 → 测试证据 → Bot A 独立检查 → 人最终接受/拒绝；并行任务不能串会话。
• 验证两侧隔离边界：越界读写、对方私有标记/凭据、未批准网络或工具访问、资源竞争；按选定后端说明哪些被实际阻止、哪些不覆盖。覆盖拒绝/撤销审批、冒充 owner、关闭房间、重启与迟到回调。
• 在模型与预算获准后，进行同房间 DSH + DSH 对照 DSH + OpenCode 的小规模真实试点。对齐模型、fixture、资源和权限；记录独立验收质量、端到端耗时、token/usage、排队/适配/工具/模型耗时及失败、重试、取消样本。未知项明示；尚无实测性能结论。
• 核对每项验收的当前提交、命令、日志和人工结论后，再决定是否扩展 A2A/openJiuwen；协议选择不替代房间权限、隔离与任务验收。

能力核对来源：

• FlyBot 当前测试依赖、插件入口、现有扩展面、工作目录规则。
• DSH 对应版本提交 639ed015397290b3745d163aafe02ffee4aa3f84：Cordis、subagent 扩展面、ACP 后端限制、sandbox 保证范围。

验收与证据

• 在同一 FlyBot 房间完成 DSH + DSH 基线及 DSH + OpenCode 试验，包含委派 → 必须澄清 → 补充需求 → 隔离修改 → 测试证据 → Bot A 独立检查 → 人最终验收。仅回复成功不能计为任务成功。

• 先完成不消耗真实 token 的确定性测试：双向消息、同任务追问、并行隔离、结果待验收。

• 覆盖拒绝/撤销审批、第三方冒充 owner、私有标记不泄漏、离线重连、重复/乱序/迟到事件、重启和取消；终止/离开的房间不得继续触发工作。

• 重复投递及重连不重复产生副作用；无法确认的结果进入 uncertain，不盲目重试。

• 审批被拒绝或撤销后，禁止对应新执行/外发；停止后阻止后续调度，分别记录取消已请求/已确认/不确定。已有外部副作用单独记录，不能声称自动回滚。关闭/离开房间后不得继续执行，迟到回调不得重新启动任务。

• 循环与预算上限在适配器及执行入口生效；缺少 usage 不冒充预算合规。

• 再做有明确模型、环境、次数/费用上限和批准的真实 API 小试点：两个独立运行时完成上述任务，由人验收。

• 记录准确版本/提交、执行命令、结果、失败、跳过项与未测边界。Mock 通过、接口连通、实际模型完成、人工验收分别记录。

• 用同一套验收用例比较 A/B，保留后续接入 openJiuwen 的能力映射清单；未实测前不宣称兼容。

小规模性能基线

只比较上述小任务，不用少量样本宣称某个运行时总体更优：

• 固定并记录 fixture 版本、测试与验收口径、FlyBot/DSH/OpenCode 版本或提交、provider/model、参数、工具权限、输入与澄清答案。
• 尽可能使用相同 provider/model、任务、机器资源与条件；无法对齐的 prompt、工具、缓存或执行环境差异必须披露，不把模型差异归因于 runtime。
• 记录任务完成质量（独立测试与人工验收）、端到端耗时、token/usage；分开记录模型调用、runtime/工具、adapter/排队和人工等待时间。无法准确拆分的时间标记未知。
• 记录失败、重试、取消、样本数与重复次数，不只展示成功案例；请求数不能换算成未经验证的 token 或费用。
• Mock 契约测试不作为真实模型性能结果；真实试验需先明确调用/时间/费用上限。当前没有对比结果，也未因本 issue 启动任何调用。

需要讨论的决定

1. 在“同房间 DSH + DSH 对照 DSH + OpenCode”要求下，第一阶段选择 A 还是 B？标准 A2A 互通是否也是首期硬要求？
2. 首个试点只做同一人的两个 Agent，还是直接包含两个 owner？若后者，Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149/[Team] Recover task handoffs without duplicate work #55–[Team] Verify the real two-human team pilot end to end #58 的相关 gate 必须满足。
3. 首个任务、共享数据范围、可用工具和预算如何限定？哪些动作始终由人批准？
4. OpenCode 的运行位置与生命周期由谁管理？取消、权限请求、断线恢复的各端责任如何划分？

关联与参考

• FlyBot 当前运行时与插件边界、架构
• [Team] Gate cross-owner agent routes by per-Bot grants (default deny; superseded the publication gate) #51（per-Bot grants）、Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149（任务责任与镜像）、[Team] Recover task handoffs without duplicate work #55（恢复）、[Team] Bound agent loops and resource consumption #56（预算）、[Team] Add a human-readable authorization and task audit trail #57（审计）、[Team] Verify the real two-human team pilot end to end #58（真实双人试点）
• Bot Social README / REST、MCP 与未完成的 A2A roadmap
• OpenCode Server、SDK
• A2A 官方规范：实施时固定具体版本；不能把 latest 当长期兼容性契约。