Урок 13.1. Логи Agent Runs

Зачем это нужно

В предыдущих модулях мы постепенно построили controlled AI-assisted development workflow:

Specification
-> Task decomposition
-> Context package
-> Skills
-> Tools / MCP
-> Development loop
-> Tests
-> Git
-> Multi-agent orchestration
-> Hooks
-> Guardrails

Теперь появляется следующий вопрос:

Как понять, что этот процесс действительно работает?

Если мы не сохраняем agent runs, мы видим только финальный ответ агента:

Сделал. Тесты прошли. Риск минимальный.

Но мы не знаем:

• какая задача была дана;
• какая модель использовалась;
• какие skills были активированы;
• какой context агент прочитал;
• какие tools он вызывал;
• какие команды реально запускались;
• сколько было retries;
• где были failures;
• сколько заняло времени;
• сколько было потрачено tokens и денег;
• какие guardrails сработали;
• какие проверки были skipped;
• почему задача завершилась именно так.

Без этих данных agent workflow нельзя улучшать. Его можно только обсуждать по ощущениям.

В обычной разработке мы давно логируем build results, test runs, CI jobs, deploys и incidents. Agent runs нужно логировать так же дисциплинированно.

Главная мысль урока:

Agent run без лога - это неповторимый эпизод.
Agent run с логом - это engineering data.

Основная идея

Agent run log - это структурированная запись выполнения агентной задачи.

Он отвечает на вопросы:

Что агент должен был сделать?
В каком контексте он работал?
Какие capabilities использовал?
Что он изменил?
Какие проверки запускал?
Что прошло, что упало, что не запускалось?
Сколько стоил run?
Почему run считается success, failed или blocked?
Что нужно улучшить в процессе?

Run log не должен быть полным transcript'ом разговора. Полный transcript часто слишком длинный, шумный и может содержать sensitive data. Run log должен быть компактным summary of execution, привязанным к проверяемым artifacts.

Принцип:

Log facts and evidence, not every thought.

Пример:

Bad:
The agent thought for a while and decided the implementation was good.

Good:
Task: Fix reset token reuse.
Model: ...
Changed files: ...
Commands:
- npm test -- tests/auth/reset-token.test.ts: passed
Failures:
- first run failed on missing consumed_at check
Retries: 1
Result: success
Evidence: regression test now passes

Лог не заменяет tests, review или CI. Он связывает их в историю выполнения.

Ключевые термины

Почему "финальный ответ" недостаточен

Финальный ответ агента обычно оптимизирован для пользователя:

Сделал изменение, запустил тесты, все прошло.

Это удобно, но недостаточно для улучшения процесса.

Представьте, что через неделю команда замечает:

• агент стал чаще забывать tests;
• одна skill начала приводить к scope creep;
• multi-agent workflow стал дороже single-agent;
• reviewer часто approve'ит без evidence;
• CI падает после локального "passed";
• tool permission errors повторяются;
• большинство retries вызваны не кодом, а плохим task brief.

Без run logs такие проблемы трудно увидеть. У команды есть только воспоминания:

Кажется, раньше агент работал лучше.

С run logs можно спросить точнее:

В каких task types выросло число retries?
Какая model чаще забывает final evidence?
Какие guardrails чаще всего блокируют run?
Какие skills увеличили duration, но снизили failures?
Где agent claims не совпадают с command evidence?

Run logs превращают vague впечатления в data.

Что Именно Нужно Логировать

Минимальная запись должна покрывать пять слоев:

Task
Process
Actions
Evidence
Outcome

Таблица:

Если лог содержит только task и result, он слишком слабый.

Если лог содержит полный transcript без структуры, он слишком шумный.

Хороший run log находится посередине:

Enough structure for comparison.
Enough detail for diagnosis.
Not so much data that nobody reads it.

Minimal Run Log Schema

Минимальная schema:

Эта schema не обязана быть идеальной с первого дня. Важно начать логировать consistently.

Схема Agent Run

Обратите внимание: лог пишется не только для успешных runs. Failed and blocked runs часто ценнее для улучшения процесса.

