← Harness

模型与开放条件Model & openness

它的 provider 很全，而且每种都能在官方样例目录里逐个核到。

官方给的是「provider 灵活 + 多语言一致 API」的组合。

官方 overview 页原文：

官方原文："Agents support model providers including Azure OpenAI, OpenAI, and Azure AI."

README 首段补充生态：

官方原文："supports a broad ecosystem including Microsoft Foundry, Azure OpenAI, OpenAI, and the GitHub Copilot SDK"

完整 provider 清单已核到（官方样例目录 README）：

python/samples/02-agents/providers

• Anthropic —— AnthropicClient / ClaudeAgent
• AWS Bedrock —— BedrockChatClient
• Azure OpenAI —— OpenAIChatCompletionClient
• Copilot Studio
• Microsoft Foundry 与 Foundry Local —— FoundryChatClient
• Google Gemini
• GitHub Copilot —— GitHubCopilotAgent
• Mistral —— embedding
• Ollama 本地模型 —— OllamaChatClient，官方标注为推荐用法
• OpenAI

自建 provider 继承 BaseAgent / BaseChatClient。

⚠ 未知：换 provider 后 tool calling / structured output 的可靠性对比，官方未说明。 （已查 overview 页与 providers 样例 README。）

运行位置Where it runs

它是双语言的库（SDK），但官方额外配了三条「托管与持久化」通道。

安装形态两条：

• Python：pip install agent-framework --pre（README，注意 --pre）
• .NET：dotnet add package Microsoft.Agents.AI

官方 overview 明确标注：

官方原文："Microsoft Agent Framework is currently in public preview."

三条托管/运行通道已核到：

① Foundry Hosted Agents（官方托管）—— 官方称：

官方原文："Deploy and host your agents to Foundry-hosted infrastructure with just 2 additional lines of code"

② Durable Task 扩展 —— 落在 Azure Functions（serverless，可 scale-to-zero）， 或 bring-your-own-compute / 自托管（容器、K8s、常驻 worker）。

③ 本地开发用 DevUI（交互式开发调试台）与 VS Code AI Toolkit。

责任边界：框架本身不运营 agent loop。托管要么交给 Foundry，要么自己部署。

这与 CrewAI 同为「库」，但 MAF 的官方托管路径写得比 CrewAI 更靠前。

本地文件Local files

框架核心不内置文件读写工具，文件能力来自 provider 与工具层。

默认边界官方未系统化定义。

官方 overview 只把 agent 描述成「调用工具与 MCP server 执行动作」。

它没把「读写本地文件」列为内建能力，也没描述默认文件访问边界。

目前唯一能核到的具体表述，在官方 providers 样例 README。

GitHub Copilot 样例演示了这条：

官方原文："permission-scoped shell/file/url access"

即文件/命令/网络的权限范围由该 provider 的权限模型决定，不是框架统一提供。

另有一组安全样例（python/samples/02-agents/security）演示三件事： prompt injection 防御、MCP 工具代理、跨工具数据外泄防护。

这属「用中间件自己加固」，不是文件沙箱。

⚠ 未知：框架级的默认文件系统权限模型与进程/容器沙箱，官方未说明。 （已查 overview 页与 providers 样例 README 两页。）

关机后的任务Tasks after shutdown

「关机后还能跑」在本站是靠官方 Durable 扩展兑现的，粒度是 superstep。

① 状态落盘（官方 workflows/checkpoints 页原文）：

官方原文："workflows are executed in supersteps... Checkpoints are created at the end of each superstep, after all executors in that superstep have completed"

一次 checkpoint 捕获四样东西：

• 所有 executor 状态
• 待处理消息
• pending 请求/响应
• 共享状态

② 落盘后端三档已核到：

• InMemoryCheckpointStorage —— 进程内
• FileCheckpointStorage —— 本地磁盘，storage_path 必填、无默认目录
• CosmosCheckpointStorage —— Azure Cosmos DB，分布式跨进程，推荐托管身份/RBAC 认证

Python 1.13.0 起还增加 entry checkpoint。

整轮运行因此「replayable」。

③ 真后台：官方 Durable Task 扩展提供持久会话、崩溃/重启后恢复， 以及 Azure Functions 的 scale-to-zero 与 session TTL。

官方原文（等待人工时）："Pause for human input or external events without consuming compute or model tokens"

纯 SDK 不托管后台：不接 Durable 扩展，就必须自己让进程常驻。

工具与扩展Tools & extensions

