Git Worktree on KnightLi Blog

¿Cómo ejecuta Orca Codex y Claude Code en paralelo: árbol de trabajo, comparación de tareas y aprobación móvil?

Wed, 15 Jul 2026 22:05:00 +0800

Si se asigna el mismo error o función a Codex y Claude Code, los puntos ciegos a menudo se descubrirán más rápido que permitir que un Agente vuelva a intentarlo infinitamente. Pero lo realmente difícil es controlar el proceso: dos cambios no pueden cubrirse entre sí, los resultados deben ser comparables y las personas deben poder saber cuándo se completa la tarea y si deben continuar cuando dejan el ordenador. Orca ejecuta múltiples agentes de terminal en árboles de trabajo Git independientes y realiza un seguimiento de las sesiones, las diferencias y el estado de las tareas en el mismo lugar. Almacén oficial de Orca

Este artículo se centra en “comparar antes de la aprobación”: la ejecución paralela no es una fusión automática; la versión móvil no reemplaza la revisión del código, pero le permite verificar el progreso a tiempo, enviar preguntas de seguimiento y decidir qué resultados vale la pena devolver a la computadora para una revisión cuidadosa.

Primero establezca el límite correcto: la ejecución paralela no significa adopción automática

Orca puede ejecutar Codex, Claude Code y otros agentes de terminal en paralelo, y cada agente utiliza su propio árbol de trabajo Git. El archivo README oficial funciona asignando el mismo mensaje a varios agentes, comparando los resultados una vez completados en el árbol de trabajo aislado y luego fusionando la solución ganadora.

Por tanto, todo el proceso debe dividirse en tres capas:

Etapa	Quien completa	Producto
Ejecución	Códice / Código Claude	Rama independiente, diferencia, salida de prueba, descripción
Comparación	Orca + revisión manual	Diferencias de planes, puntos de riesgo, conclusiones de los candidatos
Aprobación y fusión	manuales	Compromisos aceptados, modificaciones adicionales necesarias

No tome “ambos agentes dicen que ya está hecho” como aprobación. Especialmente se deben revisar los permisos, las migraciones de bases de datos, las actualizaciones de dependencias y los archivos eliminados antes de fusionar la diferencia real.

Cómo dividir tareas para que la comparación sea significativa

Si dos agentes reciben un mensaje completamente vago de “solucionar el problema de inicio de sesión”, a menudo terminan con dos cambios grandes que no se pueden comparar horizontalmente. Se debe dar una base de aceptación unificada a cada tarea y las estrategias deben ser diferentes:

共同条件：复现登录 token 过期后的重试失败；必须通过现有登录测试；不改 API 协议。

Codex：从请求重试链路定位根因，提交最小修复，并说明为何不会影响刷新逻辑。
Claude Code：先写失败复现与回归测试，再提出最小修复；不改无关认证模块。

Solo mire cuatro preguntas al comparar:

¿Qué solución realmente reproduce y cubre el problema?
¿Qué diferencia es más pequeña y tiene límites más claros?
¿Qué comando de prueba se ejecutó realmente y el resultado fue reproducible?
¿Qué solución introduce menores riesgos de dependencias, permisos o regresiones?

De esta manera, la diferencia entre Codex y Claude Code se convierte en una elección de ingeniería mensurable, en lugar de una comparación de quién escribió las instrucciones de manera más convincente.

Worktree evita que dos cambios de candidatos se contaminen entre sí

Git worktree permite que diferentes ramas del mismo repositorio tengan diferentes directorios de trabajo. Orca ejecuta el Agente en cada árbol de trabajo aislado, por lo que el formateo, la instalación de dependencias o la eliminación de archivos de A no cambian directamente al directorio de B ni contaminan directamente su directorio de inicio.

Todavía se recomienda ordenar el espacio de trabajo principal antes de comenzar:

git status
git fetch --all --prune
git switch main
git pull --ff-only

Luego use nombres de sucursales legibles por humanos para los candidatos:

1
2
3

agent/login-fix-codex
agent/login-fix-claude
agent/login-tests

