От Coding Agent к цифровому сотруднику: AI-приложения конвергируют в единую архитектуру

От Coding Agent к цифровому сотруднику: AI-приложения конвергируют в единую системную архитектуру

Обходя стенды с Agent-продуктами на Cloud Village Conference, самое контринтуитивное открытие: кажется, что они принадлежат совершенно разным отраслям, но «вырастают» в одну и ту же операционную систему.

Qoder занимается разработкой ПО, QwenWork — интеллектуальной работой с знаниями, TinyFish — веб-браузер-агентом, WonderClip — видеопроизводством, OpenSearch — поиском и исследованиями.

Убрав конкретику отраслей, их базовая структура удивительно схожа:

Контекст → Планирование → Навыки → Выполнение → Верификация → Память → Бизнес-результат

Это и есть единая системная архитектура, к которой конвергируют Agent-продукты.

⚠ В качестве примеров в статье используется экосистема Alibaba Cloud (Qoder/QwenWork/TinyFish/WonderClip/OpenSearch). Однако приведённые архитектурные выводы одинаково применимы к собственным решениям, а также к платформам агентов Huawei Cloud, AWS, Azure и GCP — семиуровневая архитектура отражает инженерную конвергенцию, а не особенности конкретного облачного провайдера.

1. Ядро агента сместилось от «генерации ответов» к «непрерывному выполнению»

В эпоху чат-ботов цикл работы системы был предельно прост: пользователь вводит запрос — модель выдаёт ответ.

В эпоху агентов задачи длятся минуты, часы и даже дольше. Агенту необходимо читать файлы, управлять браузером, вызывать API, исполнять код, ожидать асинхронные операции, проверять результаты, при сбоях — повторять попытки, сохранять состояние.

Один промпт и одна модель уже не вмещают всё это.

Система должна обзавестись рантаймом.

Перевод на русский

Продемонстрированная на стенде QwenWork задача по заполнению юридических документов весьма показательна: она выполняется в изолированной песочнице (Sandbox Container), где агент обладает виртуальным рабочим столом и может вызывать инструменты для обработки документов. При генерации маркетингового контента дополнительно используются различные инструменты — для создания презентаций, работы с изображениями, синхронизации губ (Lip Sync), а также Python, Pillow и FFmpeg.

Среда выполнения агента всё больше приближается к возможностям программируемого компьютера — это рабочая единица, защищённая песочницей, способная вызывать различные среды выполнения и инструменты, а также непрерывно выполнять задачи без прерывания. Sandbox Container обеспечивает изоляцию, виртуальный рабочий стол предоставляет возможности визуального управления через графический интерфейс, а вызов инструментов позволяет модели перейти от «разговоров» к «действиям». Только когда эта комбинация стабилизируется, агент действительно начнёт замещать операционную деятельность человека, а не только его аналитическую работу.

2. «One Foundation» от Qoder — это продуктовый сигнал, а не лозунг

На стенде Qoder написано:

One workbench. Four entries. One foundation.

Сверху располагаются Workbench, CLI, IDE, JetBrains Plugin, и это лишь начало — архитектура может расширяться дальше: Cloud Agents, Agent SDK и другие компоненты.

Но по-настоящему интерес представляет то, что находится снизу, — общий Foundation.

Если каждая точка входа будет реализовывать собственный экземпляр Agent, система быстро выйдет из-под контроля. Гораздо разумнее вынести в общий Harness такие функции, как планирование задач, управление правами доступа, инструментарий, Sandbox, Memory, Model Router и Verification.

При этом каждая точка входа отвечает лишь за адаптацию к конкретной аудитории и сценарию использования: CLI предназначен для программистов, IDE — для разработчиков, Workbench — для специалистов без технического бэкграунда, JetBrains Plugin — для миграции существующего кода, Cloud Agents — для асинхронных вызовов, а Agent SDK — для интеграции со сторонними решениями. Всё остальное — планирование, память, инструментальный шлюз, верификация и модель безопасности — работает через единый общий слой.

Ценность повторного использования гораздо глубже, чем кажется на первый взгляд. Опыт проектирования Sandbox, Permission и Recovery, накопленный в рамках Coding Agent, может напрямую переноситься на Browser Agent, Content Agent, Ops Agent. Главная проблема duplicated work — не столько затраты на разработку, сколько катастрофа в управлении, когда разные агенты ведут себя по-разному: один и тот же код можно изменить и в IDE Agent, и в CLI Agent, но модели Permission отличаются, форматы audit logs не совпадают, и при инцидентах отследить причину практически невозможно.

