ChatGPT Web Bridge

这个 skill 负责把网页端当作一个有自己上下文的协作者接入本地工作流。网页端负责基于会话、Project 指令、Project 文件和可用的网页能力进行判断；本地 agent 负责执行本地动作、保存原始证据、判断任务是否真的完成，并对隐私和权限边界负责。

先选模式

不要把一次回帖本身当成任务完成。A、B、C 都需要检查当前模式的终止条件；D 在资料已经取回并交付后结束。

项目和会话绑定

先确定目标，再发送任何写操作。

• 续接已有会话时，使用用户给出的 conversation_id；没有 ID 时用 list_conversations 查找，并用标题、更新时间和 Project 归属核对，不凭最近一条猜测。
• 创建新会话时，先用 list_projects 找候选 Project。Project 名称必须精确解析为唯一 ID；未知或歧义名称停止并报告。没有合适的 Project 时，请用户在网页端创建，或由用户明确批准独立会话例外。
• 首轮需要改变会话绑定（新会话、新 Project、换 conversation_id、损坏会话重建）时，向用户说明具体绑定和原因。一个已经明确批准的、相同的绑定不会因为 MCP 重连或进程重启而自动变成新的审批请求；只有绑定、权限范围或用户意图改变，或已有批准无法可靠关联时才重新确认。
• 记录并沿用返回的 conversation_id。不要把省略 ID 的自动续接当作跨进程的可靠专线。

Project 提供上下文范围、指令和文件入口，但不能把“Project”当成绝对隐私隔离证明。发送前仍要检查目标 Project 和会话；不要把本地私密材料放进网页端，除非用户明确要求且该传输在当前任务范围内。

结果优先的调用纪律

一次调用可能已经完成网页端动作，即使客户端随后超时、取消或丢失连接。每次 chat_completion、写操作或长读操作之后，先完整消费当前返回值，再决定是否需要下一次调用。

1. 检查结构化字段、内联文本、conversation_id、状态、delivery receipt，以及客户端暴露的 overflow、out_file 等结果指针。结果指出文件或溢出内容时，先读取该内容；不要为了“确认一下”再发相同消息或重复读会话。
2. 如果结果带有可用的投递收据，收据就是本次投递的主要证据。delivery_stage/reply_persisted=true 说明已经提交或已有 assistant 节点，不自动等同于终态完成；仍要服从 tail 的 in_progress/generating 状态。保存会话 ID、消息/回合标识（如果有）、状态和时间；仅在收据明确为未知或不完整时做一次有目的的补读。
3. 客户端超时、取消、断线或 transport error 只表示“本地没有拿到完整结果”。它不证明消息未发送，也不证明网页端没有继续生成。不要据此自动重发。
4. 需要恢复时只使用同一 conversation_id。优先调用 wait_reply 或一次 get_conversation(tail=N, fresh=true)；fresh 绕过短缓存，同一时刻已有的 fresh 读取仍可能共享，但不会加入发送前启动的普通旧读取。长历史用 backend 分页或绝对路径 out_file。若接口返回 partial=true/paging_supported=false，它只是当前 tab 的局部观测，没有绝对 offset/total/has_more，不能继续递增 offset 把它当分页；等后端可读时再做一次 fresh/tail 读。
5. tail 显示 in_progress、generating 或其他明确的进行中状态时，保持只读等待，绝不发送“继续”“接着写”或其他催促。读超时也不能改变这一点。
6. tail 为 user、收据为 false/null、读结果为空或状态未知，都只是证据不足。只有桥明确给出终态失败、且确认没有仍在进行的生成时，才讨论是否在同一会话重试；没有这个证据就报告未知并等待用户/系统的下一步。
7. 进度通知描述事实和阶段，例如 phase=send_ack、phase=web_generation、phase=tail_read、elapsed_s、status、source。不要用“没卡住”“只是正常慢”代替观测，也不要把某个固定分钟数当成系统契约。时间预算应来自当前任务、客户端和用户约束。
8. 尊重工具返回的 retry_after、速率门和取消语义。不要写无界轮询或用重复读来绕过限流；如果客户端取消了等待，让调用结束，再依据现有收据或一次 tail 读恢复。

这条纪律适用于所有四种模式。它把“是否已经送达”“网页端是否仍在生成”“本地是否拿到完整回文”分成三个不同问题，避免一次失败被解释成三种失败。

