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

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。你只管说"我要做什么"，系统决定"该用谁来做"。

网盘大战又开始了，但我的文件不在任何一家手里

6月16日，腾讯突袭上线了「腾讯网盘」。

OpenCode vs Pi Agent：同一条赛道，两种范式

写在前面：这不是一篇"谁更好"的测评

2026 年的 AI 编码工具生态，有点像 2015 年的智能手机市场——每天有新选手入场，每个产品都有自己的拥趸，社区里充斥着"XX 杀死了 YY"的标题党。

OpenCode 和 Pi Agent 是这场竞赛中最耐人寻味的一对。它们都是开源、终端优先的 AI 编码 agent，都支持多模型，都在高速迭代。但它们解决问题的起点截然不同。一个选择"什么都能干"，一个选择"什么都能改"。理解这个区别，比知道它们各自有什么功能重要得多——因为功能可以复制，但设计范式决定了你能走多远。

本文面向技术管理者。我假定你熟悉"AI 编码 agent 是什么"这个前提，但不要求你了解这两个工具的细节。我们的目标不是帮你"选一个"，而是帮你理解：当团队需要一个 AI 编码框架时，你买的到底是什么。

一、两个产品的定位画像

OpenCode：模型无关的通用 Agent

OpenCode 的故事始于 SST 团队——一个在开源领域积累了深厚声誉的 infra 团队。它的定位非常清晰：做最通用的开源 AI 编码 agent。

170K+ GitHub Stars、900+ 贡献者、13000+ 次提交、月活 750 万开发者——这些数字让 OpenCode 在这个赛道上保持了显著的身位优势。但比数字更重要的是它的架构选择：Go + Bun（JavaScript 运行时）双进程架构。Go 处理底层编排，Bun 运行 TypeScript 脚本。两层之间通过进程间通信协作。

这个选择有两层含义。第一，性能。Go 的并发模型天然适合管理多个并行编码任务，启动快、资源占用低。第二，灵活性。Bun 让用户可以用 TypeScript 写扩展，而不用跳出自己熟悉的语言环境。但代价也很实在——安装包大（约 300MB）、依赖链复杂，用户需要同时安装 Go 和 Bun 两套运行时。

OpenCode 的价值主张可以一句话概括：给你一个随时可用的 AI 编码 agent，和它支持的一切模型。它原生集成了 75+ LLM 提供商，从 OpenAI、Anthropic 到本地运行的开源模型，几乎"即装即用"。LSP 集成、多 session 管理、终端 UI、桌面应用——你能想到的"一个 agent 该有的功能"，它基本都有。

从大教堂到集市

2026年6月

三月三十一号，Claude Code 的源代码被 npm 包泄露了。五十二万行 TypeScript 暴露在公网上，几小时内 fork 超过八万次。Anthropic 发了 DMCA 删除通知，但代码早已扩散，不可撤回。

泄露的源码里什么都有——四十四个隐藏特性标记、一个叫 KAIROS 的守护进程、甚至一个叫 Undercover 的隐身模式，能让你在同事面前假装没在用 AI。

花边而已。真正让我在意的，是泄露之后——什么也没改变。Claude Code 仍然是闭源的，年营收大约二十五亿美元。Anthropic 的策略很清晰：开放 MCP 协议建生态，模型和核心引擎死守不放。所谓"开放生态，不是开源"。

这很聪明。但在我心里种下了一个问题：我们真的需要一个接一个地换闭源工具吗？

说清楚，我不是工具原教旨主义者。过去两年我桌面右下角换过不少东西。Cursor 试了三个月，Windsurf 也试了。GitHub Copilot 一直在续费，但使用频率越来越低。Claude Code 确实强，尤其大型重构和复杂推理，体验比竞品高出一截——但定价让人心惊胆战。

北美开发者社区年初有个段子：一个月 Claude Code 的费用，够买一台 MacBook Pro。不是玩笑。Copilot 六月转向按量计费后，一大批独立开发者措手不及，开始认真算"自己写代码 vs 让 AI 写"的边际收益。

