如果你已经在用 Semantic Kernel（后文简称 SK）写“会调用几个插件”的聊天助手，突然发现微软又冒出一个 Agent Framework，并且还一堆 Microsoft.Agents.AI.* 的项目目录正向你招手——此刻的你，也许就像十年前刚理解依赖注入，又被告知“我们要转向函数式”那种微妙心情。别慌，这篇超长、结构化、技术 + 思辨 + 轻幽默的文章，帮你在架构、理念、实现与落地策略上一次分清：它俩不是“谁替代谁”，而是“领域抽象层次与工程化路径的分岔与互补”。

---

摘要（给时间不多但又不想 FOMO 的你）

Semantic Kernel 侧重“模型 + 函数（插件/技能）+ 上下文”组合与意图规划，核心像一个 AI 函数编排与上下文增强内核。Microsoft Agent Framework（以下简称 MAF，为便于指代）则更进一步，把“有能力、有工具、可托管、可互联、可观测”的 智能体（Agent） 作为一级公民，并提供：

1. 统一的 Provider（Azure OpenAI / OpenAI / Azure AI 等）抽象与响应管线。

2. 面向多 Agent / Agent-To-Agent (A2A) 交互的宿主、注册、目录、执行线程与消息存储模型。

3. 工作流（Workflows 与 Declarative Workflows）作为 跨 Agent 的过程性/事件驱动 编排机制，而非单纯“语言模型一次补全 + Planner 生成调用序列”。

4. 标准协议集成（如 Model Context Protocol, MCP），扩大上下文与工具生态接入能力。

5. 工程级 Hosting（本地目录、依赖注入、OpenTelemetry 观测、电梯直达云原生服务化）。

6. A2A Hosting + ASP.NET Core 扩展，支持服务内外协同、多实例、多租户模式探索。

一句话对比：SK 更像“AI 时代的编排内核 + 函数插件引擎”，MAF 更像“多主体智能协作运行时 + 生命周期与可观测基础设施”。如果你要快速给业务加一点 LLM 调味，SK 很顺手；如果你准备把不同职责的智能体拆分、托管、互联、治理、可观测，把它们当“服务角色”，MAF 的抽象更贴合长期演进。

（当然，没有银弹，后文会极其细致地拆。）

---

目录导航

• 背景与生态演进

• 两者定位抽象层级对比

• 源码/项目结构解读（MAF）

• 核心概念映射表（文字矩阵）

• 架构深潜：执行模型、消息流、工具/函数、上下文、工作流

• A2A 与多智能体协作：从“函数调用”跨越到“主体间协商”

• 可观测与治理：OpenTelemetry、事件、线程、存储

• 与 MCP 的整合：上下文边界的再拓展

• 常见应用场景对照（单体增强 vs 多角色系统）

• 典型落地案例设计（5 类）

• 迁移与共存策略（从 SK 渐进走向 MAF）

• 性能、扩展性与工程权衡

• 安全、合规与组织治理切入点

• 面向未来的趋势预测与架构演进猜想

• 实战建议清单（Do / Don’t）

• FAQ 式“灵魂拷问”

• 总结 & 一句箴言版 TL;DR

• 彩蛋：如果它们是两个性格迥异的工程师…

---

一、背景：为什么在已有 Semantic Kernel 后还需要 Agent Framework？

在 AI 应用工程化的演化曲线上，行业其实经历了几个阶段：

1. Prompt 拼接期：直接调用 LLM，手写上下文，体验先行；

2. 函数/插件期：出现“让模型主动调用函数”能力（OpenAI function calling 等），开始把业务 API 暴露为结构化工具；

3. 规划与链式期：出现 Planner / Chain / Graph（如 SK Planner、LangChain Chains），对调用序列进行自动或半自动生成；

4. 多智能体期：从“单大脑 + 工具”转为“多个具有独立角色、记忆、工具、策略的主体”进行协同——本质是软件体系结构的再分层；

5. 运行时与治理期：需要托管、可观测、可靠恢复、跨边界（网络/组织/系统）交互与标准协议整合；

6. 生态互操作期：通过 Model Context Protocol、RAG 数据网格、事件溯源等形成“智能操作系统”式平台。

SK 在 2~3 阶段尤其强势：

• 快速包装 LLM 调用、注入 Memory、使用技能（Plugins）与 Planner 做函数调用序列决策；

• 有明确的 Kernel 作为统一上下文与依赖注册中心。

