Microsoft Agent Framework

一、Microsoft Agent Framework 的核心架构由哪些部分组成？

1. 框架定位与演进背景

Microsoft Agent Framework 是微软在 AI 智能体领域的旗舰开源框架，于 2026 年 4 月 2 日达到 GA（General Availability）1.0 版本。在此之前的 2025 年 10 月，微软将 AutoGen v0.4 和 Semantic Kernel 合并为统一产品，所有新的编排功能开发均集中在该框架上。AutoGen 和 Semantic Kernel 已进入维护模式，仅修复安全漏洞和问题，不再新增功能。

2. 核心能力分类

框架提供三大类核心能力：

• Agents（智能体）：使用大语言模型处理输入、调用工具和 MCP 服务器、生成响应的独立运行时组件。每个智能体是有状态的执行单元，而非简单的提示词封装。
• Workflows（工作流）：基于图的编排引擎，连接智能体和函数，强制执行执行顺序，支持检查点和人机协同场景。
• Foundational Building Blocks（基础构建模块）：包括模型客户端（聊天补全和响应）、智能体会话（状态管理）、上下文提供者（记忆和检索）、中间件管道（拦截、过滤、遥测）、MCP 客户端（工具发现和调用）。

3. 架构关键设计原则

框架采用统一 Agent 基类设计，无论底层模型提供商是谁，每个智能体都提供一致的接口。核心设计理念是让开发者专注于智能体的业务逻辑，框架负责所有通用能力的编排。架构中的每个智能体原生支持函数调用、多轮对话、结构化输出和流式响应。

二、Microsoft Agent Framework 支持哪些编程语言？

1. 主要支持的语言

Microsoft Agent Framework 目前支持 .NET（C#）、Python 和 Java 三种主流编程语言。其中 .NET 和 Python 的支持最为成熟，1.0 GA 版本同时覆盖了这两个平台，Java 版本处于公开预览阶段。

2. 跨语言一致性

框架在不同语言间提供统一的 API 概念和编程模型。无论是定义智能体、创建工作流还是配置中间件，.NET 和 Python 的 API 设计保持语义一致，开发者可以在两种语言之间无缝切换。这种跨语言的一致性降低了团队在多技术栈环境下的学习成本。

3. 包管理与安装

在 .NET 生态中，通过 NuGet 安装 Microsoft.Agents.AI 包；在 Python 生态中，通过 pip 安装 agent-framework 包。框架采用模块化设计，开发者可以根据需求按需安装扩展包，如 Microsoft.Agents.AI.Workflows 用于工作流编排、Microsoft.Agents.AI.Foundry 用于 Foundry 集成等。

三、Microsoft Agent Framework 中的 Agent 和 Workflow 有什么区别？

1. 职责分工

Agent 和 Workflow 在框架中承担不同的职责。Agent 负责开放-ended 或对话式的任务，具备自主的工具使用和规划能力，适合单次 LLM 调用（可能带工具）即可完成的场景。Workflow 则负责具有明确步骤的流程，通过基于图的编排显式控制多智能体的执行路径，适合多个智能体或函数需要协调的场景。

2. 执行模式差异

Agent 的执行模式以 LLM 推理为核心，通过工具调用来扩展能力，强调自主决策和灵活性。Workflow 的执行模式以确定性流程控制为核心，通过有向无环图（DAG）定义步骤间的依赖关系，强调执行顺序的可控性和可预测性。

3. 适用场景选择

当任务需要自主规划和灵活响应时使用 Agent，例如客服对话、研究助手等场景。当流程步骤清晰、需要严格顺序控制时使用 Workflow，例如订单处理流水线、文档审核流程等场景。两者可以组合使用，Workflow 中可以包含 Agent 作为执行节点，实现灵活性与可控性的平衡。

四、Microsoft Agent Framework 的 Agent Harness 是什么？它提供了哪些能力？

1. Agent Harness 的定位

Agent Harness 是框架中最受关注的特性之一，它是模型推理和真实执行之间的中间层。通过单次方法调用就能将一个普通聊天客户端变成功能齐全的智能体执行宿主。Harness 不是定义单独的运行时，而是基于现有的 Agent Framework 构建块组装而成。

2. 内置 Provider 体系

Harness 默认启用了六个核心 Provider：

• FileMemoryProvider：会话级文件内存，智能体可将笔记和学习记录持久化到本地磁盘，跨轮次保留记忆。
• FileAccessProvider：通用文件读写能力，允许智能体访问和操作工作目录内的文件。
• TodoProvider：多步骤任务管理，智能体可在规划和执行模式下跟踪工作项。
• AgentModeProvider：支持"规划"和"执行"两种模式分离，智能体先制定计划再执行，避免混淆。
• AgentSkillsProvider：技能发现和执行，智能体可按需加载文件系统上的 Skills，实现模块化能力注入。
• BackgroundAgentsProvider：并行子任务委派，支持将子任务委托给并行运行的子智能体。

