Знакомая ситуация: подключаешь к LLM-агенту двадцать тулзов, расписываешь каждому system prompt, отлаживаешь схемы аргументов — и через неделю понимаешь, что для новой задачи нужен ещё один инструмент. И ещё. И ещё. Каждый раз — деплой, тесты, регрессия. А модель тем временем тонет в раздутом списке тулзов и начинает путаться, кого вызывать.
Проект Tendril от serverless-dna предлагает выйти из этой колеи радикально: не давать агенту фиксированный набор функций вообще. Только три bootstrap-инструмента — и всё остальное он построит себе сам.
Что это вообще такое
Tendril — это саморасширяющаяся агентская песочница, демонстрирующая паттерн Agent Capability. Идея на пальцах: ты просишь сделать что-то, агент проверяет свой реестр возможностей, и если нужного инструмента нет — он пишет его прямо сейчас, регистрирует, выполняет и кладёт на полку до следующего раза.
Из README репозитория хорошо видно, как это выглядит на практике:
You: "fetch the top stories from Hacker News"
Tendril:
→ searchCapabilities("fetch url hacker news") # ничего не нашлось
→ registerCapability(fetch_url, code) # пишет инструмент
→ execute("fetch_url", {url: "..."}) # запускает по имени
→ "Here are the top stories: ..."
You: "now fetch Lobsters and compare"
Tendril:
→ listCapabilities() # уже есть: fetch_url ✓
→ execute("fetch_url", {url: "https://lobste.rs"})# никаких пересборок
Каждая следующая сессия умнее предыдущей. Реестр накапливается, и через пару недель использования у тебя появляется персональная экосистема инструментов, заточенных именно под твои задачи.
Архитектура: почему именно три инструмента — это гениально
Самое интересное в Tendril — архитектурное решение, которое автор называет «too many tools» solution. Большинство современных агентских фреймворков идут путём «дать модели большой мешок тулзов и надеяться, что она выберет правильный». Чем больше задач — тем больше мешок. Чем больше мешок — тем хуже модель ориентируется.
Tendril инвертирует подход. Модель всегда видит ровно три инструмента:
🛠️ listCapabilities / searchCapabilities — посмотреть, что уже есть в реестре
🛠️ registerCapability — зарегистрировать новый инструмент с описанием, триггерами и кодом
🛠️ executeCode — выполнить зарегистрированный инструмент по имени
Поверхность тулзов не меняется никогда, а вот возможности (capabilities) растут. И вот тут возникает момент, который мне лично нравится больше всего: ключевое архитектурное ограничение Tendril — отсутствие прямого выполнения кода. Агент физически не может «просто запустить» что-то на лету. Чтобы что-то выполнить, он обязан сначала формально описать инструмент: имя, capability, триггеры (когда вызывать), suppression (когда не вызывать). Это превращает невнятное «модель что-то сгенерировала» в дисциплинированное «модель явно задекларировала новый паттерн поведения».
Что под капотом
Вот тут интересно, потому что стек довольно зрелый:
⚙️ Агентский фреймворк — AWS Strands Agents SDK на TypeScript. Это относительно свежий SDK от Amazon для построения агентов
⚙️ Инференс — AWS Bedrock, конкретно Claude Sonnet 4.5 (us.anthropic.claude-sonnet-4-5-20250514 в дефолтном конфиге)
⚙️ Песочница для выполнения кода — Deno-сабпроцесс с явными permission-флагами. Выбор Deno здесь не случаен: в отличие от Node, Deno изначально проектировался с моделью «всё запрещено по умолчанию», и доступ к сети, файлам, env-переменным выдаётся гранулярно через флаги вроде --allow-net=api.example.com
⚙️ Десктоп-оболочка — Tauri 2.x (Rust + WebView), фронтенд — React 18 + TailwindCSS v4
⚙️ Транспорт между Rust-хостом и Node.js-агентом — JSON-RPC 2.0 over NDJSON на stdin/stdout. Агент собран как Node.js Single Executable Application (SEA) и спавнится как сайдкар
⚙️ Протокол — ACP (Agent Integrator Specification), тот самый, который использует Claude Code и подобные агентские хосты
Реестр устроен максимально просто и человекочитаемо — это меня лично подкупает:
~/tendril-workspace/
index.json ← реестр
tools/
fetch_url.ts ← TypeScript, выполняется в Deno
summarize_text.ts
parse_json.ts
Никакой магии, никакой бинарной БД — обычные файлы. Можно открыть глазами, отредактировать, удалить. Это огромный плюс с точки зрения прозрачности и отладки.
Системный промпт — где живёт автономность
Из исходников видно, что вся «автономность» агента упакована в довольно лаконичные правила в loop/prompt.ts:
📜 Перед любым действием — проверить реестр через searchCapabilities
📜 Если нашлось — загрузить и выполнить
📜 Если не нашлось — обязан построить инструмент сам, без вопросов
📜 Прямой запрет на фразы вроде «хотите, я создам инструмент?». Tendril не спрашивает разрешения — он действует
📜 Если инструмент упал — прочитать ошибку, поправить код, повторить
📜 Никогда не отвечать из training data, если живой инструмент мог бы получить актуальную информацию
Этот последний пункт особенно показателен. Это, по сути, попытка решить классическую проблему галлюцинаций административно: «не помнишь — иди и достань».
Формализация и обещание монотонного роста
В оригинальной новости упоминается, что архитектура описана в исследовании MARIA OS, где агент представлен как состояние X_t и оператор саморасширения X_{t+1}. Идея в том, что переход между состояниями монотонно расширяет множество возможностей: что один раз построено и зарегистрировано — остаётся в реестре. Возможности могут добавляться, но не теряться спонтанно.
Здесь, конечно, нужно быть честным: «теоретически гарантирует» — это не «гарантирует на практике». Реальная монотонность зависит от того, насколько корректно модель описывает триггеры и suppression-правила. Плохо описанный триггер может привести к тому, что инструмент будет вызываться невпопад, и эффективная capability упадёт, даже если формально она в реестре есть. Но как направление мысли — мне это нравится: впервые за долгое время кто-то пытается дать агентскому росту хоть какую-то формальную модель, а не очередной маркетинговый «emergent reasoning».
Что я думаю обо всём этом
Я довольно скептически смотрю на большую часть «agentic» хайпа, но Tendril мне нравится по нескольким причинам.
Во-первых, дисциплина через ограничения. Запрет на прямое выполнение кода — это не баг, это фича. Любой, кто пытался отлаживать агента, который «иногда что-то запускает на питоне, чтобы посчитать», знает, насколько это становится невозможно поддерживать. Когда агент обязан сначала формально объявить tool с триггерами — у тебя появляется trail, который можно ревьюить.
Во-вторых, прозрачность реестра. Файлы на диске — это правильно. Никаких векторных баз, никаких эмбеддингов «памяти», которые потом не воспроизвести. Хочешь форкнуть свой workspace — просто скопировал папку.
В-третьих, выбор Deno как песочницы. Это технически грамотное решение. Многие самодельные агенты запускают сгенерированный код через subprocess.run('python', ...) без какого-либо ограничения сети и ФС, и это работает ровно до первого «pip install requests» от модели в production-окружении. У Tendril через allowedDomains в конфиге можно жёстко ограничить, куда инструменты могут ходить.
Что меня настораживает: пока проект совсем молодой (на момент написания — 0 звёзд, 145 коммитов, версия 0.1.6, единственный контрибьютор), и вся «магия» сильно зависит от того, насколько хорошо Claude через Bedrock следует системному промпту. Если на каком-то шаге модель решит «а, потом зарегистрирую» и начнёт галлюцинировать ответы — вся монотонность рассыпается. Эта проблема не уникальна для Tendril, но именно в саморасширяющейся системе цена ошибки выше: некорректно зарегистрированный tool будет тянуться через все последующие сессии, пока его не вычистят руками.
Куда это всё идёт
Tendril — не первая попытка дать агенту умение писать себе тулзы. Нечто похожее было в Voyager (агент для Minecraft, который наращивал «skill library»), есть концептуальные параллели с CodeAct, ToolMaker и прочими исследовательскими работами. Но Tendril ценен тем, что это не paper с псевдокодом, а рабочее десктоп-приложение с понятным стеком, которое можно склонировать и запустить.
Если экстраполировать тренд, я думаю в ближайший год мы увидим сразу несколько таких проектов, и ключевой battleground будет не в самой идее самописных тулзов, а в:
🔮 Качестве sandbox-изоляции — как далеко можно отпустить агента, чтобы это не превратилось в supply-chain ад
🔮 Шарингe реестров между пользователями — представь маркетплейс community-built capabilities, где можно подтянуть чужие проверенные инструменты
🔮 Версионировании и rollback'ах — что делать, когда модель «починила» инструмент, а сломала три других сценария
🔮 Автоматическом депрекации — capabilities, которые годами не вызывались, должны как-то ротироваться, иначе реестр превратится в свалку
В любом случае, это правильное направление. Статичные агенты с вшитым набором функций — это тупиковая ветка ровно по той же причине, по которой статичные веб-сайты конца 90-х уступили динамическим. Гибкость всегда выигрывает. Tendril, кажется, нащупал работающий компромисс между «полная свобода = хаос» и «жёсткий tool-set = ограниченность».
И мне очень любопытно, что будет дальше.
Источники
🔗 Репозиторий проекта: https://github.com/serverless-dna/tendril
🔗 Полная версия статьи: https://telegra.ph/Kogda-II-sam-kuyot-svoi-instrumenty-kak-Tendril-menyaet-pravila-igry-agentskogo-II-04-27
🔗 AWS Strands Agents SDK: https://github.com/strands-agents/sdk-typescript
🔗 Tauri framework: https://tauri.app
🔗 Deno runtime: https://deno.com