津晶在访谈中自述，她同时在推进 400 多个 feature，工作区里有 400 多个 worktree，其中 200 多个按固定流程自动运行。这些数字不能证明团队产能，但能说明她管理任务的方式不是逐个查看 Agent。重复工作交给自动化和 Agent 之间的协作，人只处理无法标准化、影响权限或需要承担结果的部分。
人一旦被叫来，系统不应丢一整段日志或开放式问题，而要把处境整理成 2 到 3 个互斥选项，写清影响、风险和推荐答案。
这也是 ADE 和普通终端的分界。终端保存会话，ADE 还要把任务、状态、例外和选择放进同一套结构里。
1. Agent 一多，人就看不过来
一个 Agent 工作时，人要判断它在做什么、有没有卡住、结果能不能用。会话多到需要靠窗口标题和记忆找状态时，逐个查看就不可持续。
继续增加 Agent，最先暴露的是三个问题。
- 找不到任务对应哪个目录、分支和会话。
- 不知道哪些 Agent 正在工作，哪些在等人回答。
- 结果出来后，没有稳定的评审入口。
单次模型调用只生成一次输出。循环、工具调用和执行状态由 Harness 负责，跨 Harness 的任务分配、恢复和验收则由 ADE 或团队自己的控制层负责。
2. ADE 是多个 Agent 的任务控制面
Harness 把模型、上下文、工具、权限和执行循环组合成一个能工作的 Agent。Claude Code、Codex、OpenCode 和 Pi 都在这一层。Harness 的组件和责任边界见《harness：定义、价值与选型》。
ADE 接收任务，调度多个 Harness，再把执行状态、产物和评审结果收回来。
flowchart LR
M[模型] --> H[Harness]
T[任务] --> A[ADE]
A --> H
H --> E[状态和产物]
E --> A
A --> P[人的判断]
P --> A
Orca 官方文档把产品描述为同时运行多个 AI coding agent 的桌面 IDE，页脚使用的是 agent development environment。ADE 还是一个边界不稳的新词，可以用五个问题检查一个产品是否具备控制面能力。
- 任务对应哪个仓库、分支和 worktree。
- 任务由哪个 Harness 和模型执行。
- Agent 正在工作、等待输入、受阻，还是已经结束，结束后是否待评审或已验收。
- 人从哪里查看产物、批注 diff、打开页面和补充要求。
- 任务完成后，如何回到 GitHub、Linear、CI 和发布流程。
这五个问题分别对应可追溯性、工具选择、例外处理、评审入口和交付。只有界面没有这些结构，产品仍然只是一个终端多开器。
Orca 让后台进程持有 PTY。关闭窗口或自动更新时，Agent 不会跟着退出。机器重启或后台进程崩溃后，Agent 进程仍会消失，只能恢复布局和最后一次保存的输出。会话恢复真正难的部分是保持进程身份、缓存输出、重连界面，并控制几百个会话的资源占用。
3. 人的三个介入点
每一步都让人确认，只会把等待时间转移到审批队列。更合适的做法，是把人的参与压到三个判断点。
3.1 开始前定目标和边界
任务开始时，人要写清目标、验收标准、不能接受的方案、权限边界，以及哪些决定必须停下来问。
复杂任务先做一轮 grill me（让 AI 连续反问，把目标、约束、替代方案和失败边界逐层问清）。
每轮只问当前能回答的问题。AI 先给建议答案，人确认后再进入下一轮。暂时答不了的问题，要么补事实，要么标成待决定项，不要留给模型猜。
目标不清时，Agent 越能干，返工越大。模型会填补空白，但填出来的内容未必是组织真正想要的。
3.2 运行中只处理例外
只有影响目标、权限、外部系统、成本或交付时间的事件才打断人。Agent 遇到高风险动作、价值判断或系统冲突时，也应停下来请求决定。
普通进度写成通知，按影响范围分级。把通知和需要人回答的问题混在一起，状态面板很快就会变成另一个噪声源。
需要人决定时，不要直接丢一整段日志或开放式问题。给出 2 到 3 个互斥选项，写清各自影响、风险和推荐答案。人做的是选择，不是重新理解整个任务。
3.3 结束后验收并承担责任
Agent 只能报告完成。是否真的完成，要看文件、测试报告、接口返回、页面录屏和 PR。
代码任务的验收物是 diff、测试和可运行页面。
研究任务的验收物是来源、结论和未解决的问题。运营任务的验收物是实际状态变化和审计记录。
有些质量很难写成指标，比如代码是否好读、接口是否克制、交互是否顺手。
这些地方要靠人的经验、判断力和品味。品味不能替代验收标准，它处理的是多个合格方案之间的取舍。
人在这里做的不是点一下通过，而是签收结果、决定是否退回，并对后续影响负责。
4. Coding Agent 的可复用工作流
管理海量 Agent，第一步是把重复工作自动化。
没有 SOP、状态上报和定时执行，Agent 越多，人越忙。
自动化提高吞吐，也会放大错误，所以还要有任务边界、状态事件和例外处理。
Orca 的实现可以分成三层：搜索与状态汇总、Agent 管理 Agent、固定流程自动运行。
三层都在减少任务查找、状态确认和上下文重建的成本。
这套流程目前主要适用于 coding agent。
其他领域可以借用对象和控制面，但验收证据、权限边界和执行环境需要重新设计。
flowchart LR
T[任务] --> S[规格与验收]
S --> C[协调 Agent]
C --> W[独立 worktree]
W --> V[PR、测试、页面]
V --> R[人工验收]
R -->|通过| D[交付]
R -->|修改| C
4.1 把任务写成可验收单元
3.1 已经定义了目标、验收标准、禁区和需要人决定的问题。任务进入执行前，还要补上输入材料、执行环境和最终产物，形成一个可验收单元。
重点是让 Agent 知道什么算完成，让人知道最后要看什么。任务描述含糊时，多派 worker 只会同时产生更多错误。
4.2 隔离文件状态，不只隔离 Agent
一个任务对应一个分支、一个目录和一组 Agent。这样可以把任务结果和 Git 历史对上。
worktree 隔离的是文件、未提交修改和 Git 状态。写回各自目录的测试产物彼此独立，但测试进程、端口、数据库、缓存和环境变量不会自动隔离。模型上下文、权限、浏览器登录态和外部系统副作用也需要单独设计。
多个 Agent 同时改同一个目录，问题不只出现在合并冲突。更早的时候，文件和测试结果已经开始互相干扰。
4.3 让协调 Agent 拆分和回收
协调 Agent 读需求、写计划、创建子任务、分配 worker，最后收集结果。
worker 的任务边界要小，至少要能判断该任务是否完成。worker 遇到问题时通过事件提问，不要停在本地终端等待一个没人看到的提示。
4.4 用状态事件记录进度
设计时先把 Agent 状态统一成几类：
- pending
- running
- waiting_for_input
- blocked
- review
- accepted
- failed
每次状态变化写入事件日志。一个最小事件至少包含任务 ID、Agent ID、状态、时间、原因、产物引用，以及是否等待人处理。状态事件既供界面展示，也供协调 Agent、告警和定时任务使用。
界面和搜索可以替换，事件日志要长期保存。否则恢复以后无法判断一个任务做过什么、产物在哪里、失败过几次。
4.5 把重复流程变成定时任务
日报、issue triage、PR 检查和发布前检查都适合自动化。
上线顺序应该是先在禁用状态创建任务，手动触发并确认输入、输出和失败处理，再开启定时运行。任务还要设置失败告警和重试上限，否则错误会在没人看的时候重复发生。
4.6 控制评审队列
评审物要能直接支持一个决定：通过、退回、补充信息，或者升级给权限更高的人。
并发上限应该由评审能力、风险等级和系统稳定性共同决定。执行变快但评审积压时，整体交付不会更快。生产系统还要求每个结果有人验收并承担后果。
5. Orca 的产品方法
Orca 是一个案例，不是这套方法的效果证明。它值得看的地方，是产品如何围绕现有工作习惯设计控制面。
5.1 先兼容现有 CLI
津晶估计，Claude Code 和 Codex 的 CLI 用户远多于桌面应用用户。Orca 最初让用户在自带终端里继续使用这些 CLI，没有要求用户先接受一套完全不同的界面。
用户不需要先相信 Orca 比 Claude Code 更聪明，只需要相信用 Orca 管理 Claude Code 更省事。控制面适配现有 Harness，比重新实现一个 Harness 更容易被采用。
5.2 从替代方案和反馈里找需求
津晶说，团队每做一个新产品，会深度访谈约 100 位用户。问题围绕现有行为，而不是未来意愿。
- 为什么现在要解决这个问题。
- 现在用什么办法。
- 试过哪些替代方案，为什么没有继续用。
- 过去在类似产品上投入了多少时间、钱，或者用过什么临时办法。
- 这笔支出在预算里排第几。
- 谁使用，谁决定，谁承担风险。
这些答案比「如果有产品你会不会用」可靠。用户已经投入的时间和钱，能说明问题是否真实存在。
反馈仍然是输入，不是决策。声音大的用户会放大自己的场景，早期重度用户也可能把产品拉向过度复杂。访谈、内部使用数据和商业数据要一起看，最后由产品团队判断。
5.3 嵌进现有工作流
《FDE 前线部署工程师指南》讲系统做好后怎么让用户真正用起来，其中一条是尽量嵌进现有工作流，不要求用户改掉原有习惯。新系统最大的阻力往往不是旧系统，而是旧习惯。
Orca 对应的是这条原则。开发者已经在 Claude Code、Codex、worktree 和 Linear 里工作，Orca 没有要求他们迁移到一套全新的入口，而是在原入口外增加状态、搜索、评审和编排。
这也解释了 5.1 的兼容选择。先让用户在自己熟悉的地方继续工作，再把新能力加进去。控制面适配现有 Harness，比要求用户换 Harness 更容易被采用。
6. 这套工作流的边界
访谈和 Orca 文档展示的是任务、状态和评审怎么组织，没有系统讨论「一个任务该不该拆给多个 Agent」。并行 worktree 是产品能力，不等于所有任务都适合拆。
这里的工作流只限定在 coding agent。任务依赖强、共享状态多时，拆分会增加合并成本。具体拆分方式属于另一层问题，见《Agent Orchestration - 智能体编排》。
涉及医疗、金融、生产和真实用户数据的任务，还需要额外的审批、审计、回滚和权限隔离。三个通用判断点不能替代高风险场景的中间检查。
7. 怎么判断是否有效
不要只看启动了多少 Agent。更有意义的指标是：
- 完成一个任务需要人介入几次。
- 每次介入花多少时间。
- 首次验收通过率。
- 返工率和回滚率。
- 任务从创建到交付的周期。
- 每个完成任务的模型、机器和人工成本。
Agent 数量说明系统规模。完成率、人工介入次数和交付周期才反映系统产出。
8. 人的判断量决定上限
ADE 的价值在于把多个 Harness、任务、状态和评审放进同一个控制面，让 Agent 的执行结果能够回到任务和交付流程。
Orca 的案例说明，一个 Agent 平台可以先兼容已有工具，再从现有替代方案里找产品方向。它的关注度不能证明所有团队都能管理 400 个 worktree，但访谈和文档展示了任务、状态和评审如何组织。
系统需要规定人何时出现、出现时看到哪些信息、能做什么决定。Agent 可以继续扩容，人每天能处理的判断量却不会同步增长。稳定流程交给自动化，例外送进人的队列，需要决策时只给出少量、通俗、后果明确的选项。
Agent 编排的上限，最终取决于人的判断量，以及系统能否减少无用的上下文切换。
9. 参考
- 课代表立正 · 2026-09-18 对 Orca 联合创始人津晶的访谈，本文产品细节和创业方法的主要来源
- Orca GitHub 仓库 · 开源许可证、支持的 Agent 和项目状态
- Orca 文档 · Orca 对桌面 IDE、worktree、Agent 和运行方式的定义
- Orca Session restore · PTY、后台进程和会话恢复的边界
- Orca Orchestration · Run、Task、Dispatch、消息和人工决策门
- Orca Scheduled automations · 定时任务、预检查和运行位置
- Orca Quick Open · 跨 worktree、会话和任务的搜索
- Orca Diff viewer · diff 查看和评审入口
- Orca Mobile companion · 移动端查看和跟进 Agent
- FDE 前线部署工程师指南 · 系统嵌入现有工作流、降低采用门槛等 FDE 交付方法