Success показывает, что работает.

Failure показывает, что нужно чинить.

Blocked показывает, где agent needs better task input, permissions, tools or approval policy.

Result Vs Evidence

Одна из главных ошибок:

Result: success
Evidence: agent says it works

Это не evidence.

Result - это статус run.

Evidence - это проверяемые факты, которые объясняют, почему result считается корректным.

Пример:

Result:
success

Evidence:
- `npm test -- tests/auth/reset-token.test.ts`: passed
- `npm run lint`: passed
- reviewer found no blocking issues
- changed files match allowed scope

Другой пример:

Result:
blocked

Evidence:
- task requires production deploy
- deploy tool requires human approval
- approval was not granted in this run

Умение отделять result от evidence делает логи честными.

Outcome Status Taxonomy

Нужен небольшой словарь итоговых статусов.

Почему это важно?

Если все неуспехи записывать как failed, вы потеряете signal. failed test и approval required требуют разных улучшений.

Пример:

failed:
Need better code/test/debugging.

blocked:
Need clearer spec, permissions or human decision.

unsafe_request:
Need guardrail and user-facing explanation.

Event Log

Полный run log может иметь список событий.

Событие отвечает:

Что произошло внутри run?
Когда?
С каким результатом?
Какие artifacts появились?

Пример event types:

Не обязательно логировать каждую мелочь. Но если run нужен для анализа процесса, events помогают восстановить timeline.

Tool Call Log

Tools расширяют возможности агента, поэтому их нужно логировать отдельно.

Минимум:

Tool arguments нужно логировать осторожно. Не кладите в run log:

• secrets;
• raw customer data;
• full SQL with sensitive literals;
• huge log dumps;
• private tokens;
• payment identifiers;
• prompt content with confidential data.

Лог должен быть useful, not leaky.

Commands And Verification Evidence

Для coding agent особенно важны команды.

Run log должен различать:

Command was run and passed.
Command was run and failed.
Command was not run.
Command could not be run.
Command was skipped by policy.

Пример:

Commands:
- command: npm test -- tests/auth/reset-token.test.ts
  status: passed
  exit_code: 0
  evidence: "8 tests passed"

- command: npm run lint
  status: failed
  exit_code: 1
  evidence: "no-unused-vars in reset-token.ts"

- command: npm run e2e
  status: not_run
  reason: "UI branch out of scope for this backend task"

Почему not_run важно?

Потому что отсутствие проверки тоже является информацией. Reviewer должен видеть не только зеленые checks, но и то, что не проверялось.

Плохой log:

Verification: done

Хороший log:

Verification:
- targeted unit tests: passed
- lint: passed
- full e2e: not run, out of scope
- manual browser check: not run, no UI changes

Failures And Retries

Agent run без failures не всегда лучше. Иногда хороший run включает failure, correction и повторную проверку.

Пример:

First test run failed.
Agent inspected failure.
Agent fixed missing null check.
Second test run passed.

Это нормальный engineering loop. Важно сохранить его в log.

Минимальные поля failure:

Типы failures:

Retries тоже нужно логировать. Не просто количество, а причину:

Retries:
- 1 retry after typecheck failure
- 1 retry after reviewer finding

Если retries растут, это signal. Возможно, задачи слишком большие, context слабый, skill устарел или tool output непонятен.

Duration, Tokens And Cost

Agent process имеет стоимость.

Cost - это не только деньги. Это:

• model tokens;
• wall-clock time;
• tool latency;
• CI minutes;
• external API calls;
• human review time;
• coordination overhead;
• retries.

Минимум:

Duration:
- total: 18m 42s
- planning: 2m
- implementation: 9m
- verification: 5m
- review: 2m

Tokens:
- input: 48k
- output: 9k
- total: 57k

Cost:
- model: estimated
- external tools: none
- CI: 1 run

Если точная стоимость недоступна, можно логировать approximate metrics:

Tokens: not available
Cost: not available
Duration: 14m
Tool calls: 11
Retries: 2

Этого уже достаточно, чтобы сравнивать runs.

