П’ятоагентний пункт підтримки на базі Gemini 3.1 та ADK: сортування завдань, дослідження, виконання дій, перевірка якості та координація.

Уявіть замовлення, яке пішло не так. Клієнт пише, що надійшов неправильний товар, просить повернення грошей та також хоче, щоб правильний товар було надіслано того ж дня. За цим одним реченням стоять три завдання: перевірити замовлення, обробити повернення та поспішно надіслати заміну. Кожне з них потребує власних даних, власної політики та власних дій. Одинокий бот підтримки з одним величезним запитом може впоратися з простим запитанням, але починає помилятися, коли кілька завдань переплітаються. Він стає повільним, крихким та схильним до помилок.

Рішенням є багатоагентний підхід: кілька спеціалістів, кожен з яких відповідає за певну частину робочого процесу, та оркестратор, який координує їхню роботу. Далі описано, як створити таку систему на Google Cloud за допомогою моделей Gemini 3.1 та інструментарію Google Agent Development Kit (ADK). У цьому описі розглядається, як визначити ролі агентів із чіткими межами, як оркестратор направляє завдання, делегує їх та об’єднує результати, як агенти передають один одному інформацію, а також, що не менш важливо, коли кращим варіантом залишається один агент.

Що йде не так із одним великим запитом

Уявіть собі агента підтримки, який починав з простих функцій та поступово набував нових можливостей: пошук інформації в базі знань, більш лагідний тон у спілкуванні з незадоволеними клієнтами, можливість самоперевірки. Обсяг його системного запиту перевищує 3 000 токенів, і кожне додавання щось порушує в уже наявній структурі. З’являються чотири симптоми:

• Проблема розсіювання уваги. Правила повернення грошей починають застосовуватися до запитань, які не мають стосунку до повернень, тож простий запит про продукт отримує відповідь, засновану на логіці повернень.
• Розсіяна увага моделі. Увага моделі є обмеженою. Якщо її розподіляти між десятками інструкцій, більшість з яких не стосуються конкретного запиту, кожній з них приділяється менше уваги.
• Неможлива діагностика проблем. Коли відповідь є неправильною, незрозуміло, яка з багатьох інструкцій її спричинила.
• Один шлях для всього. Кожен запит проходить через ту саму послідовність обробки, незалежно від своєї складності.

Розділення роботи дозволяє кожній моделі використовувати всю свою кількість уваги для виконання конкретного завдання. Вона думає про політику повернень лише під час обробки запитів на повернення грошей та про тон лише під час перегляду чернетки.

ADK розроблений на основі цієї ідеї. Його механізм AutoFlow керує передачею завдань між спеціалістами: коли у оркестратора є підагенти, ADK додає інструмент transfer_to_agent() та записує описи кожного доступного спеціаліста у свій контекст. Таким чином оркестратор знає, хто є у його команді та до чого кожен з її членів підходить.

Структура системи

Замість одного запиту центральний оркестратор керує низкою спеціалізованих підагентів. Моделі не обов’язково мають бути ідентичними. Найсильніший аналізатор використовується там, де важливий судження (оркестрація та перевірка якості), а найшвидший та найдешевший — там, де важлива швидкість (тріаж):

• Оркестратор: планує та делегує завдання. Gemini 3.1 Pro. Його інструментами є спеціалізовані агенти.
• Агент для тріажу: аналізує настрої та наміри користувача та спрямовує завдання. Gemini 3.1 Flash-Lite, підтримуваний класифікаторами NLP.

Агент дослідження: збирає факти та контекст. Gemini 3.1 Flash із функціями пошуку Vertex та API CRM.

Агент дій: виконує операції, такі як повернення коштів та оновлення даних. Gemini 3.1 Flash із API для обробки замовлень та оплат.

Агент перевірки якості: перевіряє факти та дотримання правил. Gemini 3.1 Pro із базою знань про правила.

Gemini 2.5 Flash залишається хорошим інструментом для сценаріїв з одним агентом. Однак коли якість міркувань впливає на рішення щодо маршрутизації, моделі серії Gemini 3.1 (які зазвичай доступні з початку 2026 року) підходять краще, особливо для ролей оркестратора та перевірки якості.