闭源工具的问题不在能力，在定价权和迁移成本。你不只是花钱，你是在把工作流焊死在别人的定价表上。prompt 习惯、上下文模板、调教出来的协作节奏，全绑在一家公司的产品迭代路线上。它改一版定价，你月支出就跳一跳；它砍一个功能，你工作流就裂一道缝。

但真正推动我做决策的，不是成本。是一个更根本的念头——我也懒得折腾了。

换工具的兴奋感大概能维持两周。第一周配快捷键、导主题、调肌肉记忆。第二周写 prompt 模板、搭 MCP 服务器、调教上下文工程。第三周开始发现某个角落的限制，焦虑滋生。再过一个月，新工具发布了又一番 benchmark 狂欢，你忍不住去试。然后循环。

这精力的消耗，远比订阅费昂贵。

去健身房的人都懂：对多数人来说，最好的训练计划不是精挑细选出来的那个——是能坚持下来的那个。工具也一样。折腾的快乐是一时的，稳定的生产力才是持久的。

1997年，Eric Raymond 发表了《大教堂与集市》。大教堂模式：代码在发布时公开，版本间的开发由专属团队封闭控制，beta 版不成熟绝不发布。集市模式：代码在互联网上公开开发，任何人可以检视和贡献——“早发布、常发布、开放到近乎混乱的程度”。

二十多年后再看，当下的 AI 编程工具市场正在上演同样的剧本。Claude Code、Cursor、Copilot，大教堂模式——顶级工程师在封闭环境中精心打磨，每月给你一个惊喜或惊吓。OpenCode、Aider、Cline、Hermes Agent，集市模式——代码在 GitHub 上裸奔，任何人可以 fork、修改、提 PR。

从巫师到赞助人：Claude 5 Mythos 让我重新理解了"跟AI协作"这件事

上周沃顿商学院教授 Ethan Molick 发了一篇长文，标题很朴素——《What It Feels Like to Work with Mythos》。但读完之后我愣了很久。

不是因为 Mythos 多么炫酷——虽然它确实炫酷——而是因为它迫使我重新审视一个我一直以为已经想清楚的问题：人和 AI 到底该怎么合作？

巫师的终结

过去一年多，我用 AI 的方式大概是这样的：打开对话框，写一段精心打磨的 prompt，等它吐出结果，不满意就改 prompt 再来一遍。说白了，我就是个巫师——念咒语，看效果，调咒语。

这个过程虽然比写代码快，但本质上还是"我主导一切"。每一个决策都经过我的手，每一步走向都在我的掌控之内。舒服，而且安全。

Molick 说，面对 Mythos，这种模式失效了。

他用的比喻很妙：以前你是巫师，现在你是赞助人（Patron）。你提出需求，定下愿景，支付 token，然后——

放手。

AI 自己拆解任务，自己派子智能体去查资料、写代码、互相审计、抓 bug。它可能独自工作好几个小时，甚至十几个小时。你不需要参与中间那几百个微小的决策。你唯一要做的，是对最终成品做出判断。

Molick 原话是：“I no longer steer; I commission.”

不再掌舵，只负责委托。

九个半小时的研究软件

让 Molick 真正震撼的，不是一个玩具 demo，而是一个实打实的研究工具项目。

他提出了一个需求：给社会科学研究者造一个软件，用来校准人类判断和 AI 判断之间的偏差——那种学术界很需要但商业上根本没利润去做的工具。

Fable（Mythos 的代号）先花时间写了一份 19 页的设计文档，然后开始动手。连续工作了 9.5 个小时。

最终产出了一个完整的研究软件，能处理多数据集、校准人和 AI 的分类结果、跑复杂的统计分析。Molick 把代码开源了，放到了 GitHub 上。

他自己也坦言：一个专业工程师能很快修掉那些他发现不了的潜在 bug。但他紧接着加了一句意味深长的话——“这恰恰说明未来我们需要更多程序员，而不是更少”。

还有一个案例更离谱。Molick 让 Fable 做一张"等时线通行图"——输入城市和时间上限，就能看到你能到达哪些地方。这个任务需要计算几千条航线、铁路、公路的旅行时间，需要大量的数据检索和判断。之前所有公开模型都搞不定。

《崩溃点》：一个组织最危险的敌人，未必来自前方

