Акты Становления

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

Это специальное сообщение-инструкция (с типом kind: "advisor"), которое задаёт агенту определённую роль или модель для анализа. Оно говорит агенту: «Сначала выскажи своё структурированное „мнение“ или оцени уверенность, и только потом выбирай Инструмент или создавай Результат».

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

Хаотичное мышление

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

Из-за этого в его «памяти» накапливается слишком много лишних мыслей. Такое блуждание заставляет агента колебаться, постоянно менять мнения, что снижает точность. Непредсказуемость этого процесса бьёт и по скорости, и по надёжности. К тому же, когда решение основано на сплошном тексте, трудно понять, как взвешивались разные «за» и «против». Абзац общих рассуждений не даёт чётких цифр для сравнения.

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

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

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

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

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

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

Сообщение Советника определяет, под каким углом агент будет смотреть на проблему.

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

Стратегии участия

Свойство on контролирует, когда советник будет участвовать в работе:

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

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

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

Числовые данные, такие как «голоса», кодируются как Встроенный JSON внутри текстового поля. Это позволяет сохранить строгость данных, не усложняя общую схему.

Регистрация Советников

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

Ответ от ИИ

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

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

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

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

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

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

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