工具生态是它对标 ADK 的强项：MCP 与 A2A 都是官方点名的一等能力。

官方公告页「Four Pillars」第一条列出三项开放标准。

官方原文（MCP）："Agents can dynamically discover and invoke external tools or data servers exposed over MCP"

官方原文（A2A）："Agents can collaborate across runtimes using structured, protocol-driven messaging"

官方原文（OpenAPI）："Any REST API with an OpenAPI specification can be imported as a callable tool instantly"

overview 页原文也确认 agent 能调用工具与 MCP server：

官方原文：agent "call tools and MCP servers to perform actions"

A2A 侧已核到实现包（官方 integrations/a2a 页）：

Microsoft.Agents.AI.Hosting.A2A.AspNetCore

它用于把 agent 以 A2A 协议对外暴露，含 AgentCard 配置。

此外还有三项：

• 中间件 —— 请求/响应处理、异常处理、自定义管线
• Agent Skills —— 从文件/内联代码/类库构建领域知识库
• Declarative Agents —— 用 YAML/JSON 声明 agent

以及实验包 AF Labs。

⚠ 未知：MCP/A2A 的传输矩阵细节，官方文档未集中给出。 （已查 overview 与 a2a 两页。）

上下文与记忆Context & memory

官方把「会话状态」与「记忆」拆成两组原语。

workflow 另有 superstep 级 checkpoint。

这两件事正好对应本站「状态 ≠ 上下文」的主张。

overview 页原文列出基础积木：

官方原文："an agent session for state management, context providers for agent memory, middleware..., and MCP clients for tool integration."

公告页给出记忆的可插拔后端：

官方原文："Developers can choose Redis, Pinecone, Qdrant, Weaviate, Elasticsearch, Postgres, or their own store for conversational memory. Agent Framework provides the abstraction; you decide the backend."

这一层是本站说的「上下文/记忆」。

workflow checkpoint 是另一回事。

它落盘的是 executor 状态与待处理消息。

这属「流程状态」，见 background 轴。

两套机制官方分节描述，不可混为一谈。

⚠ 未知：长历史如何压缩进窗口，官方未在概览层给出统一机制。 （已查 overview 页与 checkpoints 页，未见类似 ADK Context Compaction 的专章。）

权限与限制Permissions & limits

官方明确的机制是「HITL 请求/响应 + 工具级人工审批」。

两者都属拦执行，不是边界划定。

① 工作流层 HITL（官方 workflows/human-in-the-loop 页）：

官方原文：HITL "is achieved through the request and response handling mechanism"

.NET 用 RequestPort（发 RequestInfoEvent）。 Python 用 ctx.request_info() 配 @response_handler。

checkpoint 会一并保存 pending 请求，恢复时重新发出。

② 工具级审批（官方公告页原文）：

官方原文："tools can be marked as requiring human approval. Agent Framework automatically emits a pending approval request that can be routed to a UI or queue, then continues or denies execution accordingly."

③ 安全样例（官方 02-agents/security）：

• SecureAgentConfig + quarantined_llm 防 prompt injection
• SecureMCPToolProxy 加固外部 MCP 工具
• 跨工具机密数据外泄防护

⚠ 未知：框架级的进程/容器沙箱默认值，官方未说明。 （已查 overview、checkpoints、a2a 三页。）

适合什么任务Best for

它是「图工作流」式的编排框架，适合五类场景。

• 要把多 agent 组织成有分支、有人工介入、可 checkpoint 恢复的确定性图工作流
• 需要 .NET 与 Python 一致 API 双语言落地
• 团队在 Azure / Microsoft Foundry 生态内
• 要求可观测性（内建 OpenTelemetry）、durability、governance 与 provider 灵活性
• 需要 MCP 与 A2A 跨运行时互通，或要从 Semantic Kernel / AutoGen 迁移

不适合四类场景。

• 只跑单个 agent、不需要图结构 —— 用 OpenAI Agents SDK 更轻
• 要求框架内置文件/进程级沙箱边界 —— 官方未提供，默认权限取决于所选 provider
• 想避开 Azure 依赖的纯本地栈 —— 虽有 Ollama 与 Foundry Local，官方托管路径仍以 Azure 为主
• 要求稳定 GA API —— 官方当前是 public preview，升级可能有破坏性变更

本页由This page is generated from the ai-agent-guide 数据层生成（CC BY 4.0）。data layer (CC BY 4.0). 方法论与坐标系定义见仓库内 METHODOLOGY.md。