用 Orca 组建 AI 编程舰队：多个命令行 Agent 并行开工的工作流完全拆解

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

先把结论摆在最前面：如果你已经在同时用 Claude Code、Codex 这类命令行 AI 编程工具，那你迟早会被"在好几个终端窗口之间反复横跳"这件事拖垮——忘了上一个 Agent 在干嘛、搞混分支、两个 Agent 改同一个文件打架，全是高频翻车点。Orca 这款开源工具给出的解法是：给每个 Agent 分一块互相隔离的 git worktree（独立工作目录），让它们各写各的、互不污染，再把所有 Agent 的进度、对话、代码改动收进同一个面板里集中看。它本质上是一个"Agent 编排台"，自己不产代码，而是当多个 AI 工人的总控室。它免费、开源（MIT 协议），桌面端覆盖 macOS、Windows、Linux，还配了手机 App 远程盯进度。 我自己把这套流程跑顺之后，最直观的变化是：一个需求可以同时撒给三四个 Agent，回头挑最好的那份合并，效率和过去串行排队完全不是一个量级。

这篇文章我会从底层的 git worktree 原理讲起，把 Orca 的并行机制、统一面板、内置终端浏览器、手机协同、Agent 兼容性逐个拆开，再给一套可以照着抄的安装与实操步骤，最后聊聊它适合谁、踩坑点在哪，以及在国内环境用这类工具要注意的合规细节。想看完整拆解，往下翻。

从"在终端之间反复横跳"说起：单个 Agent 为什么不够用了

自从命令行形态的 AI 编程助手火起来，几乎每家做大模型的厂商都端出了自己的 Code CLI。结果就是，很多人的桌面慢慢变成了这个样子：三四个终端窗口并排铺开，一个跑着这家的 Agent，一个跑着那家的，还有一个在做收尾。

我自己折腾下来，最大的痛点不是哪个模型不够聪明，而是人脑被迫去做调度这件事。你像个空管员一样，给左边那个 Agent 发完指令，切到中间看看进度，再切回左边检查输出，最后还得去右边收个尾。听上去不复杂，真干起来你会发现注意力被切得稀碎。

这里面有个工程上很硬的概念叫上下文切换成本。说人话就是：人在两个任务之间来回切的时候，大脑没办法瞬间"加载"出另一个任务的全部细节，每切一次都要花几秒到几十秒重新进入状态。Agent 越多，这个隐性损耗越大。我有好几次切回某个终端，盯着屏幕愣是想不起来这个 Agent 刚才被我派去干啥了；更狠的一次，是两个 Agent 各自改了同一个文件，合并的时候直接冲突，排查加解冲突又搭进去小半个钟头。

把这些坑归一下类，单 Agent、多终端的手工模式，问题集中在三块：

• 记忆负担：任务一多，你得自己在脑子里维护"哪个窗口对应哪个任务、哪条分支"，记错了就出乱子。
• 状态不可见：每个 Agent 是不是还在跑、跑完没有、卡在哪一步，你不主动切过去看就完全两眼一抹黑。
• 隔离缺失：多个 Agent 共用一个工作目录时，文件层面没有天然隔离，改同一处就打架。

所以问题就很清楚了：有没有办法让多个 AI 编程助手真正并行地各干各的，同时又把它们的产出统一收到一个地方来看和对比？我前前后后试过几种土办法——给每个 Agent 单独开一个仓库副本、或者老老实实排队串行跑——前者磁盘和同步成本高得离谱，后者直接把"并行"这个最大的好处给阉割了。

真正让我觉得"这事儿有解"的，是后来接触到的一套思路：用 git 自带的 worktree 机制给每个 Agent 划一块独立工作区，再在上面套一个统一的控制台。Orca 就是把这套思路产品化得比较彻底的一个开源项目。在展开讲它之前，得先把 worktree 这个底层积木说明白，不然后面所有的"隔离""并行"都是空中楼阁。

先吃透一个底层概念：git worktree 到底帮你解决了什么

很多人用了好几年 git，都不知道 git worktree 这个命令的存在。它其实从 Git 2.5（2015 年）就有了，只是平时没什么存在感。但它恰恰是"多 Agent 并行"这件事的地基，值得花点篇幅讲清楚。

先用一句白话定义：worktree（工作树）让你在同一个仓库里，同时把多个分支签出到不同的目录，每个目录各自独立、互不打扰。

