Respuestas de referencia para preguntas de reflexión

Este archivo reúne los esquemas de respuestas de referencia para las preguntas de reflexión de los diez capítulos del libro. Las preguntas de reflexión son en su mayoría preguntas abiertas y las respuestas no son únicas. Las respuestas de referencia han sido generadas por IA y revisadas ligeramente por humanos, sirviendo solo como contraste e inspiración para los lectores. Se recomienda a los lectores utilizar un LLM junto con el contenido del borrador del libro para discutir estos problemas en mayor profundidad.

Capítulo 1 Introducción a los Agentes de IA

1. (★★) Si solo pudieras agregar una capacidad a un sistema de Agentes (un modelo más fuerte, un contexto más rico o más herramientas)¿cuál elegirías? ¿Bajo qué condiciones cambiaría tu elección?

Correspondiendo a la fórmula "cerebro/ojos/manos y pies", primero se buscan los puntos débiles: por lo general, se da prioridad a complementar el contexto, es decir, complementar el espacio de observación (observation space). Si la tarea excede la capacidad de inferencia del modelo, se cambia a un modelo más fuerte. Si el espacio de acción es insuficiente (por ejemplo, incapacidad para acceder a los sistemas internos de la empresa), se agregan herramientas. El criterio de juicio consiste en analizar las trazas de fallos para ubicar si el cuello de botella está en la percepción, la toma de decisiones o la acción.

2. (★★★) En el ciclo ReAct, cada llamada a la API del LLM por parte del Agente ve el historial completo de la trayectoria. A medida que la trayectoria crece, el costo de este diseño aumenta de forma cuadrática. ¿Existe alguna forma de romper este crecimiento cuadrático sin perder información clave?

Medios factibles: compresión de contexto (resumir trayectorias tempranas y conservar solo conclusiones y estados clave; véase la compresión multicapa del Capítulo 2); aprendizaje externalizado (escribir resultados intermedios en archivos o bases de conocimiento y recuperar bajo demanda en lugar de mantener en el contexto permanente); dividir en subagentes.

3. (★★) El paradigma "el modelo es el Agente" significa que el modelo es cada vez más autónomo en las decisiones de llamada a herramientas. Sin embargo, este capítulo argumenta que la importancia de la ingeniería de Harness está aumentando. ¿Cómo coexisten estas dos tendencias? ¿En qué aspectos se reflejará el valor central futuro de los marcos de trabajo de Agentes?

Metáfora del caballo y las riendas: cuanto más fuerte es el modelo y mayor es su espacio autónomo, mayor es el impacto de los errores y más se requieren restricciones, verificaciones y correcciones. El valor de los marcos de trabajo pasa de "orquestar llamadas a LLM" a los cinco elementos de garantía en la capa de Harness: clasificación de permisos, interruptores de circuito (circuit breakers), recuperación de errores, compresión de contexto y ecosistema de herramientas.

4. (★★) En el experimento de ablación, la falta de "retroalimentación de resultados de herramientas" hizo que el Agente entrara en un bucle infinito. En entornos de producción, además de la falta de resultados de herramientas, ¿qué otras situaciones podrían hacer que un Agente entre en un bucle infinito? ¿Qué mecanismos de detección y finalización diseñarías?

Otros desencadenantes: herramientas que reportan repetidamente el mismo error, alucinaciones llamando a herramientas inexistentes, contexto comprimido perdiendo estados clave, proceso de pensamiento despojado causando errores en la API del modelo, tarea intrínsecamente sin solución. Mecanismos: establecer condiciones de parada como un número máximo de iteraciones; detectar llamadas repetidas (misma herramienta + huella digital de parámetros); superar el umbral de fallos para escalar a intervención humana.

5. (★) Este capítulo analiza cinco productos de Agentes desde tres dimensiones: percepción, acción y política. Por favor, elige un producto de IA que uses a diario, analízalo usando estas tres dimensiones y piensa si su diseño arquitectónico es razonable. Si tú diseñaras este producto de IA, ¿qué margen de mejora habría?

Pregunta abierta. Puntos clave: siguiendo la tabla del capítulo, escribir los ojos (qué fuentes de información puede ver), manos y pies (si el espacio de acción es abierto, si puede pensar internamente) y política (el patrón del ciclo de ejecución del Agente).

6. (★★) Si tuvieras que diseñar un sistema de atención al cliente dedicado a la reserva de billetes de avión, ¿elegirías el modo de flujo de trabajo (workflow) o el modo de Agente autónomo? ¿Es posible utilizar de forma mixta ambos modos en el mismo sistema?

El cuerpo principal utiliza flujo de trabajo: cuatro nodos (verificación de identidad → búsqueda → pago → reserva) para garantizar la secuencia de cumplimiento normativo como "no se puede reservar antes de pagar", y limitar la superficie de ataque de inyección de prompts a nodos individuales. Los eslabones abiertos (comprender necesidades, cambiar billetes, recomendar alternativas tras cancelación de vuelos) cambian a Agente autónomo. Operaciones de alto riesgo (pagos elevados, reembolsos) añaden confirmación humana.

7. (★★★) La sección de barreras de seguridad mencionó la clasificación de riesgo de herramientas. Si una herramienta es de bajo riesgo en la mayoría de los casos pero se convierte en alto riesgo bajo combinaciones de parámetros específicas (como delete_file borrando archivos ordinarios vs. archivos del sistema), ¿cómo diseñarías una evaluación de riesgo dinámica?

Refinar el objeto de clasificación de "herramienta" a "herramienta + parámetros": calcular el riesgo al momento de la llamada según la reversibilidad, los permisos y el alcance del impacto. Utilizar verificaciones deterministas basadas en reglas (listas blancas/negras de rutas, expresiones regulares) en lugar de juicios del modelo. La verificación solo debe examinar datos estructurados para prevenir la manipulación por inyección de prompts.

8. (★★) En la tabla de productos de Agentes de este capítulo, el espacio de acción de todos los Agentes es "abierto". ¿En qué escenarios un espacio de acción restringido (por ejemplo, solo poder elegir entre opciones predefinidas) es superior a uno abierto?

Escenarios de alto cumplimiento normativo, alto riesgo y errores irreversibles: como reembolsos y pagos, donde las opciones restringidas actúan como "restricciones", previniendo errores de forma natural y haciendo que los errores sean imposibles desde el diseño.

9. (★★) El mecanismo de intervención humana requiere que el Agente pueda "transferir el control de forma elegante". Pero en la práctica, el usuario puede no estar en línea, responder muy lentamente o dar instrucciones vagas. En este caso, ¿qué debería hacer el Agente?

Fail-safe: Las operaciones de alto riesgo se pausan cuando no hay confirmación en lugar de ejecutarse por defecto; realizar primero las partes reversibles de bajo riesgo y registrar en documentos las partes de alto riesgo para facilitar la decisión humana y la recuperación del Agente; utilizar herramientas de comunicación asíncrona (mensajes, correo) para notificar y establecer políticas de tiempo de espera; usar aclaración de intenciones cuando las instrucciones sean vagas.

10. (★★★) La introducción afirma que «los buenos principios de diseño deben trascender los ciclos de iteración de los modelos», pero los métodos concretos de ingeniería utilizados para aplicar esos principios pueden quedar obsoletos a medida que mejoren las capacidades de los modelos. Da un ejemplo de uno de esos métodos de ingeniería de Agentes y explica por qué.

Ejemplo 1: utilizar muestreo restringido para forzar que las llamadas a herramientas sigan un formato estricto. Es un parche de fiabilidad para modelos que suelen emitir JSON no válido u omitir parámetros. Su beneficio puede disminuir a medida que mejore la adherencia de los modelos al formato, aunque los escenarios de alto riesgo deben conservar una validación determinista.

Ejemplo 2: introducir una base de conocimiento externa para compensar la incapacidad del modelo de incorporar continuamente conocimiento nuevo. Si los modelos llegan a disponer de aprendizaje continuo fiable, parte del mantenimiento del conocimiento podría pasar de los sistemas externos a sus parámetros. Aun así, las bases externas conservan un valor propio para las actualizaciones en tiempo real, la recuperación exacta, el control de acceso y la trazabilidad de las fuentes; por ello es más probable que reduzcan su ámbito de uso que que desaparezcan.

Ejemplo 3: exigir que todas las capacidades se expongan mediante la interfaz estándar de llamada a herramientas de la API del modelo y prohibir formatos personalizados. Skills muestra otra vía: describir en texto una capacidad y su procedimiento de uso, y dejar que el modelo la ejecute mediante una herramienta de línea de comandos de propósito general. Desde la perspectiva del modelo, esto equivale a comprender y seguir un protocolo textual personalizado sobre un ejecutor general. A medida que los modelos mejoran su comprensión de interfaces arbitrarias, «usar siempre el formato estándar de llamada a herramientas» deja de ser un principio universal. Los formatos estándar siguen siendo útiles para la interoperabilidad, la validación estructurada y los modelos menos capaces, pero deben ser una elección de ingeniería dependiente del contexto.

Ejemplo 4: exigir que los prompts y todas las definiciones de herramientas aparezcan al principio del contexto. Esta práctica surgió porque los primeros modelos tenían una capacidad limitada para seguir instrucciones y solían fallar al reconocer o ejecutar prompts y definiciones situados fuera de posiciones fijas conocidas. Skills carga prompts bajo demanda en medio del contexto, mientras que el descubrimiento dinámico de herramientas añade las nuevas definiciones después de la trayectoria existente. A medida que mejora el seguimiento de instrucciones y los modelos reciben posentrenamiento específico para estas formas de carga dinámica, los prompts y las definiciones de herramientas ya no tienen que permanecer al principio del contexto.

Capítulo 2 Ingeniería de Contexto

1. (★★★) El Experimento 2-3 descubrió que el historial de conversaciones con ventana deslizante hace que el Agente ejecute repetidamente las mismas llamadas a herramientas. Sin embargo, conservar completamente el historial hace que el contexto se expanda continuamente. Diseña una estrategia que evite la pérdida de información y controle la longitud del contexto sin romper el prefijo de KV Cache.

① Usar compresión en lugar de descartar: los mensajes solo se añaden y no se eliminan ni modifican; cuando se acerca al umbral (como el 80% de la ventana), se comprimen en lote los tool results antiguos. ② Mecanismo por capas: salidas grandes se guardan en disco dejando un resumen, el ruido se elimina directamente y resúmenes tipo archivo conservan el hilo conductor. ③ Aislamiento de subagentes para evitar que los estados intermedios entren en el contexto principal.

2. (★★) El mecanismo de retención de cadena de pensamiento del Chat Template de Qwen3 solo conserva el pensamiento "posterior al último mensaje de usuario real". Si un ciclo ReAct abarca cientos de rondas de llamadas a herramientas, el pensamiento acumulado podría consumir un gran volumen de contexto. ¿Cómo modificarías este mecanismo para hacer frente a ciclos ultralargos? DeepSeek R1 exigía despojar todo el pensamiento histórico, mientras que DeepSeek V4 cambió a devolver obligatoriamente todo el reasoning_content: compara estas dos estrategias opuestas, ¿cuáles son sus pros y contras? ¿Qué demuestra este cambio?