但当系统要拆分为：内容生成 Agent、合规审查 Agent、数据检索 Agent、执行工具代理、工作流调度 Agent……并要求它们像“服务”一样被注册、发现、互联、监控，这时仅靠 SK 的“函数 + Planner”模型就显吃力——需要一个面向 Agent 生命周期与交互协议的宿主体系。MAF 正是在这个问题空间定位：它不是要替代“函数组合”，而是上升一个抽象层，把“有能力的逻辑单元”提升为“运行时主体”，鼓励消息线程、事件、工作流、A2A 协议式协作。

可以把差异想象成：

• SK：更像 面向开发者的 AI 中间件 / SDK；

• MAF：更像 面向系统架构的多智能体运行时框架。

---

二、定位与抽象层级：概念金字塔对齐

层级	传统软件类比	Semantic Kernel (SK)	Agent Framework (MAF)	核心差异描述
用户交互	Controller / API	Chat Completion 封装	Agent Host + AIAgent	MAF 引入主体身份、管理与消息线程
能力扩展	函数库	Plugins / Skills	Tools（通过 Provider 暴露给 Agent）	命名不同，职责相近，MAF 更强调主体拥有工具集合
调用编排	轻量脚本	Planner（函数序列）	Workflow（事件驱动 / 多 Agent 协作）	Workflow 支持状态、线程、检查点、事件
上下文管理	Context 对象	Kernel Context + Memory	Thread + MessageStore + Events	MAF 更加消息溯源化与可观测
多角色协作	多 Service	不原生（需自建）	A2A 通讯/Hosting	内置 Agent 注册/目录/Host 生命周期
可观测治理	Telemetry / Logging	可接入，但非核心	OTel 集成、Workflow Events	MAF 将其融入设计事件模型
协议互操作	Adapter	（实验性集成）	MCP 等标准接入	MAF 直接以协议作为扩展前提之一

（说明：为防止机械“表格化思维”，本文核心仍是文字阐述，此表仅作快速 mental map。）

抽象层级上，MAF 把时间 + 消息 + 主体三要素转为第一等语言，而 SK 更聚焦上下文 + 函数 + 规划三元组。换句话说：如果你的痛点在“如何让模型正确调用我们十几个 API 并记住用户偏好”，先上 SK；如果你的痛点是“我们希望五个职责不同的智能体组成一个稳态系统并能被监控与动态扩容”，那就该看 MAF。

---

三、源码与项目结构解读（聚焦 MAF）

从仓库结构可以快速嗅到关键模块（这里只归纳逻辑含义，不贴原文）：

• Microsoft.Agents.AI.Abstractions：核心接口与基础模型抽象，保证上层解耦。

• Microsoft.Agents.AI：基础 Agent 能力实现（创建、运行、消息处理）。

• Microsoft.Agents.AI.OpenAI / AzureAI / CopilotStudio：不同模型 / 服务 Provider 适配层，使 Agent 与底层推理服务松耦合。

• Microsoft.Agents.AI.Hosting：本地或服务化托管能力（注册、目录、依赖注入扩展）。

• Microsoft.Agents.AI.Hosting.A2A 与 A2A.AspNetCore：跨 Agent 通讯、服务边界暴露。

• Microsoft.Agents.AI.Workflows：工作流执行线程（WorkflowThread）、事件体系、消息存储、执行器（Executor）。

• Microsoft.Agents.AI.Workflows.Declarative：声明式工作流（可解析 JSON / DSL 形式定义的流）——对应“配置驱动”协作。

• LegacySupport：为早期或兼容层所设，提示演进轨迹。

• Shared：公共工具/常量/内部复用逻辑。

通过搜索可以发现：AIAgentHostExecutor, WorkflowThread, WorkflowMessageStore, LocalAgentCatalog, AgentNames 这些符号代表：

• 每个 Agent 或 Workflow 被包装成独立执行实体；

• 存在“线程式”上下文（Thread），解决多轮消息与状态复原；

• Catalog / Registry 负责命名与发现（支持后续 A2A 调用、外部暴露）。

整体结构展现出运行时 + 托管 + 执行管线 + 协作协议的倾向，而非仅是“客户端 SDK”。

---

四、核心概念映射矩阵（文字展开版）

下面不做死板对号入座，而是说明当你要“从 SK 迁移/对比”时如何脑内换算：

