2026-01-31 · Обновлено 2026-07-14

[!NOTE] Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

ИИ-агент Ризонинг Циклы в 2026 году: ReAct против ReWOO против подхода «планирование и выполнение»

Часть 1 серии «Инженерия стека Агентный»

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

В данной статье проводится сравнение трех паттернов AI агентный цикл, которые имеют важное значение в 2026 году: ReAct, ReWOO и Plan-and-Execute. В качестве примера используется агент-аналитик рынка, разработанный мной в LangGraph; полный исходный код доступен на GitHub.

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

Кратко: ReAct обладает высокой гибкостью, но стоит дорого; ReWOO работает быстро в случае предсказуемых рабочих процессов, а подход Plan-and-Execute подходит для многократного анализа. Продакшн-ИИ-агент может переключаться между циклами ризонинг по одному запросу, используя общее состояние и узлы LangGraph с сохранением состояния на этапах выполнения, чтобы каждая задача получала цикл, соответствующий её структуре.

Цикл отвечает за контроль затрат, латентность, и процесс восстановления

Для эффективной работы агента недостаточно просто качественного промпт. Его граф управления должен обеспечивать связь между ризонинг, инструментами и памятью при одновременном урегулировании ситуаций с сбоями.

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

Три шаблона ИИ-агент ризонинг

ReAct: анализируем, выполняем действия, отслеживаем результаты, повторяем процесс

ReAct Модель (Yao et al., 2022) является исходной реализацией интерактивных агентов. Она работает по циклу:

1. Мышление: агент генерирует «мысль» для разбиения цели и планирования следующего шага.
2. Действие: на основе этой мысли он вызывает соответствующий инструмент.
3. Наблюдение: агент анализирует полученный результат, что позволяет обновить его представление перед формированием новой мысли.

Преимущества:

• Граундинг в реальных наблюдениях снижает количество вымышленных фактов.
• Агент может динамически менять стратегию в зависимости от только что полученной информации.
• История вызовов инструментов и наблюдений позволяет получить конкретную картину трейс выполнения задачи.

Недостатки:

• История вычислений накапливается и перепроцессируется на каждом шаге, поэтому объём латентность и связанные с ним затраты растут пропорционально длине цикла.
• Это неэффективно, так как tool calls можно было запланировать заранее, и именно эту нишу и покрывает технология ReWOO.
• В отсутствие условия остановки или лимита на количество шагов цикл будет выполняться бесконечно.

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

ReWOO: заранее спланируйте всё

ReWOO Вариант (Ризонинг WithOut Observation) представляет собой более эффективную альтернативу ReAct. Секрет его работы заключается в разделении процесса ризонинг и выполнения инструментов: вместо того чтобы останавливаться для отслеживания каждого действия, ReWOO планирует всю последовательность tool calls за один проход.