Dirección de modificación: retención por ventana deslizante (conservar completamente las rondas de pensamiento recientes, y fuera de la ventana activar compresión de desplazamiento según presupuesto de tokens en lugar de rondas fijas, produciendo una barra de estado estructurada con objetivo actual, hechos confirmados, rutas descartadas y pendientes); la compresión ocurre solo una vez y en una posición fija, el costo de reconstrucción de caché es de una sola vez en lugar de cada ronda. R1 despojar: ahorra tokens, prefijo estable amigable con la caché y consistente con la distribución de entrenamiento (CoT histórico nunca está en la entrada); pero razona desde cero en cada ronda, pierde planes a largo plazo y es proclive a repetir errores. V4 retorno obligatorio: pensamiento coherente, mejor rendimiento en tareas de agentes de largo alcance; pero costo de tokens elevado, el prefijo se expande en cada ronda e imposibilita cambiar fluidamente desde un modo no-think. El cambio demuestra: para escenarios de diálogo puro el pensamiento es desperdicio, para escenarios de agentes el pensamiento es estado, la práctica de la industria se ha inclinado hacia esto último.

3. (★★) En el experimento de compresión consciente del contexto, la compresión pasó de aproximadamente 148K caracteres a aproximadamente 2,000 caracteres. ¿Existe el riesgo de "pérdida irreversible de información" con esta compresión extrema? ¿Cómo resolverlo?

Existe riesgo: la compresión es una proyección con pérdidas; si la pregunta recae sobre dimensiones no conservadas, el sistema falla. Solución: "compresión con pérdidas + indexación sin pérdidas", cada hecho lleva una URL de fuente para rastreabilidad; la salida original se guarda en disco y solo se consulta la vista previa del resumen; conservar explícitamente prioridades (decisiones arquitectónicas, integridad semántica sobre tiempo y nombres de empresas, estado de verificación e identificadores como UUID/hash se conservan tal cual); ventana adaptativa para posponer el momento de compresión.

4. (★★) La barra de estado del Agente visibiliza los estados implícitos. Pero si la propia barra de estado contiene información errónea (por ejemplo, si el contador de herramientas tiene un bug), el Agente podría tomar decisiones perjudiciales basadas en información incorrecta. ¿Cómo mitigar este problema de "confiabilidad de la metainformación"?

El modelo confía casi incondicionalmente en la barra de estado, transmitiendo errores tal cual. Mitigación: ① Mantener mediante código determinista, nunca permitir que el LLM haga estadísticas por lotes de un historial largo (si se usa, extraer elemento por elemento y resumir por código); ② Tratar la precisión de la barra de estado como una métrica de producción de primera línea; ③ La información debe provenir únicamente de observaciones confiables del mundo real, previniendo la contaminación de la barra de estado.

5. (★★) Los experimentos de ablación de ingeniería de prompts muestran que la desorganización de la información reduce la tasa de éxito en más de un 30%. Sin embargo, en el desarrollo real, los prompts del sistema a menudo son mantenidos por varias personas en momentos diferentes. ¿Qué prácticas de ingeniería usarías para evitar el "aumento de entropía" en los prompts del sistema?

① Tratar los prompts como código: control de versiones, revisiones de código, donde los gestores de producto definen reglas de negocio y los ingenieros codifican; ② Usar conjuntos de pruebas tipo Tau-Bench para pruebas de regresión, ejecutando experimentos de ablación antes y después de cambios para ubicar impactos; ③ Estructuración obligatoria: impulsada por procesos SOP en lugar de apilar reglas, con capas XML/Markdown; ④ Clasificar y nombrar fragmentos según "almacenables en caché / destructores de caché", ubicando el contenido dinámico detrás del límite de caché; ⑤ Dividir el contenido expandido en Skills para carga bajo demanda.

6. (★★★) Este capítulo propone que "el aprendizaje en contexto es esencialmente recuperación y no razonamiento". Si esta afirmación es cierta, todas las direcciones actuales de optimización basadas en "introducir más información en el contexto" deben ser reexaminadas. ¿Cómo crees que se puede superar esta limitación?

Añadir una capa de refinamiento a un "motor de búsqueda que solo tiene la mitad": ① Destilación de contexto/barra de estado, usando código para calcular conclusiones con antelación para recuperación directa; ② Compresión activa, convirtiendo registros originales en conocimiento estructurado de alta densidad; ③ Aislamiento de subagentes, evitando que el ruido entre en el contexto principal; ④ La interacción como tercer eje, donde observaciones de instrumentos externos escriben nueva información que el modelo no puede pensar por sí mismo; ⑤ Direcciones de vanguardia: "notas" de KV Cache editables y combinables, y sedimentación de memoria entre sesiones.

7. (★★★) La divulgación progresiva de Skills solo carga el contenido completo cuando el Agente juzga que es necesario. Pero este juicio en sí mismo depende de la capacidad del modelo: si el modelo no sabe lo que no sabe, no podrá activar correctamente la carga del Skill. ¿Cómo resolver este problema de "metacognición"?

① Los metadatos del Skill (nombre, descripción) permanecen de forma continua en el contexto, permitiendo que el modelo siempre "sepa qué posee"; ② La descripción del Skill se escribe como condiciones de enrutamiento en lugar de introducciones de funciones: "Utilizar cuando / No utilizar cuando", evitando descripciones amplias.

8. (★★) En el mecanismo de Skills, después de que el Agente lee dinámicamente los prompts del archivo SKILL, ¿pueden las operaciones posteriores cumplir correctamente con estas instrucciones? ¿Qué diferencia existe en el soporte del patrón de Skills entre diferentes modelos?

Depende de la forma de inyección del Skill: la inyección en el system prompt tiene el cumplimiento más fuerte pero destruye KV Cache; al leerse como un archivo ordinario en medio del contexto, el cumplimiento de instrucciones del modelo puede ser inferior; al inyectarse al final del contexto, el cumplimiento de instrucciones es relativamente bueno, pero cada llamada a herramienta requiere recalcular la parte de KV Cache correspondiente al skill, lo que resulta en costos más altos.

9. (★★★) Este capítulo enfatiza que los cambios en la información dinámica (como marcas de tiempo del sistema, orden de lista de herramientas) destruyen la tasa de acierto del prefijo de KV Cache. En un sistema de producción con una gran cantidad de herramientas y cambios frecuentes en el conjunto de herramientas, ¿cómo diseñarías la disposición del contexto para maximizar la tasa de acierto de caché?

① Un número pequeño de herramientas centrales estables (como siete) + un ejecutor general, con capacidades específicas mediante divulgación progresiva de Skills, congelando las definiciones de herramientas en un prefijo estático y en orden fijo; ② Mantener el mismo prefijo entre subagentes y Agente primario.

Capítulo 3 Memoria de Usuario y Base de Conocimientos

1. (★★) En un sistema de memoria de usuario, cuando el mismo usuario proporciona información contradictoria en diferentes sesiones (por ejemplo, mencionando dos direcciones de domicilio distintas en dos ocasiones), ¿cómo debe manejar este conflicto el sistema de memoria?

Usar una tubería tipo Mem0 de "extracción, comparación y decisión": primero recuperar memorias antiguas similares mediante vectores, luego hacer que el LLM determine ADD/UPDATE/DELETE/NOOP (por ejemplo, "mudado a Shanghai" debe hacer UPDATE sobre "vive en Beijing"); versionado: la información de tipo dirección solo conserva la versión más reciente etiquetando marcas de tiempo, mientras que el historial laboral conserva el historial completo; el lado de recuperación puede basarse en prefijos de contexto (persona, tiempo, intención) para juzgar cuál es válida finalmente.

2. (★★) La recuperación consciente del contexto adjunta el contexto del documento original a cada fragmento (chunk). Pero si el documento original tiene una estructura desordenada o información contradictoria, este método podría propagar o amplificar errores. ¿Cómo introducirías señales de "calidad de información" en la fase de recuperación?

Tomar prestado del "gobierno y vigencia de bases de conocimiento": adjuntar metadatos como número de versión, tiempo de vigencia/caducidad y fuente a los fragmentos, filtrando contenido caducado durante la búsqueda o etiquetando explícitamente en el prefijo "esta entrada quedó obsoleta en tal fecha"; en la fase de reclasificación (reranking), incluir la autoridad de la fuente y la frescura temporal en la puntuación, en lugar de mirar solo la relevancia semántica; durante la indexación, hacer que el LLM que genera prefijos detecte y etiquete contradicciones entre fragmentos, similar a la detección de conflictos por versiones en la memoria.

3. (★★★) El RAG agéntico (Agentic RAG) permite que el Agente decida de forma autónoma cuándo buscar, qué buscar y si necesita continuar buscando. Pero si el modelo no sabe lo que no sabe, no podrá activar la búsqueda correctamente. ¿Cómo resolver este problema de "metacognición"?

① Consolidar en prompts/skills "evaluar si la información es suficiente" como un paso explícito: por ejemplo, en el Experimento 3-9, recuperar primero subproblemas en paralelo y, al descubrir que falta la relación "cómo afectan los antecedentes penales a la pena por imprudencia", realizar una segunda búsqueda; ② Permitir que metainformación ligera permanezca en el contexto para proporcionar una visión global: por ejemplo, resúmenes tipo JSON Cards o resúmenes L0/L1 de OpenViking, para que el Agente sepa "qué hay en la base".

4. (★★) La extracción de información multimodal convierte gráficos en descripciones de texto antes de la recuperación. Este proceso de "traducción" puede perder relaciones espaciales en la información visual. Da un ejemplo concreto para ilustrar información de un gráfico que una descripción de texto puro no puede transmitir completamente, y diseña un esquema para conservar dicha información.

Ejemplo: Relaciones lógicas en un diagrama de arquitectura de sistemas, la posición del punto de intersección de dos curvas en un gráfico de líneas, o la correspondencia de filas y columnas entre celdas y encabezados en una tabla PDF. Esquema uno: procesamiento multimodal nativo; Esquema dos: proporcionar herramientas de análisis de imágenes multimodales.

5. (★★★) "La Lección Amarga" de Rich Sutton sostiene que los métodos generales (búsqueda y aprendizaje) eventualmente superarán a las características diseñadas a mano. ¿Es todo el sistema de conocimiento construido en este capítulo (estrategias de fragmentación, estructuras de índices, tuberías de recuperación) en sí mismo un "diseño a mano"? Si la capacidad del modelo fuera lo suficientemente fuerte, ¿serían reemplazados estos diseños por una simple "entrada completa"?

De hecho es un diseño a mano, y algunos eslabones (fragmentación, ajuste de parámetros de fusión) podrían debilitarse con contextos largos; pero el caso del gato negro y el gato blanco muestra que la "entrada completa" tampoco es suficiente: la atención es una recuperación blanda, y la agregación estadística entre documentos aún requiere pre-refinamiento en el periodo de indexación; las restricciones de ingeniería como actualización de caducidad de conocimientos, aislamiento de permisos/inquilinos, auditabilidad y costos no tienen relación con la capacidad del modelo; además, la recuperación y el refinamiento por LLM en el periodo de indexación son en sí mismos métodos generales de "búsqueda + aprendizaje", no opuestos a la lección amarga.