El aislamiento no elimina los conflictos de fusión: si dos esquemas terminan modificando el mismo archivo de certificación, la fusión aún requiere seleccionar un esquema maestro o elegir confirmaciones de prueba independientes del otro esquema. No combine varias ramas candidatas en main a la vez.

Secuencia práctica para iniciar dos Agentes en Orca

Los botones específicos cambian con la versión, pero el siguiente orden no cambiará:

Abra el repositorio de Git en Orca y confirme la rama base y los cambios actuales no confirmados.
Crear/seleccionar árboles de trabajo independientes para Codex y Claude Code.
Copie las condiciones de aceptación comunes y luego escriba las diferentes subtareas y rangos prohibidos.
Pídale al Agente que concluya enumerando los archivos modificados, las pruebas realizadas, las suposiciones no verificadas y las instrucciones de confirmación recomendadas.
Cuando termine, lea primero la diferencia y la salida de prueba, y luego decida si desea que uno de ellos continúe corrigiendo.

Orca también admite la apertura de árboles de trabajo desde GitHub y tareas lineales, y deja comentarios en las líneas de diferencias al Agente. Escribir comentarios en forma de comentarios prácticos, como “Conservar sólo las pruebas, retirar las actualizaciones de dependencia” o “Explicar aquí la secuencia de invalidación de la caché” es más eficaz que simplemente decir “Mejorarlo”.

Cómo hacer “aprobación” en el teléfono móvil

El Compañero Móvil de Orca se utiliza para monitorear y guiar a los Agentes en su teléfono: reciba notificaciones cuando completen y envíe seguimientos desde cualquier lugar. Es compatible con aplicaciones complementarias de iOS y Android y debe combinarse con la versión de escritorio.

La “aprobación móvil” aquí debe entenderse como ** toma de decisiones a nivel de tarea **, no como completar ciegamente la combinación de Git en el teléfono móvil:

通知到达
  → 查看 Agent 的完成摘要、测试状态和风险提示
  → 决定：追问 / 让它补测试 / 停止另一个候选 / 标记为待电脑审阅
  → 回到桌面端查看完整 diff、运行关键测试、再合并

Las operaciones adecuadas en teléfonos móviles incluyen pedirle al Agente que explique las pruebas fallidas, solicitar que se reduzca el alcance de los cambios, agregar un caso de regresión o detener tareas que obviamente están fuera de tema. No es adecuado para aprobar migraciones de bases de datos, configuraciones de producción, cambios de permisos o refactorizaciones extensas basadas únicamente en resúmenes de notificaciones.

Una lista de verificación de comparación y aprobación reutilizable

Cuando ambos Agentes estén completos, proceda en este orden:

[ ] 两个方案是否都基于同一基线分支？
[ ] 是否都列出了修改文件和运行过的测试？
[ ] 是否有一个方案引入了无关依赖或大范围格式化？
[ ] 是否存在同一文件的竞争修改？
[ ] 主方案能否独立通过测试？
[ ] 次方案中是否有可单独挑选的测试、注释或修复？
[ ] 是否已在桌面端审查完整 diff，再执行 merge？

Los candidatos se pueden comparar en el árbol de trabajo principal antes de fusionarlos:

1
2
3

git diff main...agent/login-fix-codex
git diff main...agent/login-fix-claude
git log --oneline main..agent/login-fix-codex

Después de la confirmación, solo fusione la rama adoptada o use git cherry-pick para elegir confirmar por separado. Conserve el árbol de trabajo no adoptado hasta que se complete la verificación y luego límpielo para facilitar la búsqueda de otra idea al regresar.

Preguntas frecuentes

¿Pueden Codex y Claude Code modificar el mismo archivo al mismo tiempo?

Sí, porque están en diferentes árboles de trabajo. Pero esto sólo evita que se sobrescriban entre sí durante el tiempo de ejecución y no resuelve automáticamente los conflictos lógicos durante la fusión. Lo mejor es designar un agente maestro de implementación y otro responsable de las pruebas, revisión o alternativas.

¿Puedo fusionar simplemente viendo “Listo” en mi teléfono móvil?

