К содержанию
Выпуски

Новости · · 15 мин

ИИ и разработка — 25 сентября 2026

Период: 24 сентября — утро 25 сентября 2026 года. За текущее окно не найдено подтверждённого значимого нового релиза железа или frontier-модели, который менял бы картину предыдущих выпусков, поэтому пустые разделы не создаются.

Сегодня основная линия проходит через слой вокруг модели. Anthropic показывает, что в agent-to-agent рынке главным bottleneck оказался не торг, а точность представления интересов пользователя; AWS выносит авторизацию MCP-вызовов из reasoning-агента в отдельный policy gateway; исследования показывают, что agent workflow уже становится версионируемым operational specification; open source быстро строит отдельные runtimes для долгоживущих, stateful и изолированных агентов. На уровне бизнеса наиболее показателен Aderant: дешёвая модель дала полезный эффект только потому, что её окружили retrieval, confidence gate, human fallback и конкретные actions.

3. Архитектура и эксплуатация агентных систем

Project Swap: главным ограничением agent-to-agent рынка оказалось понимание пользователя, а не переговоры

Что произошло. Anthropic провела Project Swap — контролируемый рынок с 201 сотрудником в шести офисах. Каждый участник коротко описывал Claude свои читательские предпочтения, после чего Claude-agent торговался с другими агентами и обменивал книги от имени человека.

Почему это важно. Для agents, которые должны покупать, выбирать подрядчика, договариваться о расписании или действовать от имени пользователя, bottleneck может находиться раньше planner и negotiation: система сначала должна достаточно точно построить user model. Сильный переговорщик, оптимизирующий ошибочно понятые предпочтения, делает неправильную работу эффективнее.

Что показали данные. Рейтинг книг, построенный Claude после короткого intake, совпадал с человеческим pairwise ranking в 61% случаев; random baseline — 50%, popularity baseline — около 53%, collaborative filtering — около 55%. Теоретически оптимальное распределение книг по реальным предпочтениям имело efficiency 0,89; фактический децентрализованный рынок — 0,55. Лучшее распределение, рассчитанное по Claude-предпочтениям, но оценённое по человеческим, дало 0,60: Anthropic оценивает, что примерно 85% разрыва до optimum объяснялось ошибкой representation и лишь 15% — механизмом переговоров. При оценке на самих Claude rankings выбор модели тоже влиял сильнее wording инструкции: Haiku floors дали около 0,75 efficiency, Sonnet 0,80, Opus 0,88, Fable 0,86. Это controlled experiment Anthropic на сотрудниках компании, а не production market; выборка явно не репрезентативна общей аудитории.

Что нужно уже понимать: preference elicitation, user model, agent-to-agent negotiation, market efficiency, delegated authority.

Что это может изменить для продукта или engineering-команды. До передачи agent'у экономически значимых решений полезно тестировать не только task execution, но и то, правильно ли он понял пользователя: например, дать несколько sample decisions и сравнить с выбором человека. Для marketplace/agent-commerce нужен отдельный слой identity, audit, rate limits и recourse.

Дата: 24 сентября 2026.
Первоисточник: https://www.anthropic.com/research/project-swap

AWS: MCP-авторизация должна выполняться вне кода и reasoning агента

Что произошло. AWS опубликовала reference architecture multi-account agent: центральный AgentCore Gateway агрегирует MCP servers разных business units, но данные остаются в исходных AWS accounts. Пользовательский JWT передаётся в Gateway; Cedar policies разрешают или запрещают каждый tool call по identity, role и action. Для разрешённых действий Gateway отдельно получает OAuth machine-to-machine credentials и только затем обращается к нужному MCP server.

Почему это важно. MCP решает discovery/interface problem, но не authorization. Если модель сама трактует роли, scopes или решает, имеет ли пользователь право вызвать tool, security policy становится probabilistic. Здесь policy enforcement находится вне agent code и независимо от его reasoning.

