Ментальные модели

После главы вы сможете отличить model call от workflow и agent loop, локализовать неопределённость и объяснить, почему «модель подумала» не означает, что среда изменилась.

Место на карте

Inference loop живёт внутри model provider: токены, скрытое reasoning state, sampling. Agent loop живёт в вашем приложении: model requests, tool calls, policy decisions, events и checkpoints. Первый нельзя использовать как durable state второго.

Модель, workflow и агент

Понятие	Кто владеет следующим шагом	Сильная сторона	Цена
Модель	Вызывающий код	Один вероятностный результат	Нет действия и долгого state
Workflow	Код/граф	Предсказуемость и тестируемость	Путь нужно описать заранее
Агент	Модель в policy boundary	Адаптация к новым наблюдениям	Вариативность, latency, risk

Это спектр, а не три несовместимых продукта. Production-система обычно сочетает их: deterministic workflow проверяет identity и policy, agent loop исследует неоднозначную проблему, обычная функция выполняет денежную транзакцию.

Anthropic формулирует похожее различие между predefined workflows и системами, где модель динамически управляет tool use. Это provider observation, не универсальное определение: Building effective agents.

Агент как feedback loop

Минимальная инженерная модель:

observe → decide → validate/authorize → act → inspect → decide ...

Виток полезен, если он изменил хотя бы одно:

• знание о среде;
• структурированное task state;
• состояние внешней системы;
• уверенность в гипотезе;
• terminal condition.

Повтор одного объяснения без нового observation — не «глубокое размышление», а loop без прогресса.

Работа ReAct показала пользу чередования рассуждения и действий в исследованных задачах. Из неё полезен feedback principle. Из неё не следует, что production runtime обязан сохранять или показывать hidden chain-of-thought: ReAct.

Ответ не равен действию

«Я вернул деньги» — последовательность токенов. Денежный outcome доказывается другим evidence:

• transaction/operation ID;
• state transition в ledger;
• успешный tool result;
• postcondition read;
• audit event.

Отсюда главное правило evals: final text, trajectory и environment outcome — разные объекты проверки.

Пять независимых неопределённостей

1. Goal: какой эффект на самом деле нужен?
2. State: какова текущая версия мира?
3. Method: какой путь даст результат?
4. Authority: что разрешено читать и менять?
5. Completion: какое наблюдение опровергает или подтверждает успех?

Не всякая неопределённость требует вопроса пользователю. State часто можно безопасно прочитать. Вопрос нужен, если ответ нельзя получить из среды, а предположение меняет продуктовый смысл, риск или полномочия.

Спектр автономности

Режим	Пример Helios	Реальный аналог
One-shot	Классифицировать тип обращения	Intent classifier
Guided dialogue	Уточнить адрес планеты	Support form/chat
Deterministic workflow	KYC → limits → payment	Neobank onboarding
Bounded agent	Исследовать причину задержки груза	Marketplace support
Approval-gated agent	Подготовить refund и ждать решения	Escrow/claims
Long-running agent	Координировать межпланетную доставку	Travel/logistics ops

Выбирайте минимально достаточную автономность. Если обычный код надёжно выражает правило, перенос control flow в LLM редко улучшает систему.

Почему интерфейс меняет качество

Naive tool:

run(command: string): Promise<string>

Он смешивает чтение, запись, shell parsing, полномочия и ошибки. Более узкая граница:

getOrder(input: {orderId: string}): Promise<OrderSnapshot>

даёт schema validation, tenant check, понятный effect class и компактный observation. SWE-agent на software-engineering benchmarks показал, что agent-computer interface существенно влияет на результат; численные результаты не следует переносить за пределы их benchmark, но гипотеза о важности интерфейса полезна: SWE-agent.

Наивный END-loop и его проблемы

while (steps < maxSteps) {
  const text = await model(history);
  if (text.includes('END')) return text;
  history.push(text);
}

Почему он ломается:

• terminal signal смешан с пользовательским текстом;
• tool call невозможно валидировать до исполнения;
• history не различает state, observation и память;
• нет typed failure, approval и operation ID;
• crash стирает позицию run;
• «правильный» ответ может не соответствовать outcome.

Варианты роста

Решение	Выигрыш	Цена	Когда плохой выбор
Structured decision union	Явные final/tool ветки	Контракт и parser	Совсем простой one-shot
Workflow state machine	Детерминированные переходы	Нужно описать граф	Путь принципиально неизвестен
Durable agent runtime	Resume, approval, audit	Storage и больше состояний	Малый обратимый запрос

Helios: статус заказа

Пользователь спрашивает: «Где мой заказ?» Модель не должна угадывать. Она выбирает get_order, runtime проверяет имя/schema/policy, доменный repository возвращает свежую ревизию, observation снова попадает в model context, и только затем появляется final answer.

Запуск:

npm run test:course:pattern -- "runs model"

Типичные ошибки мышления

• «Модель всё помнит». Context конечен; внешнее state меняется.
• «План гарантирует результат». План — гипотеза, которую обновляют по evidence.
• «Больше автономности лучше». Без recovery увеличивается только blast radius.
• «Зелёные тесты равны успеху». Они проверяют лишь закодированные ожидания.
• «Multi-agent — следующий уровень». Координация не исправляет плохой single-agent contract.

Self-check

Для одной рабочей задачи назовите:

• кто выбирает следующий шаг;
• где заканчивается inference и начинается application loop;
• какое observation меняет решение;
• какой side effect максимален;
• какой terminal reason нужен кроме completed;
• чем доказать outcome независимо от текста.