3. 上下文压缩机制

Harness 内置自动上下文压缩功能，监控 token 使用量并在工具调用链执行过程中自动压缩聊天历史。这一机制防止长时间运行的智能体因上下文窗口溢出而中断，是生产级智能体的关键保障能力。

4. 中间件与审批机制

Harness 还提供 ToolApprovalAgent 用于敏感工具调用的审批规则管理，支持"不再询问"的持久审批规则和启发式自动审批。OpenTelemetryAgent 则自动输出符合 OpenTelemetry 标准的追踪数据，开箱即用。

五、Microsoft Agent Framework 的中间件管道有什么作用？

1. 中间件管道的基本原理

中间件管道（Middleware Pipeline）允许开发者在不修改核心提示词的前提下，向智能体的执行循环中注入逻辑。它在智能体动作执行前后进行拦截、记录和修改，是实现横切关注点的核心机制。

2. 主要应用场景

中间件管道的典型应用包括内容安全过滤、合规性检查、日志记录、请求限流和授权验证等。通过中间件，开发者可以将这些横切逻辑集中管理，避免在每个智能体中重复编写相同代码。

3. 可扩展性设计

中间件以插件形式存在，开发者可以自定义中间件逻辑，也可以组合多个中间件形成处理链。每个中间件可以独立启用或禁用，提供了灵活的扩展能力。在生产环境中，中间件管道是实现 Responsible AI（RAI）的关键基础设施。

六、Microsoft Agent Framework 如何实现 Agent 的记忆和上下文管理？

1. 多层次记忆体系

框架提供多层次的记忆管理机制。Foundry Memory 提供持久化的用户级记忆，跨会话存储事实信息，新会话启动时自动恢复。File Memory 提供会话级的文件内存，以会话 ID 为键存储在本地磁盘上。这两种记忆方式分别服务于长期记忆和短期上下文的需求。

2. 上下文提供者抽象

框架通过 Context Providers 抽象实现了即插即用的记忆能力。除了内置的 FoundryMemoryProvider 和 FileMemoryProvider 外，还支持 Mem0、Redis、Neo4j 等第三方存储后端。开发者可以根据具体场景选择合适的记忆存储方案。

3. 上下文压缩策略

对于长时间运行的对话，框架提供上下文压缩策略来管理上下文窗口。当 token 使用量接近限制时，系统会自动压缩历史消息，保留关键信息的同时释放空间。压缩策略支持自定义配置，开发者可以根据应用需求调整压缩行为。

七、Microsoft Agent Framework 提供了哪些多智能体编排模式？

1. 五种编排模式概述

框架提供了五种标准化的多智能体编排模式，每种模式适用于不同的协作场景：

• Sequential（顺序模式）：智能体按固定顺序串联执行，前一个智能体的输出作为下一个智能体的输入，适用于文档处理流水线、翻译 pipeline 等场景。
• Concurrent（并发模式）：多个智能体同时接收相同的输入并独立响应，结果随后聚合，适用于投票系统、多角度分析等场景。
• Group Chat（群聊模式）：由中心管理者智能体协调，按轮次让参与者发言，支持最大轮次限制，适用于辩论、评审会议等场景。
• Handoff（交接模式）：没有中心管理者，智能体根据专业能力自行决定将对话移交给其他智能体，适用于客服工单路由、分级处理等场景。
• Magentic-One（自主规划模式）：由规划管理者智能体维护任务清单和进度记录，动态分配子任务并根据完成情况重新规划，适用于开放式研究和未知解路径的复杂问题。

2. 模式选择的考量因素

不同编排模式在控制粒度、并行度和交互性方面各有 trade-off。顺序和并发模式是确定性的控制流，适合已知步骤的场景。群聊和交接模式将发言权交给智能体自身决策。Magentic 模式最强大但也最难调试，适合探索性任务。

八、Microsoft Agent Framework 如何支持代码生成能力？

1. CodeAct 机制

CodeAct 是框架在 Build 2026 上推出的创新特性，旨在解决传统工具调用模式中每次工具调用都需要一次独立的模型推理回合所导致的延迟和 token 消耗问题。CodeAct 让模型直接生成一段简短的 Python 程序，程序中包含所有工具调用（通过 call_tool 函数），这段代码在隔离的沙箱中一次性运行，返回整合后的结果。

2. 性能提升数据

在涉及数十次工具调用的多步骤场景中，CodeAct 相比传统逐次调用模式的实测数据为：耗时降低 52.4%（从 27.81 秒降至 13.23 秒），token 消耗降低 63.9%（从 6,890 降至 2,489）。这些数据的来源是微软官方在 Build 2026 上公布的基准测试。

