Multi-Agent | The .NET Blog

Handoff 模式：当一个智能体不够用时

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

在某个时刻，每个多智能体系统都会超越一个简单的路由器。第一个信号通常是当一个专业智能体需要提出后续问题时，或者在轮次中途意识到另一个智能体应该继续时。固定管道在那里失败。单次路由器在那里失败。

这正是 Microsoft Agent Framework 中 Handoff 编排模式设计解决的问题。

Handoff 如何工作

开发者声明一个图：这些是智能体，这些是它们之间的边。框架完成其余工作——为每条出边合成一个 handoff 工具并将其注入每个智能体。当智能体决定交出控制权时，它调用该工具。框架强制执行拓扑结构。

三件事使这与简单地让智能体互相调用不同：

共享转录 — 接收智能体看到完整的对话历史。不需要从头开始。
拓扑强制执行 — 智能体只能将控制权交给声明的目标。路由错误在创作时被捕获，而不是在生产中。
自然终止 — 当活跃智能体在没有调用 handoff 工具的情况下结束其轮次时，工作流让位给用户。无需轮询，无需显式退出条件。

最小示例

在 .NET 中，构建 handoff 工作流看起来像这样：

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triage 可以发送给任一专家。两个专家都可以发送回 triage。图支持无环，但在需要时支持后向边（“我需要更多信息” → 返回研究）。

何时使用 Handoff（何时不使用）

Handoff 是好的选择，当：

所有权可能在对话中途改变 — 智能体可能意识到自己是错误的专家
后向边很重要 — 可能需要在不重启的情况下重新访问之前的步骤
路由决策是细微的 — handoff 的决定是上下文相关的，最好由模型而不是类型化谓词来做出

不是正确选择，当：

管道是固定且顺序的 — 为此使用 Sequential 工作流
每个步骤都是独立的 — 智能体共享一个只有一个需要的转录只是噪音
需要严格的处理保证 — 模型驱动路由的不确定性不是你想要的

后向边和 Human-in-the-Loop

Handoff 允许的最有趣的形式之一是真正的后向边。智能体可以决定"我没有足够的信息"并路由回研究步骤——不是使用硬编码循环，而是因为模型决定这是正确的决定。

Human-in-the-loop 交互也自然地组合。当专家需要用户输入时，工作流通过默认的轮次循环让位给用户，收集响应，并以完整上下文恢复。智能体从未丢失对话。

总结

Handoff 是那些看起来简单但一旦内化就能实现很多功能的模式之一：分散路由、共享上下文、强制拓扑、自然终止。当你的智能体开始说"实际上，应该由其他人来处理这个"时，这是正确的下一步。

在原始帖子中阅读完整演练：A Tour of the Handoff Orchestration Pattern

构建不像黑盒的实时多智能体UI

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

多智能体系统的问题在于：它们在演示中看起来令人难以置信。三个智能体互相传递工作、解决问题、做出决策。然后你试图把它展示给真实用户，得到的却是……沉默。一个旋转的加载指示器。完全不知道哪个智能体在做什么，或者系统为什么暂停了。这不是产品——这是信任问题。

Microsoft Agent Framework团队刚刚发布了一篇精彩的教程，介绍如何将MAF工作流与AG-UI配合使用。AG-UI是一个开放协议，通过Server-Sent Events将智能体执行事件流式传输到前端。说实话，这正是我们一直缺少的桥梁。

为什么这对.NET开发者很重要

如果你在构建AI驱动的应用，可能已经遇到过这堵墙。你的后端编排工作得很好——智能体之间传递任务、工具触发、决策做出。但前端完全不知道幕后发生了什么。AG-UI通过定义一个标准协议来解决这个问题，将智能体事件（想想RUN_STARTED、STEP_STARTED、TOOL_CALL_*、TEXT_MESSAGE_*）通过SSE直接传输到你的UI层。

他们构建的演示是一个包含三个智能体的客户支持工作流：一个路由请求的分诊智能体、一个处理退款事务的退款智能体，以及一个管理换货的订单智能体。每个智能体都有自己的工具，交接拓扑是明确定义的——没有"从提示词中猜测"的感觉。

交接拓扑才是真正的主角

让我眼前一亮的是HandoffBuilder如何让你声明智能体之间的有向路由图：

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

每个add_handoff创建一条带有自然语言描述的有向边。框架基于这个拓扑为每个智能体生成交接工具。因此路由决策是基于你的编排结构，而不是LLM随意决定的。这对生产环境的可靠性意义重大。

真正有效的人机协作

演示展示了任何真实世界智能体应用都需要的两种中断模式：

工具审批中断 ——当智能体调用标记为approval_mode="always_require"的工具时，工作流暂停并发出事件。前端渲染一个包含工具名称和参数的审批模态框。没有烧掉token的重试循环——只是一个干净的暂停-审批-恢复流程。

信息请求中断 ——当智能体需要用户提供更多上下文（比如订单ID）时，它会暂停并询问。前端显示问题，用户回答，执行从停止的地方精确恢复。

两种模式都作为标准AG-UI事件进行流式传输，所以你的前端不需要针对每个智能体的自定义逻辑——只需渲染通过SSE连接传来的任何事件。

接入出奇地简单

MAF和AG-UI之间的集成就是一个函数调用：

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factory为每个线程创建一个新的工作流，这样每个对话都有隔离的状态。端点自动处理所有SSE管道。如果你已经在使用FastAPI（或者可以把它作为轻量层添加），这几乎是零摩擦的。

我的看法

