Anthropic пренася хостваните многоагентни работни потоци към Claude управлявани агенти

Anthropic добави динамични работни потоци към Claude управлявани агенти в публична бета версия, премествайки общ шаблон за проектиране на агенти от код за локално оркестриране в самата платформа Claude.

Изданието от 9 октомври позволява на управляван агент да напише програма за работен поток, да изпълни много агенти на фази и да комбинира техните резултати, докато сървърът изпълнява работата във фонов режим като изпълнение на работен поток. Разработчиците активират бета версията с бета заглавката managed-agents-2026-04-01 и конфигурират поле multiagent с тип multiagent_20261001 и активирани работни потоци. Anthropic също така казва, че workflow_run събития се появяват в потока от събития на сесията, което дава на приложенията начин да наблюдават напредъка, вместо да третират работния поток като едно непрозрачно повикване.

Това е значима промяна за екипи, изграждащи агентни системи. Декомпозицията с множество агенти обикновено изисква планировчици от страна на приложението, опашки, съхраняване на състояние, повторни опити и логика за обединяване на резултати. Anthropic сега пакетира част от този слой за оркестрация като хоствана API възможност.

Какво се промени

Claude Управляваните агенти вече предоставиха на разработчиците управлявана среда за сесии на агенти. Динамичните работни потоци разширяват този модел, като позволяват на агент да създаде програма за работен поток, която координира други агенти през фазите. Вместо програмист да кодира твърдо всяка стъпка от паралелен преглед или тръбопровод за проучване, управляваният агент може да дефинира работния поток и Claude платформата може да го изпълнява асинхронно.

Полезното разграничение не е просто „повече агенти“. Това е мястото, където живее оркестрацията. С тази бета версия работата е представена като работен поток, изпълняван от страната на Anthropic, като събитията се показват обратно през потока на сесията. Това може да опрости някои архитектури, при които преди екипите трябваше да изградят своя собствена услуга за контролер около Claude повиквания.

Функцията остава бета версия. Документираната конфигурация и имена на събития на Anthropic са стабилните факти, достъпни от бележките по изданието и документацията за управляван агент, прегледани тук. Дописи от трети страни описват конкретни ограничения на мащаба за агенти за изпълнение и едновременни агенти, но тези ограничения трябва да бъдат проверени спрямо текущата документация за изпълнение на работен поток на Anthropic, преди да бъдат третирани като публикуваеми оперативни ограничения.

Защо това има значение за API екипи

Оркестрацията на хоствания работен поток улеснява стартирането на работните натоварвания на агентите, но по-трудно да се управлява небрежно. Една заявка на един потребител може да се разпръсне в много извиквания на модели, междинни обобщения, извиквания на инструменти и финални стъпки за синтез. Това променя профила на цената и видимостта на приложението, дори когато продуктът, обърнат към потребителя, все още изглежда като едно „питане“.

Най-очевидните случаи на употреба са прегледи на големи кодове, преглед на документи, планиране на миграция, анализ на надлежна проверка, проверки за съответствие и изследователски задачи, при които паралелни специалисти могат да работят върху различни части, преди координиращ агент да обедини резултатите. Тези натоварвания са привлекателни, защото се съпоставят добре с поетапно изпълнение. Те също са работните натоварвания, които най-вероятно ще създадат големи символични сметки, ако подканите, повторните опити и броят на подагентите не са ограничени.

За инженерните лидери въпросът за управление се измества от „кой модел извика тази крайна точка?“ до „какъв автономен работен процес задейства тази заявка и колко изразходва всяка фаза?“ Това е мястото, където LLM API приписването на разходите става нещо повече от финансово отчитане. Екипите трябва да знаят коя функция на продукта, клиент, проект или API ключ е причинил разпръскването на работния процес.

Има и гледна точка на надеждността. Изпълненията на работния процес във фонов режим се нуждаят от видимост на напредъка, поведение при анулиране, правила за повторен опит и трайни очаквания за състояние. Поддръжката на поток от събития на Anthropic е начало, тъй като приложенията могат да се абонират за събития, изпълнявани от работния поток, вместо да анкетират сляпо.Но екипите все пак ще трябва да решат каква част от собствената им машина за състояние остава извън доставчика.

Кой е засегнат

Непосредствената аудитория са разработчици, които вече използват Claude управлявани агенти или оценяват инфраструктурата на хоствани агенти. Екипите, които са изградили персонализирани мултиагентни системи, могат да сравнят бета версията със съществуващия си оркестрационен слой, особено ако текущото им внедряване е предимно водопроводна, а не диференцирана продуктова логика.

Екипите на корпоративните платформи трябва да обърнат внимание, дори ако не са готови да приемат бета версията. Хостваната оркестрация променя това, което трябва да бъде видимо в AI API контролна равнина. Контролна равнина, която записва само брой заявки, име на модел и общи токени, може да пропусне структурата на работното натоварване. За управлявани работни потоци екипите ще искат идентификатори на изпълнение, използване на ниво фаза, активност на инструмента, точки на неизправност и състояние на бюджета.

Това също засяга прегледа на доставките и сигурността. Хостваният мултиагентен работен процес не е просто моделна крайна точка; това е делегирана среда за изпълнение. Компаниите ще трябва да разберат какви данни протичат през всеки агент, колко дълго се запазва състоянието на работния поток, какви регистрационни файлове са налични и как достъпът е обхванат в проекти и среди.

За B2B LLM клиенти и подобни API потребители с няколко модела практическата връзка е управлението. Ако доставчиците улесняват разпръскването на агентите, контролите на ниво платформа трябва да поддържат темпото: ограничения на разходите по ключ или проект, анализи на използването за работни потоци, списъци с разрешени модели и сигнали, когато модел на автоматизация започне да консумира повече от очакваното. Динамичните работни потоци са функция на продукта, но също така напомнят, че разходите на агентите често се формират от оркестрация, а не само от цената на токена.

Какво остава несигурно

Бета версията оставя отворени няколко оперативни въпроса за екипите, които планират производствена употреба. Публичните бележки за изданието установяват съществуването на динамични работни потоци, бета заглавката, типа на мултиагентната конфигурация и повърхността на потока от събития. В прегледания материал те не уреждат всеки детайл за планиране на производството около лимити, ценообразуване, задържане или семантика на неуспех.

Разработчиците трябва да проверят текущата документация, преди да зададат допускания за максимален брой агенти за изпълнение, паралелност, поведение при изчакване и как използването се детайлизира при експортиране на фактуриране. Те също така трябва да извършат малки оценки, преди да преместят чувствителни работни потоци за преглед или съответствие към функцията, тъй като синтезът с множество агенти може да промени последователността на изхода, както и разходите.

По-широката посока обаче е ясна. Доставчиците на модели превръщат оркестрацията на агентите в примитивна платформа. Това намалява обема на инфраструктурата, необходима за експериментиране, като същевременно вдига летвата за наблюдение и контрол на бюджета, след като тези експерименти станат реални работни процеси.