Hacker News Digest

Docker Agent — это CLI-плагин для Docker, позволяющий создавать и запускать ИИ-агентов через декларативный YAML-конфиг без написания кода. Агенты могут использовать инструменты, взаимодействовать с различными LLM-провайдерами (OpenAI, Anthropic, Gemini, AWS Bedrock и др.) и работать в режиме мультиагентного взаимодействия, делегируя задачи между собой. Поддерживается RAG, встроенные инструменты для мышления и памяти, а также интеграция с MCP-серверами (локальными, удалёнными или на базе Docker). Конфигурация агента описывает модель, инструкции и наборы инструментов — например, доступ к DuckDuckGo через MCP.

Установка проста: в Docker Desktop 4.63+ плагин уже включён и доступен через docker agent; также можно установить через Homebrew или загрузить бинарник с GitHub Releases. Для работы требуется API-ключ от поддерживаемого провайдера или использование Docker Model Runner для локальных моделей. Запуск агента выполняется командой docker agent run agent.yaml, а готовые агенты можно упаковывать в OCI-образы, публиковать в реестрах и запускать везде, где есть Docker. Инструмент позиционируется как способ сделать ИИ-агентов портативными, версионируемыми и совместными — как обычные контейнеры.

Docker Agent воспринимается как экспериментальный и нестабильный инструмент, не готовый к продакшену из-за отсутствия безопасности, документации и четких сценариев применения. Пользователи считают проект «gimmick», который дублирует функции аналогов (kagent, LangChain, Cloudflare Sandboxes) и не дает реальных преимуществ. Основные проблемы и споры: — Обещание «no code» считается излишним, так как современные LLM уже генерируют готовый код. — Среди критических вызовов выделяют как поддержание когерентности агентов, так и проблемы масштабирования и маршрутизации. — Новым пользователям сложно начать работу из-за нехватки практических примеров и руководств. Рекомендации: — Внедрить явный механизм песочницы, ACL-подобные ограничения на команды и сетевые данные с возможностью запроса дополнительных прав. — Создать управляемый облачный сервис для запуска YAML-агентов в изолированных средах без локальной установки Docker. — Четко описать целевые сценарии использования, чтобы отличить продукт от других агентских проектов.

Pi изначально отвергал поддержку Model Context Protocol (MCP), заявляя, что он не нужен, и даже публично критиковал его. Однако после года наблюдения за развитием MCP команда Pi пересмотрела свою позицию: протокол стал более зрелым, а необходимые изменения для его интеграции оказались полезными и для других функций, таких как Jev и Codemode. MCP был ранее доступен как расширение, но теперь включён в ядро, чтобы обеспечить лучшую интеграцию с инструментами и улучшить опыт работы с моделями, поддерживающими отложенную загрузку инструментов и динамические системные сообщения.

Ключевая мотивация — сделать инструменты более обнаруживаемыми и возвращающими структурированные данные, подобно OpenAPI, а не просто текстовые дампы. Хотя проблемы с композицией инструментов в MCP остаются, особенно из-за серверов, оптимизированных под токенную эффективность, команда Pi видит в MCP потенциал для создания удобных, скриптоподобных рабочих процессов, аналогичных CLI. Интеграция MCP в ядро позволяет лучше управлять метаданными инструментов, например, настраивать их как отложенные или специфичные для Codemode, что ранее было невозможно при использовании отдельного расширения. Таким образом, Pi решил не избегать MCP, а активно участвовать в его эволюции, чтобы сделать его более полезным в контексте современных LLM-агентов.

