Claude 托管智能体 + Azure：没有人谈论的多云 AI 战略

在过去一年里，我一直在研究生产级 AI 智能体的构建。多智能体系统、RAG 流水线、一个全天候运行在 Mac mini 上的自主编程智能体……这些项目里最难搞的从来不是 AI 本身，而是基础设施。

沙箱隔离、状态管理、工具执行、容器编排、凭据轮换、错误恢复——在智能体真正能做什么有用的事之前，往往需要好几个月的水管工程。

Anthropic 刚刚把这些问题甩给了别人。

Claude 托管智能体（Claude Managed Agents） 正式进入公测，在亲手构建了几个智能体之后，我可以告诉大家：这不只是又一个 API 封装，这是一套完整的智能体云端运行时——容器、密钥管理、持久内存、自我评估循环、多智能体编排，应有尽有。

但有一个视角目前还没人认真讨论：托管智能体如何嵌入以 Azure 为核心的企业技术栈。

真正被忽视的问题

作为一名帮助企业在 Azure 上构建方案的人，我每天都在思考不同 AI 服务如何协同工作。Azure AI Foundry 提供了 Microsoft 模型的统一编排层——GPT-4o、Phi 以及模型目录里的一切。但当某个工作负载需要 Claude 特有的优势时——深度代码推理、超长上下文分析、精细指令遵循——你就得手动打通两套生态系统。

在此之前，这意味着运行并行基础设施：两条部署流水线、两套监控体系、两套认证系统。这种开销足以让企业默认选择单云方案，即使多云方案技术上更优。

这才是没人讨论的真问题——而托管智能体刚刚解决了其中一半。

Claude 托管智能体究竟是什么

简单说：你定义智能体的行为，Anthropic 在他们的基础设施上运行它。

这意味着：

安全容器 — 每个会话都有独立的沙箱隔离环境
长时运行会话 — 智能体可以持续运行数小时，而不只是单次请求-响应
内置工具执行 — bash、文件读写、网络搜索、网页抓取、grep，全部内置
MCP 服务器连接 — 接入 GitHub、Slack、CRM，或任何你已有的服务
事件流 — 智能体工作时通过 SSE 实时推送更新

无需自己搭 Docker，无需编排框架，无需从零构建工具执行层。

四个核心概念

每个托管智能体都围绕四个概念运作，仅此而已。

1. Agent（智能体）

你的配置。选择哪个模型（claude-sonnet-4-6、claude-opus-4-6）、系统提示词、可使用的工具，以及连接哪些 MCP 服务器。一次创建，处处复用。

2. Environment（环境）

智能体运行的容器。预装 Python 包、Node.js 依赖，按需而定。配置网络规则。每个会话都有独立的容器实例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
  "name": "python-dev",
  "config": {
    "type": "cloud",
    "networking": {"type": "unrestricted"},
    "packages": {
      "pip": ["pandas", "numpy", "pytest", "black"]
    }
  }
}

3. Session（会话）

运行中的智能体实例。它引用你的智能体配置和环境，维护对话历史，并在交互间持久化文件。会话可以运行数小时。

4. Events（事件）

你的应用与智能体之间的消息。你发送用户消息进去，Claude 通过服务器发送事件流式返回响应、工具调用和状态更新。

Agent → Environment → Session → Events，这就是完整的心智模型。

没人写出来的 Azure 集成模式

以下是对以 Azure 为核心的企业来说最合理的架构模式。

Azure AI Foundry 处理微软模型工作负载——文档智能、Azure Cognitive Search 语义检索、Azure OpenAI 文本补全。它是深度嵌入微软生态系统的一切事物的编排层。

Claude 托管智能体处理 Claude 特有推理能力能带来差异化优势的工作负载——复杂多文件代码分析、超长文档综合、多步骤自主研究。

两者的桥梁？Azure API Management（APIM） 和你已有的 Azure 身份基础设施。

用户请求
    ↓
Azure API Management（认证 + 路由 + 限流）
    ↓
┌─────────────────────┬──────────────────────────────┐
│  Azure AI Foundry   │  Claude 托管智能体             │
│  (GPT-4o, Phi,      │  (claude-sonnet-4-6,         │
│   Azure OpenAI)     │   claude-opus-4-6)           │
└─────────────────────┴──────────────────────────────┘
    ↓
Azure Monitor + Application Insights（统一可观测性）

两条路径共享同一套认证（Microsoft Entra ID）、同一套密钥管理（Azure Key Vault）、同一套可观测性体系（Azure Monitor）。你不是在运行并行基础设施——你是在现有 Azure 基础上叠加 Claude 的运行时。

这才是没人写出来的架构细节。 讨论总是停留在"该用 Azure OpenAI 还是 Anthropic？“上。真正该问的问题是：“如何同时使用两者，而不把基础设施复杂度翻倍？“托管智能体让这个问题有了答案。

让这套方案企业级就绪的权限系统