平时我们 git clone 一个仓库，git 会做两件事：在 .git 目录里放一份"裸仓库"（提交历史、对象、分支这些元数据全在这），然后在外面铺开一份工作目录，也就是你能看到、能改的那些源文件。这份工作目录，就是默认的"主工作树"。问题在于，默认情况下一个仓库只有一份工作目录，你想切到别的分支，就得 git checkout，而切换会把当前目录里的文件整个换掉。

这就引出了那个经典的尴尬场景：你正在 feature 分支写新功能，代码写了一半还不能提交，这时候线上突然冒出个紧急 bug，要你立刻切到主分支去修。怎么办？传统做法要么 git stash 把改动暂存起来，要么先随便 commit 一个半成品。两种都别扭：stash 偶尔会让人忘了自己存过什么，半成品 commit 又脏了提交历史。

worktree 的思路完全不同——它不让你"切"，而是让你"分身"。打个比方：如果说 git 仓库是一栋大楼，那每个 worktree 就是从这栋楼里隔出来的一间独立办公室。每间办公室可以摆不同的项目（不同分支），但水电、网络这些公共设施（也就是 .git 里的提交历史、远程连接）是全楼共享的。你可以在 A 办公室写新功能，在 B 办公室修 bug，两边的桌面互不影响。

落到命令上，核心就这么几条：

# 在 ../hotfix 目录下，基于 main 新建一个 hotfix 分支并签出
git worktree add -b hotfix ../hotfix main

# 查看当前仓库下所有的工作树
git worktree list
# 输出大致长这样：
# /path/to/repo          abc1234 [main]
# /path/to/repo-hotfix   def5678 [hotfix]
# /path/to/repo-feature  9a8b7c6 [feature/login]

# 用完之后干净地删掉某个工作树
git worktree remove ../hotfix

# 清理那些目录被手动删了、但记录还残留的"僵尸"工作树
git worktree prune

它和"多 clone 几份仓库"最大的区别，在于底层对象库是共享的。也就是说，五个 worktree 并不会让你的提交历史、对象数据复制五份，它们共用 .git/objects 这一份底座，只是各自有独立的工作目录和暂存区。这一下就把磁盘占用和同步成本压下来了。下面这张表能把几种做法的差异看得更直观：

有一个关键约束一定要记住：同一个分支在同一时刻只能被一个 worktree 签出。换句话说，主工作树已经在 main 上了，你就不能在另一个 worktree 里再签出 main，要么换个分支名，要么用 --detach 直接定位到某个提交。这个限制其实正中"多 Agent 并行"的下怀——本来我们就希望每个 Agent 待在自己的分支上，天然就不会撞车。

我自己第一次真正体会到 worktree 的好，是在一次很狼狈的场景里。当时我在一个 feature/refactor 分支上做一个大重构，文件改了几十个，乱七八糟全是半成品，根本没法提交。偏偏这时候测试环境上爆了个 bug，要我立刻基于 main 出个修复。搁以前我只能含泪 stash，然后切分支、修 bug、切回来再 pop，中间还得祈祷 stash 别出岔子。那次我改用了 worktree——一条 git worktree add ../hotfix -b hotfix main，瞬间在隔壁目录开出一间干净的"办公室"，我在那儿安安静静把 bug 修了、提交了、推上去了，全程我那个重构分支的几十个半成品文件一个都没动。修完回到原目录，重构现场原封不动，接着干。那一刻我才真切感觉到，这东西解决的不是什么花哨需求，而是开发里最高频、最让人心烦的"被打断"问题。

理解了这个单人场景，再把它放大到"多 Agent"，逻辑就完全打通了。一个人需要"分身"去并行处理多件事，多个 Agent 同样需要各自独立的工作空间才能真正并行。worktree 本来是给人用的，但它天生就适合拿来给一群 Agent 划地盘。

讲到这你大概已经品出味了：worktree 给"多 Agent 并行"提供的，正是那层最关键的物理隔离。 每个 AI Agent 拿到一块独立的 worktree，就等于拥有了一间自己的办公室，它在里面随便改、随便建文件，都污染不到别人。一个 Agent 写前端、一个写后端、一个跑测试，三块工作区互不见面，最后再由你来决定哪一份的成果合进主分支。