MCP стал жизнеспособным инструментом благодаря практическому применению в автоматизации macOS, управлении сложными системами и гибкости при изменении API, что перевесило первоначальные возражения. Пользователи применяют MCP в macOS-приложениях (rcmd, Clop, Lunar, BetterTouchTool) для управления автоматизацией через естественный язык, используя локальные модели типа Qwen и Pi. MCP позволяет избегать жесткой привязки к API, так как агенты работают с актуальным описанием инструментов, в отличие от CLI, где изменения ломают скрипты. MCP-серверы часто реализуются без шифрования (JSON-RPC по netcat) — распространённая практика в локальных сетях и доверенных средах. mcporter превращает MCP в shell-команды, интегрируя агентов в bash-пайпы и упрощая обработку ответов через jq. MCP-интеграция в Chrome DevTools эффективна благодаря структурированному доступу к внутренним состояниям браузера, недоступным через CLI. Создание MCP-сервера для личного финансового приложения с OAuth и токенами заняло мало времени — проще, чем ожидалось. Codemode не заменяет bash, а дополняет его: модель комбинирует несколько MCP-вызовов в один инструмент, повышая надёжность и снижая шум в контексте. Спор: Некоторые считают MCP избыточным по сравнению с CLI или REST API, видя в нём повторение ошибок прошлых стандартов вроде SOAP. Спор: Критики утверждают, что встраивание MCP в Pi противоречит его философии лёгкого расширяемого каркаса и приводит к «захламлению» системы. Спор: Некоторые не видят выгоды от MCP в простых сценариях, предлагая использовать субагентов вместо добавления сложности. Совет: Для enterprise-внедрения рекомендуются OpenCode, Codex, ClaudeCode и Antigravity как устойчивые харнесс-решения без зависимости от коммерческих моделей с неясной бизнес-моделью. Совет: MCP следует использовать как OpenAPI-подобный стандарт с самоописуемыми инструментами, где структурированные данные и документация позволяют автоматически обнаруживать возможности. Совет: Для работы с файлами в MCP нужна нативная поддержка загрузки/выгрузки — передача через контекст неэффективна и ограничена в большинстве харнессов. Совет: Push-уведомления от приложения к модели снизили бы нагрузку на опрос и улучшили интерактивность в долгоживущих сессиях. Совет: При использовании Pi как базового каркаса лучше оставлять MCP как расширение, а не встраивать его в ядро, чтобы сохранить гибкость и избежать избыточной сложности.

MCP (Model Context Protocol) был создан Anthropic в ноябре 2024 года как способ подключения ИИ-агентов к внешним сервисам и данным, когда модели ещё не могли надёжно работать с API напрямую. Протокол быстро набрал популярность, но привёл к контекстному перегрузу: каждый MCP-сервер добавлял множество инструментов со своими схемами, перегружая контекст моделей. Для обхода этой проблемы появились обёртки вроде Composio и MintMCP, которые централизуют учётные данные и дают агентам минимальный набор инструментов — полезное краткосрочное решение.

Однако модели значительно улучшились: теперь они способны писать и выполнять скрипты, вызывать незнакомые API, использовать CLI через --help и работать автономно. Это делает MCP излишним — агенты с доступом к терминалу могут напрямую взаимодействовать с сервисами через HTTP и CLI, минуя промежуточный слой. Автор предлагает прекратить поддержку MCP и перейти на прямое использование существующих интерфейсов, поскольку протокол устарел вместе с ростом возможностей ИИ.

