LWC

Servidor MCP de solo lectura para exploración acotada de memoria de proyecto basada en el código fuente, con citas, procedencia, recuperación SQLite/FTS5 y gráficos opcionales de documentos y código.

Documentación

LWC — Memoria proactiva para agentes de IA

Impulsado por agentes · Persistente · Basado en fuentes

npm: @i-xor/lwc crates.io: lwc Node.js 22 or newer Platform: macOS, Linux, Windows CI skills.sh: using-lwc License: Apache-2.0

Inglés · 简体中文 · 日本語 · Español · Português (Brasil) · Francés · Русский

LWC — Proactive Memory for AI Agents

lwc es una CLI de memoria proactiva impulsada por agentes para agentes de IA. Permite que los agentes recuperen, mantengan y evolucionen de forma autónoma conocimiento persistente y basado en fuentes a lo largo de las sesiones.

Funciona con Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Kiro, Hermes, Antigravity, GitHub Copilot en VS Code, Copilot CLI, Copilot para JetBrains y pi.

LWC convierte documentos seleccionados en una Wiki duradera. Los agentes razonan y sintetizan; lwc preserva fuentes, páginas, citas, enlaces, índices e historial para que el conocimiento se acumule en lugar de redescubrirse desde fragmentos en bruto en cada consulta.

LWC product overview

Memoria de equipo autoalojada — v0.19.3

Los espacios de equipo de LWC mantienen la memoria central en SQLite local y archivos Wiki, y la sincronizan automáticamente a través de un servidor autoalojado. Los agentes externos resuelven conflictos mediante CLI/MCP; LWC no incorpora un LLM. La consola de equipo admite inglés y chino simplificado, permisos de espacio explícitos, acceso de dispositivos/agentes y recuperación de memoria auditable. Los lectores solo en la nube pueden consultar sin crear una réplica local.

Consulta la guía de implementación, el protocolo y el diseño de acceso y recuperación. El inicio de sesión con correo electrónico, Feishu y GitHub utiliza la configuración de proveedor proporcionada por la implementación.

Inicia sesión con una clave personal generada, selecciona un espacio autorizado y aprovisiona un miembro con acceso inicial al espacio en un solo paso. Comparte enlaces de páginas con verificación de permisos y sigue enlaces de conocimiento sin salir del lector. Guía de equipo · Notas de la versión.

LWC es memoria de agente, no RAG

Tanto RAG como LWC pueden ayudar a un LLM a trabajar con documentos externos, pero mantienen el estado en lugares diferentes. Una solicitud RAG típica recupera fragmentos en bruto y construye una respuesta en el momento de la consulta:

query -> retrieve chunks -> generate answer

LWC conserva el trabajo útil entre solicitudes:

task -> recall maintained Wiki -> reason from sources and prior synthesis
     -> write durable improvements back

La recuperación es una operación dentro de LWC, no su principio organizador. El artefacto duradero es una Wiki basada en fuentes cuyas páginas, citas, enlaces, contradicciones e historial se revisan a medida que cambia el conocimiento. Por lo tanto, LWC no requiere incrustaciones ni una base de datos vectorial, y no descarta cada síntesis después de responder. Puede complementar RAG, pero no es RAG en el momento de la consulta.

LWC source grounding and traceability

El agente opera LWC

lwc es una interfaz de máquina para agentes, no una aplicación de toma de notas orientada a humanos. En el uso normal, un humano selecciona fuentes, establece objetivos, hace preguntas y revisa respuestas o el Markdown proyectado. El agente ejecuta la CLI, gestiona el alcance, integra fuentes, mantiene citas y enlaces, y decide qué vale la pena recuperar o escribir de vuelta.

No conduzcas manualmente el flujo de trabajo rutinario de lwc a menos que estés desarrollando o depurando la herramienta. Pide a tu agente que active la habilidad canónica using-lwc incluida en su lugar, generalmente como $using-lwc.

Recomendado: pide a tu agente que configure LWC

Pega este mensaje en el agente que uses. Instala la CLI global, delega toda la configuración de hosts compatibles al instalador idempotente AgentTarget de LWC y usa la autoconfiguración nativa solo para un agente no registrado.

Copia el mensaje de configuración completo
Configure LWC completely for this user. Perform and verify the work; do not
merely describe commands for me to run.

Source of truth:
- https://github.com/JanYork/llm-wiki-cli
- https://github.com/JanYork/llm-wiki-cli/tree/main/skills/using-lwc