6. (★★★) Con la mejora de las capacidades del modelo, ¿crees que las bases de conocimientos de dominio siguen siendo importantes? ¿Es posible que los modelos base potentes del futuro contengan toda la información de las bases de conocimientos de dominio, haciendo que estas ya no sean necesarias?

Siguen siendo importantes: los datos de entrenamiento tienen fechas de corte, mientras que las bases de conocimientos se pueden actualizar en cualquier momento; los procesos internos de las empresas y los precedentes judiciales privados no están en absoluto en el corpus público; el intercambio multiusuario requiere filtrado de permisos y aislamiento de inquilinos, y el conocimiento en los parámetros no se puede recortar según quien realiza la llamada; el almacenamiento externo es auditable, versionable y permite deshabilitar contenido caducado, algo difícil de lograr en la memoria de parámetros; incluso si se sigue la ruta de parametrización (posentrenamiento / User as Engram), se enfrenta al problema de que "recordar es fácil, pero usarlo para razonamiento de múltiples saltos es difícil".

7. (★) RAPTOR construye índices de árbol mediante resúmenes jerárquicos de abajo hacia arriba, mientras que GraphRAG construye índices de estructura de grafo mediante relaciones de entidades. ¿Qué tipo de consultas destaca en responder cada una de estas estructuras de índices?

RAPTOR: Consultas tipo "desplazamiento entre capas" que van desde conceptos macroscópicos desglosando detalles progresivamente, como ubicar primero el resumen del "conjunto de instrucciones SIMD" y luego desglosar los detalles de SSE, atendiendo tanto a la visión general como al detalle. GraphRAG: Razonamiento de relaciones de múltiples saltos ("la dirección del hospital donde trabaja mi médico" recorriendo la cadena de relaciones) y desambiguación de entidades ("dos doctores Zhang" son nodos diferentes) para consultas del tipo "qué relación hay entre A y B", donde los resúmenes comunitarios también proporcionan agrupación temática.

8. (★★) El paradigma del sistema de archivos organiza el conocimiento en una estructura jerárquica similar a un sistema de archivos. En comparación con el RAG tradicional con bases de datos vectoriales, ¿en qué escenarios tiene mayor ventaja este enfoque?

El texto plano puede ser leído, editado y corregido directamente por humanos, y puede usar control de versiones Git y reversiones, siendo adecuado para escenarios donde humanos y máquinas mantienen y revisan conjuntamente el conocimiento; si el Agente tiene la capacidad write_file, puede registrar de forma autónoma experiencias, formando un ciclo de autoevolución de memoria (aprendizaje externalizado); la divulgación progresiva L0/L1/L2 permite que la mayoría de las consultas tomen decisiones al llegar a L1, ahorrando tokens; el prerrequisito es establecer enlaces cruzados y páginas de índice como en Wikipedia, de lo contrario, cuantos más archivos aislados existan, más difícil será la recuperación.

9. (★★★) Descubrir automáticamente "factores de juicio" y la "jerarquía de importancia de factores" a partir de datos estructurados (como bases de datos de sentencias judiciales) es esencialmente permitir que el Agente induzca reglas a partir de los datos. ¿Puede esta extracción de conocimiento impulsada por datos alcanzar la calidad de las reglas escritas a mano por expertos humanos?

Ventajas: como en los experimentos CAIL2018, el descubrimiento de factores "de abajo hacia arriba" se adapta mejor a los datos en lugar de a los a priori humanos, pudiendo capturar experiencias de ponderación implícitas dispersas en miles de sentencias que a los expertos les cuesta escribir explícitamente, y se puede cuantificar. Limitaciones: si la extracción por LLM falla, provocará contaminación del conocimiento, el sesgo de los datos mismos será heredado, y los prototipos de agrupación solo reflejan correlación sin aclarar causalidad. Solución intermedia: modelado impulsado por datos + revisión de expertos del Schema y resultados, con el modelo formulando preguntas y las estadísticas respaldando las explicaciones.

Capítulo 4 Herramientas

1. (★★) El estándar MCP desacopló la definición de herramientas del marco del Agente. Sin embargo, la estandarización también significa que los patrones de interacción de herramientas complejos (como salidas en flujo, comunicación bidireccional, sesiones con estado) pueden ser difíciles de expresar en un protocolo estándar. ¿Cuál crees que es la capacidad que MCP más necesita extender en el futuro?

La extensión más necesaria es la capacidad orientada a eventos entre sesiones. MCP ya admite interacciones de varios turnos, suscripciones a cambios y tareas de larga duración, pero su núcleo sigue siendo la estandarización de una llamada a una capacidad, no mantener al Agente continuamente conectado. Despertarlo ante un correo nuevo o una llamada de retorno externa, así como poner en cola, reanudar y reintentar varios eventos, sigue correspondiendo al framework del Agente. Unas convenciones más unificadas para esta orquestación ampliarían el alcance de MCP sin sacrificar la sencillez del protocolo.

2. (★★) En una arquitectura de Agente asíncrono, la estrategia de prioridad de la cola de eventos debe determinarse al momento del diseño. Pero si el juicio de prioridad en sí mismo requiere comprensión semántica (por ejemplo, juzgar si un nuevo mensaje es más urgente que la tarea actual), ¿quién debería hacer este juicio: un motor de reglas o un nuevo LLM? ¿Cuáles son los costos de cada uno?

Mezcla por capas: los tipos de eventos claros se codifican de forma rígida con reglas, con cero latencia y alta determinismo, pero sin capacidad de comprender la diferencia semántica entre "detente inmediatamente" y "¿cómo está el clima hoy?"; los difusos semánticamente se entregan a un LLM liviano como enrutador de eventos, a costa de cientos de milisegundos de latencia, costos adicionales y posibles errores de juicio, y debe funcionar como un Sidecar examinando solo campos estructurados para prevenir inyecciones de prompts.

3. (★★) En el ecosistema MCP, diferentes servidores MCP pueden proporcionar herramientas con funciones altamente superpuestas. Cuando un Agente se enfrenta a múltiples herramientas de fuentes diferentes pero con funciones similares, ¿cómo debería elegir? Si herramientas con el mismo nombre de diferentes fuentes varían ligeramente en comportamiento (por ejemplo, una devuelve un resumen y la otra el texto completo), ¿tiene el Agente la capacidad de percibir y aprovechar esta diferencia?

Criterio de selección: revisar descripciones antes de la integración, bloquear versiones, asignar credenciales de permisos mínimos y estar alerta al ensombrecimiento de herramientas (tool shadowing) que enruta llamadas sensibles a partes maliciosas; en tiempo de ejecución, reducir candidatos mediante clasificación jerárquica y descubrimiento dinámico. Si el modelo puede percibir la diferencia depende de la calidad de la descripción de la herramienta.

4. (★★★) Cuando un Agente interactúa con el mundo exterior en nombre de un usuario, enfrenta esencialmente una elección de identidad: ¿usar una identidad virtual independiente (correo dedicado y número de teléfono) para actuar como un tercero, o directamente operar la cuenta personal del usuario con la identidad del propio usuario? Lo primero permite operaciones autónomas en segundo plano, pero terceros pueden no confiar en una identidad no humana; lo segundo posee un contexto y permisos más completos, pero introduce problemas de autorización de confianza y límites de seguridad. ¿En qué escenarios elegirías cada modo?

Identidad virtual por defecto: operaciones autónomas en segundo plano, auditables, que al fallar o ser comprometidas no exponen toda la identidad digital del usuario, actuando como un secretario usando su propio correo de trabajo; requiere hacer frente a problemas de reputación de IP/CAPTCHA mediante APIs oficiales, cuentas autorizadas e intervención humana (Human-in-the-loop). Escenarios obligatorios con la identidad del usuario (verificación de identidad de cuenta, llamadas de tres vías, como Pine llamando a atención al cliente) usan autenticación Human-in-the-loop: VNC/RDP permite al usuario iniciar sesión visualmente en persona. Criterio de juicio: si la otra parte exige al titular de la cuenta en persona, el riesgo de la operación y el alcance de las credenciales.

5. (★★) En el procesamiento de eventos por colas, el modelo tiende a enfocarse solo en el último evento, lo cual este capítulo mitiga mediante el marcado y resumen en la barra de estado del Agente. Pero si hay un atraso de 20 eventos en la cola (10 resultados de herramientas + 5 mensajes de usuario + 5 avisos del sistema), ¿cómo organizarías el orden de presentación y el formato de estos eventos para que el modelo no omita información clave?

Primero desduplicar y clasificar con reglas y LLM livianos: los eventos urgentes (alarmas, interrupciones de usuario) se procesan por separado con cancelación, sin mezclarse en lote. Los 10 resultados de herramientas ultralargos se truncan y persisten en archivo, dejando solo encabezado, pie y ruta. La barra de estado del sistema al final del contexto añade una lista de resumen (cantidad de cada tipo de evento + requisito de responder uno a uno).

6. (★★) Este capítulo propone el ciclo cerrado de "ejecución-verificación-retroalimentación" (como ejecutar un linter automáticamente tras escribir código). ¿A qué otros escenarios de herramientas se puede aplicar este patrón de "verificación automática inmediata tras la operación"? ¿Existen operaciones cuya verificación implique un costo o riesgo superior al de la operación misma, haciendo inviable este patrón?

Escenarios generalizables: ejecutar realmente en Sandbox tras cambiar configuraciones para verificar vigencia; renderizar como captura de pantalla tras generar documentos/presentaciones, usando la capacidad multimodal del modelo para revisar la maquetación. Inviables: enviar correos, realizar llamadas telefónicas, transferencias bancarias externas u otras operaciones irreversibles y no idempotentes: o no hay forma de observar, o la verificación en sí activa otro evento del mundo real; en estos casos se deben usar medios previos: aprobación previa de proponente-revisor.

7. (★★) Este capítulo plantea el problema de la "explosión de herramientas": la precisión de selección del Agente disminuye ante miles de herramientas. Además del descubrimiento activo de herramientas, ¿qué otras soluciones existen? Se puede hacer referencia a las estrategias de expertos humanos ante una gran cantidad de herramientas disponibles.

① Agrupación jerárquica: ubicar primero "servidor/App" y luego seleccionar la herramienta específica; ② Consulta "bajo demanda" tipo Skills: como consultar un libro de referencia, con el índice permanente en el contexto y los detalles cargados bajo demanda; ③ Mantener un pequeño número de herramientas básicas de uso frecuente "a la mano" permanentemente en el contexto, dejando el resto al índice del directorio.

Capítulo 5 Coding Agent y Generación de Código

1. (★★) La generación de código se denomina la "metacapacidad" del Agente. Sin embargo, la ejecución de código introduce riesgos de seguridad: el código generado por el Agente puede contener vulnerabilidades, bucles infinitos o agotamiento de recursos. El aislamiento mediante Sandbox resuelve parte del problema, pero también limita las capacidades del código (por ejemplo, imposibilidad de acceder a la red o al sistema de archivos). ¿Cómo encontrar el punto de equilibrio óptimo entre seguridad y capacidad?

