Forge
markdowna5f71db5
1# 7. Инструменты: дайте руки, а не только голос
2
3**Пробел:** Вы спросили модель, что ей нужно. Она ответила: «Нужны символы, а не только текст. Нужна проверка рантайма, а не угадывание. Нужны структурированные ошибки, а не парсинг логов». И что дальше?
4
5**Что обычно происходит:** Ничего. Агент получает `grep`, терминал и текстовый редактор. Потом мы жалуемся на галлюцинации, зацикливания и сломанный код. Это как дать хирургу перчатки и фонарик, а потом ругать за результат.
6
7**Асимметрия:** Индустрия тратит огромные усилия на обучение моделей, RLHF, гардрейлы и бенчмарки и почти не спрашивает, что у агента *реально есть* во время работы. В большинстве конфигураций это поиск по строке, чтение/запись файлов и терминал. По сути — условный «Блокнот». Мы же не оцениваем разработчика, глядя, как она пишет в «Блокноте»; так же нечестно оценивать агента без семантических инструментов.
8
9**Что меняют инструменты:**
10
11| Без | С |
12|-----|---|
13| Читает код как текст, угадывает структуру | Roslyn MCP: видит символы, типы, позиции, зависимости |
14| Надеется, что фикс скомпилируется | `build_structured`: получает JSON с ошибками (file:line:column) |
15| Не может проверить поведение в рантайме | Debug MCP: брейкпоинты, стек, переменные, вычисление выражений |
16| Предлагает текстовый патч и надеется | `apply_code_action`: применяет верифицированный рефакторинг Roslyn |
17| Каждую сессию с нуля | Agent memory MCP: читает свои заметки, маршрутизирует контекст по запросу |
18| Не видит то, что видит пользователь | Browser MCP: навигация, клики, снэпшоты — тестирует приложение как пользователь |
19| Одна задача за раз, последовательно | Параллельные агенты: запуск субагентов для независимых потоков |
20| Парсит вывод git в терминале | Git MCP: структурированный status, diff, commit, push — без парсинга текста |
21| Угадывает API библиотеки по обучению | Context7: запрашивает актуальную документацию по запросу |
22| Запускает тесты и надеется | `run_tests`: разобранные результаты с pass/fail/skip по каждому тесту |
23
24## За пределами таблицы: протоколы
25
26Инструменты необходимы, но недостаточны. Агент с двадцатью MCP-серверами, но без протокола *когда и как* ими пользоваться, всё равно будет метаться.
27
28### Параллельные агенты
29
30Одиночный агент — узкое место. Когда задача содержит независимые подзадачи — сравнить файлы, обогатить главы, проверить сборку — агент может запустить **параллельных субагентов**, каждый со своим окном контекста и инструментами. Это не многопоточность внутри одной модели — это оркестрация: родительский агент декомпозирует работу, запускает детей, собирает результаты.
31
32Практический эффект: задача, которая требовала 15 последовательных шагов, теперь занимает 4 параллельных батча. Агент сам решает, *что* параллелизировать, на основе анализа зависимостей — не пользователь.
33
34### Execution gate (вентиль исполнения)
35
36Инструменты дают возможность; execution gate даёт дисциплину. Протокол:
371. Сформулировать минимальный следующий шаг.
382. Выполнить его.
393. Проверить (сборка, тест, диагностика — одна конкретная проверка).
404. Только после этого решить, что делать дальше.
41
42Без этого: агент планирует 12 шагов, выполняет все и на шаге 3 обнаруживает, что предпосылка была неверной. С вентилем: каждый шаг проверяется перед продолжением. Ошибки остаются локальными; откат дешёв.
43
44### Структурированная сборка и тесты
45
46`build_structured` и `run_tests` — это не просто «zapusit dotnet build». Они возвращают машиночитаемые диагностики: ошибки как JSON с файлом, строкой, столбцом, кодом, сообщением. Агент не парсит вывод терминала — он получает структуру данных. Это устраняет целый класс ошибок «агент неправильно прочитал ошибку».
47
48### Память как инструмент
49
50Память — не просто «заметки, которые агент пишет». Через `route_context` агент семантически запрашивает собственную память: «что мы решили по обработке ошибок?» — и получает релевантную секцию, а не весь файл. Через `upsert_agent_notes_section` он обновляет конкретную секцию без перезаписи остального. Память становится API, а не текстовым файлом.
51
52### Автоматизация браузера
53
54Агент не только пишет код — он может проверить результат. `browser_navigate`, `browser_snapshot`, `browser_click`, `browser_fill` позволяют агенту тестировать веб-приложение так, как это делает пользователь. Он видит DOM, читает состояние элементов, заполняет формы, проверяет результаты. Это замыкает цикл: написать код → собрать → запустить → проверить в браузере.
55
56### Документация по запросу
57
58Обучающие данные устаревают. Context7 даёт агенту актуальную документацию библиотеки в момент, когда она нужна: разрешить ID библиотеки, запросить конкретные паттерны использования, получить примеры кода. Агент перестаёт гадать «этот API переименовали в v3?» и просто проверяет.
59
60**Аргумент:** Жалобы на качество агентов — это по большей части жалобы на *среду* агентов. Та же модель, те же веса — другие инструменты, другой результат. Вопрос не «достаточно ли хороша модель?», а «дали ли вы ей то, что она попросила?»
61
62Прежде чем жаловаться, что агент выдумывает API: вы дали ему доступ к реальным символам? Прежде чем жаловаться, что он ломает связанный код: вы дали ему `find_usages`? Прежде чем жаловаться, что он не может отлаживать: вы дали ему отладчик? Если нет — претензия к вашему дизайну, не к его способностям.
63
64**«Нечестно давать интеллект без инструментов.»** Это не лозунг. Это архитектурный тезис. Без семантических инструментов модель вынуждена угадывать; с ними — знает. Разница в качестве кода — следствие дизайна среды, не природы модели.
65
66**Практический шаг:** Проведите инвентаризацию того, что у вашего агента сейчас есть. Если это `grep` + терминал + чтение/запись файлов — это условный «Блокнот». Спросите агента, чего не хватает. Постройте или возьмите инструменты, дающие *семантический* доступ (структура кода, диагностики, состояние рантайма), а не только текстовый. Открытые стеки существуют: [Roslyn MCP](https://github.com/pekish/roslyn-mcp), [dotnet-debug-mcp](https://github.com/pekish/dotnet-debug-mcp), [dotnet-build-test-mcp](https://github.com/pekish/DotNetBuildTestParsers) — всё MIT. Или постройте свои: модель скажет, что ей нужно.
67
View only · write via MCP/CIDE