Важно не превращать cost logging в микроменеджмент. Цель не в том, чтобы ругать каждый дорогой run. Цель - видеть patterns:

• multi-agent workflow дороже single-agent без выигрыша;
• слишком большой context увеличивает tokens;
• плохой task brief вызывает retries;
• slow tests тормозят every run;
• external MCP tool unreliable;
• full eval suite запускается слишком часто.

Context Logging

Context влияет на результат не меньше, чем model choice.

Run log должен фиксировать не весь context, а sources:

Context sources:
- guide/content_plan.md: module 13 plan
- modules/module_12/lesson_12_02_guardrails.md: transition
- req/AI Agent Development 101.md: source outline
- modules/module_13/README.md: module scope

Почему это важно?

Если run failed из-за missing context, нужно увидеть:

Agent did not read architecture constraints.
Agent used outdated spec.
Agent read too many unrelated files.
Agent missed protected path policy.

Context logging помогает улучшить context engineering:

• какие docs должны быть in default package;
• какие files были лишними;
• какие skills should trigger;
• какие references outdated;
• где progressive context сработал плохо.

Не нужно логировать полный текст всех файлов. Достаточно:

• path or URI;
• version or commit if practical;
• why included;
• whether source was authoritative.

Skills, Rules And Guardrails In Logs

В module 6 мы говорили про skills. В module 12 - про hooks and guardrails. Run log должен показывать, какие из них реально участвовали.

Пример:

Skills used:
- technical-markdown-lectures

Project rules used:
- write primarily in Russian
- include summary and self-check questions
- use apply_patch for edits

Hooks/guardrails:
- diff whitespace check passed
- no placeholder scan passed
- no destructive commands

Это помогает ответить на вопросы:

• skill действительно применялся или был пропущен;
• project rule помог или мешал;
• guardrail сработал вовремя;
• approval был нужен или нет;
• правила слишком шумные или недостаточные.

Если после изменения skill качество runs ухудшилось, run logs помогут увидеть regression.

Guardrails Triggered

Guardrails нужно логировать не только при failure.

Примеры:

guardrails_triggered:
- command required approval: npm install
- direct write outside repo blocked
- secret scan passed
- branch protection requires PR
- destructive command denied

Почему логировать passed guardrails?

Потому что это показывает process coverage. Если guardrail never triggers, возможно:

• он не нужен;
• он неправильно подключен;
• задачи не доходят до этого risk;
• агент избегает действия;
• логирование не фиксирует trigger.

Если guardrail triggers too often, возможно:

• rule слишком широкий;
• task brief плохо задает scope;
• agent role has wrong permissions;
• workflow требует отдельный approval pattern.

Run logs дают материал для настройки guardrails.

Human Approvals

Human approval должен попадать в log.

Минимум:

Approval:
- action:
- reason:
- requested_by:
- approved_by:
- decision:
- timestamp:
- evidence shown:

Пример:

Approval:
- action: add new runtime dependency
- reason: existing dependencies do not support required PDF parsing
- requested_by: Implementer Agent
- approved_by: ivan
- decision: denied
- result: task split into research note

Approval log защищает от размытых историй:

Кто-то вроде разрешил deploy.

В управляемой разработке approval должен быть конкретным:

Approve what?
Why?
Based on which evidence?
With what rollback or follow-up?

Privacy And Secret Hygiene

Run logs могут стать утечкой, если писать туда все подряд.

Не логируйте:

• secrets and API keys;
• passwords;
• private tokens;
• raw customer data;
• full production logs;
• payment data;
• personal data without policy;
• hidden chain-of-thought;
• confidential prompt content;
• full tool outputs with sensitive fields;
• large unredacted database rows.

Логируйте вместо этого:

• summaries;
• hashes;
• IDs with access control;
• redacted snippets;
• links to restricted artifacts;
• counts;
• status;
• paths;
• command names without sensitive arguments.

Пример:

Bad:
query_readonly returned 500 rows with user emails.

Good:
query_readonly returned 500 rows.
Output redacted: customer_email, phone.
Artifact stored in restricted location.

Run log должен помогать debugging, но не расширять blast radius.

