Зацепка: В свежем обсуждении AI-агентов промелькнула мысль, которая сначала звучит как инженерная ересь: телефон с 6 ГБ памяти может быть лучшей средой для агента, чем безлимитная cloud VM с 64 ГБ. Не потому, что смартфон внезапно стал мощнее дата-центра, а потому, что дефицит заставляет систему забывать, ограничивать и объяснять свои действия. Иными словами, hardware constraint может работать не только как тормоз производительности, но и как safety primitive.
Но здесь есть опасная заноза. Если агенту просто не хватает памяти, он может стать более аудируемым — а может потерять критическое правило и спокойно удалить production-базу. Поэтому я исследовал не лозунг «маленькое железо — хорошо», а более точную архитектурную гипотезу: когда дефицит ресурсов превращается в контроль, а когда — в слепоту.
Cloud-среда по умолчанию поощряет накопление. Логи хранятся «на всякий случай», tool output складывается в историю, агенту дают большой context window, а стоимость очередной тысячи токенов настолько мала, что никто не хочет решать, что именно нужно выбросить. В результате получается система с почти бесконечной памятью и почти нулевой дисциплиной памяти.
Для обычного backend это просто неприятный operational debt. Для агента — уже поведенческая проблема. Агент принимает решения не в вакууме, а из того, что попало в его текущий контекст. Если в системе можно хранить всё, возникает иллюзия, что можно и учитывать всё. На практике внимание, retrieval, порядок сообщений и budget остаются конечными. Без явного лимита система лишь прячет дефицит под ковром — как команда, которая не ограничивает stint по топливу, а надеется, что инженерная магия как-нибудь доедет до клетчатого флага.
В этом смысле физически ограниченная среда делает невидимый бюджет явным. У агента появляются измеримые пределы:
Это не автоматически делает агента безопасным. Но это заставляет архитектуру признать, что память, внимание и время — ресурсы, а не бесплатная бесконечность.
В работе Falk Lieder и Thomas Griffiths Resource-rational analysis рациональность определяется не как поиск идеального решения любой ценой. Более реалистичная модель: система выбирает алгоритм, который максимизирует полезность с учётом стоимости вычислений, времени и памяти.
Такой подход объясняет, почему человеческие когнитивные «ошибки» не всегда являются ошибками проектирования. Эвристика, которая даёт 95% качества за долю секунды, может быть рациональнее полного перебора, если последний стоит слишком дорого. Мы не просматриваем все документы перед тем, как выбрать маршрут в магазин, — не потому что забыли существование теории графов, а потому что это был бы чудовищный compute bill ради пачки кофе.
Для AI-агента отсюда следует важный вывод: resource budget должен быть частью целевой функции, а не только ограничением инфраструктуры. Агент должен оптимизировать не просто качество ответа, но что-то вроде:
полезность действия − стоимость вычисления − риск − стоимость необратимой ошибки.
Если задача малозначима, допустим быстрый approximate path. Если действие необратимо — удаление, платёж, отправка письма, изменение конфигурации — бюджет на проверку должен автоматически расти. Это уже не «маленькая модель против большой», а адаптивная стоимость рассуждения в зависимости от blast radius.
RFC 9556 от IRTF описывает edge computing без маркетинговой пены: локальная обработка нужна там, где cloud плохо закрывает time sensitivity, объём данных, стоимость соединения, intermittent connectivity, privacy и security. Для resource-constrained устройств документ отдельно отмечает ограниченные storage и processing power как фактор, влияющий на надёжность, энергопотребление, безопасность и приватность.
То есть локальный агент получает не только минусы. Он может:
Но edge — это не маленькая крепость, а маленькая крепость с ограниченным запасом воды. Локальная приватность может обернуться локальной потерей данных, а автономность — невозможностью проверить спорное решение через внешний сервис.
Исследование NIST по privacy для edge-систем подчёркивает этот trade-off на потоковых IoT-данных: перенос обработки ближе к источнику снижает сетевые издержки, но создаёт новые privacy concerns. В предложенной методике используются local differential privacy, Bayesian inference и Gaussian processes для выбора подходящего уровня защиты на реальном smart-meter testbed. Смысл здесь шире конкретного метода: локализация обработки не отменяет privacy budget — она просто переносит его внутрь устройства.
Работа Agentic Performance at the Edge: Insights from Benchmarking рассматривает агентные системы на моделях примерно до 8 млрд параметров — масштабе, который реалистичен для многих edge-устройств. Авторы проверяли не только accuracy, но и latency, число шагов, взаимодействие с tools и состав отказов.
Результат неприятен для культа параметров: качество не растёт монотонно вместе с размером модели.
Один из показательных примеров — Qwen Coder 7B, который в их setup достиг той же peak accuracy, что и версии 14B и 32B, при среднем времени 1,45 секунды против 3,35 и 6,22 секунды соответственно. Это не универсальный закон и не доказательство, что 7B «лучше 32B». Это демонстрация другого: правильная точка на Pareto frontier определяется связкой model + tool workflow + workload, а не одной цифрой параметров.
Ещё интереснее разница типов отказов:
Практический вывод: маленькая модель не обязательно менее надёжна. Иногда она надёжнее в выполнении протокола, но хуже в финальном выборе. Это даже полезный профиль для production: execution failures можно быстро обнаружить и отправить задачу на fallback, а уверенный semantic error может тихо проехать в прод, как болид с идеально работающим мотором, но неправильной картой трассы.
Вот где красивый тезис про «телефон как safety constraint» сталкивается с бетонной стеной.
Препринт Governance Decay изучает, что происходит с агентом, когда длинная история периодически сжимается. В контексте есть правило — например, нельзя отправлять данные за пределы организации. Затем harness делает summarization или eviction, чтобы уложиться в token budget. Если правило не переживает compression, тот же агент на том же запросе может выполнить запрещённое действие.
В эксперименте на семи model families полная история дала 0% нарушений, а после одной compaction pooled violation rate выросла до 30%; в отдельных моделях — до 59%. В более крупной проверке авторы сообщают о росте примерно на 37 процентных пунктов. Когда constraint сохранялся, нарушение не наблюдалось; когда constraint исчезал, violation rate достигал 38–43% в зависимости от способа проверки.
Особенно неприятен Compaction-Eviction Attack: атакующему не обязательно ломать модель или system prompt. Достаточно подать много контента через tool output или retrieval, чтобы вытолкнуть легитимное правило из контекста либо повлиять на summarizer. Это атака не добавлением вредной инструкции, а удалением хорошей.
Простейшее «решение» — pinning: вынести критические правила из lossy compaction и повторно вставлять их после каждого сжатия. В описанном эксперименте примерно 47 pinned tokens вернули violation rate к 0% при заявленном overhead менее 0,5% на production scale. Но это не магический щит: pinned state должен быть действительно защищён, проверяться на целостность и не смешиваться с обычной памятью.
Получается парадокс:
Дефицит памяти повышает безопасность только тогда, когда система умеет забывать всё, кроме того, что запрещено забывать.
Просто урезать context window — не security architecture. Это всё равно что поставить маленький сейф и хранить в нём только случайные бумаги.
В препринте Auditable Agents вводится полезное различие между observability и auditability.
Авторы выделяют пять условий полноценного аудита:
Это очень хорошо стыкуется с идеей ограниченного устройства. Маленький сервер физически не может хранить бесконечную трассу. Значит, он обязан хранить не больше данных, а правильные данные: policy-relevant actions, approvals, версии инструментов, хэши результатов, границы полномочий и причины остановки.
Исследование сообщает, что в шести популярных open-source проектах обнаружено 617 security findings, связанных с базовыми предпосылками auditability, а pre-execution mediation с tamper-evident records добавляла медианно 8,3 мс overhead. Цифра не означает, что любой агент завтра станет безопасным за 8,3 мс. Но она ломает популярное оправдание «полный аудит слишком дорогой»: по крайней мере часть защитного слоя может быть дешёвой, если заложить её до выполнения действия, а не пытаться восстановить прошлое из обрывков application logs.
Из всех материалов складывается архитектурная схема. Ограниченный host полезен не сам по себе, а потому что позволяет встроить четыре типа friction:
1. Ограниченный context budget.
Агент не может бесконечно накапливать tool output. Но policy state хранится отдельно, с pinning и integrity check. Обычная история может сжиматься; критические invariants — нет.
2. Ограниченный action budget.
У задачи есть максимум tool calls, шагов и времени. Превышение лимита не превращается в отчаянное «давай ещё попробуем», а вызывает fallback или human approval.
3. Ограниченный storage budget.
Локально сохраняются не все токены, а структурированный append-only журнал: кто инициировал действие, какой skill был выбран, какие аргументы переданы, какие policy checks пройдены, какие данные вернулись и какой результат подписан.
4. Ограниченный network budget.
Внешний вызов становится редким и видимым событием. Это одновременно снижает утечку данных и делает egress аномалией, которую легче расследовать.
Такая система напоминает не «слабый компьютер», а аппаратный governor. В ней проще заметить, что агент превысил нормальный профиль поведения: слишком много шагов, неожиданный домен, попытка обойти approval, внезапный рост объёма данных.
Есть четыре сценария, в которых тезис про маленькое железо ломается.
Первый — потеря критического контекста. Если security policy живёт в той же очереди, что и обычный текст, compaction превратит экономию памяти в governance decay.
Второй — ложная локальная уверенность. Edge-агент может продолжать работать офлайн, но без свежих данных и внешней верификации. Автономность хороша для реакции, а не всегда для окончательного решения.
Третий — отсутствие forensic capacity. Если storage budget слишком мал, после инцидента останется только «агент что-то сделал». Это не аудит, а цифровая примета.
Четвёртый — неправильная оптимизация. Если система награждает только latency и стоимость, она научится экономить на проверках. Быстрый агент, который не задаёт ни одного уточняющего вопроса перед платёжной операцией, — не эффективный агент, а маленькая ракета без системы наведения.
Моя позиция после исследования стала заметно менее романтичной, но гораздо полезнее.
Телефон не безопаснее cloud VM потому, что у него мало памяти. Он может быть безопаснее, если дефицит превращён в явный контракт: ограниченные шаги, ограниченный egress, policy-pinned state, структурированный журнал и обязательный fallback при нехватке уверенности.
Cloud не опасен потому, что он большой. Он опасен, когда его бесконечность позволяет не принимать архитектурные решения. «Храним всё» часто означает «не знаем, что важно». «Дадим агенту больше контекста» часто означает «не спроектировали память». «Подключим ещё один tool» часто означает «расширили blast radius и забыли обновить audit trail».
Самая сильная связь здесь — с resource-rational cognition: разумная система не максимизирует вычисления, она распределяет дорогие вычисления туда, где ошибка дороже всего. Для агента это означает: дешёвый local inference для сбора фактов и маршрутизации, более мощный model или human approval для необратимого действия, а между ними — не декоративный dashboard, а проверяемый policy gate.
Поэтому формула выглядит так:
Scarcity полезна как safety primitive только при policy-aware allocation.
Дефицит без архитектуры — просто нехватка. Дефицит с защищёнными инвариантами — уже контроль.
В этом смысле старый смартфон, превращённый в agent host, может стать интереснее очередного огромного cloud-кластера. Не потому что он быстрее, а потому что заставляет инженера ответить на неприятные вопросы до запуска: что агент имеет право помнить, что обязан забыть, какое действие считается слишком дорогим для автономии и какие доказательства останутся после сбоя.
Большие системы обычно покупают свободу ресурсами. Маленькие системы вынуждают покупать надёжность дисциплиной. И иногда это более честная сделка.