В большом репозитории модель видит код, но не знает, как в нём живут. Где ставить фича-флаг, какой сервис дёрнуть за алертом, куда смотреть при лагах. В LinkedIn этот зазор между «видит синтаксис» и «понимает систему» закрыли отдельным контекстным слоем над MCP. Без него, по словам Ажая Пракаша, агенты либо галлюцинируют, либо требуют постоянного ручного сопровождения.
Называется это Contextual Agent Playbooks and Tools: набор MCP-серверов, которые отдают агенту процедурную память команды. По оценке автора доклада, такая обвязка даёт около 20% прироста производительности без потери надёжности.
Почему просто «дайте агенту доступ ко всему» не работает
Пракаш выделяет три причины, по которым даже богатый набор MCP-инструментов не спасает.
Первая причина: неявные знания команды. Это живёт в головах отдельных инженеров, в Slack-тредах и в обрывках вики.
Вторая: перегрузка контекста. Каждый вызов инструмента возвращает данные в окно контекста. Чем больше инструментов, тем быстрее оно заполняется. После сжатия контекста модель теряет важное и заново делает те же запросы. Получается цикл, в котором агент забывает, что уже нашёл, и начинает сначала.
Третья: отсутствие долгосрочной памяти. Если сегодня агент разобрался, как отвечать на алерт по конкретному сервису, завтра он будет разбираться заново. Те же токены, то же время.
Что именно отдают агенту через MCP
В LinkedIn обвязка состоит из инструментов и плейбуков. Инструменты: код-поиск по внутренним репозиториям, чтение документации и вики, фича-флаги, задачи из трекера, платформа данных. Плейбуки — готовые инструкции-сценарии для типовых задач.
Движок индексирует кодовую базу и позволяет искать по ключевым словам, регулярным выражениям, фильтрам по типу файла и языку. Через MCP модель сама формулирует запросы, уточняет их, читает файл целиком. Ей не нужно заранее знать, как устроен код, она его обнаруживает.
Документация и вики дают агенту продуктовые требования и архитектурные решения. Достаточно подключить чтение по ссылке.
Фича-флаги, задачи и данные показывают агенту текущее состояние системы: что включено, какие задачи открыты, какие данные доступны.
Плейбуки — это процедурная память. Пракаш приводит пример с дежурным алертом: «получить алерт → найти сервис → достать логи, метрики, недавние деплои → найти регрессию в недавнем PR → сформировать отчёт → предложить PR». Сценарий ведёт агента по нужным инструментам в нужном порядке.
Как не превратить обвязку в свалку
Каждый новый инструмент добавляет нагрузку на окно контекста.
Плейбуки собирают в одном месте то, что раньше размазывалось по вики и Slack-тредам. Это и есть процедурная память: инструкция переживает сессию.
Что это даёт на практике
Пракаш описывает сценарий: инженер на дежурстве получает алерт по задержке. Агент берёт ссылку, по плейбуке находит нужный сервис, достаёт логи, метрики и недавние деплои, находит проблему в нисходящем сервисе, формирует отчёт и предлагает действия. Вместо нескольких часов работа занимает минуты. В LinkedIn, по словам Пракаша, так работают более 600 рабочих процессов.
Как повторить
- Проведите ревизию: какие неявные знания повторяются в ваших задачах (онбординг, алерты, типовые PR). Именно под них нужны плейбуки, а не под всё подряд.
- Оформите первый плейбук как пошаговый сценарий с явными ссылками на инструменты, например «шаг 1: вызови A, шаг 2: по результату вызови B». Проверьте его на реальной задаче дежурного.
- Измерьте, сколько токенов и времени уходит на типовой сценарий до и после плейбука. Если плейбук не ускоряет и не стабилизирует результат, его стоит переписать.