不过话说回来，光有 worktree 还不够。手动去 add、list、remove 一堆工作树，再分别开终端、分别启动 Agent、分别盯状态，操作量同样不小。真正要把这套机制用顺，你需要一层把 worktree 的创建、Agent 的调度、状态的展示全都接管过去的"外壳"。这层外壳，就是接下来要聊的主角。

Orca 是什么：它把自己定位成 ADE，而不是又一个 IDE

Orca 是一个开源项目，作者是一支叫 Stably 的小团队（这家是 YC 孵化过的创业公司），项目用 TypeScript 加 Electron 写成，开源协议是相当宽松的 MIT。截至我写这篇文章时，它在 GitHub 上的 Star 数大概在 7700 上下（开源项目热度涨得快，这个数字请以仓库页面的实时显示为准），仓库地址是 https://github.com/stablyai/orca，官网在 https://onorca.dev。

用一句话概括它的核心价值：让多个 AI 编程助手在彼此隔离的工作区里并行干活，再把结果集中到一个界面里查看和对比。

它的设计理念其实很朴素：把每个 AI 都当成一个独立的"工人"，Orca 负责给每个工人分一块单独的工作区（也就是上一节讲的 git worktree），你本人坐在中央控制台统一调度。有了这层东西，你不用再在好几个终端窗口之间手忙脚乱地切来切去，所有任务的进度一眼就能看全。

这里有个细节我觉得很能体现它的野心——官方刻意没把自己叫做 IDE，而是造了个新词：ADE，Agent Development Environment（智能体开发环境）。这个区分不是玩文字游戏。传统 IDE 是为"人"设计的，编辑器、调试器、文件树，全都围着一个坐在屏幕前敲代码的人转。而 ADE 的出发点是"人 + 一群 Agent"：它假设你大部分时间不是在亲手写代码，而是在派活、看进度、审产出、做合并。所以它把 worktree、终端、浏览器、CLI 这些东西按"方便编排 Agent"的逻辑重新组织了一遍。

有个背景信息我觉得值得补一句，能帮你判断这个项目靠不靠谱。Orca 背后这支团队的核心成员，有在大厂做过浏览器底层的工程经验（公开资料里提到主创之前在 Google Chrome 团队做过资深工程师），这也解释了为什么它在内嵌浏览器、终端渲染这些偏底层的地方做得比一般的同类工具扎实——这些不是随便拼个壳子就能做出来的。另一个能反映项目状态的信号是它的迭代速度：从公开的更新记录看，它几乎是每天都在发版本、修问题、加功能。对开源工具来说，"还在被高频维护"这件事本身就是个重要的加分项，意味着你遇到的 bug 大概率有人在管，而不是丢一个半成品就跑路了。我（莫潇羽）个人选开源工具时，活跃度一直是排在前面的考量，一个半年没动静的仓库，功能再花哨我也得掂量掂量。

为了让你对它和传统方案的差别有个直观印象，我把官方和实际体验里比较突出的几个点整理成一张对照表：

说实话，刚看到"又一个 AI 编程工具"的时候我是有点麻木的——这赛道一天能冒出八个新玩意儿。但 Orca 让我愿意认真用下去的点在于，它不抢任何一个 Agent 的活，只做总控台。它不替你决定该用哪个模型、也不自己生成代码，它解决的是"多 Agent 协作"这个被严重低估的工程问题。换个角度看，单个 Agent 的能力是各家大模型厂商在卷的，而"怎么把好几个 Agent 高效地组织起来"这件事，过去几乎是个空白，全靠开发者自己用终端和脚本硬凑。Orca 想补的就是这块。

接下来的几节，我会把它最核心的几个机制一个个拆开——并行工作区、统一面板、内置终端和浏览器、手机协同、Agent 兼容性。每一块我都尽量讲清楚"它具体怎么运作"以及"为什么这么设计"，而不是停留在功能罗列。

核心机制一：并行工作区，让多个 Agent 同时各写各的

这是 Orca 最核心、也是最值得讲的能力，没有之一。

它的玩法是这样的：你可以把同一个需求，一次性撒给好几个 AI 编程助手。每个 Agent 接到活之后，都会在一块独立的 git worktree 里开始写代码。它们彼此之间完全不照面，各自待在自己的分支上推进。等都跑完了，你在 Orca 的界面里直接对比不同 Agent 交出来的结果，挑出质量最高的那一份，合并到主分支。官方给这个动作起了个挺形象的说法——"把一个 prompt 扇形分发给五个 Agent，比完之后合并赢家"。