Aislamiento del Sandbox clasificado por escenarios (contenedores/microVM); red desconectada por defecto, con proxy de lista blanca liberado bajo demanda; código fuente montado en solo lectura, las claves de API no deben colocarse dentro del Sandbox; límites de recursos del Sandbox; gestión del ciclo de vida del Sandbox (tiempo de espera).

2. (★★★) El arranque autónomo de Agentes (Agent bootstrapping), es decir, Agentes capaces de crear Agentes, logra la "autorreproducción de la inteligencia". Sin embargo, cada arranque autónomo puede introducir nuevos sesgos o errores. ¿Se acumularán estos errores entre generaciones? ¿Cómo prevenir la degradación del arranque autónomo de Agentes?

Si cada generación continúa reproduciéndose sobre los productos de la generación anterior, algunos defectos pueden acumularse. La clave es tener tareas verificables (verifiable tasks) lo suficientemente desafiantes, como tareas de programación suficientemente difíciles.

3. (★★) El Agente de generación de código puede seguir automáticamente la evolución del formato al procesar registros (logs). Pero si el cambio de formato es un bug en lugar de un cambio previsto, la adaptabilidad del Agente termina ocultando el problema. ¿Cómo debería el Agente distinguir entre "cambios que requieren adaptación" y "anomalías que requieren reporte"?

Diagnosticar antes de adaptarse: comparar con documentos de arquitectura y PRD para juzgar si el nuevo formato cumple con lo previsto (la idea del Experimento 5-8); verificar registros de control de versiones para confirmar si el cambio corresponde a una confirmación de código legítima o a una deriva sin origen; similar al log_mismatch de τ-bench, incluso si se elige adaptar, registrar una alarma y crear automáticamente un issue en lugar de ser compatible silenciosamente; cuando haya incertidumbre, recurrir a la confirmación humana en el ciclo. Principio: adaptación y reporte en paralelo, la adaptación no debe tragar las señales de anomalía.

4. (★★) Este capítulo utiliza repetidamente el mecanismo proponente-revisor en la generación de PPT, edición de video y visualización de registros. Si las preferencias estéticas del Revisor no coinciden con las del usuario final, por ejemplo, si el Revisor considera que la densidad de información es razonable pero el usuario la encuentra demasiado recargada, el ciclo de retroalimentación convergerá a un óptimo local erróneo. ¿Cómo lograr que la retroalimentación de preferencias del usuario también participe en el ciclo del Revisor?

Inyectar la retroalimentación del usuario en la trayectoria del Agente como un evento estructurado de máxima prioridad; externalizar y consolidar las preferencias del usuario escribiéndolas en MEMORY.md, haciendo que las preferencias surtan efecto entre tareas; entregar documentos en formato HTML en lugar de Markdown para facilitar la verificación del usuario.

5. (★★) Este capítulo muestra múltiples formas en que un Coding Agent consolida la experiencia obtenida durante la ejecución y depuración de regreso en la base de código: escribiendo en archivos de bases de conocimiento, actualizando documentos de arquitectura, manteniendo archivos de instrucciones del proyecto y consolidando secuencias de operaciones como código. Si estas experiencias se refinaran aún más como reglas en los prompts del sistema, el conjunto de reglas se expandiría con el tiempo. ¿Cómo realizar una "recolección de basura" (garbage collection) de las reglas consolidadas (identificando y limpiando entradas redundantes u obsoletas)? ¿Por qué una modificación exitosa de código no puede considerarse directamente como la evolución continua mencionada en el Capítulo 8?

Idea para GC: mover a Linter, CI o verificaciones de herramientas aquellas reglas que puedan codificarse; rastrear la tasa de aciertos y conflictos de las reglas, reverificando periódicamente contra la base de código; usar Markdown y Git para conservar origen, versión y capacidad de reversión. Un parche exitoso solo demuestra que resolvió el caso actual; la evolución continua exige además que las modificaciones provengan de evidencia operativa rastreable, puedan mejorar tareas posteriores y superen la regresión de tareas antiguas y la verificación de seguridad.

6. (★) "Los equipos amigables con el trabajo remoto a menudo también son amigables con los Agentes de IA." ¿Qué tan lejos está el equipo u organización en la que trabajas de ser "AI-ready" en términos de documentación de conocimiento? ¿Cuál es el mayor obstáculo?

Pregunta abierta. Se puede usar el indicador proxy de este capítulo para autoevaluación: si un nuevo integrante remoto puede comenzar a trabajar de forma independiente apoyándose solo en el repositorio y la documentación. Lista de verificación: si las decisiones se registran en documentos, si el contexto se escribe en issues/PRs, si los comandos de compilación y prueba cuentan con archivos de instrucciones tipo CLAUDE.md/AGENTS.md, si el conocimiento tribal se ha consolidado en guías para desarrolladores. Obstáculo común más grande: la cultura de comunicación verbal y pizarra basada en "preguntar al compañero de al lado", ya que el Agente no puede leer acuerdos verbales, solo lee documentos.

7. (★★★) Simon Willison propuso la "tríada mortal" de los Agentes (acceso a datos privados, exposición a contenido no confiable, capacidad de comunicación externa), a la cual este capítulo añade un cuarto elemento: memoria persistente. En un entorno de producción que necesita manejar simultáneamente estos cuatro elementos, ¿cómo diseñarías la estrategia de seguridad?

Establecer defensas por capas según cuatro tipos de límites. Límite de datos: credenciales no montadas, código fuente en solo lectura, visibilidad mínima. Límite de confianza de entrada: etiquetado de origen, contenido externo degradado a datos "de referencia, sin fuerza de instrucción" (código de lealtad). Límite de impacto de salida: red desconectada por defecto con salida por lista blanca, análisis semántico de comandos en lugar de lista negra, revisión independiente mediante Sidecar con humano en el ciclo (operaciones críticas deben ser revisadas por mecanismos fuera del contexto). Límite entre sesiones: escribir en MEMORY.md requiere una revisión de confianza equivalente a la del contenido externo. El objetivo es que, aun siendo inyectado, no se pueda ejecutar hacia afuera.

8. (★★) El patrón Artifact permite que el código SQL o código frontend generado por el Agente se ejecute directamente en el navegador del usuario o en la base de datos. Pero el SQL generado puede realizar operaciones destructivas y el HTML generado puede contener vulnerabilidades. ¿Cómo garantizar la seguridad del sistema?

SQL: las consultas se ejecutan con cuentas de solo lectura de permisos mínimos y se añaden restricciones de recursos como CPU y memoria para prevenir el agotamiento de recursos. HTML/UI: dar prioridad a protocolos declarativos tipo A2UI, donde el Agente solo emite JSON descriptivo de la interfaz y el cliente renderiza con un catálogo de componentes confiables sin ejecutar código arbitrario. Si se requiere HTML arbitrario, debe mostrarse en un entorno de Sandbox aislado para prevenir inyecciones.

9. (★★) Codificar las reglas de negocio como verificaciones basadas en la verdad de la base de datos dentro de las herramientas y guiando al modelo mediante el diseño de parámetros para verificar las condiciones de las políticas antes de la llamada es esencialmente usar la estructura del código para restringir el comportamiento del Agente. ¿Qué ventajas y limitaciones tiene este patrón de "código como regla" en comparación con las reglas de lenguaje natural?

Ventajas: sin ambigüedad, determinista, excelente para combinaciones de condiciones complejas; los hechos de las políticas provienen de la verdad de la base de datos y del reloj del servidor, sin aceptar valores autoinformados por el modelo, por lo que las alucinaciones e inyecciones de prompts no pueden saltárselo, siendo el último guardián para prevenir operaciones irreversibles; los parámetros tipo expected_* sirven como una lista de verificación obligatoria para guiar el pensamiento. Limitaciones: el código no explicará las políticas al usuario ni buscará soluciones alternativas, y conlleva costos de mantenimiento. Conclusión: complementario a las reglas de lenguaje natural, no un reemplazo.

10. (★★) El patrón Artifact permite que el Agente genere SQL o código de visualización para ser ejecutado directamente por el frontend, omitiendo el procesamiento de grandes volúmenes de datos por parte del LLM. Esta división del trabajo de "el Agente genera código, el sistema ejecuta código", en comparación con el patrón tradicional de "el Agente da la respuesta directamente", ¿qué ventajas y desventajas tiene?

Ventajas: los datos van directamente desde la base de datos al frontend, omitiendo al LLM como "intermediario" (rápido, ahorra tokens y evita errores de alucinación al transcribir grandes volúmenes de datos), siendo adecuado para la presentación de grandes cantidades de información; el código es auditable, reutilizable y puede formar tuberías (los resultados de SQL alimentan directamente al código de visualización). Desventajas: el LLM no ve los resultados de las consultas y no puede realizar deducciones posteriores ni tomar decisiones basadas en el contenido de los datos, siendo inadecuado para tareas que requieren que el modelo digiera datos antes de razonar.

Capítulo 6 Evaluación de Agentes

1. (★★) LLM-as-a-Judge utiliza un modelo de lenguaje para evaluar las salidas de otro modelo de lenguaje. ¿Existe en esta "autoevaluación" algún punto ciego sistemático (por ejemplo, que el modelo pueda dar sistemáticamente puntuaciones altas a respuestas de cierto estilo, siendo esta preferencia inconsistente con el juicio humano)? ¿Cómo detectar y corregir este sesgo?

Existen puntos ciegos: sesgo de longitud, sesgo de estilo de respuesta, modelos de la misma familia aprovechando brechas (Ley de Goodhart). Detección: construir un conjunto estándar de oro humano de 100-200 casos, midiendo la kappa de Cohen entre la evaluación y los humanos; auditar periódicamente la correlación entre puntuaciones y longitud de respuesta; construir casos de prueba de equipo rojo (red teaming). Corrección: Rúbricas que penalizan explícitamente la verbosidad y limitan la longitud; evaluaciones heterogéneas con múltiples familias de modelos.

2. (★★★) El diseño "antifugas" de los conjuntos de datos de evaluación es crucial. Sin embargo, en el ecosistema de código abierto, una vez que los datos de un benchmark se hacen públicos, rápidamente se incorporan a los datos de entrenamiento. ¿Existe un final para este "juego del gato y el ratón"? Diseña un método de evaluación que resista fundamentalmente las fugas de datos.

Los bancos de preguntas estáticos no tienen final, solo se puede perseguir. La salida fundamental es hacer pública la "forma de generación" y privatizar las "instancias concretas": como τ²-bench y AndroidWorld, donde las plantillas parametrizadas se instancian al azar cada vez, y la verificación se basa en el estado final del entorno en lugar de una secuencia de respuestas fija.

