010: Агент/План

План — это как карта для путешественника. Когда умная программа (языковая модель) видит эту карту (План) и знает, где она находится сейчас (объект Состояния), она может понять, что делать дальше. Это и делает агента по-настоящему умным и гибким. Он может следовать существующему плану, добавлять в него новые шаги или даже полностью отбросить его и составить новый, если что-то пошло не так. Это позволяет ему действовать как по строгому сценарию, так и свободно импровизировать, исследуя новые пути.

Как формируется План

Связи между шагами в плане создаются не стрелочками, как на бумаге, а с помощью простого, но мощного правила: все обмениваются информацией через специальный «контейнер» — объект Состояния.

• Узлы (вызовы инструментов): Каждый шаг в плане — это «вызов инструмента», то есть какое-то действие, которое нужно выполнить.
• Связи (объект Состояния): Связи между шагами появляются, когда один инструмент записывает результат своей работы в «контейнер» Состояния, а другой читает его оттуда. Один инструмент кладёт результат в определённое место (используя мета-свойство _outputPath). Следующий инструмент может взять этот результат для своей работы, просто заглянув в то же самое место (используя ссылку на переменную).

Так появляется чёткая зависимость: второй инструмент не может начать работу, пока первый не закончит и не оставит свой результат в «контейнере».

Например, план по получению профиля пользователя и его краткому изложению будет состоять из двух вызовов инструментов:

[
  {
    "_tool": "fetchUserProfile",
    "userName": "Alice",
    "_outputPath": "†state.userProfileData"
  },
  {
    "_tool": "summarizeProfile",
    "profile": "†state.userProfileData",
    "_outputPath": "†state.profileSummary"
  }
]

Здесь вызов summarizeProfile (сделать краткий пересказ) зависит от результата fetchUserProfile (получить профиль), что создаёт план из двух шагов. Эту зависимость можно представить в виде простой схемы.

Содержание Плана: Граф потока данных

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

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

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

Хотя содержание Плана может быть мощным инструментом для мозгового штурма, обсуждения и «размышлений вслух», его основное применение в этой системе — определение исполняемых рабочих процессов. Для этой цели мы используем определённый тип графа, называемый Направленным ациклическим графом (DAG), где каждый узел — это вызов инструмента.

У DAG есть несколько ключевых свойств, которые делают его идеальным для выполнения задач:

• Граф: «Граф» — это всё содержимое сообщения Плана: набор всех вызовов инструментов (узлы) и зависимости по данным, которые их соединяют (рёбра).
• Направленный: Связи односторонние, как улица с односторонним движением. Направление определяется потоком данных. Шаг, который создаёт данные, должен идти до шага, который их использует.
• Ациклический: В рабочем процессе не может быть круговых зависимостей (петель). Это гарантирует, что у него есть чёткое начало и конец. Это важнейшая мера безопасности, чтобы языковая модель случайно не создала бесконечный цикл. Система проверяет План на ацикличность перед выполнением.

Разделение планирования и выполнения

Самая мощная особенность этой архитектуры — полное разделение планирования и выполнения. Поскольку План — это просто декларативная структура данных, агент может сгенерировать весь граф вызовов инструментов до того, как будет запущен какой-либо код.

Языковая модель выступает в роли планировщика, составляя массив вызовов, который представляет собой задуманный рабочий процесс. Эту структуру данных затем можно:

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

Выполнением занимается Цикл выполнения, который интерпретирует сообщение Плана и запускает вызовы инструментов в правильном порядке на основе их зависимостей, заполняя объект Состояния по мере продвижения.

План как развивающаяся стратегия

План не статичен; это живая стратегия, которую можно адаптировать на каждом шаге цикла выполнения. Ключевое отличие заключается в том, что Plan — это не просто любой вывод от языковой модели. Когда агент впервые генерирует набор вызовов инструментов, это просто предлагаемая последовательность действий. Она становится настоящим Планом только тогда, когда передаётся как контекстное сообщение в следующий запрос в цикле.

Этот цикл превращает одноразовый вывод в постоянную стратегию:

• Контекст для запроса содержит объект Состояния и сообщение Плана с предыдущего шага.
• Решение, сгенерированное языковой моделью, содержит новый набор вызовов инструментов, который становится новым Планом для следующего шага.

Этот итеративный процесс позволяет агенту быть одновременно проактивным и реактивным. Он может следовать существующему Плану, но также может изменять его в ответ на результаты предыдущего шага. Например, если вызов инструмента завершился неудачно, агент может сгенерировать новый План, включающий шаги по обработке ошибок. Это делает систему устойчивой и адаптируемой.

// Agent.Request(config, schema, context)
{
  "schema": {
    "type": "object",
    "properties": {
      "calls": { "type": "array" },
      "output": {
        "type": "object",
        "nullable": true,
        "properties": {
          "confirmationId": { "type": "string" },
          "message": { "type": "string" }
        }
      }
    }
  },
  "context": [
    {
      "type": "input",
      "request": "Я бы хотел вернуть деньги за последний заказ.",
      "customerId": "cust_123",
      "amount": 50.0
    }
  ]
}