1. Kernel → Agent 宿主生态：SK 的 Kernel 像一个统一容器；在 MAF 中你往往拥有多个 Agent，被 Host / Catalog 管理。没有“一切皆在单核”假设。

2. Skill/Plugin → Agent 的工具集合：二者本质都是把外部能力显式注册给 LLM 调用，但 MAF 更强调工具属于某个主体的“能力域”。

3. Planner → Workflow +（可能的）多 Agent 交互：SK Planner 生成调用序列；MAF Workflow 除序列还可有状态演进、条件分支、事件派发、检查点。

4. Memory → MessageStore（线程化）+ 外部存储整合：MAF 倾向用消息线程 + 事件记录实现“可重放”式上下文，而不是内嵌在 Kernel 的记忆抽象；长期记忆可由你组合外部存储 / RAG。

5. Context Variables → Workflow / Thread 上下文 + 事件数据：语义类似但表达更贴运行时消息模型。

6. Function Calling 适配 → Provider 抽象：MAF 内的 Provider 体系可以挂接不同模型能力（可能含函数调用、JSON 模式输出、工具协商等）。

7. Orchestration Graph（在其他框架中）→ Declarative Workflow：更偏配置化表达，使运维/产品能在不改代码情况下调整协作逻辑。

8. Pipeline Hooks → Telemetry + Events：MAF 把事件对象（Started / Warning / …）作为一等数据流，天然利于观测。

要点：MAF 把一部分在 SK 中“隐式由开发者自行 glue” 的事项（多主体协作、执行上下文线程、消息事件化、服务托管）显式框架化。

---

五、架构深潜：执行模型、线程与消息流

5.1 执行视角类比

在 SK：一次调用往往是 Kernel.InvokeAsync 或 Planner 生成函数序列后依次执行，调用栈主线清晰但多 Agent 协作需自己额外建层。

在 MAF：执行围绕 AgentThread 与 WorkflowThread 展开，消息（包括用户输入、Agent 输出、中间事件）进入 MessageStore。执行器（如 AIAgentHostExecutor）承担调度职责，可能：

1. 读取最新消息集；

2. 调用底层模型 Provider；

3. 解析模型输出（含工具调用意图、结构化结果）；

4. 追加新的消息/事件；

5. 根据 Workflow 定义推进下一步（含分支、并行、回退）。

好处：

• 线程（Thread）= 可重放的上下文快照；

• 事件 = 天然观测节点；

• MessageStore = 类似“事件溯源日志”；

• Executor = 策略可替换点（可插入安全审查、结构校验）。

5.2 状态与检查点

在复杂场景中（长周期、跨 Agent、带审批或多轮检索），需要“可暂停、可恢复、可补偿”。Workflow 的事件与 Thread 结合，使得：

• 可以在事件边界打检查点；

• 崩溃后回放至最近稳定点；

• 支持并行分支合流（未来 Declarative 语义可拓展 graph）。

5.3 消息语义

消息不仅是“用户的 prompt + 模型的文本”，还可能包含：

• 工具调用请求/响应（结构化 JSON）；

• 工作流调度指令（开始、暂停、警告）；

• Agent 间协商（任务委派、结果回传）。

这让 MAF 更接近一个 Domain Event Stream 思维：LLM 输出是事件之一，而非唯一核心。

5.4 对比总结

维度	SK	MAF	影响
调用主线	函数序列执行	线程化事件驱动	更易做恢复/并行
上下文表示	Kernel Context + Memory	MessageStore + Thread	统一溯源，利于观测
多主体	外部自建	原生 A2A	降低协作复杂度
状态检查点	需自实现	设计为可扩展点	长生命周期任务更安全

---

六、工具 / 函数调用：能力暴露方式差异

SK：强调把 .NET / Python 方法包装成“语义函数”或“原子插件函数”，Planner 可基于描述生成调用顺序。函数侧重轻量、快速组合。

MAF：工具更像“Agent 能力域的外在延伸”，通过 Provider 与 Agent 绑定。与其说“调用函数”，不如说“Agent 决策使用自有或可访问工具来解决任务”。

这会带来认知迁移：在 MAF 中你更关心“角色具备何种工具能力集合 + 是否要把调用外包给另一个 Agent”，而不是仅仅一堆平面函数列表。层级思维改变了系统演进的上限。

---

七、A2A（Agent-To-Agent）与多智能体协作价值

很多团队初用 LLM 时，倾向把所有逻辑塞进一个“超级 Prompt + 函数调用”里，结果 prompt 膨胀、上下文成本高、职责散乱。多 Agent 拆分的价值：

