一、事情是这样的
5月29日凌晨，Anthropic 刚发完 Claude Opus 4.8，顺手把 Claude Code 升级了一波——新增动态工作流和所谓的 ultracode 模式，主打多模型协同与长链路任务编排。发布会的余温还没散，开源圈那边就炸了。
开源框架 OMO 团队在 X 上接连甩出十几条推文，矛头直指 Anthropic：「这是像素级抄袭。」配图是 OMO 今年 1 月公开的架构图，和 Anthropic 官方博客里 ultracode 的工作流示意图被放在一起对比，连命名习惯、节点拓扑、Token 流转方向都高度相似。
如果只看一两个模块，还可以辩解说「英雄所见略同」。但 OMO 团队晒出来的对照，从规划层、协调层到执行层的三段式结构、从动态模型路由到合并审查的回路设计，几乎是一一对应。最让人玩味的是命名风格——OMO 那套带着希腊神话味的命名体系，在 Anthropic 的内部代号里也能找到对应物。
二、先认识一下 OMO 是什么
对没跟过这条线的开发者补个背景。
OMO 不是从零起步的小玩具，它是开源终端 Agent 项目 OpenCode 官方认定的「No.1 插件」。OpenCode 本体在 GitHub 上已经攒了 16.7 万星，是过去半年终端 Agent 这条赛道里最热的开源项目之一。OMO 作为其插件生态的头牌，自己也吃下了 6 万星。
这个项目背后的人也挺有故事。主开发者是一位 23 岁的韩国黑客，社区里只用代号 Q 称呼他；运营和宣发由独立工作室 Sisyphus Labs 负责。这个组合在过去一年里把 OMO 推成了开发者圈子的「次世代 Agent 范本」。
OMO 的核心卖点，是一套模型无关的多智能体动态编排架构，几个关键模块分别是：
- Prometheus：规划器，负责把高层任务拆解成可执行的子任务图
- Atlas：协调大脑，负责跨智能体的合并、审查、冲突仲裁
- Sisyphus Junior：执行器，跑实际的工具调用和代码生成
- ultrawork：把上述三层串起来的动态工作流，会根据任务复杂度自动调整递归深度和并行宽度
再加上一套技能过滤机制，把不该被某个子 Agent 看到的工具屏蔽掉，避免「拿着锤子看什么都是钉子」的退化行为。整套设计的特点是把「规划—协调—执行」三段拆得很干净，每一段都可以独立替换模型。
三、Anthropic 这步操作为什么扎心
OMO 团队这次发飙，气的并不只是「像」，而是整条「先封杀、后吸收」的时间线太刺眼了。
把节点拉一遍：
- 2026 年 1 月，Q 在 OMO 中正式上线 ultrawork 工作流和 Atlas 协调大脑，社区开始大规模试用。
- 紧接着，OpenCode 联合创始人 Dax Raad 在播客里吐槽 OMO 是「Token 燃烧器」——因为它跑多智能体递归时会爆量调用 Claude API，单任务几百万 token 是常态。
- 4 月，Anthropic 出手，单方面收紧政策，封禁第三方客户端使用 Claude 订阅额度的通道。当时官方说法是「滥用」，但社区都看得明白，主要打击对象就是 OMO 这类高 Token 消耗的开源编排框架。
- 5 月 29 日，Opus 4.8 发布，Claude Code 同步上线动态工作流和 ultracode 模式，把 OMO 已经被开源社区验证过的那套机制，装进闭源、装进订阅、装回自家的护城河。
中间只隔了三个月。Q 在推特上的原话翻译过来大意是：「你们先用政策把开源实现踢出去，然后把它的架构图拓下来贴在自己产品手册上。」
这套路径让人想起前几年云厂商对开源数据库做的那些事——只是这次发生在 Agent 编排这个还没成熟的新战场，节奏被压缩到只有几个月。
四、FactoryAI 的旧账也被翻出来了
这场冲突还有个 B 面。OMO 这次没光对着 Anthropic 开火，把 FactoryAI 也一并拖出来挂了一遍。
今年 2 月，FactoryAI 高调发布过一个叫 Missions 的「多天自主任务流」产品，主打长任务、长上下文、可中断恢复。OMO 团队当时就在内部吐槽过架构相似，这次干脆把映射关系直接列出来：
| OMO 模块 | FactoryAI Missions 对应物 |
|---|---|
| 规划器 Prometheus | 计划审批流（Plan Approval） |
| 协调大脑 Atlas | Orchestrator Droid |
| 执行器 Sisyphus Junior | Worker Droid |
| 技能过滤机制 | 简化版的 tool scoping |
基本上是改了个名、套了一层 droid 的皮，逻辑骨架照搬。
FactoryAI 至今没回应。Anthropic 也是同样的姿态——既不承认，也不否认，就是不接话。这种「装聋作哑」反而让事情在开发者圈子里发酵得更厉害，过去 24 小时 OMO 的相关推文转发量翻了好几倍。
五、OMO 的反击姿势
面对大厂的沉默，OMO 团队选择了双线作战。
第一条线是架构原创性的取证。Sisyphus Labs 把 GitHub 上的提交历史、内部设计文档的时间戳、Discord 里的早期讨论记录全部公开，时间链条非常完整——尤其是 Atlas 这个名字第一次出现在仓库里的 commit，比 Anthropic 内部任何已知文档都要早。
第二条线更有意思，是直接打 Anthropic 的商业模式痛点。OMO 团队反复强调一件事：
OMO 是完全 model-agnostic 的，你不需要 Claude 的高价订阅，用本地模型、便宜的 GPT、Gemini，甚至 Kimi，都能跑起 ultrawork 工作流。
这句话翻译过来就是：Anthropic 想靠 ultracode 把开发者锁回 Claude 生态，但 OMO 给的是「同样的架构，但模型自选」的方案。 对预算敏感的团队来说，这是个非常实在的卖点。
Q 还透露，团队正在赶一个基于 GPT-5.5 的 Codex 适配版本，预计很快会发。配合他对 Opus 4.8 的毒舌点评——「这就是个还不错的 GPT-5」——指向性已经很明显了。
说回模型这一层，对国内开发者来说，跨模型跑 Agent 编排的门槛其实没那么高。像 OpenAI Hub 这类聚合平台已经把 GPT、Claude、Gemini、DeepSeek、Kimi 都接在一个 OpenAI 兼容接口下，OMO 这种 model-agnostic 框架要切换 provider，基本就是改个 base_url 的事。这也是为什么 OMO 团队敢这么硬气地喊「不需要官方配额」——可替代供应链已经成熟了。
六、几个值得想的问题
这件事看热闹之外，对开发者其实有几个真问题。
第一，Agent 编排架构有没有「原创性」可言？
说实话，规划—协调—执行这三段式，业界已经有很多类似设计，从 AutoGPT 到 LangGraph 到 CrewAI，谁也没法说自己发明了 multi-agent。但 OMO 这次拿出来的对比，关键不是「三段式」本身，而是具体的协调策略、合并审查的回路设计、动态路由的触发条件——这些工程化的细节决定了一个编排框架是能用还是不能用。Anthropic 如果只是「借鉴了思路」，那争议不大；但如果连这些工程决策都对得上号，性质就不一样了。
第二，开源贡献者的处境到底有多被动？
OMO 用的是 MIT 类的宽松协议，按字面意思 Anthropic 没违反任何许可证。但「合法」和「合理」之间的鸿沟，正是这次冲突的核心。开源社区一直在讨论是不是要给 Agent 框架引入更严格的署名条款（类似 BSD-4 的广告条款，或者 CC BY 的归属要求），这次事件大概率会再次把这个话题推到桌面上。
第三，先封杀后吸收会成为常规操作吗？
4 月那次 API 政策调整，名义上是反滥用，实际效果是给自家自研版本清场。如果这条路径被证明是有效的，其他模型厂商可能也会照做。对开源 Agent 项目来说，这意味着你越成功，越可能在某天突然失去 API 访问权。这对整个生态是个不太健康的信号。
七、接下来看什么
短期内有几个观察点：
- Anthropic 会不会回应。 沉默拖得越久，开发者社区对 Claude Code 新功能的「原创性」就越怀疑。
- OMO 的 Codex 适配版进度。 如果真能在 GPT-5.5 上跑出和 Claude 同等甚至更好的效果，相当于直接打脸 ultracode 的封闭策略。
- OpenCode 母项目的态度。 16.7 万星的体量加进来表态，分量完全不一样。Dax Raad 那句「Token 燃烧器」的玩笑会不会变成正式声明，值得盯一下。
- FactoryAI 的反应。 如果 OMO 这次真的把舆论压力做出来了，Factory 那边大概率坐不住。
这场风波短期内大概率不会有什么「正义伸张」的结果——开源对大厂，向来胜率不高。但它至少把一个一直被回避的问题摆到了台面上：当开源项目验证了一条技术路径之后，原创者除了一句「谢谢」之外，还能要回什么？
答案大概是：要不回什么。但下一次设计协议的时候，会有人记得这次。
参考来源
- 开源神作遭大厂「官方收割」？王牌插件OMO贴脸炮轰Anthropic、FactoryAI像素级抄袭其Agent编排架构！ - linux.do：本次事件的完整时间线梳理与架构对比图原始来源。