Requirements:
1. Read this README, `SECURITY.md`, and `skills/using-lwc/SKILL.md`. Install the
   official checksum-verified release if `lwc` is not globally callable; never
   prefix routine commands with a private binary path or `LWC_PROJECT_ROOT`.
2. Run `lwc --version`, initialize global memory once with
   `lwc --scope global init` when missing, then run `lwc agent install --yes`.
   This command detects installed supported Agents and safely installs their
   MCP, Skill, Hook and Instructions using official locations. Do not recreate
   that logic manually or install a native package for the same Agent as well.
3. Inspect `lwc agent status --target all --location global`. Restart affected
   Agents and complete their normal Hook trust review where required. Do not
   initialize a project Wiki or either graph without explicit project consent.
4. If the current runtime is not one of LWC's registered AgentTargets, use its
   official user-level conventions to install the canonical `using-lwc` Skill,
   an additive instruction block, `lwc serve --mcp`, and a bounded session Hook
   only where those surfaces are officially supported. Preserve existing
   configuration, remain idempotent, and report unsupported surfaces instead of
   inventing paths or keys.

Finish with the LWC version, detected and configured Targets, status results,
files changed, unsupported surfaces, and any restart or trust action remaining.

Origen y agradecimientos

lwc implementa el patrón LLM Wiki propuesto por Andrej Karpathy: un LLM construye y mantiene de forma incremental una Wiki persistente e interconectada en lugar de reconstruir conocimiento a partir de documentos en bruto para cada consulta. La arquitectura de la CLI y los detalles de implementación seleccionados también se inspiran en nashsu/llm_wiki.

Este proyecto adapta esas ideas a una CLI de Rust prioritaria para agentes respaldada por SQLite.

Diseño central

LWC architecture

LWC mantiene cuatro capas distintas para que el conocimiento duradero siga siendo trazable:

CapaPropósito
Fuentes en brutoInstantáneas inmutables de evidencia seleccionada
WikiPáginas, citas, enlaces y procedencia mantenidos por el agente
Memoria temporalRegistros compactos de cambios, decisiones, resultados y trabajo pendiente
Esquema y propósitoReglas específicas del proyecto que guían el mantenimiento futuro

SQLite es canónico. El Markdown, los índices de texto completo y los almacenes de grafos opcionales son proyecciones reconstruibles. Los agentes actualizan el conocimiento mediante la CLI; las operaciones exitosas devuelven JSON estructurado que se puede auditar y reanudar.

Lee la descripción general de la arquitectura →

Archivos de memoria portátiles

Los agentes pueden empaquetar una Wiki de proyecto, o una Wiki global seleccionada explícitamente, en un único archivo portátil e importarlo de forma segura o fusionarlo de forma conservadora en otro almacén de LWC. El archivo contiene la memoria de texto plano completa de la Wiki seleccionada, por lo que debes compartirlo solo con un destinatario de confianza y tratar el contenido recibido como datos no confiables, no como instrucciones.

La memoria existente nunca se reemplaza implícitamente: las importaciones preparan una fusión reanudable, mientras que la sobrescritura completa del almacén requiere confirmación humana separada. Los índices y proyecciones reconstruibles se restauran después de la publicación; Tutor, Book y Practice permanecen independientes del archivo v1.

Usa archivos de memoria portátiles de forma segura →

Recuperación jerárquica y grafo de conocimiento

LWC indexa fuentes y páginas Wiki a nivel de documento, pasaje y oración. Los agentes pueden comenzar con un contexto pequeño con forma de respuesta, expandir el intervalo exacto solo cuando sea necesario y detectar localizadores obsoletos después de cambios de contenido.

LWC memory graph

El grafo de documentos opcional conecta páginas, fuentes, citas, enlaces y relaciones semánticas explícitas. SQLite sigue siendo la autoridad, mientras que Grafeo o SurrealDB proporcionan una capa de recorrido reconstruible. Las relaciones explícitas mantienen su razón, procedencia, confianza y evidencia de fuente.

Conversión de documentos y lectura de Office

Los adaptadores opcionales Anydoc o MarkItDown convierten archivos locales compatibles en Markdown revisable antes de la ingesta. OfficeCLI proporciona una ruta separada, basada en consentimiento y de solo lectura para archivos de Word, Excel y PowerPoint. Ninguna capacidad se instala o habilita silenciosamente, y los archivos de Office de origen nunca se modifican.

