Subagent on KnightLi Blog

Codex vs Claude Code: cómo elegir entre dos diseños de Subagent

Fri, 08 May 2026 14:14:01 +0800

Las herramientas de programación con IA están prestando cada vez más atención a los subagentes. No es simple moda: un solo agente acaba encontrando límites cuando debe manejar tareas reales de ingeniería.

Si un agente lee código, revisa logs, modifica implementación, ejecuta pruebas, analiza errores y resume resultados a la vez, el contexto principal se ensucia rápido. Resultados de búsqueda, salidas de comandos, logs de pruebas y razonamientos intermedios se mezclan. Las decisiones posteriores se vuelven menos fiables. Además, explorar, implementar, verificar y revisar en un único hilo dificulta el paralelismo.

El objetivo de los subagentes es reducir esa presión. La sesión principal deja de hacerlo todo de principio a fin y pasa a coordinar: define objetivos, asigna trabajo, recibe resultados y los integra. Un subagente se ocupa de una parte local, como exploración, implementación, verificación o revisión, y devuelve una conclusión comprimida.

Un subagente no es “otra copia de mí”. Es una forma de dividir trabajo de ingeniería confuso en roles más claros.

Fundamentos compartidos

Un sistema maduro de subagentes suele necesitar cuatro bases:

Aislamiento de contexto.
Especialización de roles.
Configuración a nivel de proyecto y usuario.
Límites de herramientas y permisos.

El aislamiento de contexto es esencial. En un repositorio real hay mucho material intermedio: búsquedas, logs de pruebas, salidas de comandos. Si todo entra en la sesión principal, el hilo principal se vuelve ruidoso. Un subagente puede digerir ese proceso local y devolver solo las señales útiles.

La especialización de roles también importa. Multi-agent no significa abrir varias copias del mismo modelo. Un rol de exploración debe buscar, leer y resumir. Un rol de implementación debe centrarse en cambios locales. Un rol de verificación debe ejecutar checks, identificar riesgos e informar con claridad.

Los límites de herramientas y permisos determinan si el sistema es seguro. Un subagente no debería heredar automáticamente todas las capacidades de la sesión principal. Un explorer de solo lectura no necesita escribir archivos. Un verifier no siempre necesita modificar implementación.

Codex y Claude Code comparten estas preocupaciones, pero toman caminos distintos.

Codex: delegación explícita

El diseño de Codex es más contenido.

Ofrece un mecanismo de delegación controlado y ligero alrededor de la sesión principal actual. Cuándo delegar, a quién delegar y cuándo recoger resultados son decisiones explícitas. El flujo de control permanece en la tarea actual.

Sus rasgos:

La sesión principal delega explícitamente.
El conjunto de roles se mantiene pequeño.
La sesión principal sabe qué agente hace qué.
Los resultados vuelven a la línea principal.
Los límites de colaboración son transparentes.

Esto encaja con equipos que valoran orquestación manual, previsibilidad y determinismo. Puedes pedir a un explorer que inspeccione una cadena de llamadas, a un worker que haga un cambio acotado y a la sesión principal que integre el resultado.

La contrapartida es que la presión de orquestación sigue en la sesión principal. Debe decidir cuándo dividir, cómo dividir, a quién asignar y cómo fusionar resultados. Para colaboración ligera es cómodo; para flujos largos puede cansar.

Claude Code: agentes como puestos de trabajo

Claude Code toma una ruta más de plataforma.

Trata los agentes como objetos describibles, seleccionables, configurables, con memoria, aislables y capaces de ejecutarse en segundo plano. Un subagente no es solo una ayuda temporal en una conversación; se parece más a un puesto de trabajo dentro de un sistema de ingeniería.

El sistema puede exponer listas de agentes, casos de uso, descripciones y límites de herramientas al modelo, permitiendo que el modelo decida qué rol usar en cada turno. Eso hace la delegación más automática.

Varios elementos definen este enfoque.

