未来不是选最强模型，而是编排所有模型

2026年1月9日，Anthropic 在服务端部署了一道检查，拦截第三方工具通过 Claude Pro/Max 订阅的 OAuth 通道访问模型。OpenCode、Cline、RooCode，一夜之间集体断线。Hacker News 上 “Anthropic Explicitly Blocking OpenCode” 的帖子几个小时内冲上 173 分。

真正让社区炸锅的不是封杀本身，而是 OMO 维护者在 GitHub README 里写下的那句话——“We loved Anthropic models enough to get blocked.” 我们太爱 Anthropic 的模型了，爱到被拉黑。

OMO（Oh My OpenCode）是 OpenCode 的一个插件框架。但叫它插件太小了。它做的事情是：把 OpenCode 从"一个模型写代码"变成"一群模型协作写代码"。你不需要选模型，不需要写复杂提示词，不需要盯着它别中途罢工。你给它一个任务，它自己决定该用谁、怎么改、什么时候停。

Anthropic 封杀的是 OpenCode 的 OAuth 通道，不是 OMO 本身。但 OMO 的高 token 消耗——每次请求动辄 50K tokens——确实是引燃注意力的导火索之一。不过，真正让 Anthropic 警惕的恐怕不是几个 token。而是一种可能性：当用户习惯了在一个界面里自由编排 75+ 个模型供应商，没有任何一个供应商还能锁住谁。

编排，而不是选择

孔子说"君子不器"，意思是君子不应像器皿那样只有单一用途。这句话放在大模型身上也成立——没有任何一个模型在所有任务上都是最优的。

但过去三年，整个行业都在做同一件事：选一个"最强"的模型，然后把它当万能锤子用。写代码用它，写文档用它，做前端用它，做数学推导还是用它。用户的认知负担变成了一个"选择题"：Claude 还是 GPT？选错了，效果差三倍。

OMO 的做法是彻底消解这个选择题。它设了 8 个任务类别（Category），每个类别自动路由到最适合的模型族：前端开发走 Gemini 3.1 Pro，深度推理走 GPT-5.5（xhigh 模式），写作走 Kimi K2.5。你只管说"我要做什么"，系统决定"该用谁来做"。

这背后有一个 Fallback 机制值得说一句。主模型挂了，自动降级到备选：claude-opus-4-7 挂了切 kimi-k2.6，再挂切 gpt-5.5，再挂切 glm-5。跨四个模型族的自动降级链。用户甚至感知不到切换发生了。

经济上的效果同样直白。社区有人算过一笔账：每月花 $10 订阅 OpenCode Go，再花 $20 订阅 OpenAI Plus，组合起来大约等于每月花 $150-300 跑纯 API 的体验。省的不是小钱。

这笔账的另一面是供应商的痛点。Claude Code 的订阅价和 API 价之间有大约 90% 的价差补贴——每月花 $200 订阅享受的算力，如果走纯 API 路线成本要高出一个数量级。有用户在 HN 上报告，高峰期一天就能烧掉等值 $600 的 API 调用。这个补贴的前提是用户老老实实待在 Claude Code 的围墙里。一旦编排层让你跨供应商自由调度，补贴模型就被打破了。封杀事件的深层经济逻辑在这里：不是 OMO 用了太多 token，而是 OMO 让用户不再需要为了省那 90% 而绑定单一工具。

亚里士多德说过，整体大于部分之和。OMO 验证的就是这个判断：当编排层足够成熟，任何单个模型都变成了可替换的计算原语。你不再需要忠诚于任何一个模型品牌。

这才是 Anthropic 真正害怕的东西。

把幻觉问题从"模型不够聪明"变成"工具不够好"

AI 写代码最大的痛点是什么？不是逻辑推不动，而是改代码改不对。

传统 AI 编辑的机制是这样的：模型需要精确复述你想修改的那段原文，然后用新内容替换它。问题在于，模型经常写错一两个字符。一旦对不上号，整段代码就被搞乱。这不是推理能力的问题，是定位机制的问题。一个字符的偏差，结果可能是几小时代码被搞成乱码。

