人离开电脑后，怎样继续掌握 AI 团队？本地运行与手机控制面的双端设计
**系列导航：**先从长需求施工图理解工作怎样被规划，再用故障注入测试检查运行边界；本篇回答人离开电脑后怎样继续观察和作出受约束决定。
10 秒看懂
电脑继续负责真正干活，手机只负责看进度和做少量关键决定。
如果手机也保存一套任务状态、也能直接改“已批准”“已完成”，一旦断网、重复点击或任务版本变化，电脑和手机就会各自拥有一个真相。
稳妥的设计只有一句话：
电脑掌握执行和事实，手机提供受约束的观察与决策入口；手机上的每一次操作，都必须回到电脑端的最新事实重新检查。
地铁里的真实问题，不是“手机能不能打开网页”
晚上七点，一项重构还在家里的电脑上运行。开发 Agent 已提交改动，运维 Agent 正在跑集成测试，测试 Agent 刚发现一个失败。人已经在地铁上。
此时手机上真正需要的不是一套缩小版开发工具，而是三个答案：
- 现在到底进行到哪一步？
- 哪一项决定必须由我处理？
- 地铁断网后，我的点击会不会被重复执行？
最危险的做法，是让手机自己维护一份“最新任务库”。电脑上的任务已经进入审核，手机缓存还显示正在执行；手机离线时批准了旧版本，恢复网络后又把这张旧批条补写到已经变化的新任务上。
这不是页面刷新慢，而是系统出现了两个事实源。
先划清两层：电脑是执行面，手机是控制面
电脑端负责：
- 观察任务文件；
- 决定哪些工作满足开工条件；
- 启动和管理模型会话；
- 运行测试并保存证据；
- 记录任务、报告、审查和人的决定。
手机端负责：
- 查看团队和任务状态；
- 阅读报告、失败原因和证据摘要；
- 处理少量需要人类权限的批准、驳回、暂停或返工；
- 查看设备绑定和连接状态。
手机不能成为第二个运行系统。浏览器里的后台脚本可能被系统随时终止，适合做缓存、离线页面和通知，不适合承担持续数小时的 Agent 执行。W3C 的 Service Worker 规范也明确把它设计成事件驱动的网络与缓存代理，而不是永远在线的后台进程。
可以把整个系统想成：
电脑：执行与事实 手机：受约束控制
┌─────────────────────┐ ┌─────────────────────┐
│ 启动 Agent 会话 │ │ 查看团队状态 │
│ 运行测试 │<──安全连接──>│ 阅读任务与报告 │
│ 保存任务与证据 │ │ 提交带版本的决定 │
│ 判断恢复或停止 │ │ 查看设备连接 │
└──────────┬──────────┘ └──────────┬──────────┘
│ 唯一权威事实 │ 不保存第二套任务真相
└───────────────────────────────────────┘手机最少只需要六类信息
一个好的控制面不靠页面数量取胜。最小集合可以只有：
- **团队状态：**谁空闲、谁忙、谁阻塞、数据是什么时间取得的。
- **任务状态和上下级关系：**当前任务、父任务、子任务、所处阶段和阻塞原因。
- **报告与证据：**谁声称做完了什么，测试通过、失败还是根本没执行，证据在哪里。
- **待处理决定：**哪些对象等待批准、驳回、暂停或返工。
- **关键动态：**只追加的重要事件，而不是把聊天气泡当任务状态。
- **设备状态：**哪些手机已经绑定、最后在线时间、会话是否过期、当前走局域网还是中转服务。
每个页面都要能回答：“这个数字和状态来自电脑端哪一份权威记录？”
手机可以保存缓存，但缓存必须明确标成“截至 19:02 的旧视图”，不能冒充实时事实。任务列表、详情、通知和审批页如果各自从不同副本取数，迟早会对同一任务给出不同结论。
绑定手机，不是一张永久有效的二维码
设备绑定至少要分成两个阶段：短期入口和长期设备身份。
更严格的目标合同应该是：
- 电脑生成一个短期绑定入口，过期自动失效；
- 手机首次确认后，待绑定记录只消费一次；
- 为应对浏览器重复请求，同一绑定入口可以在很短的窗口内返回第一次的同一结果，但不能创建第二台“幽灵设备”；
- 服务器签发可以过期、撤销和轮换的设备会话；
- 高风险操作需要重新检查身份和角色，不能只相信手机页面上有一个按钮；
- 绑定链接、二维码、会话凭据和真实任务正文不得进入公开截图、代码仓库或普通日志。
CodeFlowMu 当前实现已经把短期绑定记录、有限时间内的重复请求处理和长期设备身份分开。长期设备记录只保存会话凭据的摘要；为了让同一绑定请求在 10 分钟的重放资格窗口内得到第一次的相同结果，进程内的短期完成记录会暂存原会话凭据。窗口结束后，旧请求不再有资格取回该结果，但记录是在下一次访问该绑定编号时惰性清理，并非由定时器在第 10 分钟准点删除。
当前代码还提供单设备吊销和“除保留设备外全部吊销”：吊销后设备被禁用，持久记录中的会话摘要与到期时间被移除，后续使用旧凭据的鉴权会失败。PC 管理页也有相应入口。这说明丢失手机后的服务端止损路径已经进入实现，但代码对照不等于完整安全验证；仍需测试已经缓存的页面、正在途中的请求、服务器重启和多端同时操作时，吊销是否始终按预期生效。
这些取舍必须纳入威胁模型，不能简化成“系统只保存摘要”或“点一下吊销就万事大吉”。真实部署还需要会话轮换、日志脱敏、吊销传播和失窃设备演练。
手机审批不是改一个“已批准”字段
这是双端系统最容易犯错的地方。
危险做法
手机只发送：
任务 1：状态改成“已批准”地铁进入隧道，请求结果没有返回，手机自动重试三次；与此同时，电脑上的任务已经被另一位管理员修改。服务器如果只看“已批准”三个字，就可能把旧决定重复写入新版本。
正确做法
下面是一张目标协议示意，用于说明一条安全决定至少需要哪些字段；它不是 CodeFlowMu 当前公开 API，也不证明现有手机端已经接入了这项审批。
手机发送的是一张完整决定单：
针对对象：任务 1
我看到的版本指纹：版本 2.1 / 指纹 123
决定：批准进入下一步
理由：已检查测试与风险说明
防重复流水号：请求 987服务器收到后重新读取最新任务：
- 版本没变、角色有权、前置条件满足，才追加一次决定；
- 版本已经变化，拒绝旧批条，要求重新阅读；
- 同一防重复流水号来了三次，只返回第一次结果；
- 网络超时，手机显示“结果未知”，不能自己宣布成功；
- 批准只代表允许系统尝试下一步，不代表执行已经完成。
这就是“失败时默认不放行”：只要版本、权限或结果不确定，系统宁可保持只读或等待，也不猜测用户已经批准。
局域网和中转服务，只改变连接路线
人在同一网络时，手机可以直接连接电脑；离开家或办公室后，可以通过受约束的中转服务转发请求和事件。
两条路线改变的是“手机怎样找到电脑”，不能改变“谁拥有任务事实和批准权”。无论请求走局域网还是中转服务，最终都必须回到同一个任务读取器、同一个权限检查和同一个决定记录。
2026 年 8 月 19 日，我们在当前 CodeFlowMu 工作树上重跑了局域网地址选择专项测试，结果为 5 项执行、5 项通过。它只证明当前环境中的地址筛选规则，不证明公网穿透、加密传输、中转服务长时间稳定或手机端整体安全。原始命令和输出保存在专项实验记录。
权限漂移：后端、提示和测试必须同时更新
移动控制面演进时，很容易出现一种隐患：后端已经收紧或重新定义权限，手机页面仍展示旧能力，自动化测试也仍按旧规则判断。
本轮专项检查就发现了一处类似的合同漂移：当前实现仍保持开放版远程发布为只读，但实现使用的权限语义与旧测试期望已经不一致。具体错误码属于开发证据，留在实验记录里；面向读者更重要的是通用教训：
权限边界必须在后端实现、用户提示和自动化测试中三处同时对齐。任何一处落后，手机都可能展示不存在的权限，或把真实限制误报成故障。
测试可以告诉我们“发生了漂移”，却不能代替产品负责人决定新旧规则哪一个具有正式权威。裁决后还必须同步代码、页面文案、错误说明和回归测试。
弱网与缓存：旧页面可以看，旧决定不能执行
手机可以离线阅读最近一次任务快照，但必须显示数据时间、所见版本和连接状态。
只显示“截至 19:02”仍然不够。手机系统时间可能因为时区、手工设置或时钟漂移而不准确，缓存是否过期不能只靠客户端墙上时钟判断。更稳妥的界面同时显示两种信息：电脑端生成的观测时间，以及“距离最后一次收到电脑心跳已经过去 X 分钟”。过期与权限判断以服务端时间和服务端规则为准；手机只根据收到心跳后的单调经过时间更新提示，不能用自己的时间把旧快照重新解释成最新状态。
CodeFlowMu 当前服务已经发送带时间戳的心跳并记录连接的最后活跃时间，但本文没有证据证明所有 PWA 页面都统一实现了上述抗时钟漂移提示。因此，“绝对观测时间 + 心跳间隔 + 服务端过期裁决”应作为下一轮 UI 与弱网测试的明确验收目标，而不是当前完成声明。
一个实用规则是：
- 断网时允许阅读明确标记为“截至某时”的任务和报告；
- 离线时不保存可以无条件重放的批准指令；
- 恢复连接后先核对版本，再开放写按钮；
- 实时通知漏掉后，完整对账仍能找回变化；
- 手机版本太旧、数据格式不兼容或权限不确定时，自动进入只读模式。
Local-first 软件研究强调本地拥有、离线可用和跨设备协调的价值，但这篇论文不能替我们的实现背书。真实产品仍要测试弱网、时钟偏差、缓存污染、设备撤销和中转服务故障。
双端验收清单
事实与显示
- 手机列表与详情都来自同一任务版本。
- 缓存页面同时显示电脑端观测时间和“距最后心跳 X 分钟”，不冒充实时状态。
- 缓存过期与写权限由服务端裁决，不依赖手机系统时间是否准确。
- 执行报告、审查决定、人的批准和实际完成不会被压成一个“完成”。
- 重新联网后的完整对账可以修复漏通知。
设备与权限
- 绑定入口短期有效，待绑定记录只消费一次。
- 短窗口内的重复请求只返回同一结果，不创建第二个设备。
- 设备会话可过期、撤销和轮换；手机丢失后可从 PC 单独吊销该设备，或只保留最近可信设备。
- 吊销后旧凭据的下一次请求必须失败；缓存页面、在途请求和服务器重启后的行为有单独测试。
- 高风险动作在服务器重新检查权限，不相信客户端按钮。
手机写操作
- 每个决定都带对象、所见版本、决定、理由和防重复流水号。
- 任务版本变化后，旧批条自动失效。
- 请求超时显示“结果未知”，不由手机宣布成功。
- 人类批准与执行成功分开显示。
网络与隐私
- 局域网和中转路线使用同一事实与权限服务。
- 断线、重复请求、服务器重启和设备撤销都有回归测试。
- 公开截图、仓库和普通日志不包含二维码、绑定链接、会话凭据或真实任务正文。
云端运行系统也是有效架构。如果任务本来就在远程沙箱执行，手机可以直接控制云端权威服务。本文讨论的是本地 Agent 团队的故障和信任模型，不主张所有 Agent 都必须在个人电脑上运行。
对本地系统来说，最好的手机端不是功能最多的手机端，而是人离开电脑后仍能看到同一事实、做少量有权决定，并在网络或版本不确定时拒绝制造第二个真相。
TMPA、FCoP、CodeFlowMu 和手机端到底是什么关系？
把四个名称挤在一句话里，读者当然会迷糊。它们不是四个并列产品，而是四个职责不同的层次。
【治理语义】TMPA Core
定义稳定工作载体、角色责任、生命周期状态、独立验收和冲突保留
│
▼
【文件协议】FCoP Profile
将部分治理语义投影为 TASK / REPORT / ISSUE / REVIEW、路径状态与迁移事件
│
▼
【本地工程系统】CodeFlowMu
在当前项目上运行 Agent、测试、依赖、会话、权限、设备绑定与审批服务
│
▼
【远程界面】CodeFlowMu Mobile PWA
显示服务端事实，并把少量受约束的人类请求送回同一个权威服务第一层，TMPA 核心规范 S1.0是供应商中立的治理语义，不规定电脑、手机或文件系统。它所说的“稳定主载体”是一项工作的稳定引用点，不是“电脑硬盘才是法定主体”。它真正提供的关键边界是：执行报告属于事实声明，有权角色发布的接受决定属于治理裁决，两者不能合并成执行者自己的“已完成”。
第二层，FCoP把治理协作投影为人机共读的文件。它规定任务、报告、问题、审查、路径状态和迁移事件，但不负责网页怎样到达手机、局域网地址怎样选择、设备凭据怎样签发，也不拥有 Agent 会话。
第三层，CodeFlowMu Open才是运行中的工程系统。在本文讨论的本地部署里，当前项目根、Runtime 和服务端读取器组成权威执行面；这是 CodeFlowMu 的部署选择，不是 TMPA 对所有系统的要求。CodeFlowMu 还必须区分两类看起来都叫“审批”的动作：任务生命周期里的 REVIEW 属于任务平面；Git 推送、外部写入等高风险操作进入独立的操作审批服务。后者不会因为手机上出现一个 REVIEW 文件就自动获得执行权。
第四层，手机 PWA 是界面和请求入口。它可以缓存旧视图，却不能成为第二个 Runtime，也不能绕过服务端直接改变权威状态。
在手机上点一次“批准”，真实边界是什么？
一次受控决定可以用五步理解。下面描述的是设计边界，不是把所有决定硬塞进同一种文件或 API。
1. 手机读取服务端返回的任务、报告、当前版本和连接时间。
2. 人点击“批准”，请求携带目标、所见版本、理由和防重复流水号。
3. CodeFlowMu 重新检查：设备会话是否仍有效、角色是否有权、目标版本是否变化、请求是否重复。
4. 校验通过后：
- 任务复核写入适用的任务/REVIEW 决定链；或
- 高风险操作写入独立的 Operation Approval 记录，只授权那一次精确尝试。
5. 后续执行产生新的报告与验证结果；手机稍后读取结果，不能把“已批准”提前显示成“已完成”。地铁弱网导致同一请求到达三次时，服务端应返回同一裁决；目标版本变化时，旧请求应被拒绝；设备已经从 PC 吊销时，旧会话不能继续提交决定；请求结果未知时，手机保持“待确认”。至于批准后是否唤醒下游 Agent，要由具体任务依赖或受控执行器决定，不能把每次批准都写成“自动解冻发布任务”。
图 1：这是目标决定边界，不是当前手机 API 已完整实现的能力声明。手机只作为入口；权威服务应重新检查设备会话、角色能力、目标版本和防重复流水号。FCoP REVIEW 与 Operation Approval 仍属于两个不同平面。来源：TMPA Core S1.0、FCoP v3，以及 CodeFlowMu 当前设备与操作审批实现已经核验的边界。
一句话概括：TMPA 定义治理语义，FCoP 规定协作工件，CodeFlowMu 承担本地执行与权限裁决，手机只提供受约束的远程入口。