Claude 启动 osFoundry Graph 只拿到排队票据：一次架构还原和轮询成本实测

作者用模拟脚本还原了 osFoundry 的 Graph 执行链路：桌面端只发起出站连接，服务器只负责排队，所以 Claude 调用 run_graph_session 拿到的只是排队确认而不是结果。文章用 2000 次模拟量化了排队等待、串行执行和轮询策略的真实代价，结论是轮询节奏应该跟着 20 秒的 relay 周期走。

为什么服务器不能直接跑 Graph

• Graph 是保存在桌面端的 JavaScript 程序，由桌面端的 fleet 引擎执行，支持条件分支、并行 agent、有限重试和 Graph 互相调用
• 引擎、agent、本地模型、文件夹和工具审批设置全在桌面进程里，服务端 runner 需要复制整套环境才能跑
• 浏览器里只能读 Graph，执行必须靠桌面端，这是功能索引里写明的限制

请求是怎么到达桌面的

• 桌面端不是被动等连接，而是主动拉任务：useConnectedGraphRelay 每 20 秒向服务器 sync 一次，顺带补发上次失败的完成回执
• 每次 sync 最多上报 100 条会话元数据，响应里带回该项目排队的命令
• 执行前会重新校验项目仍启用、会话仍共享、slug 未变，否则标记为 cancelled
• run_graph_session 的 Queue 语义由此而来：工具立即返回，桌面端要到下一个轮询周期才会看到这条命令

排队和串行执行的真实代价

• 2000 次模拟显示，从排队到启动平均 9.8 秒，p95 为 18.9 秒，上限就是一个轮询周期
• relay 串行执行命令：5 个 run 一起排队，第一个结果中位数 75 秒，最后一个中位数 399 秒、p95 达 776 秒
• 想并行应该写进 Graph 内部，引擎有 max_concurrency 和 token 上限，桌面端本身只有一个 worker

轮询策略怎么选

• 每 2 秒轮询一次，每个 run 平均 47 次工具调用，只换来 1 秒的感知延迟改善
• 指数退避（2、4、8…30 秒）在这里反而吃亏：调用次数和 15 秒固定轮询差不多，感知延迟却是两倍，因为典型 Graph 结束时退避已到 30 秒顶
• 最优策略是先等约一个轮询周期（20 秒），之后每 10 秒查一次：平均 8.8 次调用，感知延迟中位数约 5 秒

取消、幂等和离线

• 取消排队中的 run 是服务端状态变更，桌面端根本看不到，不耗 token；取消运行中的 run 靠桌面端 3 秒一次的控制轮询，平均 2 秒内终止
• idempotency_key 是必填项（8–128 字符），重试时复用同一 key 能把重复入队从 266+ 次压到 200 次，对会写文件或发邮件的 Graph 尤其关键
• 桌面离线时任务仍在服务端队列里，恢复上线约 3 秒后开始执行；真正的弱点是完成回执丢失——没有 outbox 的话状态会永远卡在 running