Ви перемкнули модель через /model, повторили завдання, і відповідь вийшла іншою. А от CLAUDE.md агент прочитав так само, дозвіл перед командою запитав так само, hook спрацював як раніше. Виходить, усе це живе не в моделі.
Розберімо, де закінчується модель і починається програма навколо неї. Це допоможе зрозуміти, що перевіряти, коли агент помиляється.
Модель і обв'язка
Модель обробляє переданий їй контекст і формує відповідь або запит до інструмента. Наприклад, вибирає, який файл прочитати і яку команду запустити. Щоб виконати ці дії, потрібна програма навколо моделі: вона звертається до файлів, запускає команди і повертає результати моделі.
В англомовних матеріалах таку програму називають harness. Дослівно це "упряж" (так, та сама, для коня), а українською зручніше казати обв'язка. Документація Anthropic формулює прямо: Claude Code - це обв'язка, Claude - модель усередині неї. Слово трапляється і в статтях про агентів загалом, тож запам'ятати його варто.
Обв'язка на схемі збирає контекст, перевіряє дозволи і виконує запити моделі до інструментів. Стрілка під моделлю позначає цикл: результат інструмента повертається в контекст, і модель вибирає наступний крок або завершує відповідь. Завершена відповідь ще не доводить, що завдання розв'язане. Результат усе одно треба перевірити.
Що ви вже налаштовували
Ось як частини обв'язки виглядають у Claude Code. Файли й команди в правій колонці допоможуть знайти кожен механізм у проєкті або сесії.
| Частина обв'язки | Що робить | Де її знайти |
|---|---|---|
| Системні інструкції | Claude Code додає їх у контекст до вашого першого повідомлення: як працювати, які є інструменти, у якій теці йде сесія | рядок System prompt у виводі /context |
CLAUDE.md | правила проєкту, які агент читає на початку сесії | файл у корені проєкту |
| Інструменти | читання і правка файлів, пошук, команди в терміналі | рядки на кшталт Read(...) і Bash(...) під час роботи |
| Skills | інструкції, які модель може вибрати під завдання або ви можете викликати явно | .claude/skills/, /skills |
| MCP | міст до зовнішніх сервісів і живих даних | /mcp |
| Субагенти | окремий виконавець зі своїм контекстом | .claude/agents/ |
| Запити дозволу | обв'язка перевіряє, чи дозволена дія; за потреби питає вашої згоди | запитання в терміналі перед командою або правкою |
| Hooks | ваші команди на події сесії, спрацьовують без рішення моделі | /hooks |
| Контекст і сесія | що модель бачить саме зараз і до якого моменту можна повернутися | /context, /clear, /rewind |
| Агентний цикл | повертає результати інструментів моделі, щоб та вибрала наступний крок | кілька дій поспіль у відповідь на один запит |
CLAUDE.md і skills дають моделі інструкції. Модель може неправильно зрозуміти або пропустити правило. Перевірка дозволів і команди в налаштованих hooks виконуються програмно, тобто їхній результат залежить від заданих умов і самих команд.
Plugins у таблицю не потрапили, бо це не окрема частина, а пакет: кілька skills, команд або hooks, які встановлюються однією дією.
Одна модель, різна поведінка
Візьмімо вебчат без підключення до вашого проєкту і термінала. У нього своя обв'язка: історія розмови, інтерфейс, іноді пошук в інтернеті або завантаження файлів. У такому чаті модель може пояснити правку і показати код, а Claude Code з доступом до проєкту може внести її у файл. Модель та сама, можливості різні, бо різна програма навколо.
З /model усе навпаки. модель змінюється, обв'язка лишається тією самою, тому правила, інструменти і запити дозволу нікуди не зникають.
Від моделі залежить, як вона розуміє завдання, вибирає інструменти й оцінює їхні результати. Натомість обв'язка збирає контекст, надає інструменти і перевіряє дозволи. Наприклад, модель може попросити файл, якого бракує, а обв'язка виконає читання і поверне його вміст.
Агент упевнено міркує про функцію, якої в проєкті давно немає? Спершу перевірте, чи потрапив актуальний код у контекст. Його можна передати через @ зі шляхом до файлу, вставити в повідомлення або отримати через інструмент читання. Окремого виклику читання в перших двох випадках може й не бути. Якщо інструмент викликався, подивіться, що він повернув: вміст файлу чи помилку доступу або шляху. Якщо коду в контексті немає, передайте його або попросіть прочитати файл. Якщо код уже є, але висновок хибний, перевірте міркування за конкретними рядками. Тут інша модель теж може допомогти.
Що виправляти, якщо агент помиляється
Разову помилку найпростіше виправити реплікою: "не той файл, подивись у src/utils.js". Якщо ж помилка повторюється із сесії в сесію, варто перевірити інструкції і доступні дані. Можливо, потрібне правило щоразу доводиться пояснювати заново, і так по колу.
На практиці це виглядає приблизно так:
- агент у кожній сесії забуває правило проєкту, наприклад що тести запускаються через
npm test, - правило треба записати вCLAUDE.md. Важливе правило надійніше явно зберегти в цьому файлі, ніж розраховувати на нагадування в листуванні; - ту саму процедуру ви пояснюєте втретє - час винести її в skill. Агент зможе підвантажити інструкцію під завдання. Перевірте під час роботи, що skill було викликано; якщо ні, викличте його самі через
/skill-name, підставивши його справжнє ім'я; - агент гадає про дані, яких у нього немає, - передайте потрібні дані: додайте файл у контекст через
@або підключіть зовнішній сервіс через MCP. Умовляннями вгадування не вилікуєш; - агент пише "готово", не запустивши перевірку, - hook на подію
Stopможе запускати тести сам, без рішення моделі. Приймаєте роботу все одно ви, за виводом команди, а не за звітом; - потрібні дані доступні й прочитані, але агент плутається в складному міркуванні - спробуйте іншу модель через
/modelі порівняйте результат на тому самому завданні.
Спершу перевірте, чи доступні потрібні дані та інструменти. Якщо складність у міркуванні, іншу модель можна спробувати одразу. Порівнюйте якість результату і витрати в /usage (повторні невдалі спроби теж витрачають ліміт і ваш час, про це легко забути).
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