|
❞
Cuando se pedía únicamente añadir código a un evento — sin crear ni modificar ningún control — el trabajo se planificaba como una sola tarea del agente de eventos COBOL, sin tarea de diseño de formulario. Esa rama estaba desconectada del formulario por cuatro sitios a la vez.
El agente recibía la orden de devolver su trabajo "dentro del array de operaciones", pero nunca veía el contrato que define ese bloque JSON, así que lo describía en prosa. Y aunque lo hubiera emitido bien, los tres puntos que recogen, recuperan y aplican los cambios sólo reconocían al Diseñador de Formularios.
El resultado era el peor posible: el flujo terminaba, el revisor aprobaba el manejador por sus propios méritos, y el formulario quedaba intacto sin que nada lo advirtiera.
Corregido, junto con:
- Una petición que añade un control Y programa su evento son dos tareas; antes sólo se aplicaba la primera. Ahora se combinan las operaciones de todas las tareas aprobadas.
- Una tarea aprobada que no produce ninguna operación ahora dice que el formulario no ha cambiado, en lugar de informar de un éxito sin más.
- El agente de eventos no veía la lista de eventos a los que se le pedía enlazar. Un nombre de evento incorrecto se rechaza al entrar y luego se descarta en silencio: el mismo síntoma, sin ningún aviso. Ahora la lista viaja con la tarea, recortada a los tipos en juego, igual que los procedimientos que puede llamar por nombre.
Además, el contexto de Grace llevaba las propiedades y los eventos de los 34 tipos de control en cada petición: medido sobre un formulario con un solo control, 32.758 de 34.843 caracteres, idénticos en todos los proyectos, mientras que el formulario que se estaba editando ocupaba unos mil. Ahora sólo recibe los tipos en juego.
BASE DE CONOCIMIENTO (trabajo de base, todavía sin uso)
Se ha añadido la infraestructura para que los agentes consulten lo que necesitan en lugar de recibirlo todo: un almacén vectorial (embedvec, cuantización E8, similitud coseno, persistencia Fjall) y un generador de embeddings semánticos en Rust puro sobre Candle (all-MiniLM-L6-v2). El índice del IDE vive fuera de los proyectos, en ~/PowerRustCOBOL/data, y el de cada proyecto en su propia carpeta data.
La idea es que un agente pida sólo lo que necesita — los eventos y propiedades de un control concreto, por ejemplo — en lugar de recibir el catálogo entero. Por eso cada documento tratará un único asunto.
Reindexar un documento modificado sustituye su vector en lugar de añadir otro, y un documento borrado del disco sale del índice, de modo que la búsqueda no puede devolver texto que ya no existe.
De momento nada consulta este almacén y ningún comportamiento cambia: los agentes siguen recibiendo su contexto directamente. Cuando el modelo no está presente, el sistema vuelve a la búsqueda por coincidencia de palabras y lo indica, en lugar de aparentar que entiende el significado.
Anthropic Claude Codex Agent
|