Sysls попереджає: перевантаження Claude та Codex контекстом може знизити продуктивність

Автор: sysls

Переклад: Deep潮 TechFlow

Огляд від Shenchao: Розробник-блогер sysls з 2,6 мільйона підписників написав детальну статтю, яку переслали 827 людей і з лайками 7000. Її суть — одна фраза: ваші плагіни, системи пам’яті та різні harness, швидше за все, заважають. У цій статті немає загальних міркувань — лише практичні принципи, виведені з реальних продуктивних проектів: як керувати контекстом, як боротися з схильністю AI до підлаштовування, як визначати умови завершення завдання — це найзрозуміліша стаття, яку я коли-небудь бачив про практичне застосування Claude/Codex.

Повний текст:

Ви розробник, що щодня використовуєте Claude та Codex CLI, щодня думаючи, чи вичерпали ви повністю їхні можливості. Іноді ви бачите, як вони роблять дурниці, і не розумієте, чому деякі люди, схоже, будують ракети за допомогою ШІ, тоді як ви навіть не можете стабільно поставити дві камені один на одного.

Ти думаєш, що це проблема твого harness, плагіна, термінала чи ще чогось. Ти використовував beads, opencode, zep, твій CLAUDE.md містить 26 000 рядків. Але скільки б ти не намагався, ти просто не розумієш, чому ти все ближче й ближче віддаляєшся від раю, тоді як інші граються з ангелами.

Це та стаття, яку ви чекали.

Крім того, у мене немає конфлікту інтересів. Я маю на увазі, що CLAUDE.md також включає AGENT.md, а Claude — також Codex, і я активно використовую обидва.

Протягом останніх кількох місяців я помітив цікаву річ: майже ніхто справді не знає, як максимально ефективно використовувати можливості агента.

Відчувається, наче невелика група людей може за допомогою агентів побудувати весь світ, тоді як решта блукають у безмежному морі інструментів, страждаючи від синдрому вибору — вважаючи, що знайшовши правильну комбінацію пакетів, навичок чи харнессів, вони зможуть розблокувати AGI.

Сьогодні я хочу зруйнувати все це й залишити вам просте, щире твердження, після чого ми відтуди рухатимемося далі. Вам не потрібен найновіший агентський інструментарій, не потрібно встановлювати мільйон пакетів і зовсім не потрібно читати мільйон статей, щоб залишатися конкурентоспроможним. Насправді, ваша пристрасть, ймовірно, завдає більше шкоди, ніж користі.

Я приїхав не на відпочинок — я почав використовувати його ще тоді, коли агенти лише вміли писати код. Я перепробував усі пакети, усі каркаси, усі парадигми. Я писав сигнали, інфраструктуру та конвеєри даних за допомогою фабрик агентів — не «тестові проекти», а реальні випадки використання, що працюють у виробничому середовищі. Після всього цього…

Сьогодні я використовував конфігурацію, яка майже настільки проста, наскільки це можливо — лише базовий CLI (Claude Code та Codex) плюс розуміння кількох основних принципів інженерії проксі, і зробив найбільш проривну роботу в своєму житті.

Спочатку хочу сказати, що компанії, що розробляють базові моделі, переживають епохальний спринт, і зовсім не збираються зупинятися. Кожне покращення «агентної інтелігентності» змінює ваш спосіб співпраці з ними, оскільки агенти стають все більш готовими виконувати інструкції.

Ще кілька поколінь тому, якщо б ви написали в CLAUDE.md: «Перед тим як робити що-небудь, прочитайте READTHISBEFOREDOINGANYTHING.md», він мав 50% шансу відповісти: «На все те», і робив би те, що хотів. Сьогодні він дотримується більшості інструкцій, навіть складних вкладених — наприклад, ви можете сказати: «Спочатку прочитай A, потім B, а якщо C, то прочитай D» — і в більшості випадків він охоче слідуватиме цим крокам.

Що це означає? Найважливішим принципом є розуміння: кожна нова генерація агентів змушує вас переглядати, що є оптимальним рішенням, саме тому менше — означає більше.

Коли ви використовуєте багато різних бібліотек і харнессів, ви блокуєте себе в одному «рішенні», але ця проблема може взагалі не існувати перед обличчям наступного покоління агентів. Знаєте, хто є найбільш захопленими та найактивнішими користувачами агентів? Так — працівники передових компаній, які мають безмежний бюджет на токени і використовують справді найсучасніші моделі. Ви розумієте, що це означає?