行业默认的归因是"模型不够强"。OMO 的判断恰恰相反：问题不在模型，在编辑工具缺了一层稳定性保证。所有主流 IDE 都没有给代码行赋予稳定的唯一标识——行号会变，文本可能重复，模型靠"猜"来定位编辑位置。Can Bölük 早就批评过这一点，但没人当回事。OMO 当回事了。

Hashline 是 OMO 对这个问题的回答。它给每一行代码绑定一个 2 字符的哈希锚点（CID），编辑前先校验哈希值。哈希对得上，说明你看到的代码和模型看到的代码是同一份，允许改。哈希对不上，说明代码已经被别的操作改过了，直接驳回，强制重读。

一句话：不改变模型的推理能力，只改变交互协议。

效果有多炸裂？Grok Code Fast 1 这个模型本身的代码编辑成功率只有 6.7%——基本等于不会改代码。装上 Hashline 之后，成功率飙到 68.3%。十倍量级的提升，纯粹靠工具层的改进。

但要泼盆冷水：这个数据是 OMO 项目自报的内部测试结果，目前没有找到第三方独立复现。而且 Grok Code Fast 1 本身是编辑能力极弱的模型，这个提升幅度不一定代表强模型场景下的收益。但方向性结论是可信的——哈希锚定比文本匹配可靠，这不是"哪个模型更强"的问题，是架构设计的问题。

《论语》里说"工欲善其事，必先利其器"。多数人理解这句话是在说工具的重要性。更深一层的意思是：好的工具能弥补人的不足，而不是要求人变得完美。Hashline 做的就是这件事——它不要求模型变得更强，而是让弱模型也能干出强模型才有的编辑精度。

让 AI"永不放弃"

AI Agent 最常见的失败方式，不是做错了什么，而是提前停了。

上下文窗口压缩后任务记忆丢失，误判任务已完成，被一个工具调用错误打断后再也回不来。这些问题困扰着几乎所有 AI 编程工具。模型不是"不会做"，是"忘了自己在做什么"。

OMO 对这个问题的解法叫 Boulder——灵感来自西西弗斯推石头。希腊神话里西西弗斯被众神惩罚，永远在推一块巨石上山，石头到顶又滚下来。但在 OMO 的语境里，Boulder 的含义反过来了：石头一旦推起来，就不允许它滚回去。

三层保障机制。第一层：检测到 session 进入空闲状态（idle），不是直接结束，而是触发检查。第二层：Todo Continuation Enforcer（持续推进器）扫描任务清单，发现有未完成的 todo 项，注入续跑指令。第三层：Ralph Loop 持续注入提示词，强制 Agent 继续执行直到所有任务项清零。

关键创新在持久化。传统 Agent 的状态完全活在上下文窗口里——会话一结束，一切归零。Boulder 把任务状态写进持久化文件（.sisyphus/boulder.json），从"内存态"提升为"持久态"。这意味着 Agent 具备了跨会话连续工作的能力。这不是优化，是质变。

OMO 官方的设计哲学说得更直白：“Human intervention during agentic work is fundamentally a failure signal.” 在 Agent 工作期间需要人为介入，这本身就是一个失败信号。这个判断很激进，但逻辑是自洽的——如果 Agent 设计得当，它应该能自己走完整个任务链。

不过 Boulder 目前还有个硬伤：GitHub Issue #1774 暴露了一个全局状态设计缺陷——多个并发计划会互相覆盖。当前的数据结构可能是一个全局单 plan 而非按 session 隔离的多 plan 结构，这意味着多任务并行时存在状态冲突风险。这说明"永不放弃"目前还做不到"永不出错"。但方向是对的：把"任务连续性"从依赖模型的自觉性，变成依赖工程保障。

一个提示词救不了一个模型

OMO 在实践中得出了一个反直觉的结论：同一个 Agent 角色，给 Claude 写提示词需要 1100 行，给 GPT 写只需要 121 行，效果一样好。

原因是两个模型"思考方式"根本不同。Claude 适合 mechanics-driven——长检查表、逐步流程、详尽指令。GPT 适合 principle-driven——短原则、XML 结构、高自由度。

