Flujo de trabajo de operación del conocimiento (Modo LLM Wiki)
Posicionamiento y aplicación
Este Skill es una metodología independiente de la plataforma: transforma conocimiento externo en reglas de comportamiento que el agente puede invocar en tiempo de ejecución (Memory/Policy/Skill). El conocimiento no es un marcador, es un motor de crecimiento de capacidades del agente — cada elemento de conocimiento ingresado debe pasar por destilación, y el único criterio para juzgar su valor es: ¿puede cambiar directamente la decisión del agente en un escenario concreto?
- Si el proyecto ya tiene su propio archivo de políticas de conocimiento (como
project_policy.md), ese archivo es la referencia autorizada; en caso de conflicto, se aplica la política del proyecto. - Al aplicar en diferentes plataformas/proyectos, se sigue la arquitectura de tres capas y el flujo de trabajo de este Skill; los nombres de directorio se pueden localizar. El repositorio
examples/proporciona ejemplos mínimos que se pueden ejecutar directamente.
Arquitectura de tres capas
| Capa | Directorio recomendado | Naturaleza |
|---|---|---|
| Raw Sources | raw/ (artículos/discusiones/videos) | Solo lectura, inmutable después de la ingesta |
| The Wiki | knowledge_base/ (index.md, collection_experience.md, operation_log.md) | Contenido derivado mantenido por el LLM |
| The Schema | project_policy.md + program files/config/ | Mantenido conjuntamente por humanos y LLM |
Principio clave: Los archivos originales siempre permanecen en Raw Sources, no se mueven al Wiki; después de la validación, se establece una referencia en index.md y se considera "ingestado".
Separación de roles (obligatorio)
| Rol | Entidad | Responsabilidades | Prohibiciones |
|---|---|---|---|
| Planner | Humano | Definir objetivos de ingesta, definir contrato de valor, guiar dirección de análisis | No manipular archivos directamente |
| Generator | LLM | Ejecutar ingesta, completar metadatos, escribir resúmenes, mantener el índice y el log | Prohibido autoevaluar la calidad de la salida |
| Evaluator | Herramienta de validación (p. ej., scripts/validate.py) | Validar formato, codificación, metadatos, referencias cruzadas de forma independiente | No participar en la generación |
Regla central: el modelo no puede calificarse a sí mismo. La evaluación de valor la registra el Generator en el log de operación, y la aprobación o no la determina el Evaluator; si el humano tiene objeciones, la decisión humana prevalece. Cuando el proyecto no tiene herramienta de validación, se sigue el Lint de seis dimensiones punto por punto, pero la conclusión no puede ser autojustificada por el generador.
Ingest (Ingesta)
Copia esta lista de verificación para seguir el progreso:
- [ ] 1. Contrato de valor previo a la ingesta (tres preguntas)
- [ ] 2. Realizar ingesta y completar metadatos
- [ ] 3. Leer contenido, extraer información clave
- [ ] 4. Juicio de valor (detener si no cumple)
- [ ] 5. Actualizar index.md (resumen + referencias cruzadas)
- [ ] 6. Agregar al registro de operaciones
- [ ] 7. Evaluar destilación y marcar estado de implementación
- [ ] 8. Commit de Git
Paso 1 · Contrato de valor previo a la ingesta — Responde las tres preguntas antes de comenzar y regístralas:
- ¿Qué problema resolverá este artículo? ¿Cuál es su relación con el conocimiento existente? (complemento/contraste/extensión)
- ¿Bajo qué condiciones se considera "valioso"? Al menos una condición: introduce un nuevo concepto, proporciona una perspectiva de comparación, o tiene referencia operativa directa.
- ¿En qué nivel de index.md se espera clasificar? (teoría fundamental/paradigma arquitectónico/práctica de ingeniería/herramientas y recursos/dinámica de la comunidad)
Paso 2 · Ingesta y metadatos — Usa el motor de ingesta de la plataforma actual para obtener el texto original (ver "Abstracción del motor de ingesta"), guárdalo en el subdirectorio correspondiente de Raw Sources, el nombre del archivo sigue el patrón {source}_{topic}_{date}.{ext} (p. ej., github_karpathy_llm_wiki_20260630.md). Los metadatos obligatorios son: URL, Tiempo de ingesta, Comando de ingesta; campos sugeridos: Por, Sitio, Publicado, Fuente original. El motor de ingesta generalmente solo puede extraer campos parciales automáticamente; los demás deben completarse.
Paso 4 · Juicio de valor (incluye detener) — Evalúa contra el contrato del Paso 1. Si claramente no cumple ninguna condición de valor (contenido vacío, repetición grave, irrelevante para el posicionamiento del conocimiento), registra explícitamente la razón de la detención en el registro de operaciones y luego sale, sin forzar la finalización del flujo de ingesta.
Paso 6 · Formato del registro de operaciones: ## [fecha] ingest | título (solo añadir).
Paso 7 · Evaluación de destilación — ¿Contiene esta entrada reglas atómicas que puedan guiar directamente el comportamiento del agente?
| Marcador | Significado | Acción |
|---|---|---|
| 🟢 Implementado | Tiene reglas atómicas ejecutables | Extraer y escribir en Memory/Policy/Skill, anotar el título de Memory en el elemento de index.md |
| 🟡 Parcialmente implementado | Algunas sí | Anotar el contenido implementado y no implementado con razones específicas |
| 🔵 Referencia de índice | Sin reglas ejecutables | Describir brevemente la razón en el registro de operaciones |
Estándar de destilación: Las reglas deben poder cambiar la decisión del agente en escenarios concretos, no ideas abstractas o información de referencia.
Adaptación de destilación multiplataforma: En Qoder, el producto de destilación se escribe en el sistema Memory (metodología → task_experience, trampas → common_pitfalls_experience, decisiones arquitectónicas → important_decision_experience, etc.); en otras plataformas de agentes, se mapea al mecanismo de memoria persistente/reglas de comportamiento de esa plataforma, manteniendo los mismos criterios y marcadores de tres colores.
Paso 8: git add -A && git commit -m "ingest: título".
Query (Consulta)
- Primero lee
knowledge_base/index.mdpara localizar páginas relevantes - Lee los archivos relacionados en profundidad, sintetiza la respuesta
- Las buenas respuestas se escriben como nuevas páginas — para que la exploración misma genere rendimientos compuestos
- Agrega al registro de operaciones:
## [fecha] query | pregunta - Después de generar una nueva página:
git add -A && git commit -m "query: pregunta"
Lint (Inspección)
Primero ejecuta la herramienta de validación del proyecto (este repositorio proporciona un ejemplo sin dependencias: python scripts/validate.py <directorio_raíz_del_conocimiento>); la decisión de la herramienta prevalece sobre el juicio humano. Si no hay herramienta, revisa punto por punto las seis dimensiones:
- Integridad de metadatos — ¿Se completaron los campos obligatorios (URL, Tiempo de ingesta, Comando de ingesta)?
- Corrección de codificación — Codificaciones dobles, BOM, caracteres de reemplazo (U+FFFD)
- Conformidad de formato — Markdown debe comenzar con H1 y los metadatos y el cuerpo deben estar separados por
---; JSON debe tener el campo_metadata - Convención de nombres — ¿Sigue el patrón
{source}_{topic}_{date}? - Referencias cruzadas — ¿Los enlaces en index.md apuntan a archivos reales? Detectar páginas huérfanas
- Validación de fuente — ¿La URL pertenece a la lista blanca de fuentes?
Agrega al registro de operaciones: ## [fecha] lint | alcance de la inspección; si hay correcciones, git commit -m "lint: alcance de la inspección".
Reducción progresiva: Las herramientas y los procesos son mecanismos auxiliares para compensar las debilidades del modelo, y deben reducirse monótonamente a medida que el modelo mejora. Cada vez que se realiza un Lint, revisa: ¿qué reglas de validación ya no se activan? ¿qué pasos ha internalizado el modelo? Elimínalos.
Abstracción del motor de ingesta (adaptación multiplataforma)
El flujo central no está vinculado a ninguna herramienta de ingesta; el motor se elige según la disponibilidad de la plataforma:
| Entorno de plataforma | Método de ingesta |
|---|---|
| Windows + navegador Edge | AutoCLI: autocli read "URL" -f markdown -o "ruta de salida", extrae automáticamente Por/Sitio/URL; ten en cuenta que en PowerShell, la información de progreso de stderr puede causar un falso ExitCode=1, si la salida contiene "Saved to ..." es éxito |
| Plataforma de agente con capacidad de lectura web | Herramienta de lectura web (WebFetch, etc.) para capturar directamente y convertir a Markdown |
| Fuentes API públicas | Hacker News, Lobsters, etc., no requieren navegador, solicitud API directa |
| Sin herramientas de red | El usuario pega el texto original, lo guarda manualmente y registra honestamente el Comando de ingesta como "pega manual" |
Independientemente del motor, los requisitos de metadatos, validación y destilación después de la ingesta son exactamente los mismos. El campo Comando de ingesta registra fielmente el motor y el comando realmente utilizados (incluidas las degradaciones), garantizando la reproducibilidad.
Referencia rápida de convenciones
- Nombre de archivo:
{source}_{topic}_{date}.{ext}, source en minúsculas - Registro de operaciones: solo añadir, formato
## [fecha] {ingest|query|lint} | breve descripción - Mensaje de commit:
{ingest|query|lint}: {breve descripción}; inicialización:init: línea base del conocimiento - Las lecciones y trampas se registran estructuradamente en
collection_experience.md, no se mezclan con el registro de operaciones