Primero, un sistema de roles. Explorer, planner, general-purpose y verifier pueden tener descripción de uso, restricciones de herramientas, modelos por defecto y condiciones de ejecución. Un explorer de solo lectura no edita archivos; un planner diseña; un verifier comprueba.

Segundo, herencia y override. Un subagente no es completamente libre. Hereda los límites grandes de la sesión principal, pero puede ajustar comportamiento local dentro de reglas permitidas.

Tercero, memoria. La memoria no es solo recordar algo. Puede tener alcance: memoria de usuario para preferencias largas, memoria de proyecto para contexto del repositorio y memoria local para estado del entorno.

Cuarto, background y worktree isolation. Algunas verificaciones pueden seguir en segundo plano mientras el hilo principal avanza. Si hace falta aislamiento fuerte, el agente puede trabajar en un worktree separado.

Quinto, ecosistema de plugins. Si los agentes son objetos de primera clase, hay que pensar en distribución, instalación, prioridades, overrides y seguridad. Los plugin agents pueden entrar al sistema, pero campos de alto riesgo como permission mode, hooks o MCP servers deben estar controlados.

Esto hace que Claude Code se parezca más a un runtime de agentes que a una herramienta de colaboración de una sola sesión.

Diferencia principal

Codex se parece a una herramienta de delegación controlada:

Delegación explícita.
Roles ligeros.
Flujo de control claro.
Subtareas centradas en la sesión actual.
Adecuado para trabajo humano-orquestado y determinista.

Claude Code se parece a un sistema de puestos de ingeniería:

Los agentes están modelados formalmente.
Los roles son más sistemáticos.
Memoria, background, aislamiento y plugins forman parte del runtime.
El modelo puede ayudar a elegir roles.
Adecuado para proyectos largos y workflows de plataforma.

La pregunta no es cuál tiene más funciones. Es si quieres que un subagente sea “un ayudante al que llamo explícitamente” o “un puesto permanente dentro del sistema”.

Cómo elegir

Elige el estilo Codex si valoras control explícito, delegación ligera y paralelismo seguro dentro de la sesión actual. Encaja con revisiones, cambios pequeños, tareas claras y flujos donde la persona quiere mantener el ritmo.

Elige el estilo Claude Code si necesitas roles sistemáticos, memoria a largo plazo, ejecución en segundo plano, aislamiento por worktree, plugins y un runtime más completo.

Hazte dos preguntas:

¿Aceptas que el modelo decida quién debe hacer el trabajo?
¿Necesitas un runtime de agentes más completo?

Si la primera te incomoda, la delegación explícita es mejor. Si la segunda es sí, un sistema tipo plataforma encaja mejor.

Consejos prácticos

No trates los subagentes como “más modelos igual a más potencia”.

Define límites de tarea para cada rol.
Limita las herramientas de cada rol.
Pide conclusiones, no logs crudos.
Mantén la decisión final en la sesión principal.
Haz visibles tareas en background y worktrees.
Define límites de seguridad para plugins.

El valor de los subagentes no está en la cantidad, sino en la calidad de la división del trabajo.

Resumen

Codex y Claude Code resuelven el mismo problema: un solo agente no puede cargar cómodamente con todo el trabajo real de ingeniería. Ambos reconocen la importancia de aislar contexto, especializar roles, definir permisos y resumir localmente.

Codex es más contenido y prioriza delegación explícita y control de la sesión principal. Claude Code es más sistemático y trata los agentes como puestos configurables, con memoria, aislamiento, background y ecosistema de plugins.

La elección no depende de qué marca gana, sino de si tu flujo necesita una herramienta de colaboración controlada o un runtime completo de agentes.

Colaboración multi-agente en Claude Code: cómo elegir entre Subagents y Agent Teams

Wed, 22 Apr 2026 21:35:52 +0800