Три. Универсальный Agent Stack включает как минимум семь уровней — и карта инвестиций «своё/совместное/требует проверки» для каждого из них

Обобщив описанные выше аспекты, я выделил семь уровней Agent Stack. Таблица ниже даёт ответ на самый практический вопрос любой организации: какие уровни имеет смысл строить самостоятельно, какие можно взять из open-source или закупить, а по каким ясности пока нет.

Уровень	Содержание	Инвестиционное решение (наблюдения на месте 2026)
1. Entry (Вход)	Web / CLI / IDE / IM / API / GitHub Issue / корпоративный рабочий стол	Слой адаптера, не строить самим — выбирать форму входа, наиболее подходящую для своих пользователей
2. Task (Задача)	Goal / Spec / Context / Acceptance / Priority / Budget	Строить самим, но очень тонко — это контракт задачи, плохо напишешь — всё внизу поедет
3. Context & Memory (Контекст и память)	Корпоративные знания, знания кода, история задач, решения, предпочтения пользователей, текущее состояние	Обязательно строить самим — Context является активом организации, не купишь
4. Planning & Skill (Планирование и навыки)	Разбиение задачи, выбор Skill, выбор модели, стратегия параллелизма	Skill строить самим, Planning можно привлекать — Skill это крепостная стена

| 5. Runtime & Tools (Среда выполнения и инструменты) | Shell / Browser / Computer Use / Filesystem / Git / Database / MCP / Enterprise API | Полусамописная — общий Runtime можно получить на базе открытых решений (Browser Use, Anthropic Agent SDK и т.д.); корпоративный API‑шлюз требует собственной реализации |
| 6. Verification & Recovery (Проверка и восстановление) | Тестирование, проверка правил, оценка результатов, восстановление при сбоях, повторные попытки и откат | Собственная реализация — правила верификации тесно связаны с бизнес‑логикой, купленные решения не заработают |
| 7. Governance (Управление) | Права доступа, Secrets, Аудит, Затраты, Политика, Утверждение человеком | Обязательная собственная реализация — проектировать с инженерной, а не с комплаенс‑точки зрения |

Ниже каждое из семи уровней разобрано в одном предложении:

Уровень 1: Entry. Web, CLI, IDE, IM, API, GitHub Issue, корпоративный портал — всё это лишь точки входа для задач и сами по себе не создают бизнес‑ценности.

Второй уровень: Task. Goal, Spec, Context, Acceptance Criteria, Priority, Budget — всё это атрибуты Task. Грамотное описание Task должно чётко определять: цель, причину выполнения, критерии завершённости, приоритет и доступный бюджет. Если в системе на базе агента отсутствует хотя бы одно из этих шести полей, задача начинает «дрейфовать» по системе.

Третий уровень: Context & Memory. Здесь сосредоточены корпоративные знания, кодовая база, история задач, принятые решения, предпочтения пользователей и текущее состояние. Именно на этом уровне реализуются концепции, которые Qoder подчёркивал на практике: Repo Wiki, Knowledge Graph, Knowledge Cards — всё это превращает «разрозненные факты» в активы, которые машина может востребовать.

Четвёртый уровень: Planning & Skill. Система определяет, как декомпозировать задачу, выбирает подходящие переиспользуемые Skill, решает, какие шаги требуют мощных моделей, а какие можно выполнять параллельно. Этот уровень — место, где агент по-настоящему начинает «думать», и где модели интенсивно задействуют свои возможности.

Пятый уровень — Runtime & Tools. Shell, браузер, Computer Use, файловая система, Git, базы данных, MCP и корпоративные API — всё это относится сюда. По сути, это та самая граница, где Agent реально соприкасается с внешним миром.

Шестой уровень — Verification & Recovery. Тестирование, валидация правил, оценка результатов, восстановление после сбоев, повторные попытки и откат.

Седьмой уровень — Governance. Здесь речь идёт о правах доступа, управлении секретами, аудите, контроле затрат, политиках и обязательном одобрении человеком. Сюда же входят более детальные аспекты — алгоритмическая регистрация (bàndē — обязательная регистрация алгоритмов в Китае), объяснимость модели, распределение ответственности за ошибки, контроль зависимостей от третьих сторон и управление трансграничной передачей данных (shùjù chūjìng — оценка рисков при отправке данных за рубеж). Для отраслей с жёстким регуляторным контролем — здравоохранение, финансы, транспорт, медиа, общественная безопасность — вывод Agent в продуктивную среду неизбежно сталкивается с этими жёсткими требованиями.