Что показали данные. Это reference architecture, а не benchmark. Важны свойства схемы: agent не изменяет JWT, данные не централизуются, policy проверяет каждый вызов; LOB runtime может принимать запросы только через identity chain, включающую Gateway, чтобы прямой вызов не обходил policy. AWS отдельно отмечает, что публичная сеть из sample-конфигурации предназначена для development, а production следует изолировать через VPC/PrivateLink.

Что нужно уже понимать: MCP Gateway, JWT, Cedar policy, OAuth M2M, least privilege.

Что это может изменить для продукта или engineering-команды. Если agent получает доступ к нескольким SaaS/внутренним системам, authorization лучше делать как отдельный deterministic control plane: user identity → policy → temporary credential → tool. Это уменьшает blast radius и позволяет менять модель без переписывания permission logic.

Дата: 24 сентября 2026.
Первоисточник: https://aws.amazon.com/blogs/machine-learning/build-a-multi-account-ai-agent-with-agentcore-gateway-and-mcp/

WhatWorkedBench: research-agent лучше дополнять статистической моделью эксперимента, а не полагаться только на LLM-intuition

Что произошло. WhatWorkedBench оценивает, насколько AI research agents действительно понимают эффект собственных экспериментов. Agent изучает code, выбирает ограниченное число измерений и должен предсказать response surface — результат для всех конфигураций компонентов. Exhaustive CPU execution даёт ground truth.

Почему это важно. Research agent может хорошо выбирать следующий experiment и при этом плохо интерполировать, что именно вызвало улучшение. Это принципиально важно для автоматического tuning prompts, retrieval, models, hyperparameters и harness: без causal/quantitative model агент легко переобучается на несколько наблюдений.

Что показали данные. Benchmark включает 36 tasks, 30 data sources, 8 workflow types, 1 248 configuration records и 4 206 numerical-control records. При восьми новых измерениях pair-effect ridge выбрал optimum на 15 из 22 sources. Добавление Gaussian Process поверх тех же agent observations повысило effect recovery с 0,632 до 0,698 в исходной cohort и с 0,621 до 0,720 в дополнительной; в beat-detection/graph family macro recovery выросло с 0,303 до 0,455. Это академический preprint, не peer-reviewed.

Что нужно уже понимать: experimental design, response surface, Gaussian Process, effect recovery, adaptive experimentation.

Что это может изменить для продукта или engineering-команды. Для систем, которые автоматически A/B-тестируют prompts, tools или models, полезно разделить роли: LLM предлагает и выполняет experiments, а численный surrogate/statistical layer оценивает эффекты и uncertainty. Это снижает риск принимать убедительные, но статистически слабые выводы агента.

Дата: 23–24 сентября 2026.
Первоисточник: https://arxiv.org/abs/2609.27490

GitHub Agentic Workflows уже ведут себя как код, но prompt-injection defense почти отсутствует

Что произошло. Исследователи изучили 1 248 GitHub Agentic Workflow files из 276 repositories и 20 841 commit-file event. Эти Markdown-файлы соединяют instructions, triggers и configuration и компилируются в исполняемые GitHub Actions workflows.

Почему это важно. Agent workflow перестаёт быть одноразовым prompt. Он становится operational specification: повторно запускается, меняется через commits, копируется между repositories и управляет действиями с реальными side effects. Следовательно, к нему нужны versioning, review, budgets и security controls как к коду.

Что показали данные. Медианная длина workflow — 556,5 слова; code blocks есть в 62,1% файлов. Среди файлов с ≥120 днями наблюдений 78,2% всё ещё менялись на четвёртом месяце. Tasks, outputs, constraints и process instructions встречались более чем в 93% размеченных workflows, но explicit prompt-injection defense — только в 9,4%. Это empirical study open-source repositories; наличие инструкции не означает, что защита эффективна, а отсутствие — что workflow обязательно уязвим.