Cuando se habla de colaboración multi-agente en Claude Code, los dos conceptos más fáciles de mezclar son Subagents y Agent Teams. Ambos suenan como “levantar varios agentes para trabajar juntos”, pero están pensados para tipos de trabajo distintos. En corto: los primeros son mejores para separar tareas independientes, mientras los segundos encajan mejor cuando varios agentes necesitan colaborar alrededor del mismo problema y revisar sus conclusiones con el tiempo.

Si ya has usado Skills, este marco también ayuda:

Una Skill define el flujo y las reglas
Un Subagent o compañero de Agent Team ejecuta el trabajo real

Así que la pregunta real no es cuál es más avanzado, sino qué problema de colaboración estás resolviendo.

Subagents: separar tareas laterales

Subagents se parecen más a copias temporales de trabajador lanzadas desde la sesión actual. Cada uno tiene su propia ventana de contexto y, al terminar, devuelve solo un resumen del resultado. La conversación principal se mantiene más limpia porque no absorbe todos los logs y salidas intermedias.

Eso da a Subagents varias fortalezas prácticas:

El hilo principal se mantiene limpio en lugar de llenarse de logs de tests, resultados de búsqueda o salida larga
Tareas independientes de investigación o ejecución pueden correr en paralelo
Funcionan bien cuando basta con “tráeme el resultado”

El artículo original señala que Claude Code trae tres tipos integrados de Subagents:

Explore: solo lectura, útil para buscar rápidamente en una codebase
Plan: solo lectura, útil para reunir información en segundo plano durante plan mode
General-purpose: puede leer y escribir, adecuado para tareas que mezclan exploración y edición

Subagents personalizados

Si las opciones integradas no bastan, puedes definir tu propio Subagent. El mecanismo es simple: escribir un archivo Markdown en una de estas ubicaciones:

.claude/agents/: activo solo en el proyecto actual
~/.claude/agents/: activo en todos tus proyectos

El formato se ve así:

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
You are a senior code reviewer ensuring high standards of code quality and security.

When invoked:

1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Review checklist:

- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Good test coverage
- Performance considerations addressed
Provide feedback organized by priority:

- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)

Include specific examples of how to fix issues.

El campo clave es description. Claude lo usa para decidir cuándo debe llamarse ese Subagent, así que cuanto más precisa sea la descripción, más fiable suele ser el disparo.

También conviene conocer algunos campos comunes:

tools: limita qué herramientas puede usar el Subagent
model: elige entre sonnet, opus, haiku o inherit
permissionMode: controla permisos de edición y prompts de autorización
memory: da al Subagent un directorio de memoria entre conversaciones

Si solo necesitas un Subagent temporal, también puedes definirlo mediante CLI:

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on code quality, security, and best practices.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Cuándo encajan mejor los Subagents

Subagents suelen encajar mejor en tareas como:

Ejecutar tests y devolver solo el resumen de fallos en lugar de llenar el hilo principal con miles de líneas de logs
Investigar varios módulos no relacionados en paralelo
Dividir “encontrar el problema” y “corregir el problema” en una pipeline simple

Por ejemplo:

`1`	`Research the authentication, database, and API modules in parallel using separate subagents`

`1`	`Use the code-reviewer subagent to find performance issues, then use the optimizer subagent to fix them`

Pero si una tarea necesita ajustes constantes de ida y vuelta, comparte mucho contexto entre etapas o concentra cambios en uno o dos archivos, manejarla directamente en la conversación principal suele ser más simple que levantar un Subagent.

Agent Teams: múltiples sesiones independientes trabajando juntas

Agent Teams operan en otro nivel. En vez de lanzar copias de trabajadores dentro de una sesión, inician varias instancias independientes de Claude Code que colaboran alrededor de una lista de tareas compartida y también pueden enviarse mensajes directamente.

Eso hace que un Agent Team se sienta más como un pequeño equipo real que como un simple sistema de tareas laterales.

El artículo señala que actualmente es una función experimental y debe activarse primero:

