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

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

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

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

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

Это устанавливает четкую зависимость: второй Вызов Инструмента не может быть выполнен, пока первый не завершится и не заполнит Состояние.

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

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

Здесь вызов summarizeProfile зависит от результата fetchUserProfile, создавая двухэтапный план. Эту зависимость можно представить в виде простого графа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// 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": "I'd like a refund for my last order.",
      "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": "The refund has been processed successfully."
  }
}

[
  { 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: "Actually, I'll be traveling with my dog.",
  },
];

{
  "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": "Your card was declined." }
  },
  // Исходный, теперь уже устаревший, план все еще находится в контексте
  {
    "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",
      // LLM знает, что нужно использовать этот путь из схемы.
      "_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: Агент/Экземплирование.