Что нужно уже понимать: agentic workflow, prompt injection, GitHub Actions, operational specification, resource budget.

Что это может изменить для продукта или engineering-команды. Agent workflow files стоит включить в обычный software-governance процесс: code owners, change review, version history, budget/timeout limits, trusted-evidence rules и explicit handling untrusted content.

Дата: 23 сентября 2026; включено как свежий research backfill.
Первоисточник: https://arxiv.org/abs/2609.27263

4. Developer tooling и программирование

Anthropic: 3× ускорение Claude UI сделали агенты, но ключом были deterministic performance ratchets

Что произошло. В двухнедельном performance sprint Anthropic использовала внутреннюю Claude Tag, сопоставимую по уровню с Opus 5.5, для поиска bottlenecks, написания benchmark'ов, fixes и наблюдения за deploys. Люди задавали цели, принимали trade-offs и утверждали каждое изменение.

Почему это важно. Это production-case не столько про «AI написал много кода», сколько про правильный harness для optimization work: измеримый objective, deterministic proxy, CI gate, tests, feature flags и human approval. Agent эффективен там, где можно быстро доказать, что изменение действительно улучшило систему и не сломало её.

Что показали данные. P75 fresh-load-to-typeable на claude.ai снизился с 3,1 до 0,55 секунды; запуск новой Claude Code session — с 0,8 до 0,3; загрузка Cowork cloud session — с 2,6 до 0,73. За sprint слили более 3 000 changes без customer-facing incident или rollback — по данным Anthropic. Для hot paths команда использовала instruction counts, V8 call counts, React commits, style recalculations и DOM mutations как deterministic CI-ratchets; flaky benchmark удаляли, если он не коррелировал с wall-clock latency. Каждый PR проходил automated review и минимум один human approval; почти 200 feature flags ограничивали rollout risk.

Что нужно уже понимать: performance regression, CI gate, deterministic benchmark, feature flag, human approval.

Что это может изменить для продукта или engineering-команды. Coding agents особенно полезны в optimization/maintenance, когда objective машинно проверяется. Стоит инвестировать в regression oracles и telemetry до попытки «дать агенту больше автономии»: хороший verifier увеличивает полезность модели сильнее, чем свободный prompt.

Дата публикации: 23 сентября 2026; backfill из-за значимости production-case.
Первоисточник: https://claude.dev/blog/how-we-made-claude-ai-faster/

GitHub меняет default governance Copilot: новые GA capabilities смогут включаться автоматически

Что произошло. GitHub добавила для Copilot Business и Enterprise глобальную policy «Default policy for new features». Администратор выбирает: автоматически включать eligible GA-функции, автоматически держать выключенными или делегировать решение организациям. Policy распространяется также на Copilot Code Review и MCP servers in Copilot; preview features остаются opt-in. Правило начнёт действовать 22 октября, explicit решения сохраняются.

Почему это важно. Capability surface coding agents меняется быстрее традиционного enterprise software. Если новый MCP/tooling feature включается по умолчанию, security boundary организации может измениться без отдельного rollout-проекта. Поэтому governance должен охватывать будущие capabilities, а не только текущие модели.

Что показали данные. Это policy release, benchmark отсутствует. Практически важная деталь — 28-дневное окно до применения политики; unconfigured eligible GA-функции после 22 октября будут наследовать выбранный global default.

Что нужно уже понимать: enterprise AI controls, default allow/deny, MCP server, feature governance, preview vs GA.

Что это может изменить для продукта или engineering-команды. Enterprise-admins стоит явно выбрать default-deny или delegated policy до 22 октября, если новые agent capabilities требуют security review. «Unconfigured» больше нельзя считать устойчивым состоянием.

Дата: 24 сентября 2026.
Первоисточник: https://github.blog/changelog/2026-09-24-default-enablement-of-copilot-features-for-copilot-business-and-enterprise/

AWS Transform + coding agent: specialized agent становится tool для general-purpose coding agent

