Ранее я уже писал, что skills, hooks и агенты должны жить в git, а не в домашней папке у каждого разработчика как связанный Грааль. В комментариях справедливо заметили: между «конфиг в git» и «конфиг реально работает» обычно сидит ручная сверка.

Но вот с агентами этот разрыв ещё глубже. Skill может лежать в репозитории, пройти ревью, задеплоиться и при этом не загрузиться.

Пример, после которого я перестал считать это теорией В наборе agent-skills Эдди Османи четыре агента не загружались в Claude Code, среди них code-reviewer и security-auditor. При этом явный список агентов в манифесте плагина подавлял их обнаружение. До исправления Claude Code показывал Agents (0), а после их стало четыре. При этом плагин всё это время работал. Пользователи получали ответы, код писался. Но вот проверк безопасности не было ни у кого, кто ставил плагин, и этого никто не видел.

Почему что-то в AI разработке ломается незаметно Агент состоит из модели и обвязки (это как раз таки Harness): промпты, контекст, инструменты, права, скиллы, субагенты, хуки, MCP, ретраи, сжатие контекста. Поведение же рождается из их сочетания. Когда обвязка отказывает, модель часто достраивает недостающее сама. При это делает это абсолютно легитимно. Документация Claude Code описывает это прямо: субагент не наследует skills родителя, но с доступом к файлам может найти их сам, просканировав каталог. При это модель может найти нужные skills, а может и нет. Skill про стиль комментариев не дошёл, субагент увидел соседние комментарии и скопировал стиль. Вроде бы результат выглядит правильно, а вот сломанный путь как так получилось не виден.

И тут я прихожу к такой формулировке: сильная модель не делает обвязку надёжнее... она лучше прячет её дефекты.

Это тот же механизм, что и с тестами, которые написал тот же агент, что и сам код. Проверка «результат выглядит правильно» разделяет приор модели, поэтому пропускает ровно то, что модель достроила.

Проверка уровня целостности Ранее я также писал, что стоит разделять целостность и смысл. Загрузился ли скилл, какой инструмент вызван, что вернул MCP — это всё вопросы первого уровня. Ответ тут вполне наблюдаемый. Поэтому это можно логировать целиком. И вот если ваша команда этого не делает, то не достижение образа результата это уже не проьоема сложности поставленной задачи.

Что логировать Имхо можно и нужно 1. логировать загрузку скилла по каждому субагенту на каждой задаче. Отсюда главная метрика: доля задач, где скилл должен был сработать и он реально сработал 2. подвергнуть логированию все фактические вызовы инструментов и особенно те случаи, когда агент правит файлы через shell вместо штатных инструментов чтения и записи 3. логировать сырой ответ MCP, а не пересказ модели 4. аудит терминальных статусов субагентов структурным полем - проверять сами ли они завершились или родитель так решил по тексту 5. Всегда учитывать модель, на которой реально работал субагент.

FYI Антропик в обновлении@ 2.1.0 чинили случаи, когда субагент не наследовал модель родителя.

Версия обвязки всегда должна быть частью сборки Каждый релиз Claude Code меняет поведение обвязки. Например, в версии 2.1.210 исправили поведение, при котором субагенты с изоляцией в worktree могли выполнять git-команды в основном репозитории.

Поэтому версия инструмента должна фиксироваться и логироваться в каждый прогон, рядом с версией конфигурации и моделью.

И все это для того, чтобы через месяц/год вы четко знали, на какой версии обвязки собран код с дефектом.

Как эксперимент можете задать своей команде после нескольких релизов с дефектами простой вопрос: "А вы точно знаете, что скилл, который породил дефект есть? Можете доказать, что он был?"

#разработка #архитектура #ai #ит #devops #агенты #наблюдаемость