Агент полезен ровно настолько, насколько видит нужный контекст, и Devin собирает его несколькими путями сразу: из текущего и других открытых файлов, из локального индекса всего репозитория и из retrieval, который извлекает релевантные фрагменты по мере работы. Для команд на Teams и Enterprise к этому добавляются индекс remote-репозиториев и Knowledge Base из Google Docs.
Наивный ход, когда контекст важен, - добавить его побольше: закрепить все документы, что кажутся связанными, распахнуть побольше файлов, подключить всю базу знаний. Логика понятна: чем больше модель видит, тем умнее ответ. На практике эта логика переворачивается на определённом пороге.
Ломается она о конкуренцию за внимание. Контекстное окно и внимание модели конечны; лишний закреплённый документ не добавляет знания, а разбавляет его, оттягивая вес от того, что действительно относится к задаче. Переполненный контекст даёт ответы более общие и менее точные - ровно противоположное тому, ради чего его наполняли.
Профессиональный приём - закреплять узко и по делу. Держите в контексте определения модулей, целевой фреймворк, файлы, которые правите, - и убирайте всё, что "может пригодиться". Для внешней документации не бросайте её целиком, а укажите версию, дату и конкретный раздел: это и точнее наводит retrieval, и защищает от опоры на устаревшую редакцию. И наоборот, пустой контекст так же вреден, как переполненный: модель, не видящая целевой фреймворк или соседний модуль, честно достраивает недостающее догадками, поэтому цель - не минимум и не максимум, а точная выборка под задачу. Контекст - это карта, а не склад: ценна выборка, а не объём.
Как устроен движок под капотом, знать полезно для верной интуиции. Это retrieval-augmented подход: локальный код индексируется целиком, включая неоткрытые файлы, а собственная техника извлечения подаёт модели релевантные фрагменты. Значит, движок не "помнит весь репозиторий" дословно, а каждый раз извлекает похожее на запрос. Отсюда практическое следствие: чем точнее сформулирована задача и уже закреплён контекст, тем точнее выборка.
У командных возможностей своя механика и свои границы. Индексирование remote-репозиториев и Knowledge Base доступны на Teams и Enterprise; на Pro расширены длины контекста и лимиты индексации. Knowledge Base в текущем beta принимает Google Docs как общий источник, понимает таблицы, схемы и форматированный текст, но изображения из документов не импортирует, а максимум - около 50 документов. Это ориентир снимка, который сверяют с актуальной страницей.
Одно свойство Knowledge Base важно не как лимит, а как вопрос доступа. После того как администратор публикует документ для команды, доступ к нему внутри команды не следует индивидуальным ACL на стороне Google Drive: его увидят все пользователи команды независимо от исходных ограничений в Drive. Это осознанное поведение общей базы, но оно легко удивляет, если ждать, что права Drive перенесутся сами.
Почему так устроено, а не как зеркало прав Drive. Knowledge Base - это общий командный контекст, а не файловый шлюз; её смысл в том, чтобы одно знание было доступно всем, кто работает над задачей. Плата за это единообразие - то, что публикация становится отдельным решением о доступе, а не автоматическим наследованием чужой модели прав. Границу проводит администратор в момент публикации, а не Drive.
Цена невнимания к этому конкретна и не всегда про качество ответа. Переполненный контекст стоит вам точности и лишних токенов - это обратимо. Опубликованный в Knowledge Base документ с чувствительным разделом стоит уже не токенов, а возможной утечки внутри команды: то, что в Drive видели трое, после публикации видят все. Второе исправляется куда дороже первого.
Проверять стоит две разные вещи. Для качества - убедиться, что в контексте закреплено только нужное, а внешние ссылки помечены версией и разделом; лишнее убрать и посмотреть, стал ли ответ точнее. Для доступа - перед подключением документа в Knowledge Base проверить его аудиторию и чувствительные разделы, помня, что публикация снимает ограничения Drive. Первая проверка - про точность, вторая - про безопасность.
Типичные провалы двусторонни. С одной стороны - завалить контекст "на всякий случай" и получить размытые ответы, объясняя их тем, что "модель тупит". С другой - опубликовать в общей базе документ, не проверив, кто теперь его увидит, полагая, что права Drive сохранятся. Признак обоих один: контекст наполняют, не спросив, что именно и для кого он добавляет. Сначала ответьте на это - и большинство и промахов точности, и промахов доступа не случится.