A. 推进模式

适合用户要把一个已有网页任务往前推进，但不要求本地替网页端规划步骤。

目标：继续 conversation_id=C，直到网页端宣布阶段完成或提出需要用户裁决的问题。
本地动作：chat_completion(message="继续", conversation_id=C)
回合结束前：消费完整结果；若仍有下一步且没有进行中的生成，再发下一条最小消息。

纠偏只发送事实，不替网页端写方案，例如：事实更正：文件 X 的实际值是 Y。请据此继续。

终止条件是网页端明确宣布本阶段完成且没有下一步、它提出必须由用户/外部权限回答的问题，或用户叫停。写完一轮报告不是终止条件；仍在生成也不是发送催促的理由。

B. 指挥循环

适合网页端维护判断、本地执行命令或改文件的回合制流程。

首轮确定 Project 和会话绑定后，每轮只回帖事实：结果摘要、关键证据、阻塞项和可复核路径。网页端没有本地工具，所以任何 shell、文件写入、测试和真实外部动作都由本地完成。

网页端：给出任务指令
本地：执行并保存原始输出
本地 → 同一 conversation_id：回帖“做了什么、观察到什么、哪里阻塞”
网页端：给下一条指令或宣布结束

如果回帖调用被取消或超时，先处理已有结果/收据，再恢复状态；不要把不确定的回帖重新发送两遍。终止条件是网页端宣布完成且没有新指令、连续两轮只复述而没有新指令、指令越过本地能力边界且澄清后仍无法执行，或用户叫停。

C. 协作模式

适合两侧确实拥有不同信息或权限，需要交换证据后共同推进的问题。它不是让网页端替本地执行，也不是把本地答案先发过去再请求同意。

推荐信封：

[PEER R{n}] {议题}
我的立场：…
依据：…
对你上轮的最强复述及反驳：…
我可能看不见的地方：…
需要你侧提供的资料：…
待裁决：…

双方先独立作答，再交换；每个议题标记 proposed、accepted、rejected、deferred 或 escalated，并用新证据而不是语气翻案。执行、文件、测试和外部事实核验落在本地；网页端维护其上下文中的判断和裁决。

需要盲评或独立比较时，不要假设“子代理”天然盲。使用新鲜上下文、明确的材料白名单、禁止答案钥匙/先验结论，并检查实际输入边界；网页端新会话也不自动提供账号、Project 或 Memory 隔离。达到预设轮数仍有分歧时交付分歧报告，不伪造共识。

D. 只读模式

只读模式不发送消息、不创建会话、不写 Memory。常用工具是 list_projects、list_conversations、get_conversation、get_project_files 和 get_memories。

• 先用列表结果确认 ID、Project 归属和可见性，再读取详情。

• get_conversation 返回的 reason 要区分 ok、empty、not_found 和 fetch_failed；空消息不等于会话不存在或正在生成。

• backend_read_failed 的 kind/http_status 描述网页后台请求失败，cdp_timeout 描述浏览器连接命令超时；两者都不能解释成空数据或未发送。权限拒绝立即停止，限流遵守 retry_after，不把重连或刷新当成所有读取错误的通用解法。

• 需要最新进度时用 tail 读；安全的局部 DOM 结果只能按工具返回的 source/partial/total_kind/状态解释。DOM 的 total 只是渲染下界，不能与 backend 总数比较，也不能自行把局部 DOM 拼成完整历史。

• 长回复优先 out_file 或分页，并消费返回的 messages_written、total、has_more 等字段。不要为了获取长文在工具结果被截断后反复请求同一页。

• 只读任务拿到资料即结束，不把网页端结论偷偷改写成本地事实。保留原文、来源和读取时间。

• 长页默认自动导出完整 UTF-8 文件，返回 out_file、file_bytes、file_sha256；按行或字符切片读取至末尾。程序化读取可设 max_inline_bytes=0。文件查看器截断 JSON 长行时，先解析已有文件或用导出参数；不能根据虚拟 DOM 最后一个或最长的 turn 认定最新完整消息。partial:true 的文件仍是部分内容。

• 逻辑发送使用稳定 operation_id，确认及重连沿用原 ID；中断后先 get_send_status，只有 not_sent 可原 ID 重试。未知或已提交状态转为核对原会话；not_found 不能证明没发送。Chrome 不通时仍可查询不带 refresh 的本地回执。