Модель пронизывает все уровни, но модель — это уже не весь Agent-платформа. Это, пожалуй, самое недооценённое изменение в мышлении за последние два года. Слишком многие команды тратят массу времени на сравнение моделей, хотя именно шесть верхних уровней определяют, сможет ли система выйти в продакшн.

Браузерный Agent: недостающее звено между Agent и реальным миром

Продукты вроде TinyFish — яркий тому пример.

Browser Agent: настоящий веб для AI-агентов

Многие реальные бизнес-системы не имеют удобных API, либо пользователям требуется входить на сайты, взаимодействовать с динамическими страницами, заполнять формы, переключаться между вкладками и скачивать файлы. Традиционная автоматизация опирается на скрипты Playwright или Puppeteer, которые ломаются при малейшем изменении страницы. Browser Agent позволяет модели напрямую понимать веб-страницу и выполнять действия на ней.

Именно так заполняется важный пробел в Agent Runtime: реальный веб.

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

Но по-настоящему сложная часть никогда не сводилась к «нажатию кнопок». В production-системах необходимо решать целый ряд задач:

Управление сессиями — как работать с Cookie и Token, что делать при их истечении.

Параллелизм — как синхронизировать действия на нескольких вкладках в рамках одной задачи.

Восстановление после сбоев — как продолжить работу при зависании страницы или обрыве сети.

Защита от повторных отправок — как предотвратить дублирование действий при сетевых колебаниях.

Обход блокировок — как справляться с географическими и IP-ограничениями.

Капча — как проходить проверку на бота.

Изоляция прав доступа — как разграничить доступ для нескольких аккаунтов.

И наконец, главный вопрос — подтверждение выполнения: как убедиться, что действие действительно сработало.

На ещё более глубоком уровне, indirect prompt injection (косвенное внедрение промптов) представляет собой наиболее реалистичную угрозу безопасности для Browser Agent в 2026 году: OWASP ставит prompt injection на первое место среди угроз ИИ в 2026 году, и достаточно разместить на странице скрытый фрагмент текста, чтобы заставить Agent отправить cookies пользованика. На архитектурном уровне полноценного решения не существует — приходится искать инженерные компромиссы в области песочниц, белых списков действий и контроля Ambient Credential.

Browser Use также необходимо включить в тестовый стенд. Возможностей уровня демо недостаточно. Если организация действительно намерена использовать Browser Agent в продакшене, затраты только на этот слой могут сравняться со стоимостью создания новой RPA-системы.

Таким образом, Browser Agent выглядит как приложение, но по сути является частью Runtime.

Пять. Verification определяет, сможет ли Agent получить более широкие права

В системах Agent существует чёткая закономерность: чем выше автономность, тем строже должны быть верификация и управление.

Agent, способный только составлять черновики писем, имеет ограниченные последствия ошибок.

Агент, способный модифицировать production-базу данных, коммитить код, управлять рекламным бюджетом и работать с корпоративными системами, представляет совершенно иной уровень риска.

По-настоящему зрелая Agent-платформа должна отвечать не только на вопрос «что можно сделать», но и чётко заявлять:

• к чему допускается доступ;
• что разрешено изменять;
• какие действия требуют согласования;
• какие аудиторские записи сохраняются на каждом этапе;
• как восстановиться после сбоя;
• каким образом система подтверждает фактическое выполнение задачи.

Здесь работает инженерное правило: если Agent не может предоставить верифицируемое доказательство каждого своего действия, его автономия должна оставаться на уровне «советчика». Иными словами, автономия расширяется по мере проверки возможностей в рамках комплаенс-фреймворка, а не вслед за списком функций. Даже если Agent технически способен вызывать 100 API, если он не может подтвердить, что каждый вызов достиг ожидаемого результата, — в финансовой, медицинской сферах или сценариях работы с трансграничными данными он останется в роли «советчика».

Именно поэтому Governance будет играть всё более значимую роль в корпоративных сценариях — это не задача комплаенс-отдела, а способность, которую инженерная команда обязана закладывать в архитектуру с самого начала, проектируя её совместно с Runtime.

Model Router станет базовым диспетчером — но не каждое звено требует самой дорогой модели

Мультимодельные системы уже давно перестали быть экзотикой.

По-настоящему ценная мультимодельная архитектура — это не просто возможность выбрать GPT, Qwen, Claude или любую другую модель из выпадающего списка. Куда разумнее, когда система сама маршрутизирует задачу в зависимости от её характера.

Сложное планирование и архитектурные решения — мощным моделям; рутинную реализацию кода и обработку текстов — более дешёвым; визуальные задачи — мультимодальным моделям; массовую классификацию — быстрым; ключевые ревью — снова мощным.

