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