3. 安全隔离机制

CodeAct 的运行基于 Hyperlight 微虚拟机技术，每次 execute_code 调用都会启动一个全新的、硬件隔离的微虚拟机，冷启动时间低于 2 毫秒。微虚拟机内没有对主机文件系统的访问权限，网络访问也仅限于显式允许的域名。如果 guest 崩溃或异常，不会影响到主机环境。

4. 适用场景与限制

CodeAct 适用于三个或更多工具串联的任务，尤其是中间数据需要在步骤间流动的场景，如数据管道、报告生成和链式查询。但不适用于需要逐操作人工审批的场景（CodeAct 以整个程序为单位进行审批），以及 .NET 平台（目前 .NET 版本的 Hyperlight 包仍处于预览阶段，完整支持计划中）。

九、Microsoft Agent Framework 的托管 Agent 是如何部署到生产环境的？

1. Foundry Hosted Agents 概述

Foundry Hosted Agents 是 Microsoft Foundry 平台提供的托管服务，为本地开发的 Agent Framework 智能体提供生产级运行环境。开发者只需将代码打包为容器镜像并部署到 Foundry 平台，即可获得自动扩缩容、持久化状态、内置可观测性和企业级身份管理的能力。

2. 部署流程

部署过程主要包括以下步骤：构建并推送容器镜像到 Azure Container Registry、创建智能体版本并注册到 Foundry Agent Service、等待版本状态变为活跃、通过专用端点调用智能体。整个过程可以通过 Azure Developer CLI（azd）、VS Code 扩展或 SDK 完成。

3. 核心特性

托管智能体提供按需扩缩容至零的能力，空闲时不产生费用。每次会话在独立的 VM 隔离沙箱中运行，支持持久化文件系统，会话间状态自动恢复。每个托管智能体拥有独立的 Microsoft Entra 身份，支持 OAuth 2.0 On-Behalf-Of 流程和托管身份认证。

4. 网络与安全

托管智能体支持私有网络连接，可以部署在网络隔离的 Foundry 资源中，并通过客户提供的 Azure Virtual Network 进行出站流量管理。会话存储支持最多 20 GiB 的磁盘预算，文件在 15 分钟无活动后自动暂停计算资源，30 天内自动销毁。

十、Microsoft Agent Framework 如何保障 Agent 的安全性和合规性？

1. 身份与访问控制

框架集成 Microsoft Entra ID 进行身份认证，支持基于角色的访问控制（RBAC）和委托执行认证。每个托管智能体拥有独立的 Entra Agent ID，提供可审计的专属身份。中间件管道支持自定义授权逻辑，可在工具调用前后实施细粒度的访问控制。

2. 内容安全与 RAI

框架通过 Azure AI Content Safety 和 Prompt Shields 实现内容安全防护，支持提示词注入检测和 PII（个人身份信息）识别。2026 年 4 月 2 日，微软同步发布了 Agent Governance Toolkit，这是一个覆盖 OWASP Agentic AI 全部 10 项风险的开源治理工具集，可与 Agent Framework 无缝集成。

3. 合规认证

依托 Azure 基础设施，Agent Framework 继承了超过 50 项合规认证，包括 SOC 2 Type 2、HIPAA、FedRAMP High、ISO 27001 等，满足金融、医疗和政府行业的严格合规要求。数据传输采用 256 位 AES 加密（符合 FIPS 140-2 标准），支持客户管理的密钥。

4. 网络安全

框架支持 VNet 集成和私有网络连接，确保智能体通信在私有网络中进行。Foundry Agent Service 提供端到端的私有网络连接，支持内部资源访问而不经过公网。

十一、Microsoft Agent Framework 的可观测性是如何实现的？

1. OpenTelemetry 集成

框架内建对 OpenTelemetry 的支持，能够自动采集智能体决策、工具调用和多智能体工作流执行的完整追踪数据。通过 .UseOpenTelemetry() 方法在 IChatClient 层面和 Agent 层面进行仪器化，追踪数据遵循 GenAI 语义规范，包含 token 使用量、延迟、工具调用参数和响应等信息。

2. DevUI 调试工具

DevUI 是一个基于浏览器的本地调试工具，提供智能体消息流、工具调用详情和状态变化的实时可视化展示。开发者可以在 IDE 中直接查看工作流图（Mermaid 或 Graphviz 格式）、每个执行步骤的详细信息以及迭代计数，大幅提升了多智能体系统的调试效率。

3. 与 Azure Monitor 的集成