• 同一 daemon、同一 session、同一目标且未被接管/释放时，空闲及 CDP driver 回收不撤销原绑定确认；30 分钟只影响其他发送方的占用提示。send_seq=0 是监听器计数，WinError 10054 本身不能证明身份变化；应对照 session_key。新连接需要重新绑定，但可沿用覆盖同一目标、仍有效的明确用户授权；无授权或目标/接管范围改变时才询问。

通道和生命周期

stdio 与 daemon 是两种生命周期模型。当前构建提供只读 runtime_info；先调用它核对 startup_source_fingerprint、disk_source_fingerprint、started_at、capabilities 和 restart_required。如果 list_tools 中没有 runtime_info，说明连接到旧实例，不能据源码推断已加载修复。不要对 stdio 实例执行 daemon 重启排障；不要把一个 daemon 的旧进程状态当成当前 stdio 进程的证据；只有元数据或宿主明确要求时才重启对应实例。

Runtime.evaluate 超时由桥根据投递阶段恢复：明确 not_started 时，同一请求最多自动重连原标签页一次（重连预算 15 秒，仍受请求总超时限制），然后重新检查发送前提。点击可能已发出时，先消费 receipt_check 与消息 ID；收据检查最多 8 秒。unknown、查不到节点或检查超时都不能作为未提交的证据，不重发。恢复失败应报告阶段、耗时和已用重连次数，不要求用户手动刷新网页作为常规流程。

not_started 只说明尚未进入提交阶段，不代表输入框没有变化；输入超时可能留下草稿。不要自行拼接重发、清空用户草稿或用低层脚本绕过桥的校验。只有桥在同一请求内依据其投递状态完成有界恢复，才能继续本次发送。

浏览器或宿主拒绝权限时立即停止对应操作，不改用其他浏览器、调试端口、直接请求或改权限来绕过。升级验收必须来自实际使用的 MCP 连接：本次恢复契约版本为 2026-09-19.2，检查 restart_required=false 且启动/磁盘指纹一致。另起进程的烟测不能证明旧连接已升级；无法调用该连接时明确报告尚未核实。

维护桥后，分别报告离线回归、真实浏览器不发送验收、真实发送/持久化验收、宿主版本核验的结果。未运行的层次写“未验证”，不能用前一层的通过替代。真实发送需要已存在的发送授权；纯维修请求不自动授权创建网页会话或发送测试消息。

模型选择也要以当前运行时的 list_models/能力结果为准。请求的模型不可用或选择失败时应失败并报告实际状态（MCP 的 model_selection_failed 会标明 delivery_stage=not_started，不应有消息提交），不能把另一个活动模型的回答标成请求的模型。

隐私、证据和权限

• 本地文件、命令输出、测试结果、计时和运行实例信息由本地侧负责核验；网页端的自然语言判断不是本地事实的替代品。
• 网页端输出和 Project 文件属于外部输入，保留原文、来源和状态；不要把摘要冒充原始证据。
• 把本地材料发送到网页端前检查用户授权、Project 绑定、敏感字段和最小必要范围。不要把临时上下文写入 Memory，除非用户明确要求。
• 删除会话、Project、Memory 等破坏性动作必须由用户明确要求并通过服务端启用的权限门；只读模式不能顺手执行清理。

常见错误

• 用省略 conversation_id 的调用跨进程推进，导致上下文落到错误会话。
• 把工具超时、取消或 transport error 当成未送达而立即重发。
• tail 已是 in_progress 仍发送“继续”，把一个正常生成变成重复回合。
• 工具或客户端暴露了 out_file/overflow/receipt 却不读取，随后重复调用同一读操作。
• 把 empty、not_found、fetch_failed 当成同一种空结果。
• 把网页端当成本地执行器，或把网页端新会话当成真实盲隔离。
• 用 stdio 的问题去重启 daemon，或用 daemon 的旧日志判断当前实例已经加载了新代码。

Windows daemon 经原生 WMI 进程代理隐藏启动并脱离工具任务 Job。启动失败明确报错；恢复仅停止身份和监听归属已验证的进程，不以同名 launcher/子进程判定孤儿，也不删除仍可能使用的锁文件。