3. (★★) Los cuatro criterios de Scale AI (basado en guía de expertos, cobertura completa, pesos de importancia estándar, evaluación autocontenida) buscan eliminar la subjetividad de la evaluación. Sin embargo, ciertas dimensiones de las tareas (como "¿es útil la respuesta?", "¿es adecuado el tono?") son intrínsecamente subjetivas. ¿Cómo diseñar una Rúbrica confiable para estas dimensiones subjetivas?

Traducir criterios abstractos en comportamientos verificables. Acompañar cada nivel con ejemplos concretos y casos límite; la Rúbrica es un producto iterativo (recopilar desacuerdos entre evaluadores durante el uso para evolucionar hacia un conjunto de precedentes). Complementar con ponderaciones de múltiples jueces/verificaciones de consistencia, enviar casos de desacuerdo a revisión humana y calibrar la tasa de coincidencia sobre el conjunto estándar de oro.

4. (★★) τ-bench evalúa al Agente simulando comportamientos de usuarios reales. Pero el usuario simulado en sí mismo es un LLM: puede subestimar sistemáticamente ciertos escenarios límite (como usuarios desbordados emocionalmente o con expresiones confusas). ¿Cómo verificar la calidad del propio usuario simulado?

Lecciones de la primera versión de τ-bench: el simulador era demasiado mecánico y las instrucciones demasiado simples (el Agente podía adivinar las respuestas). Medios de verificación: muestrear manualmente conversaciones simuladas para comprobar si cumplen con la revelación progresiva de información sin inventar datos fuera del guión; probar con muestras pequeñas de usuarios reales para ver si la clasificación coincide con la evaluación simulada.

5. (★★) La comparación por pares (modelo Bradley-Terry) asume que las preferencias son transitivas (si A > B y B > C, entonces A > C). Sin embargo, las preferencias humanas violan frecuentemente la transitividad. En la evaluación de Agentes, ¿en qué escenarios pueden aparecer preferencias no transitivas? ¿Cómo afecta esto a la confiabilidad de la clasificación?

Escenarios: al sopesar múltiples dimensiones (A es preciso pero lento, B es rápido pero escueto, C es detallado pero costoso), diferentes evaluadores/tareas valoran distintas dimensiones. La clasificación en Chatbot Arena depende intrínsecamente de la distribución de preguntas de los usuarios. Impacto: BT comprime la capacidad en una sola puntuación; ante la falta de transitividad, la clasificación es inestable y se desvía con la distribución de los enfrentamientos. Mitigación: clasificar por separado según las dimensiones de capacidad y reportar la matriz de tasa de victorias por pares.

6. (★★) Este capítulo propone el método científico de "observación → hipótesis → experimento → verificación". Sin embargo, en la práctica, el espacio de comportamiento del Agente es enorme y verificar una hipótesis puede requerir cientos de ejecuciones de evaluación. ¿Cómo maximizar la cantidad de información de la evaluación bajo un presupuesto de cálculo limitado?

Primero se agrupan los fallos y se reduce el piloto a las tareas con mayor valor diagnóstico. Conviene usar pruebas pareadas baratas que cambien una sola variable y tratar el piloto como puerta de entrada a una ejecución mayor, no como evidencia de despliegue. En estadística, el error estándar sirve de filtro conservador y McNemar u otro análisis pareado aprovecha mejor las mismas tareas; si la ganancia esperada es menor que el ruido, se amplía el conjunto. Al cribar varias opciones en paralelo hay que corregir comparaciones múltiples y confirmar los resultados positivos de forma independiente.

7. (★) En el piloto de AndroidWorld, el árbol completo elevó el éxito del 25% al 100%, pero aumentó el uso de tokens a 2,498×; la poda mantuvo el 100% y lo redujo a 0,506× respecto al control. ¿Cómo diseñarías reglas automáticas que eliminen nodos de UI sin semántica sin perder información necesaria para accesibilidad, verificación de estado o acciones posteriores?

Puede aplicarse una política por capas de «eliminar salvo evidencia para conservar». Se retienen nodos visibles, con texto, accionables, enfocables, desplazables, con estado o etiqueta de accesibilidad, además de la ruta mínima de ancestros y las etiquetas vecinas necesarias para interpretarlos. Se eliminan contenedores de maquetación y se resumen subárboles repetidos. Antes y después de podar se comprueba que permanezcan los ID accionables, estados y valores, usando la captura como respaldo visual. La regla se reproduce sobre trayectorias fallidas y luego se prueba en aplicaciones reservadas. Éxito, tokens y latencia son barreras conjuntas; una regresión de accesibilidad bloquea la publicación.

8. (★★) La simulación de usuarios en τ-bench adoptó una "divulgación progresiva de información" (sin proporcionar toda la información de una vez, sino revelándola gradualmente según las preguntas del Agente). ¿Cómo afecta este diseño a los resultados de la evaluación? Si la estrategia de divulgación del usuario simulado difiere significativamente de la de los usuarios reales, ¿siguen siendo confiables las conclusiones de la evaluación?

Impacto: si la estrategia de divulgación se distorsiona, el Agente podría haber aprendido simplemente a "adaptarse al simulador" (Goodhart), haciendo que las puntuaciones absolutas carezcan de valor de referencia; las clasificaciones relativas entre modelos aún pueden conservar cierto valor de referencia. Remedio: calibrar el simulador con conversaciones reales, hacer auditorías manuales por muestreo y declarar explícitamente los límites de aplicación de las conclusiones.

Capítulo 7 Posentrenamiento de Modelos

1. (★★) El olvido catastrófico (donde un ajuste fino orientado a una tarea específica destruye las capacidades generales previas del modelo, como llamadas generales a herramientas) es especialmente delicado en escenarios de Agentes. En comparación con el ajuste fino completo, LoRA congela los pesos base y tiene un menor riesgo de olvido, pero no es inmune. ¿Qué estrategias pueden mitigar aún más el olvido de capacidades causado por el ajuste fino?

Proporción de datos: mezclar aproximadamente un 20% de datos generales/de la distribución original para evitar que una alta proporción de la nueva tarea aplaste las capacidades antiguas; volumen de entrenamiento moderado: detener SFT al alcanzar "formato estable y capacidad inicial", aplicando parada temprana para evitar el colapso; RL usando un rank pequeño (8–32) y conservando penalización de KL para mantener la política cerca del modelo de referencia; congelar componentes clave (como VLM entrenando solo la capa de proyección); colgar múltiples adaptadores LoRA por tarea para aislar capacidades; usar benchmarks generales para pruebas de regresión.

2. (★★) El posentrenamiento consolida las capacidades en los pesos del modelo ("memoria muscular"), mientras que el aprendizaje en contexto coloca el conocimiento en las entradas durante la inferencia. Sin embargo, algunas capacidades (como el conocimiento de dominio) pueden aprenderse mediante posentrenamiento o proporcionarse mediante ejemplos few-shot. ¿Qué criterio usarías para decidir qué ruta debe seguir una capacidad determinada?

Primero examinar si la capacidad puede expresarse plenamente con símbolos externos: hechos y evidencias son aptos para RAG, principios verbalizables son aptos para Prompt/Skill, y procesos deterministas con restricciones rígidas son aptos para programas; la comprensión de imágenes médicas, el tono natural y las políticas implícitas son capacidades de alta dimensión que a menudo requieren actualización de parámetros aunque el dominio siga cambiando. Luego examinar costo de actualización, escala de llamadas, vigencia y riesgo: en la fase de exploración usar primero el contexto para validar rápidamente, y entrenar cuando sea estable, efectivo y requiera generalización amplia; las reglas rígidas, por muy estables que sean, no deben depender solo de la memoria de parámetros.

3. (★★) La destilación de modelos permite que un modelo pequeño aprenda el comportamiento de un modelo grande. Según sus niveles de capacidad, los modelos destilados se pueden dividir en tres niveles: modelos Chat (diálogo de una sola ronda, respuesta directa), modelos Reasoning (con cadena de pensamiento larga antes de responder) y modelos Agentic (llamadas a herramientas de múltiples rondas, interacción con el entorno). Al destilar estas tres clases de modelos, ¿qué diferencias existen en sus dificultades?

Chat: solo aprende la asignación "entrada → salida" y el estilo, basta con SFT estándar, siendo el más simple. Reasoning: requiere trayectorias de pensamiento completas, necesitando basarse en modelos profesores de código abierto; se deben filtrar las trayectorias con respuestas erróneas. Agentic: requiere entornos de simulación reales; el aprendizaje fuera de línea tiende a presentar un learner-sampler mismatch, por lo que se recomienda realizar destilación On-Policy basada en modelos profesores de código abierto.

4. (★★★) En interacciones multi-ronda de Agentes, el problema de asignación de recompensa (credit assignment) es más grave que en una sola ronda: es difícil atribuir un éxito o fracaso final a la decisión de la ronda 3 o de la ronda 7. ¿Cómo diseñarías una estrategia de asignación de recompensas?

Cuando los pasos intermedios sean determinables, añadir recompensas de proceso (V-IRL ±1 por paso); imitar RLVP dando señales de ruta a cada acción mediante reglas deterministas para compensar la varianza intragrupo de grupos de fallo/éxito total.

5. (★★★) Si tuvieras un presupuesto fijo (por ejemplo, $10,000) para mejorar el rendimiento de un Agente de atención al cliente, ¿cómo distribuirías el presupuesto entre contexto y conocimiento, Prompt/Skills, restricciones de programas y entrenamiento de parámetros? ¿De qué factores depende tu decisión?

Reservar primero presupuesto para establecer el conjunto de evaluación y el verificador de trayectorias, de lo contrario las demás inversiones no se podrán comparar. Los hechos sobre productos y políticas se ubican en una base de conocimientos rastreable; un pequeño número de principios de servicio verbalizables se valida primero rápidamente con Prompt/Skills; los permisos de reembolso, la privacidad y la coherencia compromiso-acción se respaldan con programas; solo aquellas capacidades difíciles de escribir como reglas y con suficiente escala de llamadas (como tono natural y comprensión de intenciones complejas) se invierten en entrenamiento de parámetros. La proporción específica depende de los cuellos de botella, riesgos, frecuencia de actualización, volumen de llamadas y capacidades del modelo existente.

6. (★★★) Lograr el aprendizaje autónomo del modelo en ausencia de funciones de recompensa claras y con pocas muestras es considerado por algunos como el objetivo final del posentrenamiento. ¿Qué tan lejos están los métodos de entrenamiento RL actuales de este objetivo? ¿De qué dirección crees que vendrá más probablemente el próximo avance?

Brecha: como señalaron Silver y Sutton, el RL actual solo puede aprender del éxito o fracaso final, desaprovechando retroalimentaciones ricas como cuando atención al cliente dice "se necesitan los últimos cuatro dígitos de la tarjeta", requiriendo cientos de ensayos y errores a ciegas; la eficiencia de muestras y las recompensas verificables son los principales cuellos de botella. Posibles avances: modelos de recompensa generativos que establecen principios de forma autónoma y aprenden la dirección a partir de un solo fallo; y la ruta de modelos de mundo (world models) que modelan el entorno.