Інструменти Google Cloud, які використовуються:

• Моделі Gemini 3.1 як основа для міркувань, налаштовані для використання з інструментами.
• Agent Development Kit як фреймворк для керування передачею завдань через AutoFlow.
• Vertex AI Agent Engine як керований середовище виконання для розгортання та масштабування агентів.
• Firestore як спільний стан сеансу, де агенти читають та записують інформацію про розмову.
• Vertex AI Vector Search для пошуку в базі знань.

Налаштування ADK

ADK забезпечує необхідну інфраструктуру, включаючи механізм передачі, за допомогою якого один агент може ефективно передати дзвінок іншому. Встановлення відбувається за один рядок:

pip install google-adk google-generativeai google-cloud-firestore pydantic

Pydantic вказаний прямо тому, що ADK покладається на нього для схем вхідних та вихідних даних агентів, а зазначення його назви забезпечує сумісність версій.

Структуру проекту варто продумати заздалегідь. Багатоагентні системи найчастіше виходять з ладу через неузгодженості: один агент надсилає refund_id у вигляді цілого числа, тоді як інший очікує рядок. Плоска структура з спільними схемами запобігає таким типам помилок:

support_agents/
├── main.py              # Entry point for Cloud Run
├── common/
│   ├── __init__.py
│   └── schemas.py       # Shared Pydantic models (the "handshake")
├── agents/
│   ├── __init__.py
│   ├── orchestrator.py
│   ├── triage.py
│   ├── research.py
│   ├── action.py
│   └── qa.py
└── config.py            # Environment & project IDs

Лікарня є доречною аналогією. Оркеструвальником є медбрат з триажу, агентом дослідження — лаборант, а агентом дії — хірург. Жоден з них не спілкується з пацієнтом одночасно. Вони читають та оновлюють медичну картку пацієнта, якою тут є Firestore, а schemas.py — це формат картки, щодо якого всі домовлені.

Агент триажу

Триаж виконує функцію контролю повітряного руху. Він сам нічого не вирішує, а лише переконується, що кожен запит потрапляє до правильного спеціаліста з належним пріоритетом.

Передача необроблених рядків між агентами може призвести до проблем. Сувора схема Pydantic означає, що оркеструвальник отримує перевірений об’єкт Python та ніколи не мусить аналізувати вільний текст. Схема має бути на першому місці:

# common/schemas.py
from pydantic import BaseModel, Field