За этим стоит простая инженерная логика: у разных задач совершенно разные требования к кривой «возможности-стоимость». Глупо заставлять мощную модель разбираться с массовой классификацией — это банальная растрата ресурсов. А вот поручить быстрой модели архитектурные решения — получите бесконечные доработки. Компания Requesty в 2026 году опубликовала показательный опыт: перенаправление 70% рутинных задач на нано-модели, 20% на среднеуровневые и 10% на передовые позволяет снизить стоимость одного запроса на 60–80% практически без потери качества. Это лишь ориентир, конкретные цифры зависят от типа задач и стратегии маршрутизации.

Модели всё больше превращаются в диспетчеризируемый вычислительный ресурс. Agent Platform берёт на себя динамический выбор между качеством, скоростью, стоимостью и рисками.

Практический пример каскадной маршрутизации: когда агент получает задачу «проанализировать ценовую стратегию конкурентов и дать рекомендации», он использует мощную модель на этапе понимания задачи, декомпозиции шагов и определения приоритетов. Затем переключается на быструю модель для классификации 100 SKU по ценовым диапазонам. После получения результатов классификации для итоговой оценки снова задействуется мощная модель.

Если все задачи выполняются самой дорогой моделью, стоимость системы резко возрастает. Если же для всех задач используется дешёвая модель, это приводит к постоянным сбоям на сложных участках. Настоящая инженерная ценность заключается в стратегии планирования, а не в выборе конкретной модели.

Семь. Skill — ключевой слой между универсальным Runtime и вертикальными бизнес-задачами, а также будущий конкурентный барьер

Универсальный Agent Runtime сам по себе не имеет бизнес-ценности.

Его ценность раскрывается только через Skill в реальных сценариях.

Coding Skill понимает, как читать репозиторий, писать спецификации, запускать тесты и генерировать Pull Request. Он определяет правила: когда обязательно сначала запускать юнит-тесты, когда можно пропустить, какие поля должен содержать PR-дескриппшен, какие изменения требуют обязательной ручной проверки (review).

SEO Research Skill знает, как искать ключевые слова, анализировать поисковый интент, оценивать конкурентную плотность, генерировать контент-план и проверять индексацию страниц. Это не просто «провести исследование ключевых слов», а полноценный процесс.

E-commerce Creative Skill отвечает за знание брендов, SKU, форматов платформ, требований к комплаенсу и процедур модерации. Он должен учитывать ограничения по размерам изображений на каждой платформе, списки запрещённых слов, требования к категориям товаров и финальную проверку перед запуском рекламной кампании.

Ops Skill знает, как работать с мониторингом, логами, контейнерами, базами данных и процедурами отката. Он способен определять, какие алерты допускают автоматическую обработку, а какие требуют вмешательства специалиста, а также где находится безопасная точка отката.

Skill — это не просто набор стандартных процедур, а исполняемый актив с управлением версиями, зависимостями, итерациями и механизмами отказоустойчивости. Можно ориентироваться на протокол Skills, представленный Anthropic в октябре 2025 года: каждый тип предметной экспертизы упаковывается в папку SKILL.md, что позволяет различным Agent-платформам загружать их по необходимости вместо того, чтобы переписывать каждый раз заново.

Skills соединяют общие исполнительные возможности с предметными знаниями.

Поэтому будущие конкурентные преимущества многих AI-приложений будут строиться на Domain Skills, прошедших валидацию на大量 реальных задачах. Эти Skills аккумулируют знание о том, «как делаются дела в данной области», — их непросто заменить новыми моделями или платформами, и с течением времени они будут только прибавлять в ценности благодаря эффекту сложных процентов.

Восемь отраслевых перспектив: конкретные формы внедрения в четырёх типах организаций

Следующие четыре раздела — не повествование, а картографирование абстрактных «семи слоёв стека» на конкретные отрасли, показывающее, где именно у каждой из них узкие места.

Телеком/операторы: смена тарифных планов, подключение выделенных линий для корпоративных клиентов, локализация междоменных сбоев — всё это требует прохождения через множество доменов: BSS, OSS, CRM, биллинг. Главная боль при внедрении Agent — междоменная сверка: Agent изменил тарифный план клиента в CRM, и он обязан синхронизировать это с биллингом и OSS, иначе расчётный период не сойдётся. Самые ценные слои стека здесь — 5-й (Runtime & Tools для объединения интерфейсов разных доменов) и 7-й (Governance для аудита финансовых операций).