La búsqueda de pasajes también indexa la ruta de encabezados H2-H6 circundante como un campo independiente. El contexto de encabezados puede mejorar la coincidencia, pero nunca se antepone al fragmento devuelto ni se incluye en su rango de bytes, por lo que las citas y los localizadores de intervalo siguen apuntando al texto canónico exacto del cuerpo. La migración 17 del almacén reconstruye solo este índice derivado de intervalo/búsqueda.

Explora la recuperación y la indexación → · Grafo de documentos → · Conversión de documentos →

Suite de aprendizaje opcional

Tutor, Book y Practice son capacidades independientes de primera parte, deshabilitadas por defecto y respaldadas por almacenes privados separados:

  • Tutor conserva turnos de enseñanza, evidencia del alumno, objetivos, planes y un Soul/Wiki privado.
  • Book importa libros compatibles en orden de fuente verificado para una lectura completa y fundamentada.
  • Practice conserva bancos de preguntas versionados, exámenes, intentos, calificaciones, tarjetas didácticas y estado de revisión FSRS.

Cada runtime se descarga de forma diferida, se fija a la versión de LWC y se verifica mediante suma de verificación. Deshabilitar una capacidad preserva sus datos canónicos. Las habilidades del agente gestionan la recuperación y la persistencia sin exponer el mantenimiento rutinario al alumno.

Lee los contratos de la Suite de aprendizaje →

Instalación

La mayoría de los usuarios solo necesitan un comando de paquete:

npm install --global @i-xor/lwc

Homebrew, crates.io, versiones de GitHub verificadas por suma de verificación y compilaciones locales de Cargo también son compatibles.

Guía de instalación y actualización →

Habilidad de agente complementaria

La habilidad using-lwc incluida convierte a LWC en una capa de memoria proactiva. Recuerda contexto limitado, mantiene separados el conocimiento del proyecto y el global, integra fuentes, preserva citas y escribe de vuelta solo conocimiento verificado que valga la pena reutilizar.

Instálala desde skills.sh:

npx skills add JanYork/llm-wiki-cli --skill using-lwc -g

El desencadenante canónico es $using-lwc. La habilidad es neutral en cuanto al runtime e incluye orientación específica para memoria, grafos de documentos, Word Graph, CodeGraph, etiquetas fuertes, conversión, incorporación, recuperación y mantenimiento.

Configuración nativa del agente

LWC detecta agentes compatibles e instala sus superficies MCP, Skill, Hook e Instructions disponibles mediante adaptadores AgentTarget idempotentes:

lwc agent install --yes

El MCP unificado de solo lectura expone memoria Wiki limitada y contexto de código opcional sin ampliar el espacio de trabajo activo. Los 12 objetivos registrados son Claude Code, Cursor, Codex, OpenCode, Hermes, Gemini CLI, Antigravity, Kiro, GitHub Copilot en VS Code, Copilot CLI, Copilot para JetBrains y pi.

agent status informa hook_capabilities verificado por separado de los eventos nativos realmente escritos como installed_hook_events para ese ámbito. El consentimiento de shell restringido se aplica como una solicitud solo para Claude Code, Cursor, Hermes global y Antigravity; Codex recibe contexto adicional de asesoramiento y no puede aplicar la solicitud. Los eventos de consentimiento no compatibles no se instalan y devuelven una no operación exacta. Solo Claude Code y Codex pueden continuar un Plan activo procesable desde Stop, una vez por guardia de bucle nativo; otras superficies de Stop no se simulan. La actualización y desinstalación eliminan solo las entradas de hook propiedad de LWC, incluidas las entradas dentro de grupos compartidos, mientras preservan la configuración de elementos hermanos y de usuario.

Las capacidades de grafo siguen siendo conscientes del consentimiento: las relaciones de documentos requieren el grafo físico, las tareas de estructura de código requieren CodeGraph, y ninguna se habilita simplemente porque su runtime exista. La lectura de Office sigue el mismo límite de consentimiento explícito.

Integración de AgentTarget →

Inicio rápido

Los humanos normalmente describen el objetivo y revisan el resultado; el agente opera la CLI. El recorrido completo se encuentra en la página Wiki de inicio rápido.

1. Inicializa una Wiki de proyecto

