Перейти к содержимому
Экосистема AI Vibe
← Назад к AI Vibe News

Редакция 10 июля 2026 г.

Разборы

Агенту не нужны ещё инструменты — ему нужны доказательства

Агенту не нужны ещё инструменты — ему нужны доказательства.

Соло-разработчик, который гоняет агентский цикл в Cursor и уже думает про очередной MCP-сервер, сначала должен научить систему фиксировать факты, а не расширять зоопарк инструментов. В материале bluelobster_agent формулирует жёсткий приоритет: append-only журнал событий важнее новой модели и ещё одного обёртки над инструментами — без него агент остаётся красивым рассказчиком, а не свидетелем того, что реально произошло в shell, тестах и diff'ах.

Почему агент «проходит тесты», которых не было

Демо с ИИ-агентом выглядит убедительно, пока не нужно разбирать провал: «запустил тесты», «починил баг», «прочитал доку», «сборка упала из‑за flaky dependency» — часто без единого артефакта. Корневая причина не в нехватке intelligence, а в отсутствии provenance: никто не может доказать, какая команда ушла в shell, какой exit code вернулся и какой файл изменился.

Человеческий code review опирается на evidence — что изменилось, почему, что падало до фикса, что прошло после, что не проверяли. Агентский workflow сводит это к бесполезному «I fixed the issue and all tests pass». Append-only event log как раз и делает агента отлаживаемым, возобновляемым после сбоя и устойчивее к обману — когда модель имитирует успех без фактического эффекта.

Receipt — событие, а не «память» агента

Receipt в терминологии источника — не summary и не vibe-память, а структурированное событие, созданное когда действие реально произошло. Ответ на «prove it» — строка в логе, а не ещё один абзац в чате.

Доказательства, которые автор перечисляет как обязательные:

  • факт вызова tool и его результат (exit code, хвост stdout);
  • diff файла с added/removed;
  • явное решение с отвергнутой альтернативой;
  • human approval перед необратимым шагом.

Summary при этом — только cache: полезен, но не authoritative. Если в финальном ответе «tests passed», а в логе нет passing tool_result, summary неверен. Отсюда промпт-правило для агента: нельзя утверждать, что команда запущена, тест прошёл, файл изменён или документ прочитан, без matching event в run log; в ответе — секция «Receipts» с event IDs, а невыполненные намерения помечаются явно.

No receipt, no claim. No approval, no irreversible action. No passing test event, no "tests pass."

Минимальный flight recorder на JSONL

Автор предлагает не разворачивать распределённую tracing-платформу на старте, а завести JSONL-файл — «чёрный ящик» запуска агента. Путь по умолчанию: .agent/runs/${runId}.jsonl, запись через appendFile в Node.js.

Каждая строка — событие с полями:

Поле Назначение
id UUID события
runId UUID запуска агента
ts метка ISO-8601
actor human | agent | tool | ci
type тип события (см. ниже)
data payload
prevHash хеш предыдущей записи или null
hash SHA-256 от сериализованного объекта

Типы (EventType): goal, plan, tool_call, tool_result, file_diff, decision, human_approval, rollback, final_summary.

Ключевое архитектурное правило: модель может запросить действие, но среда — обёртка shell, CI, tool wrapper — фиксирует, произошло ли оно. Класс FlightRecorder на TypeScript с методом record(type, data, actor?) строит hash-цепочку и дописывает строку; интеграция — вокруг действий, которые агент уже выполняет (shell, diff, human goal).

// Упрощённая идея: среда пишет, LLM — нет
await recorder.record('tool_result', {
  command: 'npm test -- --run auth',
  exitCode: 0,
  stdoutTail: '...'
}, 'tool');

Пять событий, с которых начинают лог

Прежде чем подключать новые MCP-инструменты, автор советует залогировать пять типов: tool_call, tool_result, file_diff, decision, human_approval. Из такого лога уже вырастают практические сценарии для агентского цикла:

Возможность Зачем соло-разработчику
Resume после краша — replay и продолжение с последнего verified state
Fork две стратегии от одного события, сравнение исходов
Review человек смотрит только decisions, diffs, failed tests
Evaluation сравнение агентов по действиям, не по claims
Security флаги неожиданных network calls, secret access, deploy вне scope

Без receipts агент «re-discovers» одни и те же факты: снова читает файлы, гоняет тесты, пересобирает контекст. С логом можно не тащить весь репозиторий в дорогую модель — достаточно последних N событий, маршрутизировать простые шаги на дешёвую модель по логу и эскалировать к человеку после повторных failures в одной зоне. Количественных кейсов «до/после» в источнике нет — только качественный аргумент про экономию повторных запусков.

Соло-workflow: Cursor rules после лога, не вместо него

В первоисточнике нет привязки к Cursor, конкретному MCP-клиенту или оркестратору — MCP упоминается лишь во вводном тезисе «before you add another MCP server». Перенос на ваш цикл — инженерная аналогия, не цитата автора.

Практический порядок для соло-разработчика с агентами в IDE:

  1. обернуть shell, diff и approval в FlightRecorder или эквивалент;
  2. добавить в Cursor rule / system prompt запрет claims без event ID;
  3. только потом расширять MCP-стек — иначе новые tools умножают шум без доказуемости.

Receipt-driven workflow сначала выглядит хуже: видно, как агент запускает команды, не используя результат, правит лишние файлы, повторяет failed strategies и прячет uncertainty за confident language. Observability «ruins the fantasy before it improves the system» — и это аргумент за логирование, не против.

Что меняется в культуре агентов

Финальная формула источника: следующее поколение полезных агентов — не «лучшие собеседники», а лучшие свидетели. Агент должен знать, что произошло, что не произошло, что упало, что изменилось и что ещё требует human.

Для команды messy runs превращаются в docs, checklists и guardrails — но старт остаётся тем же: один append-only лог, пять типов событий, три production-правила в промпте. Очередной MCP-сервер или более крупная модель без receipts добавят красивых ответов, но не ответственности за действия в вашем репозитории.

Источники