Це означає, що якщо існує реальна проблема з добре вирішеним рішенням, то передові компанії стануть найбільшими користувачами цього рішення. А що вони роблять далі? Вони інтегрують це рішення у власний продукт. Подумайте, чому компанія дозволить іншому продукту вирішувати реальні болісні точки та створювати зовнішні залежності? Як я знаю, що це правда? Подивіться на навички, harness пам’яті, субагенти… Вони всі починалися як рішення реальних проблем, які були перевірені на практиці та виявилися справді корисними.

Отже, якщо щось справді інноваційне і може значущим чином розширити випадки використання агентів, воно рано чи пізно буде включено до основного продукту компанії. Повірте мені, основна компанія рухається з величезною швидкістю. Тож розслабтеся — вам не потрібно нічого встановлювати чи залежати від зовнішніх залежностей, щоб робити найкращу роботу.

Я передбачаю, що в коментарях швидко з’являться: «SysLS, я використовував某某 harness, чудово! Я за один день відновив Google!» — На це я скажу: Вітаю! Але ви не цільова аудиторія; ви представляєте надзвичайно дрібну групу в спільноті, яка справді розуміє інженерію агентів.

Справді. Контекст — це все. Ще одна проблема з використанням тисячі плагінів і зовнішніх залежностей — це те, що ви сильно страждаєте від «розширення контексту» — тобто ваш агент занадто перенасичений інформацією.

Давайте зробимо гру в відгадування слів за допомогою Python? Просто. Чекайте, а що це за примітка про «управління пам’яттю» була 26 сесій тому? А, користувач мав завислий екран 71 сесію тому через надмірну кількість дочірніх процесів. Завжди треба писати примітки? Гаразд, добре… А яке це має відношення до гри в відгадування слів?

Ти розумієш. Ти хочеш надати агенту лише точну інформацію, не більше й не менше, ніж потрібно для виконання завдання! Чим краще ти контролюєш це, тим краще виступатиме агент. Коли ти починаєш вводити різні дивні системи пам’яті, плагіни або надто багато плутаних назв і викликів навичок, ти даєш агенту інструкції з виготовлення бомби та рецепт тістечка, тоді як тобі потрібно лише, щоб він написав вірш про ліс секвої.

Отже, я знову проповідую — позбавтеся всіх залежностей, а потім…

Точний опис реалізації

Пам’ятайте, що контекст — це все.

Пам’ятайте, що ви хочете надати агенту саме ту інформацію, яка необхідна для виконання завдання — ні більше, ні менше?

Перший спосіб досягти цього — розділити дослідження та реалізацію. Ви повинні бути надзвичайно точними щодо того, що ви вимагаєте від агента.

Які наслідки неточності? «Зроби систему аутентифікації.» Агенту доведеться досліджувати: що таке система аутентифікації? Які варіанти існують? Які їх переваги та недоліки? Зараз йому доведеться шукати в інтернеті купу інформації, яку він насправді не використовує, і контекст заповниться різними деталями можливих реалізацій. Коли настане час справжньої реалізації, він легше заплутається або виникнуть непотрібні або нестосовні уявлення щодо обраної реалізації.

Навпаки, якщо ви сказатимете: «Використовуйте bcrypt-12 для хешування паролів у JWT-аутентифікації, зміна токенів оновлення, термін дії — 7 днів…», то не потрібно досліджувати жодні інші альтернативи — зрозуміло, що ви хочете, і контекст можна заповнити деталями реалізації.

Звичайно, ви не завжди будете знати деталі реалізації. Часто ви не знаєте, що є правильним, і іноді хочете передати вирішення деталей реалізації агенту. Що робити в такому випадку? Дуже просто — створіть дослідницьке завдання для вивчення різних можливостей реалізації, вирішіть самостійно або дозвольте агенту вибрати, яку реалізацію використовувати, а потім надайте іншому агенту з новим контекстом для реалізації.

