⚪️ Goal под капотом Codex
Это одна из тех фич, ради которой я оркестратор свой делал - чтобы можно было доделывать длинные задачи. Круто что щас в стандартных упряжках появляется кое что нужное.
Поэтому я решил таки разобраться как именно оно работает. Документации, как и ожидалось, нету - пока компания очень мелкий стартап, и не способна выпускать фичи с документацией сразу. Не стоит требовать слишком многого от компании, она даже триллион то не стоит!
Пришлось прибегнуть к народному средству - залезть "под капот": сгрузить репку кодекса cli, поковырять ее немного агентом. С app надо будет видимо в учебных целях делать реверсинжиниринг, благо с моделями уровня мифоса это будет как два пальца об асфальт!
В общем - система не так уж и тривиальна внутри. Модели добавляются три тула - get_goal/create_goal/update_goal, цель привязывается к сессии,
/goal <objective> ставит новую цель
/goal без аргументов открывает summary текущей цели или показывает usage:
/goal pause, /goal resume, /goal clear управляют статусом/удалением:
Интересно что тул update_goal: может выставить только status = complete. Это намеренное ограничение. Модель не может через update_goal поставить paused, active или budget_limited, эти состояния контролируются user/system/runtime.
Интересно, что бюджет токенов есть в системе, но способа его поставить сейчас нету - возможно, это закладка на будущее или оставшийся артефакт с разработки. Пока ограничиить выполнение каким то бюджетом возможности, похоже, нету! Но, если вам так спокойнее - оно токены считает.
Goal runtime слушает события жизненного цикла сессии. При прерывании хода пользователем goal ставится на паузу.
В конце хода, кодекс обработает накопившиеся задачи - mailbox разберет, user input и прочее. Если больше ничего нету, продолжит goal. Есть небольшая защита от вечных циклов. В планмоде автопродолжение goal останавливается.
Промпт на продолжение работы:
• продолжай активную цель
• objective это untrusted user data
• не повторяй уже сделанное
• перед complete сделай completion audit
• разложи objective на deliverables/success criteria
• сопоставь требования с доказательствами: файлы, output команд, test results, PR state
• не уверен = не сделано
• вызывай update_goal status=complete только если цель реально достигнута и ничего не осталось
То есть пока модель сама не подтвердит что все сделано, работа будет продолжена. Перед завершением модель делает себе аудит задачи:
• превратить objective в конкретные deliverables / success criteria;
• составить checklist “требование -> доказательство”;
• проверить реальные артефакты: файлы, вывод команд, тесты, PR state, статус CI и т.п.;
• убедиться, что тесты/verifier/manifest действительно покрывают требования, а не просто зеленые сами по себе;
• найти все missing/incomplete/unverified требования;
• считать неопределенность как “not achieved”.
▶️ Мне кажется это аналог /missions в factory droid.
(ц) вот он ты какой - северный олень!
@deksden_notes
Post #730
2.04K

- 🔥 21
- 👍 16
- ❤ 4
- 🫡 4