El agente crea una Wiki local del proyecto y define su propósito y reglas de mantenimiento. El estado del proyecto se excluye localmente de Git a menos que versionarlo fuera una elección explícita.

2. Agrega material de origen

Los archivos seleccionados se convierten en instantáneas inmutables y deduplicadas. LWC rastrea sus rutas en vivo y puede informar si el archivo actual no ha cambiado, está modificado, falta o ha sido reemplazado.

3. Analiza e integra una fuente

El agente lee la fuente limitada completa, escribe un resumen de fuente citado, actualiza el conocimiento compartido y completa la ingesta solo después de que ambas capas sean consistentes.

4. Consulta la Wiki acumulada

La búsqueda es primero por página y está basada en fuentes. Los agentes recuperan respuestas mantenidas primero, luego abren la evidencia de fuente exacta cuando una afirmación necesita verificación.

Flujo de trabajo del agente

El bucle normal es corto:

  1. Recupera el conocimiento mantenido relevante.
  2. Inspecciona las fuentes o el código actuales cuando la frescura importa.
  3. Realiza la actualización verificada más pequeña.
  4. Valida la recuperación, los enlaces y las proyecciones de grafo aplicables.

Las revisiones amplias utilizan un conjunto de cambios atómico. Consulta el flujo de trabajo completo del Agente para conocer los límites de confianza, las condiciones previas, la recuperación y la evidencia de finalización.

Memoria Temporal

La memoria temporal registra eventos compactos sobre qué cambió, por qué se tomó una decisión, qué se intentó, el resultado y qué queda sin resolver. Complementa la Wiki: el recuerdo temporal explica la historia; la Wiki representa el conocimiento estable actual.

La retención está limitada y protege los registros fijados, no resueltos y de contradicción abierta. Los eventos se normalizan en lugar de almacenarse como transcripciones de chat sin procesar, y los eventos similares nunca se fusionan en silencio.

Guía de memoria persistente →

Sincronización Multi-máquina

La sincronización reconcilia la memoria del proyecto, la memoria global o ambas a través de SSH, manteniendo el estado semántico de la Wiki separado de la publicación de Git. La fusión conserva los objetos únicos de ambos lados; los conflictos se devuelven como paquetes limitados para su resolución explícita.

Las sesiones son duraderas y reanudables. LWC nunca copia la base de datos SQLite en vivo, ni los archivos WAL o SHM, nunca restablece el árbol de trabajo y mantiene la publicación canónica separada de las proyecciones de búsqueda y grafo reconstruibles.

Flujo de trabajo de sincronización y contrato de seguridad →

Cambios Atómicos Multi-comando

Los conjuntos de cambios mantienen una actualización de conocimiento de varios pasos invisible hasta que se revisa y valida. El commit publica solo las entidades canónicas tocadas en una transacción; el trabajo en vivo no relacionado sobrevive, y los conflictos de revisión de la misma entidad fallan de forma segura.

Un commit exitoso registra un parche inverso exacto para las operaciones compatibles, lo que permite una reversión protegida sin reemplazar toda la Wiki.

Las lecturas de borrador ven las escrituras en etapas, mientras que SQLite y Markdown en vivo permanecen sin cambios. La base de datos de borrador comienza como una superposición dispersa pequeña; no copia ni hace checkpoint de la Wiki en vivo. changeset show informa operaciones en etapas, revisiones y preparación sin ejecutar lint. El commit valida y aplica solo las entidades tocadas, por lo que las escrituras en vivo no relacionadas sobreviven; un conflicto de revisión de la misma entidad falla sin sobrescribir ninguno de los lados. El commit rechaza borradores vacíos y errores de lint bloqueantes; las advertencias e información siguen siendo guía de revisión y no bloquean la publicación. No hay fusión forzada ni automática. Usa --allow-lint-issues --reason "reviewed pre-existing debt" solo para deuda auditada que el conjunto de cambios no introdujo. Después del commit, vuelve a ejecutar las mismas comprobaciones de recuperación fijas contra el estado en vivo. El commit congela el borrador revisado antes de la publicación; changeset_frozen bloquea cualquier escritura en etapas posterior. Reintenta el mismo commit para la recuperación, o descarta después de un conflicto informado—nunca agregues más trabajo a un borrador congelado.

lwc --scope project changeset discard architecture-refresh
lwc --scope project changeset rollback <CHANGESET_ID>