{
  "calls": [
    {
      "_tool": "checkBillingHistory",
      "customerId": "†input.customerId"
    },
    {
      "_tool": "issueRefund",
      "customerId": "†input.customerId",
      "amount": "†input.amount"
    }
  ],
  "output": null
}

[
  {
    "type": "state",
    "billingHistory": {
      "orders": 5,
      "lastChargeback": "2025-09-10"
    }
  },
  {
    "type": "plan",
    "plan": [
      {
        "_tool": "checkBillingHistory",
        "customerId": "†input.customerId"
      },
      {
        "_tool": "issueRefund",
        "customerId": "†input.customerId",
        "amount": "†input.amount"
      }
    ]
  }
]

{
  "calls": [
    {
      "_tool": "issueRefund",
      "customerId": "†input.customerId",
      "amount": "†input.amount"
    }
  ],
  "output": {
    "confirmationId": "refund_xyz789",
    "message": "Возврат был успешно обработан."
  }
}

[
  { type: 'tool', tool: Tool.bookFlight },
  { type: 'tool', tool: Tool.bookHotel },
  { type: 'tool', tool: Tool.findPetFriendlyHotel },
  {
    type: 'plan',
    plan: [
      {
        _tool: 'bookFlight',
        destination: '†input.destination',
      },
      {
        _tool: 'bookHotel',
        destination: '†input.destination',
      },
    ],
  },
  {
    type: 'input',
    destination: 'Berlin',
    instruction: "Кстати, я буду путешествовать со своей собакой.",
  },
];

{
  "calls": [
    {
      "_tool": "bookFlight",
      "destination": "†input.destination"
    },
    {
      "_tool": "findPetFriendlyHotel",
      "destination": "†input.destination"
    }
  ],
  "output": null
}

Agent.Request(config, {
  schema: {
    type: 'object',
    properties: {
      calls: { type: 'array' },
      output: {
        type: 'object',
        nullable: true,
        properties: {
          status: {
            type: 'string',
            enum: ['Success', 'Failed'],
          },
        },
      },
    },
  },
  context: [
    { type: 'tool', tool: 'Tool.processPayment' },
    { type: 'tool', tool: 'Tool.confirmOrder' },
    { type: 'tool', tool: 'Tool.reportFailure' },
    { type: 'input', amount: 50.0 },
  ],
});

{
  "calls": [
    {
      "_tool": "processPayment",
      "amount": "†input.amount",
      "_outputPath": "†state.receipt || †state.error"
    },
    {
      "_tool": "confirmOrder",
      "receipt": "†state.receipt"
    }
  ],
  "output": null
}

[
  {
    "type": "state",
    "error": { "code": "card_declined", "message": "Ваша карта отклонена." }
  },
  // Оригинальный, теперь устаревший план всё ещё в контексте
  {
    "type": "plan",
    "plan": [
      { "_tool": "processPayment", "_outputPath": "†state.receipt || †state.error" },
      { "_tool": "confirmOrder", "receipt": "†state.receipt" }
    ]
  }
]

{
  "calls": [
    {
      "_tool": "reportFailure",
      "error": "†state.error"
    }
  ],
  "output": { "status": "Failed" }
}

[
  { "type": "tool", "tool": "Tool.detectLanguage" },
  { "type": "tool", "tool": "Tool.isEnglish" },
  { "type": "tool", "tool": "Tool.translateText" },
  {
    "type": "input",
    "text": "Bonjour le monde"
  },
  {
    "type": "state",
    "schema": {
      "type": "object",
      "properties": {
        "language": { "type": "string" },
        "isEnglish": { "type": "boolean" },
        "translatedText": { "type": "string" }
      }
    }
  }
]

{
  "calls": [
    {
      "_tool": "detectLanguage",
      "text": "†input.text",
      // Языковая модель знает, что нужно использовать этот путь из схемы.
      "_outputPath": "†state.language"
    },
    {
      "_tool": "isEnglish",
      // Она правильно ссылается на вывод предыдущего шага.
      "language": "†state.language",
      "_outputPath": "†state.isEnglish"
    },
    {
      "_tool": "translateText",
      "text": "†input.text",
      "isEnglish": "†state.isEnglish",
      "_outputPath": "†state.translatedText"
    }
  ],
  "output": null
}

Этот итеративный цикл планирования и выполнения является ядром Процесса. Он представляет собой автономный снимок рабочего процесса, охватывающий доступные Инструменты, текущее Состояние и сам План.

От одного плана к многоразовым рабочим процессам

Сообщение Плана определяет последовательность действий для конкретной задачи. Чтобы сделать эти рабочие процессы по-настояшему мощными, нам нужен способ упаковывать их в многоразовые компоненты, которые можно вызывать из других Планов.

Протокол для такого параллельного выполнения описан в документе 011: Агент/Экземплирование.