Сбор фактической основы

Этап 1: сбор фактической основы​

У главного агента — оркестратора — ограниченное контекстное окно. Каждый токен исходных материалов — результатов grep по кодовой базе, веб-поиска, истории git — конкурирует за место с планированием, выполнением и проверкой, которые ещё предстоят. Чем больше необработанных результатов исследования ты добавляешь, тем меньше пространства остаётся для эффективной работы.

Решение — не заставлять оркестратора самостоятельно проводить исследование. Нужно поручить его отдельному субагенту: агенту сбора фактической основы, который ищет по исходным источникам, отбирает важное и возвращает только компактный, очищенный от лишнего ответ. Этот агент широко исследует материал в собственном контексте. Оркестратор получает нужные факты, а не шум.

Методология

Сбор фактов превращает исследование в полезный контекст

Агент сбора фактов ищет в любых источниках, содержащих нужные задаче знания. Два из них покрывают большинство потребностей:

• Исследование кода — как работает твоя система: ответственность модулей, точки интеграции, соглашения об именовании, шаблоны обработки ошибок, контракты тестов и установленные инварианты.
• Исследование веб-источников — как устроен внешний мир: актуальная документация фреймворков, справочники API, руководства по миграции, уведомления о безопасности и практики эксплуатации. Для быстро меняющихся экосистем обучающие данные модели устарели.

Третий источник, история git, нужен в отдельных задачах: прежние миграции, отменённые подходы, исправления ошибок, отражающие скрытые ограничения, и архитектурные решения, зафиксированные в коммитах. Помимо них подходит любой артефакт: спецификации, задачи Jira, письма, презентации, обсуждения в Slack, расшифровки разговоров, проектные документы.

Не в каждой агентной оболочке есть встроенная поддержка субагентов. Claude Code для этого запускает субагентов Explore. ChunkHound раскрытие интересов создан именно для этого подхода. Если твоя среда не поддерживает субагентов, тот же принцип работает через границы контекста: проведи сбор фактов в одной сессии, сохрани результат исследования — Markdown-файл с выжимкой выводов, — затем загрузи его в новую сессию и переходи к планированию. Механизм меняется — субагент или передача артефакта, — но принцип тот же: оркестратор получает компактный контекст, а не необработанное исследование.

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

Если ты не передашь контекст явно, агент соберёт его сам — эта возможность называется агентным поиском. Способность к такому поиску оценивают бенчмарки; SWE-bench, стандартный бенчмарк для агентов программирования, измеряет, насколько хорошо агенты самостоятельно ориентируются в незнакомых кодовых базах. Но агентный поиск происходит внутри контекста оркестратора. Каждая строка вывода grep, каждая загруженная страница, каждая неудачная гипотеза конкурирует за то же ограниченное место, которое агенту нужно для планирования и выполнения. Явный сбор фактов отдельным субагентом избегает этой цены: исследование изолируется в собственном контексте, а назад возвращается только ответ.

Есть и более глубокая причина собирать фактическую основу явно. Агент не знает, чего он не знает. Он будет считать, что всё необходимое под рукой, и при этом упускать критически важные знания: недокументированное соглашение об именовании, ограничение из отменённого PR, точку интеграции в другом сервисе. Хуже того, общая картина часто нигде не записана полностью: почему принято это продуктовое решение, какие альтернативы рассматривали и отвергли, какие бизнес-ограничения определяют пространство решений, что команда уже пробовала и от чего отказалась. Явно собирая фактическую основу, ты заполняешь оба вида пробелов — разбросанные по кодовой базе и спрятанные в обсуждениях Slack, письмах, презентациях и обращениях в поддержку.