MCP стал критически важным для безопасного, аудитируемого и управляемого доступа ИИ-агентов к сервисам без прямого доступа к API или терминалу, особенно в корпоративной и непрограммистской среде. Он позволяет контролировать, какие внешние сервисы может использовать агент, и изолировать API-ключи от модели, что критично для безопасности. MCP-плагины в ChatGPT и позволяют бизнес-пользователям без технического бэкграунда подключать сервисы одним кликом, делая их основным каналом взаимодействия с ИИ. MCP обеспечивает единый протокол для доступа к HTTP-сервисам и локальным процессам через stdin, что делает его гибче, чем CLI или прямые API. Многие компании, не имевшие API, теперь предоставляют MCP-серверы, чтобы дать пользователям доступ к данным через агентов — это выгодный сдвиг в сторону открытости. MCP позволяет агентам использовать новые функции сервиса сразу после обновления сервера, без переобучения модели, решая проблему устаревания контекста. Для агентов без доступа к терминалу (например, в облачных, мобильных или iPhone-средах) MCP — единственный практичный способ взаимодействия с внутренними системами. MCP-серверы могут включать трансформации и фильтрации данных, которые API не поддерживают, обеспечивая безопасный и релевантный доступ к чувствительной информации. Они также поддерживают автоматическое обновление регистраций, снижая административную нагрузку при масштабировании. MCP позволяет агентам работать с UI-приложениями (например, Unity, Blender), которые не имеют API, предоставляя скриптируемый интерфейс через сокет. Споры о избыточности MCP игнорируют случаи, где прямой доступ запрещён политиками безопасности или отсутствует. Критика о перегрузке контекста неверна: в реальных сценариях включаются только релевантные серверы. Рекомендуется развивать специализированные CLI для агентов (например, grafana/gcx), стандартизировать HTTP-заголовки для ответов в Markdown или упрощённом JSON, и использовать MCP как основу для протоколов вроде ADP (Agent Delegation Protocol). Ничего не добавлять от себя.

Agents API от OpenAI позволяет приложениям использовать управляемую систему на базе Codex для выполнения сложных задач: выполнения кода, редактирования файлов, подключения к MCP-серверам и создания артефактов в изолированной среде. OpenAI автоматически управляет сессиями, компактацией контекста и восстановлением, а разработчик предоставляет инструменты и выбирает окружение — либо хостинг OpenAI, либо собственное. Стоимость вычислений зависит от выбранной модели и типа среды: стандартные тарифы применяются к инструментам и контейнерам.

Сессии сохраняют состояние между этапами, позволяя продолжать работу без потери контекста. Примеры применений включают агентов для анализа GitHub-тикетов, расследования инцидентов, проверки документов и работы в Slack. Агенты могут делегировать задачи подагентам, использовать веб-поиск и MCP-серверы, а также суммировать предыдущие действия для управления контекстом. Поддерживается только хостинг в США, Zero Data Retention недоступен даже при использовании self-hosted сред. Создание сессии требует указания модели (например, gpt-6-astra), инструкций, инструментов и входных данных — всё это передаётся через API-вызов, после чего система сама управляет выполнением.

Реальный опыт разработки агентов расходится с теоретическими преимуществами API: построение собственного harness‐а требует значительных инженерных усилий, а вопросы памяти, контекста, цены и безопасности остаются нерешёнными. Пользователи обходят ограничения через самохостинг, локальные sandbox‐ы (например, QEMU‐VM) и нейтральные библиотеки вроде ADK, но единого решения, устраняющего зависимость от провайдера, пока нет. Главная проблема — определить правильную абстракцию для агентов; создание harness‐а — глубокий и трудоёмкий процесс. Некоторые успешно используют локальные решения (например, tmux‐менеджеры сессий) для полного контроля над окружением и отказа от провайдера. Есть разногласия: одни считают предложения OpenAI и Anthropic переоценёнными и проприетарными, другие отмечают, что субсидированные подписки делают их де-факто стандартом, несмотря на более высокие цены по сравнению с альтернативами вроде GLM 5.3. Ценообразование неясно: сессии биллируются по 20‐минутным блокам, нет простого способа принудительно завершить их — это ведёт к неожиданным расходам. Безопасность требует локального запуска агентов с защищёнными удалёнными песочницами для доступа к данным. Рекомендации: — Использовать самохостинг sandbox (как у 6thbit) для снижения зависимости от OpenAI и контроля расходов; — Применять нейтральные библиотеки (ADK) для абстрагирования от провайдеров и управления памятью/контекстом; — Планировать поддержку асинхронных вызовов инструментов, ожидания ответа от человека и отображения форм — эти аспекты часто становятся проблемными на поздних стадиях.