对于我们.NET开发者来说，第一个问题是：“我能用C#做这个吗？“Agent Framework同时支持.NET和Python，AG-UI协议是语言无关的（只是SSE）。所以虽然这个特定演示使用Python和FastAPI，但模式可以直接移植。你可以用ASP.NET Core最小API配合SSE端点，遵循相同的AG-UI事件模式来实现。

更重要的启示是，多智能体UI正在成为一等公民的关注点，而不是事后才想到的事情。如果你在构建任何需要智能体与人类交互的东西——客户支持、审批工作流、文档处理——MAF编排加AG-UI透明度的组合就是应该遵循的模式。

总结

AG-UI + Microsoft Agent Framework给你两全其美：后端强大的多智能体编排和前端的实时可视化。不再有黑盒式的智能体交互。

查看完整教程和AG-UI协议仓库以深入了解。

Microsoft Agent Framework 正式发布 1.0 — 这些才是 .NET 开发者真正需要关注的

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

本文为自动翻译。如需查看原文，请点击此处。

如果你一直在关注 Agent Framework 从早期 Semantic Kernel 和 AutoGen 时代走来的历程，这次的消息意义重大。Microsoft Agent Framework 刚刚发布了 1.0 版本 — 生产就绪、API 稳定、长期支持承诺。它同时支持 .NET 和 Python，并且真正可以承载实际工作负载。

让我跳过公告的噪音，专注于你用 .NET 构建 AI 驱动应用时真正重要的内容。

简短版本

Agent Framework 1.0 将之前的 Semantic Kernel 和 AutoGen 统一为一个开源 SDK。一个代理抽象。一个编排引擎。多个 AI 提供商。如果你之前一直在 Semantic Kernel（企业模式）和 AutoGen（研究级多代理工作流）之间来回切换，现在可以停了。这就是那个唯一的 SDK。

入门简单得几乎不公平

这是一个在 .NET 中运行的代理：

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

就这些。几行代码，你就有了一个在 Azure Foundry 上运行的 AI 代理。Python 的等效代码同样简洁。随着需求增长，逐步添加函数工具、多轮对话和流式输出 — API 表面会平稳地扩展，不会变得奇怪。

多代理编排 — 这才是真正的核心

单个代理对演示来说够了，但生产场景通常需要协调。Agent Framework 1.0 附带了经过实战考验的编排模式，直接来自 Microsoft Research 和 AutoGen：

顺序执行 — 代理按顺序处理（写手 → 审核 → 编辑）
并发执行 — 并行分发给多个代理，汇聚结果
移交 — 一个代理根据意图委托给另一个代理
群组聊天 — 多个代理讨论并收敛到一个解决方案
Magentic-One — 来自 MSR 的研究级多代理模式

所有这些都支持流式处理、检查点、人机回路审批以及暂停/恢复。检查点部分至关重要 — 长时间运行的工作流在进程重启后依然可以恢复。对于我们这些用 Azure Functions 构建过持久工作流的 .NET 开发者来说，这感觉很熟悉。

最重要的功能

以下是我认为值得了解的要点：

中间件钩子。 你知道 ASP.NET Core 有中间件管道吗？同样的概念，但用于代理执行。拦截每个阶段 — 添加内容安全、日志记录、合规策略 — 而无需触碰代理的提示词。这就是让代理达到企业级标准的方式。

可插拔内存。 对话历史、持久键值状态、基于向量的检索。选择你的后端：Foundry Agent Service、Mem0、Redis、Neo4j，或者自己实现。内存是将无状态的 LLM 调用变成真正能记住上下文的代理的关键。

声明式 YAML 代理。 在版本控制的 YAML 文件中定义代理的指令、工具、内存和编排拓扑。通过单个 API 调用加载和运行。这对于想要在不重新部署代码的情况下迭代代理行为的团队来说是颠覆性的。

A2A 和 MCP 支持。 MCP（Model Context Protocol）让代理能够动态发现和调用外部工具。A2A（Agent-to-Agent 协议）实现跨运行时协作 — 你的 .NET 代理可以与其他框架中运行的代理进行协调。A2A 1.0 支持即将推出。

值得关注的预览功能

1.0 中有些功能以预览形式发布 — 功能可用但 API 可能会演进：

DevUI — 一个基于浏览器的本地调试器，用于实时可视化代理执行、消息流和工具调用。可以把它想象成 Application Insights，但用于代理推理。
GitHub Copilot SDK 和 Claude Code SDK — 直接从编排代码中使用 Copilot 或 Claude 作为代理工具。在同一工作流中将编程代理与其他代理组合在一起。
Agent Harness — 一个可定制的本地运行时，为代理提供对 shell、文件系统和消息循环的访问。可以理解为编码代理和自动化模式。
Skills — 可复用的领域能力包，为代理提供开箱即用的结构化能力。

从 Semantic Kernel 或 AutoGen 迁移

如果你有现有的 Semantic Kernel 或 AutoGen 代码，有专门的迁移助手可以分析你的代码并生成逐步迁移计划。Semantic Kernel 迁移指南和 AutoGen 迁移指南会引导你完成所有步骤。

如果你一直在使用 RC 包，升级到 1.0 只需更改版本号。

总结

Agent Framework 1.0 是企业团队一直在等待的生产里程碑。稳定的 API、多提供商支持、真正能在大规模下运行的编排模式，以及从 Semantic Kernel 和 AutoGen 的迁移路径。

该框架已在 GitHub 上完全开源，你今天就可以通过 dotnet add package Microsoft.Agents.AI 开始使用。查看快速入门指南和示例来动手实践。

如果你一直在等待"可以安全用于生产"的信号 — 就是现在。