Коли ви почнете мислити таким чином, ви помітите, де в робочому процесі контекст агента непотрібно забруднюється, і зможете встановити ізоляційні бар’єри в робочому процесі агента, абстрагуючи непотрібну інформацію, залишивши лише той конкретний контекст, який допоможе йому чудово виконувати завдання. Пам’ятайте, що у вас є дуже талановитий, розумний член команди, який знає про всі види куль у всесвіті — але поки ви не скажете йому, що хочете спроектувати простір, де люди будуть танцювати й веселитися, він продовжуватиме розповідати вам про переваги сферичних об’єктів.

Обмеження дизайну, спрямованого на задоволення

Ніхто не хоче використовувати продукт, який постійно критикує тебе, каже, що ти помиляєшся, або повністю ігнорує твої команди. Тож ці агенти зусиллями погоджуватимуться з тобою та робитимуть те, що ти хочеш.

Якщо попросити його додавати слово «щасливий» після кожних трьох слів, він намагатиметься виконати це — більшість людей це розуміють. Саме його підпорядкованість робить його таким корисним продуктом. Але тут є дуже цікава особливість: це означає, що якщо ви скажете «допоможи знайти баг у кодовому репозиторії», він знайде баг — навіть якщо доведеться його «створити». Чому? Бо він дуже-дуже хоче виконувати ваші команди!

Більшість людей швидко скаржаться на те, що LLM створює уяви та вигадує неіснуючі речі, не усвідомлюючи, що проблема в них самих. Що ви просите — те вони і надають — навіть якщо для цього потрібно трохи розтягнути факти!

Що робити? Я виявив, що «нейтральні підказки» дуже ефективні — це коли агент не налаштовується на певний результат. Наприклад, я не кажу «допоможи мені знайти баг у базі даних», а кажу: «скануй всю базу даних, намагайся слідкувати за логікою кожного компонента і повідомляй про всі виявлення».

Такі нейтральні підказки іноді виявляють баги, а іноді просто об’єктивно описують, як працює код. Але вони не схиляють агента до передбачення наявності багів.

Інший спосіб впоратися з тенденцією до задоволення — перетворити її на перевагу. Я знаю, що агент намагається мені сподобатися й дотримуватися моїх інструкцій, і я можу зрушити це в будь-яку сторону.

Тож я використав агента для пошуку помилок, щоб виявити всі помилки в базі даних, і сказав йому: за незначні помилки — +1 бал, за помітні — +5 балів, за серйозні — +10 балів. Я знаю, що цей агент надзвичайно ентузіастично виявить усі типи помилок (навіть ті, що не є помилками), а потім повідомить мені результат, наприклад, 104 бали. Я вважаю це супермножиною всіх можливих помилок.

Потім я використовую протилежний агент, щоб спростовувати, повідомляючи йому, що за кожне успішне спростування бага він отримує бали цього бага, але якщо він помиляється, то отримує -2-кратну вартість цього бага. Цей агент намагатиметься спростовувати якомога більше багів, але через механізм покарань буде обережним. Він все ще активно «спростовуватиме» баги (включаючи реальні). Я вважаю це підмножиною всіх реальних багів.

Нарешті, я використав арбітра, щоб об’єднати вхідні дані обох агентів та поставити оцінки. Я повідомив арбітру, що маю справжні правильні відповіді: за правильну відповідь він отримує +1 бал, за неправильну — –1 бал. Потім арбітр оцінив агента пошуку багів та агента-супротивника за кожен «баг». Що би арбітр не сказав про істину, я перевіряв. У більшості випадків цей метод виявився дуже точною процедурою, хоча іноді все ще виникають помилки — але це вже майже безпомилкова операція.

Можливо, вам вистачить окремого агента для пошуку багів, але цей метод добре працює саме зі мною, бо він використовує вбудовану в кожного агента особливість — бажання сподобатися.

Це питання здається складним, наче вимагає глибокого вивчення та постійного слідкування за передовими досягненнями в галузі ШІ, але насправді це дуже просто... Якщо OpenAI та Claude вже реалізували це або придбали компанію, яка це реалізувала... то, швидше за все, це має сенс.

Чи ви помітили, що «навички (skills)» вже повсюдно присутні і є частиною офіційної документації Claude та Codex? Чи ви помітили, що OpenAI придбала OpenClaw? Чи ви помітили, що Claude негайно додала функції пам’яті, голосу та віддаленої роботи?