Финансы и банковское дело: Управление рисками, противодействие отмыванию денег, сверка операций и регуляторная отчётность — всё это требует прозрачности, проверяемости и отслеживаемости. Каждое решение AML-агента «пропустить» или «заблокировать» операцию должно быть обосновано: какое правило применилось, какая история транзакций учитывалась, какие данные о клиенте использовались. Наиболее ценными в стеке являются 6-й уровень — Verification (верификация, то есть проверяемая цепочка обоснований) и 7-й — Governance (управление, включая согласование алгоритмов и контроль трансграничной передачи данных). В условиях российского финансового регулирования именно эти два уровня являются обязательными требованиями для запуска в эксплуатацию, а не дополнительными преимуществами.

Производство: MES, ERP, QMS, SRM долгое время существуют изолированно друг от друга, а принятие решений в межфункциональных контекстах (например, «при недостатке мощностей стоит ли увеличивать закупку материалов») требует согласования между четырьмя системами. В промышленности агент выступает уровнем оркестрации между системами, а не заменой отдельных систем. Он одновременно обращается к данным о материалах из ERP, показателям брака из QMS, загрузке мощностей из MES и оценке эффективности поставщиков из SRM, формируя комплексное решение. Наиболее ценными в стеке для этого сценария являются 5-й уровень — Runtime (среда выполнения, корпоративный API-шлюз) и 3-й — Context (накопленный контекст, включающий технологические знания, историю неисправностей и опыт производственного персонала).

Электронная коммерция: пиковые нагрузки при междоменных сценариях (оформление заказа, платежи, складские остатки, логистика, поддержка клиентов), стресс-тестирование / согласованность складских данных / защита от накрутки бонусов / сверка данных между платформами. Первыми в электронной коммерции внедряются агенты для креативных операций (замена изображений товаров, фонов, подготовка материалов на нескольких языках) и ассистенты операторов колл-центров. Наиболее ценными на уровнях Stack являются: 4-й уровень Skill (процессы проверки на соответствие требованиям и модерации для каждого SKU/канала) и 6-й уровень Verification (автоматическая проверка соответствия материалов стандартам платформы).

Общая черта четырёх типов организаций: чем ниже уровень Stack, тем целесообразнее совместное использование; чем выше — тем выгоднее строить собственное решение. Базовые компоненты вроде Runtime, Model Router и Tool Gateway выгоднее развивать совместно нескольким компаниям или использовать готовые open-source стеки. Уровни Skill, Context и Governance необходимо строить самостоятельно, поскольку они привязаны к бизнес-процессам, нормативному соответствию и организационным активам.

IX. Конечный продукт может выглядеть совершенно иначе, но в основе лежать общие принципы

UI, пользовательский опыт и бизнес-модель Coding Agent и видео-агента кардинально различаются.

Однако всем им на уровне инфраструктуры требуются: Context, Task, Skill, Tools, Runtime, Verification, Memory и Governance — и всё должно в конечном счёте приводить к измеримым бизнес-результатам.

Корпоративный Knowledge Agent и Browser Agent могут казаться весьма далёкими друг от друга, но в конечном счёте оба сталкиваются с необходимостью решать задачи прав доступа, управления состоянием, восстановления после сбоев и аудита.

Поэтому при разработке нескольких AI-продуктов имеет смысл выделять два уровня.

Верхний уровень остаётся специализированным. Каждый продукт строится вокруг законченной Job, имеет собственные пользовательский опыт, модели данных и бизнес-метрики. Для Coding Agent объектами являются Repo и Code Review, для видео Agent — Script и Asset, для исследовательского Agent — Source и Citation. Углублённую специализацию каждого из них невозможно заменить универсальными возможностями.

Нижний уровень должен быть по возможности общим. Agent Runtime, Model Router, Tool Gateway, Memory, Audit, Secrets и Evaluation могут стать общей инфраструктурой.

Такой подход позволяет избежать дублирования усилий при создании каждого продукта, а также избежать ошибки, которую совершили многие команды за последние два года — попытки сразу построить огромную «универсальную Agent-платформу» без реальных пользователей. Попытки охватить все сценарии разом приводили к тому, что ни один из них не доводился до практически применимого уровня.

Более надёжный путь — сначала проверить ценность на конкретных задачах, а затем выделить повторяющиеся базовые возможности. Ключевой вывод: общий слой может вырасти только из конкретных сценариев, а не из архитектурной диаграммы. Проектирование Runtime “для всех сценариев” с самого начала обычно означает, что ни один сценарий не будет проработан должным образом.

Три вопроса самопроверки (сверьтесь после написания):