我用一张流程图把这个过程画出来，会比纯文字清楚得多：

flowchart TD
    A[你写下一个需求 prompt] --> B{Orca 扇形分发}
    B --> C1[worktree A：Claude Code]
    B --> C2[worktree B：Codex]
    B --> C3[worktree C：另一个 Agent]
    C1 --> D1[分支 feature/a 独立产出]
    C2 --> D2[分支 feature/b 独立产出]
    C3 --> D3[分支 feature/c 独立产出]
    D1 --> E[在统一面板里对比三份结果]
    D2 --> E
    D3 --> E
    E --> F[挑出最优的一份合并进 main]

为什么这个模式值得专门拿出来吹？我自己用下来，它至少在三个层面带来了实打实的变化。

第一，它让"模型对比"变得几乎零成本。 同样一句需求，不同的 Agent 给出的实现思路可能天差地别——有的爱用现成的库、有的喜欢手写、有的在边界处理上更细致。过去你想横向比，得自己把同一个需求在不同工具里各跑一遍，再人肉 diff，麻烦到大多数人根本懒得做。现在并行一跑，三份方案摆在一块儿，谁更贴合你这个项目的风格，一目了然。这种"用结果说话"的对比，比看任何榜单都靠谱。

第二，它把串行等待压成了并行推进。 多个任务可以同时跑，不用排队。一个典型的分工是：让一个 Agent 写前端页面，另一个去搭后端接口，第三个专门做代码审查。三件事同时滚动，整体的吞吐量自然上去了。我后面会专门有一节讲我常用的几套编排打法。

第三，它从物理层面把冲突风险摁住了。 这点正是上面那节 worktree 原理的延续——每个 Agent 在自己独立的 worktree 里干活，文件层面天然隔离，根本不会出现两个 Agent 抢改同一个文件的情况。冲突这件事，被从"事后解决"提前变成了"压根不发生"。当然，最终往主分支合并的时候，如果两份产出动了同一处逻辑，该面对的合并取舍还是要面对，只不过这时候是你在清醒地做决策，而不是被动地救火。

这里我得插一句新手友好的提醒：并行不等于无脑撒网。 不是任何需求都适合一口气甩给五个 Agent。如果是个边界特别清晰、答案基本唯一的小任务，单个 Agent 串行做完全够，扇形分发反而是浪费算力（也浪费你各家订阅的额度）。并行真正发光的场景是两类：一类是"我不确定哪种实现更好，想让几个方案打个擂台"；另一类是"这一坨活本来就能拆成互不依赖的几块，那就拆开同时干"。把这两类场景识别出来，并行的价值才用得到刀刃上。

讲完了"为什么并行"，下一个很自然的问题是：这么多 Agent 同时在跑，我怎么知道每个都进展到哪一步了？这就轮到 Orca 的第二块核心能力——统一编排面板。

核心机制二：一个面板统管所有 Agent 的状态，告别窗口切换

如果说并行工作区解决的是"怎么让 Agent 同时干活"，那统一面板解决的就是"怎么让我一个人看得过来"。这两块是配套的，缺一不可——光能并行、却看不清，那只是把"在终端之间横跳"换成了"在脑子里横跳"，没本质改善。

Orca 的界面布局，我用熟之后的体感是这样的：左边是一整列正在运行的 worktree，每一条都标着当前的状态，是还在跑、已经完成、还是卡在那等你拍板。点开任意一个 worktree，右边就铺开这个 Agent 的完整上下文——它和你的对话历史、它改了哪些代码、终端里吐出来的实时输出，全在一个视图里。

这种集中式的好处，得真正多 Agent 跑起来才体会得到。我挑三个对我帮助最大的点说说。

实时追踪，不用主动去问。 过去多终端模式下，你不切过去看，就永远不知道某个 Agent 到底跑完没。现在所有 Agent 的状态在左侧一列里平铺着，哪个在转圈、哪个亮了完成、哪个在等你授权（比如它想执行一条需要确认的命令），扫一眼就清楚。这把"我得记着去查进度"这件事，从主动轮询变成了被动接收。

上下文不丢，任务不串。 所有任务都收在同一个界面里，每个 worktree 自己的对话和改动是绑定在一起的。我再也不会出现"切回某个窗口、对着屏幕想不起来这是在干啥"的窘境了——点进去，前因后果都在。这一条听着小，但对降低心智负担的作用特别大。