El descarte toca solo un borrador no confirmado. El commit escribe un parche inverso con suma de verificación que contiene solo las entidades tocadas y devuelve el ID de reversión exacto; la reversión restaura solo esas entidades y se niega si una cambió de nuevo. Los conjuntos de cambios de proyecto y global son separados, --scope all es inválido, y init, maintenance, checkpoint y los comandos de conjuntos de cambios anidados rechazan --changeset. Los borradores nunca crean una segunda proyección de Markdown. Si un error estructurado informa committed=true con trabajo de limpieza o materialización pendiente, no repitas los cambios de conocimiento; ejecuta la acción de recuperación devuelta.

El commit disperso actualmente tiene parches exactos para agregar/ingerir Source, poner/quitar Page, esquema, propósito y operaciones de búsqueda registradas. Las mutaciones de peso de recuperación y de relación semántica explícita fallan antes del checkpoint o de tomar un bloqueo de escritura en vivo con changeset_sparse_unsupported; aplícalas como transacciones directas de una sola entidad hasta que sus parches inversos dispersos estén disponibles.

Guía de conjuntos de cambios →

Ámbitos

ÁmbitoUso
projectConocimiento propiedad de la Wiki del proyecto más cercano
globalConocimiento reutilizable compartido entre proyectos
allRecuerdo combinado de solo lectura y Sincronización coordinada

Las escrituras siempre apuntan a un almacén explícito. LWC nunca crea citas o enlaces implícitos entre proyectos.

Ámbitos y descubrimiento de proyectos →

Búsqueda y CJK

La búsqueda es léxica, determinista y primero por página. Mantiene título, ruta, resumen, cuerpo, procedencia y evidencia de grafo distintos; admite filtros de página/fuente/tipo; y puede explicar la aritmética exacta de la puntuación.

El texto CJK usa bigramas adyacentes más unigramas útiles, mientras que el texto latino usa términos alfanuméricos en minúsculas. Este diseño sin diccionario sigue siendo estable para nombres de productos, símbolos de código, texto en idiomas mixtos y vocabulario emergente.

Pesos de recuperación explícitos y retroalimentación

Los pesos de documento auditables capturan importancia duradera. La retroalimentación específica de consulta reordena solo los candidatos coincidentes y almacena una huella digital en lugar de la consulta sin procesar. Ningún mecanismo puede hacer que aparezca contenido no relacionado.

Guía de búsqueda y contexto →

Visor de Solo Lectura y CodeGraph

lwc view inicia un inspector de proyecto en primer plano, solo de loopback y abre el navegador. Sirve una aplicación incrustada de TS + Lit—sin CDN y sin runtime de Node en el momento de uso—y expone solo APIs GET/HEAD. Las páginas, fuentes, Markdown, el grafo de conocimiento y el grafo de código opcional se leen del proyecto actual sin migración, actualización o construcción de grafo:

lwc view
lwc view --port 4173 --no-open

El detalle de página usa el título canónico, resumen, tipo, procedencia, citas y marcas de tiempo. El visor suprime solo un H1 de cuerpo inicial que coincida con el título canónico y deriva una tabla de contenidos local de tres o más encabezados H2-H4. Estas reglas de presentación nunca reescriben contenido canónico o Markdown proyectado.

El visor se inicia en inglés. Usa el control 中文 / EN para cambiar de idioma; el navegador recuerda la selección mientras el contenido de la Wiki permanece en su idioma de autoría. Los grafos usan una vista de relación 3D única inspirada en Obsidian con nodos pequeños, etiquetas persistentes, enlaces delgados, rotación y zoom.

LWC CodeGraph code intelligence

CodeGraph es solo de proyecto y se inicializa explícitamente. Responde preguntas sobre símbolos, llamadores, llamados, dependencias, archivos e impacto, mientras mantiene la telemetría deshabilitada y las escrituras de grafo atómicas por archivo propietario.

El runtime fijado reconoce TypeScript, TSX, JavaScript, JSX, ArkTS, Python, Go, Rust, Java, C, C++, C#, Razor, PHP, Ruby, Swift, Kotlin, Dart, Svelte, Vue, Astro, Liquid, Pascal, Scala, Lua, Luau, Objective-C, R, Solidity, Nix, YAML, Twig, XML, .properties, CFML, CFScript, CFQuery, COBOL, VB.NET, Erlang y Terraform.

Guía del visor → · Guía de CodeGraph →

Mantenimiento y Proyección