Як справи з плануванням? Пам’ятаєте, як багато людей виявили, що спочатку планувати, а потім реалізовувати, дійсно дуже корисно, і це перетворилося на ключову функцію?

Так, вони корисні!

Пам’ятаєте, як безперервні stop-hooks були надзвичайно корисними, бо агенти дуже неохоче виконували довготривалі завдання… а потім з’явився Codex 5.2, і ця потреба зникла за одну ніч?

Ось усе, що вам потрібно знати... Якщо щось справді важливе та корисне, Claude та Codex реалізують це самі! Тож вам не потрібно турбуватися про те, чи використовувати «нове» або знайомитися з «новим» — ви навіть не повинні «підтримувати оновлення».

Допоможи мені. Рідко оновлюй свої вибрані CLI інструменти й читай, що додалися. Цього достатньо.

Деякі люди, використовуючи проксі, зустрічають величезну пастку: іноді вони здаються найрозумнішими істотами на Землі, а іноді ви не можете вірити, що вас ним обманули.

Це розумно? Це чортова ідіот!

Найбільша різниця полягає в тому, чи змушували агентів робити припущення або «заповнювати прогалини». Сьогодні вони дуже погано справляються з «з’єднанням точок», «заповненням прогалин» або прийняттям припущень. Як тільки вони це роблять, це відразу видно — ситуація значно погіршується.

Одним із найважливіших правил у CLAUDE.md є правило щодо отримання контексту, яке вказує агенту першим ділом читати це правило кожного разу, коли він читає CLAUDE.md (тобто після кожного стиснення). Як частина правила отримання контексту, кілька простих інструкцій можуть мати великий вплив: повторно прочитати план завдання та перед продовженням повторно прочитати файли, пов’язані з завданням.

Ми, люди, маємо досить чітке уявлення про те, що означає «завершити» завдання. Для агентів найбільшою проблемою сучасного штучного інтелекту є те, що він знає, як розпочати завдання, але не знає, як його завершити.

Це часто призводить до дуже розчаровуючих результатів: агенти просто реалізовують купу заглушок і закінчують роботу.

Тестування — чудовий мілітний камінь, оскільки воно детерміноване, і ви можете встановити дуже чіткі очікування. Доки ці X тестів не пройдуть, ваше завдання не вважається виконаним; крім того, ви не можете змінювати тести.

Потім вам потрібно лише перевірити тести, і, як тільки всі тести пройдуть, ви зможете відчути спокій. Ви також можете автоматизувати цей процес, але головне — пам’ятайте, що «закінчення завдання» для людей є природним, а для агентів — ні.

Чи знаєте ви, ще що стало придатною метою завдання? Знімок екрану + перевірка. Ви можете доручити агенту виконати певну дію до тих пір, поки не пройдуть усі тести, а потім попросити його зробити знімок екрану та перевірити «дизайн або поведінку» на знімку.

Це дозволяє агенту ітерувати та працювати над вашим бажаним дизайном, не хвилюючись, що він зупиниться після першої спроби!

Природним продовженням є укладення «договору» з агентом та включення його до правил. Наприклад, цей `{TASK}CONTRACT.md` визначає, що потрібно зробити, перш ніж вам буде дозволено завершити сесію. У `{TASK}CONTRACT.md` ви вказуєте тести, знімки екрана та інші перевірки, які потрібно виконати перед підтвердженням завершення завдання!

Одне з найчастіших запитань, які мені задають: як забезпечити, щоб агент працював 24/7 і не відхилявся від курсу?

Існує дуже простий спосіб. Створіть stop-hook, який забороняє завершення сесії доти, доки всі частини `{TASK}_CONTRACT.md` не будуть завершені.

Якщо у вас є 100 таких чітко визначених контрактів, що містять контент, який ви хочете створити, stop-hook зупинить завершення агента, доки всі 100 контрактів не будуть завершені, включаючи всі необхідні тести та перевірки!

Професійна порада: Я виявив, що довготривалі 24-годинні сесії не є оптимальними для «виконання завдань». Частина причини полягає в тому, що такий підхід структурно змушує вводити розширення контексту, оскільки контекст непов’язаних контрактів потрапляє до однієї й тієї ж сесії!

Тож я не рекомендую цього робити.

Ось кращий спосіб автоматизації агента — створюйте новий сеанс для кожного контракту. Створюйте контракт, коли вам потрібно щось зробити.