1. Проверяли ли мы универсальность абстрагированного Runtime хотя бы в двух конкретных сценариях?
2. Соответствует ли дизайн каждого слоя реальной бизнес-проблеме, с которой мы сталкивались?
3. Если сегодня сократить бюджет вдвое, какие слои мы сохраним? Если ответ — “context и skill”, направление верное; если “runtime и шлюз”, возможно, стоит переделать.

Именно этот долгосрочный вывод я вынес с конференции Yunqi: над моделями формируется новый системный слой, который принадлежит не какому-то конкретному продукту, а постепенно становится OS для эпохи агентов. Кто первым укрепит этот слой OS, тот с большей вероятностью получит преимущество в следующем цикле развития продуктов.

---

Выводы для руководителей

Если вы отвечаете за AI в компании с годовым доходом более 5 миллиардов юаней (CDO/CIO/CTO), вот три направления, которые можно начать реализовывать уже сейчас:

1. Визуализируйте текущий семиуровневый снимок Agent Stack в вашей организации — не стоит сразу бросаться закупать решения. Сначала оцените, что на каждом уровне у вас: пробелы, сторонние компоненты или полуфабрикаты. Уже один этот снимок вскроет реальные узкие места.

2. Выберите один сценарий с высоким ROI и доведите до конца полный вертикальный цикл — не начинайте с построения Runtime. Возьмите Coding Agent, ассистента поддержки клиентов или инструмент для разработчиков, и пройдите все четыре уровня — Context, Task, Skill, Verification. А уже потом заводите речь о «платформе».

3. Выведите Governance на инженерный уровень, а не на уровень комплаенса — права доступа, аудит, интерпретируемость, распределение ответственности за ошибки и контроль сторонних зависимостей проектируйте параллельно с бизнес-Agents с самого старта проекта, а не добавляйте задним числом.

Возможные вопросы

Q1: Чем этот семиуровневый Stack отличается от фреймворков многоагентной оркестрации, которые предлагают Gartner и IDC?

Gartner и IDC фокусируются на координации и управлении множеством Agents на уровне организации. Семиуровневая модель в статье описывает инженерную структуру отдельного Agent. Организация может работать на обоих уровнях одновременно: отдельные Agents следуют семиуровневой архитектуре, а взаимодействие между Agents строится на принципах оркестрации. Stack — это микроуровень, оркестрация — макроуровень.

Q2: Почему слой модели не выделен отдельно?

Потому что модель в системе Agent — это сквозной горизонтальный ресурс, а не отдельный изолированный слой. Model Router трактует разные модели как различные вычислительные мощности, подлежащие диспетчеризации, и по статусу они находятся на одном уровне с Shell и Browser в среде Runtime — всё это «инструменты». Модель, разумеется, критически важна, но она не может монополизировать сложность Agent-системы.

Q3: Стоит ли небольшим командам пропустить этот слой и сразу перейти к сквозным решениям вроде ChatGPT или Claude?

Да. Командам с годовым доходом менее 100 миллионов юаней и низкой организационной сложностью выгоднее сразу использовать готовые Agent-продукты (Browser Use, Manus, Alibaba Cloud Bailian Agent и другие). Семь слоёв, о которых идёт речь в этой статье, рассматриваются в контексте вопроса «стоит ли организациям с годовым доходом 50 миллиардов юаней и выше строить собственную Agent-платформу». Для небольших команд создание платформы — это контрпродуктивная оптимизация.

Самопроверка наоборот (для вас и для меня)

Если вы внутренне соглашаетесь с любым из трёх приведённых ниже утверждений, это может означать, что вы следуете за нарративом, а не за фактами:

Если ни один из этих трёх пунктов вам не близок — продолжайте чтение.

---

Ссылки и источники в конце статьи (по пунктам: источник + уровень доказательности + позиционирование)

1. «Одна платформа. Четыре входа. Одна основа.» — официальный стенд и блог Qoder, представлены на конференции Cloud Town 2026, а также статья Introducing Qoder 1.0 от Alibaba Cloud Community от 31.08.2026. Уровень доказательности: заявление производителя (позиция Alibaba).

2. QwenWork Legal Document Fill Out: изолированный контейнер + виртуальный рабочий стол + вызов инструментов — демонстрация QwenWork от Alibaba Cloud вживую, статья в Alibaba Cloud Community от 25.09.2026. Уровень доказательности: заявление производителя (позиция Alibaba).

3. QoderWake как продукт «цифрового сотрудника», выпущен 30.04.2026 — статья о Qoder в Baidu Encyclopedia + официальные материалы Alibaba. Уровень доказательности: заявление производителя (позиция Alibaba).

