Agents | The .NET Blog

NL2SQL — это SQL-инъекция агентной эпохи

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

Есть версия предложения NL2SQL, которая звучит идеально: пользователи задают вопросы на естественном языке, агенты генерируют SQL, данные возвращаются. Меньше экранов, меньше запросов, меньше кода. Просто.

Потом вы думаете об этом ещё пять минут.

Проблемы, о которых никто не говорит на демо

Схемы не были созданы для объяснения вещей. Криптические имена таблиц, непоследовательные имена столбцов, технически допустимые связи, которые семантически недопустимы без дополнительных предикатов — это нормально для корпоративных баз данных. Это не баги, это просто накопленная история бизнес-изменений. Но когда вы просите модель вывести намерение из схемы, которая не была создана для передачи намерения, модель попробует в любом случае. Она не сдастся. Она сгенерирует свой лучший вариант запроса и вернёт результаты с уверенностью.

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

Пользовательская проверка не масштабируется. “Просто проверяйте каждый запрос перед выполнением” звучит безопасно. Но это предполагает, что пользователи являются экспертами как в модели данных, так и в SQL — именно те люди, которым не нужен был интерфейс на естественном языке. Это также вводит когнитивную перегрузку и новый класс предвзятости подтверждения, где пользователи, перегруженные сложностью запроса, утверждают недействительные запросы вместо того, чтобы их исследовать.

И затем есть инъекция. В традиционной разработке SQL параметризация решала проблему инъекции, потому что пользовательский ввод заполнял параметры, а не структуру SQL. С NL2SQL модель сама генерирует SQL. Подсказка, контекст схемы, история разговора и полученные данные — всё влияет на то, что выполняется. Если кто-то создаёт подсказку, которая изменяет то, что генерирует модель, это инъекция — не на уровне параметра, а на уровне генерации запроса. И в отличие от удаления таблицы (очевидно, восстановимо), инъекция NL2SQL производит запросы, возвращающие неверные результаты без видимой ошибки. Бизнес-решения принимаются на основе неверных данных.

Что на самом деле решает SQL MCP Server

Именно здесь статья делает свой самый полезный практический вывод. Вместо того чтобы давать агенту произвольный доступ к схеме и надеяться на лучшее, SQL MCP Server предоставляет курируемую поверхность API, построенную на основе Data API builder.

Разница важна: агент не генерирует SQL. Он вызывает именованные конечные точки, которые возвращают предопределённые формы результатов. SQL пишется один раз, разработчиком, и является детерминированным. Недетерминизм агента ограничен выбором какую конечную точку вызвать, а не построением произвольных запросов.

Это аналогично тому, что параметризация сделала с SQL-инъекцией в традиционной модели приложений — вы убираете возможность создавать произвольные запросы из ненадёжного ввода.

Правильный вопрос

Статья не говорит “никогда не используйте NL2SQL.” Она говорит: будьте целенаправленны в том, где вы применяете его и что вы открываете. Для исследовательского анализа в контролируемой среде, с ограниченной схемой и доступом только для чтения, NL2SQL может подойти. Для производственных систем, где бизнес-решения зависят от результатов, курируемый уровень API значительно безопаснее.

Честность: некоторые проблемы действительно лучше решаются структурированными запросами за именованными конечными точками, чем естественным языком в SQL. SQL MCP Server даёт вам эту возможность, не отказываясь полностью от агентного интерфейса.

Оригинальная публикация: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

У Вашего ИИ-Агента Проблема с Идентификацией (И Вот Шаблон, Который Её Решает)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

Есть момент в каждом проекте ИИ-агента, который выглядит примерно так: демо работает идеально, агент интерпретирует естественный язык, вызывает нужные API, возвращает нужные данные. Затем вы начинаете думать о реальных пользователях.

Что мешает сессии агента одного пользователя видеть данные другого пользователя? Что если агент будет обманут через инъекцию промпта? Что если он вызовет инструмент неожиданным образом?

Это не крайние случаи. Это проектные решения, которые нужно принять перед запуском.

Новый шаблон azd от Curity и Microsoft даёт вам рабочий эталон именно для этой проблемы.

Основная Проблема: Аутентификация ≠ Авторизация

Большинство примеров агентов хорошо справляются с аутентификацией пользователей. Они плохо справляются с авторизацией. Знание кто является пользователем не говорит вам, какие данные он должен видеть.

Традиционное клиентское приложение делает предсказуемые вызовы API. ИИ-агент не является детерминированным — он интерпретирует естественный язык и решает, что вызывать. Он может быть творческим. Он также может ошибаться. И если он манипулируется через инъекцию промпта, вам нужны правила, которые не зависят от хорошего поведения ИИ.

Решение, которое демонстрирует этот шаблон: краткосрочные токены, несущие именно правильную информацию для каждого перехода.

Как Работает Цепочка Токенов

Шаблон использует токены доступа OAuth 2.0 с обменом токенов для сужения разрешений на каждом шаге. Токен пользователя обменивается дважды, прежде чем достигнет MCP-сервера:

Первый обмен — сужает область применения и преобразует непрозрачный токен в JWT
Второй обмен — добавляет идентификацию агента и новую аудиторию для перехода к MCP-серверу

Как выглядит токен MCP-сервера:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

customer_id встроен в токен сервером авторизации, а не передаётся как параметр, которым управляет агент. API проверяет токен, а не инструкции агента.

Это означает: даже если кто-то обманет агента, заставив его попытаться получить данные другого клиента, токен не авторизует это.

Что Развёртывает Шаблон

С несколькими командами azd вы получаете:

Бэкенд-агент на Microsoft Foundry (C#, SDK Microsoft A2A и MCP)
MCP-сервер, предоставляющий пример портфельного API
Curity Identity Server в качестве сервера авторизации, наряду с Entra ID для аутентификации
Внешние и внутренние API-шлюзы, обрабатывающие обмен токенов и журналирование аудита
Bicep для всей инфраструктуры Azure: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, хранилище

Весь шаблон поддаётся проверке и настройке.

Принцип Дизайна, Достойный Заимствования

Даже если вы не используете Curity, шаблон можно перенести: агенты никогда не должны иметь постоянный доступ к API. Каждое действие должно использовать краткосрочный токен с минимальной областью применения, необходимой для этого конкретного вызова, выданный для конкретной идентификации агента, несущий утверждения, которые API нужны для принятия решений об авторизации.

Это устойчиво к творческим агентам, ошибкам и инъекции промпта теми способами, которыми «просто убедитесь, что агент не делает плохих вещей» никогда не будет.

Заключение

Шаблоны безопасности для ИИ-агентов всё ещё разрабатываются в отрасли. Этот шаблон является одной из наиболее полных эталонных реализаций, которые я видел — он охватывает фактический поток авторизации, а не только аутентификацию.

Оригинальный пост: Least privilege AI agents: A new azd template from Curity and Microsoft

CodeAct в Agent Framework: Как сократить задержку агента вдвое

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Эта статья была переведена автоматически. Для просмотра оригинала нажмите здесь.

В каждом проекте с агентами наступает момент, когда смотришь на трассировку и думаешь: «Почему это так долго работает?» Модель в порядке. Инструменты работают. Но для получения результата, который можно вычислить за один раз, происходит семь туров обмена данными.

Именно эту проблему решает CodeAct — и команда Agent Framework только что выпустила альфа-поддержку через новый пакет agent-framework-hyperlight.

Что такое CodeAct?

Паттерн CodeAct элегантно прост: вместо того чтобы давать модели список инструментов для поочерёдного вызова, вы даёте ей единственный инструмент execute_code и позволяете выразить весь план как короткую программу на Python.

Подход	Время	Токены
Традиционный	27,81с	6 890
CodeAct	13,23с	2 489
Улучшение	52,4%	63,9%

Безопасность: Микро-VM Hyperlight

Пакет agent-framework-hyperlight использует микро-VM Hyperlight. Каждый вызов execute_code получает собственную свежесозданную микро-VM. Запуск измеряется в миллисекундах. Изоляция практически бесплатна.

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

Минимальная настройка

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Когда использовать CodeAct (и когда не стоит)

Используйте CodeAct, когда:

Задача включает много небольших вызовов инструментов (поиск, объединение, вычисления)
Важны задержка и стоимость токенов
Нужна надёжная изоляция для кода, генерируемого моделью

Оставайтесь на традиционном вызове инструментов, когда:

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

Попробуйте сейчас

pip install agent-framework-hyperlight --pre

Читайте полную статью в блоге Agent Framework для углублённого изучения.

Где Ваш Агент Помнит Вещи? Практическое Руководство по Хранению Истории Чата

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Этот пост переведён автоматически. Чтобы просмотреть оригинал, нажмите здесь.

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

Оно определяет, могут ли пользователи ветвить беседы, отменять ответы, возобновлять сессии после перезапуска и покидают ли ваши данные вашу инфраструктуру. Команда Agent Framework опубликовала глубокий анализ.

Два основных паттерна

Управляемое сервисом: ИИ-сервис хранит состояние разговора. Ваше приложение хранит ссылку, и сервис автоматически включает нужную историю в каждый запрос.

Управляемое клиентом: ваше приложение поддерживает полную историю и отправляет нужные сообщения с каждым запросом. Сервис не имеет состояния. Вы контролируете всё.

Как Agent Framework это абстрагирует

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Меня зовут Алиса.", session);
var second = await agent.RunAsync("Как меня зовут?", session);

session = agent.create_session()
first = await agent.run("Меня зовут Алиса.", session=session)
second = await agent.run("Как меня зовут?", session=session)

Быстрый справочник по поставщикам

Поставщик	Хранилище	Модель	Компрессия
OpenAI/Azure Chat Completions	Клиент	N/A	Вы
Foundry Agent Service	Сервис	Линейная	Сервис
Responses API (по умолчанию)	Сервис	Ветвящаяся	Сервис
Anthropic Claude, Ollama	Клиент	N/A	Вы

Как выбрать

Нужны ветвление или «отмена»? → Responses API, управляемый сервисом
Нужен полный контроль над данными? → Управляемое клиентом с DB-бэкендом
Простой чатбот? → Линейное, управляемое сервисом, — достаточно

Читайте полный пост для полного дерева решений.

Foundry Toolboxes: Единый эндпоинт для всех инструментов агентов

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Этот пост был автоматически переведён. Для оригинальной версии нажмите здесь.

Есть проблема, которая кажется скучной, пока не столкнёшься с ней лично: организация строит несколько ИИ-агентов, каждому нужны инструменты, и каждая команда настраивает их с нуля. Та же интеграция веб-поиска, та же конфигурация Azure AI Search, то же подключение к GitHub MCP-серверу — но в другом репозитории, другой командой, с другими учётными данными и без общего управления.

Microsoft Foundry только что выпустила Toolboxes в Public Preview — прямой ответ на эту проблему.

Что такое Toolbox?

Toolbox — это именованный, многократно используемый набор инструментов, который определяется один раз в Foundry и предоставляется через единый MCP-совместимый эндпоинт. Любая среда выполнения агента, говорящая на MCP, может его потреблять — никакой привязки к Foundry Agents.

Обещание простое: build once, consume anywhere. Определить инструменты, настроить аутентификацию централизованно (OAuth passthrough, управляемые удостоверения Entra), опубликовать эндпоинт. Каждый агент, которому нужны эти инструменты, подключается к эндпоинту и получает их все.

Четыре столпа (два доступны сегодня)

Столп	Статус	Что делает
Discover	Скоро	Находить одобренные инструменты без ручного поиска
Build	Доступен	Собирать инструменты в многократно используемый bundle
Consume	Доступен	Единый MCP-эндпоинт предоставляет все инструменты
Govern	Скоро	Централизованная аутентификация + observability для всех вызовов

Практический пример

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Поиск по документации и ответы на GitHub-issues.",
 tools=[
 {"type": "web_search", "description": "Поиск в публичной документации"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

После публикации Foundry предоставляет единый эндпоинт. Одно подключение — все инструменты.

Нет привязки к Foundry Agents

Toolboxes создаются и управляются в Foundry, но поверхность потребления — открытый протокол MCP. Их можно использовать из кастомных агентов (Microsoft Agent Framework, LangGraph), GitHub Copilot и других MCP-совместимых IDE.

Почему это важно сейчас

Волна мульти-агентов добирается до продакшена. Каждый новый агент — это новая поверхность для дублированной конфигурации, устаревших учётных данных и непоследовательного поведения. Основа Build + Consume достаточна, чтобы начать централизацию. Когда придёт столп Govern, появится полностью наблюдаемый, централизованно управляемый инструментальный слой для всего парка агентов.

Итог

Пока рано — Public Preview, сначала Python SDK, Discover и Govern ещё впереди. Но модель надёжная, а MCP-нативный дизайн означает, что она работает с инструментами, которые уже строятся. Подробности в официальном анонсе.

VS Code 1.117: Агенты получают собственные ветки Git, и я полностью за

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Грань между «ИИ-ассистентом» и «ИИ-тиммейтом» продолжает стираться. VS Code 1.117 только что вышел, и полные заметки о релизе насыщены, но суть ясна: агенты становятся полноценными участниками вашего рабочего процесса разработки.

Вот что действительно важно.

Режим Autopilot наконец запоминает ваши настройки

Раньше приходилось заново включать Autopilot каждый раз при запуске новой сессии. Раздражало. Теперь режим разрешений сохраняется между сессиями, и вы можете настроить значение по умолчанию.

Agent Host поддерживает три конфигурации сессии:

Default — инструменты запрашивают подтверждение перед запуском
Bypass — автоматически одобряет всё
Autopilot — полностью автономный, сам отвечает на свои вопросы и продолжает работу

Если вы создаёте новый .NET-проект с миграциями, Docker и CI — установите Autopilot один раз и забудьте. Эта настройка сохранится.

Worktree и git-изоляция для сессий агентов

Это главное. Сессии агентов теперь поддерживают полную изоляцию worktree и git. Это значит, что когда агент работает над задачей, он получает собственную ветку и рабочую директорию. Ваша основная ветка остаётся нетронутой.

Ещё лучше — Copilot CLI генерирует осмысленные имена веток для этих worktree-сессий. Никаких больше agent-session-abc123. Вы получаете название, которое действительно описывает, чем занимается агент.

Для .NET-разработчиков, управляющих несколькими feature-ветками или исправляющих баги, пока длительная задача скаффолдинга выполняется, это кардинально меняет ситуацию. Можно поручить агенту создавать API-контроллеры в одном worktree, пока вы отлаживаете проблему в сервисном слое в другом. Никаких конфликтов. Никакого стеширования. Никакого хаоса.

Субагенты и команды агентов

Agent Host Protocol теперь поддерживает субагентов. Агент может запускать других агентов для обработки частей задачи. Считайте это делегированием — ваш главный агент координирует, а специализированные агенты занимаются отдельными частями.

Это пока на ранней стадии, но потенциал для .NET-рабочих процессов очевиден. Представьте: один агент обрабатывает ваши миграции EF Core, пока другой настраивает интеграционные тесты. Мы ещё не совсем там, но поддержка протокола появляется сейчас — значит, инструменты подтянутся быстро.

Вывод терминала автоматически включается, когда агенты отправляют ввод

Мелочь, но значимая. Когда агент отправляет ввод в терминал, вывод терминала теперь автоматически включается в контекст. Раньше агенту требовался дополнительный ход, чтобы просто прочитать, что произошло.

Если вы когда-нибудь наблюдали, как агент запускает dotnet build, терпит неудачу, а потом делает ещё один round-trip, чтобы увидеть ошибку — это трение исчезло. Он видит вывод мгновенно и реагирует.

Приложение Agents на macOS обновляется автоматически

Автономное приложение Agents на macOS теперь обновляется самостоятельно. Больше не нужно вручную скачивать новые версии. Оно просто остаётся актуальным.

Мелочи, которые стоит знать

Подсказки package.json теперь показывают и установленную версию, и последнюю доступную. Полезно, если вы управляете npm-инструментами наряду с .NET-проектами.
Изображения в комментариях JSDoc корректно отображаются в подсказках и автодополнении.
Сессии Copilot CLI теперь показывают, были ли они созданы в VS Code или извне — удобно, когда переключаетесь между терминалами.
Copilot CLI, Claude Code и Gemini CLI распознаются как типы оболочек. Редактор знает, что вы запускаете.

Итог

VS Code 1.117 — это не броский набор фич. Это инфраструктура. Изоляция worktree, постоянные разрешения, протоколы субагентов — это строительные блоки для рабочего процесса, в котором агенты выполняют реальные параллельные задачи, не затрагивая ваш код.

Если вы разрабатываете на .NET и ещё не погрузились в агентный рабочий процесс, честно говоря, сейчас самое время начать.

Где размещать AI-агентов в Azure? Практическое руководство по выбору

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинальная версия доступна здесь.

Если вы сейчас создаёте AI-агентов с .NET, вы наверняка заметили: способов разместить их в Azure очень много. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — и все звучат разумно, пока вам не нужно действительно выбрать один. Microsoft только что опубликовала полное руководство по размещению AI-агентов в Azure, и я хочу разобрать его с практической точки зрения .NET-разработчика.

Шесть вариантов с первого взгляда

Вариант	Лучше всего для	Вы управляете
Container Apps	Полный контроль контейнеров без сложности K8s	Наблюдаемость, состояние, жизненный цикл
AKS	Корпоративный комплаенс, мультикластер, пользовательские сети	Всем (в этом и суть)
Azure Functions	Событийные краткосрочные задачи агентов	Почти ничем — настоящий serverless
App Service	Простые HTTP-агенты, предсказуемый трафик	Развёртывание, настройка масштабирования
Foundry Agents	Агенты без кода через портал/SDK	Почти ничем
Foundry Hosted Agents	Агенты с пользовательским фреймворком на управляемой инфраструктуре	Только ваш код агента

Первые четыре — это вычисления общего назначения: вы можете запускать на них агентов, но они не были для этого спроектированы. Последние два — нативные для агентов: они понимают разговоры, вызовы инструментов и жизненные циклы агентов как первоклассные концепции.

Foundry Hosted Agents — оптимальный выбор для .NET-разработчиков агентов

Вот что привлекло моё внимание. Foundry Hosted Agents находятся точно посередине: вы получаете гибкость запуска собственного кода (Semantic Kernel, Agent Framework, LangGraph — что угодно), а платформа управляет инфраструктурой, наблюдаемостью и управлением разговорами.

Ключевой элемент — Hosting Adapter — тонкий слой абстракции, который соединяет ваш фреймворк агентов с платформой Foundry. Для Microsoft Agent Framework это выглядит так:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Это вся ваша история хостинга. Адаптер обрабатывает трансляцию протоколов, стриминг через server-sent events, историю разговоров и трассировку OpenTelemetry — всё автоматически. Никакого пользовательского middleware, никакой ручной прокладки.

Развёртывание действительно простое

Я раньше развёртывал агентов в Container Apps, и это работает, но в итоге вы пишете много связующего кода для управления состоянием и наблюдаемости. С Hosted Agents и azd развёртывание — это:

# Установить расширение AI-агента
azd ext install azure.ai.agents

# Инициализировать из шаблона
azd ai agent init

# Собрать, отправить, развернуть — готово
azd up

Эта единственная команда azd up собирает ваш контейнер, отправляет его в ACR, создаёт проект Foundry, развёртывает endpoints моделей и запускает вашего агента. Пять шагов сжаты в одну команду.

Встроенное управление разговорами

Это та часть, которая экономит больше всего времени в продакшене. Вместо создания собственного хранилища состояния разговоров, Hosted Agents обрабатывают это нативно:

# Создать постоянный разговор
conversation = openai_client.conversations.create()

# Первый ход
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Второй ход — контекст сохранён
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Никакого Redis. Никакого хранилища сессий Cosmos DB. Никакого middleware для сериализации сообщений. Платформа просто справляется.

Мой фреймворк принятия решений

Пройдя все шесть вариантов, вот моя быстрая ментальная модель:

Нужен нулевой уровень инфраструктуры? → Foundry Agents (портал/SDK, без контейнеров)
Есть пользовательский код агента, но нужен управляемый хостинг? → Foundry Hosted Agents
Нужны событийные краткосрочные задачи агентов? → Azure Functions
Нужен максимальный контроль контейнеров без K8s? → Container Apps
Нужен строгий комплаенс и мультикластер? → AKS
Простой HTTP-агент с предсказуемым трафиком? → App Service

Для большинства .NET-разработчиков, работающих с Semantic Kernel или Microsoft Agent Framework, Hosted Agents — вероятно правильная отправная точка. Вы получаете scale-to-zero, встроенный OpenTelemetry, управление разговорами и гибкость фреймворка — без управления Kubernetes или создания собственного стека наблюдаемости.

Подводя итог

Ландшафт хостинга агентов в Azure быстро зреет. Если вы начинаете новый проект AI-агента сегодня, я бы серьёзно рассмотрел Foundry Hosted Agents, прежде чем по привычке тянуться к Container Apps или AKS. Управляемая инфраструктура экономит реальное время, а паттерн hosting adapter позволяет сохранить ваш выбор фреймворка.

Ознакомьтесь с полным руководством Microsoft и репозиторием Foundry Samples для рабочих примеров.

Azure MCP Server 2.0 выпущен — Self-Hosted Agentic Cloud Automation здесь

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

Эта статья была переведена автоматически. Оригинал доступен здесь.

Если вы в последнее время создавали что-то с MCP и Azure, вы наверняка уже знаете, что локальный опыт работает хорошо. Подключите MCP сервер, позвольте вашему AI агенту общаться с ресурсами Azure, и двигайтесь дальше. Но в момент, когда нужно поделиться этой настройкой с командой? Вот тогда всё становится сложным.

Больше не нужно. Azure MCP Server только что достиг стабильности версии 2.0, и главная фишка — это ровно то, о чём просили enterprise команды: поддержка self-hosted удалённых MCP серверов.

Что такое Azure MCP Server?

Быстрое напоминание. Azure MCP Server реализует спецификацию Model Context Protocol и раскрывает возможности Azure в виде структурированных, обнаруживаемых инструментов, которые AI агенты могут вызывать. Думайте об этом как о стандартизированном мосте между вашим агентом и Azure — provisioning, развёртывание, мониторинг, диагностика, всё через один консистентный интерфейс.

Цифры говорят сами за себя: 276 MCP инструментов в 57 сервисах Azure. Это серьёзное покрытие.

Главное: self-hosted удалённые развёртывания

Вот в чём дело. Запуск MCP локально на вашей машине — это нормально для разработки и экспериментов. Но в реальном сценарии с командой вам нужно:

Общий доступ для разработчиков и внутренних систем агентов
Централизованная конфигурация (контекст тенанта, умолчания подписки, телеметрия)
Enterprise границы сети и политики
Интеграция в CI/CD pipelines

Azure MCP Server 2.0 решает все эти проблемы. Вы можете развернуть его как централизованно управляемый внутренний сервис с HTTP-транспортом, правильной аутентификацией и консистентным управлением.

Для аутентификации у вас есть два хороших варианта:

Managed Identity — при работе рядом с Microsoft Foundry
On-Behalf-Of (OBO) flow — OpenID Connect делегирование, которое вызывает Azure API, используя контекст вошедшего пользователя

Этот OBO flow особенно интересен для нас, .NET разработчиков. Это означает, что ваши agentic workflows могут работать с реальными разрешениями пользователя, а не с какой-то чрезмерно привилегированной сервисной учётной записью. Принцип наименьших привилегий, встроенный прямо туда.

Усиление безопасности

Это не просто выпуск фич — это ещё и выпуск безопасности. Релиз 2.0 добавляет:

Более сильную валидацию endpoints
Защиту от injection паттернов в инструментах, ориентированных на запросы
Более жёсткие элементы управления изоляцией для окружений разработки

Если вы собираетесь раскрывать MCP как общий сервис, эти меры защиты имеют большое значение. Большое.

Где вы можете его использовать?

История совместимости клиентов широкая. Azure MCP Server 2.0 работает с:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI agents: GitHub Copilot CLI, Claude Code
Standalone: локальный сервер для простых настроек
Self-hosted remote: новая звезда версии 2.0

Плюс есть поддержка sovereign cloud для Azure US Government и Azure, управляемого 21Vianet, что критично для регулируемых развёртываний.

Почему это важно для .NET разработчиков

Если вы создаёте agentic приложения с .NET — будь то Semantic Kernel, Microsoft Agent Framework или ваша собственная оркестровка — Azure MCP Server 2.0 даёт вам production-ready способ дать вашим агентам взаимодействовать с инфраструктурой Azure. Нет пользовательских REST обёрток. Нет сервис-специфичных паттернов интеграции. Просто MCP.

Вместе с fluent API для MCP Apps, который вышел несколько дней назад, экосистема .NET MCP быстро растёт.

Начало работы

Выберите свой путь:

GitHub Repo — исходный код, документация, всё
Docker Image — контейнеризованное развёртывание
VS Code Extension — интеграция IDE
Self-hosting guide — главная фишка версии 2.0

В итоге

Azure MCP Server 2.0 — это ровно тот вид upgrade инфраструктуры, который не выглядит ослепительно на демо, но всё изменяет на практике. Self-hosted удалённый MCP с правильной аутентификацией, усилением безопасности и поддержкой sovereign cloud означает, что MCP готов для реальных команд, создающих реальные agentic workflows на Azure. Если вы ждали сигнала “enterprise-ready” — вот он.

Microsoft Foundry Март 2026 — GPT-5.4, Agent Service GA и Обновление SDK, Которое Меняет Всё

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Ежемесячные посты «Что нового в Microsoft Foundry» обычно представляют собой сочетание инкрементальных улучшений и редких ключевых функций. Мартовский выпуск 2026 года? Практически сплошные ключевые функции. Foundry Agent Service выходит в GA, GPT-5.4 выпускается для продакшена, SDK получает крупный стабильный релиз, а Fireworks AI приносит инференс открытых моделей в Azure. Давайте разберём, что важно для .NET-разработчиков.

Foundry Agent Service готов к продакшену

Это главная новость. Среда выполнения агентов нового поколения вышла в общую доступность — построена на OpenAI Responses API, совместима на уровне протокола с агентами OpenAI и открыта для моделей от различных поставщиков. Если вы сегодня строите на Responses API, миграция на Foundry добавит корпоративную безопасность, приватную сеть, Entra RBAC, полную трассировку и оценку поверх вашей существующей агентной логики.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Ключевые дополнения: сквозная приватная сеть, расширение MCP-аутентификации (включая OAuth passthrough), предварительный просмотр Voice Live для голосовых агентов и размещённые агенты в 6 новых регионах.

GPT-5.4 — надёжность важнее чистого интеллекта

GPT-5.4 — это не про то, чтобы стать умнее. Это про надёжность. Более сильное рассуждение в длинных взаимодействиях, лучшее следование инструкциям, меньше сбоев в середине рабочего процесса и встроенные возможности использования компьютера. Для продакшен-агентов эта надёжность значит гораздо больше, чем результаты бенчмарков.

Модель	Цена (за М токенов)	Лучше всего для
GPT-5.4 (≤272K)	$2.50 / $15 вывод	Продакшен-агенты, кодирование, документооборот
GPT-5.4 Pro	$30 / $180 вывод	Глубокий анализ, научное рассуждение
GPT-5.4 Mini	Экономичный	Классификация, извлечение, лёгкие вызовы инструментов

Умная стратегия — маршрутизация: GPT-5.4 Mini обрабатывает высоконагруженную работу с низкой задержкой, а GPT-5.4 берёт на себя запросы с интенсивным рассуждением.

SDK наконец стабилен

SDK azure-ai-projects выпустил стабильные релизы на всех языках — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0 и .NET 2.0.0 (1 апреля). Зависимость от azure-ai-agents исчезла — всё живёт под AIProjectClient. Установите через pip install azure-ai-projects, пакет включает openai и azure-identity как прямые зависимости.

Для .NET-разработчиков это означает единый NuGet-пакет для всей поверхности Foundry. Больше никакого жонглирования отдельными SDK для агентов.

Fireworks AI приносит открытые модели в Azure

Пожалуй, самое архитектурно интересное дополнение: Fireworks AI обрабатывает более 13 триллионов токенов в день при ~180K запросов/секунду, теперь доступен через Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5 и MiniMax M2.5 при запуске.

Настоящая история — это bring-your-own-weights — загружайте квантованные или дообученные веса откуда угодно без смены стека обслуживания. Развёртывание через бессерверную модель с оплатой за токен или выделенную пропускную способность.

Другие важные моменты

Phi-4 Reasoning Vision 15B — мультимодальное рассуждение для графиков, диаграмм и макетов документов
Evaluations GA — готовые оценщики с непрерывным мониторингом продакшена через Azure Monitor
Priority Processing (Preview) — выделенная вычислительная линия для нагрузок, чувствительных к задержке
Voice Live — среда выполнения «голос-к-голосу», подключаемая напрямую к агентам Foundry
Tracing GA — сквозная инспекция трассировок агентов с сортировкой и фильтрацией
Устаревание PromptFlow — миграция на Microsoft Framework Workflows к январю 2027

Заключение

Март 2026 — это поворотный момент для Foundry. Agent Service GA, стабильные SDK на всех языках, GPT-5.4 для надёжных продакшен-агентов и инференс открытых моделей через Fireworks AI — платформа готова к серьёзным нагрузкам.

Прочитайте полный обзор и создайте своего первого агента, чтобы начать.

VS Code 1.116 — Приложение Agents Получает Навигацию с Клавиатуры и Автодополнение Контекста Файлов

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

VS Code 1.116 — это апрельский релиз 2026 года, и хотя он легче некоторых недавних обновлений, изменения целенаправленны и значимы — особенно если вы ежедневно используете приложение Agents.

Вот что появилось, на основе официальных заметок о релизе.

Улучшения приложения Agents

Приложение Agents продолжает развиваться с доработками юзабилити, которые реально влияют на повседневные рабочие процессы:

Выделенные горячие клавиши — теперь можно переключать фокус на представление Changes, дерево файлов внутри Changes и представление настроек чата с помощью выделенных команд и горячих клавиш. Если вы раньше кликали по приложению Agents для навигации, теперь доступен полностью клавиатурный рабочий процесс.

Диалог помощи по доступности — нажатие Alt+F1 в поле ввода чата теперь открывает диалог помощи по доступности, показывающий доступные команды и горячие клавиши. Пользователи экранных читалок также могут контролировать подробность объявлений. Хорошая доступность полезна для всех.

Автодополнение контекста файлов — введите # в чате приложения Agents, чтобы вызвать автодополнение контекста файлов в рамках текущего рабочего пространства. Это одно из тех маленьких улучшений качества жизни, которые ускоряют каждое взаимодействие — больше не нужно вводить полные пути к файлам при обращении к коду.

Разрешение ссылок CSS `@import`

Приятно для фронтенд-разработчиков: VS Code теперь разрешает CSS @import-ссылки, использующие пути node_modules. Вы можете переходить через Ctrl+клик по импортам вроде @import "some-module/style.css" при использовании бандлеров. Мелочь, но убирает точку трения в CSS-рабочих процессах.

Заключение

VS Code 1.116 — это про совершенствование: сделать приложение Agents более удобным для навигации, более доступным и более дружелюбным к клавиатуре. Если вы проводите значительное время в приложении Agents (а я подозреваю, что многие из нас так и делают), эти изменения накапливаются.

Ознакомьтесь с полными заметками о релизе для полного списка.

Агентная платформенная инженерия становится реальностью — Git-APE показывает как

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Платформенная инженерия была одним из тех терминов, которые звучат отлично на конференциях, но обычно означают «мы построили внутренний портал и обёртку для Terraform.» Настоящее обещание — самообслуживающаяся инфраструктура, которая действительно безопасна, управляема и быстра — всегда была в нескольких шагах.

Команда Azure только что опубликовала Часть 2 серии об агентной платформенной инженерии, и эта часть целиком о практической реализации. Они называют это Git-APE (да, акроним намеренный), и это open-source проект, который использует агенты GitHub Copilot плюс серверы Azure MCP для превращения запросов на естественном языке в валидированную и развёрнутую инфраструктуру.

Что Git-APE делает на самом деле

Основная идея: вместо того чтобы разработчики изучали модули Terraform, навигировали по UI порталов или создавали тикеты для платформенной команды, они разговаривают с агентом Copilot. Агент интерпретирует намерение, генерирует Infrastructure-as-Code, валидирует его по политикам и разворачивает — всё внутри VS Code.

Вот настройка:

git clone https://github.com/Azure/git-ape
cd git-ape

Откройте workspace в VS Code, и файлы конфигурации агента автоматически обнаруживаются GitHub Copilot. Вы взаимодействуете с агентом напрямую:

@git-ape deploy a function app with storage in West Europe

Агент использует Azure MCP Server под капотом для взаимодействия с сервисами Azure. Конфигурация MCP в настройках VS Code активирует конкретные возможности:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Почему это важно

Для тех из нас, кто строит на Azure, это смещает разговор о платформенной инженерии с «как построить портал» на «как описать наши ограничения как API.» Когда интерфейс вашей платформы — это ИИ-агент, качество ваших ограничений и политик становится продуктом.

Блог Части 1 изложил теорию: хорошо описанные API, схемы контроля и явные ограничения делают платформы agent-ready. Часть 2 доказывает, что это работает, поставляя реальные инструменты. Агент не генерирует ресурсы вслепую — он валидирует по лучшим практикам, соблюдает соглашения об именовании и применяет политики вашей организации.

Очистка так же проста:

@git-ape destroy my-resource-group

Моё мнение

Буду честен — здесь больше о паттерне, чем о конкретном инструменте. Git-APE сам по себе — это демо/референсная архитектура. Но лежащая в основе идея — агенты как интерфейс к вашей платформе, MCP как протокол, GitHub Copilot как хост — вот куда движется experience корпоративного разработчика.

Если вы — платформенная команда, которая ищет, как сделать внутренние инструменты agent-friendly, лучшего стартового пункта не найти. А если вы .NET-разработчик и думаете, как это связано с вашим миром: Azure MCP Server и агенты GitHub Copilot работают с любыми нагрузками Azure. Ваш ASP.NET Core API, ваш стек .NET Aspire, ваши контейнеризированные микросервисы — всё это может быть целью агентного потока деплоя.

Подведём итоги

Git-APE — это ранний, но конкретный взгляд на агентную платформенную инженерию на практике. Клонируйте репозиторий, попробуйте демо и начните думать о том, как API и политики вашей платформы должны выглядеть, чтобы агент мог безопасно их использовать.

Читайте полный пост для walkthrough и видео-демонстраций.

azd теперь позволяет запускать и отлаживать ИИ-агенты локально — Что изменилось в марте 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинальную версию можно найти здесь.

Семь релизов за месяц. Именно столько выпустила команда Azure Developer CLI (azd) в марте 2026, и главная фича — та, которую я ждал: локальный цикл запуска и отладки для ИИ-агентов.

PC Chan опубликовала полный обзор, и хотя там много всего, позвольте мне отфильтровать то, что действительно важно для .NET-разработчиков, создающих приложения с ИИ.

Запуск и отладка ИИ-агентов без деплоя

Это главное. Новое расширение azure.ai.agents добавляет команды для полноценного inner-loop для ИИ-агентов:

azd ai agent run — запускает агент локально
azd ai agent invoke — отправляет сообщения (локально или в продакшн)
azd ai agent show — показывает статус контейнера и здоровье
azd ai agent monitor — стримит логи контейнера в реальном времени

Раньше тестирование ИИ-агента означало деплой в Microsoft Foundry при каждом изменении. Теперь можно итерировать локально, тестировать поведение агента и деплоить только когда готов.

GitHub Copilot настраивает ваш azd-проект

azd init теперь предлагает опцию “Set up with GitHub Copilot (Preview)”. Вместо ручного ответа на промпты, Copilot-агент генерирует конфигурацию за вас. Когда команда падает, azd предлагает ИИ-ассистированное устранение неполадок — всё не выходя из терминала.

Container App Jobs и улучшения деплоя

Container App Jobs: azd теперь деплоит Microsoft.App/jobs через существующую конфигурацию host: containerapp.
Настраиваемые таймауты деплоя: Новый флаг --timeout в azd deploy и поле deployTimeout в azure.yaml.
Фолбэк удалённой сборки: При неудаче ACR-сборки azd автоматически переключается на локальный Docker/Podman.
Локальная preflight-валидация: Bicep-параметры проверяются локально перед деплоем.

Улучшения DX

Автоматическое определение pnpm/yarn для JS/TS-проектов
Поддержка pyproject.toml для Python
Локальные каталоги шаблонов — azd init --template принимает пути файловой системы
Улучшенные сообщения об ошибках в режиме --no-prompt
Переменные окружения сборки — инжектируются во все подпроцессы сборки (.NET, Node.js, Java, Python)

Подведём итоги

Локальный цикл отладки ИИ-агентов — звезда этого релиза, но совокупность улучшений деплоя и DX делает azd более зрелым, чем когда-либо. Если вы деплоите .NET-приложения в Azure — особенно ИИ-агенты — это обновление стоит внимания.

Ознакомьтесь с полными заметками о выпуске.

Foundry Agent Service вышел в GA: что действительно важно для .NET-разработчиков агентов

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Будем честны — создать прототип ИИ-агента — это простая часть. Сложная часть — всё, что идёт после: вывести его в продакшен с правильной сетевой изоляцией, запустить оценки, которые действительно что-то значат, обеспечить соответствие требованиям и не сломать ничего в 2 часа ночи.

Foundry Agent Service только что вышел в GA, и этот релиз сфокусирован именно на этом разрыве «всё, что после».

Построен на Responses API

Вот главная новость: Foundry Agent Service нового поколения построен на OpenAI Responses API. Если вы уже работаете с этим wire-протоколом, миграция на Foundry — это минимальные изменения кода. Что вы получаете: корпоративную безопасность, приватную сеть, Entra RBAC, полную трассировку и оценку — поверх вашей существующей логики агента.

Архитектура намеренно открыта. Вы не привязаны к одному провайдеру моделей или одному фреймворку оркестрации. Используйте DeepSeek для планирования, OpenAI для генерации, LangGraph для оркестрации — рантайм обеспечивает слой согласованности.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Если вы переходите с пакета azure-ai-agents, агенты теперь являются операциями первого класса на AIProjectClient в azure-ai-projects. Удалите отдельную зависимость и используйте get_openai_client() для работы с ответами.

Приватная сеть: корпоративный блокер устранён

Это функция, которая разблокирует корпоративное внедрение. Foundry теперь поддерживает полную сквозную приватную сеть с BYO VNet:

Нет публичного исходящего трафика — трафик агента никогда не проходит через публичный интернет
Внедрение контейнеров/подсетей в вашу сеть для локальной коммуникации
Подключение инструментов включено — MCP-серверы, Azure AI Search, агенты данных Fabric — всё работает через приватные пути

Последний пункт критичен. Приватными остаются не только вызовы для вывода — каждый вызов инструмента и поисковый запрос тоже остаётся внутри границы вашей сети. Для команд, работающих под политиками классификации данных, запрещающими внешнюю маршрутизацию, это то, чего не хватало.

Аутентификация MCP сделана правильно

Подключения к MCP-серверам теперь поддерживают полный спектр паттернов аутентификации:

Метод аутентификации	Когда использовать
На основе ключей	Простой общий доступ для внутренних инструментов организации
Entra Agent Identity	Сервис-к-сервису; агент аутентифицируется от своего имени
Entra Managed Identity	Изоляция на уровне проекта; без управления учётными данными
OAuth Identity Passthrough	Делегированный доступ пользователя; агент действует от имени пользователей

OAuth Identity Passthrough — самый интересный. Когда пользователям нужно предоставить агенту доступ к своим личным данным — их OneDrive, их организации Salesforce, SaaS API с пользовательской областью — агент действует от их имени через стандартные OAuth-потоки. Никакой общей системной идентификации, притворяющейся всеми.

Voice Live: речь-в-речь без сантехнических работ

Добавление голоса к агенту раньше означало объединение STT, LLM и TTS — три сервиса, три задержки, три поверхности биллинга, всё синхронизировано вручную. Voice Live сворачивает это в единый управляемый API с:

Семантическое определение голосовой активности и конца реплики (понимает смысл, а не просто тишину)
Серверное подавление шума и эхо-компенсация
Поддержка прерывания (пользователи могут прервать ответ)

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

Оценки: от галочки к непрерывному мониторингу

Здесь Foundry серьёзно подходит к качеству продакшена. Система оценки теперь имеет три уровня:

Готовые оценщики — связность, релевантность, обоснованность, качество поиска, безопасность. Подключите к датасету или живому трафику и получите оценки обратно.
Пользовательские оценщики — закодируйте свою бизнес-логику, стандарты тона и специфичные для домена правила соответствия.
Непрерывная оценка — Foundry сэмплирует живой продакшен-трафик, запускает набор оценщиков и отображает результаты через дашборды. Настройте алерты Azure Monitor на случай падения обоснованности или нарушения порогов безопасности.

Всё публикуется в Azure Monitor Application Insights. Качество агента, здоровье инфраструктуры, затраты и телеметрия приложения — всё в одном месте.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Шесть новых регионов для размещённых агентов

Размещённые агенты теперь доступны в East US, North Central US, Sweden Central, Southeast Asia, Japan East и других регионах. Это важно для требований к размещению данных и для снижения задержки, когда ваш агент работает рядом с источниками данных.

Почему это важно для .NET-разработчиков

Хотя примеры кода в анонсе GA написаны на Python, базовая инфраструктура не зависит от языка — и .NET SDK для azure-ai-projects следует тем же паттернам. Responses API, фреймворк оценки, приватная сеть, аутентификация MCP — всё это доступно из .NET.

Если вы ждали, пока ИИ-агенты перейдут от «классной демо» к «я реально могу отправить это на работе», этот GA-релиз — тот самый сигнал. Приватная сеть, правильная аутентификация, непрерывная оценка и продакшен-мониторинг — это были недостающие элементы.

Итог

Foundry Agent Service доступен сейчас. Установите SDK, откройте портал и начинайте строить. Руководство по быстрому старту проведёт вас от нуля до работающего агента за минуты.

Для полного технического погружения со всеми примерами кода ознакомьтесь с анонсом GA.

Agents | The .NET Blog

NL2SQL — это SQL-инъекция агентной эпохи

Проблемы, о которых никто не говорит на демо

Что на самом деле решает SQL MCP Server

Правильный вопрос

У Вашего ИИ-Агента Проблема с Идентификацией (И Вот Шаблон, Который Её Решает)

Основная Проблема: Аутентификация ≠ Авторизация

Как Работает Цепочка Токенов

Что Развёртывает Шаблон

Принцип Дизайна, Достойный Заимствования

Заключение

CodeAct в Agent Framework: Как сократить задержку агента вдвое

Что такое CodeAct?

Безопасность: Микро-VM Hyperlight

Минимальная настройка

Когда использовать CodeAct (и когда не стоит)

Попробуйте сейчас

Где Ваш Агент Помнит Вещи? Практическое Руководство по Хранению Истории Чата

Два основных паттерна

Как Agent Framework это абстрагирует

Быстрый справочник по поставщикам

Как выбрать

Foundry Toolboxes: Единый эндпоинт для всех инструментов агентов

Что такое Toolbox?

Четыре столпа (два доступны сегодня)

Практический пример

Нет привязки к Foundry Agents

Почему это важно сейчас

Итог

VS Code 1.117: Агенты получают собственные ветки Git, и я полностью за

Режим Autopilot наконец запоминает ваши настройки

Worktree и git-изоляция для сессий агентов

Субагенты и команды агентов

Вывод терминала автоматически включается, когда агенты отправляют ввод

Приложение Agents на macOS обновляется автоматически

Мелочи, которые стоит знать

Итог

Где размещать AI-агентов в Azure? Практическое руководство по выбору

Шесть вариантов с первого взгляда

Foundry Hosted Agents — оптимальный выбор для .NET-разработчиков агентов

Развёртывание действительно простое

Встроенное управление разговорами

Мой фреймворк принятия решений

Подводя итог

Azure MCP Server 2.0 выпущен — Self-Hosted Agentic Cloud Automation здесь

Что такое Azure MCP Server?

Главное: self-hosted удалённые развёртывания

Усиление безопасности

Где вы можете его использовать?

Почему это важно для .NET разработчиков

Начало работы

В итоге

Microsoft Foundry Март 2026 — GPT-5.4, Agent Service GA и Обновление SDK, Которое Меняет Всё

Foundry Agent Service готов к продакшену

GPT-5.4 — надёжность важнее чистого интеллекта

SDK наконец стабилен

Fireworks AI приносит открытые модели в Azure

Другие важные моменты

Заключение

VS Code 1.116 — Приложение Agents Получает Навигацию с Клавиатуры и Автодополнение Контекста Файлов

Улучшения приложения Agents

Разрешение ссылок CSS @import

Заключение

Агентная платформенная инженерия становится реальностью — Git-APE показывает как

Что Git-APE делает на самом деле

Почему это важно

Моё мнение

Подведём итоги

azd теперь позволяет запускать и отлаживать ИИ-агенты локально — Что изменилось в марте 2026

Запуск и отладка ИИ-агентов без деплоя

GitHub Copilot настраивает ваш azd-проект

Container App Jobs и улучшения деплоя

Улучшения DX

Подведём итоги

Foundry Agent Service вышел в GA: что действительно важно для .NET-разработчиков агентов

Построен на Responses API

Приватная сеть: корпоративный блокер устранён

Аутентификация MCP сделана правильно

Voice Live: речь-в-речь без сантехнических работ

Оценки: от галочки к непрерывному мониторингу

Разрешение ссылок CSS `@import`