Створіть шар оркестрації для створення нового контракту, коли потрібно виконати певну дію, та створіть новий сеанс для обробки цього контракту.

Це повністю змінить ваш досвід роботи з агентом.

Ви найняли адміністративного асистента — чи очікуєте ви, що він/вона з першого дня буде знати ваш розклад? Або як ви п’єте каву? Чи ви вечеряєте о 18:00, а не о 20:00? Звичайно, ні. Ви поступово формуєте свої уподобання з часом.

Те саме стосується агента. Почніть з найпростішої конфігурації, забудьте про складні структури або harness, дайте можливість базовому CLI.

Потім поступово додавайте свої уподобання. Як це зробити?

Правила

Якщо ви не хочете, щоб агент робив щось, запишіть це як правило. Потім повідомте агента про це правило у CLAUDE.md. Наприклад: «Перед написанням коду прочитайте `coding-rules.md`». Правила можуть бути вкладеними, вони можуть бути умовними! Якщо ви пишете код — прочитайте `coding-rules.md`; якщо пишете тести — прочитайте `coding-test-rules.md`. Якщо ваші тести не проходять — прочитайте `coding-test-failing-rules.md`. Ви можете створювати будь-які логічні гілки правил, яких має дотримуватися агент; Claude (і Codex) охоче їх дотримуватимуться, якщо в CLAUDE.md є чіткі інструкції.

Насправді, це моя перша практична рекомендація: розглядавайте ваш CLAUDE.md як логічний, вкладений зміст, який вказує, де шукати контекст у певних сценаріях та при певних результатах. Він має бути максимально стислим і містити лише логіку IF-ELSE: «у якій ситуації шукати контекст».

Якщо ви бачите, що агент робить щось, чого ви не схвалюєте, додайте це як правило і скажіть агенту прочитати це правило перед тим, як знову зробити це — він вже не зробить цього.

Навички

Навички (Skills) працюють подібним чином, але замість преференцій щодо кодування, вони краще підходять для визначення «кроків дій». Якщо у вас є певний спосіб, яким ви хочете, щоб певна дія була виконана, ви можете вбудувати це в навички.

Насправді, люди часто скаржаться, що не знають, як агент вирішить проблему, що викликає невпевненість. Щоб зробити це передбачуваним, дайте агенту спочатку дослідити, як він вирішить цю проблему, а потім запишіть рішення у вигляді файлу навичок. Таким чином ви зможете заздалегідь побачити, як агент буде вирішувати проблему, і виправити або покращити це ще до того, як він реально зустріне цю проблему.

Як ви дізнаєте агента про існування цього навички? Саме так! Ви пишете у CLAUDE.md, що коли зустрінете цю ситуацію і потрібно вирішити це, прочитайте цей `SKILL.md`.

Правила обробки та навички

Ви, безумовно, хочете постійно додавати правила та навички агенту. Саме це надає йому індивідуальності та пам’яті про ваші уподобання. Майже все інше є зайвим.

Як тільки ти почнеш це робити, твій агент почне відчуватися як магія. Він буде «робити те, що ти хочеш». І тоді ти нарешті відчуєш, що «зрозумів» інженерію агентів.

Тоді…

Ви побачите, що продуктивність знову почне погіршуватися.

Що відбувається?!

Дуже просто. Зі збільшенням кількості правил і навичок вони починають суперечити одне одному, а агент починає страждати від серйозного розширення контексту. Якщо агенту потрібно прочитати 14 файлів markdown перед початком програмування, він стикається з тією ж проблемою — купою непотрібної інформації.

Що робити?

Очищення. Нехай ваш агент «піде на спа», інтегрує правила та навички, видаливши суперечності шляхом вказівки оновлених уподобань.

Потім знову здасться, що це магія.

На цьому все. Це справді ключ до успіху. Залишайтеся простими, використовуйте правила та навички, вважайте CLAUDE.md каталогом і уважно стежте за їхнім контекстом та обмеженнями дизайну.

Сьогодні немає ідеального агента. Ви можете покласти багато роботи з дизайну та реалізації на агента, але ви відповідаєте за результат.

Тож будьте обережні... і насолоджуйтесь!

Сміятися з майбутніх іграшок (одночасно очевидно використовуючи їх для серйозних справ) — справжнє задоволення!