{
    "env": {
        "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
    }
}

Una vez añadido a settings.json, puedes pedir a Claude que organice un equipo alrededor de un objetivo. Por ejemplo:

1
2
3

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

De qué se compone un Agent Team

Un Agent Team incluye principalmente tres partes:

Team lead: la sesión principal que usas, responsable de organizar, asignar y resumir
Teammates: varias instancias independientes de Claude Code
Task list y Mailbox: lista compartida de tareas y canal de comunicación

La mayor diferencia con Subagents es que los teammates pueden comunicarse directamente entre sí en lugar de pasar todo por el lead. Las tareas suelen moverse por estados como pending, in progress y completed; cuando un teammate termina una tarea, puede tomar la siguiente.

Cuándo encajan mejor los Agent Teams

Cuando una tarea necesita varias perspectivas, discusión activa, hipótesis en conflicto o trabajo paralelo en módulos, Agent Teams encajan mejor.

El artículo da varios ejemplos representativos:

Varios revisores inspeccionan el mismo PR en paralelo, cada uno centrado en una dimensión
Varios agentes investigan el mismo bug con explicaciones competidoras y desafían las conclusiones de los otros
Frontend, backend y testing avanzan en paralelo en distintas partes del proyecto

Por ejemplo, revisión de código en paralelo:

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

Y depuración estilo debate:

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

El patrón común es que no quieres una sola respuesta. Quieres varios agentes intercambiando juicios, desafiando supuestos y convergiendo gradualmente en una conclusión más sólida.

Cómo elegir entre ellos

Si quieres una regla rápida:

Si solo necesitas el resultado, usa Subagents
Si el trabajo requiere discusión y validación cruzada, usa Agent Teams

Ampliando un poco:

Estilo de comunicación: Subagents principalmente reportan resultados a la sesión principal; miembros de Agent Teams pueden hablar directamente entre sí
Modelo de coordinación: Subagents dependen más de la conversación principal para orquestación; Agent Teams trabajan desde una lista de tareas compartida que los miembros pueden reclamar
Coste de tokens: Subagents son más baratos; Agent Teams cuestan más porque cada teammate es una instancia independiente
Mejor ajuste: Subagents para trabajo independiente y orientado a resultados; Agent Teams para trabajo con mucha discusión y revisión cruzada

Precauciones prácticas

Agent Teams son más potentes, pero eso no significa que cada tarea merezca un equipo completo. El artículo destaca varias preocupaciones prácticas:

el uso de tokens sube de forma notable
si varios teammates editan el mismo archivo a la vez, los conflictos de sobrescritura son muy probables
añadir demasiados teammates aumenta el coste de coordinación sin garantizar mejores resultados

Un valor predeterminado más seguro suele ser:

empezar con 3 a 5 teammates
dividir tareas por módulo o archivo para evitar conflictos de edición
si el lead empieza a hacer el trabajo de los teammates demasiado pronto, pedirle explícitamente que espere primero a los demás

La versión experimental actual también tiene limitaciones:

sin soporte de /resume y /rewind para teammates en proceso
el estado de tareas puede retrasarse y a veces necesita corrección manual
un lead solo puede gestionar un equipo a la vez
los teammates no pueden crear child teams propios

Conclusión breve

Estas dos funciones no se sustituyen entre sí. Resuelven dos problemas de colaboración distintos.

Si tu objetivo es paralelizar tareas laterales y mantener limpio el contexto principal, empieza con Subagents. Si tu objetivo es dejar que varios agentes trabajen como un pequeño equipo, discutan y se revisen entre sí, Agent Teams son la mejor herramienta.

Probar ambas en una tarea real suele aclarar la diferencia rápidamente: una está optimizada para aislamiento de contexto y recolección de resultados; la otra para colaboración multiperspectiva e interacción continua.

Enlaces relacionados

Artículo original: https://cloud.tencent.com/developer/article/2652960