017: Агент/Советник

Протокол Советника реализует архитектуру по принципу «сначала обдумай, потом действуй». Регистрируя Советников, агент оценивает контекст через определенные стратегические «линзы» — например, «Архитектор Безопасности» или «Менеджер Продукта» — прежде чем совершить Действие.

Ненаправленное мышление

Неструктурированные рассуждения (например, цепочка мыслей) часто хаотичны. Агенты блуждают без карты, смешивая сбор информации, рассуждения и принятие решений в один «шумный» вывод.

Такое отсутствие структуры перегружает контекст избыточными рассуждениями. Ненаправленное обдумывание заставляет агента колебаться, что приводит к смене мнений и снижению точности. Непредсказуемость этого процесса ухудшает и скорость, и надежность. Более того, решения, основанные на неструктурированном тексте, трудно согласовать; абзац общих рассуждений не дает количественных ориентиров для балансировки конкурирующих приоритетов.

Протокол Советника формализует часть процесса рассуждения для решения этих проблем. Он структурирует оценку, делая её предсказуемой и точной. Эта структура также улучшает пользовательский опыт. Вместо того чтобы скрывать «стены текста», система может представлять структурированные, взвешенные выводы, которые четко показывают расхождения во мнениях, сильные предпочтения и конкретные рекомендации. Это создает лучшую среду для принятия решений и значительно улучшает отчетность.

Протокол Советника не заменяет скрытое рассуждение, а структурирует его определенную часть. Он фиксирует процесс оценки в виде осязаемого артефакта — взвешенного мнения, — которое служит прямым входом для принятия решений.

Разные точки зрения и взвешивание инструментов

Регистрируя нескольких Советников, система заставляет агента оценивать ситуацию с конкурирующих точек зрения (например, «Риск» против «Возможности»). Это расхождение фиксируется через Взвешенный Выбор Инструментов, где Советники выдают явные «вызовы» или оценки уверенности для конкретных Инструментов.

Агент агрегирует эти взвешенные голоса от своего «совета». Он не просто «выбирает» инструмент, а согласовывает вектор различных мнений для достижения консенсуса. Активация инструмента становится взвешенным решением на основе конкурирующих советов.

Сообщение советника

Сообщение Советника определяет «линзу», через которую агент смотрит на проблему.

• id: Уникальный идентификатор советника (например, "securityArchitect").
• role: Описание области знаний и точки зрения советника.
• schema: JSON Schema, определяющая структуру совета. Это позволяет получать конкретные количественные данные (например, оценки риска, бюджетные сметы) или структурные значения, выходящие за рамки стандартного голосования за инструменты.
• on: Определяет стратегию участия.
• scopes: Массив ключей контекста (например, ["input", "state"]), которые фокусируют анализ советника.
• isInstanced: Булевый флаг (по умолчанию false). Если true, определение советника включает свойство _instance, обеспечивая индивидуальную консультацию для каждого экземпляра в пакете.

Стратегии исполнения

Свойство on управляет участием:

• start (Начальное): Высказывает мнение только в начале диалога для задания направления.
• finish (Остановка): Консультируется при определении необходимости остановить цикл.
• request (Непрерывное): Предоставляет мнение в начале, в конце и на каждой итерации. Идеально для мониторов безопасности или ключевых стратегических советников.
• null / undefined (По требованию): Молчит, пока не будет вызван явно. Система предоставляет мета-инструмент ConsultAdvisor, позволяющий LLM вызывать этих советников по требованию в неоднозначных ситуациях.

Порядок консультирования

Когда Советники активны, LLM генерирует их структурированный вывод в первую очередь, в том же окне генерации. LLM принимает на себя роли советников для анализа состояния или голосования за действия. Затем Агент немедленно использует этот вывод для принятия окончательного решения о том, какой Инструмент вызвать.

Количественные данные, такие как «вызовы» (calls), кодируются как встроенный JSON в строковом поле, чтобы избежать разрастания схемы, сохраняя при этом строгость.

[
  {
    "type": "advisor",
    "id": "riskAnalyst",
    "on": "request",
    "scopes": ["†state.deploymentHistory"],
    "role": "Анализировать риски и голосовать за действия по развертыванию.",
    "schema": {
      "type": "object",
      "properties": {
        "thought": { "type": "string", "description": "Оценка риска развертывания." }
      },
      "required": ["thought"]
    }
  }
]

{
  "advisors": [
    {
      "id": "riskAnalyst",
      "thought": "Новая функция прошла юнит-тесты, но интеграционные тесты отсутствуют. Высок риск регрессии.",
      "calls": "{\"deploy\": 10, \"rollback\": 5, \"delay\": 95}"
    }
  ],
  "calls": [
    {
      "_tool": "delay",
      "_reasoningForCall": "Аналитик рисков настоятельно рекомендует отложить из-за недостаточного тестирования."
    }
  ]
}

Взаимодействие с другими системами

• • 002: Агент/Инструмент

  Инструмент: Советники не выполняют действия, а голосуют за них. Возможность advisors структурно похожа на вызов инструмента в схеме вывода, но она представляет собой мета-действие — «мыслительный процесс», — которое строго предшествует выполнению любого реального Инструмента. Такое разделение гарантирует, что совет будет получен до принятия обязательств.

• • 010: Агент/Цикл

  Цикл: Свойство on интегрирует советников в жизненный цикл агента. Советники с on: request действуют как постоянные мониторы, работающие на каждом «тике» цикла. Те, что с on: null (по требованию), служат предохранительными клапанами, которые можно вызвать, когда агент сталкивается с неоднозначностью или трудными решениями во время выполнения.

• • 012: Агент/План

  План: Советы важны на этапе планирования. Консультируясь с советниками с on: start или on: request, агент может согласовать свою начальную стратегию и последующие шаги с консенсусом специализированных персон, обеспечивая, чтобы План был надежным и хорошо продуманным с самого начала.

• • 013: Агент/Экземплирование

  Экземплирование: Советники поддерживают пакетное выполнение. Установив isInstanced: true, советник начинает учитывать экземпляры. Система будет генерировать советы, специфичные для каждого контекста (идентифицированного по _instance), гарантируя, что каждый элемент в пакете оценивается советником индивидуально.

• • 015: Агент/ОбластиВидимости

  ОбластиВидимости: Свойство scopes в сообщении Советника позволяет сфокусировать его внимание. В отличие от строгой изоляции данных, наблюдаемой у Делегатов, здесь области видимости действуют как мягкие указания. Они предписывают конкретной персоне-советнику приоритизировать анализ перечисленных ключей контекста (например, ["†state.deploymentHistory"]), обеспечивая «разделение ответственности» на этапе консультирования, не блокируя доступ к более широкому контексту.