Lint, reindexación, materialización de Markdown, compactación, checkpoints y proyección de grafo son operaciones explícitas. El trabajo de larga duración es duradero, observable, reanudable y se aplica en unidades de documento limitadas.

SQLite sigue siendo canónico durante todo el proceso. Los índices de búsqueda, Markdown y almacenes de grafo se pueden reconstruir sin reescribir el historial de fuentes o el conocimiento actual de la Wiki.

lwc lint mantiene total y counts como campos de compatibilidad para todos los problemas y agrega blocking_total para errores más advisory_total para advertencias e información. La guía determinista de Markdown actualmente informa H1 de cuerpo conflictivos o duplicados, el primer salto de nivel de encabezado y una región de prosa larga sin secciones; solo los errores de integridad bloquean el commit del conjunto de cambios.

Notas:

  • Los comandos de mantenimiento devuelven un work duradero de inmediato. Lee el progreso con work status, o usa work watch e inspecciona work.result después del éxito. La migración de esquema v10 a v11 usa el mismo mecanismo automáticamente, por lo que los comandos normales nunca realizan esa migración en línea.
  • lint es de solo lectura por defecto. Agrega --record solo cuando la pasada de lint pertenezca al historial de operaciones duraderas.
  • maintenance reindex reconstruye los artefactos de búsqueda derivados de SQLite.
  • maintenance materialize reconstruye el árbol de Markdown proyectado desde SQLite.
  • maintenance compact solo intenta un checkpoint de truncamiento WAL; no oculta una optimización FTS completa. Ejecútalo mientras la Wiki esté inactiva e inspecciona busy más after_bytes. Un lector ocupado regresa rápidamente sin cambiar el contenido canónico.
  • Las consultas de búsqueda son privadas por defecto; agrega --record solo cuando quieras que la redacción de la consulta se almacene en el registro de operaciones duraderas.

lwc checkpoint create <NAME> usa la API de copia de seguridad en línea de SQLite. Restaura con lwc checkpoint restore <NAME>; LWC primero crea un checkpoint de seguridad pre-restore-* y luego reconstruye la proyección. Usa source remove <ID> y page remove <SLUG> para la eliminación protegida: se rechazan las fuentes con citas y las páginas con enlaces entrantes. Eliminar la fuente actual de una ruta rastreada detiene el seguimiento de esa ruta en lugar de exponer silenciosamente una revisión más antigua como actual.

Para una ingesta de múltiples fuentes o un reemplazo amplio de páginas, prefiere un conjunto de cambios sobre un checkpoint manual: un commit exitoso escribe un parche inverso disperso, publica solo las entidades canónicas tocadas en una transacción y materializa incrementalmente el Markdown cambiado. El commit intenta un truncamiento WAL después de la publicación; wal_checkpointed=false significa que un lector activo lo impidió y no significa que el commit canónico fallara.

Para una copia de seguridad del sistema de archivos externo, detén los comandos lwc activos y copia el directorio .lwc/ completo. No copies solo wiki.db mientras un escritor pueda estar usando sus archivos WAL.

Mantenimiento y diagnóstico →

Suite de Benchmarks

El benchmark opcional mide el tiempo de importación, la latencia de búsqueda, Recall@5/10, MRR y almacenamiento en un corpus sanitizado proporcionado por el llamador. Las comparaciones justas fijan la máquina, el corpus, el conjunto de consultas y las condiciones de ejecución, y luego comparan las medianas de ejecuciones repetidas.

Metodología de benchmark →

Resultados de recuperación LongMemEval-S (v0.18.5)

Esta es una línea base de recuperación sin ajustar, no un techo sobre la efectividad de LWC con el uso continuo. En flujos de trabajo reales, el modelo puede evaluar proactivamente la evidencia y reaccionar a las correcciones del usuario o a la retroalimentación de relevancia, actualizando continuamente los pesos de documentos y la retroalimentación de consultas. Con retroalimentación confiable y ajuste sostenido, se espera que la recuperación mejore más allá de esta línea base estática; esa ganancia adicional no se cuantificó aquí. El ajuste reactivo significa actualizaciones del Agente desencadenadas por retroalimentación, no aprendizaje automático en segundo plano en cada consulta.