1. План: один вызов LLM записывает полный план tool calls с использованием местоимений переменных (#E1, #E2) — для результатов, которые пока ещё не существуют.
2. Worker: процесс, отличный от LLM экзекьютор, который выполняет запланированные инструменты последовательно или параллельно, заполняя места замены.
3. Solver: окончательный вызов LLM обрабатывает собранные данные и формирует итоговый ответ.

Преимущества:

• Количество повторяющихся вызовов модель меньше, чем ReAct, при условии сохранения действительности первоначального плана.
• Значение латентность снижается. Не требуется повторная отправка истории на каждом шаге.
• планировщик можно настраивать независимо, без необходимости использования живой среды.

Недостатки:

• Система становится критически уязвимой при сбоях инструментов; план исходит из предположения, что всё будет работать корректно.
• Требуются предсказуемые рабочие процессы.
• В отсутствие явной логики резервного варианта неисправный план продолжает выполняться.

Идеально подходит для быстрых снапшоты, проверки статуса и работы дашбордов. Для любых сценариев, где поведение инструментов предсказуемо.

Планирование и выполнение: гибридный подход

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

1. Планирование фаза: агент сначала генерирует план, разделяющий задачу на более мелкие подзадачи.
2. Фаза выполнения: затем агент выполняет эти подзадачи.

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

Преимущества:

• Иерархическая структура ризонинг, отражающая способ, которым человек‑эксперт декомпозирует проект.
• Возможна переоценка планирование: вы можете приостановить работу и пересмотреть ситуацию, если результат определённого шага оказался неожиданным.
• Специализация Модель. Реализация планировщик может быть дорогостоящей, тогда как экзекьютор — дешёвой.
• Ограниченная сложность, при этом после каждого шага имеется чёткий чекпоинт.

Недостатки:

• Более высокий латентность по сравнению с ReWOO из-за последовательного выполнения шагов.
• Необходимо управлять большим количеством состояний.
• Чрезмерная сложность для одноразовых запросов.

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

Выбор в зависимости от возможных точек сбоя плана

Эта таблица представляет собой лишь отправную точку, а не результат бенчмарк. Применяйте ReAct в тех случаях, когда каждое наблюдение может повлиять на выбор следующего действия. Метод «Планирование и выполнение» подходит, когда общая задача может быть разложена на части, но отдельные шаги всё равно требуют обратной связи. Метод ReWOO используется, когда зависимости известны до начала выполнения, и сбой входных данных способен прервать последующие вызовы. Перед принятием решения, основываясь исключительно на затратах, необходимо измерить показатели всех трех методов с помощью ваших собственных инструментов латентность, модель, набора задач и политики повторных попыток.

Пример реализации: агент аналитика рынка

Чтобы проиллюстрировать это на практике, я разработал Агент аналитика рынка этот пример использует все три шаблона в одном кодбейсе для решения задачи по исследованию рынка.

Он использует LangGraph для оркестрация. Поскольку все три шаблона используют один и тот же объект состояния, роутер может выбирать, какой из них запустить для каждого запроса:

Определение состояния

Общее состояние хранит всю информацию, необходимую агенту для работы в разных режимах:

class PlanStep(BaseModel):
    """A single step in the research plan."""
    step_number: int
    description: str
    tool_hint: str | None = None
    completed: bool = False
    result: str | None = None

class UserProfile(BaseModel):
    """Structured user context loaded from long-term memory."""
    risk_tolerance: str | None = None
    investment_horizon: str | None = None

class AgentState(BaseModel):
    """Main state for the Market Analyst Agent graph."""

    # Identity and profile context for memory-backed personalization
    user_id: str
    user_profile: UserProfile = Field(default_factory=UserProfile)

    # Message history with LangGraph's add_messages reducer
    messages: Annotated[list, add_messages] = Field(default_factory=list)

    # Execution mode (set by router)
    execution_mode: ExecutionMode | None = None

    # Plan-and-Execute state
    plan: list[PlanStep] = Field(default_factory=list)
    current_step_index: int = 0

    # ReWOO state
    rewoo_plan: list[ReWOOPlanStep] = Field(default_factory=list)

    # Research results
    research_data: ResearchData | None = None

    # HITL output
    draft_report: DraftReport | None = None
    report_approved: bool = False

Шаблон 1: реализация по принципу «планирование и выполнение»

Модель Plan-and-Execute идеально подходит для задач, требующих многократной синтезации. Ключевой момент заключается в разделении процесса формирования планирование и его реализации: сначала создаётся надёжный модель план, а затем используется цикл ReAct для выполнения каждого шага с возможностью react обработки результатов, полученных от инструментов.

Как это соотносится с шаблоном:

1. Одна начальная фаза планирование. Один вызов LLM позволяет получить полный план в виде списка описаний шагов.
2. Вывод, формируемый на основе схемы, который проверяет корректность плана перед его выполнением.
3. Выполнение инструментов ещё не происходит. планировщик лишь определяет, что нужно сделать, но не как это сделать.
4. Шаги, доступные для чтения человеком. Каждый шаг представляет собой текст, который будет интерпретироваться экзекьютор.

# System prompt guides the LLM to think like a research analyst
# creating a strategic plan, not immediate tool calls
PLANNER_SYSTEM_PROMPT = """You are a senior investment research analyst.
Break down stock analysis requests into 4-6 research steps covering:
1. Current price and basic metrics
2. Recent news and announcements
3. Competitor analysis (if relevant)
4. Financial health assessment
5. Risk factors
6. Investment thesis synthesis

Output as JSON with step_number, description, and tool_hint."""

# Schema-Guided Reasoning: Enforce structure with Pydantic
class PlanOutput(BaseModel):
    """Structured output for the planner."""

    steps: list[PlanStep] = Field(description="Research steps to execute")
    ticker: str = Field(description="The stock ticker being analyzed")

def planner_node(state: AgentState) -> dict:
    """Generate a research plan from the user's request.

    This is Phase 1 of Plan-and-Execute: creating the high-level strategy.
    """

    # Use a powerful model for strategic planning
    llm = ChatAnthropic(model="claude-sonnet-4-5-20250929", temperature=0)

    # Ask for a typed plan and validate it before execution.
    # The API can still fail, so production code also handles that exception.
    structured_llm = llm.with_structured_output(PlanOutput)

    # Context from long-term memory personalizes the plan
    profile_context = f"""
User Profile:
- Risk Tolerance: {state.user_profile.risk_tolerance}
- Investment Horizon: {state.user_profile.investment_horizon}
"""

    # Single LLM call creates the complete plan
    result: PlanOutput = structured_llm.invoke([
        SystemMessage(content=PLANNER_SYSTEM_PROMPT + profile_context),
        HumanMessage(content=f"Create a research plan for: {last_user_message}"),
    ])

    # State update: Store the plan and initialize tracking
    return {
        "plan": result.steps,           # The sequential steps to execute
        "current_step_index": 0,        # Start at step 0
        "research_data": ResearchData(ticker=result.ticker),  # Initialize data container
    }

Это llm.with_structured_output(PlanOutput) Эта строка представляет собой Schema-Guided Ризонинг (SGR), что я уже рассматривал ранее. предыдущая публикация. Эта схема позволяет приложению отклонять некорректно структурированные планы ещё до того, как LangGraph начнёт использовать проверенные поля для формирования условных рёбер.

Вариант 2: выполнение ReAct

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

Как соотносится часть ReAct:

1. Итеративная реализация. Один шаг за разом с получением обратной связи от наблюдений.
2. Цикл «мышление — действие — наблюдение» выполняется внутри create_react_agent.
3. Результаты предыдущего шага подаются в качестве контекста для текущего ризонинг.
4. Агент выбирает инструменты на основе описания шага.
5. Он может изменить подход в ходе шага в зависимости от данных, возвращаемых инструментом.

# Tools available for the ReAct agent to choose from
TOOLS = [
    get_stock_snapshot,
    get_price_history,
    search_news,
    search_competitors,
    get_financials,
]

def executor_node(state: AgentState) -> dict:
    """Execute the current step using a ReAct agent.

    This is Phase 2 of Plan-and-Execute: adaptive execution of each planned step.
    Each step runs as a mini ReAct loop until completion.
    """

    # Get the current step from the plan
    current_step = state.plan[state.current_step_index]

    # Build context from what we've learned so far
    # This matters: each step builds on previous observations
    previous_context = ""
    for step in state.plan[:state.current_step_index]:
        if step.result:
            previous_context += f"\nStep {step.step_number}: {step.result}\n"

    # Create a ReAct agent for this step
    # LangGraph's create_react_agent implements the full Thought-Action-Observation loop:
    # 1. Agent generates a "thought" about what tool to call
    # 2. Agent calls the tool ("action")
    # 3. Tool returns result ("observation")
    # 4. Agent decides: call another tool or finish
    react_agent = create_react_agent(
        model=ChatAnthropic(model="claude-sonnet-4-5-20250929"),
        tools=TOOLS,
    )

    # Invoke the ReAct loop for this single step
    # The agent will loop internally until it completes the step
    result = react_agent.invoke({
        "messages": [
            SystemMessage(content=EXECUTOR_SYSTEM_PROMPT),
            HumanMessage(content=f"""Execute Step {current_step.step_number}:
{current_step.description}

Ticker: {state.research_data.ticker}
Previous findings: {previous_context}"""),
        ]
    })

    # Extract the final answer from the ReAct agent's message history
    # The last message contains the synthesis after all tool calls
    updated_plan = list(state.plan)
    updated_plan[state.current_step_index] = PlanStep(
        step_number=current_step.step_number,
        description=current_step.description,
        completed=True,
        result=result["messages"][-1].content,  # Final observation
    )

    # State update: Mark step complete and advance to next
    return {
        "plan": updated_plan,
        "current_step_index": state.current_step_index + 1,
    }

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

Шаблон 3: ReWOO для быстрого снапшоты

Для кратких брифингов ReWOO пропускает процесс взаимодействия с ризонинг и запускает инструменты параллельно. планировщик заранее генерирует скомпилированный скрипт на языке tool calls, после чего рабочий процесс выполняет его без дальнейшего участия LLM.

Форма объекта:

1. Три фазы (Планировщик → Worker → Solver), без циклов.
2. Ссылка на Tool calls #E1, #E2 места замещения для результатов, которые пока отсутствуют.
3. Во время выполнения не происходит использования LLM. Рабочий процесс просто запускает соответствующие инструменты.
4. Независимые инструменты работают параллельно.
5. В конце осуществляется один вызов синтеза, обрабатывающий всю информацию одновременно.

Этап 1: ReWOO планировщик (предварительно формирует полную графу выполнения)

class ReWOOPlanStep(BaseModel):
    """A step in the ReWOO plan with variable placeholders.

    Key difference from Plan-and-Execute's PlanStep:
    - Contains actual tool_name and tool_args (not just description)
    - Uses variable references (#E1) for dependencies
    """
    step_id: str  # e.g., "#E1" - becomes a variable
    description: str
    tool_name: str     # Exact tool to call
    tool_args: dict    # May contain variable refs like {"price": "#E1"}
    depends_on: list[str] = []  # For dependency ordering
    result: str | None = None

class ReWOOPlanOutput(BaseModel):
    """Structured output for ReWOO planner."""
    steps: list[ReWOOPlanStep] = Field(description="Planned tool calls with variables")

def rewoo_planner_node(state: AgentState) -> dict:
    """Generate a complete plan of tool calls upfront.

    This is the key difference from Plan-and-Execute: instead of creating
    human-readable step descriptions, we create EXACT tool calls that
    the worker will execute blindly.
    """

    llm = ChatAnthropic(model="claude-sonnet-4-5-20250929", temperature=0)

    # Schema-Guided Reasoning ensures valid tool call specifications
    structured_llm = llm.with_structured_output(ReWOOPlanOutput)

    ticker = state.research_data.ticker if state.research_data else "UNKNOWN"

    # Single LLM call to plan ALL tool executions
    result: ReWOOPlanOutput = structured_llm.invoke([
        SystemMessage(content=REWOO_PLANNER_PROMPT),
        HumanMessage(content=f"""Create a ReWOO plan for: {query}

Ticker: {ticker}

Output tool calls with:
- step_id: Variable name (#E1, #E2, etc.)
- description: What this accomplishes
- tool_name: Exact tool from the list
- tool_args: Dictionary of arguments
- depends_on: List of step_ids this depends on"""),
    ])

    # State update: Store the complete execution plan
    # Worker will execute this without any LLM involvement
    return {"rewoo_plan": result.steps}

Этап 2: рабочий процесс ReWOO (осуществляет запуск инструментов без LLM ризонинг)

def rewoo_worker_node(state: AgentState) -> dict:
    """Execute all planned tools in parallel (no LLM calls).

    This is the key efficiency: Worker is "dumb" - it just runs tools
    according to the plan. No LLM calls = massive token savings.
    """

    results = {}  # Store results keyed by step_id (e.g., "#E1": "$150.23")

    # Execute ALL independent steps in parallel using ThreadPoolExecutor
    # This is where ReWOO gets its speed advantage
    with ThreadPoolExecutor(max_workers=5) as executor:
        futures = {
            executor.submit(execute_tool, step): step
            for step in state.rewoo_plan
            if not step.depends_on  # Only independent tools for parallel batch
        }

        # Collect results as they complete
        for future in as_completed(futures):
            step = futures[future]
            results[step.step_id] = future.result()
            # No LLM reasoning here - just store the raw tool output

    # State update: Store results for the Solver phase
    return {"rewoo_plan": updated_steps}

Этап 3: решатель ReWOO (синтезирует все результаты в одном вызове LLM)

def rewoo_solver_node(state: AgentState) -> dict:
    """Synthesize all tool results into a flash briefing.

    This is the second efficiency gain: Instead of interleaving
    LLM calls with tool execution (like ReAct), we make ONE
    final synthesis call with all gathered data.
    """

    # Build context from ALL tool results at once
    tool_results = []
    for step in state.rewoo_plan:
        if step.result:
            tool_results.append(f"### {step.description}\n{step.result}")

    context = "\n\n".join(tool_results)

    # Single LLM call to synthesize everything
    structured_llm = llm.with_structured_output(FlashBriefingOutput)
    result = structured_llm.invoke([
        SystemMessage(content=REWOO_SOLVER_PROMPT),
        HumanMessage(content=f"Create a flash briefing from this data:\n\n{context}"),
    ])

    return {"draft_report": result}

ReWOO заранее планирует каждый tool call и сохраняет зависимости в специальных местах, таких как #E1 и #E2. экзекьютор может выполнять независимые вызовы параллельно, не запрашивая у модель дальнейшие действия. Окончательный вызов модель объединяет полученные результаты, что позволяет сохранять низкие затраты на реализацию предсказуемых рабочих процессов.

Где каждый шаблон вызывает модель

Эти три шаблона отличаются по времени и способу вызова LLM:

Разница между ними заключается в том, что генерирует планировщик. Именно это определяет всё последующее поведение системы.

1. Механизм Plan-and-Execute генерирует описания шагов в формате, понятном человеку:

   # Planner output (list of PlanStep objects)
   plan = [
       PlanStep(
           step_number=1,
           description="Get current price and key financial metrics",
           tool_hint="get_stock_price"
       ),
       PlanStep(
           step_number=2,
           description="Search for recent news and earnings",
           tool_hint="search_news"
       ),
       # ... more steps
   ]

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

2. ReAct не предусматривает первоначальный план. В его реализации используется итеративный ризонинг:

   # No planning phase - ReAct works step-by-step with accumulated messages
   messages = [
       HumanMessage(content="Execute Step 1: Get current price"),
       AIMessage(content="I'll call get_stock_price"),
       ToolMessage(tool_call_id="1", content="$132.45"),
       AIMessage(content="Now I need metrics..."),
       # ... agent continues until step complete
   ]

   Множественные вызовы LLM в рамках одного шага позволяют адаптироваться к получаемым наблюдениям, но обычно приводят к более высоким затратам по сравнению с двумя запланированными режимами работы.

3. ReWOO генерирует чёткие, исполняемые спецификации tool call:

   # Planner output (list of ReWOOPlanStep objects)
   rewoo_plan = [
       ReWOOPlanStep(
           step_id="#E1",
           tool_name="get_stock_price",
           tool_args={"ticker": "NVDA"}
       ),
       ReWOOPlanStep(
           step_id="#E2",
           tool_name="search_news",
           tool_args={"query": "NVDA earnings", "limit": 5}
       ),
       # ... all tool calls planned upfront
   ]

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

Поток памяти и состояний:

• Планирование и выполнение: последовательность действий модели plan → current_step_index → research_data.
• ReAct: состояние накапливается внутри messages массив (полная история диалога).
• ReWOO: состояние претерпевает изменения rewoo_plan, с result поля, заполняемые оператором.

Сборка всего воедино: подключение графа

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

LangGraph сохраняет описание структуры связей в декларативном формате:

def create_graph(checkpointer=None):
    builder = StateGraph(AgentState)

    # Add nodes
    builder.add_node("router", router_node)
    builder.add_node("planner", planner_node)
    builder.add_node("executor", executor_node)
    builder.add_node("reporter", reporter_node)
    builder.add_node("rewoo_planner", rewoo_planner_node)
    builder.add_node("rewoo_worker", rewoo_worker_node)
    builder.add_node("rewoo_solver", rewoo_solver_node)

    # Define edges
    builder.add_edge(START, "router")
    builder.add_conditional_edges("router", route_after_router, {
        "planner": "planner",
        "rewoo_planner": "rewoo_planner",
    })

    # Deep Research path
    builder.add_edge("planner", "executor")
    builder.add_conditional_edges("executor", route_after_executor, {
        "executor": "executor",  # Loop back for more steps
        "reporter": "reporter",  # Done with plan
    })
    builder.add_edge("reporter", END)

    # Flash Briefing path (ReWOO)
    builder.add_edge("rewoo_planner", "rewoo_worker")
    builder.add_edge("rewoo_worker", "rewoo_solver")
    builder.add_edge("rewoo_solver", END)

    return builder.compile(
        checkpointer=checkpointer,
        interrupt_before=["reporter"],  # HITL pause for approval
    )

Автоматический выбор шаблона с использованием роутер

Чтобы выбирать подходящий цикл для каждого запроса, я добавил классификатор роутер. Для обеспечения надёжности классификации он использует метод Schema-Guided Ризонинг:

class ExecutionMode(str, Enum):
    """Execution mode for the agent."""

    DEEP_RESEARCH = "deep_research"  # Plan-and-Execute + ReAct (thorough)
    FLASH_BRIEFING = "flash_briefing"  # ReWOO (fast, token-efficient)

class RouterOutput(BaseModel):
    """Structured output for the router."""

    mode: ExecutionMode  # DEEP_RESEARCH or FLASH_BRIEFING
    ticker: str
    reasoning: str

ROUTER_SYSTEM_PROMPT = """Classify the user's request:

1. **deep_research**: Complex analysis requiring synthesis
   - Examples: "Analyze strategic risks", "investment thesis"

2. **flash_briefing**: Quick snapshots, simple data retrieval
   - Examples: "quick snapshot", "current price"

Default to deep_research if unclear."""

structured_llm = llm.with_structured_output(RouterOutput)

Благодаря этому решению пользователи не вынуждены выбирать режим работы. роутер автоматически направляет запросы на получение «текущей цены» в модуль ReWOO, а запросы, связанные с «инвестиционной тезисом», — в модуль Plan-and-Execute.

Основные выводы

1. ReAct обеспечивает наибольшее количество точек возврата информации, но при этом требует частых вызовов модель.
2. ReWOO сокращает количество итераций модель в тех случаях, когда инструменты работают стабильно и зависимости предсказуемы.
3. Подход Plan-and-Execute подходит для сложных анализов, которые можно разложить на этапы перед выполнением, но при этом всё равно требуют обратной связи по каждому шагу.
4. роутер может самостоятельно выбирать один из этих подходов для каждого запроса, что освобождает пользователя от необходимости принимать решения вручную.
5. Для того чтобы цикл мог продолжить работу после перерыва или перезапуска работника, необходимо сохранять его состояние. Именно это рассматривается во Второй части.

Полная реализация, включая роутер и общее состояние, находится в Репозиторий агентов аналитиков рынка.

Следующим уровнем является память

Часть 2, ИИ-агент Архитектура памяти в 2026 году, отделяет возобновляемые чекпоинты данные от кросс-сессия знаний и документации проектов. Без этого слоя состояния вышеупомянутые роутер и экзекьютор могут функционировать лишь в том случае, если активны один процесс и один контекстное окно.

Список литературы

• ReAct: Синергизация Ризонинг и действия в рамках языка Модели (Yao et al., 2022) ReWOO: Разделение Ризонинг от наборов наблюдений для эффективного создания расширенных языков Модели (Xu и др., 2023)
• Подсказки с планированием и решением: повышение эффективности задач без предварительного обучения Chain-of-Thought Ризонинг с помощью крупных языковых Модели (Wang et al., 2023) Хранилище агентов аналитиков рынка

Код агента «Аналитик рынка» уже загружен GitHub если хотите следить за прогрессом чтения.

Серия: Инженерная реализация стека Агентный

• Часть 1: ИИ-агент Ризонинг Циклы в 2026 году (эта статья) Часть 2: ИИ-агент Архитектура памяти в 2026 году — чекпоинты, векторные хранилища и память документов Часть 3: ИИ-агент Tool Use в 2026 году — MCP, интерфейс командной строки, навыки, выполнение кода и ACI Часть 4: ИИ-агент Безопасность в 2026 году — гардрейлы, права доступа, сэндбоксы, HITL и ограничение области применения MCP
• Часть 5: Долгосрочная работа ИИ-агент Рантайм в 2026 году — сессии, сэндбоксы, чекпоинты, механизмы интеграции и деплой формы представления данных
• Часть 6: Харнесс-инжиниринг для ИИ-агенты (вскоре выйдет) — проверки приема данных, трейсы, повторные попытки обработки, передача задач и циклическая работа в рамках модель