ai-agent-book 精选快照（<2MB 代码与文档，来自 github.com/bojieli/ai-agent-book）

book-es/reference-answers.es.md

@@ -0,0 +1,408 @@
+# 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 añadir una capacidad a un sistema de Agente (un modelo más fuerte, un contexto más rico o más herramientas), ¿cuál elegirías? ¿En 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 un bucle ReAct, el volumen acumulado de lecturas de caché crece aproximadamente de forma cuadrática con el número de rondas. ¿Cómo puede reducirse este crecimiento?**
+
+> En la ronda i, la longitud del prefijo en caché es aproximadamente proporcional a i, por lo que las lecturas acumuladas son 1 + 2 + ... + n = O(n²). El crecimiento cuadrático corresponde al costo acumulado de lectura de caché, no a la longitud de la trayectoria ni al espacio ocupado por la KV Cache, que crecen aproximadamente de forma lineal. Al alcanzar un umbral de tokens, se puede comprimir por lotes la trayectoria inicial y conservar solo las conclusiones y el estado clave; también se pueden externalizar los resultados intermedios grandes para recuperarlos bajo demanda o aislarlos en subagentes. No conviene comprimir en cada ronda: puede perjudicar el rendimiento del Agente y añade llamadas de compresión y costos de reconstrucción de caché.
+
+**3. (★★) El paradigma "El Modelo como Agente" significa que los modelos son cada vez más autónomos en sus decisiones de llamadas a herramientas. Sin embargo, este capítulo sostiene que la importancia de la ingeniería de Harness está aumentando. ¿Cómo pueden coexistir estas dos tendencias?**
+
+> 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 ausencia de "retroalimentación de resultados de herramientas" hizo que el Agente cayera en un bucle infinito. En un entorno de producción, ¿qué otras situaciones podrían causar que un Agente entre en un bucle? ¿Qué mecanismos de detección y terminació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 analizó cinco productos de Agentes en tres dimensiones: contexto de trabajo, interfaces de acción y estrategia. Elige un producto de IA que uses a diario, analízalo en esas tres dimensiones y juzga si su arquitectura es adecuada.**
+
+> 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 fueras a diseñar un sistema de atención al cliente específicamente para reservar vuelos, ¿elegirías un patrón de workflow o un patrón de Agente autónomo? ¿Es posible mezclar ambos patrones 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 guardarraíles mencionó las clasificaciones de riesgo de las herramientas. Si una herramienta es generalmente de bajo riesgo pero se vuelve de alto riesgo con combinaciones específicas de parámetros (ej. `delete_file` borrando un archivo normal vs. un archivo de 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, todos los Agentes tienen un espacio de acción "abierto". ¿En qué escenarios sería superior un espacio de acción restringido (ej. solo poder elegir entre opciones predefinidas)?**
+
+> 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 "transfiera el control de forma elegante". Sin embargo, en la práctica, el usuario podría estar desconectado, responder lentamente o dar instrucciones vagas. ¿Qué debería hacer el Agente en tales casos?**
+
+> *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 identificó que utilizar una ventana deslizante en el historial de conversación puede provocar que el Agente ejecute repetidamente las mismas llamadas a herramientas. Sin embargo, conservar el historial completo provoca que el contexto se expanda continuamente. Diseña una estrategia que evite la pérdida de información crucial, controle la longitud del contexto y no invalide el prefijo de la 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 Chat Template de Qwen3 conserva el pensamiento de Cadena de Pensamiento (CoT) solo para la sección posterior al "último mensaje real del usuario". Si un bucle ReAct abarca más de cien rondas de llamadas a herramientas, el pensamiento acumulado puede consumir un volumen considerable de contexto. ¿Cómo modificarías este mecanismo para manejar bucles extremadamente largos? DeepSeek R1 requería eliminar todo el historial de pensamiento anterior, mientras que DeepSeek V4 pasó a exigir el reenvío obligatorio de todo el `reasoning_content`: compara ambas estrategias opuestas, analiza sus ventajas e inconvenientes y explica 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, al comprimir desde aproximadamente 148.000 caracteres hasta cerca de 2.000 caracteres, ¿existe el riesgo de una "pérdida irreversible de información"? ¿Cómo se puede mitigar?**
+
+> 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 transforma estados implícitos en conocimiento explícito. No obstante, si la propia barra de estado contiene información errónea (por ejemplo, un bug en el contador de herramientas), el Agente podría tomar decisiones perjudiciales basándose en datos incorrectos. ¿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 en ingeniería de prompts demostraron que una organización caótica 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 suelen ser mantenidos por múltiples personas en diferentes momentos. ¿Qué prácticas de ingeniería aplicarías para prevenir 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 sostiene que "el aprendizaje en contexto es esencialmente recuperación y no razonamiento". Si esta afirmación es correcta, todas las líneas de optimización basadas únicamente en "introducir más información en el contexto" deben ser reevaluadas. ¿Cómo propones 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 en Skills solo carga el contenido completo cuando el Agente evalúa que lo necesita. Sin embargo, esta evaluación depende de la propia capacidad del modelo: si el modelo no sabe lo que desconoce, no podrá activar correctamente la carga de la 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, tras leer dinámicamente las instrucciones desde un archivo `SKILL`, ¿puede el Agente seguir adecuadamente esas instrucciones en las operaciones posteriores? ¿Qué diferencias existen entre distintos modelos en cuanto al soporte del patrón de Skills?**
+
+> 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 las variaciones en la información dinámica (como marcas de tiempo del sistema o el orden de listas de herramientas) invalidan la coincidencia del prefijo en la KV Cache. En un sistema de producción con un catálogo extenso de herramientas con cambios frecuentes, ¿cómo diseñarías la disposición del contexto para maximizar la tasa de coincidencia de la 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 del usuario, cuando un mismo usuario proporciona información contradictoria en diferentes sesiones (por ejemplo, menciona dos direcciones de residencia distintas), ¿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 bloque. Sin embargo, si el documento original es desorganizado o contiene información contradictoria, este método puede propagar o amplificar los errores. ¿Cómo introducirías señales de "calidad de la información" en la fase de búsqueda?**
+
+> 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. (★★) La extracción de información multimodal convierte los gráficos en descripciones de texto antes de buscar. Este proceso de "traducción" puede perder relaciones espaciales presentes en la información visual. Proporciona un ejemplo concreto donde la descripción en texto plano no logre transmitir la información del gráfico y diseña una solución para preservar 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.
+
+**4. (★★★) La "Lección Amarga" de Rich Sutton sostiene que los métodos generales (búsqueda y aprendizaje) terminarán superando a las características diseñadas manualmente. ¿Son los sistemas de conocimiento construidos en este capítulo (estrategias de fragmentación, estructuras de índices, canalizaciones de búsqueda) una forma de "diseño manual"? Si la capacidad de los modelos fuera suficiente, ¿podrían estas estructuras ser reemplazadas por una simple "entrada masiva"?**
+
+> 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.
+
+**5. (★★★) Con la mejora de las capacidades de los modelos, ¿seguirán siendo importantes las bases de conocimiento de dominio? En el futuro, ¿es posible que los modelos base incluyan toda la información de las bases de dominio, haciendo innecesarias las bases de conocimiento externas?**
+
+> 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".
+
+**6. (★) RAPTOR construye índices en árbol mediante resúmenes jerárquicos ascendentes, mientras que GraphRAG construye índices en grafo mediante relaciones entre entidades. ¿En qué tipo de consultas destaca cada uno de estos índices estructurados?**
+
+> 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.
+
+**7. (★★) El paradigma del sistema de archivos organiza el conocimiento en estructuras jerárquicas similares a directorios de archivos. ¿En qué escenarios ofrece ventajas este enfoque frente a las bases de datos vectoriales RAG tradicionales?**
+
+> 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.
+
+**8. (★★★) Descubrir automáticamente "factores de sentencia" y "jerarquías de importancia de factores" a partir de datos estructurados (como bases de datos de sentencias judiciales) consiste en hacer 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 redactadas manualmente 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.
+
+**9. (★★★) Diseña los flujos de actualización incremental y reorganización periódica para una biblioteca de memoria de usuario en Markdown. Si Reviewer y Proposer usan el mismo modelo y solo pueden ver los fragmentos de conversación elegidos por Proposer, ¿qué errores podrían incorporarse todavía? Explica las mejoras en términos de independencia de los modelos, cobertura de las pruebas y permisos de herramientas.**
+
+> Actualización incremental: trata la biblioteca de memoria como un repositorio de código y haz pasar cada cambio por un PR. El Proposer busca primero el conocimiento existente relacionado y luego propone el diff más pequeño y completo posible, manteniendo a la vez enlaces, índices, metadatos temporales y referencias de evidencia; el Reviewer audita de forma independiente con el conocimiento previo al cambio, el diff y la evidencia original, y al rechazar devuelve comentarios accionables que apuntan a evidencia y números de línea concretos; la iteración tiene un número máximo o un presupuesto de coste, y superarlo escala a una persona en lugar de aprobar por defecto. Tras la fusión, CI comprueba primero formato, enlaces, metadatos y etiquetas de permisos, y solo después reconstruye de forma incremental los fragmentos e índices vectoriales afectados a partir de la versión fusionada. Consolidación periódica: dispara un escaneo completo por tiempo o por número de entradas nuevas, deduplica, fusiona, divide archivos demasiado grandes y reconstruye las páginas de entrada; lo esencial es volver a las conversaciones originales párrafo a párrafo para comprobar si los resúmenes antiguos perdieron una negación, una condición temporal o un matiz. Las contradicciones no se resuelven con «conservar lo más reciente», sino rastreando cada afirmación hasta su fuente y escribiendo bajo qué condiciones vale cada una; si la evidencia no basta, conserva el conflicto y márcalo como pendiente. La reorganización también se envía como PR, si conviene dividido por directorios, y cuando todos pasan se reconstruye el índice y se reproducen casos típicos de recuperación para confirmar que el conocimiento que antes se encontraba no ha quedado invisible.
+>
+> El mismo modelo con fragmentos preseleccionados dejará escapar tres clases de error. **Independencia del modelo**: modelos de la misma familia comparten sesgos previos y puntos ciegos, así que el Reviewer tiende a repetir la conclusión del Proposer en vez de volver a la evidencia, y una mala lectura compartida no se detecta; usa modelos de capacidad similar pero de otra familia para la revisión cruzada. **Cobertura de evidencia**: con solo los fragmentos elegidos por el Proposer, la cita fuera de contexto, las negaciones y condiciones previas descartadas y los conflictos con otros archivos quedan invisibles; el Reviewer debe poder consultar por su cuenta la base de conocimiento completa y el almacén de evidencia original, dentro del alcance de inquilino o usuario que tenga autorizado. **Permisos de herramientas**: si el Proposer puede escribir en la rama principal o tocar el índice en producción, la revisión es papel mojado; impón la separación: el Proposer solo escribe en una rama de trabajo, el Reviewer solo lee evidencia y emite su veredicto, solo la canalización de fusión actualiza la rama principal y el índice en producción, y los verificadores y las puertas de publicación quedan fuera del alcance modificable.
+
+## Capítulo 4 Herramientas
+
+**1. (★★) El estándar MCP desacopla la definición de herramientas de los frameworks de Agentes. Sin embargo, la estandarización implica también que patrones de interacción complejos (como salidas en streaming, comunicaciones bidireccionales o sesiones con estado) resulten difíciles de expresar en un protocolo estándar. ¿Cuál considera que es la capacidad más urgente que MCP 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 el ecosistema MCP, distintos servidores MCP pueden proporcionar herramientas con funciones altamente superpuestas. Cuando un Agente enfrenta múltiples herramientas de orígenes distintos pero con funciones similares, ¿cómo debe elegir? Si herramientas con el mismo nombre procedentes de distintos orígenes muestran ligeras diferencias de comportamiento (por ejemplo, una devuelve un resumen y otra el texto completo), ¿posee el Agente la capacidad de percibir y aprovechar dicha 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.
+
+**3. (★★) Este capítulo presenta el bucle de "ejecución-validación-retroalimentación" (como ejecutar automáticamente un linter tras escribir código). ¿En qué otros escenarios de herramientas se puede aplicar este patrón de "validación automática inmediata tras la operación"? ¿Existen operaciones donde el costo o riesgo de la propia validación supere 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.
+
+**4. (★★) Este capítulo plantea el problema de la "explosión de herramientas": la precisión de selección del Agente se degrada ante miles de herramientas. Además del descubrimiento proactivo de herramientas, ¿qué otros esquemas existen? Se pueden tomar como referencia las estrategias de expertos humanos al enfrentarse a 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 en sandbox resuelve parte de los problemas, pero también limita las capacidades del código (como el acceso a la red o al sistema de archivos). ¿Cómo encontrar el punto de equilibrio óptimo entre la seguridad y las capacidades?**
+
+> 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 autoinicio del Agente (Agentes capaces de crear Agentes) logra la "autorreproducción de la inteligencia". Sin embargo, cada autoinicio puede introducir nuevos sesgos o errores. ¿Se acumularán estos errores entre generaciones? ¿Cómo prevenir la degradación en el autoinicio de los 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. (★★) Al procesar el parseo de registros, el Agente de generación de código puede seguir automáticamente la evolución de los formatos. Sin embargo, si el cambio de formato se debe a un error y no a una modificación prevista, la adaptabilidad del Agente podría terminar ocultando el problema. ¿Cómo debería diferenciar el Agente entre "un cambio que requiere adaptación" y "una anomalía que debe reportarse"?**
+
+> 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 utilizó 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 Reviewer no coinciden con las del usuario final (por ejemplo, si el Reviewer considera que la densidad de información es adecuada pero el usuario la percibe demasiado apretada), el bucle de retroalimentación convergerá a un óptimo local incorrecto. ¿Cómo integrar la retroalimentación de preferencias del usuario en el bucle del Reviewer?**
+
+> 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 mostró múltiples formas en que el Coding Agent deposita en el repositorio de código la experiencia obtenida durante la ejecución y depuración: escribiendo archivos en la base de conocimiento, actualizando documentos de arquitectura, manteniendo archivos de instrucciones del proyecto y consolidando secuencias de operaciones como código. Si esta experiencia se sintetiza aún más en reglas dentro de los prompts del sistema, el conjunto de reglas se expandirá continuamente con el tiempo. ¿Cómo realizar la "recolección de basura" sobre las reglas acumuladas para identificar y limpiar elementos redundantes u obsoletos? ¿Por qué una modificación exitosa de código aún no puede considerarse directamente como la evolución continua discutida en el Capítulo 9?**
+
+> 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 suelen ser también amigables con los Agentes de IA." ¿Qué tan alejado está el equipo u organización en el que trabajas de estar "preparado para IA (AI-ready)" en cuanto a documentación del 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 y capacidad de comunicación externa), a la cual este capítulo añadió un cuarto elemento: la memoria persistente. En un entorno de producción que deba gestionar 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 modo Artifact permite que el Agente genere código SQL o de visualización para ser ejecutado directamente por el frontend, omitiendo el procesamiento de grandes volúmenes de datos por parte del LLM. Comparado con el modo tradicional donde el "Agente entrega directamente la respuesta", ¿cuáles son las ventajas y desventajas de este modo de división del trabajo de "el Agente genera el código y el sistema lo ejecuta"? Además, el SQL generado podría ejecutar operaciones destructivas y el HTML generado podría contener vulnerabilidades. ¿Cómo garantizar la seguridad del sistema?**
+
+> Ventajas y desventajas: 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.
+>
+> Seguridad: 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 validaciones internas en las herramientas basadas en los datos reales de la base de datos, y guiar al modelo a verificar las políticas antes de llamar mediante el diseño de parámetros, equivale esencialmente a restringir el comportamiento del Agente con la estructura del código. ¿Qué ventajas y limitaciones presenta este modo de "código como reglas" en comparación con las reglas en 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.
+## Interacción: la expansión de los espacios de observación y de acción
+
+**1. (★★) En una arquitectura de Agentes asíncrona, la estrategia de prioridad de la cola de eventos debe determinarse durante el diseño. Sin embargo, si el propio juicio de prioridad requiere comprensión semántica (por ejemplo, juzgar si un nuevo mensaje es más urgente que la tarea actual), ¿quién debe realizar este juicio: un motor de reglas o una llamada a otro LLM? ¿Cuáles son los costos de cada opción?**
+
+> 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.
+
+**2. (★★) En el procesamiento de eventos en cola, el modelo tiende a prestar atención únicamente al último evento, problema que este capítulo mitiga mediante marcas en la barra de estado del Agente y resúmenes. Sin embargo, si en la cola se acumulan 20 eventos (10 resultados de herramientas + 5 mensajes de usuario + 5 recordatorios del sistema), ¿cómo organizaría el orden y formato de presentación 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).
+
+**3. (★★★) Al interactuar con el mundo exterior en nombre del usuario, el Agente enfrenta esencialmente una elección de identidad: ¿utilizar una identidad virtual independiente (correo y teléfono dedicados) para actuar como un tercero, o gestionar directamente las cuentas reales del propio usuario para operar? Lo primero permite operaciones autónomas en segundo plano, pero los terceros podrían 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 considera que se debe elegir 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.
+
+**4. (★★) El modelo de extremo a extremo de los Agentes de voz combina ASR-LLM-TTS en un solo modelo, lo que reduce la latencia pero pierde modularidad. Si el modelo de extremo a extremo comete un error en alguna etapa (como el reconocimiento de voz), la depuración y reparación es mucho más difícil que en un pipeline serial. ¿Cómo diseñarías el sistema de observabilidad (observability) para un Agente 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.
+
+**5. (★) Step-Audio R1 logra "pensar mientras se habla" mediante la arquitectura de doble cerebro MPS. Sin embargo, los seres humanos a menudo dicen palabras sin pensar profundamente, se autorcorrigen o utilizan muletillas al "pensar mientras hablan". ¿Debería el "pensar mientras se habla" de un 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.
+
+**6. (★★) SoM (Set-of-Mark) y sus variantes estructuradas (índice de elementos DOM) convierten el grounding visual de Computer Use de una predicción de coordenadas abierta a una selección de ID cerrada, pero ambos requieren detectar y etiquetar previamente los elementos de la interfaz, ya sea mediante modelos de segmentación o mediante el DOM. Si la interfaz contiene controles no estándar o elementos dinámicos, la anotación puede ser incompleta o inexacta. 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.
+
+**7. (★★) Plataformas robóticas del orden de mil 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 en gran medida de la habilidad del operador. ¿Cómo afectará el entrenamiento del modelo VLA los datos proporcionados por un operador no experimentado? ¿Cómo filtrar automáticamente datos de baja calidad durante la etapa de recopilación?**
+
+> 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 8: los datos son más cruciales que la arquitectura.
+
+**8. (★★★) Este capítulo abarca tres formas de interacción: voz, Computer Use y robótica. La tendencia común de estas tres formas es evolucionar de pipelines seriales 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.
+
+**9. (★★) El índice de elementos DOM/Accessibility Tree produce efectos notables en aplicaciones Web estándar, pero cada vez más interfaces de software (renderizado en Canvas/WebGL, controles autodibujados multiplataforma) no proporcionan información estructurada accesible, teniendo que depender únicamente de la anotación visual o la predicción de coordenadas. ¿Crees que Computer Use debería apostar por una ruta puramente visual, o mantener simultáneamente dos vías, estructurada y visual? ¿Cuáles son los costos y beneficios de mantener ambas vías?**
+
+> 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.
+
+**10. (★★) Los modelos VLA adoptan la fragmentación de acciones (action chunking); como se menciona en el texto principal, la configuración típica de π₀ es generar de una vez entre 25 y 50 acciones futuras a una frecuencia de 50 Hz, ocultando la latencia de inferencia en el tiempo de ejecución. Sin embargo, si el entorno cambia repentinamente durante la ejecución (por ejemplo, si se retira un objeto), la secuencia de acciones pregenerada quedará invalidada. ¿Cómo equilibrar la ventaja de eficiencia de la fragmentación de acciones con la velocidad de respuesta ante cambios en el entorno?**
+
+> 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.
+
+**11. (★★★) Los tres escenarios de este capítulo (voz, Computer Use y robótica) enfrentan el problema de latencia en el bucle "Percepción-Pensamiento-Acción", evolucionando todos hacia la paralelización del pensamiento rápido y lento. En el escenario de voz, esto se manifiesta como "corregir tras hablar mal"; en el escenario de Computer Use, se manifiesta como "hacer clic primero y mirar después"; en el escenario robótico, se manifiesta como "dar un paso y observar". ¿Cómo garantizar que estas acciones basadas en el pensamiento rápido no causen consecuencias irreversibles?**
+
+> 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.
+
+**12. (★★★) En este capítulo reaparece el mismo conjunto de primitivas (despertar, punto seguro, cancelación, desalojo, separación rápido/lento) implementado en escalas temporales distintas. Elija una y explique en qué difiere su implementación entre el procesamiento orientado a eventos (segundos a días) y la acción por bloques robótica (milisegundos). ¿Qué determina principalmente esa diferencia: la velocidad de cambio del entorno, la reversibilidad de la acción o el coste de obtener una observación?**
+
+> Tomemos la **cancelación**. En el procesamiento orientado a eventos ocurre en un punto seguro entre dos llamadas a herramientas: al recibir `terminate`, el Agente libera recursos, devuelve una confirmación y sale; una latencia de segundos es aceptable, porque una sola llamada a herramienta ya tarda de segundos a minutos. En la acción por bloques, la cancelación debe surtir efecto en milisegundos: en cuanto el hilo de control detecta un evento de seguridad o un cambio notable en la observación, debe detener el movimiento actual, descartar el bloque restante y volver a observar; un paso tarde y puede chocar con un obstáculo.
+>
+> De los tres factores candidatos, **el coste de obtener una observación** es en realidad el menos decisivo: ambos lados pueden volver a observar barato. Lo que de verdad marca la diferencia es la combinación de los otros dos: **la velocidad de cambio del entorno** determina cuán densos deben ser los puntos seguros (basta entre llamadas a herramientas frente a uno por ciclo de control), y **la reversibilidad de la acción** determina el coste de perderse uno (un correo de más se compensa con una disculpa; una taza volcada no se deshace).
+>
+> De ahí se destila una regla de diseño: la densidad de los puntos seguros debe ajustarse a la velocidad de cambio del entorno; y cuánta protección adicional hace falta más allá de ellos (parada de emergencia por hardware, controlador de seguridad independiente, confirmación secundaria) depende de cuán irreversible sea la acción. Eso explica también por qué las operaciones de alto riesgo del capítulo 4 exigen aprobación previa y los robots necesitan una capa de seguridad en hardware independiente del modelo: ambas son la segunda línea de defensa allí donde los puntos seguros no bastan.
+
+## Capítulo 7 Evaluación de Agentes
+
+**1. (★★) LLM-as-a-Judge utiliza un modelo de lenguaje para evaluar la salida de otro. ¿Presenta esta "autoevaluación" puntos ciegos sistemáticos (por ejemplo, que el modelo otorgue sistemáticamente puntuaciones altas a respuestas con cierto estilo, discrepando dicha preferencia del juicio humano)? ¿Cómo detectar y corregir esta desviación?**
+
+> 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 de "prevención de fugas" en los datasets de evaluación resulta crucial. Sin embargo, en el ecosistema de código abierto, una vez publicado un benchmark, sus datos son incorporados rápidamente a los datos de entrenamiento. ¿Tiene fin este juego del gato y el ratón? Diseña un método de evaluación que sea fundamentalmente resistente a la fuga 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 principios de Scale AI (orientación de expertos, cobertura completa, ponderación estandarizada, evaluación autocontenida) buscan eliminar la subjetividad. Sin embargo, ciertas dimensiones de las tareas (como "si la respuesta es de ayuda" o "si el tono es apropiado") son inherentemente subjetivas. ¿Cómo diseñar Rúbricas confiables 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 Agentes simulando comportamientos de usuarios reales. Sin embargo, el usuario simulado es también un LLM que puede subestimar sistemáticamente ciertos escenarios límite (como usuarios alterados 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 los rankings?**
+
+> 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 distingue Pass@k, que mide el techo de capacidad, de Pass consecutive@k, que mide la fiabilidad de negocio. Para un Agente cuya tasa de éxito en una sola ejecución es de solo el 60 %, ¿cómo combinarías el coste del fallo, el coste del reintento y los efectos secundarios de la tarea para decidir qué métrica informar y qué valor de $k$ tomar?**
+
+> Empieza por si el fallo se puede revertir. Cuando los fallos se pueden reintentar automáticamente y no dejan efectos secundarios externos (recuperación, generación de borradores, autocompletado de código), lo que importa es «si se consigue dando suficientes oportunidades», así que informa Pass@k con k igual al presupuesto de reintentos realmente permitido. Cuando el fallo deja consecuencias irreversibles (pagos, reembolsos, correo saliente, despliegue a producción), un solo error ya es una pérdida real, así que informa Pass^k. Con una tasa de éxito por ejecución de 0,6, Pass@5 ≈ 99,0 % mientras que Pass^5 ≈ 7,8 %: dos cifras separadas por un orden de magnitud para el mismo Agente, de modo que informar solo la primera sobrestima gravemente la fiabilidad.
+>
+> Que k venga de la realidad del despliegue y no del número que mejor luce: para Pass@k toma el presupuesto de reintentos; para Pass^k, cuántas tareas se ejecutan seguidas en un turno o en un lote. Si reintentar es caro, acepta en dos fases: criba con Pass@1 y luego ejecuta Pass^k sobre los pocos candidatos que queden. Sea cual sea la métrica, indica k y el protocolo de muestreo; en operaciones con efectos secundarios, muestrea en un sandbox o en un entorno reversible y contabiliza cada fallo en la estadística de fiabilidad en lugar de «reintentar hasta que salga».
+
+**7. (★★) Este capítulo propone el método científico de "Observar → Hipotetizar → Experimentar → Validar". Sin embargo, en la práctica, el espacio de comportamientos 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 obtenida de la evaluación bajo un presupuesto computacional 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.
+
+**8. (★) 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.
+
+**9. (★★) La simulación de usuarios en τ-bench adopta la "divulgación progresiva de información", proporcionando datos gradualmente según las preguntas del Agente en lugar de entregarlos todos de una vez. ¿Cómo influye este diseño en los resultados de 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 8 Posentrenamiento de Modelos
+
+**1. (★★) El olvido catastrófico (donde un ajuste fino para una tarea específica degrada capacidades generales previas como la llamada a herramientas) resulta crítico en Agentes. Frente al ajuste completo, LoRA congela los pesos base reduciendo el riesgo, aunque sin ser inmune. ¿Qué estrategias adicionales permiten mitigar el olvido de capacidades durante 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 post-entrenamiento consolida capacidades en los pesos del modelo ("memoria muscular"), mientras que el aprendizaje en contexto coloca el conocimiento en la entrada durante la inferencia. Sin embargo, algunas capacidades (como el conocimiento de dominio) pueden aprenderse por post-entrenamiento o suministrarse mediante ejemplos few-shot. ¿Qué criterios utilizarías para decidir qué ruta debe seguir una capacidad específica?**
+
+> 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 del comportamiento de uno grande. Según su nivel de capacidad, los modelos a destilar se dividen en tres categorías: **Modelos de Chat** (diálogo de un solo turno, respuesta directa), **Modelos de Razonamiento** (cadena de pensamiento larga previa a responder) y **Modelos de Agentes** (llamada a herramientas multiturno, interacción con el entorno). ¿Qué diferencias de dificultad presentan la destilación de cada una de estas tres categorías? (Sugerencia: Analiza qué se está destilando en cada caso: si el estilo de salida, la trayectoria completa de pensamiento o la estrategia de decisión en interacción con el entorno; qué tokens de la trayectoria deben aprenderse y cuáles son retornos del entorno que no deben aprenderse; y cuán diferida y esporádica es la señal de éxito o fracaso).**
+
+> 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 multiturno de Agentes, la asignación de crédito es más compleja que en un solo turno: resulta difícil atribuir un éxito o fracaso final a la decisión del turno 3 o del turno 7. ¿Cómo diseñarías una estrategia de asignación de recompensa?**
+
+> 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. (★★★) Ante un presupuesto fijo (por ejemplo, 10.000 USD) para elevar el rendimiento de un Agente de atención al cliente, ¿cómo distribuirías el presupuesto entre contexto y conocimiento, Prompt/Skills, restricciones por programa y entrenamiento de parámetros? ¿De qué factores dependería 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 explícitas y con pocas muestras es considerado por algunos el objetivo final del post-entrenamiento. ¿A qué distancia se hallan los métodos de RL actuales de dicha meta? ¿De qué dirección consideras más probable 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 es moderado. ¿Sería viable entrenar un LoRA dedicado para cada usuario (o 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 "escribir la memoria en parámetros" supera a "almacenarla en bases de conocimiento"? ¿En qué escenarios resulta 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 en la Política depende de un profesor más fuerte para supervisar al estudiante. Sin embargo, la investigación de Generalización Weak-to-Strong de OpenAI reveló un hallazgo contraintuitivo: la señal de supervisión de un modelo débil puede activar capacidades latentes no expresadas en un modelo fuerte. Si se aplica esta idea al entrenamiento de Agentes, ¿sería factible lograr una destilación inversa donde "un modelo pequeño enseñe a uno 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 del pensamiento, y el Modelo de Recompensa de Resultado (ORM) evalúa solo el resultado final. Entre "un proceso correcto que conduce a un resultado erróneo" y "un proceso erróneo que llega por azar a un resultado correcto", ¿cuál merece mayor recompensa? En escenarios de llamadas a herramientas de múltiples pasos en Agentes, ¿cómo equilibrarías ambos aspectos?**
+
+> 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 abordados en este capítulo (SWE-Bench Verified, $\tau²$-bench, AndroidWorld) pueden emplearse tanto para evaluar como para realizar post-entrenamiento. Sin embargo, al usar un conjunto de evaluación para entrenar, este deja de ser independiente, violando el principio de separación entre datos de entrenamiento y prueba. La generación dinámica de parámetros en $\tau²$-bench y las plantillas parametrizadas de AndroidWorld mitigan parcialmente este problema, aunque la estructura de la plantilla permanece fija. ¿Cómo equilibrar el aprovechamiento del valor de entrenamiento de los datos de evaluación con la preservación de la independencia en 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 "primero la forma, luego el espíritu": aplicar SFT hasta lograr "estabilidad de formato y capacidad inicial" para luego migrar a RL. En la práctica, ¿cómo determinar que el SFT ha sido "suficiente" para realizar dicha transición?**
+
+> 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 (Experimento 7-15) muestra que unas pocas respuestas extremadamente largas prolongan sustancialmente el ciclo global de entrenamiento: la gran mayoría de las rollouts finalizan pero deben esperar a las más largas, reduciendo la utilización de GPU en el clúster. ¿Cómo mejorar la utilización de recursos en clústeres de entrenamiento ante este escenario 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 entrenar Agentes con LLM que simulan el entorno (como motores de búsqueda o usuarios simulados), el objeto de reward hacking del Agente pasa de ser "las reglas del entorno real" a ser "los sesgos y vulnerabilidades del propio simulador". ¿Qué comportamientos concretos de reward hacking pueden emerger 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 9 Evolución Continua del Agente
+
+**1. (★★) Un documento de conocimiento de experiencia cuenta con el respaldo de tres trayectorias exitosas y una fallida. La falla ocurrió en una versión de API más reciente. ¿Cómo debe determinar el sistema si la experiencia fue refutada o si cambiaron sus 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 de un Agente de atención al cliente aumentó, pero también se incrementó la tasa de infracción de reglas. ¿Por qué no se puede tomar la satisfacción como única señal de aprendizaje? ¿Cómo diseñaría los indicadores de salvaguarda (guardrails)?**
+
+> 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. (★★★) Un mismo problema de "falsa promesa" se puede mitigar mediante Prompts, verificaciones en el Harness o entrenamiento de parámetros. ¿En qué evidencias se basaría 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. (★★★) Un Agente puede modificar herramientas y verificadores, pero no debe modificar la raíz de confianza que aprueba sus propias actualizaciones. ¿Cómo dividiría los permisos y las fronteras de código entre ambas 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. (★★) A medida que la base de conocimientos de experiencia crece continuamente, los errores de recuperación y los conflictos de conocimiento anulan las ganancias del aprendizaje. ¿Cómo diseñar mecanismos de versión, vigencia y retiro?**
+
+> 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 estilos de lenguaje natural, pero le cuesta garantizar reglas de negocio rígidas. Diseñe un esquema de evolución continua para atención médica que coordine la colaboración entre parámetros, conocimientos, Skills y restricciones de código.**
+
+> 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 10 Colaboración Multi-Agente
+
+**1. (★★) En la colaboración con contexto compartido, ¿cómo se puede detectar y eliminar la interferencia del sesgo de encuadre (*framing bias*) 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 patrón de manager, ¿cómo se puede garantizar que el Manager genere una descomposición de tareas adecuada y precisa?**
+
+> 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. (★★) ¿Qué "patologías organizacionales" humanas son más probables en una sociedad de Agentes y cómo pueden prevenirse?**
+
+> 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 patrón de manager, cuando múltiples sub-agentes se ejecutan en paralelo, el hallazgo de un sub-agente puede hacer que el trabajo de los demás carezca de sentido (por ejemplo, cuando en una búsqueda un Agente ya encuentra la respuesta). Diseñe un mecanismo eficiente de terminación en cascada para lograr que "al tener éxito uno, se detengan todos".**
+
+> 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 presentado en este capítulo resuelve los conflictos de escritura concurrente en un solo archivo; sin embargo, en los sistemas multi-agente reales, el sistema de archivos compartido enfrenta también conflictos semánticos entre archivos, contaminación del espacio de nombres (Agentes creando archivos libremente desordenando directorios) y puntos únicos de fallo (un Agente borrando por error todos los archivos). ¿Cómo diseñaría un mecanismo de gobernanza 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 entre Agentes basada en mecanismos de mercado (Pinchwork, RentAHuman) introduce relaciones comerciales: un Agente paga para contratar a otro Agente (o a un humano) para completar una tarea. En este contexto, ¿cómo puede el Agente empleador medir automáticamente la calidad del resultado entregado? Si el ejecutor afirma haber terminado pero el empleador considera que la calidad es insuficiente, ¿quién arbitra la disputa? ¿Cómo se evita que la mala moneda desplace 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 a los Agentes contratar humanos mediante criptomonedas, invirtiendo la relación tradicional entre humanos y máquinas. Si este modelo se generaliza, ¿qué papel desempeñarán los humanos en la economía de Agentes? ¿Se limitarán únicamente a ejecutar las 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 la colaboración entre varias personas porque las capacidades individuales son limitadas (quien hace frontend no necesariamente entiende backend, y quien sabe de diseño no necesariamente maneja operaciones). Sin embargo, los grandes modelos de lenguaje se asemejan más a un "todoterreno". Investigaciones afirman que en tareas de razonamiento puramente textual, el debate multi-agente no supera a un solo Agente a igualdad de cómputo. ¿Dónde reside entonces la verdadera ventaja de utilizar múltiples Agentes en lugar de uno solo?**
+
+> 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 establece el "contexto compartido" y el "contexto no compartido" como las dimensiones de diseño centrales de los sistemas multi-agente. El contexto compartido permite que todos los Agentes vean la misma información, lo cual parece favorecer la coordinación. Sin embargo, en *El problema de los tres cuerpos*, el pensamiento de los trisolarianos es completamente transparente pero su desarrollo tecnológico se estancó; el experimento mental del sujetapapeles muestra asimismo que cuando el grupo converge hacia un único objetivo, se pierde la diversidad. En los sistemas multi-agente, ¿cómo se puede equilibrar la eficiencia y la 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 a un Coding Agent un presupuesto de 30 pasos frente a uno de 300 pasos, ¿cómo debería cambiar su estrategia de trabajo? Las investigaciones demuestran que el simple aumento del presupuesto de pasos no garantiza una mejora en el rendimiento, ya que el Agente se "satura" prematuramente tras búsquedas superficiales. Diseñe un mecanismo "consciente del presupuesto" (*budget-aware*) que permita al Agente implementar funciones centrales rápidamente bajo presupuestos pequeños y añadir etapas de planificación, pruebas y revisión bajo presupuestos grandes 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. (★★) La Tabla 10-3 establece una correspondencia línea por línea entre los sistemas multi-agente y los sistemas operativos. Extienda esta tabla algunas líneas más: ¿a qué corresponden la memoria virtual y la paginación, los permisos de archivos, la detección de bloqueos mutuos (*deadlocks*) y los algoritmos de programación en el mundo de los Agentes? ¿Qué conceptos de los sistemas operativos no encuentran correspondencia 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.