单点能力再强,没有编排、治理和弹性伸缩的底座,AI 也只是实验室里的 demo。微软正在把 Azure 打造成一个覆盖全栈的开放 Agent 平台——多模型接入、每一层可替换、每一环可观测。这才是真正能把 AI 变成业务生产力的东西。
模型 ≠ 系统:为什么"只选一个大模型"走不远
很多团队的第一步是选模型:GPT-4o、Claude、Gemini,然后围绕它写 prompt、做微调。这在原型阶段没问题,但一旦进入生产,问题立刻冒出来:
- 单模型锁定——价格变动、服务中断、能力边界,你全受制于一家。
- 缺乏编排——一个 Agent 调另一个 Agent、接入外部工具、维护对话状态,全靠手写胶水代码。
- 没有治理——谁调了什么、花了多少 token、输出是否合规,一概不清。
微软在这篇文章里把立场说得很明确:他们要建的是一个 comprehensive agent platform——支持多模型、开放架构、每一层都给灵活性。换句话说,模型只是棋子,平台才是棋盘。
全栈灵活性:每一层都可以换
所谓"every layer of the stack"的灵活性,大致拆成这几层:
| 层级 | 锁定风险 | 平台化做法 |
|---|---|---|
| 模型层 | 只用一家 API | 多模型路由,按任务选最优模型 |
| 编排层 | 手写 if-else 调用链 | Agent 框架自动规划、执行、纠错 |
| 工具层 | 硬编码 API 调用 | 工具注册中心,Agent 动态发现与调用 |
| 存储层 | 对话历史散落各处 | 统一线程与状态管理 |
| 治理层 | 无审计无限流 | 日志、计费、内容安全策略集中管控 |
微软的 Azure AI Agent Service + Semantic Kernel 就是这套棋盘的具体实现。下面用代码说话。
实操:用 Semantic Kernel 编排多模型 Agent
Semantic Kernel 是微软开源的 SDK(Python / C# / Java),核心思路是:把模型、工具、记忆都注册进 Kernel,然后让 Planner 自动编排执行流程。这比手写调用链要可靠得多,也天然支持多模型切换。
下面是一个可运行的 Python 示例——同一个 Kernel 里挂两个不同模型,让 Planner 自己决定怎么调用工具完成任务:
# semantic_kernel_multi_agent.py
# 依赖:pip install semantic-kernel azure-identity
import asyncio
from semantic_kernel import Kernel
from semantic_kernel.connectors.ai.open_ai import (
AzureChatCompletion,
OpenAIChatCompletion,
)
from semantic_kernel.core_plugins import TextPlugin
from semantic_kernel.functions import kernel_function
from semantic_kernel.planners.basic_planner import BasicPlanner
# ---- 自定义业务工具插件 ----
class OrderPlugin:
"""模拟订单查询与创建"""
@kernel_function(name="query_order", description="根据订单号查询订单状态")
def query_order(self, order_id: str) -> str:
# 实际场景对接 ERP / 数据库
return f"订单 {order_id} 状态:已发货,预计明天送达"
@kernel_function(name="create_order", description="为指定商品创建新订单")
def create_order(self, product: str, quantity: int) -> str:
return f"已创建订单:{product} × {quantity},订单号 ORD-20250701-001"
# ---- 构建 Kernel,注册多模型 + 工具 ----
kernel = Kernel()
# 模型 1:Azure OpenAI GPT-4o(主模型,负责规划与对话)
kernel.add_service(
AzureChatCompletion(
service_id="gpt4o",
deployment_name="gpt-4o", # ← 替换为你的 deployment 名
endpoint="https://YOUR_RESOURCE.openai.azure.com", # ← 替换
api_version="2024-06-01",
)
)
# 模型 2:Azure OpenAI GPT-4o-mini(轻量模型,执行简单子任务)
kernel.add_service(
AzureChatCompletion(
service_id="gpt4o-mini",
deployment_name="gpt-4o-mini", # ← 替换
endpoint="https://YOUR_RESOURCE.openai.azure.com", # ← 替换
api_version="2024-06-01",
)
)
# 注册工具插件
kernel.add_plugin(OrderPlugin(), plugin_name="order")
kernel.add_plugin(TextPlugin(), plugin_name="text")
# ---- Planner 自动编排 ----
async def run_agent(goal: str):
planner = BasicPlanner()
plan = await planner.create_plan(goal, kernel)
print("=== 生成的执行计划 ===")
print(plan.description)
result = await planner.execute_plan(plan, kernel)
print("\n=== 最终结果 ===")
print(result)
# ---- 运行 ----
if __name__ == "__main__":
# 用户自然语言输入 → Planner 拆解为工具调用序列
asyncio.run(
run_agent("帮我查一下订单 ORD-8842 的状态,然后给客户发一条简短通知")
)
运行前需要改什么:
- 把
YOUR_RESOURCE替换成你的 Azure OpenAI 资源名。 - 确保 deployment 名
gpt-4o/gpt-4o-mini在你的 Azure 资源里已创建。 - 环境变量设置
AZURE_CLIENT_ID、AZURE_CLIENT_SECRET、AZURE_TENANT_ID(用 Azure CLI 登录也可以)。
这段代码演示了什么:
- 多模型共存:同一个 Kernel 注册两个模型,Planner 可以按任务复杂度路由到不同模型。
- 工具自动发现:
OrderPlugin的方法用@kernel_function声明,Planner 读取 description 后自动编排调用顺序。 - 执行计划可观测:
plan.description打印出 Planner 生成的步骤链,你能看到它怎么拆解"查订单 → 发通知"。
进阶:Azure AI Agent Service 的声明式配置
如果你不想写编排代码,Azure AI Agent Service 提供了更上层的方式——用 REST API 或 SDK 声明式创建 Agent,自动获得线程管理、工具绑定、内容安全过滤:
# azure_agent_service.py
# 依赖:pip install azure-ai-projects azure-identity
import asyncio
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import Agent, AgentTool
from azure.identity import DefaultAzureCredential
async def create_customer_service_agent():
# AIProjectClient 自动连接到你的 Azure AI Foundry 项目
# 环境变量需设置 AZURE_AI_PROJECT_ENDPOINT
client = AIProjectClient(
endpoint="https://YOUR_AI_PROJECT.services.ai.azure.com/api", # ← 替换
credential=DefaultAzureCredential(),
)
# 声明式创建 Agent:指定模型 + 工具 + 安全策略
agent: Agent = await client.agents.create_agent(
model="gpt-4o", # 可替换为任何已部署模型
name="cs-agent",
instructions=(
"你是客户服务助手。查询订单时调用 order_query 工具,"
"创建订单时调用 order_create 工具。"
"回复必须简洁,不超过 3 句话。"
),
tools=[
AgentTool(
type="function",
function={
"name": "order_query",
"description": "根据订单号查询状态",
"parameters": {
"type": "object",
"properties": {
"order_id": {"type": "string"}
},
"required": ["order_id"],
},
},
),
],
)
print(f"Agent 已创建,ID: {agent.id}")
# 创建对话线程 + 发送消息
thread = await client.agents.create_thread()
await client.agents.create_message(
thread_id=thread.id,
role="user",
content="订单 ORD-8842 到哪了?",
)
# 运行 Agent
run = await client.agents.create_and_process_run(
thread_id=thread.id,
agent_id=agent.id,
)
print(f"Run 状态: {run.status}")
print(f"Agent 回复: {run.last_message.content}")
# 清理(生产环境可保留线程做历史追溯)
await client.agents.delete_agent(agent.id)
if __name__ == "__main__":
asyncio.run(create_customer_service_agent())
关键差异:
- Agent Service 把线程、消息、运行状态全部托管,你不再自己管理对话上下文。
- 工具定义用 JSON Schema 声明,和 OpenAI Assistants API 格式兼容,迁移成本低。
create_and_process_run是同步式调用(内部异步轮询),适合简单场景;复杂场景可以拆成create_run+ 事件流。
落地前想清楚的三件事
-
别只评估模型,评估平台。模型能力半年一迭代,今天最强的半年后可能不是。平台的多模型路由、工具生态、治理能力才是长期资产。
-
从单 Agent 起步,但架构要留多 Agent 的口子。用 Semantic Kernel 或 Agent Service 先跑一个 Agent,但插件和工具注册方式要标准化,这样后续叠加 Agent 间协作时不用重构。
-
治理不是可选的。生产环境必须回答:哪个 Agent 调了什么工具、花了多少 token、输出是否经过安全过滤。Azure AI Foundry 的日志和内容安全策略是现成的,别自己造。
模型是引擎,平台是整车。只买引擎不上路,业务永远停在原地。