Что произошло. AWS открыла MCP-интеграцию AWS Transform с Kiro, Claude Code, Cursor и другими coding agents. General-purpose agent может создавать Transform workspaces/jobs, передавать local context, ждать long-running migration steps, обрабатывать human-in-the-loop checkpoints и проверять generated migration artifacts.

Почему это важно. Это практический pattern model/tool routing на уровне агентов: универсальный coding agent не пытается сам стать экспертом по migration planning, network conversion и wave design, а вызывает специализированную систему и остаётся orchestrator'ом.

Что показали данные. Это integration release, без controlled benchmark. AWS рекомендует задавать concrete verification loops — например, чтобы каждый server оказался ровно в одной migration wave, чтобы wave не превышала заданный размер и prod/non-prod dependencies сохранялись; при нарушении критериев agent должен rerun/refine. AWS Transform for migrations доступен без отдельной платы, custom transformations тарифицируются только за active agent minutes; token cost внешнего coding agent остаётся отдельным.

Что нужно уже понимать: MCP, specialist agent, orchestration, human-in-the-loop, verification loop.

Что это может изменить для продукта или engineering-команды. Не обязательно расширять один agent бесконечным числом prompts/skills. Для сложных domain operations часто лучше подключать специализированный deterministic/agentic service как tool и держать general agent на уровне orchestration.

Дата: 24 сентября 2026.
Первоисточник: https://aws.amazon.com/blogs/migration-and-modernization/migrate-faster-with-aws-transform-and-your-ai-coding-agent/

5. Production AI, SaaS и бизнес

Aderant: Nova Lite + retrieval + confidence gate автоматизировали ticket triage примерно за $30 в месяц

Что произошло. Aderant автоматизировала triage для 38-person SierraOps team, обслуживающей 268 client environments. Hourly workflow собирает ticket из Jira, environment metadata из Athena, документацию из Confluence/SharePoint и похожие resolved Jira tickets. Nova Lite выдаёт structured classification; система автоматически маршрутизирует только достаточно уверенные cases, а low-confidence отправляет человеку.

Почему это важно. Это хороший counterexample идее, что production automation требует frontier reasoning model. Простая и дешёвая модель даёт бизнес-эффект, когда задача узкая, context authoritative, action ограничен, confidence threshold явный, а corrections возвращаются в knowledge/process loop.

Что показали данные. За первые 2,5 недели production — 109 tickets — Aderant получила около 96% routing accuracy: четыре misroutes. Manual baseline составлял 15–25 минут исследования на ticket; компания оценивает экономию в 8–14 инженерных часов в неделю, или 32–56 часов в месяц. Полная система стоит менее $30/месяц, Bedrock inference — менее $1/месяц. Это first-party early production measurement на небольшой выборке; до automation система около двух недель работала monitoring-only.

Что нужно уже понимать: confidence threshold, RAG/context enrichment, structured output, human fallback, operational KPI.

Что это может изменить для продукта или engineering-команды. Для back-office automation сначала ищите workflows с дорогим ручным context gathering и простым, ограниченным action space. Frontier model может оказаться экономически хуже небольшого model + хорошего retrieval + confidence gate.

Дата: 24 сентября 2026.
Первоисточник: https://aws.amazon.com/blogs/machine-learning/aderant-builds-intelligent-ticket-triage-with-amazon-nova/

6. GitHub / open-source сигналы

Google AX: Kubernetes-подобный control plane для долгоживущих agent workloads быстро набирает внимание

Что произошло. Google AX — Apache-2.0 declarative orchestrator, где agent workload описывается через Task, Workspace и Model manifests. AX sandbox'ит execution, подготавливает Git/MCP/skills environment и даёт agent-specific lifecycle primitives: watch, ssh, suspend/resume. Проект прямо позиционирует agents как отдельный класс workloads — не stateless microservices и не обычные batch jobs.

