--- id: "archive-013" title: "ORCA：更优雅的 Vibe Coding" description: "工具的堆积并不会自动形成工作流。Agent 需要 Harness，人同样需要 Harness。" url: "https://folklore25.me/archive/archive-013/" contentDate: "2026-07-22" publishedAt: "2026-07-22T06:01:12.000Z" tags: - "含AI生成内容" - "ORCA" - "Vibe Coding" - "AI Native" - "开发环境" aiGeneratedContent: true --- # ORCA：更优雅的 Vibe Coding On Harness, Workflow, and the Person Behind the Agent 很多人在刚开始接触 AI 编程时，都会自然地采用一种叠加式思路：先在 VS Code 里安装一个 Agent 插件，再在终端里打开 Claude Code、Codex、Pi 或 OpenCode；如果某个工具缺少搜索、浏览器、Git 操作或上下文管理能力，就继续安装新的插件、MCP 和脚本。工具数量不断增加，终端窗口越来越多，编辑器侧边栏也越来越拥挤，于是很容易形成一种直觉：工具越多，工作流就越强。 但工具的堆积并不会自动形成工作流。真正决定 Vibe Coding 体验的，并不是接入了多少模型和插件，而是这些能力是否被组织成了一套清晰、稳定、可理解的系统。模型能够读取文件、调用终端、修改代码和运行测试，只解决了 Agent 如何执行任务的问题；作为最终决策者的人，还需要看见任务边界、项目状态、并行关系、分支归属和修改结果。Agent 需要 Harness，人同样需要 Harness。 ![对比图：左侧六个工具被虚线松散连接（"工具堆积"），右侧六个工具以"Workflow"为中心放射连接（"集成 Harness"）](https://media.folklore25.me/archive/content/archive-013/a-workflow-is-not-a-pile-of-tools-8bf8a3bda622.webp) ## Harness 是 Agent 与人共同需要的操作环境 Harness 可以理解为一套为执行者准备的操作环境和约束结构。对于 Coding Agent 来说，文件系统、终端、Git、代码搜索、浏览器和测试工具构成了它的 Harness。没有这些能力，模型只能在聊天框中给出建议，无法真正参与项目开发。但在 Vibe Coding 中，人并没有因为 Agent 能够写代码而退出开发过程。人的工作从逐行编写代码，转向定义需求、拆分任务、选择方案、检查结果和决定是否合并。既然人的角色发生了变化，开发环境也不应继续只围绕手工编辑代码设计。 传统编辑器和终端的问题，并不是能力不足。VS Code 可以安装功能丰富的 Agent 插件，终端中的 CLI Agent 通常也足够强大，Git Worktree 更是早已存在。真正的问题是，这些能力彼此分散，默认由人自行维持它们之间的关系。哪个终端对应哪个分支，哪个 Agent 正在修改哪个模块，某个窗口当前位于哪个目录，哪些任务可以并行，哪些修改已经完成，哪些结果还没有经过验证，往往都需要依靠使用者自己记忆。工具本身知道各自正在做什么，却没有共同构成一个完整的项目视图。 ![对比图：左侧 Agent Harness 五件套（Files/Terminal/Git/Search/Browser）围绕 Coding Agent；右侧 Human Harness 五件套（Project View/Task State/Parallel Work/Decision Points/Review）围绕决策者；二者用 + 号相连](https://media.folklore25.me/archive/content/archive-013/agent-execution-and-human-judgment-both-need-structure-a1091d087aea.webp) ## "传统工具 + AI" 的模式与 ORCA 的重新组织 这是一种典型的"传统工具加上 AI"模式。编辑器仍然假设开发围绕一个主要工作区展开，终端仍然只是独立的命令执行窗口，Agent 则被放进侧边栏或命令行会话中。整个开发过程依旧是线性的：打开一个项目，向一个 Agent 描述需求，等待修改完成，再继续提出下一个需求。即使同时打开多个 Agent，也只是增加了几个彼此缺少结构关联的会话。并行能力确实存在，但管理并行任务的成本仍然由人承担。 ORCA 更重要的价值，不是把更多功能放进同一个窗口，而是重新组织了项目、Agent、终端、Git 和工作区之间的关系。它更接近一种 AI Native 的开发环境：不是把 Agent 塞进旧有开发工具，而是承认 Agent 已经成为项目中的执行主体，并围绕这一事实重新设计交互结构。 ## 一个 ORCA 工作流的样子 一个典型的 ORCA 工作流，可以从新建项目开始。项目本身仍然是一个正常的 Git 仓库，版本管理逻辑没有被隐藏或替代。进入项目后，可以选择平时使用最顺手的 Coding Agent，例如 Claude Code、Codex、Pi 或 OpenCode。这里没有必要为了 ORCA 更换模型，也没有必要相信某个特定 Agent 会因为换了界面就突然变得更聪明。ORCA 的优势不在模型层，而在模型之上的组织层。 假设正在开发一个包含前端界面、用户认证和数据处理模块的 Web 项目。传统的线性做法，是让一个 Agent 依次处理三个模块。它先修改前端，随后处理认证，再继续调整后端数据逻辑。随着任务不断推进，同一个工作区中会积累越来越多相互关联的改动，Agent 的上下文也会逐渐混杂。一旦其中一个方向出现问题，回退和定位都会变得困难。如果中途希望尝试另一种实现方式，还需要额外保存当前状态、切换分支，或者依赖 Agent 自己理解哪些代码应当保留。 在 ORCA 中，更自然的做法是先把这三个模块看作三个独立任务。每个任务都可以直接创建自己的 Git Worktree，拥有独立分支和独立工作目录。前端模块在一个 Worktree 中开发，认证模块在另一个 Worktree 中开发，数据处理模块则进入第三个 Worktree。每个工作区都可以启动自己的 Agent 会话，甚至进一步交给子 Agent 分别执行。不同任务之间彼此隔离，不会因为多个 Agent 同时修改同一份工作目录而相互覆盖，也不会让尚未验证的代码直接污染主分支。 这时，ORCA 所提供的已经不只是"同时打开多个终端"。项目中的并行结构本身是可见的。每个任务对应哪个 Worktree、使用哪个分支、由哪个 Agent 执行，可以在统一的项目环境中被识别和切换。人的注意力不再消耗在记忆窗口位置和终端目录上，而可以集中在更重要的问题上：任务是否拆分合理，Agent 是否理解了需求，某个实现是否值得保留，以及多个模块合并之后是否仍然符合整体设计。 当多个任务完成后，可以由主 Agent或 orchestrator 检查各个分支的结果，运行测试，比较实现差异，并处理合并过程中出现的冲突。简单冲突可以由 Agent 主动分析和解决；涉及业务逻辑取舍的冲突，则应当被明确暴露给人作出判断。这里的重点并不是让 orchestrator 不经检查地自动合并所有代码，而是让合并成为一个有上下文、有验证过程、能够回退的步骤。每个并行任务都有清晰来源，失败的实现可以直接丢弃，成功的实现则可以合并回主线。 ![流程图：一个项目展开为三个并列任务（Task A/B/C），每个任务有独立分支、独立工作目录、独立 Agent；三个任务下方汇合到"比较/合并"节点](https://media.folklore25.me/archive/content/archive-013/parallel-tasks-should-be-isolated-visible-and-reversible-1c7df8dad81e.webp) ## 与 VS Code + CLI 方案的本质差异 这一流程体现了 ORCA 与传统 VS Code 加终端方案之间最本质的差异。使用 VS Code 和 CLI 完成同样的事情当然可行，但需要手动承担大量机械工作。首先要为每个任务规划分支名称，再执行 `git worktree add` 创建多个目录；随后为每个 Worktree 单独打开终端和编辑器窗口，并确保每个 Agent 都在正确目录中启动。为了避免混淆，还需要记住窗口、目录、分支和任务之间的对应关系。如果多个模块需要运行开发服务器，还要处理端口冲突、依赖安装和环境变量差异。任务执行过程中，进度信息分散在不同终端会话里，任何一个窗口关闭或目录切换错误，都可能破坏原有状态。 开发完成后，仍然需要逐个进入分支检查修改、运行测试、提交代码，再切回主分支执行合并。出现冲突时，要重新确认冲突分别来自哪个任务，理解不同 Agent 的修改意图，再决定保留哪一边。如果某个实现最终被否决，还需要清理对应 Worktree 和分支。所有这些步骤都不是高难度操作，但它们会持续占用人的工作记忆。项目越复杂，并行任务越多，这种成本越明显。 因此，不能简单地把 ORCA 的优势总结为"少输入几条 Git 命令"。命令本身并不是问题，真正的问题是传统方案把项目结构藏在命令、目录和窗口之中。人必须自己在脑中维护一张不断变化的映射表：终端 A 对应前端分支，终端 B 对应认证模块，窗口 C 正在运行测试，窗口 D 中的 Agent 已经偏离了最初需求。只要同时进行的任务稍微增加，这张映射表就会成为主要负担。 ## 让隐性状态变成可见结构，重新理解 AI Native ORCA 的优雅之处，在于把原本存在于人脑中的隐性状态转化成可见结构。项目是中心，Worktree 是任务隔离单元，Agent 是执行者，终端和编辑器是操作界面，Git 则负责记录和恢复。各个部分不再只是被同时打开，而是被组织进同一个工作模型中。传统工具要求人围绕窗口和命令移动，ORCA 则试图让工具围绕项目和任务排列。 这也是"AI Native"更准确的含义。AI Native 并不是界面中出现更多聊天框，也不是所有操作都必须交给模型完成。它意味着整个系统的基本结构已经适应 Agent 参与开发这一事实。传统开发工具主要为一个人直接编辑代码而设计；AI Native 环境则需要同时容纳多个执行主体、多个并行任务和多个候选结果，并让最终决策者能够理解和控制这些过程。 ![对比图：左侧"传统"模式编辑器/终端/Git/Agent 聊天用虚线交叉连接（"人脑维护状态"）；右侧"AI Native"模式以"项目"为中心向外辐射到 Worktrees/Agents/终端/Git（"状态可见"）](https://media.folklore25.me/archive/content/archive-013/the-difference-is-not-the-model-it-is-the-structure-00d0567a71c1.webp) ## ORCA 适用的边界 正确使用 ORCA，也不等于把所有任务都拆成尽可能多的 Worktree。并行并不是目标，清晰的任务边界才是目标。只有当两个任务可以相对独立地开发、验证和合并时，才适合分配到不同 Worktree。一个只需要修改几行配置的任务，没有必要启动完整的并行流程；一个会同时触及大量共享核心代码的任务，也不应为了追求形式上的并行而强行拆分。ORCA 降低了并行开发的管理成本，但并不会替代对任务耦合关系的判断。 同样，ORCA 并不适合所有文件操作。如果只是让 Agent 批量重命名文件、转换图片格式、清理一份临时数据，通常没有必要建立 Git 仓库、创建分支和组织 Worktree。ORCA 真正适合的是需要持续维护、需要版本管理、可能产生多种实现方案，并且需要验证和回退的真实项目。只要一个任务已经进入"开发项目"而不是"临时处理文件"的范围，Git 和任务隔离就不再是额外负担，而是控制 Agent 行为的基础设施。 ## 以任务为中心，而非会话为中心 成熟的 Vibe Coding 也不应以聊天会话为中心。聊天只是表达需求和传递上下文的方式，项目才是长期存在的实体。无止境地在同一个会话中追加需求，会让任务边界逐渐模糊，也会使 Agent 越来越难判断哪些约束仍然有效。更合理的做法，是把每次开发视为一个边界明确的任务：定义目标，建立隔离环境，让 Agent 执行，检查结果，然后选择合并或丢弃。一个任务完成后，再开始下一个任务。 从这个角度看，ORCA 并不是为了让一个 Agent 在同一个窗口中做更多事情，而是为了让多个 Agent 在清晰边界内分别完成有限任务，再由人完成判断和取舍。Agent 负责执行，orchestrator 负责协调，人负责定义目标和承担最终决策。只有当这三层关系被明确组织起来，Vibe Coding 才能从"让 AI 帮忙改代码"进一步变成一种真正稳定、可扩展的开发方式。 ![流程图：五步循环——定义任务边界 → 创建 worktree → 让 Agent 执行 → 复审与对比 → 合并或丢弃，第五步返回第一步标注"Next task"](https://media.folklore25.me/archive/content/archive-013/think-in-bounded-tasks-not-endless-chat-sessions-f3ee5a777b46.webp) ## 工具数量不是工作流成熟度的指标 工具数量从来不是工作流成熟度的可靠指标。一个编辑器、五个 CLI、十几个插件和几十个 MCP，也可能只构成一堆彼此割裂的能力。真正有效的工作流，需要清晰的任务边界、可见的项目状态、隔离的执行环境、可验证的结果，以及可靠的合并与回退机制。 ORCA 的价值，正在于它不仅为 Coding Agent 提供工具，也为管理 Coding Agent 的人提供结构。