MAF 的 OpenTelemetry 追踪数据可以自动流入 Application Insights，通过新建的 Agents 视图进行集中监控。Application Insights 提供按智能体维度的指标面板，包括调用次数、token 使用趋势、延迟百分位数和错误率等。此外还支持 Azure Managed Grafana 预置仪表板，实现运营层面的持续监控。

4. 评估与优化闭环

Foundry 平台提供端到端的评估能力，包括意图解析准确率、工具调用准确性、任务遵循度、相关性和可信度等维度。评估结果直接与追踪数据关联，当发现质量评分下降时可以快速定位到具体的执行路径。Prompt Optimizer 工具可对提示词进行结构化优化，形成"优化-测量-再优化"的持续改进闭环。

十二、Microsoft Agent Framework 如何支持长运行任务的断点续传？

1. 工作流检查点机制

框架通过 Microsoft.Agents.AI.DurableTask 扩展包将工作流执行能力接入 Durable Task 技术栈。该扩展使得工作流中的每个 Executor 步骤在执行完成后自动保存检查点，即使进程崩溃、重启或缩放事件发生，工作流也能从最后保存的状态恢复执行。

2. Durable Task Scheduler

Durable Task Scheduler（DTS）作为持久化运行时，负责存储工作流状态和管理编排历史。它为每个 Executor 生成带有 dafx- 前缀的活动名称，提供内置的 Dashboard 用于监控和管理执行进度。本地开发阶段可通过 Docker 运行 DTS Emulator 进行快速验证。

3. 长运行工作流能力

借助 Durable Task 运行时，工作流可以持续运行数分钟、数小时甚至数天。支持扇出/扇入模式（Fan-out/Fan-in），允许多个智能体并行处理同一输入后再汇聚结果。支持条件分支路由，通过 AddSwitch 根据前序步骤的输出动态选择执行路径。

4. 人机协同与暂停恢复

框架通过 RequestPort.Create() 实现人机协同场景，工作流可以在等待人工审批时进入暂停状态并持久化，当收到响应后自动恢复执行。这种机制特别适合需要人工介入的业务流程，如财务审批、内容审核等场景。

十三、Microsoft Agent Framework 适用于哪些应用场景？

1. 企业级业务流程自动化

框架的强项在于自动化跨越多个步骤和工具的业务流程。例如 KPMG 使用该框架自动化审计测试和文档生成流程，BMW 部署多智能体系统分析车辆遥测数据进行异常检测，Commerzbank 推进 Avatar 驱动的客户服务。这些场景的共同特点是涉及多步骤、多工具的复杂业务流程。

2. 研发与编码辅助

通过集成 GitHub Copilot SDK，框架可以直接利用 Copilot 的代码理解能力和 Shell 执行能力，构建代码审查、代码重构、单元测试生成等研发辅助智能体。CodeAct 特性进一步提升了代码执行类任务的效率。

3. 数据分析与研究

Harness 的文件内存、Web 搜索和代码解释器能力，结合多智能体编排，使框架适用于数据分析、市场研究、竞品分析等需要多源信息整合的场景。Magentic 模式特别适合开放式研究任务，智能体可以自主规划研究路径并动态调整方向。

4. 客户支持与工单处理

Handoff 编排模式和 Group Chat 模式天然适用于客户支持场景。智能体可以进行初步诊断，然后根据问题类型自动路由到相应的专业智能体，复杂问题还可以通过群聊模式进行多方协作分析。

十四、Microsoft Agent Framework 与 LangGraph 等其他 Agent 框架有何区别？

1. 与 LangGraph 的定位差异

LangGraph 是基于 LangChain 的图编排框架，强调灵活的图结构和状态管理，在 Python 生态中有广泛的用户基础。Microsoft Agent Framework 则提供更完整的端到端解决方案，不仅包含编排能力，还集成了企业级特性如中间件管道、审批机制、可观测性和 Foundry 平台集成。

2. 语言支持的差异

LangGraph 主要面向 Python 开发者，而 Microsoft Agent Framework 同时支持 .NET、Python 和 Java，在多语言企业环境中更具优势。特别是对于已有 .NET 技术栈的企业，MAF 提供了更平滑的迁移路径。

3. 生态集成的差异

MAF 深度集成 Microsoft Foundry 平台，提供从本地开发到云端部署的一体化体验。Foundry Agent Service 提供托管运行时、Toolboxes 工具管理、Foundry IQ 知识层等配套能力。相比之下，LangGraph 更偏向于框架层面的编排能力，部署和运维需要自行搭建基础设施。

4. 编排模式的差异

MAF 提供了五种标准化的编排模式（Sequential、Concurrent、Group Chat、Handoff、Magentic），每种都有明确的适用场景和 API 抽象。LangGraph 则提供更底层的图构建原语，开发者需要手动定义节点和边，灵活性更高但学习曲线也更陡峭。