Este no debería ser el caso. Los teléfonos móviles son buenos para recibir notificaciones y enviar preguntas de seguimiento; Las diferencias completas, las pruebas en vivo, las configuraciones confidenciales y las decisiones de fusión aún deben realizarse en un entorno de escritorio confiable.

¿Por qué los resultados de ambos agentes no son satisfactorios?

A menudo, los límites de la tarea o los criterios de aceptación no son lo suficientemente específicos. Primero, permita que uno de los agentes solo lea el código y enumere las suposiciones de la causa raíz y los archivos de impacto mínimo; Después de confirmar la dirección y luego comenzar la implementación paralela, el costo será menor.

Resumen

Orca permite que Codex y Claude Code se ejecuten en paralelo en árboles de trabajo aislados, y las ganancias reales provienen de diferencias, pruebas y notas de riesgo comparables posteriores. La aplicación móvil complementaria es adecuada para completar “recibir notificaciones, hacer preguntas y decidir el siguiente paso” por adelantado, pero no reemplaza la revisión completa manual ni la fusión con Git. Al separar la ejecución, la comparación y la aprobación, los riesgos del código no se amplificarán debido al paralelismo entre múltiples agentes.

Tutorial de flujo de trabajo de Orca Parallel Agent: use Git Worktree para ejecutar Codex y Claude Code simultáneamente

Wed, 15 Jul 2026 21:58:00 +0800

多个 Agent 同时改一个仓库，最怕的不是速度不够，而是它们相互覆盖文件、污染未提交改动，最后很难判断哪一份结果可合并。Orca 的做法是为每个 Agent 分配独立的 Git worktree：同一个仓库可以并行运行 Codex、Claude Code 或其他终端 Agent，完成后再比较 diff、选择并合并结果。Orca 官方仓库

它不是另一个模型，也不会替代 Codex 或 Claude Code；更准确地说，它是给多个 CLI Agent 加上一层工作区、任务和结果管理界面。适合需要并行探索方案、但又希望保留 Git 隔离边界的开发者。

Orca 适合什么任务

Orca 最适合“目标相同、实现路径可比较”的任务，例如：

让两个 Agent 分别实现同一个接口，再比较测试、可读性和改动范围。
一边排查 bug，另一边补测试或阅读相关模块。
同时尝试保守修复与重构方案，最后只合并其中一个。
把前端、后端、文档拆成互不重叠的子任务并行推进。

不适合直接拆开的情况也很常见：多个 Agent 同时改同一个核心文件、需要共享未提交状态的调试过程，或需求本身还没有明确。这时先用一个 Agent 梳理计划，通常比并行启动五个窗口更省时间。

工作原理：每个 Agent 一棵独立工作树

Git worktree 允许一个仓库同时检出多个分支到不同目录。Orca 在此基础上为 Agent 创建和管理这些独立目录：每个 Agent 都有自己的文件改动、终端会话和分支上下文，不会直接覆盖主工作目录。

官方 README 描述的典型流程是：把同一个提示分发给多个 Agent，每个 Agent 在隔离 worktree 中完成任务，然后比较结果并合并胜出的实现。Parallel Worktrees 说明

可以把关系理解为：

层级	负责什么
Codex / Claude Code	理解任务、修改代码、执行测试
Git worktree	隔离每个方案的文件和分支改动
Orca	创建工作树、启动 Agent、集中查看会话与 diff
你	拆分任务、审查结果、决定合并哪个方案

开始前的仓库准备

并行之前先把主目录收拾干净。worktree 能隔离新分支的文件改动，却不能替你判断主目录里哪些未提交变更应该保留。

git status
git fetch --all --prune
git switch main
git pull --ff-only

如果 git status 不是干净状态，先提交、暂存或明确保留当前改动。随后为不同方案建立清晰的分支命名，例如：

1
2
3

agent/fix-login-codex
agent/fix-login-claude
agent/add-login-tests

Orca 支持 Windows、macOS 和 Linux 桌面端；安装包和当前版本以官方发布页为准。它可以运行任何能在终端执行的 Agent，因此还要确认本机已经完成 Codex、Claude Code 或你计划使用的 CLI 的登录和基础配置。

