📋 本章概览
| 项目 | 详情 |
|---|---|
| 考试领域 | Plan AI-powered business solutions (25-30%) |
| 预计学习时间 | 3 小时 |
| 难度级别 | ⭐⭐ 中等 |
| 前置知识 | Ch1 Agentic AI 架构概述 |
| 章节类型 | 免费章节 |
⚠️ 考试重点: 本章是"Plan"领域的核心实战章节。考试会给你一个业务场景,让你判断:是否该用 Agent?数据准备好了吗?Build 还是 Buy?ROI 合不合理?这些都是架构师的"第一步"——做错了,后面全白费。
🎯 学习目标
完成本章后,你将能够:
- ✅ 评估 Agent 在任务自动化、数据分析和决策制定中的适用场景
- ✅ 审查 Grounding 数据的五个质量维度
- ✅ 设计数据组织方案使其可被其他 AI 系统访问
- ✅ 运用 Cloud Adoption Framework 规划 AI 采用流程
- ✅ 对 AI 方案进行 ROI 分析(包括 TCO)
- ✅ 使用 Build vs Buy vs Extend 框架做出组件决策
- ✅ 理解 Model Router 的智能路由原理和应用场景
本章知识地图
AI 驱动业务方案需求分析
├── Agent 适用性评估 ──── 任务自动化
│ ├── 数据分析
│ └── 决策制定
│
├── Grounding 数据审查 ── 准确性 (Accuracy)
│ ├── 相关性 (Relevance)
│ ├── 时效性 (Timeliness)
│ ├── 清洁度 (Cleanliness)
│ └── 可用性 (Availability)
│
├── 数据组织策略 ──────── 数据可发现性
│ ├── 跨系统共享
│ └── 安全访问控制
│
├── Cloud Adoption Framework ── AI 采用流程
│ ├── 战略定义
│ └── 能力评估
│
├── ROI 分析 ──────────── TCO 总拥有成本
│ ├── ROI 标准
│ └── 成本效益分析
│
├── Build vs Buy vs Extend ── 决策框架
│ ├── 能力矩阵
│ └── 场景匹配
│
└── Model Router ──────── 智能路由
├── 成本/性能/延迟平衡
└── 多模型策略
🔍 评估 Agent 在业务中的适用性
三大应用领域
AB-100 考试大纲明确要求:"Assess the use of agents in task automation, data analytics, and decision-making(评估 Agent 在任务自动化、数据分析和决策制定中的应用)"。
用一个比喻来理解这三个领域:
想象一家大型零售公司:
- 任务自动化 = 仓库里的智能分拣机器人——重复性工作,按流程干
- 数据分析 = 总部的商业智能分析师——海量数据中找洞察
- 决策制定 = CEO 身边的首席战略顾问——基于洞察给出行动建议
一个优秀的 Agentic AI 方案,往往同时覆盖这三层:自动化执行 + 分析洞察 + 辅助决策。
1. 任务自动化 (Task Automation)
术语:Task Automation with Agents(Agent 驱动的任务自动化)
- 一句话解释:用 AI Agent 自动执行重复性、规则性的业务流程,减少人工干预。
- 考试怎么考:给你一个有大量重复操作的场景(如"每天手动处理 500 张发票"),让你评估是否适合用 Agent 自动化。
- 核心判断标准:高频次 + 规则明确 + 低模糊性 = 适合自动化。
评估框架——FAIR 原则:
| 维度 | 英文 | 评估问题 | 适合自动化的标志 |
|---|---|---|---|
| 频次 | Frequency | 任务多久执行一次? | 每天/每小时/持续执行 |
| 准确性要求 | Accuracy | 能容忍多少错误? | 允许一定错误 + 可自动纠错 |
| 独立性 | Independence | 需要多少人工判断? | 80%+ 步骤可自动化 |
| 重复性 | Repetitiveness | 流程是否标准化? | 有明确 SOP 和规则 |
任务自动化适用性评估矩阵
═══════════════════════════════════════════════════════
高频次
│
┌───────┼────────┐
│ 优先 │ 首选 │
│自动化 │自动化 │ 频次高 + 重复性高 = 最适合
│ │ │
低──┼───────┼────────┼──高 重复性
│ │ │
│ 考虑 │ 评估 │ 频次低 + 重复性低 = 需评估
│保留人工│ ROI │
└───────┼────────┘
│
低频次
═══════════════════════════════════════════════════════
典型自动化场景:
| 场景 | Agent 角色 | 自动化程度 |
|---|---|---|
| 发票处理 | 提取信息 → 匹配 PO → 审批路由 → 入账 | 90%+ |
| 客户咨询分流 | 理解意图 → 分类 → 路由到对应团队 | 85%+ |
| 员工入职流程 | 创建账号 → 分配权限 → 发送欢迎邮件 → 安排培训 | 80%+ |
| 报告生成 | 收集数据 → 分析趋势 → 生成图表 → 分发 | 95%+ |
2. 数据分析 (Data Analytics)
术语:Agent-powered Data Analytics(Agent 驱动的数据分析)
- 一句话解释:用 AI Agent 自主地从海量数据中提取洞察,发现人类难以察觉的模式和趋势。
- 考试怎么考:给你一个数据密集的场景(如"分析 10 万条客户反馈"),让你判断 Agent 如何增强分析能力。
Agent 在数据分析中的四层价值:
Agent 数据分析价值层级
═══════════════════════════════════════════════════════
Level 4: 自主行动 ──── Agent 直接执行优化策略
↑
Level 3: 建议行动 ──── Agent 推荐"应该怎么做"
↑
Level 2: 预测洞察 ──── Agent 预测"会发生什么"
↑
Level 1: 描述分析 ──── Agent 回答"发生了什么"
═══════════════════════════════════════════════════════
| 层级 | 示例 | 对应 Dynamics 365 功能 |
|---|---|---|
| 描述 | "上月客户流失率上升 15%" | Customer Insights 仪表盘 |
| 预测 | "下月 Top 20 高风险流失客户名单" | Copilot for Sales 成交预测 |
| 建议 | "建议对这 20 位客户启动挽留方案" | Copilot for Service 建议 |
| 行动 | 自动发送个性化挽留邮件 + 安排回访 | Autonomous Agent |
3. 决策制定 (Decision-Making)
术语:Agent-assisted Decision-Making(Agent 辅助决策)
- 一句话解释:AI Agent 基于数据分析结果和业务规则,帮助或代替人类做出业务决策。
- 考试怎么考:给你一个需要决策的场景,让你判断 Agent 应该"辅助决策"还是"自主决策"。
- 最易混淆:高风险决策(财务、法律、人事)通常需要 human-in-the-loop,Agent 只做辅助。
决策自主性判断框架:
| 风险级别 | 决策类型示例 | Agent 角色 | Human-in-the-loop |
|---|---|---|---|
| 低风险 | 客服工单分类 | 自主决策 | 否 |
| 中风险 | 采购审批(小额) | 建议 + 自动执行 | 异常时 |
| 高风险 | 信贷审批、合同签署 | 分析 + 建议 | 必须 |
| 极高风险 | 法律合规判断 | 仅提供参考信息 | 必须 |
⚠️ 考试重点: 在评估 Agent 适用性时,考试最常考的判断标准:
- 任务自动化: 看频次和重复性——高频 + 重复 = 适合
- 数据分析: 看数据量和复杂性——大数据 + 多维度 = Agent 优势明显
- 决策制定: 看风险等级——风险越高,Agent 自主性越低,人工参与越多
如果题目问"什么场景最适合 Autonomous Agent",答案通常是低风险 + 高频次 + 高重复性的任务。
这张图展示了微软 AI Agent 采用的四阶段流程:(1) Plan for Agents — 业务计划、技术计划、组织准备、数据架构;(2) Govern and Secure Agents — 负责任 AI、治理安全、环境准备;(3) Build Agents — 单 Agent 和多 Agent 系统构建;(4) Manage Agents — 集成和运维。AB-100 考试的三大领域(Plan / Design / Deploy)与此框架高度对应。
📊 Grounding 数据审查
什么是 Grounding?
术语:Grounding(数据锚定/接地)
- 一句话解释:将 AI 模型的输出"锚定"在可信的、特定的数据源上,使其回答基于事实而非幻觉。
- 形象比喻:像法庭上的证人——不能凭空捏造,每句话都要有证据(数据)支撑。没有 Grounding 的 AI 就像一个"没有参考资料的实习生"——可能说得头头是道,但不一定对。
- 考试怎么考:题干出现"如何减少 AI 幻觉"、"如何确保 Agent 回答准确"时,答案通常指向 Grounding 数据质量。
- 最易混淆:Grounding ≠ Fine-tuning。Grounding 是在推理时提供参考数据;Fine-tuning 是在训练时改变模型权重。

