Weaver Stack предлагает единый контрактный слой для безопасных LLM‑агентов

Инициатива weaver-spec предлагает способ строить LLM-агентов через общий контрактный слой между компонентами системы. Как пишет Towards AI, документ нацелен на решение четырех типичных проблем агентных архитектур: tool explosion, context bloat, unsafe execution и flaky orchestration.

В реальных системах у агента может быть более 1,000 инструментов. Их схемы раздувают контекст и расходуют токены. К этому добавляется другая проблема: результаты работы инструментов часто передаются в сыром виде. Это могут быть строки из баз данных, ответы API или содержимое файлов. Такие данные нередко оказываются слишком объемными и иногда содержат информацию, которую модель не должна видеть. Ситуацию усложняют слабая прозрачность аудита вызовов и нестабильность пайплайнов, особенно когда процесс состоит из нескольких последовательных шагов.

weaver-spec при этом не предлагается как новая runtime-библиотека. Скорее это набор документации и контрактов, единый источник описаний словаря, инвариантов и language-agnostic схем. На них могут опираться независимые компоненты агентной архитектуры. В стеке выделяют три слоя: routing (contextweaver), execution (agent-kernel) и orchestration (ChainWeaver). Контракты задают структуры вроде RoutingDecision, Frame и CapabilityToken. Они описаны через JSON Schema и Python dataclasses, чтобы разные реализации могли взаимодействовать друг с другом.

У каждого слоя своя четкая роль. contextweaver собирает контекст и показывает модели не полный список инструментов, а ограниченный набор ChoiceCards, после чего формирует RoutingDecision. agent-kernel проверяет CapabilityToken, принимает PolicyDecision, выполняет вызов инструмента и пропускает результат через firewall. На выходе формируется Frame, безопасное представление для LLM. При необходимости создается Handle, ссылка на полный артефакт. Там же фиксируются TraceEvents. ChainWeaver управляет детерминированными DAG-процессами и передает все вызовы инструментов слою выполнения.

Границы между компонентами закреплены набором инвариантов в документе INVARIANTS.md. Один из ключевых, I-01: по умолчанию LLM никогда не получает необработанный результат инструмента. Данные сначала проходят через firewall и превращаются в Frame. Инвариант I-02 требует, чтобы каждый запуск начинался с PolicyDecision и завершался TraceEvent. В I-06 указано, что токены должны иметь ограниченную область действия и быть одноразовыми или истекать по времени. Любая реализация, которая нарушает хотя бы один из инвариантов с I-01 по I-07, считается несовместимой со спецификацией.