В центре обновлённого дорожного плана MCP — пять приоритетных направлений, сформированных совместно с сообществом. Главное внимание уделяется агентным мессенджерным примитивам: новые механизмы, такие как Tasks, subscriptions/listen и progress‑уведомления, позволяют управлять длительными потоками, перенаправлять работу в реальном времени и избавиться от постоянного опроса клиента. Эти функции разрабатываются совместно с группами Agents, Transports и Triggers & Events, а также готовятся к включению в спецификацию (SEP‑2663).

Второй ключевой блок — унификация транспорта по HTTP. После релиза 2026‑07‑28 любой удалённый MCP‑сервер превращается в обычный HTTP‑службу, что упрощает развертывание на уже используемой инфраструктуре. Планируется расширить поддержку, включая локальные серверы через Streamable HTTP и stdio, чтобы сократить сложность клиент‑серверных взаимодействий.

Третья область — идентичность агентов и корпоративная безопасность. Текущая модель авторизации, ориентированная на подтверждение в браузере, не покрывает автономных агентов в облаке. Разрабатывается стандартный способ распознавания агентских идентификаций на основе Proof‑of‑Possession (RFC 9449), чтобы обеспечить доверие без длинных токенов.

Все эти направления получают приоритет в SEP‑процессе: предложения, попадающие в соответствующие зоны, проходят ускоренный review. Присоединиться можно через Working Groups, открытые дискуссии в Discord, экспериментальные расширения experimental-ext-* или прямую работу над спецификацией и SDK.

MCP упрощает централизованное управление навыками и доступом к инструментам — можно включать/выключать их для отдельных агентов, избегать ручного распространения skills.md и скрывать чувствительные данные (например, API-ключи) за stdio-сервером, защищая их от прямого доступа LLM. Для агентов без песочницы позволяет вызывать инструменты через внешний сервер как прокси. Планируется поддержка стандартных механизмов авторизации (DPoP, Workload Identity Federation) для замены долгоживущих токенов. Однако MCP вызывает сомнения: его сложность не оправдывает пользу для самих агентов — по сравнению с REST + skills.md, преимущества ощущают только организации. В версии 1 требовался сложный слой постоянства, затруднявший развертывание. Некоторые считают внедрение собственного протокола избыточным — предпочтительнее JSON-RPC или чистый HTTP.

Stateless MCP 2.0 — выпущенный 28 июля 2026 года — вернул интерес к протоколу, упростив его до одной HTTP-запроса без сессий. Ранее требовалось два запроса: инициализация сессии и вызов инструмента, теперь всё передаётся в одном запросе через заголовки MCP-Protocol-Version, Mcp-Method и Mcp-Name, а метаданные клиента включаются в _meta. Это устраняет необходимость хранить состояние на сервере, делая систему масштабируемой и проще для реализации — автор построил три реализации за неделю.

Вдохновлённый упрощением, он создал mcp-explorer — CLI-инструмент, позволяющий через uvx mcp мгновенно тестировать MCP-серверы. Пример: запрос «count the notes» к Datasette вернул 151 заметку, с детальным логом рассуждений LLM. MCP теперь выглядит безопаснее, чем доступ к терминалу и curl: он ограничивает возможности агента заранее аудитируемыми действиями, снижая риски утечек данных и атак типа «смертельной триады». Автор планирует активно использовать MCP в чувствительных приложениях, где безопасность важнее гибкости.

Тред дополняет статью опытом эксплуатации MCP, возражениями, предложениями по улучшению и обсуждением ограничений текущей реализации. @rutierut отмечает, что навыки не загрязняют контекстное окно и гибче, но это не универсально. @ai_critic считает MCP просто RPC-over-HTTP/JSON, @lexicality — что стандартизация взаимодействия со сервисами — верный подход. @mailmrg предлагает использовать generic HTTP execution engine и YAML-описания endpoint’ов для решения проблем. @mmasu подчеркивает, что MCP даёт доступ к ресурсам, недоступным через API или CLI. @cush утверждает, что MCP менее составен, чем CLI, и может загрязнять контекст; @olmo23 отвечает, что это можно компенсировать позволением AI оценивать код и предоставляя нужные API.

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

