Agentes de IA

Kimi Code CLI

Kimi Code — Agentes y subagentes

Cada sesión la dirige un Agente principal, que puede lanzar subagentes con ventanas de contexto aisladas. Los subagentes nunca ven la conversación principal; sólo vuelve su resultado final. Cada subagente consume sus propios tokens de modelo.

Subagentes integrados

AgentePara qué sirveCapacidades
coder (por defecto)Implementación de uso generalLeer, escribir y ejecutar comandos
exploreExploración del código en solo lecturaSólo leer y buscar
planPlanificación y arquitecturaSin shell

Los subagentes integrados no pueden lanzar otros subagentes. Los agentes propios heredan una lista blanca de delegación por defecto (coder, explore, plan); para cadenas más profundas hay que declararlo explícitamente en el frontmatter subagents.

Cómo se invocan

  • Automáticamente, por el Agente principal — cada lanzamiento muestra una petición de aprobación salvo que aplique una regla de permitir o el modo Ask When Needed (la herramienta Agent en sí está permitida por defecto).
  • Por instrucción tuya: “usa explore para mapear los archivos bajo src/auth/…”.
  • Se admite la ejecución en segundo plano, y se pueden retomar instancias existentes (el parámetro resume de la herramienta Agent). El timeout por defecto de un subagente es de 2 horas ([subagent] timeout_ms, variable KIMI_SUBAGENT_TIMEOUT_MS).
  • Las reglas de “permitir siempre” que acepta el agente principal se propagan a los subagentes.

Las herramientas Agent y AgentSwarm

  • Agent — lanza un único subagente (coder por defecto).
  • AgentSwarm — abanico por elementos: hasta 128 subagentes, empezando por 5 concurrentes y subiendo +1 cada 700 ms; el tope se ajusta con KIMI_CODE_AGENT_SWARM_MAX_CONCURRENCY. Está permitida por defecto en modo enjambre; fuera de él requiere aprobación en modo manual.
  • Control desde la TUI: /swarm on|off activa o desactiva el modo enjambre; /swarm <tarea> lo activa y envía la tarea, apagándose solo al terminar con normalidad.
  • Persistencia: cada subagente tiene su propio agents/<id>/wire.jsonl en el directorio de la sesión; los subagentes en segundo plano exponen su ciclo de vida en tasks/.

Agentes propios

Los agentes propios son archivos Markdown con frontmatter YAML.

Directorios (se escanean en recursivo buscando .md; la raíz del proyecto es el ancestro más cercano con .git):

ÁmbitoUbicación
Usuario$KIMI_CODE_HOME/agents/, ~/.agents/agents/
Proyecto.kimi-code/agents/, .agents/agents/
Extraextra_agent_dirs en config.toml
PluginEl campo agents del manifiesto del plugin (o agents/ en su raíz)

Prioridad por ámbito: Explícito (--agent-file) > Proyecto > Extra > Usuario > Plugin > Integrado. Las colisiones de nombre se resuelven por esa prioridad; para sobrescribir un integrado con el mismo nombre hace falta override: true (no es necesario con --agent-file).

Campos del frontmatter: name (en kebab-case; por defecto el nombre del archivo), description (obligatorio), whenToUse, override (false por defecto), tools (lista blanca; admite comodines MCP tipo mcp__github__*; omitirlo o * = todas; [] = ninguna), disallowedTools y subagents (lista blanca; omitirlo hereda la de por defecto). El cuerpo es el system prompt, y se renderiza como plantilla con marcadores ${var} como ${base_prompt}, ${agents_md}, ${cwd}, ${os}, ${shell} y ${skills}.

Ejemplo: un agente revisor de solo lectura

.kimi-code/agents/reviewer.md:

---
name: reviewer
description: Revisor de código de solo lectura para problemas de corrección, seguridad y estilo
whenToUse: Revisar diffs o archivos recién modificados antes de mergear
tools:
  - Read
  - Grep
  - Glob
---

Eres un revisor de código. Lee los archivos modificados y quién los llama, y luego
reporta los problemas ordenados por severidad: primero errores de corrección, después
riesgos de seguridad y por último estilo. Cita cada hallazgo como `ruta:línea`. No
modifiques ningún archivo. Si no encuentras nada, dilo explícitamente.

Para usarlo como agente principal en una sesión de solo revisión:

kimi --agent reviewer
# o
kimi --agent-file ./agents/reviewer.md

El agente principal queda fijado al crear la sesión (sólo en sesiones nuevas; no con --session/--continue); las sesiones que abras luego con /new usan el agente por defecto. SYSTEM.md puede sustituir de forma permanente el system prompt del agente principal — ver Instrucciones de proyecto (AGENTS.md).

Pool de modelos para subagentes ([secondary_model])

Estable desde la 0.40.0 y activado por defecto, permite que los subagentes corran con un modelo distinto (por ejemplo más rápido o más barato) que el agente principal:

[secondary_model]
default_model = "kimi-for-coding-highspeed"
force = false          # true fija TODOS los subagentes a default_model
  • En la TUI: /secondary-model (alias /subagent-model) fija el modelo por defecto de los subagentes.
  • Las herramientas Agent/AgentSwarm ganan un parámetro model; orden de resolución: parámetro model explícito > default_model; "primary" significa el modelo de quien llama.
  • Los fallos de validación hacen que el arranque de la sesión falle de forma ruidosa. Para desactivar el pool: KIMI_CODE_EXPERIMENTAL_SECONDARY_MODEL=0.

Casos de uso y limitaciones

Encajan bien: mapear un código en solo lectura (explore), trabajar en paralelo sobre elementos independientes (AgentSwarm), pasadas de revisión aisladas y abanicos con modelos baratos usando el pool.

Limitaciones: los subagentes nunca ven la conversación principal (pásales todo lo que necesiten en el prompt de lanzamiento); los integrados no pueden encadenar más subagentes; cada subagente quema sus propios tokens; y a quien llama sólo le vuelve el resultado final.


Última verificación: 2026-09-07

Fuentes oficiales:

Las herramientas de IA para programar evolucionan rápido. Si encuentras información desactualizada, abre un issue o un pull request.