快速对比，挑活方便。 想横向比几个 Agent 的产出，在不同 worktree 之间点来点去就行，代码改动、diff 都摆在那。挑哪份合并、哪份丢弃，决策链路很短。

这里我想多聊一句这个面板背后的心智变化。多终端时代，你的注意力是被工具牵着走的——哪个窗口在闪、哪个在响，你就被动地扑过去。统一面板把这个关系倒过来了：所有 Agent 的状态平铺在你眼前，你是主动地扫视全局、按优先级决定先处理谁。这个差别看着细微，体感上却是从"救火队员"变成了"调度中心"。我自己最明显的感受是，并行跑四五个 Agent 的时候居然比过去跑两个还轻松，因为我不用再在脑子里维护那张"谁在干啥"的表了，面板替我记着。说到底，人的精力是最稀缺的资源，一个好的编排工具的价值，恰恰在于它把你从"维护状态"这种纯消耗的事里解放出来，让你能把脑力花在真正需要判断的地方——派什么活、合哪一份、怎么取舍。这才是"编排"这两个字对个人产出的真正意义。

Orca 在"审查 Agent 产出"这块还做了一个我很喜欢的细节：你可以在某一行 diff 上直接写批注（markdown 格式的评论），把这些批注攒成一批，然后一键打回给 Agent 让它改。这等于把"代码评审"做成了和 Agent 之间的一个闭环——你不用复制代码、切回终端、重新组织语言描述问题，直接在 diff 上圈点，意见就回流到了 Agent 那里。对习惯了 GitHub PR 评审节奏的人来说，这套交互非常顺手。

顺带一提，它还原生集成了 GitHub 和 Linear 这类工具，PR、issue、项目看板可以直接在应用内浏览，从某个任务直接拉起一个对应的 worktree 来处理，省掉了在浏览器和编辑器之间反复跳的麻烦。这部分对接的是境外的协作平台，国内团队如果用的是 Gitee、Coding、自建 GitLab 这类国内平台，能否对接、对接到什么程度，建议以官方文档的实时说明为准，别想当然。

核心机制三：内置终端和浏览器，把"看效果"也收进同一个窗口

一个编排工具，光会派活和看 diff 还不够。真实的开发里，你总得跑命令、总得看页面跑起来长什么样。Orca 在这两件事上都做了内置，思路依然是"别让你为了一件事专门切出去"。

先说终端。 Orca 内置了一个基于 WebGL 渲染的终端。这个技术选型说人话就是：渲染交给显卡来扛，所以即便你刷出大量输出、疯狂滚屏，它也不太会卡。它支持无限分屏，你可以把窗口切成好多块，每块跑不同的东西；而且滚动历史在应用重启之后依然保留，还能全文搜索。官方把这套终端的体验对标到了 Ghostty 那个级别——Ghostty 是近一两年开发者圈里口碑很好的一款终端，能拿它当标尺，说明 Orca 在终端这块是认真下了功夫的，而不是随便塞一个能用的进去交差。对于本来就重度依赖命令行的人，这个内置终端基本可以当主力终端用。

再说浏览器，这块是我觉得最惊艳的。 Orca 内置了一个真实的 Chromium 浏览器窗口（注意是真实的浏览器内核，不是截图或者模拟），而且是每个 worktree 配一个。你可以在这个浏览器里预览自己正在开发的网页，然后——重点来了——点击页面上任意一个 UI 元素，Orca 会自动把这个元素的 HTML、CSS 结构连同一张裁切好的截图，一起注入到 Agent 的提示词里。

官方给这个功能起了个名字叫 Design Mode（设计模式）。我第一次用的时候有点小震撼。做过前端的都懂那个流程有多繁琐：发现某个按钮样式不对，你得先 F12 打开开发者工具、找到对应的 DOM 节点、复制结构、再截个图、回到 Agent 那里用文字描述"就是右上角那个蓝色按钮，圆角太大了"。一套下来好几步，还经常描述不清。现在呢？在内置浏览器里直接点那个按钮，元素的结构和外观就自动喂给 Agent 了，你只要补一句"把圆角改小一点"就行。它把"人肉传达视觉信息给 AI"这个一直很别扭的环节，压缩成了一次点击。

我把传统改 UI 的流程和 Design Mode 的流程并排列一下，差距很直观：

