oh-my-pi v15.10.4–v15.10.7 发布 —— agent loop 大修、thinking 签名修复、MCP 启动加速

agent loop 大修（v15.10.5）

v15.10.5 是三个版本里改动最深的——它不是修某个 bug，是整条 agent loop 的执行路径重检了一遍。

最大的变化：去掉了 maxToolCallsPerTurn 上限。 之前每轮 assistant turn 有一个内置的工具调用数量上限，到了就截断。去掉之后，agent 在一轮里能调用的工具数不再被硬限制——对于复杂任务（比如 subagent 派发 + 结果的批量处理），之前可能一轮做不完要拆两三轮，现在一轮搞定。

剩下的全是修边缘情况的正确性：

• 中断 assistant 响应后，run 不会再卡在 provider 的 iterator cleanup 上
• afterToolCall 现在即使在 run 被 abort 后也会执行——工具的后处理逻辑不会因为中断而被跳过
• agentLoopDetailed().detailed() 修复：run telemetry 和 coverage 在 stream.result() 解析前就捕获好
• GPT-5 Harmony 泄露处理：有效的 tool call 会被恢复，泄露的 partial assistant output 在重试前丢弃
• Abort 时只保留已完成的 tool-call 块，未完成的 tool-call 块如果不是故意中断则丢弃
• 故意中断（TTSR 规则匹配、用户中断标签）会保留 mid-stream 的 tool-call 块，配一个占位 result

Anthropic thinking 签名修复（v15.10.7）

这个 bug 藏得很深：你在 agent 可见输出过程中 interrupt 了模型，transformMessages 会把被中断的 turn 里所有 thinking block 的签名都清空——包括那些已经完成流式输出的 block。Anthropic 在 content_block_stop 时就已经发了签名，所以已经完成的 thinking block 是有签名的。结果被 rerun 时带了一个空签名过去，Anthropic 拒收（HTTP 400）。

修法很简单也很精准：只有中断点正在流式输出的那个 thinking block 被标记为不可信，已经完成流式的 block 保留它们的可重放签名。

如果你用过 Opus 4.7+ 的 adaptive reasoning，又在运行中经常中断 agent 修改提示——这个 bug 你大概率碰到过（表现为 random 400 错误）。

MCP 启动加速（v15.10.7）

之前 omp 启动时如果有一个 MCP 服务器不响应，整个 UI 会被卡住 25–30 秒。原因是 MCPManager.connectServers 在等所有 pending 服务器的工具列表。现在没有缓存的服务器在 Promise.allSettled 中放行，它们的工具通过后台 #onToolsChanged → refreshMCPTools 路径在连接完成时自然出现，不阻塞启动。

装了较多 MCP 服务器的用户，启动速度会有明显改善。

其他修复

v15.10.5：tool result 解析修复（不支持的内容块标记为错误 + diagnostic text）、stall 时正确返回 aborted message、run telemetry 在正确的 finalization 路径上触发、length stop reason 后继续执行等。

v15.10.6：未列出具体变更（可能为内部基础设施）。

v15.10.7：Antigravity 用量计数器分离——Google/Gemini 配额耗尽显示 0% free，独立的 Anthropic/OpenAI Antigravity 计数器不受影响。MCP OAuth 回退渲染修复（终端显示短超链接，授权 URL 不换行）。

升级：

curl -fsSL https://omp.sh/install | sh
# 或用 Bun
bun install -g @oh-my-pi/pi-coding-agent

完整更新日志：GitHub Release

连续三个小版本，agent loop 的执行路径修了一遍、thinking 签名不再丢失、MCP 启动不再卡 30 秒。体量不大但每一刀都砍在点上。

📢 关注我，获取最新开源更新日志和开发者工具动态。

#oh-my-pi #AI编程 #agentloop #Anthropic #MCP