1. 职责单一：每个 Agent 可以被更精准微调提示、裁剪上下文。

2. 安全隔离：高风险调用由具备严格策略的执行 Agent 负责。

3. 可扩展：新增“合规审计 Agent”无需改动其他 Agent 的提示语。

4. 资源优化：某些 Agent 使用小模型（如分类/路由），主 Agent 用大模型。

5. 运行时治理：可对特定 Agent 设限流、监控、熔断。

MAF 的 Hosting 与 A2A 模块直接提供：

• Agent 注册（Catalog / Registry）；

• 命名发现（通过名称调用或调度）；

• ASP.NET Core 集成让外部系统可与特定 Agent 通讯；

• 统一生命周期（启动、依赖注入、扩展点）。

与此对比 SK：需要由开发者自行抽象“多个 Kernel / 多个 Planner / 共享上下文”并编写 glue code。复杂度会在规模增长时成几何级数膨胀。

---

八、可观测性与事件：从“日志里翻历史”到“事件即真相”

LLM 应用调试痛点：回答质量下降、幻觉来源、工具调用失败链路难还原。MAF 通过：

• Workflow 事件（Started / Warning / …）；

• MessageStore 保存所有消息片段；

• OpenTelemetry 集成（Tracing / Metrics / Logs）；

• Executor 层便于插桩；

使得 一次任务执行 = 一串结构化事件。这让你能：

1. 回放：重建上下文复现实验。

2. 统计：不同 Agent 的平均响应延迟、失败率。

3. 诊断：哪一步工具调用参数偏移。

4. 风险控制：对异常事件触发熔断或人工介入。

SK 虽然可以手动插入 Telemetry，但它不是默认“事件化、线程化”思路。你需要自建 Envelope，或引入中间 Event Sourcing 层。

---

九、与 Model Context Protocol (MCP) 的整合

MCP 旨在标准化“模型如何安全、结构化地访问外部资源（文件、数据库、工具）”。当多智能体系统需要不断拓展上下文边界（比如接入企业知识库、外部代理网络），统一协议极其重要。

MAF 支持将 MCP 作为第一等扩展途径：

• 你可以把一个 MCP Server 的能力暴露给某个 Agent；

• 或者让特定 Agent 作为 MCP 客户端，动态发现新资源；

• 加速构建“上下文网格”（Context Mesh），减少重复适配。

这降低了“功能插件爆炸”下的维护成本，而不是每接入一个系统都再次写函数签名 + Parser。

---

十、典型应用场景对照

场景	推荐首选	原因	可能的共存方式
简单 FAQ ChatBot + 两三个内部 API	SK	快速、轻量	后期引入单独执行 Agent 作安全审查
文档摘要 + 多步检索 + 结构输出	SK 或 MAF	若仅单主体→SK；需分拆检索/整理→MAF	用 SK 构建检索函数，MAF 主 Agent 调用
多部门流程协调（生成→审批→发布）	MAF	多角色事件流	SK 作为某角色的工具封装层
代码分析（分模块Agent合作）	MAF	并行、多角色、结果合并	SK 内函数为每个模块分析子任务
合规审查 + 日志留痕	MAF	线程化溯源 + OTel	SK 用于补全 + 分类子任务
自然语言驱动 RPA	MAF	需要执行Agent + 监督Agent	SK 提供工具函数层
教学对话 + 动态生成习题	SK	单 Agent 足够	未来复杂教学路径再迁移
数据治理问答（需权限隔离）	MAF	每权限域独立 Agent	SK 为数据检索函数封装

---

十一、五类落地案例设计（简化描述）

11.1 AI 报表工厂

角色：QueryAgent（解析自然语言 → SQL/RAG）、ValidationAgent（校验安全/敏感列）、NarrationAgent（用业务腔调生成描述）。 MAF 用 Workflow：顺序（解析→校验→生成），ValidationAgent 不通过则回退重新询问。 优势：权限隔离 + 可观测 + 审计可回放。

11.2 法务合同初审

角色：ClassifierAgent（识别合同类型）、ClauseCheckAgent（条款扫描）、RiskSummarizer、HumanReview（人工插入点）。 Workflow 可配置：某风险等级直接升级人工。SK 在这里可作为 Clause 检索插件实现快速迭代。

11.3 多模型成本优化调度

