Ahora es el 23 de enero de 2026, en la madrugada.
Lamentablemente, descubrí que el rendimiento del Agente en tareas de traducción no es tan bueno como la traducción directa con LLM de un solo disparo (one-shot). Parece que la ventaja del Agente reside más en tareas que requieren razonamiento y toma de decisiones en múltiples pasos, y no en tareas simples de un solo paso. El Agente utiliza 10 veces más tokens que el LLM, pero la calidad de la traducción incluso empeora, especialmente con el YAML Frontmatter, que a veces traduce con errores de formato.
Originalmente, planeaba usarlo para resolver el problema de que el LLM de un solo disparo excede el límite de longitud máxima de salida en tareas de traducción de textos largos, pero parece que no es tan simple. Por lo tanto, en la versión [email protected], revertí esta función para reconsiderarlo a largo plazo.
Creo que esto puede deberse a que los escenarios típicos del Agente suelen ser tareas complejas con una enorme cantidad de información. Por lo tanto, está diseñado para leer y escribir lo menos posible en el contexto, priorizando la lectura y escritura local de archivos para aumentar su capacidad de procesamiento de grandes volúmenes de datos. Esta estrategia de gestión del contexto hace que no incorpore toda la información por defecto, lo que le impide aprovechar plenamente la información contextual para traducir, como sí lo hace el LLM de un solo disparo.
Curiosamente, en algunas tareas de traducción de idiomas menos comunes (por ejemplo, del chino simplificado al indonesio), el Agente incluso puede ocasionalmente caer en un bucle infinito de traducción, sin poder converger a un resultado estable. Esto podría deberse a que la herramienta Edit tiene defectos al procesar ciertos idiomas, lo que le impide reemplazar el texto correctamente y lo lleva a un bucle infinito. (Ser demasiado eficiente también puede tener sus problemas).
Se me ocurren dos soluciones:
- Utilizar un marco de Agentes / Sub-Agentes para descomponer la tarea de traducción, por ejemplo, un marco de generación adversaria de traducción-revisión.
- Usar Skill para ensamblar una API de LLM de un solo disparo de bajo nivel (Low-level), permitiendo que el Agente invoque la habilidad de traducción, en lugar de que el Agente mismo traduzca.
Probablemente prefiera la primera solución, ya que su potencial parece mayor. Solo no sé qué tan bien soporta OpenCode las llamadas complejas de Agentes.
Además, el registro de cambios de CZON:
- 0.5.0: Integró OpenCode para tareas de traducción. (Sin embargo, introdujo problemas de rendimiento al traducir una gran cantidad de archivos, que se solucionaron posteriormente).
- 0.5.1: Solucionó el problema de fallo en la carga de recursos estáticos frontend (tailwindcss) debido a la inaccesibilidad de jsdelivr en redes domésticas chinas. (Se logró descargando los archivos CDN localmente durante la fase de construcción).
- 0.5.2: Cuando el slug ya existe, ya no se actualiza, evitando que los cambios en el contenido provoquen modificaciones en el slug. (Previene la invalidación de enlaces históricos debido al renombrado de archivos de registro); Revirtió la función de traducción por Agente, eliminando la integración de OpenCode para tareas de traducción.
