换了三个工具后,我们把 AI 编码的工作台留在了 Orca

去年我们开始用 Warp 配 Claude Code、Codex 这类编码 agent。一开始是一个 agent 一个活，后来工作流越跑越顺，交给 agent 的任务越来越长，人坐在旁边等就变得不耐烦，等一个任务跑完的工夫，不如再开一个。agent 就这样越开越多，而人的精力是有限的：四五个窗口同时在跑，切来切去，常常反应不过来其中某个任务做到哪了、上下文是什么，出错就是从这时候开始的。

Warp 先撑不住的不是功能，是性能：agent 开多了就卡，卡死也是常事。我们开始看别的工具。herdr 太简陋，它更适合装在远程服务器上管长会话，不是我们想要的日常工作台；Multica 反过来，太重了，agent 处理问题的细节被它包掉一层，过程看不见，在软件开发里这是硬伤。这一圈试下来我们反而想明白了自己要什么：不是再找一个终端，而是一个为「人管 agent」设计的管理面。

这类工具现在有个统一的名字：ADE，Agentic Development Environment，智能体开发环境。这个词是 Warp 打出来的，它在 2025 年 6 月发布 2.0 版本时自称「第一个 ADE」。和 IDE 相比，ADE 管理的一等对象不再是文件，而是 agent 的任务、分支和运行状态。

最后留在 Orca，决定性的一点是它的所有功能都围着同一个概念做：任务看板、基于 worktree 的任务分发、文件树，拆开看都是普通功能，合在一起恰好是一个 ADE 该有的样子：每个 agent 在独立的 worktree 里干活，看板把每个任务的状态摊开，文件树让产物一眼可见。Orca 是 GitHub 上的开源项目（MIT 协议，6.9 万星，今年 3 月才出现），桌面、手机和远程主机三端都能用；能跑的 agent 不挑，Claude Code、Codex、Pi、Grok 这些命令行 agent 都行，模型走的是你自己的订阅。

还有一个能力我们越用越看重：agent 之间可以相互调用，这让「多个相互独立的第三方审批」变得可行，对 SDLC 工作流来说正合适。SDLC 是软件开发生命周期的缩写，指需求、设计、构建、测试、部署、运维这六个阶段的流程。AI 把构建阶段压到以小时计之后，传统流程的控制点陆续失灵，怎么重建流程是今年的行业大话题：亚马逊云科技（AWS）去年 7 月提出 AI-DLC（AI 驱动的开发生命周期），Anthropic 今年 8 月发布《The AI-Native SDLC playbook》，主张每个阶段以提交的工件结束、工件链即审计链、需要判断的决策留给人。后者的核心判断我们在第 10 期聊过：代码不再是瓶颈，流程才是。

我们在一个项目里按同样的思路把这条链写成了仓库宪法：写码的 agent 交付前，必须由另一个不同模型的 agent 独立评审，评审看的是工件本身和验收标准，不是作者的口头总结，评审结论随工件一起入库；人只出现在守门点上，受理需求、签收设计、批准发布。这套流程前几天刚完整跑过一遍技术选型，从立项、设计到评审、签收，每一步的工件都在仓库里。

现在最忙的时候，我们同时跑五个 agent。这个公众号每天早上的热点采集跑在 Orca 的定时任务上，七点自动起一个会话，把前一日 AI 圈的重点采进知识库，漏跑有六小时宽限；手上一个客户项目同时挂着三个工单，各开一个 worktree、各跑一个 agent，人只在派活和验收两头出现。写这篇稿子的会话，本身也跑在 Orca 里。

用下来的变化是具体的：看板把任务面板理干净了，进程切换的负担直接降下来；文件树让产物一目了然，不用再靠记忆去追某个 agent 改到哪了。不满也有两个，照实说：worktree 的创建表单还不够方便，我们希望有更智能的创建方式；它的 issue 强制绑定 GitHub 或者 SaaS 任务管理平台，对不用这些平台的人是个限制。

为什么愿意为一个工具写这么多？因为我们一直认为，AI 完全颠覆了软件开发这件事，围绕 IDE 的工作方式、以及长在 IDE 上的各种插件，已经适应不了生产方式的变动，业内必定会有新的生产工具诞生，ADE 可能就是那个新答案。大模型是不是 AGI 的版本答案，我们之前也聊过；但大模型还在发展，人类天才们还在找 AGI 的最终答案，生产方式可能还会变，最终我们会走向哪里，任何结论都还为时尚早。Orca 是我们当下这一站的答案，先把它用好。这个号写的都是我们自己在用的工具和做法，没有厂商供稿，想跟着看可以点关注。