角色：RouterAgent（模型路由规则）、CheapModelAgent（小模型粗生成）、RefinerAgent（高质量润色）、JudgeAgent（质量打分）。 好处：分层使用模型降低成本；线程记录用于统计 ROI。SK Planner 可辅助 RouterAgent 的函数策略微调。

11.4 智能代码重构建议

角色：StructureAnalyzer、IssueDetector、RefactorPlanner、PatchGenerator、Reviewer。 每个 Agent 拥有不同上下文窗口需求（Analyzer 可用本地 AST 工具，PatchGenerator 使用函数调用生成 patch JSON）。

11.5 企业知识网关（MCP 驱动）

角色：IndexAgent（构建索引）、AnswerAgent（综合回答）、CitationAgent（生成引用说明）、AuditAgent（合规过滤）。 MCP Server 提供文件/向量数据源，Workflows 控制回答前后处理。

---

十二、迁移与共存策略（渐进式演进路径）

不要“推倒重来”，推荐 4 阶段：

1. 嵌入式：保留现有 SK 项目，新增一个 MAF Host，包装原有 SK 函数为单个工具（Adapter）。

2. 角色拆分：将原大而全 Prompt 拆出 2~3 个职责 Agent（如检索/生成/审查），复用 SK 工具。

3. 工作流化：把跨 Agent 顺序/条件/环路抽象为 Declarative Workflow（JSON/DSL） -> 交给非核心开发人员可配置。

4. 协议化与治理：接入 MCP、OpenTelemetry 仪表板、加入策略（配额/隔离），实现平台化。

实践建议：

• Adapter 模式：写一个包装器把 ISemanticFunction 映射为 MAF Tool；

• 将 Memory（如向量检索）封装为独立 RetrievalAgent，主 Agent 仅发查询请求；

• 利用事件做 AB 实验：不同生成策略写成多个 Agent 版本并行输出，JudgeAgent 评分。

---

十三、性能、扩展性与工程权衡

关注点	SK	MAF	评述
开发启动速度	极快	稍高（需 Host/Agent 定义）	MVP 快速试错 → SK；中长期 → MAF
多角色扩展	手工 glue 放大复杂度	原生支持	扩展临界点是决策节点
观测 & 调试	自行插桩	内建事件/OTel 点位	复杂调度下 MAF 具显著优势
成本优化	需自建路由	可多 Agent 路由/裁剪	MAF 更易插入 RouterAgent
协议互操作	需单独集成	MCP 等融入生态	减少集成重复劳动
学习曲线	低	中	与功能边界宽度成正比

工程实践中一个常见误区：过早全面迁移。如果没有明确多 Agent 协作需求，不必强求引入 MAF；否则会陷入“为了框架而框架”。识别信号：代码里开始出现“Router/审查/生成”几类功能互相污染、Prompt 超长、异常定位困难、函数调用序列经常需要动态调整——这就是上升抽象层的窗口。

---

十四、安全、合规与组织治理切入点

多 Agent 带来的新机会：

• 最小权限原则：执行危险操作（文件写、API 变更）集中于一个受策略网关保护的 ExecutorAgent。

• 审计与留痕：通过 Thread + MessageStore 保留决策链，每一次工具使用具有上下文。

• 策略注入层：在 Executor 级别做输出过滤（PII、敏感术语）。

• 人工介入点：Workflow 里定义“人工审批”事件节点，暂停流等待外部输入。

SK 时代这些往往是程序逻辑里“夹杂 if/else” 的散点；在 MAF 中可转换为结构化节点 + 可配置策略。

---

十五、未来趋势与可能演进

1. Declarative Workflow Graph 化：从线性/简单分支到 DAG / BPMN 式表达，并支持可视化编辑。

2. 语义成本感知调度：通过 OTel Metrics + 成本模型，让 Agent 动态选择模型/参数平衡质量与费用。

3. Memory 网格化：引入跨 Agent 共享的知识总线，支持策略化缓存与访问控制。

4. 多协议互联：MCP + LangChain Agents + 外部工具市场互操作，形成“智能插件网关”。

5. 安全策略 DSL：以声明语义约束某类工具调用频率、数据出境、审查级别。

6. 人机混编团队 IDE：Workflow 中插入人类任务节点（Label、审批），统一编排循环学习闭环。

7. 模型自治调参：Agent 基于历史评分事件自调温度/TopP 等推理参数。