Пример кода в статье демонстрирует базовую реализацию агента с использованием всего 15 строк кода через API OpenAI. Интересно, что контекстное окно в этом случае — просто список сообщений, а многопользовательский диалог поддерживается путем сохранения истории. Автор отмечает, что сам LLM является stateless-черным ящиком, а иллюзия непрерывного диалога создается разработчиком. Даже если многие специалисты не сочтут этот пример полноценным агентом (который должен использовать инструменты), добавление инструментов также оказывается простой задачей.

• Обсуждение показало, что большинство участников считают, что писать агентов вручную — это не только учебное упражнение, но и способ глубже понять, как работают LLM и инструменты вроде MCP.
• Участники подчеркнули, что даже простой агент может быть реализован всего в несколько строк кода, но при этом важно понимать, что именно делает его "агентом" — способность к итерации и само-улучшению.
• Обсуждались риски безопасности и контроля при использовании агентов, особенно в контексте предоставления им доступа к оболочке и файловой системе.
• Также обсуждались вопросы, связанные с тем, что агенты могут быть использованы для решения задач, которые еще не решены, и что это может быть более ценно, чем попытка создать еще один чат-бот или инструмент для уже решенной задачи.
• В конце обсуждение перешло к тому, что важно помнить, что даже если вы не собираетесь писать агентов для продакшена, опыт их создания может быть полезен для понимания того, как работают инструменты, которые вы используете, и как они могут быть использованы или злоупотреблены.

Claude Skills — новый подход, где LLM использует специальные файлы-инструкции для решения задач. Например, Anthropic предоставляет шаблон для создания гифок под Slack: в нём есть код для проверки размера файла, валидации и даже пример готового GIF. Это позволяет Клоду генерировать контент, который сразу проходит модерацию платформы.

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

По сути, Claude Skills — это шаблон для создания инструментов, которые LLM может использовать "по требованию". Это открывает путь к генерации не только медиа, но и документов, баз данных и даже ПО через подобные шаблоны. Уже сейчас есть навыки для работы с Excel, Word и PowerPoint, что делает систему универсальным ассистентом для автоматизации рутинных задач.

• Существуетение, что MCP и "skills" — это просто переименование уже существующих концептов: MCP — это стандартизированный способ подключения внешних сервисов, а skills — это просто контекст под рукой.
• Участники обсуждения отмечают, что большинство MCP-серверов бесполезны и могут быть заменены простым вызовом CLI-утилит.
• Некоторые участники подчеркивают, что Skills и MCP решают разные задачи: MCP — это про интеграцию внешних сервисов, а Skills — про управление контекстом.
• Участники также обсуждают, что Skills могут быть более удобны для конечного пользователя, так как они не требуют сложной настройки и могут быть созданы просто как текстовый файл.

Claude теперь может использовать «навыки» для выполнения специализированных задач — это папки с инструкциями и ресурсами, которые Claude загружает по мере необходимости. Это позволяет Claude работать с такими объектами, как Excel, Word и PowerPoint, преобразуя их в нужные форматы, например, создавая отчёты из нескольких таблиц. Функция работает во всех продуктах Claude: в приложениях, API и Claude Code. В организациях это ускоряет работу с финансами и отчётностью, экономя часы рутинной работы.

• Обсуждение охватывает вопросы от навыков и их взаимодействия с MCP, субагентами и инструментами, до того, как они влияют на разработку и использование навыков в Anthropic и в целом на экосистему инструментов.
• Участники обсуждают, что навыки могут быть просто переименованными инструкциями или инструментами, и что их влияние на разработку может быть ограничено.
• Также обсуждается, что навыки могут быть использованы для упрощения сложных задач, но также может быть использованы для создания более сложных и запутанных инструментов.
• Участники также обсуждают, что навыки могут быть использованы для автоматизации задач, но также может быть использованы для создания более сложных и запутанных инструментов.
• В конце обсуждение подводит к тому, что навыки могут быть использованы для создания более сложных и запутанных инструментов, но также может быть использованы для автоматизации задач.