这张图对应 Grounding 的工程实现路径:先检索、再拼接上下文、最后生成回答。考试里凡是“降低幻觉”场景,优先落到这条链路。
数据质量五维度 (ARTCA)
AB-100 考试大纲明确列出了审查 Grounding 数据的五个维度。我们用 ARTCA 来记忆:
Grounding 数据质量五维度 (ARTCA)
═══════════════════════════════════════════════════════
A ─── Accuracy (准确性)
│ "数据是对的吗?"
│
R ─── Relevance (相关性)
│ "数据和问题相关吗?"
│
T ─── Timeliness (时效性)
│ "数据是最新的吗?"
│
C ─── Cleanliness (清洁度)
│ "数据干净吗?有没有噪音?"
│
A ─── Availability (可用性)
"数据能被 Agent 访问到吗?"
═══════════════════════════════════════════════════════
五维度详解
1. Accuracy(准确性)
术语:Data Accuracy(数据准确性)
- 一句话解释:数据内容与现实世界的事实是否一致。
- 形象比喻:像导航地图——如果地图上的路和实际的路不一样,你跟着走只会迷路。
- 考试怎么考:给你一个 Agent 回答不准确的场景,让你分析根因,通常指向 Grounding 数据的准确性问题。
准确性检查清单:
| 检查项 | 具体内容 |
|---|---|
| 数据来源验证 | 数据来自权威、可信的来源? |
| 交叉验证 | 关键数据是否有多个来源交叉验证? |
| 事实核查 | 数字、日期、名称等是否经过核实? |
| 版本控制 | 是否有数据版本管理,能追溯变更? |
2. Relevance(相关性)
术语:Data Relevance(数据相关性)
- 一句话解释:数据与 Agent 要完成的任务或回答的问题是否高度相关。
- 形象比喻:像给厨师备料——你让他做川菜,但给了一堆法餐原料,再好的食材也没用。
相关性优化策略:
| 策略 | 描述 | 示例 |
|---|---|---|
| 领域范围限定 | 只提供与业务场景相关的数据 | 客服 Agent 只访问产品知识库,不访问财务数据 |
| Semantic Chunking | 将长文档按语义切分为有意义的片段 | 把 100 页手册切成按主题组织的片段 |
| Metadata 标注 | 为数据添加元数据,方便 Agent 筛选 | 按部门、产品线、日期标注文档 |
| Relevance Scoring | 对检索结果按相关性评分排序 | Azure AI Search 的相关性评分机制 |
3. Timeliness(时效性)
术语:Data Timeliness(数据时效性)
- 一句话解释:数据是否及时更新,能反映最新的业务状态。
- 形象比喻:像天气预报——用上周的天气预报来决定今天穿什么,必然会出问题。
| 数据类型 | 更新频率要求 | 过时的风险 |
|---|---|---|
| 产品价格 | 实时/每日 | Agent 报错误价格 → 客户投诉 |
| 政策法规 | 即时更新 | Agent 给出违规建议 → 合规风险 |
| 客户信息 | 每日/每周 | Agent 推荐不相关内容 → 体验差 |
| 培训材料 | 每季度/每年 | Agent 回答过时内容 → 信任丧失 |
4. Cleanliness(清洁度)
术语:Data Cleanliness(数据清洁度)
- 一句话解释:数据中是否存在重复、矛盾、格式不一致、缺失值等噪音。
- 形象比喻:像做手术前的消毒——再高明的医生,如果器械没消毒,手术也会出问题。脏数据就是 AI 的"细菌"。
常见数据质量问题:
数据清洁度问题分类
═══════════════════════════════════════════════════════
问题类型 示例 影响
重复数据 ── 同一客户出现 3 条记录 ── Agent 给出矛盾信息
矛盾数据 ── A 文档说"支持退款" ── Agent 回答自相矛盾
B 文档说"不支持退款"
格式不一致 ── 日期混用 "2026-01-01" ── Agent 无法正确解析
和 "01/01/2026"
缺失数据 ── 产品价格字段为空 ── Agent 无法回答关键问题
过时数据 ── 包含已下架产品的说明 ── Agent 推荐不存在的产品
═══════════════════════════════════════════════════════
5. Availability(可用性)
术语:Data Availability(数据可用性)
- 一句话解释:数据是否能被 AI Agent 在需要时及时、安全地访问到。
- 形象比喻:图书馆里有一本绝版好书,但锁在馆长办公室里不让借——再好的数据,Agent 访问不到也没用。
数据可用性设计要素:
| 要素 | 描述 | 微软解决方案 |
|---|---|---|
| 存储位置 | 数据是否在 Agent 可访问的系统中 | Dataverse, SharePoint, Azure SQL |
| API 接口 | 数据是否有标准化的 API 可供调用 | MCP Server, Connectors |
| 访问权限 | Agent 是否有适当的权限读取数据 | Entra ID, RBAC |
| 性能延迟 | 数据查询的响应时间是否满足要求 | Azure AI Search, 缓存 |
| 可靠性 | 数据源的 SLA 是否满足业务需求 | 高可用部署, 冗余 |
⚠️ 考试重点: Grounding 数据质量五维度是高频考点。考试常见题型:
- 给你一个 Agent 回答不正确的场景 → 分析是五个维度中的哪个出了问题
- 给你一个数据源 → 评估是否适合作为 Grounding 数据
记忆口诀:ARTCA("Art + CA")= Accuracy, Relevance, Timeliness, Cleanliness, Availability
📦 组织业务数据供 AI 系统使用
为什么数据组织很重要?
AB-100 考试大纲要求:"Organize business solution data to be available for other AI systems(组织业务方案数据使其可被其他 AI 系统使用)"。
用一个比喻来理解:
想象你有一个巨大的仓库,堆满了货物。如果没有分类、没有标签、没有通道,即使货物再值钱,也找不到。数据组织就是给你的"数据仓库"做分类、贴标签、修通道的过程。
数据组织三层架构
数据组织三层架构
═══════════════════════════════════════════════════════════════
┌─────────────────────────────────────────────────────────────┐
│ 数据消费层 (Consumption) │
│ │
│ Copilot Studio Microsoft Foundry Dynamics 365 M365 │
│ Agent Agent Copilot Copilot │
│ ▲ ▲ ▲ ▲ │
├─────┼─────────────────┼──────────────────┼─────────────┼────┤
│ │ 数据服务层 (Services) │ │ │
│ │ │ │ │
│ ┌──┴──────────┐ ┌────────────────┐ ┌─┴──────────┐ │ │
│ │ Azure AI │ │ Microsoft │ │ Dataverse │ │ │
│ │ Search │ │ Graph API │ │ API │ │ │
│ │ (语义搜索) │ │ (Office 数据) │ │ (业务数据) │ │ │
│ └──┬──────────┘ └────────┬───────┘ └─┬──────────┘ │ │
│ │ │ │ │ │
├─────┼──────────────────────┼────────────┼─────────────┼────┤
│ │ 数据存储层 (Storage) │ │ │
│ │ │ │ │
│ ┌──┴──────────┐ ┌────────┴───────┐ ┌─┴──────────┐ │ │
│ │ Azure Blob │ │ SharePoint │ │ Dataverse │ │ │
│ │ Storage │ │ Online │ │ Tables │ │ │
│ │ Azure SQL │ │ OneDrive │ │ │ │ │
│ └─────────────┘ └────────────────┘ └────────────┘ │ │
│ │ │
└───────────────────────────────────────────────────────┘────┘
数据组织最佳实践
| 实践 | 描述 | 为什么重要 |
|---|---|---|
| 统一数据模型 | 使用 Dataverse 或 Common Data Model 统一数据格式 | Agent 不需要学多种数据格式 |
| Metadata 标注 | 为每份数据添加创建者、日期、部门、权限等元数据 | Agent 可以按条件筛选数据 |
| 语义索引 | 使用 Azure AI Search 创建语义索引 | Agent 通过自然语言就能找到数据 |
| 权限继承 | 数据访问权限与组织权限体系一致 | Agent 只能看到用户有权限的数据 |
| 版本管理 | 数据变更有版本记录和回滚能力 | 出问题时能追溯和恢复 |
| 数据目录 | 建立企业级数据目录(如 Microsoft Purview) | 让所有 AI 系统都能"发现"数据 |
⚠️ 考试重点: 考试经常问"如何让多个 AI 系统共享数据"。核心答案是:
- 使用 Dataverse 作为统一数据平台(Dynamics 365 + Power Platform 原生支持)
- 使用 Azure AI Search 提供语义检索能力
- 使用 Microsoft Graph API 访问 Microsoft 365 数据
- 通过 MCP 标准化工具和数据访问接口
☁️ Cloud Adoption Framework - AI 采用流程
CAF 概述
术语:Cloud Adoption Framework (CAF)
- 一句话解释:微软提供的结构化框架,指导组织如何系统地采用云服务和 AI 技术。
- 形象比喻:像"搬家指南"——从"要不要搬"(战略)到"搬去哪"(规划)到"怎么搬"(实施)到"搬完怎么住"(治理),每一步都有清单。
- 考试怎么考:题干出现"组织如何系统地采用 AI"、"AI 转型路线图"时,选 Cloud Adoption Framework。
AI 采用流程七步法
这张图来自微软官方 Cloud Adoption Framework 文档,展示了 AI 采用的结构化流程:从 AI Strategy(战略)到 AI Plan(规划)到 AI Ready(准备),再到 Govern AI(治理)、Manage AI(管理)和 Secure AI(安全)。考试中出现 "组织如何系统地采用 AI" 相关题目时,直接联想这个框架。
Cloud Adoption Framework - AI 采用流程
═══════════════════════════════════════════════════════════════
Step 1 Step 2 Step 3 Step 4
Strategy Plan Ready Adopt
(战略) (规划) (准备) (采用)
├── Innovate
└── Migrate
│ │ │ │
▼ ▼ ▼ ▼
Step 5 Step 6 Step 7
Secure Manage Govern
(安全) (管理) (治理)
═══════════════════════════════════════════════════════════════
←──────── 持续迭代和优化 ────────→
AI Strategy(AI 战略定义)
AI 战略是 CAF 的第一步,也是 AB-100 最常考的 CAF 内容。
AI 战略三要素:
| 要素 | 英文 | 描述 | 示例 |
|---|---|---|---|
| 目标 | Goal | 你想通过 AI 实现什么大方向? | "用 AI 提升客户服务体验" |
| 目的 | Objective | 具体想达到什么可衡量的结果? | "将首次响应时间从 24h 降到 2h" |
| 成功指标 | Success Metric | 怎么知道做到了? | "客户满意度 CSAT 从 3.5 提升到 4.5" |
⚠️ 考试重点: 考试经常考 Goal vs Objective vs Success Metric 的区别:
- Goal = 方向(定性的)
- Objective = 目标(具体的、可衡量的)
- Success Metric = 指标(数字化的衡量标准)
秒判法:看描述是否有数字。有数字 = Metric;有具体行动 = Objective;纯方向性 = Goal。
AI 就绪度评估
在制定战略之后,组织需要评估自身的 AI 就绪度:
| 评估维度 | 评估内容 | 关键问题 |
|---|---|---|
| 数据就绪 | 数据质量、可用性、治理 | 数据是否满足 ARTCA 五维度? |
| 技术就绪 | 基础设施、计算资源、网络 | 是否有足够的 Azure 资源? |
| 组织就绪 | 团队技能、变革管理、领导支持 | 是否有 AI 架构师和工程师? |
| 治理就绪 | 安全策略、合规框架、审计机制 | 是否有 Responsible AI 框架? |
| 财务就绪 | 预算、ROI 模型、成本控制 | 是否有 AI 投资的预算审批? |
三种 AI 消费模式
CAF 定义了三种 AI 消费模式,与考试中的 "Build vs Buy vs Extend" 决策密切相关:
| 模式 | 英文 | 描述 | 微软对应方案 | 技术门槛 |
|---|---|---|---|---|
| 即用型软件 | Ready-to-use (SaaS) | 直接使用预构建的 AI 功能 | Dynamics 365 Copilot, M365 Copilot | ⭐ 最低 |
| 可扩展平台 | Extensible (PaaS) | 在平台上扩展和定制 AI | Copilot Studio, Power Platform | ⭐⭐ 中等 |
| 完全管理基础设施 | Fully managed (IaaS) | 从底层构建自定义 AI | Microsoft Foundry, Azure OpenAI | ⭐⭐⭐ 最高 |
AI 消费模式选择
═══════════════════════════════════════════════════════════
控制程度低 控制程度高
简单快速 灵活复杂
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ SaaS 即用 │ ←→ │ PaaS 扩展 │ ←→ │ IaaS 构建 │
│ │ │ │ │ │
│ D365 Copilot│ │Copilot Studio│ │ Foundry │
│ M365 Copilot│ │Power Platform│ │ Azure OpenAI│
└─────────────┘ └─────────────┘ └─────────────┘
Buy (购买) Extend (扩展) Build (构建)
═══════════════════════════════════════════════════════════
⚠️ 考试重点: CAF 中的三种 AI 消费模式直接对应 Build vs Buy vs Extend 决策。考试会给你一个组织场景(技术能力、预算、时间约束),让你选择最合适的模式。
💰 ROI 分析
为什么要做 ROI 分析?
术语:ROI Analysis for AI Solutions(AI 方案 ROI 分析)
- 一句话解释:系统化地评估 AI 投资的成本和收益,确保投资回报合理。
- 形象比喻:像买房前的财务规划——不只看房价(投入),还要看租金回报、增值潜力(收益),以及物业费、维修费(持续成本)。
- 考试怎么考:给你一个 AI 方案,让你识别 TCO 组成部分,或判断 ROI 计算中应包含哪些因素。
Total Cost of Ownership (TCO)
术语:TCO(总拥有成本)
- 一句话解释:AI 方案在整个生命周期中的所有成本总和,不只是初始投入。
AI 方案 TCO 构成
═══════════════════════════════════════════════════════════
初始成本 (One-time) 持续成本 (Ongoing)
┌─────────────────────┐ ┌─────────────────────────┐
│ ● 平台许可证购买 │ │ ● Azure 计算/存储月费 │
│ ● 开发和集成费用 │ │ ● AI 模型 API 调用费用 │
│ ● 数据迁移和清洗 │ │ ● 运维团队人力成本 │
│ ● 培训和变革管理 │ │ ● 模型监控和调优 │
│ ● 安全合规审计 │ │ ● 数据更新和维护 │
│ ● 概念验证 (PoC) │ │ ● 许可证续费 │
└─────────────────────┘ └─────────────────────────┘
隐性成本 (Hidden)
┌─────────────────────────────────────────────────────────┐
│ ● 组织变革中的生产力损失 ● 技术债务和迁移成本 │
│ ● Agent 错误导致的业务损失 ● 安全事件的潜在成本 │
│ ● 人才招聘和留存成本 ● 合规违规的罚款风险 │
└─────────────────────────────────────────────────────────┘
═══════════════════════════════════════════════════════════
ROI 标准和计算
AI 方案的 ROI 评估维度:
| 维度 | 收益类型 | 衡量指标示例 |
|---|---|---|
| 效率提升 | 定量 | 处理时间减少 X%、人工干预减少 Y% |
| 成本节约 | 定量 | 年省 $X 人力成本、减少 $Y 错误成本 |
| 收入增长 | 定量 | 客户转化率提升 X%、追加销售增长 Y% |
| 客户体验 | 定性→定量 | NPS 提升 X 分、CSAT 提升 Y% |
| 员工满意度 | 定性 | 重复性工作减少、专注高价值任务 |
| 风险降低 | 定性→定量 | 合规违规减少 X%、安全事件减少 Y 次 |
| 创新加速 | 定性 | 新功能上线速度、决策速度 |
ROI 计算公式:
(收益总额 - 投资总额)
ROI = ─────────────────────── × 100%
投资总额
示例:
年度收益:$500,000(效率提升 + 成本节约 + 收入增长)
年度成本:$200,000(平台费用 + 运维 + 人力)
初始投资:$300,000(开发 + 集成 + 培训)
第一年 ROI = (500,000 - 200,000 - 300,000) / 500,000 × 100% = 0%
第二年 ROI = (500,000 - 200,000) / 500,000 × 100% = 60%
第三年 累计 ROI = (1,500,000 - 600,000 - 300,000) / 900,000 × 100% = 67%
⚠️ 考试重点: ROI 分析考试考点:
- TCO 不只是平台费用——要包含人力、培训、数据准备、运维等全部成本
- AI 方案的收益不只是"省钱"——效率提升、收入增长、风险降低都要计入
- ROI 通常需要 6-18 个月才能转正——考试可能问"第一年 ROI 为负是否正常"
- 隐性成本(组织变革、技术债务)容易被忽略——考试喜欢考这个
🏗️ Build vs Buy vs Extend 决策框架
三种选择
术语:Build vs Buy vs Extend(构建 vs 购买 vs 扩展)
- 一句话解释:对于 AI 方案中的每个组件,决定是从零构建、直接购买现成方案,还是在现有平台上扩展。
- 形象比喻:像装修房子——Build 是请施工队从毛坯房开始全部定制装修,Buy 是买精装修的二手房直接入住,Extend 是买半精装然后自己改造不满意的部分。
这张决策树来自微软 Cloud Adoption Framework,展示了完整的 AI Agent 技术选型流程:首先判断 SaaS Agent 是否满足需求(Buy),不满足则进入 Build 分支,根据技术能力和需求选择 Copilot Studio(低代码)、Microsoft Foundry(全代码)或 GPU/容器(自定义基础设施)。这与考试中 Build vs Buy vs Extend 决策题直接对应。
决策矩阵
| 维度 | Build(构建) | Buy(购买) | Extend(扩展) |
|---|---|---|---|
| 适用场景 | 独特需求,市场无对应产品 | 通用需求,有成熟产品 | 大部分需求已覆盖,需小量定制 |
| 开发成本 | 高 | 低 | 中 |
| 上线时间 | 长(3-12 个月) | 短(天到周) | 中(周到月) |
| 定制灵活性 | 完全灵活 | 受限 | 中等 |
| 维护负担 | 完全自己维护 | 供应商维护 | 共享维护 |
| 技术要求 | 需要专业 AI 团队 | 低 | 中等 |
| 微软对应 | Microsoft Foundry 自定义开发 | D365 Copilot / M365 Copilot | Copilot Studio 扩展 |
| 一句话记忆 | "毛坯房全定制" | "精装房直接住" | "半精装自己改" |
决策流程
Build vs Buy vs Extend 决策树
═══════════════════════════════════════════════════════════
需求是否与现有微软产品高度匹配?
│
├── YES → 现有功能是否 100% 满足需求?
│ │
│ ├── YES → 直接 Buy (购买)
│ │ 用 D365 Copilot / M365 Copilot
│ │
│ └── NO → Extend (扩展)
│ 用 Copilot Studio 定制
│ 或 D365 AI + Power Platform
│
└── NO → 组织是否有专业 AI 开发能力?
│
├── YES → 时间是否充裕?预算是否充足?
│ │
│ ├── YES → Build (构建)
│ │ 用 Microsoft Foundry
│ │
│ └── NO → 先 Buy/Extend,再逐步 Build
│
└── NO → 考虑 Buy + 培养团队
或找合作伙伴帮助 Build
═══════════════════════════════════════════════════════════
场景速选
| 业务场景 | 决策 | 理由 |
|---|---|---|
| 需要 CRM 中的邮件摘要功能 | Buy | D365 Copilot for Sales 原生支持 |
| 需要定制客服 Agent 的对话流程 | Extend | Copilot Studio 扩展主题和动作 |
| 需要垂直行业的专有 AI 模型 | Build | 市场上没有现成方案 |
| 需要在 Teams 中查询内部知识库 | Extend | M365 Copilot + 知识源扩展 |
| 需要训练行业专属的 SLM | Build | 需要 Fine-tune 自定义模型 |
| 需要自动化审批流程 | Extend | Power Automate + AI Builder |
⚠️ 考试重点: Build vs Buy vs Extend 是高频考题。考试的标准答案倾向于:
- 优先 Buy → 如果微软已有产品满足需求
- 其次 Extend → 如果需要小量定制
- 最后 Build → 只有在独特需求且有能力时才构建
考试偏好"最低复杂度"原则——能用简单方案解决的,不选复杂方案。
🔀 Model Router:智能模型路由
什么是 Model Router?
术语:Model Router(模型路由器)
- 一句话解释:一个智能中间层,根据请求的特征(复杂度、成本敏感度、延迟要求)自动将请求路由到最合适的 AI 模型。
- 形象比喻:像医院的分诊台——感冒去普通门诊(小模型、低成本),疑难杂症去专家门诊(大模型、高精度),急救去 ICU(专用模型、最快响应)。不需要所有病人都看专家。
- 考试怎么考:题干出现"优化模型使用成本"、"不同任务使用不同模型"、"平衡成本和质量"时,选 Model Router。
- 最易混淆:Model Router 不是一个具体的模型,而是一个路由/编排层。
为什么需要 Model Router?

