Foundry Toolboxes：AI Agent工具的统一端点

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

本文已自动翻译。如需查看原始版本，请点击此处。

有一个问题听起来无聊，直到你真正遇到它：你的组织在构建多个AI Agent，每个都需要工具，每个团队都从头开始配置。相同的Web搜索集成、相同的Azure AI Search配置、相同的GitHub MCP服务器连接——但在不同的仓库里，由不同的团队，使用不同的凭据，没有任何共享治理。

Microsoft Foundry刚刚以公开预览版发布了Toolboxes，这是对该问题的直接回应。

什么是Toolbox

Toolbox是一个有命名的、可复用的工具包，在Foundry中定义一次，通过单一MCP兼容端点公开。任何能够使用MCP的Agent运行时都可以消费它——不受限于Foundry Agents。

承诺很简单：build once, consume anywhere。定义工具，集中配置身份验证（OAuth直通、Entra托管标识），发布端点。需要这些工具的每个Agent连接到端点即可获取全部工具。

四个支柱（今天两个可用）

支柱	状态	功能
Discover	即将推出	无需手动搜索即可发现已批准的工具
Build	现已可用	将工具整合到可复用包中
Consume	现已可用	单一MCP端点公开所有工具
Govern	即将推出	集中身份验证+所有工具调用的可观测性

实践示例

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的自定义Agent、GitHub Copilot和其他MCP兼容IDE以及任何支持MCP的运行时中使用它们。

为什么现在重要

多Agent浪潮正在进入生产环境。每个新Agent都是重复配置、过期凭据和不一致行为的新风险面。Build + Consume基础足以开始集中化。当Govern支柱推出时，你将拥有对整个Agent群完全可观测、集中控制的工具层。

总结

还是早期阶段——公开预览，Python SDK优先，Discover和Govern仍在路上。但模型是稳固的，MCP原生设计意味着它可以与你已经在构建的工具配合使用。查阅官方公告了解详情。

Azure上のAIエージェントはどこにホストすべき？実践的な判断ガイド

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

本文为自动翻译。查看原文请点击这里。

如果你现在正在用.NET构建AI代理，你可能已经注意到一件事：在Azure上托管它们的方式太多了。Container Apps、AKS、Functions、App Service、Foundry Agents、Foundry Hosted Agents——在你真正需要选择之前，每个都听起来合理。Microsoft刚刚发布了一份Azure AI代理托管综合指南来澄清这个问题，我想从.NET开发者的实践角度来拆解它。

六种选项速览

以下是我对这个版图的总结：

选项	最适合	你需要管理
Container Apps	无需K8s复杂性的完整容器控制	可观测性、状态、生命周期
AKS	企业合规、多集群、自定义网络	所有东西（这就是重点）
Azure Functions	事件驱动的短时代理任务	几乎不需要——真正的无服务器
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追踪。不需要自定义中间件，不需要手动配置。

部署真的很简单

我以前在Container Apps上部署过代理，虽然可以工作，但最后你会写很多胶水代码来处理状态管理和可观测性。使用Hosted Agents和azd，部署是：

# 安装AI代理扩展
azd ext install azure.ai.agents

# 从模板初始化
azd ai agent init

# 构建、推送、部署——完成
azd up

这个单独的azd up会构建你的容器、推送到ACR、配置Foundry项目、部署模型端点并启动你的代理。五个步骤压缩成一个命令。

内置对话管理

这是在生产中节省最多时间的部分。不需要构建自己的对话状态存储，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会话存储。不需要自定义中间件来序列化消息。平台直接处理了。

我的决策框架

在审查了所有六个选项之后，这是我的快速心智模型：

需要零基础设施？ → Foundry Agents（门户/SDK，无容器）
有自定义代理代码但想要托管主机？ → Foundry Hosted Agents
需要事件驱动的短期代理任务？ → Azure Functions
需要不用K8s的最大容器控制？ → Container Apps
需要严格合规和多集群？ → AKS
有流量可预测的简单HTTP代理？ → App Service

对于大多数使用Semantic Kernel或Microsoft Agent Framework构建的.NET开发者来说，Hosted Agents可能是正确的起点。你能获得scale-to-zero、内置OpenTelemetry、对话管理和框架灵活性——无需管理Kubernetes或搭建自己的可观测性栈。

总结

Azure上的代理托管格局正在快速成熟。如果你今天要开始一个新的AI代理项目，我会在习惯性地使用Container Apps或AKS之前认真考虑Foundry Hosted Agents。托管基础设施节省实际时间，而hosting adapter模式让你保留框架选择。

查看Microsoft的完整指南和Foundry Samples仓库获取可运行的示例。

Microsoft-Foundry | The .NET Blog