Агенту потрібен набір базових інструментів

Бачу, що всі обговорюють питання набору інструментів для агента — чи достатньо просто надати оболонку (shell), і все буде готово? Після роботи з holon зрозумів, що насправді все не так просто.
Читаючи: чому відмовилися від Read/Glob і перейшли повністю на shell
Набір інструментів holon змінювався кілька разів, і в кінцевому підсумку відмовилися від таких спеціалізованих інструментів, як Read (читання файлу) або Glob (патерн пошук), які пропонували Claude Code, і всі операції читання та пошуку тепер виконуються через shell. Це збігається з підходом Codex — у нього команда ExecCommand одна, читання файлу — це cat, пошук коду — це rg, і не визначають окремий інструмент для кожної "читальної" операції.
Причина такого підходу дуже проста: shell — це найзнайоміша "мова програмування" для LLM. Замість того, щоб змушувати модель вчитися параметричний семантику Read, краще дати їй написати вже натреновані мільярдами команд shell. Кожен додатковий спеціалізований інструмент збільшує когнітивне навантаження моделі; а shell — це вже знайомий інтерфейс, і модель у ньому досить вправна.
Але повністю перейти на shell має свою ціну: обмеження виводу. Щоб уникнути надто довгих відповідей, які можуть "завалити" контекст, фреймворк встановлює обмеження на довжину вихідних даних кожної команди. Наприклад, Agent використовує cat для читання великого файлу, але може отримати лише його першу частину, решту — у файлі artifact, і щоб прочитати все, потрібно знову викликати cat кілька разів. Read у Claude Code має набагато вищий поріг стиснення, і читання великих файлів відбувається одним рухом, без зайвих пересилань. По суті, це компроміс: менше визначених інструментів — менше когнітивного навантаження, але спеціалізовані інструменти більш ефективні у прикордонних сценаріях.
Пишучи: від sed до ApplyPatch і проблеми з free grammar tool
Але операції запису вже не можна повністю покрити через shell.
Якщо змусити агента редагувати лише за допомогою sed, то виникають труднощі з багаторядковим пошуком — переноси рядків, екранізація, відступи — будь-яка помилка може призвести до невдачі редагування. Тому багато систем пропонують інструменти типу Replace String, що дозволяють точно знайти та замінити фрагмент тексту, передаючи старий рядок (old_string) і новий (new_string). Це менш зручно, ніж sed, але набагато стабільніше.
Codex пішов далі і створив власний інструмент ApplyPatch, що дозволяє агенту безпосередньо генерувати патчі для масового редагування. holon теж запозичив цю ідею.
Але при реалізації виникла проблема: Codex використовує власний спрощений формат патчів, а також застосовує спеціальний механізм — free grammar tool — для передачі форматів.
Чому потрібен саме цей новий механізм? Тому що стандартне визначення інструментів для LLM — tool(args), де args — JSON-подібні параметри. Якщо передавати патч у вигляді JSON-рядка, доведеться багато екранування: переносити рядки, додавати зворотні косі риски для лапок, обережно обробляти відступи. Написати патч — вже складно, а додаткове екранування JSON збільшує ймовірність помилок у рази. Ідея free grammar tool — передавати текст патчу безпосередньо як вхідний текст інструменту, без JSON-екранування, і модель буде писати що завгодно. Це значно знижує ймовірність помилок при генерації патчів.
На даний момент ця система підтримується лише через API OpenAI Codex. holon прагне бути сумісним з різними провайдерами моделей, тому не може покладатися лише на цей механізм.
Тому holon реалізує різні варіанти ApplyPatch залежно від моделі: для моделей, що підтримують free grammar, використовується оригінальний формат патчу; для інших — стандартний git diff. Я вважаю, що LLM, натреновані на мільярдах diff з GitHub, досить добре розуміють git diff. Практика показує, що цей підхід працює — хоча іноді і помиляється, але в більшості випадків редагує правильно, і з накопиченням даних ця здатність тільки покращується. Втім, я закликаю всіх виробників моделей підтримувати free grammar tool, адже для сценаріїв написання коду агентом це справжня необхідність.
Організація: довготривалі команди та абстракція задач
Третя проблема — команда shell, яку виконує агент, може тривати дуже довго: запуск dev-сервера, тестування, збірка проекту — все це може займати багато часу або й ніколи не завершитися. У ранніх фреймворках агентів це вирішували грубо: або синхронно блокувалися, або запускали всі команди у фон, і тоді агент міг повторювати одне й те саме завдання багато разів.
Зараз у галузі поступово сформувався базовий консенсус: не варто давати агенту вибір "передній/фоновий режим" — цю задачу агент сам визначити не може. Краще встановити тайм-аут, після якого команда автоматично переводиться у фоновий режим, і агент про це не дізнається. Агенту не потрібно передбачати, чи варто ставити команду у фон — все робить runtime.
Але автоматичне переведення у фон — лише перший крок. Після цього виникають справжні інженерні питання — і поки що у галузі немає єдиного стандарту.
Перш за все — як читати вихідні дані. Фонові задачі можуть ще працювати або вже завершилися, і вихідних даних може бути багато. Але API у різних систем мають різну семантику: одні використовують опитування (polling), інші — події (event-driven).
Далі — як зупинити задачу. У кожної системи є механізми скасування, але чи потрібно негайно вбивати процес, чи краще дочекатися "гарної" зупинки, і чи зберігати вже отриманий вихідний результат?
І нарешті — хто має "пробудити" агента. Після того, як задача пішла у фон і агент "заснув", хто її розбудить, коли вона завершиться? Це вимагає глибокого зв’язку між runtime і менеджером задач, і не може бути вирішено лише на рівні інструментів.
Ці три аспекти — читання вихідних даних, зупинка задачі, пробудження агента — разом формують повний цикл управління фоновими задачами. Всі реалізують можливість запуску у фоні, але стандарту управління ще немає, і це може стати ключовим етапом розвитку агентських інструментів.
Ще не час просто застосовувати готові шаблони
Повертаючись до початкового питання: shell вирішує 80%, але решту 20% — точність редагування, відповідність формату патчу можливостям моделі, абстракція довгих задач — саме ці моменти визначають, чи зможе агент перейти від демонстраційної версії до справді робочої системи.
Вибір інструментарію — це не просто "загорнути shell", і ще не час бездумно застосовувати готові шаблони. Саме тому у різних системах, таких як Codex і Claude Code, відповіді на ці базові питання різняться, а holon підходить до них по-своєму, з урахуванням своїх сценаріїв. В цьому просторі ще багато для досліджень і покращень.