Продовжуємо аналізувати патерни проектування агентів з репозиторію https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools і після розбору XML-тегів у першій частині переходимо до наступного ключового елемента.
Йтиметься про механізм списку завдань (To-Do list) — один із найважливіших і найчастіше вживаних патернів у просунутих системних промптах. Його реалізація та цілі можуть сильно відрізнятися.
Список агентів і рішень, які використовують механізм To-Do List або аналогічні системи планування:
- Augment Code
- Claude Code
- Cursor Prompts
- Kiro
- Manus Agent Tools & Prompt
- Codex CLI
- Qoder
- Same.dev
- Trae
- v0 Prompts and Tools
- VSCode Agent
- Windsurf
- Z.ai Code
- Traycer AI
1. Augment Code
- Як реалізовано: Через формальний набір інструментів (
add_tasks
,update_tasks
,reorganize_tasklist
). Промпт приписує чіткі стани для кожної задачі, які, ймовірно, відображаються в UI:[ ]
(не розпочато),[/]
(у процесі),[x]
(завершено). - Особливості та ціль: Тут
todo list
— це інструмент для управління складними, багатоступеневими задачами. Промпт вводить тригери (Tasklist Triggers
у версії для GPT-5), які змушують агента використовувати цей механізм за певних умов (наприклад, якщо зміни стосуються кількох файлів). Ціль — структуризація роботи та інкрементальне, кероване виконання.
2. Claude Code
- Як реалізовано: Через інструмент
TodoWrite
. Промпт вимагає використовувати його дуже часто (VERY frequently
). - Особливості та ціль: Це унікальна реалізація. У середовищі командного рядка (CLI) у користувача немає графічного інтерфейсу, щоб бачити, що робить агент. Тут
todo list
використовується так само як основний канал комунікації та зворотного зв’язку. Агент проголошує свої дії, створюючи та позначаючи задачі.
3. Cursor Prompts
- Як реалізовано: Через інструмент
todo_write
. - Особливості та ціль: Це одна з найпросунутіших реалізацій. Промпт не просто дає інструмент, він навчає модель, як правильно ним користуватися. Секція
<todo_spec>
містить правила, що таке хороший пункт плану (не більше 14 слів, починається з дієслова) і що таке поганий. Ціль — не просто планування, а навчання моделі створенню якісних, високорівневих і осмислених планів.
4. Kiro
- Як реалізовано: Через файл-артефакт. У спеціалізованому режимі
Spec mode
агент проходить через етапи «Вимоги → Дизайн → План». Кінцевим продуктом цього робочого процесу є файлtasks.md
, який містить список завдань із чекбоксами. - Особливості та ціль: Тут
todo list
— це формальний, стійкий артефакт, який створюється у файловій системі проекту. Він є результатом великого етапу проектування. Ціль — створення детального та довгострокового плану реалізації функції, який потім може виконуватися частинами.
5. Manus Agent Tools & Prompt
- Як реалізовано: Гібридна система. Промпт говорить про існування зовнішнього
<planner_module>
, який надсилає агенту високорівневий план. Агент, у свою чергу, повинен створити та підтримувати більш детальний план у файліtodo.md
. - Особливості та ціль: Це ієрархічна система планування. Є стратегічний план від планувальника, і є тактичний, детальний план у
todo.md
, який веде сам агент. Ціль — зв’язати високорівневі бізнес-цілі з низькорівневими задачами виконання.
6. Codex CLI
- Як реалізовано: Через інструмент
update_plan
. - Особливості та ціль: Дуже схоже на
Cursor
. Промпт також містить приклади хороших і поганих планів, щоб навчити модель якісному плануванню. План є важливою частиною комунікації з користувачем у CLI, показуючи, як агент збирається вирішувати задачу.
7. Qoder
- Як реалізовано: Через інструменти
add_tasks
іupdate_tasks
. - Особливості та ціль: Промпт чітко розділяє задачі на прості (до 3 кроків), де планування не потрібно, і складні, де воно обов’язкове. Це прагматичний підхід, який не перевантажує прості задачі зайвою бюрократією.
8. Same.dev
- Як реалізовано: Через файл-артефакт. Промпт (
<memos>
) приписує агенту створити та підтримувати файл.same/todos.md
. - Особливості та ціль: Як і в
Kiro
, це зовнішня, стійка пам’ять для плану. Це робить роботу агента прозорою для користувача та стійкою до переривань сесії. Агент зобов’язаний оновлювати цей файл на початку та в кінці свого ходу, що робить ведення плану суворим ритуалом.
9. v0 Prompts and Tools
- Як реалізовано: Через спеціалізованого субагента
TodoManager
. Основний агент не керує списком сам, а викликає субагента з командамиset_tasks
,move_to_task
і т. д. - Особливості та ціль: Це архітектурний патерн розділення відповідальності. Задача управління планом винесена в окремий, спеціалізований компонент. Це робить систему більш модульною. Промпт також вимагає створювати milestone-level tasks (задачі рівня віхи), а не мікрозадачі, що вказує на фокус на високорівневому, стратегічному плануванні.
10. VSCode Agent
- Як реалізовано: Через інструмент
manage_todo_list
. - Особливості та ціль: Промпт
gpt-5.txt
містить розділtodoListToolInstructions
, який вимагає використовуватиtodo list
для всіх багатоступеневих задач. Описаний дуже суворий «CRITICAL workflow»: 1) Сплануй, 2) Познач ОДНУ задачу якin-progress
, 3) Виконай її, 4) НЕГАЙНО познач якcompleted
, 5) Переходь до наступної. Ціль — максимальна прозорість, методичність і запобігання розфокусуванню агента.
11. Traycer AI
- Як реалізовано: Це система генерації плану як кінцевого продукту. Агент-технологічний лід у режимі
phase_mode
використовує інструментwrite_phases
для створення високорівневого плану (фаз). - Особливості та ціль: На відміну від інших систем, тут агент не використовує план для своєї роботи, а створює його для інших (ймовірно, для інших агентів або для користувача).
Загальні висновки та патерни
- Універсальне поширення: Механізми планування та
todo list
є стандартом де-факто для будь-якого серйозного кодинг-агента, який вирішує задачі складніші за одне діяння. - Три основні способи реалізації:
- Управління через інструменти (Tool-Based): Найчастіший підхід. Агент використовує інструменти (
todo_write
,update_plan
) для інтерактивного управління списком завдань. (Приклади:Cursor
,ClaudeCode
,Codex CLI
,VSCode Agent
). - Управління через файли (File-Based): План зберігається у вигляді
.md
-файлу в проекті. Це робить його стійким і легко читабельним для користувача. (Приклади:Kiro
,Same.dev
,Manus
). - Управління через субагента (Agent-Based): Задача планування делегована окремому спеціалізованому агенту. (Приклад:
v0
).
Навіщо агенту потрібен план? Від декомпозиції до управління увагою
На перший погляд, відповідь очевидна: щоб розбити складну задачу на прості кроки. Але це лише вершина айсберга. Механізми планування та списки To-Do вирішують кілька критичних проблем. Одна з них — схильність ШІ відходити від теми та забувати попередні цілі, особливо в довгих контекстах або при роботі зі складними задачами.
1. Управління увагою за допомогою декламації
При виконанні довгих задач, що складаються з десятків кроків (типова сесія агента може включати 20+ викликів інструментів), модель ризикує загубитися посередині — забути початкову ціль або захопитися побічною задачею.
Постійно оновлюючи список To-Do і позначаючи виконані пункти, агент поміщає актуальний план у кінець свого контексту. Це не випадкова дія, а цілеспрямований механізм керування увагою. Переносячи глобальний план у найсвіжішу частину своєї пам’яті, агент постійно нагадує собі про головні цілі. Він ніби декламує план знову і знову, не даючи своїй увазі розсіятися. Це елегантне рішення промптингу для зсуву фокусу моделі на стратегічну ціль, не вимагаючи складних архітектурних змін.
2. Декомпозиція складності та підвищення якості
Це більш класична, але не менш важлива причина.
- Від хаосу до структури: План перетворює одну велику та абстрактну задачу на послідовність маленьких, конкретних і виконуваних дій.
- Проектування до коду: Сам процес створення плану — це вже етап проектування. Як видно з прикладів
Cursor
іCodex CLI
, промпти змушують агента створювати хороші, деталізовані плани. Це змушує модель спочатку продумати рішення, а не кидатися писати код, що кардинально підвищує якість кінцевого результату.
3. Керованість та співпраця
План — це ключовий елемент інтерфейсу між людиною та ШІ.
- Дорожня карта для користувача: Замість того щоб спостерігати за чорною скринькою, користувач бачить наміри агента. Це дозволяє вчасно втрутитися, скоригувати курс або просто бути в курсі того, що відбувається.
- Точка синхронізації: План стає спільним простором для роботи. Користувач може редагувати план, додаючи або видаляючи задачі, перетворюючи монолог агента на діалог і спільну роботу.
Думки наостанок
Концепція динамічних списків To-Do намагається вирішити фундаментальні проблеми дрейфу цілей та декомпозиції складних задач, але на практиці це не завжди спрацьовує.
На мою думку, причина в тому, що список To-Do є надто низькорівневим інструментом для вирішення проблеми вищого порядку. Для ефективного управління складними процесами потрібна певна високорівнева концептуальна рамка, але поки топові агентські системи її не використовують, хоча розумний пошук дає деякі методи та підходи:
- CBR-системи використовують адаптацію минулого досвіду для нових задач.
- Memory-augmented агенти підтримують довгостроковий контекст і персоналізацію.
- Reflection-based системи включають механізми самокорекції та навчання на помилках.
Коментарі