4. OWASP 2026: Prompt Injection занимает первое место в списке угроз — обзор State of Browser Use, May 2026 (блог Michael Livs). Уровень доказательности: комплексная сторонняя оценка (позиция OWASP, отраслевой консенсус).

5. Requesty: каскадная маршрутизация 70/20/10 позволяет сократить расходы на 60–80% — официальный блог Requesty, 2026. Уровень доказательности: заявление производителя (позиция сервиса маршрутизации моделей, цифры завышены, приводится как ориентир).

6. Microsoft Agent Governance Toolkit (AGT), 02.04.2026 — открытый код под лицензией MIT — материал с niteagent.com. Уровень доказательности: комплексная сторонняя оценка (позиция Microsoft, но AGT — проект с открытым исходным кодом, данные верифицируемы).

7. Протокол Anthropic Skills: опубликован 2025-10-16, открыт как открытый стандарт 2025-12-18 — блог Anthropic Engineering + обзор на Substack + Medium LM Po. Уровень доказательности: заявление вендора + обзор третьих сторон (позиция Anthropic).

8. IDC прогнозирует, что в 2026 году 40% производителей внедрят AI-управление планированием — обзор Groovy Web на 2026 год, со ссылкой на отчёт IDC. Уровень доказательности: обзор третьей стороны (позиция IDC, цифры направленного характера).

9. Stripe «Minions»: еженедельно мержат 1300+ PR, 0 человек пишут код, полностью人工 review — выступление Steve Kaliski из инженерной команды Stripe на How I AI 2026-03-25 + репост ByteMonk от 2026-02-14. Уровень доказательности: заявление вендора (позиция Stripe, цифры справочные, сценарий — внутренняя инженерия Stripe, не распространяется на средние показатели по отрасли).

10. BCG 2026 Applied AI Index: доля agentic AI в общей стоимости ИИ — 22% (2026) → 39% (2030) ——Публичный отчёт BCG. Уровень доказательности:第三方综合(позиция консалтинговой компании, направленность цифр для справки).

11. Gartner прогнозирует, что к 2026 году 40% корпоративных приложений будут встраивать задачных AI-агентов, тогда как в 2025 году этот показатель составлял менее 5% ——Обзор Пола Окрема за 2026 год со ссылкой на Gartner. Уровень доказательности:第三方综合(позиция Gartner, направленность для справки).

12. Китайские CAC/NDRC/MIIT совместно опубликовали «Мнения о стандартизированном применении и инновационном развитии интеллектуальных агентов», вступающие в силу 15.07.2026 ——Ежемесячный обзор китайского AI-законодательства от Rimon Law за июль 2026 года. Уровень доказательности:第三方综合(позиция юридической организации, документ доступен для проверки).

Примечание: CAC — Китайская администрация киберпространства; NDRC — Государственный комитет по развитию и реформам; MIIT — Министерство промышленности и информационных технологий КНР.

13. TinyFish: привлечение $47 млн инвестиций, клиенты включают Google/DoorDash/Amazon, холодный старт в браузере <250 мс — обзор SwitchTools 2026. Уровень доказательности: сторонняя сводка (позиция评测站产品评测平台, цифры требуют проверки на официальном сайте TinyFish).

---

Если вы оцениваете, как построить внутреннюю платформу Agent для предприятия, какие возможности следует разрабатывать самостоятельно / закупать / использовать совместно, и какие Agent Runtime обеспечивают максимальную повторную ценность — давайте обсудим. Мы специализируемся на консалтинге по трансформации предприятий в сфере AI — от архитектуры Agent и проектирования Runtime до накопления Skill, помогая превратить «точечных Agent» в «платформу Agent организационного уровня».

Услуги и цены

• Корпоративное обучение: для руководителей и ключевых специалистов, 3-дневный базовый курс — 90 000 ¥ за сессию. Разберём с вашей командой семь уровней Agent Stack, инженерный взгляд на Governance и методологию накопления навыков.
• Профильный консалтинг: 90-минутная диагностика архитектуры — от 3 000 ¥. Независимая оценка текущего состояния семи уровней, выявление пробелов, рекомендации по выбору между готовыми решениями и собственной разработкой; глубокое сопровождение проекта — по договорённости.
• Выступления для руководства и отраслевые мероприятия: доклады на конференциях, закрытых встречах и форумах — программа составляется под ваш запрос.

Связаться: [email protected]

---

Рекомендуем к прочтению

«Семишаговая рамка AI-трансформации» — системное руководство по внедрению AI в компании.

---

Локализация (многоязычное сравнение, соглашения IAIUSE от 09.08.2026)

