oh-my-pi v15.11.8 发布 —— 当你的 agent 可以被别人实时加入，会发生什么？
v15.11.7 + v15.11.8 两个版本背靠背发布，核心词就一个：collab（协作）。但这只是冰山一角——模型目录整个重写了路由逻辑，冷启动快了 244ms，流式渲染减少 66% 的 CPU 开销。两个版本的更新量加起来相当于一次中型重构。
最重磅更新：Collab 实时会话共享
v15.11.8 的核心成就——collab（协作模式）终于从实验代码变成产品功能。
怎么工作的？ 你先在终端里跑 omp，然后 /collab start 生成一个链接。这个链接里嵌了 AES-256-GCM 的密钥在 URL fragment 里，relay 服务器（默认 relay.omp.sh）看到的只有加密后的 opaque 字节。你把链接发给同事，他在浏览器里打开 collab.omp.sh 或者直接在终端跑 omp join <link>，就能实时看到你的 TUI（终端用户界面）画面。
不只是看画面那么简单。 客人端渲染的是原生的 TUI——流式文字、tool card、footer 状态、ctrl+o 扩展、/dump 导出——全部都是实时的。客人还能在对话里发消息，agent 会看到带 author badge 的 prompt。有人问「你这步在干嘛」，客人直接打字就行，不用你手动转述。
子智能体也是透传的。客人可以看到 subagent 的实时状态、progress、甚至查看每个 subagent 的完整 transcript。host 的 Agent Hub 表格、hub chat/kill/revive——这些操作通过 collab link 路由到 host 端执行，会话关联的命令只能由 host 触发。
安全设计上也很讲究：relay 只转发加密后的字节，看不到明文内容。非本地的 ws:// relay URL 和无效的 room key 都会被拒绝（v15.11.8 的安全加固）。
另外 collab.relayUrl 和 collab.displayName 两个配置项可以自定义 relay 服务器和显示名。collab 状态行会显示参与者数量（host 端）或 guest 角标。
模型目录：变体折叠，告别凌乱的 thinking 后缀
这是 v15.11.7 最核心的底层改动——不是一次简单"重构"，而是把整个模型路由逻辑翻了底朝天。
问题是什么？ 很多 Provider 把同一个模型拆成多个 id：gemini-3.5-flash 和 gemini-3.5-flash-low、claude-sonnet 和 claude-sonnet-thinking。以前这些 entry 在目录里是独立条目，用户选模型时看到一堆几乎一样的名字，不知道哪个该选。
v15.11.7 的解决方式：variant-collapse 机制自动检测这类变体对，把 X 和 X-thinking（或 X-low/X-high）折叠成一个逻辑条目，在 thinking.effortRouting 里记录每个 effort 级别对应的上游 wire id。请求时通过 resolveWireModelId(model, effort) 动态解析出正确的 outbound id。
这个机制不只是对已知的 Provider 生效——它有一套自动推导规则（deriveThinkingPairFamilies）：任何 Provider 目录里存在的 bare 和 thinking twin 都会自动折叠，门控条件是同一 API 通道且兼容的定价。还加入了防止 mandatory reasoning 被绕过的兜底：thinking.requiresEffort 为 Gemini 3.x、OpenAI o-series、MiniMax M2 等模型强制最低 effort 级别。
这意味什么？ 你选 gemini-3.5-flash，告诉 omp 你想不用 thinking，它会自动路由到 -low 变体。选 thinking high，路由到 -high。你不用关心背后的 id 叫什么——omp 替你管了。
模型显示名也做了清理：去掉了 gateway 前缀（OpenAI:、Google:）、促销标签（(latest)、(20% off)）、Provider 归属（(Antigravity)）、价格档次（($$$$)）。只保留变体区分标签（(Thinking)、(free)、(Fast)）和日期/地域标签。
性能：冷启动和流式渲染被翻了个遍
v15.11.7 和 v15.11.8 各自的性能改进叠加起来，效果相当显著。
冷启动被优化了两处：模型目录的 buildCanonicalModelIndex 从构造函数移到了首次读取时懒加载，节省约 210ms；createAgentSession 不再阻塞在 MCP server 发现上——它立即返回，MCP 工具在后台连接成功后通过已有的 live-refresh 通道补上来。合计约 244ms 从冷启动关键路径里扣掉了。在你输完第一条 prompt 之前，后台连接已经跑完了。
流式渲染也动了大手术。Markdown 渲染在流式输出时不再每次 tick 全量重解析——marked 没有可恢复的 lexer，但 v15.11.8 的 team 找到了一个 trick：在空白行边界处分段，冻结前缀 block token，只 re-lex 新增长的 tail。对于非追加编辑和 fence 平衡的情况有 full-lex fallback。一个 6,000 字符的 reveal 从 575ms 降到 89ms。
Think 块 + Answer 流的渲染优化：在 think 块完成后、answer 还在流的时候，已经完成的 think 块不再每帧重新高亮，减少约 66% 的渲染工作量。
Assistant 消息流也改了：组件复用了 Markdown subtree，只 re-render 增长的块而不是每次 tear down 后重建。grapheme count 也做了 memoization。
🔧 修复与优化
MCP（Model Context Protocol）与连接质量
- 修复了 Windows 上从 npm
.cmdshim 启动 CodeGraph MCP 的问题：直接解析 shim 的 Node 入口点启动，而不是走 transient 的 cmd.exe wrapper - MCP server 连接失败的"still connecting"占位符变成确定性错误，不再显示"unknown tool"。session 在后台连接未完成时被销毁也不会遗留下工具
TUI 体验
- 修复了 Ctrl+T（切换 think block）清除待发送消息的问题——在
message_start到来之前，user message 通过optimisticUserMessageSignature机制乐观渲染 - 修复了 SSH 远程使用时报图片路径不可达的问题：不再是静默插入本地路径文本，而是提示用户使用剪贴板图片粘贴快捷键
- 修复了 snapcompact archive 在 OpenRouter 上部分不可读的问题——OpenRouter 硬性限制每请求 8 张图片，超过部分静默丢弃；每个 Provider 现在有帧预算控制
模型与基准
omp bench基准测试新增--runs、--max-tokens、--prompt、--json参数，支持失败报告和退出码- 修复了
omp bench在 OpenRouter 上因 response caching 导致 TPS 为零的假阳性——现在发送X-OpenRouter-Cache: false - 修复了
omp bench在 openai-codex 模型上 400 的问题——请求带上了最小默认 system prompt - 新增
snapcompact.shape设置支持auto模式（每个 Provider 的 eval 胜者）和所有 research-eval 变体
超时与兼容性
- 修复了 Kimi K2.6 OpenAI-compatible 的 stream watchdog：用 300s 下限覆盖 Fire Pass router id，防止超长 reasoning 开始阶段超时
- 修复了 Hindsight retains 发送 UTC Z 字符串而非本地时间戳的问题
升级
目前 omp 的最新版是 v15.11.8，升级方式：
# macOS/Linux
curl -fsSL https://omp.sh/install | sh
# Homebrew
brew update && brew upgrade can1357/tap/omp
# Bun（推荐，包管理器和 runtime 合一）
bun update -g @oh-my-pi/pi-coding-agent
# mise（版本固定）
mise use -g github:can1357/oh-my-pi
完整更新日志：GitHub Release v15.11.8
📢 关注我，获取最新开源更新日志和开发者工具动态。
#ohmy-pi #Collab #模型路由 #性能优化 #Agent共享