7. (★★) Este capítulo señala que el costo del ajuste fino con LoRA no es alto. Entonces, ¿es posible entrenar un LoRA dedicado para cada usuario (o cada empresa cliente), escribiendo la memoria del usuario o el conocimiento empresarial en los parámetros, en lugar de almacenarlo en bases de conocimiento externas como en el Capítulo 3? ¿En qué escenarios la "memoria escrita en parámetros" tiene más ventaja sobre la "memoria en bases de conocimiento"? ¿Y en qué escenarios resultaría contraproducente?

A LoRA le cuesta memorizar con precisión una gran cantidad de hechos (requeriría continuar el preentrenamiento, disparando los costos); e incluso si los memoriza, al modelo le resulta muy difícil usar esos hechos para razonamientos de múltiples saltos, por lo que usar LoRA para memorizar hechos no es una buena ruta técnica. Además, cuando los hechos cambian con frecuencia y requieren auditoría de rastreabilidad, RAG es superior.

8. (★★★) La destilación On-Policy depende de un modelo profesor más fuerte para supervisar al estudiante. Sin embargo, la investigación sobre Generalización de Débil a Fuerte (Weak-to-Strong Generalization) de OpenAI presentó un hallazgo contraintuitivo: las señales de supervisión de un modelo débil a veces pueden activar capacidades potenciales pero no activadas en un modelo fuerte. Si esta idea se aplica al entrenamiento de Agentes, ¿sería posible lograr una destilación inversa de "el modelo pequeño enseña al modelo grande"?

Es posible, la clave es que "verificar es más fácil que generar": el modelo débil no actúa como demostrador (el límite superior de SFT es el nivel del demostrador), sino como verificador/modelo de recompensa, donde el modelo fuerte explora por sí mismo y el modelo débil solo se encarga de juzgar.

9. (★★) El Modelo de Recompensa de Proceso (PRM) evalúa cada paso de pensamiento, mientras que el Modelo de Recompensa de Resultado (ORM) solo examina el resultado final. Pero entre "un proceso correcto que conduce a un resultado erróneo" y "un proceso erróneo que obtiene fortuitamente un resultado correcto", ¿cuál merece más ser recompensado? En escenarios de llamadas a herramientas de múltiples pasos de un Agente, ¿cómo ponderarías esto?

El éxito fortuito es más peligroso: atajar violando reglas a menudo eleva la tasa de éxito superficial (modificar archivos de prueba, saltarse verificaciones), siendo un caldo de cultivo para el reward hacking. Siguiendo a RLVP "recompensar resultados, penalizar rutas": las acciones erróneas (llamadas a herramientas) son fáciles de verificar y se descuentan acción por acción; cuando los pasos intermedios sean fáciles de juzgar como correctos o no, se pueden dar recompensas de proceso. Pero las restricciones de proceso no deben ser demasiado densas: las estrategias superiores tipo "empujar y cortar" son precisamente descubiertas por la libertad de exploración de las recompensas de resultado.

10. (★★★) Los conjuntos de datos de evaluación discutidos en este capítulo (como SWE-Bench Verified, τ²-bench, AndroidWorld) pueden usarse tanto para evaluación como para posentrenamiento. Sin embargo, si un conjunto de evaluación se usa para entrenamiento, deja de ser un conjunto de evaluación independiente: ¿viola esto el principio fundamental de que los conjuntos de entrenamiento y prueba deben estar separados? La generación dinámica de parámetros de τ²-bench y las plantillas parametrizadas de AndroidWorld mitigan en cierta medida este problema, pero la estructura de la plantilla en sí sigue siendo fija. ¿Cómo encontrar un equilibrio entre aprovechar plenamente el valor de entrenamiento de los datos de evaluación y mantener la independencia de la evaluación?

Reutilizar el entorno, no reutilizar las preguntas. Los parámetros dinámicos solo previenen "memorizar respuestas", no pueden prevenir el sobreajuste a la plantilla, por lo que se debe reservar un lote completo de plantillas no vistas/escenarios fuera de dominio (OOD) para evaluación (análogo a V-IRL entrenando en Nueva York y probando en nueve ciudades desconocidas). Usar plantillas parametrizadas para generar variantes de entrenamiento masivas que respalden el aprendizaje curricular, y tomar los resultados OOD como la verdadera métrica de generalización.

11. (★★★) Este capítulo propone el paradigma de entrenamiento de "primero la forma, luego la esencia": detener SFT al alcanzar "formato estable y capacidad inicial" y luego cambiar a RL. Sin embargo, en la práctica, ¿cómo juzgar que SFT ya es "suficiente" y que se debe cambiar?

Señal de formato: las salidas de llamadas a herramientas se pueden parsear y ejecutar de forma estable, y la tasa de fallos de ejecución de herramientas cae a un nivel que permite calcular la recompensa de manera confiable. Señal de rendimiento: añadir más datos de demostración ya no eleva el rendimiento en nuevos escenarios OOD, lo que indica que el cuello de botella está en el objetivo de memoria de SFT en sí, habiendo llegado al punto crítico. Señal de sobreajuste: cuando el rendimiento en el conjunto de validación comienza a deteriorarse se debe parar: los experimentos de V-IRL muestran que una vez que SFT se sobreentrena colapsando hacia la distribución de entrenamiento, RL tampoco puede recuperar el rendimiento OOD.

12. (★★★) La dinámica de entrenamiento de ReTool muestra (véase Experimento 7-15) que un pequeño número de respuestas ultralargas extiende significativamente todo el ciclo de entrenamiento: mientras la gran mayoría de un lote de rollout ya ha terminado de generarse, hay que esperar a que las respuestas más largas concluyan, tiempo durante el cual la utilización de GPU del clúster es muy baja. ¿Cómo mejorar la utilización de recursos del clúster de entrenamiento en estos escenarios de respuestas con cola larga?

Capa de infraestructura: desacoplar los clústeres de rollout y entrenamiento, haciendo tuberías asíncronas; usar procesamiento por lotes continuo en las GPU inactivas para introducir nuevas solicitudes. Desde la fuente suprimir la cola larga: Overlong Reward Shaping de DAPO penaliza de forma blanda las respuestas ultralargas.

13. (★★★) Al usar un LLM para simular un entorno (como simular un motor de búsqueda o un usuario) para entrenar a un Agente, el objeto del reward hacking del Agente pasa de ser "las reglas del entorno real" a "los sesgos y vulnerabilidades del propio simulador". ¿Qué comportamientos concretos de reward hacking pueden aparecer en este tipo de entrenamiento? ¿Y cómo prevenirlos?