При переводе на 19 языков указанные ниже элементы заменяются в соответствии с целевым языковым рынком, структура и визуал сохраняются:

中文稿内容	英文版	日文版	德文版	阿拉伯版
Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch (сохранены названия продуктов)	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch

| 阿里云 / 钉钉 / 飞书 | Alibaba Cloud / AWS / GCP / Azure / Slack / Teams | アリババクラウド / AWS / GCP / Azure / Slack / Teams / Lark | Alibaba Cloud / AWS / GCP / Azure / Slack / Teams | علي بابا كلاود / AWS / Slack / Teams |
| 中国电信 / 移动 / 联通 (сценарии развёртывания корпоративных Agent) | AT&T / Verizon / T-Mobile | NTT / KDDI / SoftBank | Deutsche Telekom / Vodafone | STC / Etisalat |
| 代表льные предприятия китайской обрабатывающей промышленности (кейсы ERP/MES/QMS/SRM) | GE / Honeywell / Rockwell | Toyota / Hitachi / NTT Data | Siemens / Bosch / SAP | SABIC / Aramco / STC |

中国银行 (финансовый кейс)	JPMorgan / Goldman Sachs	Mitsubishi UFJ / SMFG	Deutsche Bank / Commerzbank	Emirates NBD / QNB
Sandbox Container / виртуальный рабочий стол / вызов инструментов	Sandbox Container / Virtual Desktop / Tool Calling	サンドボックス / 仮想デスクトップ / ツール呼び出し	Sandbox-Container / Virtueller Desktop / Werkzeugaufruf	حاوية معزولة / سطح مكتب افتراضي / استدعاء الأدوات
One Foundation / Harness	One Foundation / Harness	One Foundation / Harness	One Foundation / Harness	One Foundation / Harness

| Browser Agent(интеллектуальный агент браузера) | Browser Agent(сохраняется) | интеллектуальный агент браузера | интеллектуальный агент браузера | интеллектуальный агент браузера |

| Навык предметной области / Навык программирования / Навык исследования SEO / Навык творчества в электронной коммерции / Навык операционной деятельности | Навык предметной области (сохранено) / Навык программирования / Навык исследования SEO / Навык творчества в электронной коммерции / Навык операционной деятельности | Навык предметной области / Навык программирования / Навык исследования SEO / Навык творчества в электронной коммерции / Навык операционной деятельности | Навык предметной области / Навык программирования / Навык исследования SEO / Навык творчества в электронной коммерции / Навык операционной деятельности | Навык предметной области / Навык программирования / Навык исследования SEO / Навык творчества в электронной коммерции / Навык операционной деятельности |

| Model Router | Model Router(保留) | モデル路由器 | Model-Router | Маршрутизатор моделей |
| Verification & Recovery / Governance | Verification & Recovery / Governance(保留) | 検証と復旧 / ガバナンス | Verifikation & Wiederherstellung / Governance | Верификация и восстановление / Управление |
| 算法备案 / 数据出境 | Algorithm Filing / Cross-border Data Transfer | アルゴリズム登記 / データ越境移転 | Algorithmus-Registrierung / grenzüberschreitende Datenübertragung | Регистрация алгоритмов / Трансграничная передача данных |

О серии

«Облачная обитель» — серия практических материалов от IAIUSE, созданная по итогам Cloud ASCEND 2026. Здесь исследуются реальные изменения в AI-индустрии с точки зрения исследователя — без погоне за хайпом, только анализ направлений и силы доказательной базы.

В серию входит около 10 материалов, охватывающих системный уровень над моделями, внедрение Agent, Context-активы, проектирование AI-организаций, миграцию конкурентных единиц AI-продуктов и другие темы.

У меня почти 8 лет опыта в консалтинге для крупных предприятий и бизнес-аналитике. Я работал в IBM, участвовал в проектах в сферах телекоммуникаций, финансов, страхования и производства. После этого продолжил работать на передовой в области операторских продуктов, интернет-продуктов и разработки AI-приложений, занимаясь анализом требований, проектированием продуктов и кросс-командным внедрением.

За этим каналом стоит небольшая команда — я и 1-2 постоянных коллеги, которые 分别负责 направления研究 AI-инструментов программирования, систематизации кейсов по организационному управлению и коучинговых диалогов. Большинство проектов, которые мы описываем как «помогаем компаниям пройти», были реализованы совместно несколькими участниками нашей команды.

База исследовательских материалов насчитывает более 200 статей. Выводы в этой серии основаны на моём непосредственном наблюдении и кросс-валидации в отрасли, содержат чёткую авторскую позицию и не отражают точку зрения каких-либо производителей.