Codex Agents V2 у версії 0.145.0: що змінилося та як їх увімкнути

Codex 0.145.0 став першим релізом, у якому мені захотілося всерйоз випробувати Agents V2. OpenAI тепер позначає прапорець multi_agent_v2 як stable, але за замовчуванням залишає його вимкненим. Якщо ввімкнути прапорець явно, Codex примусово перейде на V2. До релізу також увійшли зміни в керуванні паралельністю, виборі моделей, ролях і навігації. PR #34383 (opens in a new tab) (відкриється в новій вкладці) пояснює, як працює цей прапорець. Без явного перевизначення Codex усе одно може вибрати бекенд за метаданими моделі. У каталозі моделей для цього тегу GPT-5.6 Sol і Terra вибирають V2, а Luna вибирає V1. Каталог моделей для цього тегу (opens in a new tab) (відкриється в новій вкладці) та реалізація вибору бекенду (opens in a new tab) (відкриється в новій вкладці) показують, як Codex поєднує примусове значення прапорця з вибором, заданим для моделі.

Коротко

Прапорець multi_agent_v2 має статус stable і за замовчуванням вимкнений. Якщо його ввімкнути, Codex примусово перейде на V2, хоча V2 уже може вибиратися за метаданими моделі.
V2 замінює плоский список ID агентів на ієрархію завдань, у якій можна переміщатися.
Обсяг успадкованого контексту задається явно. Так само визначено правила роботи поштових скриньок батьківських і дочірніх агентів.
У 0.145.0 оновили ролі агентів, моделі за замовчуванням, відновлення після перезапуску та навігацію в TUI.
Усі агенти працюють в одному робочому каталозі та спільній файловій системі замість окремих worktree.
max_concurrent_threads_per_session враховує потоки створених агентів у всьому дереві сесії.

Що змінилося порівняно з V1

У V2 кожна гілка роботи має назву й місце в дереві завдань, а правила обміну повідомленнями між гілками визначені наперед. Визначення інструментів V1 і V2 для цього тегу (opens in a new tab) (відкриється в новій вкладці) показують різницю.

Аспект	Agents V1	Agents V2
Ідентифікатор	Непрозорі ID агентів	Канонічні шляхи завдань, наприклад `/root/research/api`
Контекст під час створення	`fork_context` увімкнено або вимкнено	`fork_turns` приймає `none`, `all` або кількість останніх ходів
Спілкування	`send_input`, очікування конкретних агентів, відновлення та закриття за ID	`send_message`, `followup_task`, очікування повідомлень у скриньці, переривання та перегляд дерева
Вкладеність	Керується через `agents.max_depth`	Ієрархічна вкладеність, `max_depth` ігнорується
Керування в TUI	Потоки V1 приймають пряме введення	Дочірні потоки V2, що належать батьківському агенту, доступні лише для перегляду
Конфігурація	Застаріла модель плоского списку агентів	Параметри під час створення, спільні типові значення та іменовані ролі, що зберігаються між запусками

Дерево завдань V2

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

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

Успадкування контексту задається явно

У V2 старий логічний параметр контексту замінили на fork_turns. Обробник створення агента для цього тегу приймає значення у трьох формах:

Варіанти контексту під час запуску V2text

fork_turns = "all"   # уся історія, значення за замовчуванням
fork_turns = "none"  # без історії розмови
fork_turns = "5"     # п’ять останніх ходів

Тепер я можу підбирати обсяг контексту під конкретне завдання. Рецензенту може знадобитися недавнє обговорення дизайну, а агенту, який досліджує репозиторій, часом вистачить точно сформульованого завдання. Парсер і типове значення можна побачити в реалізації запуску V2 для цього тегу (opens in a new tab) (відкриється в новій вкладці).

Повідомлення і додаткова робота розділені

Дві операції з повідомленнями працюють по-різному:

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

Агент може чекати на оновлення поштової скриньки; його також можна перервати або знайти в списку за шляхом завдання. Схема інструментів для спільної роботи в цій версії (opens in a new tab) (відкриється в новій вкладці) описує цю поведінку.

Codex відновлює конфігурацію ролі після перезапуску

Іменована роль може містити опис для користувача, окремий шар конфігурації та варіанти псевдонімів:

~/.codex/config.tomltoml

[agents.researcher]
description = "Audit primary sources and report evidence with links."
config_file = "./agents/researcher.toml"
nickname_candidates = ["Ada", "Grace"]

