在今年的 Microsoft Build 上，Microsoft Discovery 宣布正式商用（GA），同时推出了 Microsoft Discovery App 的预览版。对于正在把 AI Agent 从原型推向生产环境的团队来说，这个消息值得关注——它不是又一个模型 API，而是专门针对 agentic AI 工作流的构建与治理 的完整平台。
为什么需要专门的 Agent 平台？
单次 LLM 调用已经不够了。现实中的业务场景——客户服务、供应链调度、研发文献检索——都需要多个 Agent 协作、调用外部工具、维护上下文状态，同时还要满足合规审计要求。
过去，团队往往自己拼凑：用 LangChain 串联调用，用自定义中间件做路由，再手动写日志做追踪。这套做法在 demo 阶段跑得通，上生产后很快遇到三个痛点：
- 编排混乱：Agent 之间的调用链缺乏统一调度，出错时难以定位。
- 治理缺失：谁调了什么工具、花了多少 token、是否触发了安全策略，几乎没有系统化记录。
- 扩展瓶颈：加一个新 Agent 或改一条工作流，往往要改多处硬编码。
Microsoft Discovery 要解决的正是这些问题。
核心能力拆解
1. Agentic 工作流编排
Discovery 提供声明式的工作流定义方式。你可以把一个多步骤的 Agent 流程描述成结构化的配置，而不是散落在多个 Python 文件里的函数调用。这样做的好处是：流程可可视化、可版本管理、可回滚。
2. 工具调用与集成
Agent 的价值在于能行动——调用搜索、读写数据库、发邮件、操作 API。Discovery 内置了对 Azure 生态工具的集成支持，同时也允许注册自定义工具端点。
3. 治理与可观测性
这是 GA 版本最强调的部分。每条工作流的执行都有完整轨迹：哪个 Agent 在哪一步调了哪个工具、输入输出是什么、耗时与 token 消耗多少。这些数据既用于调试，也用于合规审计。
4. 安全策略与权限控制
Agent 自主行动意味着风险。Discovery 支持在工作流层面设置策略：比如限制某个 Agent 只能访问指定数据源、对高敏感操作要求人工审批节点。
实践：用 Discovery 构建一个文献检索 Agent 工作流
下面用一个最小可运行的示例，展示如何定义一个两步 Agent 工作流——第一步检索文献，第二步总结并输出结论。这个示例基于 Discovery 的 REST API 和 Python SDK（azure-ai-discovery 包，GA 后已发布到 PyPI）。
前提：你已有 Azure 订阅，并创建了 Discovery 资源。替换
<your-endpoint>和<your-api-key>为实际值。
安装 SDK
pip install azure-ai-discovery azure-identity
定义并运行一个 Agentic 工作流
from azure.ai.discovery import DiscoveryClient
from azure.identity import DefaultAzureCredential
import json
# 1. 认证与初始化客户端
credential = DefaultAzureCredential()
client = DiscoveryClient(
endpoint="https://<your-endpoint>.services.azure.microsoft.com",
credential=credential,
)
# 2. 声明式定义工作流：检索 → 总结
workflow_definition = {
"name": "literature-search-summarize",
"version": "1.0",
"description": "检索指定主题的科研文献，并生成结构化总结",
"agents": [
{
"id": "search-agent",
"role": "Searcher",
"model": "gpt-4.1",
"tools": [
{
"type": "azure_ai_search",
"index_name": "pubmed-index",
"description": "在 PubMed 索引中检索文献摘要"
}
],
"instructions": "根据用户查询，检索最多 5 篇相关文献，返回标题、作者和摘要。"
},
{
"id": "summarize-agent",
"role": "Summarizer",
"model": "gpt-4.1",
"tools": [],
"instructions": "基于 search-agent 返回的文献列表，生成一段 200 字的中文总结，突出共同发现和分歧点。"
}
],
"flow": [
{"from": "search-agent", "to": "summarize-agent"}
],
"governance": {
"trace_level": "full", # 记录完整执行轨迹
"token_budget_per_run": 5000, # 单次运行 token 上限
"human_approval": False # 此流程无需人工审批
}
}
# 3. 注册工作流
workflow = client.workflows.create_or_update(
workflow_name="literature-search-summarize",
body=workflow_definition,
)
print(f"工作流已注册: {workflow.id}")
# 4. 触发一次运行
run = client.workflows.run(
workflow_name="literature-search-summarize",
input={"query": "CRISPR 在遗传性视网膜病变中的最新临床试验进展"},
)
# 5. 查看结果与执行轨迹
print("=== 输出 ===")
print(run.output["summary"])
print("\n=== 执行轨迹 ===")
trace = client.traces.get(run_id=run.id)
for step in trace.steps:
print(f"[{step.agent_id}] {step.action} → tokens: {step.token_usage}")
运行后你会看到两步 Agent 的完整输出和轨迹。trace_level: "full" 确保每一步的工具调用、模型响应、token 消耗都被记录——这正是治理的基础。
用 CLI 快速检查工作流状态
# 列出已注册的所有工作流
az discovery workflow list --resource-group myRG --name myDiscoveryResource
# 查看某次运行的轨迹详情
az discovery trace show --run-id <run-id> --resource-group myRG --name myDiscoveryResource
Discovery App 预览版：可视化编排的入口
伴随 GA 发布的还有 Microsoft Discovery App 的预览版。它提供了一个可视化界面，让你在浏览器中拖拽编排 Agent、配置工具连接、设定治理策略，然后一键部署到 Discovery 后端。
对于不熟悉声明式 YAML/JSON 定义的业务团队，App 预览版降低了门槛。但底层生成的仍然是同一套工作流定义，所以你可以在 App 里设计，在代码里迭代，两边互不冲突。
上生产前的检查清单
把 Agent 工作流从 demo 推向生产，建议逐项确认：
| 检查项 | 说明 |
|---|---|
| token 预算 | 为每条工作流设定 token_budget_per_run，防止 Agent 循环调用导致成本失控 |
| 轨迹级别 | 至少设为 full；合规场景建议导出轨迹到 Azure Monitor 或外部审计系统 |
| 人工审批节点 | 涉及数据删除、资金操作等高敏感动作，务必开启 human_approval: true |
| 工具权限边界 | 每个 Agent 只注册它真正需要的工具，避免过度授权 |
| 版本管理 | 工作流定义纳入 Git，每次变更走 PR 审查，与基础设施同等待遇 |
| 回滚方案 | 保留上一版本的工作流定义，出问题时秒级回退 |
看清边界
Microsoft Discovery 目前有几个值得注意的限制：
- 生态绑定：内置工具集成以 Azure 服务为主（AI Search、Cosmos DB 等）。如果你大量依赖非 Azure 工具，需要自行注册自定义端点，额外工作量不小。
- App 预览版功能不全：拖拽编排已可用，但高级治理策略的图形化配置仍在迭代中，复杂场景暂时需要回退到代码定义。
- 模型选择范围：当前支持 Azure OpenAI Service 上的模型系列，尚未开放第三方模型接入。
如果你已经在 Azure 上运行 AI 应用，Discovery 是把 Agent 从脚本升级为可治理生产系统的合理路径。如果你的基础设施以多云或自建为主，则需要评估集成成本是否可接受。
Agentic AI 正从"能跑起来"走向"能管得住"。Microsoft Discovery GA 的信号很明确：编排和治理不再是可选附件，而是 Agent 平台的核心能力。现在可以开始在非关键业务流程上试跑，积累工作流定义和治理策略的实战经验——等到你需要把 Agent 放到真正敏感的业务环节时，这套基础设施已经磨合过了。