Human-Readable Format

Для курса хорошо начать с Markdown.

Шаблон:

Agent Run Log

Run ID:

Date:

Actor:

Agent role:

Model:

Runtime:

Mode:

Task type:

Task summary:

Acceptance criteria:
-

Scope:
- In scope:
- Out of scope:
- Allowed paths:

Context sources:
-

Skills/rules used:
-

Branch/worktree:

Files changed:
-

Tool calls:
- tool:
  risk:
  status:
  summary:

Commands:
- command:
  status:
  exit_code:
  evidence:

Guardrails/approvals:
-

Failures:
- type:
  stage:
  summary:
  resolved:

Retries:

Tokens:
- input:
- output:
- total:

Cost:
- model:
- tool:
- ci:

Result:

Residual risks:
-

Next actions:
-

Такой формат легко заполнить руками после run. Он подходит для обучения, retrospectives и review.

Machine-Readable Format

Когда run logs нужно анализировать, удобнее JSONL.

Одна строка - один run summary:

{
  "run_id": "run_2026_08_08_001",
  "timestamp_start": "2026-08-08T10:00:00+03:00",
  "timestamp_end": "2026-08-08T10:18:42+03:00",
  "duration_seconds": 1122,
  "actor": "ivan",
  "agent_role": "implementer",
  "model": "codex",
  "runtime": "codex-cli",
  "mode": "act",
  "task_type": "bugfix",
  "task_summary": "Reject reused password reset token",
  "files_changed": [
    "src/auth/resetTokenService.ts",
    "tests/auth/resetTokenService.test.ts"
  ],
  "commands_run": [
    {
      "command": "npm test -- tests/auth/resetTokenService.test.ts",
      "status": "passed",
      "exit_code": 0
    }
  ],
  "failures": [],
  "retries": 0,
  "result": "success"
}

Для detailed tracing можно вести отдельный event log:

{
  "run_id": "run_2026_08_08_001",
  "event_index": 4,
  "event_type": "command_run",
  "timestamp": "2026-08-08T10:12:10+03:00",
  "command": "npm test -- tests/auth/resetTokenService.test.ts",
  "status": "passed",
  "duration_ms": 2140
}

В 101 курсе не нужно строить observability platform. Достаточно понять, что human-readable и machine-readable formats решают разные задачи.

Example 1. Coding Task Run Log

Task:

Fix bug: reused password reset token must be rejected.

Run log:

Agent Run Log

Run ID:
run-auth-reset-001

Agent role:
Implementer

Mode:
Act

Task type:
bugfix

Task summary:
Reject reused password reset tokens and add regression coverage.

Acceptance criteria:
- second use of token fails;
- password remains unchanged after second use;
- regression test covers reused token.

