Bounded Task Context Agent: как строить coding-agent’ов без деградации контекста и непредсказуемой стоимости

Рынок coding-agents переживает классическую фазу: демо работают впечатляюще, но как только вы пытаетесь использовать “агента в IDE” на длинной задаче, в реальном репозитории и с реальной ответственностью, система начинает деградировать.

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

• контекст раздувается, стоимость каждого шага растет;
• агент теряет фокус и начинает повторяться;
• появляется “магическая память”, которая либо протекает между задачами, либо превращается в мусор;
• попытка дать агенту больше инструментов делает его менее управляемым и более рискованным.

Главный тезис этой статьи такой:

чтобы coding-agent был production-инструментом, ему нужен bounded-контекст на каждом шаге, внешнее управляемое состояние задачи и строгая модель исполнения вместо “бесконечного чата с памятью”.

Эту архитектуру мы называем Bounded Task Context Agent. Она напрямую стыкуется с нашей более общей рамкой Domain-Isolated AI Architecture: вместо “одного агента на всё” мы строим изолированные контуры, а внутри каждого контура — предсказуемые, проверяемые циклы работы с bounded-контекстом.

Важно: для нас это не теоретическая заметка. Именно вокруг этих принципов мы проектируем TaoCoder IDE — рабочее место для production AI coding, которое мы реализуем на базе зрелого open-source ядра, добавляя поверх него собственный агентный контур, контроль и инфраструктуру.

Почему обычные IDE-агенты деградируют

1) Линейная “память” превращает агента в дорогой чат

Типичный агент сегодня работает по схеме append-only:

1. прочитал файлы и логи;
2. записал всё в контекст;
3. на следующем шаге тащит в модель ещё больше текста;
4. после переполнения делает compaction/summary;
5. теряет детали и повторяет уже проверенные ветки.

Это дает предсказуемый эффект: каждое последующее действие становится дороже и менее точным, потому что модель вынуждена “переваривать историю”, а не решать конкретный следующий шаг.

2) “Больше инструментов” без границ = шире execution surface

Когда агент получает доступ к browser, shell, файлам, API и интеграциям, кажется, что это усиление. В реальной эксплуатации это быстро превращается в проблему:

• сложнее ограничивать права;
• сложнее валидировать вход/выход;
• дороже аудит;
• выше цена ошибки.

Именно поэтому не работает базовый шаблон “один универсальный агент, которому мы дадим всё”.

Архитектура Bounded Task Context Agent

Принцип 1. LLM — процессор решений, но не хранилище памяти

LLM должен принимать решения, но “память задачи” не должна быть append-only логом в промпте. Память выносится наружу в отдельный артефакт.

Принцип 2. Task Context как внешний kernel состояния задачи

Вместо того чтобы держать историю и тул-логи в контексте модели, вводится внешний Task Context — компактное, управляемое состояние задачи.

На каждом шаге агент получает:

• Task Context (минимально достаточное состояние);
• цель текущего шага;
• небольшое окно последних действий (без длинных логов и дампов).

Task Context хранит не “всю историю”, а структурированные ссылки:

• релевантный код (путь + диапазон строк + зачем нужен);
• решения (что выбрали и почему);
• негативные знания (что проверено и не подходит);
• краткий execution log (ссылки на артефакты, а не копипаста).

Принцип 3. Негативные знания — обязательны

Большая часть стоимости длинной задачи уходит не на “придумывание”, а на повторные обходы тупиков.

Поэтому negative knowledge — это first-class сущность:

• “эту ветку проверили, она не подходит”;
• “этот файл legacy, в текущем flow не используется”;
• “этот подход ломает контракт, не повторять”.

Это превращает агента из “болтливого исследователя” в систему, которая учится не повторять собственные ошибки на длинной дистанции.

Принцип 4. State machine вместо “магии”

Чтобы поведение было предсказуемым, работа агента оформляется как конечный набор стадий:

• уточнение задачи;
• сбор данных;
• разработка;
• аудит/проверка;
• отчет/передача результата;
• отдельный цикл для доработок.

У каждой стадии есть:

• допустимые инструменты;
• критерии выхода;
• тип проверок.

Это простая идея, но она меняет всё: агент перестает быть “универсальным болтуном” и становится управляемым производственным контуром.

Как это соотносится с Domain-Isolated AI Architecture

Domain-Isolated AI Architecture отвечает на вопрос “как должна выглядеть production AI-система в целом”, а Bounded Task Context Agent — “как должна работать одна длинная задача внутри изолированного контура”.

Связка выглядит так:

• изоляция по доменам и проектам задает границы памяти, прав и ответственности;
• Task Context становится локальной “доской состояния” внутри конкретного доменного/проектного контура;
• task-oriented субагенты выполняют узкие функции (анализ, генерация, валидация, аудит), а не “всё подряд”;
• control layer ограничивает доступ к действиям и оформляет их как контрактные операции;
• validation layer проверяет вход/выход и не пропускает невалидные результаты дальше по цепочке;
• bounded main-context стабилизирует стоимость и качество на каждом шаге.

Если упростить до одного вывода:

Domain Isolation делает систему безопасной и управляемой по границам, а Bounded Task Context делает каждую длинную задачу предсказуемой по стоимости и качеству.

Почему мы делаем TaoCoder IDE именно так

На уровне рынка сейчас популярна логика “vibe coding”: пусть агент пишет, а мы посмотрим, что получится. На уровне бизнеса это быстро упирается в другое:

• вам нужен результат в срок, а не бесконечная генерация;
• вам нужен контроль над риском, а не широкий доступ к опасным действиям;
• вам нужна стоимость, которую можно объяснить и повторить;
• вам нужен аудит того, что именно было сделано и почему.

Именно поэтому TaoCoder IDE строится вокруг production-шаблона:

• bounded-контекст на каждом шаге;
• внешний Task Context как состояние задачи;
• отделение интеллекта от исполнения через контракты;
• контроль и валидация как отдельные инженерные слои;
• изоляция контуров по проектам и доменам.

Технически мы реализуем TaoCoder IDE на базе готового open-source ядра (редактор/IDE-платформа), потому что в этой задаче нет смысла заново изобретать то, что уже отлично решено сообществом: UI, редактор, интеграции с языками, базовая инфраструктура.

Наш фокус — не “еще один редактор”, а производственная архитектура:

• агентный runtime с bounded-контекстом;
• Task Context как управляемая память задачи;
• контрольный контур инструментов и операций;
• валидация результата;
• наблюдаемость и трассировка действий.

Вывод

Сильный coding-agent — это не модель “побольше” и не чат “подольше”.

Production-агент в IDE — это архитектура, где:

• память задачи вынесена наружу и управляема;
• контекст на каждом шаге ограничен и минимально достаточен;
• тупики фиксируются как negative knowledge и не повторяются;
• исполнение проходит через контракты, контроль и валидацию;
• домены и проекты изолированы, а не смешаны в одной универсальной памяти.

Мы называем эту связку Domain-Isolated AI Architecture + Bounded Task Context Agent и строим вокруг нее TaoCoder IDE как production-инструмент для компаний, которым нужна не “демо-магия”, а предсказуемая AI-разработка с контролируемым риском.