这个能力背后其实藏着一个更大的趋势：AI 编程工具正在从"只懂文本"往"能感知界面"演进。代码本质是文本，过去 Agent 擅长处理文本，但前端开发里有大量信息是视觉的、是空间的，靠纯文字描述天然损耗严重。Design Mode 这类设计，是在给 Agent 补上"看得见页面"这只眼睛。等这类能力再成熟一些，前端这种强视觉反馈的活，人和 Agent 的协作方式还会有不小的变化。

核心机制四：手机端协同和远程工作区，让你离开电脑也能盯进度

Agent 跑长任务的时候，有个很现实的问题：它可能要跑十几分钟甚至更久，你总不能一直守在电脑前盯着。Orca 在这件事上给了两条路。

一条是手机 App。 它提供了 iOS 和 Android 的配套应用，通过手机和你的桌面端配对之后，你可以随时查看各个 Agent 任务的实时状态、查看额度用量、甚至远程给 Agent 发新指令。当某个 Agent 完成任务时，手机会收到推送通知。这个功能对经常通勤、出差的人挺实用——想象一下，你在地铁上收到通知，知道某个 Agent 已经把一轮代码写完了，可以马上点开看结果，或者顺手回它一句"这里再调整一下"，让它继续往下推。等于把"盯 Agent"这件事从工位上解放了出来。

需要说明的是，手机端这类功能版本迭代很快，具体支持到哪些操作、安装包从哪获取，请以官网 https://onorca.dev 和应用商店的实时信息为准，我这里就不贴具体下载链接了，免得过段时间失效误导人。

另一条是远程工作区（SSH worktree）。 这个面向的是另一类需求：你本地机器性能一般，但手头有一台配置很猛的远程服务器。Orca 支持通过 SSH 连到远端机器上，在那台机器上完整地跑 Agent——文件编辑、git 操作、终端，全都在远端进行，还自带断线自动重连和端口转发。这样你本地就是个轻量的控制端，真正吃算力的活全压在远程那台机器上。对做大型项目、或者需要特定环境（比如某些只能在 Linux 服务器上跑的依赖）的人来说，这条路很关键。

把手机端和远程工作区放一块看，你会发现 Orca 想表达的是一种"开发不必被绑死在某一台电脑前"的姿态。控制和执行可以分离：执行可以在远程的强力机器上，监控和指挥可以在你手机上。这种解耦，正是"编排"这个词的应有之义。

支持哪些 Agent：从 Claude Code 到国产命令行工具，几乎来者不拒

聊了这么多机制，还有个绕不开的问题：Orca 到底能接哪些 AI 编程助手？

答案是——几乎所有能在终端里跑的命令行 Agent，它都能接。 官方预置开箱即用的就有二十多种，常见的境外工具像 Claude Code、Codex、Gemini、Grok、Cursor CLI、GitHub Copilot、OpenCode、Amp 等都在列；它的一个核心原则叫"自带订阅"（Bring Your Own Subscription），意思是 Orca 自己不卖模型、也不要你在它那再登录，你把已有的各家订阅插进来，就能在同一个界面里并排跑。

这里要给国内读者重点说一段，因为前面提到的那些工具里，有相当一部分是境外的大模型服务。在国内环境使用境外模型服务，需要遵守国内网络与内容管理的相关规定，这一点务必心里有数，别图省事踩了线。好在 Orca 这套"任何 CLI Agent 都能接"的开放架构，恰恰给了国内开发者一个很合规的选择：直接接国产的命令行 AI 编程工具。

国内这两年的命令行 AI 编程生态其实起得很快，而且很多是数据在国内云上、符合国内合规要求的方案，举几个有代表性的：

• Qwen Code：阿里在 2025 年开源的命令行 AI 编程工具，是国内大厂里较早做这个形态的，主要搭配 Qwen 系列模型。
• Qoder CN（原通义灵码）：阿里云的智能编码产品，底层支持 GLM、DeepSeek、Kimi、MiniMax 等国内主流大模型，全链路在国内云上部署，主打金融、政务这类对数据安全和合规要求高的场景。（产品名称和品牌近期有过调整，以官方最新公告为准。）
• OpenCode：走"本地优先、模型中立"路线的开源项目，内置了 provider 抽象层，可以对接 Qwen、Kimi、DeepSeek、GLM 等国内模型，对数据安全要求极高、需要私有化部署的团队比较合适。
• 此外还有腾讯系的 CodeBuddy 等。这个赛道目前迭代极快，工具的存续状态、免费政策、模型支持范围随时