Для відносних шляхів до файлів ролей Codex бере за основу каталог із config.toml, де ці ролі визначено. У 0.145.0 агент V2 зі збереженим станом після перезапуску також відновлює конфігурацію вибраної ролі. Інтеграційний тест перевіряє інструкції ролі, модель, провайдера, рівень міркування та дозволи. PR #33657 (opens in a new tab) (відкриється в новій вкладці) описує це виправлення.

Дочірні потоки V2 під керуванням батьківського агента доступні лише для перегляду

У TUI Codex відкриває дочірній потік V2, що належить батьківському агенту, у режимі перегляду. Я можу переглядати потік, а батьківський агент спілкується з ним через інструменти V2. Так Codex закріплює керування потоком за батьківським агентом і зберігає чернетки та текст у черзі, поки дочірній потік відкритий. PR #33841 (opens in a new tab) (відкриється в новій вкладці) містить обґрунтування та тести, які перевіряють введення у V1 і режим лише для перегляду у V2.

Як увімкнути Agents V2

Щоб примусово використовувати V2, достатньо одного прапорця:

~/.codex/config.tomltoml

[features]
multi_agent_v2 = true

Команда CLI записує те саме значення:

Увімкнути Agents V2sh

codex features enable multi_agent_v2

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

Моя робоча конфігурація

~/.codex/config.tomltoml

[agents]
enabled = true
max_concurrent_threads_per_session = 8
 
[features]
multi_agent_v2 = true

agents.enabled = true вказано явно, хоча цей рядок зайвий. За схемою конфігурації інструменти для роботи з кількома агентами увімкнені за замовчуванням, а активний прапорець V2 має пріоритет. Я також не задаю default_subagent_model або default_subagent_reasoning_effort, тому конфігурація не прив’язує всіх створених агентів до певної моделі чи рівня міркування. Ці необов’язкові типові значення застосовуються лише тоді, коли під час створення агента окремо не задано модель або рівень міркування. Схема конфігурації для цього тегу (opens in a new tab) (відкриється в новій вкладці) визначає ці поля.

У тій самій схемі старий параметр max_depth позначено як доступний лише у V1, а V2 його ігнорує. Тому розгалуження V2 я контролюю через ліміт паралельності та чіткі межі завдань.

Як перевірити фактичний стан

Я одночасно перевіряю встановлену версію та потрібні рядки у списку можливостей:

Перевірити версію Codex і стан можливостейsh

codex --version
codex features list

22 липня 2026 року відповідна частина виводу мала такий вигляд:

Відповідна частина локального виводуtext

codex-cli 0.145.0
multi_agent       stable  true
multi_agent_v2    stable  true
multi_agent_mode  removed false

Доступні інструменти дають ще один спосіб перевірити стан під час роботи. spawn_agent потребує task_name, а в сесії є send_message, followup_task, list_agents та interrupt_agent. Список можливостей показує налаштовані прапорці, а набір інструментів показує, чим може користуватися активне завдання.

Рівні міркування High і Ultra

Agents V2 працює і з High, і з Ultra. На рівні High я явно прошу Codex залучити паралельних агентів. На рівні Ultra Codex може делегувати роботу проактивно, хоча невелике або тісно пов’язане завдання він усе одно може залишити одному агенту.

Старий параметр multiAgentMode застарів та ігнорується. Довідник протоколу app-server (opens in a new tab) (відкриється в новій вкладці) пов’язує проактивне делегування з рівнем міркування Ultra.

На рівні High достатньо такого запиту:

Явне делегування з Hightext

Використовуй Agents V2 там, де роботу можна виконувати незалежно. Делегуй
дослідження джерел, реалізацію та перевірку, а потім об’єднай результат у
кореневому завданні.

Чіткі межі завдань важливіші за ліміт у шість чи вісім потоків.

Обмеження спільного робочого простору

Агенти V2 працюють у спільному робочому просторі без окремих worktree. Реалізація конфігурації для цього тегу (opens in a new tab) (відкриється в новій вкладці) вказує, що всі агенти працюють в одному контейнері, файловій системі та поточному робочому каталозі й одразу бачать зміни одне одного.

Я використовую Agents V2 для координації паралельної роботи. За нею простіше стежити завдяки шляхам завдань, вибору обсягу контексту, поштовим скринькам і ролям, що зберігаються між запусками. Та ділити роботу все одно треба так, щоб агенти не заважали одне одному.

Коли я вмикаю V2

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

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

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