.@thsottiaux 我在手机端使用 Codex 时，发现了一个很隐蔽的多任务协作问题。 它不是模型能力下降，也不是执行窗口报错。 更像是：手机端与电脑执行主机之间的任务控制和回执同步出了问题。 电脑端使用时，我可以正常地向多个正式工作窗口派发任务，例如： Conversation OS Platform Core Product Web QA / Security 这些窗口会主动汇报： 接受任务 → 阶段进度 → 阻塞 → 最终结果 → 等待下一步 主控窗口负责协调和继续派发。 但换到手机端后，会出现一种很危险的状态： 任务发送、读取状态、等待结果等请求长时间不返回。 问题在于，这不等于任务发送失败，也不等于执行窗口不可用。 它只能说明： 当前投递状态未知，delivery unknown。 如果主控系统把“请求未返回”误判成“执行窗口不可用”，就可能发生更严重的问题： 主控窗口自行接管工作，或者临时启动另一个代理代做。 这样表面上任务还在继续，实际上已经破坏了原本的责任边界： 正式 owner 不再是唯一执行者 同一文件可能被多个窗口同时处理 审查结果可能绑定到不同版本 任务回执和实际执行状态开始分叉 最终很难判断哪份结果才是真的 所以我给多 Agent 工作流补了一条非常重要的规则： 线程请求超时、挂起或没有返回，只能标记为 delivery unknown。
它不能证明 owner 不可用，也不能授权主控或临时代理接管任务。 正确处理方式应该是： 保留原来的正式执行窗口 保留同一个 dispatch ID 重新读取、等待或重试投递 等待正式窗口主动确认接受 验证最终回执确实回到主控窗口 在此之前，不启动替代执行者 这次经历也让我更明确地区分了手机端和电脑端的角色。 电脑端更适合执行和调度。 它直接连接本地项目、工作树、终端和执行主机，正式窗口之间的控制链路通常更稳定。 手机端更适合查看、决策和轻量指挥。 但在涉及多窗口派发、长任务执行和跨线程回执时，手机端目前可能存在控制状态同步不完整的问题。 最危险的不是“任务失败”。 最危险的是： 系统不知道任务有没有成功送达，却假装自己知道。 在多 Agent 系统中，真正重要的不只是模型能不能完成任务，而是控制平面能不能准确回答三个问题： 任务到底有没有发出去？ 现在究竟是谁在执行？ 最终结果有没有回到正确的主控窗口？ 如果这三个问题没有可靠答案，再强的模型也可能把协作变成混乱。 所以，多 Agent 工作流必须把下面几种状态严格区分： not dispatched
delivery unknown
dispatched
running
blocked
completed 不能把“没有收到回复”直接理解成失败，更不能因此偷偷换人执行。 Agent 系统的可靠性，不只取决于模型能力。 它同样取决于投递、回执、所有权和状态同步。 手机端与电脑端的差异，恰好把这个问题暴露得非常清楚。 ——有时候真正需要修复的不是 Agent，而是 Agent 之间的交通系统。