如果有人问我 2025 年上半年 .NET 方向最值得关注的新东西我会毫不犹豫提名 Microsoft Agent FrameworkMAF。原因很简单它把 Multi-Agent 的编排成本一下子拉低到了“写配置文件 少量注册代码”就能搞定而且还内置了 SubAgent 这种原生子代理模式。我从公共预览版开始落地陆陆续续跑了几个真实业务场景最大的体会是——单 Agent 解决不了的问题拆成子代理之后效果往往是质的差别。这篇文章不打算重复官方文档里的 Hello World我直接把 0.1 到 1 的完整过程写出来从包选型、YAML 定义、宿主注册到子代理的动态任务调度、状态共享、可观测性踩坑全部摊开讲。如果你正准备把一个逐渐失控的单 Agent 重构为可维护的多代理系统这应该能省你不少弯路。1. 为什么单 Agent 撑不起复杂业务而 SubAgent 可以先从一个很典型的现象说起。很多人做 Agent 的第一版都极其顺利一个模型、几百行指令、几个 tool业务就跑通了。但上线三个月后开始变味——业务方不断往里加需求你不断往 instructions 里追加行为约束prompt 越来越长模型开始“顾此失彼”工具调用的选择也越来越飘。最后你发现系统不是被模型限制卡死的是被指令冲突和上下文污染卡死的。1.1 单 Agent 的四个天花板我自己的体感是单 Agent 架构有四个早晚会撞上的天花板上下文窗口瓶颈所有工具结果、历史对话、业务规则最后都堆进同一个 context窗口再大也不够用。尤其当工具是网页抓取、代码检索这类高 token 消耗操作时很快就把预算烧光了。指令优先级冲突同一个 Agent 既要“扮演客服安抚情绪”又要“严格按 API 返回结果给事实”还要“输出 JSON”。模型在多个目标之间做取舍行为就变得不可预测。失败爆炸半径大一次工具调用异常或一次错误的上下文拼接会直接污染整个对话轮次而且很难定位到底哪一步出的问题。难以并行和复用单个 Agent 是串行工作的天然无法把独立子任务拆给多个并发执行者。这些问题的本质是把“一个负责决策的大脑”和“多个负责执行的肢体”硬塞进了同一个进程、同一个 context。而 Multi-Agent 架构尤其是 SubAgent 模式恰恰是把决策和执行拆开。1.2 MAF 里的四种多代理模式Microsoft Agent Framework 在架构上把协作模式分成了几类理解这个分类很重要因为它决定了你的系统设计模式核心特点适用场景Single Agent一个代理独立完成任务简单问答、单工具调用SubAgent主代理在运行时动态创建子代理把子任务委派出去任务可变性高、子任务边界清晰Teams多个代理相对固定地分组协作有明确的角色和会话规则客服团队、固定流程会议Workflows代理之间通过预定义的工作流/状态机连接审批流、数据管道、定时任务SubAgent 和 Teams 的区别很微妙很多初学者会混淆。Teams 模式下代理集合基本是预先确定的它们的角色像一个固定阵容而 SubAgent 模式下上层代理是按需创建下层代理的同一个上层代理面对不同的任务可以动态拉起完全不同的子代理组合。这种动态性才是 SubAgent 最值钱的地方。1.3 什么场景才真的需要 SubAgent不是所有项目都需要 Multi-Agent。如果任务链条短、工具数量少、交互模式固定老老实实用单 Agent 反而更稳。我自己的判断标准有三条业务存在明显的子任务边界比如“先检索、再写作、再审校”这种可以切成阶段的流程。子任务之间存在隔离需求某个子任务的失败不应该污染主任务状态。你希望独立演进某个能力比如换掉“写作”这个子模块的模型或提示词而不影响其他部分。满足其中两条SubAgent 模式就值得认真考虑。2. Microsoft Agent Framework 与原有多代理框架的差异到底在哪如果你之前接触过 Semantic Kernel、AutoGen、LangGraph、CrewAI 这类东西可能会问MAF 和它们到底有什么本质区别直接说结论MAF 不是又一个“Agent 框架”它更像一个Agent 运行时与编排层目标是把上层的 AI Agent 框架和下层的企业基础设施粘合起来。2.1 从 Semantic Kernel 到 Agent Framework 的演进MAF 和 Semantic KernelSK的关系比较有意思。SK 解决的是“如何让模型和代码、记忆、工具更好地协作”它的核心抽象是 Kernel、Plugin、Function本质上还停留在“函数调用”这一层。你在 SK 里写 Multi-Agent仍然需要自己去编排消息循环、自己管理代理生命周期、自己处理跨代理状态。MAF 则是在 SK 之上做了一层面向 Agent 生命周期与协作的抽象。它提供了AgentFactory统一创建代理的入口代理定义可以是 YAML。AgentContext给代理运行提供计时器、遥测、请求响应等基础设施。AgentRuntime负责代理任务的分发、长时运行、水平扩展。声明式能力代理的定义不写在代码里而是写在 YAML 配置里代码只负责注册和启动。这个设计直接改变了开发方式。以前你要理解整套 agent 内部逻辑必须去读代码现在团队里一个新的开发者光看 agents.yaml 就能知道系统有哪些角色、各自干什么。2.2 “框架无关”与统一 Worker 接口MAF 还有一个很激进的特性代理元框架无关。它允许你接入 Semantic Kernel 的 Agent、OpenAI 的 Agent SDK、LangChain 的 Agent甚至 Carbon 等第三方运行时然后统一暴露成AgentWorker接口。这意味着你团队里有人用 SK 写代理、有人用 LangChain 写代理上层编排不用改这是很多框架做不到的。在我实际使用中这个特性的价值主要在渐进式迁移。我们有一个老系统是用别的框架写的 Agent迁移到 MAF 时不需要全部推翻重写只要把代理外面包一层 Worker 适配就能被 MAF 的编排层托管业务侧无感。2.3 和其他主流框架的横向对比框架Agent 定义方式子代理支持运行时企业特性Microsoft Agent FrameworkYAML 声明式原生 SubAgent 模式支持分布式 Runtime强含治理、可观测性Semantic Kernel代码为主需自行实现无独立运行时一般AutoGen代码为主支持对话式多代理无独立运行时弱LangGraph代码/图定义通过图节点实现有平台但生态较新中等CrewAI代码为主角色分工无独立运行时弱表格可能有点简单粗暴但方向是真实的MAF 最大的差异化不在于“能建多代器”而在于它把多代理从“代码调出来的”变成了“配置声明出来的”并配了一个真正的运行时。3. 环境准备与最小 Demo先把一个 Agent 跑起来聊再多架构不如先把一个 Agent 跑起来。MAF 公共预览版目前主要支持 .NET我用的是 .NET 8建议至少安装 SDK 8 以上用 VS 2022 17.12 或直接命令行都可以。3.1 项目初始化与包选型创建一个控制台项目dotnet new console -n SubAgentDemo cd SubAgentDemo然后引入核心包。公共预览阶段我实际用的是这几个包dotnet add package Microsoft.Agent.Framework dotnet add package Microsoft.Agent.Framework.Extensions dotnet add package Microsoft.Agent.Framework.Extensions.SubAgents dotnet add package Microsoft.SemanticKernel注意SubAgents 扩展在早期是以独立包发布的后续版本可能合入主包这很正常。装的时候建议直接看 NuGet 上的最新版本以 0.x 的预览版本号为主。3.2 配置模型连接我用的是 Azure OpenAI需要在项目里配置客户端凭据。可以在appsettings.json里写也可以用环境变量。我倾向用环境变量避免把密钥放进仓库export AZURE_OPENAI_API_KEY你的key export AZURE_OPENAI_ENDPOINThttps://your-resource.openai.azure.com/MAF 的模型配置是放在 YAML 里的但 provider 相关的连接信息会从宿主配置取。这块和 SK 的习惯一致算是对老玩家的友好设计。3.3 编写最简 Host 引导代码MAF 应用本质上是一个 Generic Host 应用。先写一个最简入口确保框架能启动using Microsoft.Agent.Framework; using Microsoft.Agent.Framework.Extensions; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Hosting; var builder Host.CreateApplicationBuilder(args); builder.UseAgentFramework(); var host builder.Build(); await host.StartAsync(); var factory host.Services.GetRequiredServiceAgentFactory(); // 这里的 echo 是我们即将定义的一个代理名称 var agent factory.CreateAgent( Path.Combine(AppContext.BaseDirectory, agents.yaml), echo ); await agent.RunAsync(你好帮我确认系统正常。); await host.StopAsync();在项目目录下放一个agents.yaml并设置“复制到输出目录”name: echo description: A simple echo agent for smoke testing instructions: | 你是一个简单的测试代理用户说什么你就如实确认你收到了什么。 model: provider: azureopenai name: gpt-4o-mini跑起来之后如果控制台能看到模型回复说明环境链路通了。这一步虽然看起来原始但能帮你在引入 Multi-Agent 之前就排除掉“模型连接、YAML 解析、Host 装配”这类基础问题。3.4 常见的启动坑我在第一步踩过一个比较典型的坑CreateAgent的路径是基于当前工作目录的而不是项目目录。如果使用dotnet run从项目根运行通常没问题但如果是发布后从别的目录启动比如 systemd 服务路径就会失配。建议像我上面那样用AppContext.BaseDirectory拼出绝对路径同时把 YAML 文件的“复制到输出目录”属性改为“如果较新则复制”。4. 用 YAML 定义“整套”Agent 配置的实战写法YAML 定义在整个 MAF 里地位很高。它不只是配置文件更是代理的“身份契约”。把代理的定义和实现解耦最大的好处是调优行为不用改代码改 YAML 就行。但这也意味着 YAML 写得好不好直接决定系统的上限。4.1 Agent YAML 的核心字段以我们实际用的子代理为例拆解一下字段含义schema_version: 1 name: researcher description: 负责检索资料、整理事实依据的研究型子代理 instructions: | 你是一个研究助手。你会收到一个研究任务任务是主代理分配给你的。 请按照以下步骤执行 1. 确认任务中的主题和范围 2. 调用可用的检索工具获取信息 3. 输出结构化的资料摘要包含来源、关键事实、引用 注意你只需要输出研究结果不要尝试写作或审校。 model: provider: azureopenai name: gpt-4o-mini skills: - name: web_search type: nativename代理的唯一标识CreateAgent和AddSubAgent里都靠它定位。description这个字段不只是给人看的更是给上层代理“选择谁”看的。上层代理是通过 description 来判断某个子代理是否适合当前子任务的。instructions子代理的系统提示词只对它自己的 context 生效。model可以给子代理指定不同的模型。便宜的模型跑量贵的模型做决策这是多代理系统成本控制的重要杠杆。skills代理能用的工具集合。MAF 里技能可以是原生代码技能也可以是 SK 插件还可以是 MAF 内置的 AgentTask、AgentCache 这类特殊技能。4.2 description 的“面向选择器”写法这里有个很重要的经验description 是写给“调度者/上层代理”看的不是写给用户看的。很多人习惯写“我是研究助手”这太泛了。更好的写法是明确说明“我负责什么、我能接受什么任务、我会产出什么格式”。比如description: 检索型子代理。擅长联网搜索、知识库检索与事实核查。 当主代理需要背景资料、数据支撑、来源引用时调用本代理。 输入为研究主题输出为带来源的结构化摘要。写得越具体上层代理的调度准确率就越高。我甚至建议在 description 里写明“什么情况不要用我”比如“不要用我处理情感类内容”这能在一定程度上减少误调度。4.3 instructions 的隔离与边界子代理的 instructions 和主代理的 instructions 是隔离的这一点一定要吃透。子代理看不到主代理的全部对话历史只会收到主代理通过 AgentTask 工具传过来的任务描述。这个隔离既是优点也是约束优点是不会被无关上下文污染约束是你要在任务描述里把上下文讲清楚否则子代理会“断章取义”。所以在设计子代理时我会在 instructions 里固定两个小节输入解读和输出协议。输入解读告诉子代理“你会收到什么格式的任务”输出协议告诉它“你必须返回什么结构”。这样主代理传参时只需要按约定填内容子代理不会自由发挥。4.4 用多个 YAML 组织代理群我建议一个系统使用一个主 YAML 文件或按目录分隔config/ agents.yaml # 主代理定义 sub_agents/ researcher.yaml writer.yaml reviewer.yaml主代理和子代理可以放在不同文件里。AddSubAgent注册时分别传路径即可。注意主代理定义里不会显式列出“我有哪些子代理”子代理列表是通过宿主注册注入到运行时的主代理在运行时靠 tool 感知它们。这个设计和很多人想当然的“父引子”不同一开始我也理解错了。5. 构建一个真实的多代理系统稿件生产流水线概念讲完上实战。我用一个“稿件生产系统”来做完整示例主代理接收一个写作主题动态拉起三个子代理——研究者、写手、审核者——分别完成资料检索、初稿生成、质量审校。这个场景足够典型既涉及动态调度也涉及状态共享还涉及终止条件。5.1 定义三个子代理先定义sub_agents/researcher.yamlname: researcher description: 研究型子代理。擅长检索信息、归纳事实、提供结构化资料。 当主代理需要背景资料、数据支撑、来源引用时调用本代理。 输入为研究主题输出为带来源的结构化资料摘要。 instructions: | 你是研究子代理。你会收到主代理传来的研究主题。 步骤 1. 解读主题提取关键检索词。 2. 使用 web_search 技能检索至少 3 个有效来源。 3. 输出 JSON 格式的研究报告 { topic: 主题, key_findings: [关键结论], sources: [{title: 标题, url: 地址}] } 不要编写正文不要给建议只输出事实与来源。 model: provider: azureopenai name: gpt-4o-mini定义sub_agents/writer.yamlname: writer description: 写作型子代理。擅长将研究资料改写为流畅的科普/技术稿件。 当研究资料已准备好、需要成稿时调用本代理。 输入为研究摘要与写作要求输出为符合要求的完整文章。 instructions: | 你是写作子代理。你会收到研究摘要和写作要求。 步骤 1. 以研究摘要中的事实为准不虚构数据。 2. 按照要求的篇幅、语气、结构输出文章。 3. 用 Markdown 输出标题清晰。 如果研究摘要缺失明确说明“缺少资料”不要强行编造。 model: provider: azureopenai name: gpt-4o定义sub_agents/reviewer.yamlname: reviewer description: 审核型子代理。擅长检查文章的事实准确性、逻辑连贯性、格式规范。 当初稿完成、需要质量把关时调用本代理。 输入为待审核文章输出为审核意见与修改建议。 instructions: | 你是审核子代理。你会收到一篇文章。 请检查以下维度 1. 事实是否有依据是否有明显的无根据断言。 2. 逻辑是否连贯段落衔接是否自然。 3. 格式是否符合 Markdown 规范。 4. 是否满足要求中的篇幅。 输出审核意见格式 【通过/需修改】 问题列表 - 严重问题 - 建议修改 model: provider: azureopenai name: gpt-4o-mini5.2 定义主代理主代理不直接干活它扮演的是“拆解任务 分配 聚合结果”的角色name: editorial_coordinator description: 稿件生产主代理负责把写作任务拆解给研究、写作、审核子代理。 instructions: | 你是稿件生产协调者。你会收到用户的写作请求。 流程 1. 先启动 researcher 子代理传入写作主题取得研究资料。 2. 再启动 writer 子代理传入研究资料和写作要求取得初稿。 3. 最后启动 reviewer 子代理传入初稿取得审核意见。 4. 如果审核意见要求修改将修改意见连同初稿传给 writer重新生成。 5. 汇总最终稿件与审核结论在回复中展示 - 最终稿件 - 资料来源如果有 - 审核结论 注意 - 子代理之间不要互相传递原始对话历史只传递任务所需的摘要。 - 如果某一步子代理任务失败重试一次仍失败则向用户说明。 model: provider: azureopenai name: gpt-4o5.3 在宿主中注册子代理并运行接下来是代码装配。在Program.cs里通过AddSubAgent注册子代理using Microsoft.Agent.Framework; using Microsoft.Agent.Framework.Extensions; using Microsoft.Agent.Framework.Extensions.SubAgents; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Hosting; var builder Host.CreateApplicationBuilder(args); var appBuilder builder.UseAgentFramework(); // 注册子代理state 参数指向 YAML 文件 appBuilder.AddSubAgent( state: Path.Combine(AppContext.BaseDirectory, config/sub_agents/researcher.yaml) ); appBuilder.AddSubAgent( state: Path.Combine(AppContext.BaseDirectory, config/sub_agents/writer.yaml) ); appBuilder.AddSubAgent( state: Path.Combine(AppContext.BaseDirectory, config/sub_agents/reviewer.yaml) ); var host builder.Build(); await host.StartAsync(); var factory host.Services.GetRequiredServiceAgentFactory(); var coordinator factory.CreateAgent( Path.Combine(AppContext.BaseDirectory, config/agents.yaml), editorial_coordinator ); await coordinator.RunAsync( 写一篇介绍 Microsoft Agent Framework 的科普文章目标读者是 .NET 开发者1500 字左右。 ); await host.StopAsync();代码本身不复杂。真正的工作量在 YAML 的指令设计里。运行时里发生的事是主代理判断任务需要拆解于是调用 AgentTask 工具传入 researcher 的描述与输入MAF 运行时动态创建 researcher 实例研究结果返回后主代理再启动 writer依此类推。5.4 流水线成功的关键任务描述即接口这个系统跑起来之后我发现最核心的优化点是任务描述的“接口化”。主代理在调度时传给子代理的文本就是子代理的输入接口。这个接口是否稳定直接影响子代理的输出质量。我会给每个子代理在 instructions 里规定输入格式同时在主代理 instructions 里也写清楚“传给 researcher 的主题要包含哪些字段”。比如传给 researcher 主题{topic} 额外要求{requirements}这样即使主代理换了模型、换了提示词只要它按这个格式传参子代理就不容易跑偏。这是我从实践中悟到的一条经验多代理系统的稳定性不取决于单个代理多聪明而取决于代理之间的接口契约多清晰。6. 子代理编排细节动态任务、缓存共享与终止控制上面那个例子能跑但离“生产可用”还差一步——你无法控制子代理之间的状态共享、并行关系和终止行为。MAF 的 SubAgent 模式里这几个问题分别由三个工具解决AgentTask、AgentCache、AgentTerminate。6.1 AgentTask子代理的创建与执行AgentTask 是 MAF 的内置技能也是 SubAgent 模式的触发器。主代理调用它时本质上是向运行时提交了一个“子代理任务”。这个任务包含目标子代理的名称或描述。传给子代理的输入内容。期望的输出形式。运行时会负责实例化子代理、执行、回收结果。这种“任务式调度”有几个好处一来任务可以被记录、追踪、重试二来任务可以在不同的进程甚至主机上执行三来任务天然支持排队避免多个子任务同时打爆 API 的 rate limit。在我做的实测里同一批子任务配置了并发后稿件生产流水线从串行的 40 秒左右降到了 22 秒左右收益很明显。并行是把双刃剑并发太高可能触发模型服务限流我的建议是先保守并发数观察延迟和错误率再逐步调整。6.2 AgentCache让子代理之间共享高频上下文子代理的 context 是隔离的但很多场景下它们需要共享一些高频信息比如用户身份、业务规则、术语表。如果每个子代理任务都带着完整术语表token 成本会指数级上升。AgentCache 工具就是干这个的。它可以让你在子代理之间共享一部分只读上下文类似于给所有子代理带了一张“公共记忆卡”。我实际用下来最适合放进去的是全局业务术语与缩写解释。统一的输出格式约束。需要保持一致的事实基准比如公司名称、产品或版本号。但不要什么垃圾都丢进去。缓存内容会被所有子代理读取一旦更新可能影响正在运行的一批任务。我建议缓存只放“高频、稳定、只读”的内容可变的状态还是通过任务参数传递。6.3 AgentTerminate多代理的刹车多代理系统最怕的是死循环主代理反复修改、反复再生成token 烧完还没结束。MAF 提供了 AgentTerminate 工具让代理显式表达“任务完成”的语义。在稿件生产流水线里我给主代理的指令就是“审核通过或重试一次后必须调用 AgentTerminate 结束任务”。这个指令虽然简单但能避免很多失控情况。我还结合了超时机制子代理任务如果超过预设时长运行时强制终止。这些强制边界在预览版阶段尤其重要因为多代理行为的不确定性和单代理不是一个量级。6.4 状态传递的最佳实践子代理之间传递状态我建议遵循三条原则只传摘要不传原文。上一个子代理的完整输出往往包含大量无关内容传摘要能显著省 token。用结构化格式传递。比如 JSON字段明确解析也方便。纯文本容易导致下一环误解。传递时带版本或来源标记。尤其在写作流水线里审核意见引用初稿某一段时最好带上段落编号否则子代理不知道你指的是哪一句。有一段时间我们的流水线产出经常“逻辑断裂”排查下来发现是子代理之间传的是大段聊天记录writer 分不清哪些是资料、哪些是历史消息。改成结构化摘要后问题立刻消失。这类问题在单 Agent 时代是不存在的算是多代理特有的“沟通税”。7. 可观测性与线上排错别让多代理变成黑盒多代理系统最大的运维噩梦是黑盒你只看到用户发了一条消息系统内部发生了 4 次子代理调用、3 次工具回调然后用户说“结果不对”你根本不知道哪一环出了问题。所以从一开始就要把可观测性当成功能来做而不是事后补救。7.1 接入 OpenTelemetry 与运行时遥测MAF 对 OpenTelemetry 支持是内建的。你只需要在 Host 里加上 tracing 即可builder.Services.AddOpenTelemetry() .WithTracing(tracing { tracing.AddSource(Microsoft.Agent.Framework) .AddConsoleExporter(); });加了之后每次代理任务、子代理任务、工具调用都会输出带 trace 的记录。你可以看到完整调用链主代理启动了哪个子代理、传了什么任务、子代理调用了哪些工具、耗时多少、在哪一环失败。这套信息比任何日志都好使。实际排查的时候我最常用的视图是“按任务划分的耗时瀑布”。一眼扫过去就能发现是研究阶段慢还是写作阶段慢还是某个工具调用拖后腿。曾经有一个场景整体响应时间 90% 花在检索工具上给子代理换了一个更快的召回接口后直接缩短了 30 秒。7.2 三个高频问题与对应解法问题一子代理“答非所问”。现象子代理回复的内容看起来正确但格式完全不合规。根因往往在 YAML 的 instructions 没有明确输出协议或者 task 输入里没有提供足够的输出样例。解法在 instructions 里给出一个具体输出样例模型照样例输出的概率会大幅提升。问题二主代理迟迟不调用子代理自己硬干。现象你定义了一堆子代理但主代理绕过它们直接回答。根因通常是 description 写得太笼统主代理认为“自己处理更直接”。解法强化主代理 instructions 里的流程并明确告诫“不要自己执行子任务必须分派”。同时 description 要写得能让主代理一眼判断“这事该给谁”。问题三任务超时整个对话卡死。现象某个子代理一直不结束。根因可能是子代理陷入了自我修正循环或者模型服务本身超时。解法给子任务设置明确的超时时间并训练主代理在超时后走降级路径比如“重试一次不行就明确告诉用户”。我在生产环境里的做法是每个子任务都配上最大执行次数和超时阈值宁可返回“部分成功”也不要无限等待。7.3 日志与审计的额外注意点多代理系统里日志不是越多越好而是越结构化越好。我建议从第一天起就给每条日志打上task_id、agent_name、attempt这几个标签。只有这样才能把分散在多个子代理中的日志串起来。预览版阶段我也吃过日志没有统一 trace id 的亏排查问题时只能靠时间戳猜测先后顺序效率极低。如果你把 Agent Runtime 部署成分布式模式这个问题会更突出因为日志会散落在不同主机上。尽早接入集中式日志平台比如 ELK 或者云原生日志服务会比事后补救省力得多。8. 我的落地体会与接下来的计划从 Single Agent 迁到 SubAgent 模式我最大的感受是架构变轻了心智负担变重了。以前是“一个模型什么都要懂”现在是“每个模型只干一点但你要把边界划清楚”。这个过程很像把一个全能型员工的职责拆成一支小团队——每个人职责更纯粹但团队的默契需要设计。8.1 迁移时最值得注意的三件事先说第一件不要一步到位。哪怕你已经确定最终要用多代理也建议先让系统在单代理模式下跑通再逐步抽离子模块。直接上多代理出问题你都不知道是模型的问题还是链路的问题。第二件子代理的模型选择要分档次。不是所有子代理都要用最强模型。我的经验是“检索类”和“格式化类”的子代理用 gpt-4o-mini 这类小模型完全够只有“决策类”和“终审类”的才值得上大模型。这样一套流水线跑下来token 成本能省 40% 以上。第三件接口契约大于一切。与其花时间调一个子代理的 prompt不如花时间把子代理之间的输入输出格式定死。稳定的接口比聪明的模型更能提升系统整体的可靠性。8.2 后面我打算怎么扩展我现在还在持续关注 MAF 的两个能力一是Agent Runtime 的分布式模式把子代理任务真正分发到多台机器上执行解决单机并发瓶颈二是Long Running Steps让子代理任务可以挂起、等待外部事件、再恢复执行——这个对涉及人工审批的业务流程价值会非常大。Calendars 技能我也在试可以让代理在特定时间点被唤醒执行任务比如每天早上九点自动跑一次“数据汇总 简报生成”这就是 SubAgent 和定时工作流的组合玩法。8.3 一个小建议先手动构造一次“伪多代理”跑通业务如果你暂时不想引入 MAF或者团队还没准备好看 .NET 代码可以先做一个“伪多代理”模拟用代码把任务拆成多个步骤每个步骤调用一次独立的模型 prompt步骤之间传 JSON 数据。把这条链路跑通后再把每一步替换成真正的 SubAgent迁移会顺滑很多。这本质上就是多代理系统的雏形。理解了这个雏形再看 MAF 的 YAML 配置你会发现它不过是在替你处理那些“调度、生命周期、状态共享、失败重试”的枯燥工作。换个角度说MAF 的价值不是发明了多代理而是让多代理从“专家才能玩的东西”变成了“配置就能落地的东西”。如果你是 .NET 技术栈、又恰好被单 Agent 的各种限制折磨过花一个周末把 MAF 的 SubAgent 模式试一遍大概率会打开新思路。