chatgpt-web-bridge git:20260920.3367b72A

Immutable. This exact content never changes and is served at /api/v1/blob/72ee5375918f9ce4.

---
name: chatgpt-web-bridge
description: |
  通过 chatgpt-web 的 MCP 或 REST 桥，把本地 agent 接入已登录的 ChatGPT Web。
  适用于“推进/继续网页端会话”“让网页端设计、本地执行”“协作/对等推进”，以及只读拉取网页端会话/项目资料和 conversation_id 续接。
  桥只传递文本；网页端没有本地 shell、文件系统或其他本地工具。
---

# ChatGPT Web Bridge

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

## 先选模式

| 用户意图 | 模式 | 回合形状 |
| --- | --- | --- |
| “推进/继续这个网页会话” | A 推进 | 发最小推进消息，读回结果，按终止条件决定是否继续 |
| “让网页端指挥现在的项目” | B 指挥 | 网页端给指令，本地执行并回帖事实，直到指令循环结束 |
| “协作/对等/共同推进” | C 协作 | 双方先独立陈述，再交换证据、交锋，执行落在本地 |
| “用网页端项目/会话的资料” | D 只读 | 只读项目、会话或记忆；不发送消息、不创建会话 |

不要把一次回帖本身当成任务完成。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. 推进模式

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

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

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

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

## B. 指挥循环

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

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

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

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

## C. 协作模式

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

推荐信封：

```text
[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` 等字段。不要为了获取长文在工具结果被截断后反复请求同一页。
- 只读任务拿到资料即结束，不把网页端结论偷偷改写成本地事实。保留原文、来源和读取时间。

## 通道和生命周期

| 场景 | 推荐通道 | 生命周期处理 |
| --- | --- | --- |
| MCP 工具随当前 agent 会话使用 | stdio `chatgpt-web2api-mcp` | 由 MCP 客户端启动和回收；断线时重新建立该 stdio 连接，不启动共享 daemon |
| 多个客户端共享一个服务 | SSE daemon `:8090` | 用 `start.ps1`/`ensure` 管理共享服务；先看健康状态和运行时元数据，再决定是否重启 |
| 串行 REST 客户端 | REST `:8080` | 显式携带 `conversation_id`；遵守相同的结果、收据和取消纪律 |

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 的旧日志判断当前实例已经加载了新代码。