3. Архитектура и эксплуатация агентных систем
AWS AgentCore Runtime V2: agent compute начинают тарифицировать по реальному CPU, а не по времени жизни сессии
Что произошло. В значимом backfill от 18 сентября AWS выпустила следующее поколение Amazon Bedrock AgentCore Runtime. Это serverless microVM runtime с hardware-enforced session isolation, scale-to-zero, elastic memory reclamation и snapshot-based cold start. Среда подготавливается один раз, затем новые instances восстанавливаются из snapshot.
Почему это важно. Агент принципиально отличается от обычного web-service: он много ждёт — LLM, browser, MCP/API, database, human approval. Если платить за зарезервированный CPU всё время жизни session, значительная часть стоимости приходится на idle wait. Agent-specific runtime начинает оптимизировать именно эту форму workload.
Что показали данные. AWS сообщает P75 cold start 1,9–2,0 с для container images от 200 MB до 2 GB против 5,4–30 с у V1. В pricing documentation AWS оценивает типичный I/O wait agent workloads в 30–70% времени. В своём illustrative example с 10 млн 60-секундных support-agent sessions и 70% I/O wait AWS получает $7 235 в месяц за Runtime compute; это vendor pricing example, не независимое production measurement.
Что нужно уже понимать: microVM, session isolation, cold start, I/O wait, active-resource billing.
Что это может изменить для продукта или engineering-команды. Если agent работает минуты или часы, стоимость execution layer нужно считать отдельно от token cost. Имеет смысл сравнить pre-provisioned containers с agent-specific runtime на реальном профиле CPU/memory/I/O, особенно при bursty concurrency.
Дата: 18 сентября 2026; backfill.
Первоисточники: https://aws.amazon.com/about-aws/whats-new/2026/09/new-agentcore-runtime-generally-available/ ; https://aws.amazon.com/bedrock/agentcore/pricing/
SafeHarness: одной инструкции «не делай опасное» недостаточно — constraint нужно встроить в planner
Что произошло. Исследователи проверили coding-agent paradigm для robot manipulation: LLM пишет controller program, но каждая задача дополнительно содержит obstacle, которого робот не должен касаться. Агент видел obstacle и рассуждал о нём в trace, а prompt явно запрещал collision, однако baseline всё равно часто оптимизировал только достижение цели. SafeHarness добавляет отдельные obstacle-aware route planning и contact-execution stages: построить маршрут, проверить, при необходимости перепланировать и лишь затем выполнить.
Почему это важно. Это физический пример общего agent pattern: constraint в prompt ≠ constraint в execution policy. Если ограничение критично, оно должно участвовать в планировании и verification path, а не быть пожеланием в natural-language instructions.
Что показали данные. SafeHarness получил 71,9% task success и 87,5% collision avoidance; авторы сообщают соответственно 2,3× и 1,5× результат того же агента без harness. Также заявлено +6,5 и +27,0 процентного пункта против предыдущего SOTA по этим двум метрикам. Это академический preprint, ещё не peer-reviewed; unit of evaluation — robot-manipulation tasks с явно заданным obstacle.
Что нужно уже понимать: planner, constraint enforcement, verification, replanning, coding agent.
Что это может изменить для продукта или engineering-команды. Для payments, deletion, production changes и других high-impact actions стоит проверить: ограничение только написано в system prompt или реально влияет на planner и hard gate перед action? Для критичных constraints второй вариант предпочтительнее.
Дата: 17 сентября 2026; backfill.
Первоисточник: https://arxiv.org/abs/2609.20822
DeltaSelect: полный coding-agent benchmark плохо подходит для ежедневного A/B-тестирования harness
Что произошло. DeltaSelect предлагает выбирать небольшой фиксированный набор benchmark tasks, чьи single-run результаты статистически лучше отслеживают поведение полного benchmark, и укладывать этот набор в заданный dollar budget. Авторы подчёркивают: метод предназначен для повторных baseline-vs-candidate экспериментов при разработке prompts, skills и harness, а не для публичного ranking моделей.
Почему это важно. Команды часто либо вообще не regression-test'ят agent instructions из-за стоимости, либо делают выводы по нескольким удобным задачам. Исследование показывает, что «случайная маленькая подвыборка» может быть очень шумным proxy полного benchmark.
Что показали данные. В resampling опубликованных DeepSWE trials лишь 19,5% задач — 22 из 113 — имели fifth-percentile Pearson correlation не ниже 0,50 с full-benchmark performance. В case study с GPT-5.6 Luna low-reasoning через 13 evals была выбрана версия skills/instructions со стоимостью $1,75 против $4,18 у исходной, то есть −58,1% (p=0,008); calibrated score был 42,36% против 36,46%, но paper приводит p=0,326 для published-analog variance, поэтому прирост score не стоит интерпретировать как надёжно доказанный общий quality gain. Это single-author preprint без peer review.
Что нужно уже понимать: A/B evaluation, sampling variance, Pearson correlation, regression test, cost per eval.
Что это может изменить для продукта или engineering-команды. Имеет смысл создать дешёвый внутренний regression suite, статистически откалиброванный против более полного benchmark. Он нужен для частых изменений skills/harness; периодически всё равно следует запускать большой suite, чтобы маленький набор не превратился в новую цель для overfitting.
Дата: 17 сентября 2026; backfill.
Первоисточник: https://arxiv.org/abs/2609.19607