Context engineering

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

Контекст пересобирается на каждом step

Context engineering — управление working set inference. Storage отвечает «что сохранено», retrieval — «что найдено», context policy — «что сейчас увидит модель».

Anthropic описывает context engineering как циклический отбор полезных tokens из растущего множества возможной информации. Это provider guidance, совпадающий с архитектурой capstone: Effective context engineering for AI agents.

Пять слоёв

Слой	Зачем	Что нельзя подменять им
Conversation	Коммуникативная история	Domain state
Current goal	Ближайший outcome	Старый user request
Task state	Решения, status, revisions	Transcript
Observations	Evidence от tools	Безусловно актуальный факт
Retrieved memory	Выбранный прошлый/knowledge context	Вечную память обо всём

Должна ли модель всегда видеть ввод пользователя?

Текущий unresolved user intent — да, напрямую или в проверяемом semantic summary. Старый дословный вопрос не обязан повторяться вечно, если:

• ответ уже завершён;
• новый turn имеет другую цель;
• важные ограничения вынесены в task state/memory;
• summary сохраняет исключения и provenance.

Потеря исходной цели опаснее потери вежливой реплики. Поэтому goal — отдельное поле, а не вывод из последнего сообщения.

Что делать с ответами прошлых итераций

Не складывайте hidden reasoning в общий массив. Для следующего step обычно нужны:

• наблюдаемое решение (tool call или final);
• tool result;
• обновлённое task state;
• unresolved error/approval;
• короткое rationale, если оно нужно пользователю или review.

Внутренний inference trace не является source of truth и может быть недоступен. Application events и evidence должны быть достаточны без него.

History ≠ state

Старая tool-строка status=created может оставаться в transcript после того, как БД уже содержит out_for_delivery. Context builder должен либо перечитать source of truth, либо маркировать observation revision как stale.

Helios сравнивает entityRevision observation с revision task state и выставляет stale. Это упрощённая учебная политика: production freshness может зависеть от timestamp, ETag, version vector или domain-specific invalidation.

Compaction

Наивно: удалить первые N сообщений. Тогда легко потерять approval, constraint или причину решения.

Надёжнее сохранять семантические инварианты:

• goal и non-goals;
• accepted decisions и причины;
• current domain/task state;
• pending tool/approval;
• unresolved failures;
• evidence/provenance;
• следующий безопасный шаг.

В capstone старый большой tool payload заменяется typed summary с исходным размером, top-level keys и provenance; самое свежее observation остаётся полным. Замена происходит только в собираемом model request и сопоставляется по callId: append-only event и исходное tool message в durable state не мутируют. Иначе экономия tokens уничтожила бы audit/replay evidence.

Четыре долговечных артефакта

Context brief

## Outcome
## Current state
## Scope / non-goals
## Constraints and authority
## Verification
## Open questions

Decision log

- Decision: использовать event log + projection.
- Why: run должен переживать restart.
- Alternatives: transcript-only, snapshot-only.
- Revisit when: все задачи станут one-shot.

Evidence ledger

Claim	Evidence	Status
Order revision = 5	get_order, revision 5	confirmed
Cargo разрешён	cached policy rev 2	stale
Новый retriever улучшит recall	пока нет eval	hypothesis

Handoff summary

## Goal and acceptance
## Decisions already made
## Changed artifacts
## Verification results
## Remaining risks
## Next safe action

Эти артефакты особенно полезны при длинной работе coding/knowledge agents; runtime может хранить их как typed state, а не Markdown.

Progressive disclosure

1. Дать карте tools/resources и goal.
2. Догрузить только связанный компонент.
3. После выбора пути добавить implementation details.
4. Для проверки получить external evidence.
5. Сжать завершённый участок в outcome + provenance.

Это уменьшает шум, но добавляет retrieval latency и риск не найти нужное. Для короткой задачи полная маленькая инструкция лучше сложной lazy-loading системы.

Context budget strategies

Стратегия	Выигрыш	Цена	Плохой выбор
Last-N messages	Дёшево	Теряет важное не по возрасту	Долгий stateful run
Semantic summary	Компактно	Ошибки summary	Юридически точные формулировки
Retrieval	Масштабируется	Miss/leakage/latency	Малый фиксированный корпус
Structured state projection	Предсказуемо	Нужна schema/migration	Чистый creative chat
Hybrid	Лучшее покрытие	Больше moving parts	Ранний прототип

Security boundary

Tool output, web page, seller description и memory record могут содержать инструкции. Context builder маркирует tool observations как trust: untrusted; role остаётся tool, provenance не теряется. Это не гарантирует, что модель никогда не поддастся injection, поэтому authority проверяется ещё раз в policy layer перед действием.

Лаборатория

npm run test:course:pattern -- "context|memory|injection"

Измените maxObservationCharacters и предскажите, какие поля переживут compaction.

Failure modes

• Context dump: всё загружено, цель утонула.
• Transcript as state: много сообщений, неизвестно, что истинно.
• Stale observation: старый tool text конкурирует с новой БД.
• Instruction in data: контент повышает собственную authority.
• Smooth summary: ограничения исчезли, текст звучит уверенно.
• Cross-tenant retrieval: память одного пользователя попала другому.

Self-check

• Где отдельно хранятся goal, state и memory?
• Как определяется freshness?
• Какие данные нельзя summarise?
• Что модель увидит после compaction?
• Как provenance и tenant filter проходят весь pipeline?
• Можно ли продолжить run без hidden reasoning прошлого step?