这是托管智能体真正与开源替代品拉开差距的地方。

两种权限模式：

always_allow — 工具自动运行，适合受信任的内部智能体
always_ask — 会话暂停，等待应用审批每次工具调用，适合面向用户的智能体

可以按工具混合设置：

1
2
3
4
5
6
7
8


{
  "tools": [
    {"type": "file_read", "permission": "always_allow"},
    {"type": "web_search", "permission": "always_allow"},
    {"type": "bash", "permission": "always_ask"},
    {"type": "file_write", "permission": "always_ask"}
  ]
}

让智能体自由读文件、搜索网页，但在执行 bash 命令或写文件前要求审批。每个工具一个配置项。

这对企业安全团队来说至关重要。LangGraph、CrewAI、AutoGen——这些框架都没有开箱即用的按工具权限作用域。你得自己构建。在这里，这只是一个配置项。这就是框架与平台的区别。

通过 MCP 将托管智能体接入 Azure 服务

Model Context Protocol 是集成层。你可以把任意 Azure 服务暴露为 MCP 服务器——Azure Blob Storage、Azure SQL、Azure Cognitive Search、Azure DevOps——然后托管智能体通过 APIM 与它们直接连接。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 带有 MCP 服务器配置的智能体，指向 Azure APIM 网关
agent_config = {
    "name": "enterprise-analyst",
    "model": "claude-sonnet-4-6",
    "system_prompt": "你是一名企业数据分析师，可以访问我们的 Azure 数据平台。",
    "tools": [{"type": "agent_toolset_20260401"}],
    "mcp_servers": [
        {
            "type": "url",
            "url": "https://{apim-name}.azure-api.net/mcp",
            "authorization_token": "${APIM_KEY}"
        }
    ]
}

APIM 处理 OAuth 2.0/PKCE 流程，Entra ID 管理身份，Azure Key Vault 管理密钥，智能体负责推理。每一层都做它被设计来做的事——一种你的安全和平台团队会真正批准的清晰职责分离。

Azure 企业今天能构建什么

这不是理论推演。工具链已经生产就绪。

企业代码审查智能体 — 通过 MCP 连接 Azure DevOps，克隆仓库，分析代码质量，运行测试，发布 PR 评论。全程在有权限管控的沙箱环境中运行。

文档智能流水线 — 将 Azure Document Intelligence 的提取能力与 Claude 的推理和综合能力结合。超长文档、复杂模式、细致分析——正是 Claude 的专长领域。

数据分析工作流 — 给智能体一个指向 Azure Blob Storage 数据的指针，让它在容器里编写 Python 脚本、执行脚本、返回结构化洞察。全套 Python 环境预装就位。

多智能体编排 — 用 Azure AI Foundry 做路由和编排层，针对需要 Claude 深度推理的具体子任务生成 Claude 托管智能体会话。

真正的多云 AI 战略

“我们用 Azure 还是用 Anthropic"这种非此即彼的框架是错误的，一直都是。真正的战略是：

用 Azure AI Foundry 处理微软模型工作负载、深度 Azure 服务集成，以及 GPT-4o 或 Phi 是最优选择的任务。
用 Claude 托管智能体处理 Claude 深度推理能力是差异化关键的工作负载——代码理解、超长上下文任务、复杂多步骤分析。
在 Azure 基础设施上统一 — 相同的认证、相同的可观测性、相同的密钥管理、相同的合规态势。模型是可替换的，基础设施是共享的。

这才是生产级多云 AI 的真实面貌。不是"把一切都到处跑”，而是"在共享的企业基础上，用最适合的模型处理对应的工作负载”。

复盘：如果重来，我会怎么做

回看我自己的基础设施工作——容器沙箱（2 周）、工具执行层（1 周）、状态持久化（3 天）、权限系统（4 天）、错误恢复（1 周）——差不多是 5 周的工程，而托管智能体用几个 API 调用就替代了。

对 Azure 企业来说，基础设施层面的故事更干净。你不是从零开始搭 Anthropic 基础设施，而是用 Anthropic 的智能体运行时扩展你现有的 Azure 基础。APIM 成为统一网关，Entra ID 成为单一身份提供商，Azure Monitor 成为可观测性平面。

“我们的企业需要 Claude 的推理能力"到"Claude 智能体在我们的 Azure 生产环境中运行"之间的距离，刚刚大幅缩短。

接下来会发生什么

未来 12 个月，我预期会看到：

Azure AI Foundry 与托管智能体的原生集成（统一编排两者的层）
带有预建 Azure 服务连接器的 MCP 服务器市场
允许托管智能体在 Azure 受监管行业中使用的合规认证
基于任务复杂度和成本在模型间路由工作负载的成本优化模式

多云 AI 的对话才刚刚开始。那些现在就摸清集成模式的企业——明白哪些工作负载适合哪些模型、跑在共享基础设施上——将获得显著的先发优势。

基础设施问题基本已经解决，真正有意思的工作现在才开始。