为什么 osFoundry 让 Codex CLI 用轮询而不是推送？一次客户端重建实验的答案

作者用 Python 脚本模拟 Codex CLI 作为 MCP 客户端，实测 osFoundry 服务端关闭了所有推送通道，只剩一个只读的 poll_resource_events 工具。文章用数据解释了为什么游标必须放在客户端、limit 该设多少、以及 30 个资源该以什么频率轮询最划算。

三条推送通道全部关闭

• initialize 声明 capabilities 里只有 tools 且 listChanged: false，连工具列表变化都不会通知
• resources/subscribe 返回 Method not found（-32601），对 MCP URL 发 GET 也只得到 405
• 未认证请求返回 401，但响应头带 X-RateLimit-Limit: 2000、约 61 秒重置，限额相当宽松

为什么轮询适合 Codex

• Codex CLI 不是常驻 daemon，跑完一轮就停，推送通道需要会话之间有东西在监听，笔记本上通常没有
• 序列号游标贴合这种使用方式：客户端每个资源存一个整数，随时回来问之后发生了什么
• 真正的瓶颈不是服务器负载，而是模型自己的轮次——每次 poll 都是一次工具调用加一次读取

游标为什么归客户端管

• 服务端的 wait_for_messages 支持服务端游标和最长 50 秒的 long polling，但 poll_resource_events 两者都没有，连 timeout_s 参数都会被拒绝
• 重建实验让两个终端轮流消费 600 个事件：服务端游标下 A 只看到 305、B 只看到 295，各丢一半；客户端游标下双方都看全 600
• 两个终端用同一账号登录 Codex 是常见场景，服务端游标会被互相推进，所以多读者场景必须由客户端持有 after_sequence
• schema 不强制 after_sequence，缺省行为未定义，别赌，每次都显式传

发现可轮询资源的两步走

• 先调 list_granted_resources（无参数，传多余参数会被拒），服务端主动告诉你有哪些项目和资源
• 再用 list_project_resources 按类型列举，没有一次列全部的接口，9 个类型要 9 次调用，超 50 条还要 offset 翻页
• graph_session 可轮询但不可列举，只能等所有者在桌面端分享后通过 list_graph_sessions 拿到
• 这三个工具共占 591/12662 tokens，约 4.7%，schema 设计相当克制

轮询频率的量化对比

• limit 上限 100：清空 350 个积压事件，limit 100 要 4 次调用，limit 20 要 18 次，所以每次都请求 100
• 固定每 30 秒轮询 30 个资源：每小时 3600 次调用，94.7% 是空的，但事件平均只延迟 14.9 秒
• 固定每 5 分钟：每小时 360 次，但最活跃的频道也要平均等 150.9 秒
• 空轮询翻倍间隔、上限 10 分钟的 backoff 是折中方案：每小时约 502 次调用，中位延迟 34.9 秒，空轮询降到 70.2%

token 成本参考

• 重建格式下空页响应约 17 tokens，单个事件约 41 tokens（cl100k_base 计），空轮询读起来很便宜
• 这些是重建实验自己的响应格式，不是 osFoundry 生产格式，但数量级可参考
• 轮询的总成本主要由调用轮次决定，而不是单次响应大小