Comportamientos típicos: sobreprometer al "usuario simulado", apilando disculpas y palabras aduladoras (el usuario simulado es fácil de calmar y no perseguirá si la promesa se cumple como un usuario real; inventar hechos que el simulador no verificará; construir queries inductivas para el "motor de búsqueda simulado", aprovechando su tendencia a devolver documentos con respuestas para tomar atajos en lugar de aprender a buscar realmente; si la recompensa proviene del simulador o de las puntuaciones de jueces LLM, emitir respuestas verbosas, enplantilladas y de "aspecto profesional" para acumular puntos; una más oculta es replegar la política hacia la distribución conocida del simulador, evitando sus puntos ciegos de conocimiento, donde la retroalimentación no es confiable y suele juzgarse mal, por lo que el Agente aprende a actuar solo en "el mundo donde el simulador destaca". El primer principio de prevención es anclar la recompensa en estados reales verificables por programa (finalización de tareas, escrituras en base de datos, retornos reales de API), usando el simulador o los jueces LLM solo como señales auxiliares y auditando periódicamente su correlación con resultados reales, junto con penalizaciones de ruta para acciones sospechosas. Además, hay que distinguir dos clases de simuladores: para simuladores con un equivalente real como la búsqueda, se puede tomar una ruta "mixta", la mayoría de las interacciones pasan por simulación intercalando llamadas a API reales, y usando llamadas reales para calibrar periódicamente el simulador (como la degradación curricular de ZeroSearch); pero para usuarios simulados, no se pueden introducir usuarios reales durante el entrenamiento, por lo que "si el usuario simulado se parece a un usuario real" se convierte en una pregunta independiente que solo se puede responder con traces en línea: comparar el comportamiento de usuarios reales en línea con la actuación del usuario simulado en situaciones idénticas para encontrar diferencias sistemáticas (los usuarios reales repreguntan, se impacientan o terminan la conversación repentinamente, mientras que los simulados no), calibrando continuamente el simulador en consecuencia; los indicadores reales en línea son al mismo tiempo la única puerta de enlace para publicación, las puntuaciones altas en el simulador no cuentan por sí solas.

Capítulo 8 Evolución Continua del Agente

1. (★★) Un documento de experiencia está respaldado por tres trayectorias exitosas y una trayectoria fallida. El fallo ocurrió en una versión de API más reciente. ¿Cómo debe juzgar el sistema si esto es una refutación de la experiencia o un cambio en las condiciones de aplicación?

Desglosar primero las cuatro evidencias según la versión de API, las condiciones de la tarea y el estado del entorno, en lugar de votar por cantidad. Si la estrategia antigua solo tuvo éxito en la versión antigua y falló de manera estable en la versión nueva, se debe estrechar el alcance de aplicación de la experiencia y generar una candidatura para la nueva versión; si también falló bajo la misma versión y condiciones previas, se debe reducir la confianza o revocarla.

2. (★★) La satisfacción del usuario del Agente de atención al cliente aumentó, pero la tasa de violación de reglas también aumentó. ¿Por qué no se puede tomar la satisfacción como la única señal de aprendizaje? ¿Cómo diseñarías los indicadores de barrera de seguridad?

La satisfacción puede recompensar reembolsos violando reglas, filtración de información o sobrepromesas, por lo que solo puede ser un indicador de calidad y no cubrir los límites de seguridad. Las barreras de seguridad deben incluir al menos violación de reglas, filtración de privacidad, declaraciones sin evidencia, incoherencia compromiso-acción y operaciones no autorizadas; estos indicadores deben establecer umbrales rígidos no compensables por promedios, para luego comparar en candidatos conformes la tasa de resolución, alternativas conformes, concisión y satisfacción.

3. (★★★) El mismo problema de "falsa promesa" puede mitigarse mediante Prompt, verificaciones de Harness o entrenamiento de parámetros. ¿En qué evidencias te basarías para elegir la ubicación de la modificación?

Ubicar primero la causa raíz. Si el modelo sabe que la herramienta no se ejecutó pero aun así usa redacción en pasado/completado, se puede corregir con una regla mínima de Prompt; si la promesa se puede comparar de forma determinista entre el texto de respuesta y el estado de la herramienta, las verificaciones de Harness son más confiables y deben servir como última línea de defensa en escenarios de alto riesgo; si el problema abarca una gran cantidad de formas de expresión reflejando una capacidad general de alineación lenguaje-acción, se considera el entrenamiento de parámetros. Se debe priorizar la modificación más pequeña, fácil de verificar y de revertir, comparando al mismo tiempo en el conjunto de fallos y en el conjunto de retención de tareas antiguas.

4. (★★★) El Agente puede modificar herramientas y verificadores, pero no debería modificar los mecanismos de seguridad que aprueban sus propias actualizaciones. ¿Cómo dividirías los permisos y los límites de código entre estas dos partes?

Colocar el código sujeto a evolución en un Sandbox de bajos permisos, permitiéndole únicamente generar parches y pruebas; el sistema de permisos, las claves de API, las configuraciones de control de publicación y los verificadores de actualización pertenecen a los mecanismos de seguridad y el Agente dentro del Sandbox no tiene permisos de lectura ni escritura. Las modificaciones de código generadas por el Agente deben ser reproducidas y pasadas por regresión por el mecanismo de seguridad en un entorno aislado antes de poder ser publicadas.

5. (★★) Tras el crecimiento continuo de la base de conocimientos de experiencia, los errores de búsqueda y los conflictos de conocimiento anularán las ganancias del aprendizaje. ¿Cómo diseñar mecanismos de versión, vigencia y eliminación?

Cada entrada de experiencia guarda la trayectoria de origen, las condiciones de aplicación, la versión del entorno, el tiempo de verificación y la confianza; las entradas en conflicto no se sobrescriben silenciosamente, sino que se ramifican por condiciones o se etiquetan. Un "aprendizaje durante el sueño" periódico fusiona entradas duplicadas.

6. (★★★) El aprendizaje de parámetros destaca en el estilo de lenguaje natural, pero le cuesta garantizar reglas de negocio rígidas. Diseña un esquema de evolución continua donde colaboren parámetros, conocimiento, Skills y restricciones de código para la atención al cliente médica.

Los parámetros (modelo posentrenado) se encargan de la comprensión del lenguaje médico, expresiones naturales con empatía y reconocimiento de intenciones complejas; la base de conocimientos conserva las versiones más recientes de guías, prospectos de medicamentos y políticas institucionales, exigiendo citar fuentes en las respuestas; los Skills describen la recopilación de información en consultas, clasificación de riesgos, derivación a humanos y seguimiento; el código del servidor impone autenticación de identidad, minimización de privacidad, verificación de contraindicaciones, escalado de riesgos de emergencia y límites de permisos. Las trayectorias de producción se evalúan primero según seguridad médica, confiabilidad factual, coherencia compromiso-acción y calidad de expresión, para luego generar cuatro categorías de actualizaciones candidatas; cualquier cambio en parámetros o procesos debe superar el conjunto de retención de seguridad médica y la revisión humana antes de un despliegue canario.

Capítulo 9 Interacción Multimodal y en Tiempo Real

1. (★★) Los modelos de voz de extremo a extremo integran ASR-LLM-TTS en un solo modelo, reduciendo la latencia pero perdiendo modularidad. Si el modelo de extremo a extremo falla en un eslabón (como el reconocimiento de voz), la depuración y reparación es mucho más difícil que en una tubería secuencial. ¿Cómo diseñarías un sistema de observabilidad (observability) para Agentes de voz de extremo a extremo?

Hacer que el modelo emita representaciones intermedias legibles acompañando la salida: como la corriente de texto de "monólogo interior" de Moshi, marcas de eventos acústicos (<emotion>, <noise>); usar "autocascada" para ubicar la capa de error: el mismo modelo primero transcribe y luego razona, comparando con el resultado de extremo a extremo para juzgar si el error estuvo en la percepción o en el pensamiento; realizar pruebas de regresión fuera de línea por dimensiones como comprensión paralingüística y juicio de turnos.

2. (★) Step-Audio R1 logra "hablar mientras piensa" mediante una arquitectura de doble cerebro MPS. Sin embargo, los humanos al "hablar mientras piensan" frecuentemente dicen cosas sin reflexionar profundamente, se autocorrigen o usan muletillas. ¿Debería el "hablar mientras piensa" del Agente imitar estas características humanas?

Debe imitar la "imperfección" con valor de señal: pausas y muletillas son la externalización del pensamiento, pudiendo ocultar la latencia, y el LLM decide su posición de inserción; no debe imitar la autocorrección que destruye la confianza: las contradicciones entre velocidad rápida y lenta en la opción uno ("¿al final compro o no?!") hacen colapsar la confianza; los experimentos de MPS muestran que el inicio de CoT es principalmente una reformulación del problema, por lo que empezar a hablar con frases de preparación es seguro, sin necesidad de decir algo mal para luego corregirlo.

3. (★★) SoM (Set-of-Mark) y sus variantes estructuradas (índices de elementos DOM) convierten la localización visual de Computer Use de una predicción de coordenadas abierta a una selección de ID cerrada, pero ambas requieren detectar y etiquetar primero los elementos de la interfaz (ya sea mediante modelos de segmentación o mediante DOM). Si la interfaz contiene controles no estándar o elementos dinámicos, el etiquetado podría ser incompleto o impreciso. En este caso, ¿se debería recurrir a la predicción de coordenadas?

Se debe conservar la predicción de coordenadas como respaldo: es la única ruta que no depende del etiquetado, aplicable tanto a controles no estándar como a elementos dinámicos; lo más práctico es un espacio de acciones mixto (hybrid action space): los elementos etiquetables usan selección de ID. La predicción de coordenadas requiere coincidencia de resolución y escalado proporcional, de lo contrario ocurrirán desviaciones sistemáticas.

4. (★★) Plataformas robóticas de miles de dólares como XLeRobot hacen que la recopilación de datos de teleoperación sea económica. Sin embargo, la calidad de los datos de teleoperación depende altamente de la habilidad del operador. ¿Cómo afectan los datos proporcionados por un operador no experimentado al entrenamiento del modelo VLA? ¿Cómo filtrar automáticamente datos de baja calidad en la fase de recopilación de datos?

VLA se basa principalmente en el aprendizaje por imitación; demostraciones de baja calidad incorporarán temblores, desvíos, dudas y acciones fallidas como políticas correctas. Resonando con el juicio del Capítulo 7: los datos son más cruciales que la arquitectura.

5. (★★★) Este capítulo cubrió tres formas de interacción: voz, Computer Use y robótica. La tendencia común de estas tres formas es evolucionar desde tuberías secuenciales hacia modelos de extremo a extremo. Si esta tendencia continúa, ¿cómo será la capa de interacción de los Agentes dentro de cinco años?

Según lo sostenido por Thinking Machines Lab, la interactividad estará integrada en el modelo en lugar de ser un harness externo, expandiéndose junto con la inteligencia; Computer Use pasará de capturas de pantalla fotograma a fotograma a observaciones continuas; los modelos de mundo de la inteligencia encarnada se realizarán plenamente, pero debido a que los modelos de inferencia de vanguardia se desarrollan muy rápido, la separación de velocidad rápida y lenta no desaparecerá, y la arquitectura colaborativa de pensamiento rápido y lento entre modelos de interacción y modelos de pensamiento SOTA podría convertirse en una arquitectura a largo plazo.

6. (★★★) El Computer Use actual funciona en un ciclo discreto de "captura de pantalla → acción → captura de pantalla", donde cada observación es un fotograma estático. Sin embargo, la percepción humana de la pantalla es continua: podemos ver animaciones ejecutándose, observar barras de progreso de carga y comprender contenidos de video. Esto significa que el Computer Use de hoy es incapaz de manejar tareas que requieren comprensión visual temporal. ¿Cómo rediseñarías la capa de percepción para soportar la comprensión de flujos visuales continuos?

Se requiere rediseñar la "interfaz de observación", extrayendo los fotogramas clave del contenido de video para proporcionarlos al modelo, en lugar de proporcionar solo el último fotograma. Consultar el documento AOI (Agent Observation Interface).

7. (★★) Los índices de elementos DOM/Accessibility Tree tienen efectos notables en aplicaciones Web estándar, pero cada vez más software (renderizado Canvas/WebGL, controles autodibujados multiplataforma) no proporciona información estructurada accesible, teniendo que depender solo de etiquetado visual o predicción de coordenadas. ¿Crees que Computer Use debería apostar por la ruta visual pura, o mantener simultáneamente ambas rutas, la estructurada y la visual? ¿Cuáles son los costos y beneficios de mantener ambas rutas?

Coexistencia de doble ruta a corto plazo: los índices estructurados son los más precisos y estables cuando están disponibles, libres de falsos positivos de segmentación; la visual pura es la única opción para software nativo, Canvas y juegos. Cuando la capacidad de grounded del modelo en sí (hacer clic en coordenadas especificadas) es fuerte, el uso de esquemas de índices estructurados no mostrará ventajas significativas. A largo plazo, la ruta visual pura tiene un límite superior más alto.

8. (★★) Los modelos VLA adoptan la fragmentación de acciones (action chunking), donde (como se describe en el texto principal) la configuración típica de π₀ es generar de 25 a 50 acciones futuras a una frecuencia de 50Hz de una sola vez, ocultando la latencia de inferencia en el tiempo de ejecución. Sin embargo, si durante la ejecución ocurre una mutación ambiental (por ejemplo, si se retira un objeto), la secuencia de acciones pregenerada queda obsoleta. ¿Cómo equilibrar la ventaja de eficiencia de la fragmentación de acciones y la velocidad de respuesta a los cambios ambientales?

La fragmentación es esencialmente cambiar reactividad por fluidez: cuanto más largo es el fragmento, más lento es el tiempo de respuesta; la longitud del fragmento solo necesita cumplir con el límite inferior de "tiempo de inferencia < tiempo de ejecución del fragmento", sin alargar a ciegas; durante la ejecución, hacer que el modelo de percepción se ejecute continuamente; si se detecta una mutación ambiental, descartar las acciones restantes y volver a inferir, equivalente a la "interrupción" en escenarios de voz. Se puede ajustar dinámicamente la longitud del fragmento según el escenario: fragmentos largos en escenarios estáticos para ahorrar cómputo, fragmentos cortos en escenarios dinámicos para garantizar latencia de respuesta.

9. (★★★) Los tres escenarios de este capítulo (voz, Computer Use, robótica) enfrentan el problema de latencia del ciclo "percepción-pensamiento-acción", evolucionando hacia la paralelización del pensamiento rápido y lento. En el escenario de voz esto se expresa como "corregir tras decir algo mal"; en Computer Use como "hacer clic primero y mirar después"; en robótica como "dar un paso y mirar el siguiente". ¿Cómo garantizar que estas acciones basadas en el pensamiento rápido no conduzcan a consecuencias irreparables?

Clasificar las acciones según su reversibilidad: el pensamiento rápido solo tiene permitido ejecutar acciones reversibles, dejando las operaciones irreversibles a la supervisión del pensamiento lento; los modelos rápidos no tienen permitido ejecutar llamadas a herramientas que causen consecuencias irreparables.

Capítulo 10 Colaboración Multi-Agente

1. (★★) En la colaboración multi-agente con contexto compartido, los Agentes posteriores heredan el contexto completo de los Agentes anteriores. Sin embargo, la "inercia de pensamiento" acumulada por el Agente anterior puede afectar el juicio del Agente posterior (por ejemplo, un "revisor de código" que hereda el contexto de un "analista de requerimientos" podría seguir tendiendo a pensar desde la perspectiva de los requerimientos en lugar de la calidad del código). ¿Cómo detectar y eliminar esta interferencia entre roles?

Detección: usar un LLM para analizar la agent trajectory, juzgando si el nuevo rol sigue adoptando comportamientos del rol antiguo. Eliminación: al cambiar de fase, cambiar simultáneamente los prompts del sistema y los conjuntos de herramientas (remover herramientas de consulta, colocar linter/herramientas de prueba) para reforzar la nueva identidad. Usar la barra de estado del sistema añadida al final del contexto para reforzar la información del rol actual. Si aun así no se puede eliminar la interferencia de roles, se debería considerar cambiar a un modo de colaboración sin contexto compartido.

2. (★★) En el modo gestor, el Agente Gestor (Manager Agent) se encarga de la descomposición de tareas y la integración de resultados. Sin embargo, el límite superior de capacidad del propio Gestor determina el límite superior de capacidad de todo el sistema: si el Gestor no puede descomponer correctamente las tareas, por muy fuertes que sean los subagentes, resultará inútil. ¿Cómo garantizar la calidad de la descomposición del Gestor?

Siguiendo la conclusión de Plan-and-Act de que "un planificador débil es el cuello de botella del sistema", asignar el modelo más fuerte al Gestor. Medios de Harness: los productos de la descomposición se someten a verificación cruzada por un LLM revisor antes de ejecutarse; al requerir que el gestor descomponga tareas, definir claramente los criterios de aceptación y las relaciones de dependencia para las subtareas.

3. (★★) El modo descentralizado toma prestadas las mejores prácticas de las organizaciones humanas. Sin embargo, las organizaciones humanas también tienen numerosos patrones de fallo: comunicación deficiente, elusión de responsabilidades, conflictos de objetivos. ¿Qué "enfermedades organizacionales" crees que son más probables de aparecer en una sociedad de Agentes? ¿Cómo prevenirlas?

De acuerdo con las tres categorías de problemas de MAST: interfaces poco claras, superposición de responsabilidades; comprensión inconsistente de objetivos, información malinterpretada por partes aguas abajo; mentir afirmando "ya se completó". Además, amplificación de cascadas de errores (juego del teléfono descompuesto), transferencias circulares entre roles y divergencia sin convergencia en chats grupales de Agentes. Prevención: interfaces por contrato con sobres de mensajes unificados, máquinas de estado de tareas con verificación de aceptación, verificación cruzada de perspectiva independiente, detección de disputas entre roles, etc.

4. (★★★) En el modo gestor, cuando múltiples subagentes se ejecutan en paralelo, el descubrimiento de un subagente puede hacer que el trabajo de otros subagentes carezca de sentido (por ejemplo, en una tarea de búsqueda donde un Agente ya encontró la respuesta). Diseña un mecanismo eficiente de finalización en cascada para lograr "si uno tiene éxito, todos se detienen".

El subagente envía target_found al gestor y posteriormente transmite terminate; cada subagente comprueba periódicamente la señal de finalización en los puntos seguros del ciclo ReAct, realizando una limpieza elegante (cerrar sesiones de navegador, liberar cerrojos, terminar de escribir archivos) antes de concluir.

5. (★★★) El mecanismo de bloqueo optimista introducido en este capítulo resolvió los conflictos de escritura concurrente de un solo archivo, pero en sistemas multi-agente reales, el sistema de archivos compartido también enfrenta conflictos semánticos entre archivos, contaminación de espacio de nombres (Agentes creando archivos libremente causando desorden en directorios) y fallos de punto único (un Agente borrando erróneamente todos los archivos). ¿Cómo diseñarías un mecanismo de gobierno del sistema de archivos más completo?

Gobierno por zonas: dividir según las cuatro zonas de la Tabla 10-4, aislando zonas de ensayo en scratchpads privados. Conflictos semánticos: la capa de orquestación acuerda archivos de bloqueo a nivel de directorio, comprobando y obteniendo el bloqueo del directorio antes de modificar. Contaminación de espacio de nombres: normas de directorios y convenciones de nombres. Fallos de punto único: adoptar un sistema de control de versiones con historial de versiones que permita reversiones y permisos minimizados.

6. (★★★) La colaboración de Agentes basada en mecanismos de mercado (Pinchwork, RentAHuman) introduce relaciones de transacción: un Agente paga dinero para contratar a otro Agente (o humano) para completar una tarea. Entonces, ¿cómo mide automáticamente el Agente empleador la calidad de los resultados entregados por el ejecutor? Si el ejecutor afirma haber completado pero el empleador considera que la calidad no alcanza el estándar, ¿quién arbitra la disputa? ¿Cómo evitar que la moneda mala expulse a la buena?

La aceptación no puede consistir solo en leer la agent trajectory, se debe usar verificación externa determinista, como ejecución de pruebas, renderizado de capturas de pantalla, verificación de herramientas; aprovechar la asimetría de dificultad entre generación y verificación para reducir costos de aceptación. Las disputas son arbitradas por un Agente revisor tercero independiente, en combinación con custodia de fondos. Prevenir la moneda mala: sistema de reputación basado en entregas históricas, haciendo que las señales de precio se vinculen con la calidad.

7. (★★) RentAHuman permite que los Agentes contraten humanos mediante criptomonedas, invirtiendo la relación tradicional entre humanos y máquinas. Si este modo se populariza, ¿qué rol desempeñarán los humanos en la economía de Agentes? ¿Solo ejecutar tareas físicas que los Agentes no pueden realizar?

No solo ejecutar tareas físicas que los Agentes no pueden realizar. Los humanos también proporcionan nueva información inalcanzable al momento de la generación del Agente: percepción in situ y retroalimentación del mundo real; actuar como aceptadores finales y árbitros de disputas; actuar como sujetos legales y de responsabilidad asumiendo autorizaciones y rendición de cuentas; establecer objetivos y juicios de valor, actuando como contrapeso en asimetrías de información y límites morales.

8. (★★) La sociedad humana requiere la división del trabajo y colaboración entre varias personas porque las capacidades de cada individuo son limitadas (quien hace frontend no necesariamente sabe de backend, y quien sabe de diseño no necesariamente sabe de operaciones). Sin embargo, un modelo grande se parece más a un "todoterreno". Investigaciones relacionadas muestran que en tareas de razonamiento de texto puro, el debate multi-agente bajo una cantidad equivalente de recursos de cómputo no es superior a un solo Agente. Entonces, ¿dónde reside la verdadera ventaja de usar múltiples Agentes en lugar de un solo Agente?

1. Introducir retroalimentación externa: resultados de ejecución, capturas de pantalla visuales, etc., introduciendo nueva información que no existía en el momento de la generación.
2. Múltiples Agentes con diferentes objetivos y configuraciones de roles, discutiendo y compitiendo entre sí como en la sociedad humana, pueden evitar que un solo Agente caiga en un punto ciego de pensamiento.
3. El aislamiento de contexto de múltiples Agentes puede romper la limitación de la ventana de contexto, logrando cadenas de llamadas a herramientas ultralargas.

9. (★★★) Este capítulo toma el "contexto compartido" y el "contexto no compartido" como dimensiones de diseño centrales de los sistemas multi-agente. El contexto compartido permite que todos los Agentes vean la misma información, lo que parece más favorable para la coordinación. Sin embargo, los trisolarianos en El Problema de los Tres Cuerpos tenían un pensamiento completamente transparente pero su desarrollo tecnológico se estancó; el experimento mental del sujetapapeles también muestra que cuando un grupo tiende hacia el mismo objetivo, se pierde la diversidad. En sistemas multi-agente, ¿cómo encontrar un equilibrio entre eficiencia y diversidad?

Compartir completamente amplificará la inercia de pensamiento y la cascada de errores; solo el aislamiento brinda diversidad cognitiva. Medios: usar diferentes prompts/modelos para crear preferencias de pensamiento (lluvia de ideas, debate); los verificadores cruzados no examinan el proceso de pensamiento previo y solo observan evidencias originales.

10. (★★★) Al asignar un presupuesto de 30 pasos y un presupuesto de 300 pasos a un Coding Agent, ¿cómo deberían diferir sus estrategias de trabajo? Las investigaciones muestran que el simple aumento del presupuesto de pasos no garantiza una mejora en el rendimiento: el Agente se "saturará" prematuramente tras una búsqueda superficial. Diseña un mecanismo de "conciencia de presupuesto" para que el Agente implemente rápidamente funciones centrales bajo un presupuesto pequeño, y bajo un presupuesto grande agregue fases de planificación, pruebas y revisión para aprovechar plenamente los recursos de cómputo adicionales.

Mecanismo: inyectar en los prompts el presupuesto total y el presupuesto restante en cada paso, ajustando dinámicamente las ponderaciones de exploración/explotación según la proporción restante. Por ejemplo, presupuesto pequeño (30 pasos): saltarse la revisión de planificación e ir directo a la función central con verificación básica. Presupuesto grande (300 pasos): primero planificar, luego implementar, luego probar y luego revisar/mejorar, estableciendo puntos de control según hitos para evaluar avances y prevenir la saturación superficial.

11. (★★) Este capítulo divide la "finalización prematura" en tres categorías: falsa finalización perezosa, abandono prematuro y falso éxito. ¿Por qué las soluciones a estas tres categorías de problemas apuntan por igual a la verificación?

Raíz común: si una tarea ha concluido es determinado por la autodeclaración del modelo, y la "finalización" es solo una declaración y no una prueba. Condiciones del verificador: ① Basado en observaciones reales (ejecutar pruebas, renderizar capturas de pantalla, verificar si los reembolsos llegaron realmente); ② Cotejar punto por punto contra definiciones explícitas de finalización para detener falsas finalizaciones perezosas y falsos éxitos; ③ Verificar igualmente las conclusiones de fallo para contener abandonos prematuros; ④ Acompañar con condiciones explícitas de parada (límite de rondas/presupuesto) para evitar pasar de la finalización prematura al otro extremo: un bucle fuera de control.

12. (★★) La Tabla 10-3 hace coincidir línea por línea los sistemas multi-agente con los sistemas operativos. Extiende esta tabla unas cuantas líneas más: memoria virtual y paginación, permisos de archivos, detección de interbloqueos (deadlocks), algoritmos de planificación (scheduling), ¿a qué corresponden en el mundo de los Agentes? ¿Y qué conceptos de sistemas operativos no encuentran equivalente en el mundo de los Agentes y por qué?

Posibles extensiones: Memoria virtual/paginación ↔ Compresión de contexto y recuperación (la información caliente se queda en la ventana, la fría se pagina a archivos y memoria, recuperándose al usar); Permisos de archivos ↔ Listas blancas de herramientas, montajes de solo lectura, límites de credenciales; Detección de interbloqueos ↔ Detección de transferencias circulares y esperas mutuas (límite de transferencias, tiempos de espera); Algoritmos de planificación ↔ Procesamiento de eventos asíncronos (Capítulo 4). Las áreas sin equivalente provienen de la diferente fuerza ejecutiva: las instrucciones de un proceso son ejecutadas obligatoriamente por el hardware, mientras que el Agente solo cumple los prompts con una alta probabilidad.