Платформа RU

Агент-инженер по репозиторию · Модуль 3 · Урок 3.1

Окно как бюджет: почему нельзя дать агенту «весь репозиторий»

Зачем (какую проблему чиним)

На версии v1 агент исследует репозиторий «руками»: grep → read_file → read_file. На большом репозитории это упирается в стену: окно модели заполняется, растут стоимость и латентность, а главное — наступает context rot: чем больше нерелевантного текста в окне, тем хуже модель удерживает важное. Нужен осознанный бюджет контекста.

Решение и альтернативы

Решение (план версии v2): ввести слой retrieval — заранее проиндексировать репозиторий и подавать модели только релевантные куски, а не файлы целиком. Этот урок — про принцип и измерение: считаем токены, заводим бюджет на задачу, договариваемся, что окно — дефицитный ресурс. Конкретный индекс строим в 3.2–3.3.

Альтернативы: модель с огромным окном — закинуть весь репозиторий — дорого, медленно и всё равно страдает от context rot и «потерянного в середине». Только grep как сейчас — не находит по смыслу (синонимы, близкие формулировки). Гибридный retrieval — баланс точности и стоимости.

DIFF

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

⚠ Безопасность

Бюджет контекста — это и предохранитель стоимости (вместе с maxSteps из версии v0). Кроме того, чем меньше нерелевантного текста мы тянем в окно, тем меньше поверхность для prompt injection из содержимого репозитория: вредоносная инструкция в случайном файле не попадёт в контекст, если мы его не извлекли.

Проверка

Лог показывает оценку токенов на каждый вызов и накопленный бюджет задачи; при приближении к лимиту — предупреждение. На большом файле видно, как наивное «прочитать всё» быстро съедает бюджет.

Глубже

Context engineering, prompt caching, борьба с context rot — курс «Продакшн-разработка», Модуль 1 (гл. 2); почему окно — бюджет, и стратегии управления им — там же.

config.go: бюджет контекста и порог предупреждения
 type Config struct {
 	Model     string
 	MaxTokens int
+	Root      string
+	// Бюджет контекста на задачу: суммарные входные токены, после которых
+	// агент должен опираться на retrieval, а не на «прочитать ещё файл».
+	ContextBudget int
 }

 func loadConfig() Config {
 	model := os.Getenv("ANTHROPIC_MODEL")
 	if model == "" {
 		model = "claude-haiku-4-5"
 	}
-	return Config{Model: model, MaxTokens: 1024}
+	return Config{Model: model, MaxTokens: 1024, ContextBudget: 100_000}
 }

Anti-patterns

Грабли работы с контекстом
ГрабляПочему плохоКак правильно
«У модели большое окно — закинем весь репозиторий»Дорого, медленно, context rot и «потерянное в середине»; качество падаетИзвлекать только релевантные куски (retrieval); окно — дефицитный бюджет
Не измерять заполнение окнаПроблема видна только по счёту за токены постфактумЛогировать токены и бюджет задачи; предупреждать у порога

Практическое задание (RA-v2)

  • Добавить ContextBudget в конфиг и грубую оценку токенов на вызов.
  • Логировать накопленный бюджет задачи и предупреждать у порога.
  • Закоммитить: git commit -m "v2: context budget accounting".

Проверка знаний

Почему «просто использовать модель с большим окном и подать весь репозиторий» — плохой план для агента-инженера?

  • A Большие окна запрещены лицензией
  • B Дорого и медленно, плюс context rot и потеря важного среди нерелевантного — качество падает с ростом мусора в окне
  • C Это всегда даёт лучший ответ, минусов нет
  • D Go не умеет читать много файлов

Дальше почитать