class TriageResult(BaseModel):
    intents: list[str] = Field(description="List of detected customer goals")
    urgency: str = Field(pattern="^(low|medium|high|critical)quot;)
    sentiment: str = Field(description="Current emotional state of the user")
    required_agents: list[str] = Field(
        description="List of sub-agents needed (research, action, etc.)"
    )

Потім агент, який його створює:

# agents/triage.py
from google.adk.agents import LlmAgent
from common.schemas import TriageResult

triage_agent = LlmAgent(
    name="triage_agent",
    model="gemini-3.1-flash-lite",  # Fast and cheap for classification
    instruction="""You are a triage specialist. Analyze the customer's
    message and categorize it accurately.

    Urgency rules:
    - critical: Active outages or safety threats
    - high: Frustrated users or financial issues > $100
    - medium: Standard requests needing action
    - low: General info/feedback

    You must NOT attempt to solve the problem. Only classify it.""",
    output_schema=TriageResult,  # Force structured JSON output
    output_key="triage_data"
)

У цьому визначенні важливі чотири фактори дизайну:

• Одна функція. Агент ніколи не відповідає на запитання чи не виконує дій, лише класифікує. Це забезпечує короткі запити та високу точність.
• Структурований вихідний формат. output_schema змушує створювати коректний JSON, що відповідає TriageResult, а ADK автоматично перевіряє його за допомогою Pydantic.
• Кілька намірів одночасно. Оскільки intents — це список рядків, повідомлення з проханням оновити адресу та перевірити останню рахунок працює, на відміну від класифікатора з одним мітком, який би в цьому випадку зазнав невдачі.
• Передача стану. output_key="triage_data" зберігає результат у стані сеансу, тож оркестратор читає його з session.state['triage_data'].

Дослідницький агент

Агент дослідження — це слідчий. Він отримує необроблені дані з Firestore та каналу отримання даних, а потім узагальнює їх у структурований звіт для агента дії. Схема цього звіту є угодою між цими двома ролями:

# common/schemas.py (add to existing file)

class ResearchBrief(BaseModel):
    order_status: str = Field(description="Current order state")
    customer_tier: str = Field(description="e.g. Gold, Standard")
    applicable_policy: str = Field(description="Relevant policy text")
    can_refund: bool = Field(description="Whether a refund is allowed")
    reasoning: str = Field(description="Why this conclusion was reached")

Далі йдуть його інструменти та визначення агента:

# agents/research.py
from google.adk.agents import LlmAgent
from google.cloud import firestore
from common.schemas import ResearchBrief

db = firestore.Client()

def lookup_order(order_id: str) -> dict:
    """Fetch real-time shipping status and line items for an order ID."""
    doc = db.collection('orders').document(order_id).get()
    if doc.exists:
        return doc.to_dict()
    return {"error": f"Order {order_id} not found"}

def lookup_customer(customer_id: str) -> dict:
    """Retrieve customer profile, tier, and interaction history."""
    doc = db.collection('customers').document(customer_id).get()
    if doc.exists:
        return doc.to_dict()
    return {"error": f"Customer {customer_id} not found"}

def search_knowledge_base(query: str) -> list:
    """Search product docs and company policies via RAG pipeline."""
    # Uses the RAG pipeline from our previous article
    from rag_pipeline import pipeline
    result = pipeline.query(query, top_k=5)
    return result['sources']

research_agent = LlmAgent(
    name="research_agent",
    model="gemini-3.1-flash",
    instruction="""You are a research specialist.
    1. Extract identifiers (Order ID, Customer ID) from the triage data.
    2. Use tools to gather order history and relevant company policies.
    3. If policy info is missing, use search_knowledge_base.

    CRITICAL: Do not answer the customer. Output a formal ResearchBrief.""",
    tools=[lookup_order, lookup_customer, search_knowledge_base],
    output_schema=ResearchBrief,
    output_key="research_brief"
)

Державні системи працюють без додаткового коду. Коли запускається агент дослідження, ADK вставляє triage_data з попереднього кроку у свій контекст, тож він вже знає, що має шукати інформацію за номером 12345, оскільки процедура триажу визначила таку мету. Кожен агент будує на роботі попереднього та нічого не виконується двічі. Один короткий порада з експлуатації: ADK автоматично обгортає звичайні функції у об’єкти FunctionTool, але їхнє явне обгортання за допомогою from google.adk.tools import FunctionTool забезпечує кращий моніторинг затримок та журналування використання токенів у Vertex AI Agent Engine.

Агент дій

Лише цей спеціаліст має право на запис до бізнес-API. Оскільки він виконує операції з високим ризиком, для нього передбачені суворі схеми та чіткі обмеження. Спочатку — схема вихідних даних:

# common/schemas.py (add to existing file)

class ActionSummary(BaseModel):
    actions_taken: list[str] = Field(description="List of actions executed")
    refund_id: str | None = Field(default=None, description="Refund ID if issued")
    escalated: bool = Field(default=False)
    escalation_reason: str | None = Field(default=None)

Потім сам агент, який вимагає підтвердження від людини для операцій з високою вартістю:

# agents/action.py
from google.adk.agents import LlmAgent
from google.adk.tools import FunctionTool
from common.schemas import ResearchBrief, ActionSummary

def process_refund(order_id: str, amount: float, reason: str) -> dict:
    """Process a financial refund. Required: valid order_id and amount."""
    # In production: call your payment API
    return {
        "status": "processed",
        "refund_id": f"REF-{order_id}",
        "amount": amount
    }

def create_replacement_order(
    order_id: str,
    item_id: str,
    shipping_speed: str
) -> dict:
    """Create a replacement order with specified shipping speed."""
    # In production: call your order management API
    return {
        "status": "created",
        "new_order_id": f"REPL-{order_id}",
        "estimated_delivery": "2 business days"
    }

def escalate_to_human(reason: str, priority: str) -> dict:
    """Escalate to a human agent with full context."""
    return {
        "status": "escalated",
        "queue": "priority" if priority == "high" else "standard"
    }

# Wrap refund tool with human confirmation for high-value transactions
refund_tool = FunctionTool(
    func=process_refund,
    require_confirmation=True  # Pauses for human approval before executing
)

action_agent = LlmAgent(
    name="action_agent",
    model="gemini-3.1-flash",
    instruction="""You are an action specialist.
    Review the 'research_brief' in the session state.

    CRITICAL RULES:
    1. Only refund if 'can_refund' is True in the research brief
    2. If amount > $500, you MUST use escalate_to_human
    3. You must call tools for every action — do not just tell the user
       it happened
    4. If information is missing from the brief, escalate""",
    tools=[refund_tool, create_replacement_order, escalate_to_human],
    input_schema=ResearchBrief,   # Only sees research data, not raw chat
    output_schema=ActionSummary,
    output_key="action_result"
)

Два параметри забезпечують основну частину безпеки. Параметр require_confirmation існує тому, що продакшн-системи рідко дозволяють агенту здійснити повернення коштів лише на основі простих інструкцій. Механізм підтвердження в інструменті ADK зупиняє виконання дій до моменту схвалення людиною, а оркестратор бачить статус „у процесі“, який може направити на панель керування персоналу. Параметр input_schema має важливе значення, адже без нього агент бачить усю розмову, включаючи застарілі повідомлення. Обмеження вхідних даних до формату ResearchBrief запобігає потраплянню застарілого контексту та забезпечує прийняття рішень на основі найсвіжіших даних.

Також варто зазначити, що параметр escalate_to_human є свідомим бізнес-правилом, а не станом збою. Оркестратор може точно бачити, чому агент зупинився, та надіслати заявку людині разом із повним описом дослідження.

Агент QA

QA — це останній етап перевірки. Окрім перевірки формулювань, він порівнює те, що зробив агент дій, із тим, що було зазначено у поясненні до дослідження, щоб дії відповідали знанням.

Ця функція працює на Gemini 3.1 Pro, оскільки їй потрібно пам’ятати весь стан розмови та виявляти тонкі суперечності — у цих завданнях Pro постійно перевершує Flash. ADK також дозволяє їй використовувати режим мислення для глибшого самоаналізу перед схваленням відповіді. Схема перевірки:

# common/schemas.py (add to existing file)

class QAReview(BaseModel):
    is_approved: bool = Field(description="True if the response meets all criteria")
    feedback: str = Field(description="Specific corrections if not approved")
    final_text: str = Field(description="The customer-facing message")

А конфігурація агента:

# agents/qa.py
from google.adk.agents import LlmAgent
from google.adk.planners import BuiltInPlanner
from google.genai.types import ThinkingConfig
from common.schemas import QAReview

qa_agent = LlmAgent(
    name="qa_agent",
    model="gemini-3.1-pro",
    instruction="""You are a senior QA auditor. Compare the 'action_result'
    against the 'research_brief' in the session state.

    CRITICAL CHECKS:
    1. Did the Action Agent refund the EXACT amount listed in the brief?
    2. Does the response cite the policy found during research?
    3. Is the tone empathetic but professional?
    4. Are ALL intents from the triage classification addressed?
    5. No unauthorized promises, discounts, or policy exceptions

    If any check fails, set is_approved to False with specific feedback.""",
    output_schema=QAReview,
    output_key="qa_review",
    # MEDIUM for routine QA; switch to HIGH for edge cases or audits
    planner=BuiltInPlanner(
        thinking_config=ThinkingConfig(thinking_level="MEDIUM")
    )
)

Відхилення не завершує процес. Коли значення qa_review.is_approved дорівнює false, оркестратор читає поле feedback та направляє повідомлення назад до відповідного агента з конкретними корекціями. Саме цей цикл корекцій відрізняє продакшн-агента від демонстраційного скрипту. Він обмежений двома циклами корекцій, після чого справа передається людині.

Оркестратор

Оркестратор не здійснює досліджень та не виконує дій. Він керує станом та стежить за тим, щоб спеціалісти працювали у логічному порядку. За наявності sub_agents система AutoFlow від ADK додає інструмент transfer_to_agent(), а ШІ оркестратора обирає наступного спеціаліста на основі своїх інструкцій та поточного стану сеансу:

# agents/orchestrator.py
from google.adk.agents import LlmAgent
from agents.triage import triage_agent
from agents.research import research_agent
from agents.action import action_agent
from agents.qa import qa_agent

orchestrator = LlmAgent(
    name="support_orchestrator",
    model="gemini-3.1-pro",  # Best reasoning for delegation decisions
    instruction="""You are the lead coordinator of a customer support team.
    Use the following specialists in order:
    1. triage_agent: to classify the intent and urgency
    2. research_agent: to gather order data and relevant policies
    3. action_agent: to execute the required operations
    4. qa_agent: to verify the final response

    Special cases:
    - If triage classifies as 'critical': bypass the chain and escalate
    - If QA returns is_approved=False: re-route to the responsible agent
      with the feedback (maximum 2 revision cycles, then escalate)
    - If any agent fails: escalate to human with full context

    You must never respond to the customer directly.
    Always route through the specialist pipeline.""",
    sub_agents=[triage_agent, research_agent, action_agent, qa_agent]
)

Запуск

ADK виконує агентів за допомогою Runner, який призупиняє виконання, коли агент викликає інструмент, а потім знову запускає агента після отримання результату:

# main.py
from google.adk.runners import Runner
from google.adk.sessions import InMemorySessionService
from agents.orchestrator import orchestrator

APP_NAME = "customer_support"
USER_ID = "system"

# For production, replace with a Firestore-backed session service
session_service = InMemorySessionService()

runner = Runner(
    agent=orchestrator,
    app_name=APP_NAME,
    session_service=session_service
)

async def handle_customer_message(customer_id: str, message: str):
    """
    Entry point for customer messages.
    """
    session_id = f"support-{customer_id}"

    # Ensure session exists
    session = await session_service.get_session(
        app_name=APP_NAME, user_id=USER_ID, session_id=session_id
    )
    if not session:
        session = await session_service.create_session(
            app_name=APP_NAME, user_id=USER_ID, session_id=session_id
        )

    # run_async yields events as agents execute
    final_response = None
    async for event in runner.run_async(
        user_id=USER_ID,
        session_id=session_id,
        new_message=message
    ):
        if event.is_final_response():
            final_response = event

    return {
        "response": final_response.content.parts[0].text if final_response else None,
        "session_id": session_id
    }

Чому б не зателефонувати агентам безпосередньо? Runner керує всім процесом. Він зберігає сеанси, відстежує активного агента, обробляє виклики інструментів та фіксує кожен крок. Оскільки кожен агент записує свої результати під output_key, Runner гарантує наявність необхідної інформації, коли її потребує виконавчий агент, без необхідності ручного написання додаткового коду. Прозорість також забезпечується автоматично: кожен виклик агента, використання інструменту та передача даних фіксуються як події, що допомагає у вирішенні проблем під час дебаггінгу. Якщо щось піде не так, сліди дозволяють зрозуміти, який агент прийняв яке рішення та чому.

Шляхи розгортання

Існує два способи розгортання. Vertex AI Agent Engine пропонує керований середовище виконання, яке майже не потребує обслуговування, тоді як Cloud Run надає повний контроль над контейнером.

Agent Engine

Це варіант з мінімальним обслуговуванням, рекомендований для більшості сценаріїв, створених за допомогою ADK. Необхідно встановити дві змінні:

PROJECT_ID=your-project-id
LOCATION_ID=us-central1

Потім розгорніть за допомогою одного команди:

adk deploy agent_engine \
  --project=$PROJECT_ID \
  --region=$LOCATION_ID \
  --display_name="Customer Support Team" \
  support_agents

Agent Engine забезпечує масштабування, зберігання сеансів та облік дій агентів у журналах. Не потрібні Dockerfile, код сеансів чи інфраструктура для обслуговування.

Cloud Run

Оберіть цей варіант, коли потрібні користувацькі бібліотеки системи, специфічні мережеві функції, такі як VPC Service Controls, або компоненти, що не належать до ADK. У прикладі використовується Quart замість Flask. Синтаксис майже ідентичний, але Quart нативно підтримує async/await, що уникає антипаттерну asyncio.run(), який передбачає створення нового циклу подій для кожного запиту:

# server.py
from quart import Quart, request, jsonify
from main import handle_customer_message

app = Quart(__name__)

@app.route("/support", methods=["POST"])
async def support():
    data = await request.get_json()
    # No asyncio.run needed — Quart handles the event loop
    result = await handle_customer_message(
        data["customer_id"],
        data["message"]
    )
    return jsonify(result)

@app.route("/health", methods=["GET"])
async def health():
    return jsonify({"status": "healthy"})

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Визначення контейнера:

# Dockerfile
FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
EXPOSE 8080

CMD ["python", "server.py"]

А команда розгортання:

gcloud run deploy support-agents \
  --source . \
  --region us-central1 \
  --memory 4Gi \
  --cpu 2 \
  --allow-unauthenticated

Коротко кажучи, Cloud Run вимагає середніх зусиль для налаштування (Dockerfile та API), потребує ручного керування станом за допомогою Firestore або Redis, записує логи у стандартний Cloud Logging та підходить для користування з власними середовищами виконання та фреймворками. Agent Engine працює за однією командою, має вбудовані сесії, створює трекування специфічне для агента та підходить для агентів ADK, яким потрібна швидка масштабуваність.

Збереження розмов

У прикладі оркестратора використовувався InMemorySessionService, який підходить для тестування, але втрачає всю інформацію після перезапуску процесу. У продакшені потрібен надійний сервіс. ADK пропонує два таких варіанти.

З Agent Engine обробка сесій здійснюється автоматично через сервіс сесій Vertex AI:

# config.py
from google.adk.sessions import VertexAiSessionService

session_service = VertexAiSessionService(
    project="your-project-id",
    location="us-central1",
    agent_engine_id="your-agent-engine-id"  # From adk deploy output
)

Agent Engine також узагальнює довгі історії та сам очищує залишки, тому код Firestore не потрібен.

Для Cloud Run DatabaseSessionService працює з бекендом PostgreSQL або SQLite:

# config.py
from google.adk.sessions import DatabaseSessionService

# PostgreSQL for production
session_service = DatabaseSessionService(
    db_url="postgresql+asyncpg://user:pass@host:5432/agents"
)

# Or SQLite for development
session_service = DatabaseSessionService(
    db_url="sqlite+aiosqlite:///sessions.db"
)

Він створює свої таблиці під час першого запуску. Якщо перемістити його до Runner, стан сесії зберігатиметься після перезапуску.

Як стан передається між агентами

Не потрібні жодні ручні виклики get() та set(). output_key кожного агента автоматично записує дані у стан сесії, а наступні агенти читають їх звідти:

triage_agent (output_key="triage_data")
    ↓ writes to session.state["triage_data"]
research_agent (reads triage_data, output_key="research_brief")
    ↓ writes to session.state["research_brief"]
action_agent (input_schema=ResearchBrief, output_key="action_result")
    ↓ writes to session.state["action_result"]
qa_agent (reads action_result + research_brief, output_key="qa_review")

The Runner зберігає весь цей стан у будь-якому налаштованому бекенді – чи то Firestore, PostgreSQL, чи Agent Engine.

Три звички допомагають підтримувати здоров’я пам’яті:

• Узагальнюйте. Зберігайте стислі результати замість сирих відповідей API, інакше вікно контексту заповниться зайвими даними.
• Встановлюйте термін дії сеансів. Сеанси, які підтримуються, повинні мати термін дії від 24 до 48 годин, що допомагає зберігати базу даних компактною та безпечною.
• Захищайте персональні дані. Сирі персональні дані, такі як номери національних ідентифікаторів чи паролі, не мають місця у спільному стані, тож їх слід маскувати перед записом у сеанс.

Коли один агент все ще є кращим варіантом

Багатоагентна система не є автоматично кращою. Практичний спосіб прийняття рішення:

• Просте FAQ або перевірка статусу: один агент. Мінімальна затримка та витрати, не потрібні складні міркування.
• Збагачення даних за допомогою трьох–п’яти пошуків: один агент. Одне запитання до LLM достатнє для базового використання інструментів.
• Регульовані робочі процеси: багатоагентний підхід. Ізоляція забезпечує розділення логіки дій від вхідних даних користувача, що обмежує можливості введення шкідливого коду.
• Неоднозначне спрямування дій: багатоагентний підхід. Спеціалізований агент для сортування завдань, який займається визначенням наміру користувача, зменшує кількість помилок.
• Дії високого ризику на суму понад 500 доларів: багатоагентний підхід. Дозволяє провести подвійну перевірку за допомогою агента QA перед використанням будь-якого API.
• Вимоги до аудиту: багатоагентний підхід. Вхідні та вихідні дані кожного агента записуються окремо.

Орієнтовне правило: коли кількість токенів у запиті до одного агента наближається до 3 000, тобто настає момент, коли з’являються проблеми з обмеженнями та розсіяністю уваги, або коли різні частини робочого процесу потребують різних інструментів, настав час його розділити.

Поширені пастки

• Агент, який робить усе. Продуктивність падає, коли один агент володіє десятьма чи більше інструментами, оскільки моделі починають витрачати зусилля на вибір інструменту замість того, щоб зрозуміти запит. Розділіть його за функціями: агент, якому потрібні інструменти для повернення грошей, доставки та юридичних питань, стане трьома спеціалістами.
• Неконтрольований контекст. Якщо кожен агент бачить повний чат з десяти розмов, витрати на токени стрімко зростають. Скомпактуйте стан, щоб процес сортування передавав лише виявлену мету, а не всю розмову.

Нескінченна передача завдань. Агент A надсилає їх агенту B, який у свою чергу повертає їх A, тим самим витрачаючи ресурси у безкінечному циклі. Необхідно встановити максимальну кількість передач завдань; два цикли до звернення до людини є оптимальним терміном.

Розмиті межі обов’язків. Два агенти беруть на себе одне й те саме завдання або завдання залишається між ними. Слід чітко визначити контракти input_schema та output_schema без перекриття обов’язків.

Ігнорування затримок. У послідовному підході додається 4–6 секунд, тоді як у одного агента цей показник становить 1–2 секунди. Механізм ParallelAgent в ADK дозволяє розподіляти завдання між кількома агентами, що може скоротити загальну затримку на 30–40% шляхом одночасного виконання досліджень та перевірок.

Що можна очікувати

Багатоагентні системи жертвують часом виконання заради надійності у складних завданнях. Опубліковані тестування та досвід галузі підтверджують ці переваги:

• Точність при виконанні складних завдань. Розбиття багатоетапних проблем на конкретні підзавдання зазвичай дає кращі результати, ніж використання єдиного комплексного запиту, а документація ADK свідчить про вищі показники завершення завдань, коли у агентів є чітко визначені обов’язки.
• Обмежені наслідки збоїв. Якщо один з компонентів не працює, пошкодження залишається лише в межах цього агента та не псує всю відповідь.
• Можливість аудиту. Окремі журнали для кожного агента полегшують відлов помилок та перевірку дотримання правил.

Витрати також є реальними:

• Затримка. Повний процес із п’ятьма агентами займає приблизно 3–8 секунд, тоді як для одного агента цей час становить 1–2 секунди. Основною перешкодою є послідовні виклики.

Витрати на API. П’ятеро агентів (оркестратор та чотири спеціалісти) коштують приблизно в чотири-п’ять разів більше, ніж один агент за запит, хоча використання комбінації моделей допомагає контролювати ці витрати. Сортування даних за допомогою Flash-Lite коштує 0,25 долара за мільйон токенів вхідних даних, а версія Pro за 2 долари за мільйон призначена для оркестрації та перевірки якості; це дозволяє тримати загальну вартість однієї взаємодії нижче одного цента.

Токени для обробки інформації. Режим розширеної обробки інформації у версії Pro (thinking_level="HIGH") може додати близько 20 тисяч токенів, за які стягується плата у розмірі 12 доларів за мільйон токенів вихідних даних. Таким чином, одна глибока перевірка якості коштує приблизно 0,24 долара лише на обробку інформації. Використовуйте режим HIGH лише у вибіркових випадках, адже для більшості перевірок достатньо режиму MEDIUM.

Складність. Потрібно стежити за більшою кількістю елементів. Це доцільно для складних робочих процесів, але зайве для простих.

Для орієнтовного щомісячного рахунку за 100 000 складних запитів:

• Маршрутизація через Orchestrator у Gemini 3.1 Pro: близько 80 доларів
• Обробка запитів за допомогою Flash-Lite: близько 20 доларів
• Дослідження функціоналу Flash: близько 40 доларів
• Використання Flash: близько 40 доларів
• Перевірка якості з рівнем обробки MEDIUM у версії Pro: близько 100 доларів
• Cloud Run з 2 vCPU та 2 GiB пам’яті: близько 120 доларів
• Сесії PostgreSQL: близько 30 доларів
• Пошук векторів у режимі спільного використання з одним агентом: близько 100 доларів
• Загалом: близько 530 доларів на місяць

Справжнім фактором контролю витрат є поєднання моделей. Лише близько 30% запитів (оркестрація та перевірка якості) оплачуються за тарифом Pro, тоді як решта виконується за допомогою Flash чи Flash-Lite за ціною від однієї восьмої до однієї п’ятдесятої від ціни за токен. Вартість однієї складної взаємодії становить приблизно пів цента. Ці цифри базуються на оприлюднених тарифах Google Cloud, причому фактичні рахунки змінюються залежно від складності запиту, рівня обробки та глибини взаємодії з агентом.

Порядок впровадження

Розумна послідовність — почати з одного агента, налаштувати його логіку, забезпечити підтримку через пошук інформації, а розділяти на спеціалістів — лише тоді, коли запит системи стає занадто довгим або завдання настільки різноманітними, що одна модель не може їх надійно обробити. Кожен шар ґрунтується на тому, що знаходиться нижче.

Момент використання мікросервісів для агентів

Дизайн з кількома агентами не робить ШІ складнішим. Він робить складні робочі процеси прогнозованими, подібно до того, як мікросервіси замінили моноліти: один запит перетворюється на розподілений набір елементів, кожен з яких виконує певну функцію. Прохати одного агента водночас сортувати інформацію, проводити дослідження, діяти та перевіряти результати — це все одно, що просити одну людину водночас бути рецепціоністом, головним аналітиком, техніком та аудитором. Це можливо в компанії з одним працівником, але не спрацює в великому підприємстві.

Надайте кожному агенту чітко визначене завдання, спеціалізовані інструменти та спільний шар пам’яті — результат буде точним, адже чіткі інструкції зменшують відхилення під час виконання непов’язаних завдань; систему можна буде виправляти, оскільки проблеми конкретного спеціаліста є видимими; крім того, це буде дешево, адже використання п’яти агентів у Gemini 3.1 коштує приблизно пів цента за кожну складну взаємодію, що значно менше, ніж хвилина роботи людського агента.

Ця конструкція також має можливості для розвитку. Завдяки протоколу Agent-to-Agent (A2A), відкритому стандарту, яким керує Linux Foundation, подібна система з часом зможе вести переговори з агентами, які працюють у постачальників чи партнерів, наприклад, коли агент підтримки спілкується безпосередньо з агентом перевізника для вирішення проблеми з загубленим посилкою без участі людини.

Наразі порада проста: спочатку створіть одного агента, а потім розділіть його функції, якщо інструкції стануть занадто довгими чи завдання — занадто різноманітними.