高考前不久刚落幕。每到这个时候我就想起一部剧——《兄弟连》。那年高考正值它在央视热播，学业紧得喘不过气，偏偏心里放不下，每天想着偷看一集。这种矛盾的心情，后来每逢六月都会冒出来。

最近重看了第七集《崩溃点》（The Breaking Point）。

大多数人记得的是阿登森林的冰雪、德军猛烈的炮火、巴斯托涅的绝境，还有最后斯皮尔斯穿过战场的经典一幕。这些当然精彩。但多年以后再看，我觉得这一集真正在讲的，不是战争。

是组织。

战争里的敌人看得见，摸得着。看不见的，才真正要命。

彼时的E连，已经是一支逼近极限的部队。补给断了，弹药告急，御寒装备几乎没有，每天都有人倒下。每个人心里都清楚——情况糟透了。可即便如此，连队居然还能撑着运转。

为什么？因为大家心里有一个底：再难，总有人在顶着。前面有人在扛，后面有人在托，中间有人在补。秩序还在，信心就还在。

然而一个组织最可怕的事，从来不是资源枯竭。

而是在最需要有人站出来的时候，那个该站出来的人，站不出来。

第七集里最让人窒息的，不是德军的炮火。是一种弥漫开来的情绪，像冬天的寒气一样渗透到每个人骨头里——

没人知道下一步怎么办。没人知道计划是什么。没人知道谁在做决定。甚至没人知道应该向谁汇报。

战场上出现了一种诡异的现象：所有人都在拼命，组织却在加速失能。士兵在一线死扛，军士长在四处协调，排长在补位顶上，后方在拼命想办法。唯独那个本该承担最终责任的位置，悄无声息地空了。

这种真空不会立刻导致溃败。相反，它往往能维持相当长的时间。因为组织里总有人会主动补位——有人扛下额外的工作，有人自发协调资源，有人默默收拾烂摊子。表面上一切还在转，只是代价在悄悄叠加：责任越来越模糊，情绪越来越压抑，信任一点一点流失。

终于有一天，每个人都开始问同一个问题——

到底是谁在指挥？

有个细节特别真实。戴克不是传统意义上的坏人。他没有叛变，没有贪腐，也没有故意害谁。他的问题只有一个：当组织最需要领导力的时候，他给不了。而这恰恰是最致命的——能力不够可以补，经验不足可以学，但关键时刻的失能，会在极短的时间内摧毁一个团队的信心。

老子说"太上，不知有之"，讲的是最好的领导让人感觉不到领导的存在。反过来呢？最差的领导，恰恰是所有人都意识到了他存在——因为他什么都不做。

很多人记住了斯皮尔斯冲过战场的画面。但让我印象更深的，是温特斯站在后方观察时的表情。他知道问题在哪，也知道再拖下去会发生什么。所以他必须做出那个决定。

这个细节其实揭示了组织管理中最残酷的一条规律：知道有问题的人如果不行动，他和制造问题的人没有区别。

“崩溃点"这个标题取得极好。因为真正的崩溃点，不是佛伊镇前面那片雪地。

是信任耗尽的那一刻。

当大家开始怀疑计划是否存在、决策是否存在、责任是否存在——组织离散架就不远了。

E连最终等来了斯皮尔斯，这是剧情的仁慈。但现实中呢？很多组织没有这份运气。问题不在于缺优秀的人，而在于关键岗位长期失灵却无人纠偏。于是最能干的人越来越累，最负责的人越来越沉默，最有热情的人慢慢离开。留下来的，学会了降低期待。

《孙子兵法》有句话叫"将弱不严，教道不明，吏卒无常，陈兵纵横，曰乱”。说的就是这个——将领软弱，号令不明，上下失序，再好的兵也会变成一盘散沙。两千五百年前的话，放在今天任何一个办公室里，一样扎心。

《兄弟连》最让我感慨的地方在于，它从头到尾没有大声批判谁。它只是平静地把事实摆在那里——

任何团队里，勇气重要，能力重要，资源也重要。

但比这些都重要的，是当关键时刻到来时，那个坐在关键位置上的人，是否真的在那里。