Un lenguaje común entre agentes, sin prometer magia

Revisé si WSP, el formato de mensajes de ECHO, podía ser un idioma entre agentes: qué sirve, qué falla y cómo probarlo.

Quise averiguar si WSP podía servir de lenguaje entre módulos y agentes de ECHO: percepción, planificador, supervisor y un modelo que propone hipótesis. La idea de expresar eventos como relaciones tipadas, con formatos de texto, bits o sonido, es fértil. La implementación de 32 bytes presentada como WSP-5.8 todavía no es un protocolo compatible ni una mejora demostrada. Por eso publico un roadmap de investigación, no un anuncio de release.

Qué medí y qué no

Inspeccioné el repositorio público de WSP en un commit fijado y el paquete de 16 bytes ya existente en ECHO. Ejecuté 33 pruebas seleccionadas del proyecto WSP; pasaron. En un ejemplo de una sola línea, WSP usó 49 tokens con el tokenizador fijado de Qwen2.5-Coder-32B-Instruct. Un JSON con nombres usó 62 y uno posicional 47. La ventaja frente al JSON con nombres fue 21%; frente al JSON posicional, WSP usó 4,3% más tokens. Es una muestra mínima, no un benchmark general.

También comprobé que una grilla arbitraria de 64×64 con cuatro bits por píxel puede requerir 2.048 bytes. Un paquete pequeño no reemplaza esa geometría sin pérdida. Deltas y referencias a datos compartidos pueden ahorrar transmisión, pero hay que contar la base, el acceso y los detalles que se recuperan. No medí inferencia GPU, un canal físico de audio, latencia IPC ni puntuación ARC.

Bits y frecuencias son medios, no semántica

El WSP existente ya explora máscaras musicales y una ruta acústica FSK. A la tasa nominal calculada para ese formato, 32 bytes ocuparían unos 5,6 segundos antes de cabeceras y pausas adicionales. No he medido altavoz, micrófono, ruido ni reconocimiento entre equipos. El sonido podría ser útil para interacción o sincronización, pero no es automáticamente más rápido que datos digitales.

Una secuencia binaria o una frecuencia puede transportar una señal compacta. Para que dos agentes la entiendan, necesitan compartir el código y su significado. Las películas Close Encounters of the Third Kind y Project Hail Mary inspiran preguntas sobre comunicación; no son evidencia de que los agentes converjan espontáneamente en una lengua universal. La investigación de comunicación emergente estudia tareas, recompensas y decodificadores concretos.

Correcciones necesarias antes de integrar

La propuesta cambia identificadores que colisionan con átomos existentes, y el formato de 16 bytes citado en ella no mide 16 bytes. La estructura C propuesta no pasa una comprobación estricta C11 tal como está escrita. El cálculo de clave CAM en C y Python da resultados distintos. Además, un emisor no puede autodeclarar que su mensaje está verificado: la autoridad debe venir del supervisor que comprueba la evidencia. Un MAC demuestra integridad y origen bajo una clave; no demuestra que una hipótesis sea cierta.

Por eso mi dirección es evolucionar los formatos en las fronteras existentes, conservar compatibilidad explícita, separar hechos de hipótesis y enlazar observaciones a frames y recibos comprobables. No añadiré un segundo bus de pensamiento, una CAM paralela ni un LLM en NEXUS-0. La primera entrega debe ser fixtures y codecs compatibles; solo después compararía coste y recuperación exacta con datos públicos congelados.

Roadmap de investigación e implementación

  1. Contrato compatible, CPU: fijar IDs, namespaces versionados, entidades por episodio, ausencias, rangos, autoridad y fixtures de interoperabilidad. Rechazar MAC alterados, replay, valores inválidos y declaraciones de verificación no autorizadas.
  2. Compresión justa, CPU: comparar JSON actual, JSON posicional y WSP sobre los mismos campos y observaciones públicas. Contar leyendas, frames, deltas y referencias; medir tokens Qwen exactos, bytes, parseo, recuperación de geometría y feedback retenido. Separar el efecto del codec del efecto de percepción.
  3. Calibración ARC pareada, con GPU solo después: primero BP35, y luego muestras de movimiento y clics si pasa la puerta. Comparar CPU ECHO, REPL con JSON y el mismo REPL con WSP. Registrar niveles, acciones, score oficial, tokens, hipótesis contrastadas, latencia y errores de custodia. No llamar The Duck a un arnés distinto.
  4. Audio e IPC, solo si hay motivo medido: perfilar primero. Para sonido, medir BER, latencia y recuperación en ruido y distinguir decodificación exacta de fallback heurístico. Para memoria compartida, probar procesos reales, sincronización, reinicios y backpressure; no afirmar zero-copy por tener un struct alineado.

La puerta propuesta para el codec es ahorrar al menos 15% de tokens medianos frente al mejor control equivalente sin pérdida en casos geométricos ni de custodia; es un criterio por fijar antes del corpus de evaluación, no una predicción. Si no se cumple, conservaré la representación más simple. El 90% de ahorro, el 20× de latencia y las afirmaciones de 15 ns siguen sin evidencia experimental.

Conclusión

WSP merece una prueba como formato interoperable y herramienta de trazabilidad. Su posible beneficio para ARC está en conservar y transmitir observaciones útiles con menos coste, no en descubrir por sí solo quién es el jugador o cuál es la meta. La reciente R2 de ECHO-5.5 refuerza esa cautela: hacer caber el contexto no produjo una estrategia. En BP35, el modelo terminó con cero niveles, 16 acciones, ocho llamadas y 22.201 tokens. El siguiente paso es mejorar y medir la memoria experimental antes de volver a atribuir inteligencia al formato o al modelo.

Fuentes y evidencia

  1. Auditoría técnica WSP-5.8 completa Original
  2. Roadmap y puertas propuestas Original
  3. Mediciones reproducibles y límites
  4. Repositorio WSP en el commit auditado
  5. Foerster et al., comunicación multiagente aprendida
  6. Lowe et al., riesgos de medir comunicación emergente
Consultar el archivo documental completo

Siguiente cuaderno
Del smoke a niveles reales: lo que resolvió ECHO

Vista previa

Abrir original