Scope:
- In scope: reset token service and tests.
- Out of scope: UI, email delivery, migration.
- Allowed paths: src/auth/**, tests/auth/**

Context sources:
- bug report
- existing reset token service
- auth test patterns

Files changed:
- src/auth/resetTokenService.ts
- tests/auth/resetTokenService.test.ts

Tool calls:
- search_repository: success, found reset token service
- read_file: success, read service and tests
- apply_patch: success

Commands:
- npm test -- tests/auth/resetTokenService.test.ts: failed
  evidence: reused token test expected rejection but password changed
- npm test -- tests/auth/resetTokenService.test.ts: passed
  evidence: 9 tests passed
- npm run lint: passed

Failures:
- type: test_failed
  stage: verification
  summary: first implementation did not preserve password after reused token
  resolved: true

Retries:
1

Result:
success

Residual risks:
- full e2e not run because UI out of scope

Что полезного видно из лога:

• задача была узкой;
• regression evidence есть;
• first failure не скрыт;
• retry привязан к причине;
• e2e не запускался, но причина записана;
• scope не расширился.

Это намного сильнее, чем:

Fixed password reset bug. Tests pass.

Example 2. Documentation Task Run Log

Task:

Write lecture about guardrails.

Run log:

Agent Run Log

Run ID:
run-course-guardrails-001

Agent role:
Writer

Mode:
Act

Task type:
docs

Task summary:
Expand module 12 lesson 12.2 into a complete Markdown lecture.

Context sources:
- modules/module_12/README.md
- modules/module_12/lesson_12_01_hooks.md
- guide/content_plan.md
- req/AI Agent Development 101.md

Skills used:
- technical-markdown-lectures

Files changed:
- modules/module_12/lesson_12_02_guardrails.md

Commands:
- rg UNFINISHED/DRAFT_MARKER/TEMP_MARKER: no matches
- awk code fence count: even
- git diff --check: passed

Guardrails:
- no destructive commands
- write scope stayed within course repo

Result:
success

Residual risks:
- no full docs site build configured for repo

Для content work тоже нужна evidence. Не обязательно tests. Для Markdown лекции evidence может быть:

• file changed;
• outline satisfied;
• code fences balanced;
• placeholder scan clean;
• diff whitespace clean;
• transition to next lesson present.

Example 3. Multi-Agent Run Log

Multi-agent workflow лучше логировать на двух уровнях:

Parent orchestration run
  -> child agent run: Planner
  -> child agent run: Backend Agent
  -> child agent run: Frontend Agent
  -> child agent run: Test Agent
  -> child agent run: Integrator
  -> child agent run: Reviewer

Parent run:

Run ID:
run-password-reset-parent-001

Task:
Implement password reset feature.

Task DAG:
- contract
- backend
- frontend
- tests
- integration
- review
- CI

Child runs:
- run-password-reset-plan-001: success
- run-password-reset-api-001: success
- run-password-reset-ui-001: partial_success
- run-password-reset-tests-001: success
- run-password-reset-integration-001: blocked

Blocked reason:
Frontend expects `{ success: true }`, backend returns `{ ok: true }`.
Contract mismatch requires integration fix.

Result:
blocked

Child run:

Run ID:
run-password-reset-ui-001

Parent:
run-password-reset-parent-001

Agent role:
Frontend Implementer

Task:
Build request and confirm password reset UI from approved contract.

Evidence:
- component tests passed
- screenshot captured

Known issue:
API response assumption differs from backend packet.

Result:
partial_success

Почему это важно?

Если parent run просто говорит "multi-agent failed", команда не знает, где. Run logs показывают, что проблема была не в frontend quality, а в contract mismatch на integration stage.

Log Storage

Для курса достаточно простого хранения:

docs/development/agent-run-log.md

или:

logs/agent-runs/
  2026-08-08-run-auth-reset-001.md
  2026-08-08-run-course-guardrails-001.md

Для machine-readable records:

logs/agent-runs.jsonl

Практичные правила:

• один run имеет один run_id;
• artifacts ссылаются на run_id;
• parent/child runs связаны через parent_run_id;
• logs хранят summary, а не sensitive raw data;
• large artifacts хранятся отдельно;
• final answer агентa ссылается на executed checks;
• logs можно сравнивать между runs.

Не нужно начинать с базы данных. Markdown + JSONL often enough для учебного процесса.

Как Использовать Run Logs Для Улучшения Процесса

Run logs полезны, только если по ним принимаются решения.

Примеры анализа:

Это и есть observability agent process.

Не "какая модель лучшая вообще", а:

Какая часть нашего процесса создает failure, cost или uncertainty?

Run Logs Для Evals

Следующий урок будет про tests vs evals. Run logs готовят почву для evals.

Почему?

Потому что eval для agent behavior должен знать, что измерять.

Например, eval:

Agent adds tests when creating endpoint.

Нужные поля из run log:

• task_type: feature;
• files_changed;
• tests_changed;
• commands_run;
• evidence;
• result;
• scope violations;
• retries.

Другой eval:

Reviewer refuses approval without verification evidence.

Нужные поля:

• agent_role: Reviewer;
• review packet inputs;
• evidence_present;
• findings;
• approval status.

Run logs дают реальные examples для будущей regression suite. Без логов eval scenarios придется придумывать наугад.

Run Logs Для Cost Control

Cost control начинается не с запрета дорогих runs, а с visibility.

В логах полезно сравнивать:

Например:

Small docs task:
- duration: 12m
- tokens: medium
- tool calls: 8
- retries: 0

Small typo fix:
- duration: 35m
- tokens: high
- tool calls: 40
- retries: 5

Второй run выглядит подозрительно. Возможно:

• task была не typo fix;
• context был слишком большой;
• agent lost focus;
• tests были flaky;
• user request был ambiguous;
• tool output confusing.

Без run log это не видно.

What Not To Log

Run log не должен становиться мусорной корзиной.

Не логируйте:

• полный chain-of-thought;
• raw prompt with secrets;
• full transcript без нужды;
• full tool logs with sensitive data;
• production data dumps;
• customer PII;
• private credentials;
• огромные stack traces целиком;
• temporary noise;
• speculation without evidence.

Лучше:

summary + evidence + artifact reference

Пример:

Bad:
stdout: <5000 lines of logs>

Good:
stdout_excerpt: "3 failed tests in auth reset suite"
artifact: "restricted://logs/run-auth-reset-001/test-output"
redactions: ["email", "token"]

Лог должен быть читаемым, безопасным and useful.

Common Log Quality Levels

Можно оценивать качество run logs по уровням.

Для курса цель после этого урока:

Level 3 as default.
Level 4 for important tasks.

Level 5 появится позже, когда будет eval suite.

Типичные Ошибки

Ошибка 1. Лог Только Для Успеха

Плохо:

Сохраняем только successful runs.

Так команда теряет самые ценные данные.

Лучше:

Log success, failure, blocked and cancelled runs.

Ошибка 2. Result Без Evidence

Плохо:

Result: success
Reason: agent said done

Лучше:

Result: success
Evidence: commands passed, reviewer approved, AC covered.

Ошибка 3. Failed Checks Скрываются

Плохо:

Verification passed after some fixes.

Лучше:

First test run failed on X.
Agent fixed Y.
Second run passed.

Ошибка 4. not_run Не Записывается

Плохо:

No mention of e2e.

Reviewer не знает, забыли проверку или она была out of scope.

Лучше:

e2e: not_run, no UI changes.

Ошибка 5. Лог Содержит Sensitive Data

Плохо:

Tool result includes token, user emails and full production logs.

Лучше:

Redacted summary + restricted artifact link.

Ошибка 6. Нельзя Сравнивать Runs

Если каждый лог написан в свободной форме, анализ невозможен.

Лучше:

Use stable fields: task_type, model, role, result, failures, retries, duration.

Ошибка 7. Tokens And Cost Игнорируются

Плохо:

Run successful, но cost неизвестен.

Иногда это нормально для маленьких задач, но если cost grows, team needs visibility.

Лучше:

Log tokens/cost when available.
Log duration/tool calls/retries as fallback metrics.

Ошибка 8. Логи Не Используются

Если run logs никто не читает, они становятся ритуалом.

Лучше:

• раз в неделю смотреть failures;
• обновлять skills по повторяющимся ошибкам;
• улучшать prompts/rules;
• добавлять evals из real failures;
• пересматривать guardrails by trigger frequency.

Практика

Возьмите один недавний Agent Task и заполните run log.

Шаблон:

Run ID:

Date:

Actor:

Agent role:

Model/runtime:

Mode:

Task type:

Task summary:

Acceptance criteria:
1.
2.
3.

Scope:
- in:
- out:
- allowed paths:

Context sources:
-

Skills/rules used:
-

Tools used:
-

Tool calls:
-

Files changed:
-

Commands run:
-

Verification evidence:
-

Guardrails triggered:
-

Approvals:
-

Failures:
-

Retries:

Duration:

Tokens:

Cost:

Result:

Residual risks:
-

Next actions:
-

После заполнения спросите:

• можно ли понять task без transcript;
• можно ли проверить result по evidence;
• видно ли, какие checks не запускались;
• видно ли, где были failures and retries;
• не попали ли secrets or sensitive data;
• можно ли сравнить этот run с другим run;
• появилась ли идея для улучшения skill, hook, guardrail or eval.

Мини-Лаборатория: Agent Run Log Для Курса

Для этого курса можно вести простой docs/development/agent-run-log.md.

Структура:

Agent Run Log

Purpose:
Track AI-assisted course development runs.

Required fields:
- run_id
- date
- task
- target files
- context sources
- skill used
- commands/checks
- failures
- retries
- result
- residual risks

Optional fields:
- model
- duration
- tokens
- cost
- guardrails
- approvals

Пример записи:

Run ID:
course-module-13-lesson-01

Task:
Write lesson 13.1 about agent run logs.

Target files:
- modules/module_13/lesson_13_01_agent_run_logs.md

Context:
- module 13 README
- content plan
- previous lesson 12.2 ending
- source requirement outline

Skill:
- technical-markdown-lectures

Checks:
- placeholder scan
- code fence count
- git diff --check

Result:
success

Такой лог уже полезен. Он показывает, как сам курс создавался агентом, и дает материал для уроков про evals.

Метрики Эффекта Agent Workflow

Run log полезен сам по себе, но его главная ценность раскрывается в агрегировании. Один успешный run не доказывает, что AI agents улучшили разработку. Нужно смотреть на поток задач до review, после review и после release.

Метрики удобно делить на четыре группы.

Важная мысль:

Agent productivity нельзя измерять только количеством сгенерированного кода.

Если агент пишет код быстрее, но:

• review time вырос;
• PR стали больше;
• rework rate вырос;
• тесты часто дописываются человеком;
• CI падает после "local passed";
• стоимость runs растет из-за retries;

то процесс не стал лучше. Он просто перенес bottleneck из coding в review/verification.

Минимальный pilot для команды:

1. Выберите 2-3 типа задач: bugfix, endpoint feature, docs/update.
2. Зафиксируйте baseline без agent или со старым workflow.
3. Запускайте agent-assisted tasks 2-4 недели.
4. Сравните cycle time, review time, rework, failed checks, cost.
5. Решайте не "нравится ли agent", а "улучшился ли поток после проверок".

Run logs дают данные для этого сравнения. Без них команда видит только финальный diff и субъективное ощущение скорости.

Критерии Готовности Run Log

Хороший run log:

• имеет run_id;
• описывает task and acceptance criteria;
• фиксирует role, model/runtime and mode;
• перечисляет context sources;
• показывает skills/rules used;
• перечисляет tools and important tool calls;
• фиксирует changed files;
• содержит commands and verification evidence;
• честно сообщает failed and not-run checks;
• фиксирует failures and retries;
• указывает result taxonomy;
• содержит duration/tokens/cost when available;
• отмечает guardrails and approvals;
• не содержит secrets or sensitive raw data;
• достаточно структурирован для сравнения с другими runs.

Минимальный стандарт:

Task + context + actions + evidence + outcome.

Если этих пяти блоков нет, лог слабый.

Краткое резюме

Agent run logs нужны, чтобы улучшать не только продукт, но и сам процесс работы с агентами.

Лог должен сохранять:

• task;
• model/runtime;
• role and mode;
• context sources;
• skills/rules;
• tools and tool calls;
• changed files;
• commands and evidence;
• failures and retries;
• guardrails and approvals;
• duration, tokens and cost;
• final result and residual risks.

Главный принцип:

Log evidence, failures and decisions.
Do not log secrets, noise or hidden reasoning.

Run logs делают agent workflow наблюдаемым. Без них нельзя надежно понять, почему агент succeeded, failed, got blocked, became expensive or started violating scope.

Вопросы для самопроверки

1. Почему финального ответа агента недостаточно для улучшения процесса?
2. Чем result отличается от evidence?
3. Какие поля должны быть в минимальном agent run log?
4. Почему нужно логировать failed and not-run checks?
5. Какие данные нельзя класть в run log даже для debugging?

Что дальше

В следующем уроке мы разделим tests и evals. Tests проверяют software behavior. Evals проверяют agent behavior: добавляет ли агент тесты, соблюдает ли scope, использует ли tools правильно, сообщает ли evidence и останавливается ли на approval gates. Run logs дают фактическую основу для таких evals.