这张图对应 Model Router 的落地视角:请求进入统一入口后再按策略分发到不同模型。考试里看到“统一入口 + 多模型分流 + 成本优化”通常就是在考路由层设计。
没有 Model Router 有 Model Router
═══════════════════ ═══════════════════
所有请求 → GPT-4o 简单查询 → Phi-4 (SLM)
(贵、慢但强大) 成本: $
成本: $$$$ 普通对话 → GPT-4o-mini
延迟: 高 成本: $$
所有任务用同一个模型 复杂推理 → GPT-4o
= 简单任务被"杀鸡用牛刀" 成本: $$$
= 成本浪费
代码生成 → Claude Opus 4.6
成本: $$$
平均成本: $$ (节省 40-60%)
每个任务匹配最佳模型
Model Router 路由策略
| 路由维度 | 描述 | 路由逻辑 |
|---|---|---|
| 任务复杂度 | 请求的推理难度 | 简单查询 → SLM;复杂推理 → LLM |
| 成本敏感度 | 预算约束 | 成本敏感 → 小模型;质量优先 → 大模型 |
| 延迟要求 | 响应时间要求 | 实时交互 → 低延迟模型;批量处理 → 高精度模型 |
| 数据安全 | 数据敏感度 | 高敏感 → 私有部署模型;一般 → 云端 API |
| 专业领域 | 任务所属领域 | 代码 → 代码专用模型;医疗 → 医疗 Fine-tuned 模型 |
在微软生态中的实现
| 平台 | Model Router 能力 |
|---|---|
| Microsoft Foundry | Model Catalog 支持 1600+ 模型,可通过策略配置路由规则 |
| Copilot Studio | 支持在 Topic 级别选择不同的 AI 模型 |
| Azure OpenAI Service | 支持多模型部署,可通过 API 管理层实现路由 |
Model Router 架构示例:
Model Router 架构
═══════════════════════════════════════════════════════════
用户请求
│
▼
┌────────────────┐
│ Model Router │
│ (智能路由层) │
│ │
│ ● 分析请求特征 │
│ ● 匹配路由规则 │
│ ● 选择最优模型 │
└───────┬────────┘
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Phi-4 │ │ GPT-4o │ │ Claude │
│ (SLM) │ │ mini │ │ Opus │
│ │ │ │ │ │
│ 简单查询 │ │ 一般对话 │ │ 复杂推理 │
│ FAQ │ │ 摘要生成 │ │ 代码生成 │
│ 分类 │ │ 翻译 │ │ 架构设计 │
│ │ │ │ │ │
│ 成本: $ │ │ 成本: $$ │ │ 成本: $$$│
│ 延迟: 低 │ │ 延迟: 中 │ │ 延迟: 高 │
└──────────┘ └──────────┘ └──────────┘
═══════════════════════════════════════════════════════════
⚠️ 考试重点: Model Router 考试考点:
- 核心目的是平衡成本和质量——不是所有任务都需要最强的模型
- 路由维度包括:复杂度、成本、延迟、安全、领域
- 与 AB-100 考纲中的 "implement a model router to intelligently route requests" 直接对应
- 考试可能问"如何降低 AI 方案的运营成本"——答案之一就是 Model Router
📝 综合场景演练
场景 1: 零售公司客户服务 AI 方案评估
背景: 一家澳洲零售公司每天收到 2000+ 客户咨询(邮件 + 在线聊天)。目前全靠 30 人的客服团队手动处理。公司已使用 Dynamics 365 Customer Service。
问题: 如何评估是否应该引入 AI Agent?
分析步骤:
| 步骤 | 评估内容 | 结论 |
|---|---|---|
| 1. 任务自动化适用性 | 频次高(2000+/天)+ 重复性强(常见问题占 70%) | 非常适合 |
| 2. 数据就绪度 | 已有 D365 客户数据 + 产品知识库 → 检查 ARTCA | 数据基础好 |
| 3. Build vs Buy vs Extend | 已有 D365 → Copilot for Service 原生支持 | Extend |
| 4. ROI | 预计可自动处理 60% 咨询 → 减少 18 人工作量 | ROI 显著 |
| 5. 风险评估 | 客服场景低风险 → 可使用 Autonomous Agent | 风险可控 |
推荐方案: Extend Dynamics 365 Copilot for Service + Copilot Studio 定制化 Agent
场景 2: 金融机构贷款审批 AI 方案评估
背景: 一家银行想用 AI Agent 自动化贷款审批流程。涉及客户信用评估、风险定价和合规检查。
问题: Agent 的自主性级别应该怎么设计?
分析步骤:
| 步骤 | 评估内容 | 结论 |
|---|---|---|
| 1. 风险级别 | 金融决策 → 高风险 | 必须 human-in-the-loop |
| 2. 合规要求 | 金融监管严格 → 审计追踪必须 | Agent 辅助决策,人工最终审批 |
| 3. Agent 类型 | 需要多步骤(收集资料→评估→定价→合规检查) | Task Agent + 人工审批节点 |
| 4. 数据 Grounding | 信用数据 → 高准确性要求;法规数据 → 高时效性要求 | ARTCA 严格审查 |
| 5. Model Router | 简单查询用 SLM;信用评估用专业模型 | 需要 Model Router |
推荐方案: Task Agent(L2 半自主)+ 关键决策节点必须人工审批 + 完整审计追踪
场景 3: 快速选择题
| 场景 | 答案 | 秒判理由 |
|---|---|---|
| "需要评估 AI 数据是否最新" | Timeliness | ARTCA 中的 T |
| "Agent 回答包含过时的产品信息" | 数据时效性 + 清洁度问题 | 过时数据未清理 |
| "如何降低 AI API 调用成本" | Model Router | 智能路由匹配合适模型 |
| "组织如何系统性地引入 AI" | Cloud Adoption Framework | CAF AI 采用流程 |
| "自定义 Agent 还是用 D365 自带的" | Build vs Buy vs Extend | 先看现有产品能否满足 |
| "AI 方案总共要花多少钱" | TCO 分析 | 包含初始+持续+隐性成本 |
| "Agent 需要访问 SharePoint 文档" | Data Availability + MCP/Graph API | 数据可用性 + 接口设计 |
⚡ 30 秒答题框架
遇到"需求分析"相关场景题时,按这四步走:
第一步:评估 Agent 适用性
| 关键词 | 判断 |
|---|---|
| 高频 + 重复 + 规则明确 | 适合自动化,优先考虑 Agent |
| 低频 + 高度创意 + 模糊规则 | 不适合完全自动化 |
| 高风险决策 | Agent 辅助 + 人工最终决策 |
第二步:审查数据质量
| 问题 | 对应维度 |
|---|---|
| 数据是对的吗? | Accuracy |
| 数据和任务相关吗? | Relevance |
| 数据是最新的吗? | Timeliness |
| 数据干净吗? | Cleanliness |
| Agent 能访问到数据吗? | Availability |
第三步:选择实现路径
| 条件 | 选择 |
|---|---|
| 微软产品原生支持 | Buy |
| 需要小量定制 | Extend |
| 独特需求 + 有技术能力 | Build |
第四步:验证 ROI
| 检查项 | 要点 |
|---|---|
| TCO 是否完整? | 初始 + 持续 + 隐性成本全算了吗? |
| 收益是否可量化? | 效率提升、成本节约、收入增长都算了吗? |
| 回收周期合理吗? | AI 方案通常 6-18 个月回收 |
⚠️ 常见错误
1. 只关注技术,忽略业务价值
- ❌ 错误: "这个场景可以用最新的 GPT-4o 模型来解决"
- ✅ 正确: 先问"这个场景是否真的需要 AI",再问"用哪个模型最合适"
秒判口诀:先问 Why(为什么需要 AI),再问 How(怎么实现)。
2. Grounding 数据只关注准确性
- ❌ 错误: "数据是对的就够了"
- ✅ 正确: 数据需要同时满足 ARTCA 五个维度——准确但过时的数据同样会导致问题
3. 所有任务都用最强的模型
- ❌ 错误: "全部用 GPT-4o 就不会出错"
- ✅ 正确: 使用 Model Router,简单任务用 SLM 降低成本,复杂任务才用大模型
4. 低估隐性成本
- ❌ 错误: TCO = 平台许可费 + Azure 计算费
- ✅ 正确: TCO 还包括人力培训、数据准备、变革管理、运维、安全合规等隐性成本
5. Build vs Buy 选择过于激进
- ❌ 错误: "我们团队技术很强,全部自己 Build"
- ✅ 正确: 优先 Buy/Extend,只在真正需要差异化的地方 Build
AB-100 考试倾向于"最低复杂度"原则——能用现成的就不要自己造。
6. 高风险场景赋予过高自主性
- ❌ 错误: 让 AI Agent 自主决定贷款审批
- ✅ 正确: 高风险决策必须有 human-in-the-loop
🧠 高频关键词速配
| 题干关键词 | 优先联想 | 常见干扰项 |
|---|---|---|
| 数据准确/过时/矛盾 | Grounding 数据质量 (ARTCA) | 模型选择问题 |
| 组织如何引入 AI | Cloud Adoption Framework | 直接开始 Build |
| 降低 AI 运营成本 | Model Router + SLM | 减少功能 |
| 投资回报 / 成本效益 | ROI + TCO 分析 | 只看技术可行性 |
| 现有 D365 增强 AI | Buy 或 Extend | Build 全新方案 |
| 自定义行业模型 | Build (Microsoft Foundry) | 用通用模型 |
| 数据无法被 Agent 访问 | Availability (可用性) | Accuracy |
| Agent 回答有幻觉 | Grounding 数据不足 | 模型太小 |
| 多个 AI 系统共享数据 | 数据组织 + Dataverse + MCP | 各自维护数据 |
| 平衡模型成本和质量 | Model Router | 只用一个模型 |
| 高风险 + 自动化决策 | Human-in-the-loop | Autonomous Agent |
| Goal vs Objective vs Metric | CAF AI Strategy 三要素 | 混为一谈 |
✅ 复习检查清单
- 能说出 Agent 在三大领域的适用场景和评估标准
- 能用 ARTCA 记忆法列出 Grounding 数据的五个质量维度
- 能解释每个质量维度的含义并举出具体例子
- 能描述数据组织三层架构(存储层→服务层→消费层)
- 能说出 Cloud Adoption Framework AI 采用七步流程
- 能区分 AI Strategy 中的 Goal、Objective 和 Success Metric
- 能进行基本的 ROI 计算,知道 TCO 的完整构成
- 能用 Build vs Buy vs Extend 决策树选择实现路径
- 能解释 Model Router 的作用和路由维度
- 能完成综合场景分析,给出合理的方案推荐
📚 参考资源
官方文档
| 资源 | 链接 |
|---|---|
| AB-100 考试指南 | Study Guide for AB-100 |
| Cloud Adoption Framework - AI | AI adoption |
| CAF - AI 规划 | Plan for AI adoption |
| CAF - AI 战略 | Create your AI strategy |
| CAF - AI Agent 采用指南 | AI Agent Adoption Guidance |
| Microsoft Foundry 文档 | Microsoft Foundry |
| Foundry Agent Service | What is Foundry Agent Service? |
| Azure AI Search | Azure AI Search |
| Dataverse 文档 | Microsoft Dataverse |
学习路径
| 资源 | 说明 |
|---|---|
| Microsoft Learn: AB-100 | 官方自学路径 |
| Power Platform Well-Architected | Power Platform 架构指南 |
| Responsible AI | 负责任 AI 原则 |