← Registro de trabajo 2026

Registro de trabajo

2026-01-24

Hoy dormí hasta las 11 sin preocupaciones, me siento muy aliviado. Hacía mucho tiempo que no dormía tan a gusto.

  1. ¿Qué hice hoy?

    1. Subí una nueva versión de node-unit. La razón por la que me atreví a subirla es que tengo pruebas integrales bastante detalladas. En concreto, inicié un timescaledb (PostgreSQL 17) con Docker, luego inicié dos node-unit, inserté 21 instancias de @yuants/portal en la base de datos para probar, y finalmente convergieron a un estado en que cada uno se quedó con la mitad.

      Esta prueba básicamente permite verificar que, cuando aparecen un montón de deployments sin dueño, al subir dos node-unit se puede observar cómo se turnan para ocupar los deployments. Si algo falta, por un lado está la carga de trabajo real que ocupa CPU/memoria, y por otro lado está el escenario en que un node-unit se desconecta por algún motivo.

    2. Con la nueva versión multiagente de legionmind, resolví en Yuan el problema de la salida del flujo de cuentas para la cuenta vendor-gate earn. Le pedí al agente que primero usara legion para crear documentación, y en total generó los siguientes documentos:

      .legion/tasks/vendor-gate
├── context.md
├── docs
│   ├── api-doc.md
│   ├── pr-body.md
│   ├── report-walkthrough.md
│   ├── rfc.md
│   ├── spec-bench.md
│   ├── spec-dev.md
│   ├── spec-obs.md
│   └── spec-test.md
├── plan.md
└── tasks.md

      Parece un flujo de trabajo decente. Sin embargo, mi nuevo sistema multiagente entra en conflicto con la redacción de documentos del legionmind original. Debería considerar cuidadosamente los límites de cada tarea, por ejemplo, las normas sobre cómo redactar cada tipo de documento deberían colocarse en skills separadas, y legionmind debería ser una descripción del flujo de trabajo. Cada tipo de agente debería poder cargar algunos skills pequeños para ayudarle a completar su trabajo.

      También hay algunos problemas: la primera vez que funcionó, cometió un error y envió el flujo de cuentas a =account-actions-with-credential.ts=, porque le pedí que se basara en vendor-okx para integrar la cuenta earn. Le hice esa petición porque actualmente solo la cuenta earn de okx se ha integrado como una cuenta. Pero la IA también aprendió algunas prácticas obsoletas de ahí. El estándar actual de integración de exchanges es publicar todas las cuentas mediante =provideExchangeServices=, no usando =provideAccountActionsWithCredential=.

      Este conocimiento no lo posee un nuevo agente de IA. ¿Cómo modelar este conocimiento? ¿Cómo proporcionar a un agente de IA este contexto del proyecto como su cerebro externo? Es una cuestión que vale la pena reflexionar; mañana deberé pensar con cuidado.

    3. Por la tarde cociné para recibir a los amigos de sy, ¡estaba muy cansado! Así que mañana seguiré trabajando.

  2. ¿Qué ideas tengo?

    • Como mencioné arriba, necesito considerar detalladamente cómo diseñar un cerebro externo compacto para el agente de IA. Lo más sencillo podría empezar con un conjunto de archivos AGENT.md. He intentado algo similar antes, pero el overhead de mantener estos documentos también es bastante alto; distinguir entre basura y experiencias realmente valiosas es un problema difícil. Por ahora, la memoria es como cualquier otro prompt, solo que quizás el agente tenga un bucle propio para actualizar la memoria. Lo más importante sigue siendo cómo medir los resultados del trabajo del agente de IA.

    • Respecto al punto anterior, vi un artículo que me pareció interesante. Ahora lo resumiré con mis palabras:
      Primero, la evaluación del trabajo de un agente en un solo paso se puede clasificar así:

      1. Evaluación estática con herramientas: compilador, linter, pruebas unitarias, pruebas e2e.
      2. Evaluación con modelo: usar otro LLM según un prompt definido por nosotros para juzgar.
      3. Evaluación manual: la hago yo.

      Luego, la evaluación sistémica de un agente se divide en dos tipos:

      1. Evaluación de capacidad: responde a qué puede hacer el agente, y la tasa de éxito puede ser baja. Por ejemplo, quiero que use legion para ejecutar tareas cada vez más grandes y difíciles, como explorar una nueva frontera.
      2. Evaluación de regresión: ¿mantiene las capacidades que tenía antes? Por ejemplo, repetir algunas tareas para asegurarse de que aún se realizan de forma estable.

      Cuando se introduce una nueva capacidad, se debería pasar de la evaluación de capacidad a la de regresión.

      El artículo también menciona dos métricas importantes: pass@K y pass^K:

      • pass@k: al menos un éxito en k intentos. Cuantos más intentos, mayor probabilidad de al menos un éxito. Se aplica cuando solo te importa “encontrar al menos una solución viable”.
      • passk: deben tener éxito todos los k intentos. Cuantos más intentos, más difícil mantener la consistencia. Se aplica cuando los usuarios esperan un agente productivo fiable en cada ocasión.

      FYI: Ver este artículo

    • Todavía tengo poca energía. Trabajé un rato por la tarde, cociné por la noche y me sentí algo cansado. ¿Cuándo podré no necesitar dormir como CZ?

  3. ¿Qué planeo hacer mañana?

    1. Reflexionar sobre el modelo de evaluación del agente y seguir iterando este sistema multiagente.
    2. El problema de seguridad del clúster; tengo que abordarlo.
    3. legion-github-bridge.