这些趋势多数在 MAF 架构语义中更易落地，因为其事件化、主体化、线程化设计天然支持扩展。SK 未来也可能上探，但定位差异仍会存在：SK 会保持“轻量内核”特性，MAF 走“运行时平台”路线。

---

十六、实战建议清单（Do / Don’t）

Do：

1. 先用 SK 快速验证价值，再识别是否需要多 Agent；

2. 以职责拆分 Agent：用户交互 / 数据检索 / 生成 / 审查 / 评估 / 执行；

3. 引入 Telemetry 早于扩容：先看得见，再跑得快；

4. 把高风险操作隔离为专职 Agent + 严格工具白名单；

5. 利用 Declarative Workflow 让非核心开发者参与配置；

6. 为每类 Agent 编写“提示模板 + 行为准则 + 失败重试策略”；

7. 设计 Judge / Evaluator Agent 实时反馈质量（自动测试文化延伸）。

Don’t：

1. 一开始就为“可能的多 Agent 未来”重构所有；

2. 把所有业务逻辑塞到单 Agent 里期待它“自我反省”；

3. 忽视事件流持久化（丢失可回放性 → 无法复现问题）；

4. 让模型直接调用破坏性工具（缺审查环节）；

5. 在没有指标的情况下主观切换模型；

6. 把 Prompt 当作唯一治理手段（需要结构 + 策略 + 监控）。

---

十七、FAQ 式灵魂拷问

Q1：我已经在 SK 里用 Planner 编排十几个函数了，为什么还要 Workflow？ —— A：当你需要状态暂停 / 回放 / 多角色协同 / 事件驱动扩展（审计、人工介入）时，Workflow 的线程与事件模型会显著降低粘合代码量。

Q2：多 Agent 会不会增加延迟和成本？ —— A：会引入额外消息往返，但可通过路由 Agent 使用小模型、并行化分支、缓存工具结果来抵消。总体是“结构化成本换取可维护性” 的经典工程 trade-off。

Q3：能否只用 MAF 不用 SK？ —— A：可以，但在快速原型期你可能重写一些 SK 现有的插件封装；共存是更常见路径。

Q4：MCP 一定要上吗？ —— A：当你接入来源多、希望标准化上下文资源访问（减少各自写 Adapter）时，它的收益迅速放大；单一数据源阶段可暂缓。

Q5：如何测试多 Agent 系统？ —— A：对线程消息序列做 Snapshot Test；对关键 Agent 输出加入自动评估（JudgeAgent），并将评分事件与生成上下文绑定，形成回归基准。

Q6：有没有“过度工程”警报？ —— A：如果日常修改都集中在 Prompt 调整，且很少出现跨角色冲突 / 审查需求，就暂缓引入多 Agent 架构。

---

十八、总结：一句话 TL;DR

把 Semantic Kernel 看作“让单个智能单元更聪明的函数上下文内核”，把 Agent Framework 看作“让一群各司其职的智能体能协作、可观测、可治理的运行时”。前者让你快，后者让你稳与长远。它们不是对手，是技术曲线不同高度的支点。选型的关键是：你当前的复杂性发生在哪一层——函数内？还是系统间？

---

十九、彩蛋：如果它们是两个工程师…

Semantic Kernel 像那个超能写脚本的全栈小能手：一个下午就能把想法拼成 Demo，递给你说“看，能跑！”；Agent Framework 像资深架构师，桌上贴着一堆系统交互图，对你说“这个得分服务、那块要观测、后面要加审计……”。前者让你心情愉悦地快速试水，后者让你年底复盘时感激当初没有写成一团意大利面。真正成熟的团队，会让他们坐在同一间会议室——一个冲前排迭代，一个在后方搭建长久基座。

---

结尾：行动号召

读完后你可以：

1. 盘点当前项目：是否出现多角色逻辑混杂、Prompt 膨胀？

2. 选一个独立子职责拆成第二个 Agent（例如“合规审查”）。

3. 引入事件记录与基本 Telemetry 看清瓶颈。

4. 试写一个 Declarative Workflow，把人工审批节点插进去。

5. 评估是否需要 MCP 规范化你的外部资源访问。

欢迎将你的多 Agent 实战坑点与改进策略继续分享，生态正处在“最佳实践快速沉淀期”，越早结构化，未来重构成本越低。

祝你的智能体团队排班井然、消息线程永不迷路、成本曲线一路下滑。我们下次再聊“Agent 评估体系与自动纠偏闭环”那点事。

更多AIGC文章