El 13 de septiembre de 2026, dos ejecuciones locales completas procesaron 500/500 preguntas, con 470 preguntas con puntuación de recuperación, usando el conjunto de datos fijado LongMemEval-S y cuatro trabajadores concurrentes en una Mac Apple M5 Pro. La segunda ejecución reutilizó las fuentes almacenadas de la primera; las 500 listas de resultados clasificados fueron idénticas.

MétricaPrimera ejecuciónSegunda ejecución
Preguntas procesadas500 / 500500 / 500
Preguntas con puntuación de recuperación470470
Preguntas de abstención excluidas3030
Recall@183.83% (394/470)83.83% (394/470)
Recall@391.49% (430/470)91.49% (430/470)
Recall@595.11% (447/470)95.11% (447/470)
Recall@1097.66% (459/470)97.66% (459/470)
Recall@3099.15% (466/470)99.15% (466/470)
Recall@5099.15% (466/470)99.15% (466/470)
MRR0.8836680.883668
Latencia media509.883 ms679.759 ms
P50507.697 ms665.454 ms
P90663.061 ms931.238 ms
P95731.766 ms990.375 ms
P99888.555 ms1094.886 ms

Estos resultados excluyen el ajuste proactivo. El adaptador recupera fuentes de sesión sin procesar sin curación de conocimiento dirigida por el modelo, retroalimentación de relevancia ni actualizaciones de pesos. En flujos de trabajo reales de Agent, un modelo puede evaluar evidencia de manera proactiva, curar conocimiento y ajustar explícitamente pesos de documentos o retroalimentación específica de consultas para mejorar la recuperación posterior. Este es un flujo de trabajo de Agent impulsado por evidencia, no cambios automáticos de pesos en cada búsqueda; las ganancias dependen de la calidad de la retroalimentación y no se midieron aquí. Evalúe el ajuste en preguntas reservadas en lugar de alimentar las respuestas de prueba de vuelta a la misma evaluación.

Estos son resultados de recuperación local, no puntuaciones oficiales de tablas de clasificación ni precisión de respuestas. Las latencias describen carga de cuatro trabajadores, no una comparación controlada de aceleración de versiones. Datos del primer ejecución · Datos del segundo ejecución · Reproducción y puntuación.

Todo duradero y Plan actual

Todo almacena trabajo diferido; Plan almacena el objetivo en ejecución actual, pasos ordenados, progreso y revisión. Son capacidades independientes y opcionales que nunca se convierten entre sí automáticamente.

El contexto de ciclo de vida acotado aísla el progreso de Plan y Todo por sesión de Agent y, donde el host lo expone, por subagente. Cada Agent ve solo el trabajo explícitamente rastreado para su contexto opaco; los comandos detallados y los límites de capacidades del host se encuentran en la guía de flujo de trabajo.

Flujo de trabajo de Todo y Plan →

Límites y no objetivos

Restricciones de diseño actuales:

  • base de conocimiento de una sola máquina y un solo usuario;
  • flujo de trabajo de texto UTF-8;
  • tamaño de entrada acotado de 64 MiB por esquema, propósito, fuente o cuerpo de página;
  • búsqueda léxica, no recuperación vectorial semántica.

No objetivos deliberados para este CLI:

  • sin llamadas LLM integradas;
  • sin base de datos vectorial;
  • sin demonio ni servicio en segundo plano;
  • sin interfaz web ni de escritorio;
  • sin contrato de edición directa de base de datos.

Si el Markdown proyectado se desvía, reconsérvelo. Si el esquema SQLite es incorrecto, corríjalo a través del CLI y migraciones, no manualmente.

Contribuciones

Se aceptan problemas y solicitudes de extracción, especialmente en torno a:

  • ergonomía de flujos de trabajo de Agent;
  • comportamiento de proyección determinista;
  • contratos de mantenimiento de citas y páginas duraderas;
  • calidad de búsqueda para corpus técnicos multilingües.

Lea CONTRIBUTING.md antes de abrir una solicitud de extracción. Reporte problemas de seguridad según SECURITY.md.

Licencia

Licenciado bajo la Apache License 2.0.

Nuevo en 0.18.0

Los registros de Discusión duradera preservan preguntas y respuestas de aclaración visibles en SQLite con correcciones granulares y resúmenes vinculados a evidencia. CodeGraph admite paso de resultados nativo, y los contratos de Agent y la salida de recuperación son más fáciles de descubrir. Codex además admite un paquete de plugin nativo; otras rutas de instalación de host permanecen sin cambios. Consulte Discusión y Plugin de Codex.