Inicio / Varios agentes y verificación adversa

Sostener un fan-out a gran escala

Un entregable voluminoso confiado a un solo agente se ve cortado por un límite de tamaño sin que se escriba nada: fraccionar por eje, hacer que cada agente escriba en su propio archivo, respetar el tope documentado de dieciséis agentes activos a la vez y de mil agentes en total en una misma ejecución, una sola llamada que acepta hasta 4096 elementos que el runtime ordena por sí mismo bajo ese tope, y luego verificar comparando los archivos esperados con lo que existe realmente en el disco en lugar de creer a los agentes bajo palabra.

Un único agente encargado de escribir un entregable demasiado largo se ve interrumpido por un límite de tamaño de salida, y no se escribe nada en el disco: la tarea parece imposible cuando el problema está en el reparto. La solución cabe en una frase, un agente por eje, cada uno escribiendo su propio archivo, para que el límite ya nunca recaiga más que sobre un único archivo a la vez en lugar de sobre el conjunto del entregable.

El tope documentado

Claude Code limita a dieciséis el número de agentes activos al mismo tiempo, una cifra que baja si la máquina dispone de menos procesadores, incluso dentro de un contenedor con un número de núcleos limitado. Un segundo tope, distinto del primero, limita a mil el número total de agentes lanzados en el conjunto de una misma ejecución, precisamente para impedir que un bucle se desboque y relance agentes sin fin. Estos dos contadores no deben confundirse: el primero acota lo que se ejecuta en el mismo instante, el segundo acota el acumulado durante toda la duración del trabajo. Una tercera cifra cambia el panorama práctico: una sola llamada parallel() o pipeline() acepta hasta cuatro mil noventa y seis elementos, y es el propio runtime el que los ordena bajo el tope de dieciséis, sin intervención manual, un envío más largo se rechaza simplemente con un error en lugar de truncarse en silencio. El reparto manual en oleadas sucesivas, cada oleada verificada antes de que arranque la siguiente, conserva su utilidad, pero como una opción para verificar el trabajo por lotes y no como la única forma de mantenerse bajo el tope de concurrencia.

Verificar el disco, no el informe

Un agente que afirma haber escrito su archivo puede equivocarse, sobre su propia ruta de salida o sobre el contenido realmente producido. La disciplina que cierra el bucle consiste en escribir, antes de lanzar el fan-out, la lista exacta de los archivos esperados, y luego compararla después con lo que existe de verdad en el disco, nunca con los informes que devuelven los propios agentes.

# lista esperada, escrita antes del lanzamiento
cat > attendus.txt < obtenus.txt
diff attendus.txt obtenus.txt

Un último reflejo ahorra presupuesto en un gran volumen de llamadas similares que no necesitan una respuesta inmediata. La Batch API procesa este tipo de trabajo de forma asíncrona con un descuento del cincuenta por ciento sobre el coste en tokens, con una cuota de caudal separada de la de las llamadas en directo. Conviene a un fan-out ya escrito y listo para ejecutarse de una sola vez, no a un trabajo cuyas etapas dependen cada una del resultado de la anterior.

Estas tres disciplinas se combinan en el orden inverso a su descubrimiento. Primero se aísla cada agente en su worktree, luego se respeta el tope de concurrencia mediante oleadas, y por último se verifica en el disco lo que el fan-out ha producido realmente, nunca lo que los agentes han dicho al respecto.