一个可复用的并行拆分方式

以“登录偶发失败”为例，不要给三个 Agent 都发送“修复登录 bug”。更好的拆分是把交付物写清楚：

1
2
3

Agent A：定位请求重试与 token 刷新路径；只提交最小修复，并补充复现步骤。
Agent B：不改业务逻辑；为登录失败、过期 token、网络超时补自动化测试。
Agent C：审查最近登录相关改动，给出根因假设、风险文件和建议，不直接修改代码。

这样三条工作树的输出可以直接比较：A 提供候选修复，B 提供回归保护，C 提供独立审查。即使最终只采用 A 的修改，B 和 C 的结果仍能帮助验证方向。

对于同一个功能的多方案竞赛，也应限制范围：要求每个 Agent 只改指定模块、运行相同测试命令、在最终说明中列出修改文件和未解决问题。没有共同的验收标准，多个 Agent 的“完成”很难横向比较。

在 Orca 中启动并行 worktree

具体界面会随版本变化，但操作顺序通常如下：

打开一个已初始化 Git 的仓库，确认基线分支和主目录没有意外改动。
为每个子任务创建独立 worktree 或让 Orca 从任务创建工作树。
分别选择 Codex、Claude Code 等本机可用 Agent，给出不重叠的任务说明和验收命令。
让 Agent 在自己的 worktree 中执行；不要在主目录同时手动修改同一批文件。
完成后查看每棵工作树的 diff、测试输出和提交记录，再决定保留、修改或丢弃。

Orca 还提供终端分屏、diff 行内评论、文件拖放给 Agent，以及通过 CLI 管理工作树的能力；例如其文档列出了 orca worktree create、snapshot 等工作流命令。功能入口以当前版本文档为准。Orca CLI 介绍

如何合并结果，避免把三个方案混在一起

最安全的顺序是先审查、后合并：

# 在主工作树中查看某个候选分支
git diff main...agent/fix-login-codex
git log --oneline main..agent/fix-login-codex

# 确认测试和改动范围后再合并
git switch main
git merge --no-ff agent/fix-login-codex

如果测试工作树和修复工作树都值得保留，先合并测试，再合并修复，或用 git cherry-pick 挑选单独提交。不要因为它们都由 Agent 生成，就直接把全部 worktree 一次性 merge；重复的依赖升级、格式化改动和同文件重构最容易在这里引入冲突。

合并前至少检查四项：

改动是否只覆盖了任务范围内的文件。
测试命令是否实际运行且结果可复现。
是否包含密钥、生成文件、大型锁文件或无关格式化。
两个候选方案是否改了同一段业务逻辑；若是，保留一个作为主方案，另一个只作为参考。

常见问题

Orca 会替我购买或共享 Codex、Claude Code 的额度吗？

不会。Orca 的定位是编排终端 Agent；你仍使用自己已有的 Agent 订阅、账号和本机登录状态。多开 Agent 也可能更快消耗对应产品的用量额度。

多个 Agent 可以修改同一个文件吗？

可以，因为它们位于不同 worktree；但后续合并会产生竞争。若同一个文件不可避免地要改，最好指定一个主实现 Agent，其他 Agent 只做审查、测试或提出补丁建议。

没有 Git 仓库能用吗？

Orca 能运行终端 Agent，但并行 worktree 的隔离和可控合并依赖 Git。对重要项目，先初始化仓库并建立可回滚的基线，再开始并行任务。

Orca 与直接开多个终端有什么区别？

手动开多个终端也能并行，但你需要自己创建工作树、记住分支、追踪会话和对比结果。Orca 把这些步骤放到同一界面，重点是降低并行 Agent 的管理成本，而不是改变 Agent 本身的能力。

小结

Orca 的实用之处在于把“并行试错”变成可审查的 Git 工作流：每个 Agent 在独立 worktree 中工作，结果用 diff、测试和分支提交来比较。先把任务拆到互不干扰，再只合并经过审查的候选分支，才能让 Codex、Claude Code 的并行能力真正服务于交付，而不是制造更多冲突。