Почему это важно. Production agent runtime постепенно отделяется от application framework. Stateful sessions, isolation, checkpoints, model/tool connectivity и cost controls требуют отдельного substrate, похожего по роли на Kubernetes для services, но с другими lifecycle semantics.

Что показали данные. GitHub на момент проверки показывает около 10,5 тыс. stars и 507 forks; GitNova зафиксировала примерно +1 022 stars за 24 сентября. Но репозиторий прямо предупреждает о возможных major breaking changes до stable release. Заявление о «billions of tasks per cluster» — design target проекта, а не опубликованный независимый performance benchmark.

Что нужно уже понимать: agent runtime, sandbox, checkpoint/resume, declarative control plane, Kubernetes-style orchestration.

Что это может изменить для продукта или engineering-команды. Пока ранняя стадия. Но если команда строит много persistent agents, полезно отделять agent lifecycle от бизнес-логики: environment, model, workspace, network policy и pause/resume должны быть управляемыми сущностями.

Дата сигнала: 24–25 сентября 2026.
Первоисточник: https://github.com/google/ax
Дополнительный источник динамики: https://gitnova.dev/en/day/2026-09-24

Unreal Agent: ранний сигнал на durable async harness вместо синхронного «LLM loop»

Что произошло. Новый Go-проект Unreal Agent строит harness вокруг append-only persisted session, idempotent inbox, coordinator и durable asynchronous operations. Tool translator только валидирует model request и превращает его в serializable operations; фактическое I/O выполняется отдельно. Session history можно fork'ать и восстанавливать, а context builder обязан явно записывать, что было omitted, truncated или compacted.

Почему это важно. Long-running agents ломают простую модель prompt → tool call → response. Реальные operations могут жить дольше LLM-turn, падать, retry'иться или выполняться в удалённом sandbox. Отделение durable operation state от conversational history делает recovery и audit значительно надёжнее.

Что показали данные. Проект очень молодой: на момент проверки около 1,9 тыс. stars, 98 forks, 135 commits, 8 issues и 0 open PR; GitNova зафиксировала примерно +450 stars 24 сентября. Это developer-attention signal, а не доказательство production maturity или превосходства по benchmark.

Что нужно уже понимать: durable execution, idempotency, append-only event log, async operation, session recovery.

Что это может изменить для продукта или engineering-команды. Если agent выполняет задачи дольше одной request/response session, state операции лучше хранить отдельно от LLM context. Retries должны быть idempotent, а resume — опираться на persisted state, а не на пересказ предыдущего чата.

Дата сигнала: 24–25 сентября 2026.
Первоисточник: https://github.com/unreallabsai/unreal-agent
Дополнительный источник динамики: https://gitnova.dev/en/day/2026-09-24

Главный технологический сдвиг выпуска

Главный сдвиг — agent system всё отчётливее раскладывается на независимые control layers. User preference representation, authorization, experimental inference, durable execution и workflow specification больше нельзя считать «частью prompt»: каждый из этих слоёв получает собственные модели данных, policy, evals и lifecycle.

Практический вывод: следующий прирост качества и экономики часто дешевле получить не заменой LLM, а улучшением того, что находится до и после неё — context, verifier, policy gateway, deterministic benchmark, confidence gate и durable runtime.

Что обсудить с технической командой

  1. Передаём ли мы agent'у решения от имени пользователя, не проверив отдельно, насколько точно он понял preferences и constraints этого пользователя?
  2. Какие permission checks сегодня находятся внутри LLM reasoning, хотя их можно вынести в deterministic gateway/policy engine?
  3. Есть ли у каждого повторяемого agent workflow versioning, regression tests, resource budgets и prompt-injection policy как у обычного production code?
  4. Для long-running agents отделён ли durable operation state от conversational context, чтобы retries/resume были идемпотентными и проверяемыми?
  5. Где мы используем сильную дорогую модель для задачи, которую можно решить дешёвой моделью при лучшем retrieval, confidence gate и human fallback?