如果你把 1100 行的 Claude 提示词喂给 GPT，GPT 会在自相矛盾的指令里打转。反过来，如果你把 121 行的 GPT 提示词喂给 Claude，Claude 会因为指令不够具体而到处漂移。

OMO 用一句话总结了这条经验：“A PROMPT CANNOT FIX A MODEL.” 一个提示词救不了一个模型。

这个发现直接支撑了核心论点。正因为不同模型有硬性的内在特性差异——不是提示工程能弥合的——你才需要编排，而不是选择。你不能把所有模型都训练成 Claude 的风格，但你可以让 Claude 做它擅长的事，GPT 做它擅长的事，Kimi 做它擅长的事。编排的意义就在这里。

一半人喊"革命"，一半人喊"过度"

OMO 的社区评价是撕裂的。

正面反馈很猛。有人说"它让我取消了 Cursor 订阅"，有人说"一夜之间把一个 4.5 万行的 Tauri 应用转成了 SaaS Web 应用"。GitHub Star 数突破 6 万，从早期的 3.8 万到 6 万+只用了几个月，增长速度不亚于许多明星项目。

负面反馈同样猛烈。有人报告"每次请求烧 5 万 tokens"，“半天用完了一周预算的一半”。社区有人 fork 了一个 slim 版本（oh-my-opencode-slim），直接砍掉 6 个 Agent，把 Frontend agent 的提示词从 5173 行压到 1037 行——砍掉了 80%。

这种分裂不是简单的偏好差异。根因在于 OMO 的设计假设是 greenfield 场景——从零生成整个应用。但多数开发者的实际需求是 brownfield——在现有代码库里做增量修改。前者需要多 Agent 并行规划和自主执行，后者需要轻量、可控、低成本的交互式编辑。OMO 在前者上极强，在后者上过度工程化。slim 版本砍掉 80% 提示词后依然能用，恰恰说明 OMO 的全量配置对多数场景来说太重了。

话说回来，目前还缺少 OMO 在 SWE-bench 等标准基准上的独立评估数据。Claude Code 有 Opus 4.6 @ 80.8% 的公开成绩，OMO 的表现则"依赖所选模型"——这意味着没有可比的基准。效果评估只能依赖用户证言，而这些证言天然存在自我选择偏差：满意的人会去 GitHub 点 Star，不满的人会去 Reddit 吐槽，沉默的大多数可能两边都没去。

一个人加上编排，约等于一个团队

回到开头那个问题：Anthropic 到底在害怕什么？

不是 token 消耗。是编排能力。

当用户习惯了在一个界面里，按任务类型自动切换模型，按哈希锚定可靠编辑，靠持久化状态持续推进——这时候，任何一个模型供应商的锁定策略都会失效。你不再需要忠诚于 Claude，不需要忠诚于 GPT，不需要忠诚于任何品牌。你忠诚的是你自己的编排层。

上一篇我写过 OpenCode 和 Pi Agent 的对比，核心结论是：双进程架构（OpenCode）比单进程架构（Pi Agent）更有扩展潜力。OMO 把这个结论往前推了一步——不只是进程架构的问题，而是整个范式的转换。从"绑定一个最强模型"到"编排所有模型"。

对个人开发者来说，这意味着什么？

以前你需要一个团队：前端工程师用 Gemini，算法工程师用 GPT，文档工程师用 Kimi，code review 用 Claude。现在你一个人，加一套编排系统，就能覆盖这些角色。不是每个角色都做得比专家好，而是所有角色都能做到 70 分以上——而 70 分乘以效率，往往胜过 90 分乘以排队等待。

孔子说"君子不器"。放在 AI 时代，这句话可以翻译成：未来属于那些能驾驭多个模型协作的人，而不是忠实于单一模型的人。

工具会迭代，模型会换代，但编排思维不会过时。学会拆解任务、匹配能力、持续推进——这套能力比任何单个模型的强弱都更耐用。

这不是 OMO 的胜利，是编排范式的胜利。OMO 只是最先把这条路蹚出来的人之一。