OpenAI представила Apps SDK — фреймворк для разработки приложений, интегрируемых напрямую в ChatGPT. Он позволяет создавать инструменты на основе MCP-серверов, настраивать пользовательский интерфейс, управлять аутентификацией и хранить данные. Сейчас доступен в режиме предпросмотра для тестирования, а публичная отправка приложений откроется позже в этом году.

Разработчикам предлагаются чёткие руководства по дизайну, безопасности и метаданным, чтобы приложения соответствовали стандартам качества и органично вписывались в экосистему ChatGPT. Процесс включает планирование use-cases, развёртывание серверов и подключение к ChatGPT, с примерами и troubleshooting для упрощения разработки.

• OpenAI представляет платформу "Apps" на базе MCP, позволяющую интегрировать сторонние сервисы (например, бронирование отелей, поиск недвижимости) прямо в чат-интерфейс ChatGPT.
• Мнения разделились: одни видят в этом стратегический шаг к созданию экосистемы и монетизации (доля от транзакций, скрытая реклама), другие критикуют за слабую UX, бритвость и повторение прошлых неудач (как Custom GPTs).
• Поднимаются вопросы для разработчиков: монетизация, риск заблокирования будущими обновлениями ChatGPT и усиление зависимости от OpenAI.
• Техническая реализация вызывает вопросы: работа примеров кода, механизм внедрения интерактивных элементов (iframe?) и ограничения MCP.
• Обсуждается фундаментальный конфликт: должен ли чат быть универсальным интерфейсом или AI-функции лучше встраивать в традиционные приложения.

• Локальный стек: Ollama (LLM), assistant-ui (веб-интерфейс), Apple container (изолированные ВМ), Playwright (браузер), coderunner (MCP-сервер с Jupyter).
• Цель: чат, запуск кода и доступ в интернет без облаков и утечек данных.
• Проблемы:
  – Модели Ollama пока не поддерживают вызовы инструментов.
  – Создание нативного Mac-приложения провалилось: a0.dev заточен под iOS, Electron + NextJS оказались геморроем.
  – Apple container часто падает с Trap; помогает pkill + перезапуск.
• Решения:
  – Веб-версия assistant-ui через ai-sdk с выпадающим списком моделей (локальных и облачных).
  – Jupyter в изолированной ВМ, доступен по MCP: http://coderunner.local:8222/mcp.
  – Конфиг для Claude Desktop: "coderunner": { "httpUrl": "http://coderunner.local:8222/mcp" }.

• Участники восхищаются локальной, «песочной» архитектурой для приватного AI-воркспейса и инструментом coderunner, но отмечают, что узкие места — это не только софт, но и «железо»: 80B-модели требуют ≥80 ГБ быстрой RAM, что доступно разве что на RTX 4090 или Strix Halo.
• Критичным становится слой знаний: RAG над личными файлами требует вектор-БД, а значит — много диска и оперативки; Docker-обёртка или docker compose up -d просится как минимальный способ разворачивания.
• Пока локальные модели — скорее «увлекательное хобби» (медленно, глючно, нужен тюнинг), чем рабочий инструмент; облачные API (Cerebras, Groq) дают 1000 ток/с, но подрывают приватность.
• Сообщество просит готовый «всё-в-одном» стек: веб-поиск, голосовой режим, image-gen, лёгкий switch «локально ↔ облако» без потери данных.
• Несколько участников делятся своими решениями: Kasm + Ollama, Open WebUI, MLX-электрон-приложение, Synology-NAS-контейнеры, браузерный LLM без установки.