相关技术
Microsoft 365 Copilot
Copilot Studio
Azure AI Foundry
GitHub Copilot
Azure Open Al
相关技术
Microsoft 365
Microsoft 365 Teams and Teams Phone
Microsoft 365 移动和安全套件
Microsoft Azure
Microsoft Entra ID
Microsoft Security
相关技术
NovaFlow BPM引擎
Microsoft Dynamics 365 BC
Microsoft Dynamics 365 CRM
Microsoft Power Apps
Microsoft Power Automate
Microsoft Power BI
相关技术
诺未服务中心
诺未支持团队
ITIL运维工具
Copilot Studio 的边界与突破：AI Agents Hackathon 冠军背后的多智能体架构实践
30
2026-07-30
2025 年「Eva」在微软中国区 Copilot AI 创新大赛拿了第一名，2026 年「Sales Deal Mate」在 Frontier Agentic Hackathon 又拿了智胜全能金奖。很多人问：你们是不是 prompt 写得特别好？
不是。真正的护城河在四层：A2A 多智能体编排、四阶段数据管线、Entra→Snowflake 权限复刻、Skill Engine 自进化规则引擎。这篇文章把架构、管线、SQL、技术选型全部拆开讲。
一、A2A 多智能体架构：为什么 Agent 调 Agent，不是 Tool 调 Tool
先看架构全貌。Sales Deal Mate 在 Microsoft Teams 中部署了 1 个主控 Agent + 4 个专属子 Agent：
1.1 Agent-to-Agent（A2A），不是 Tool-to-Tool
这是整个架构最核心的设计决策。
传统做法（Tool-to-Tool）：把每个功能封装成 REST API，由一个中央调度器按 if-else 或状态机调用。问题是：每次新增能力，调度器的路由逻辑都要改。三个子模块还行，十个就变成意大利面条。
我们的做法（Agent-to-Agent）：在 Copilot Studio 的可视化编排画布上，主控 Agent 像"技术主管"一样调度子 Agent，只管"谁擅长什么"，不关心内部实现。子 Agent 之间也可以互相调用——比如 KA Agent 发现客户近期有招标公告，可以直接触发 Tender Agent 的扫描任务。
⚠️ 注意：以上是逻辑示意。实际编排在 Copilot Studio 的低代码画布中完成，不是手写 JS。
1.2 为什么选 Copilot Studio 而非 LangChain/LlamaIndex？
这是每次分享都会被问到的问题。我们的决策逻辑：
|
维度
|
Copilot Studio
|
LangChain/LlamaIndex
|
|
企业身份集成
|
Entra ID 原生对接，零配置
|
需要自己接 OAuth/OIDC
|
|
Teams 集成
|
Adaptive Card 原生输出
|
需要自建 Bot + Bot Framework
|
|
多 Agent 编排
|
可视化 Agent Flow，非技术人员可维护
|
Python 代码，需要开发者维护
|
|
客户运维
|
客户 IT 团队无需 Python 技能
|
客户需要招懂 AI 框架的人
|
结论：这是给企业客户的交付项目，不是内部工具。可维护性 > 技术炫技。
二、四阶段数据管线：从 RFP 的 312 页到 47 条结构化评分
RFP Agent 是整个项目最重的一个子 Agent。它的任务是：用户上传一份 312 页的 PDF 标书 → Agent 解析出所有需求 → 逐条与应答书对照评分 → 给出修订建议。
技术难点就一个：标书不是纯文本，是表格、图章、手写批注、合并单元格的大杂烩。
管线分四步走：
Stage 1 — 原始文档解析 (Ingest)
这里有一个工程细节值得说：Azure Document Intelligence 默认不支持 "技术规格章节" 的语义识别。我们针对客户标书的版式特征（固定字体、固定缩进层级、固定编号规则），训练了一个轻量的自定义模型，准确率从 72% 提高到 94%。
Stage 2 — 语义切片 + 向量化 (Chunk)
为什么不按固定 token 窗口切？因为标书的结构性太强——「第三章 技术要求」和「第四章」，语义断点非常明确。如果按 512-token 固定窗口硬切，一条完整的技术需求可能被切成两半。section-aware chunking 的语义完整性大幅提升，代价是为每个文档类型维护一份章节边界配置文件。
Stage 3 — 混合检索 (Retrieve)
这是召回质量最关键的一步：
为什么不用纯向量检索？因为标书中有大量术语精确匹配的需求，比如 "ISO 50001"、"Niagara Framework"、"BACnet/IP"，这些术语即便语义空间里距离不远，但我们不能依赖语义近似去"猜"，必须精确命中。
BM25 解决了精确匹配，向量解决了语义匹配，Cross-Encoder 做最终仲裁。三管齐下，NDCG 达到 0.91。
Stage 4 — 应答判分 (Score)
判断分 Prompt 的设计原则是：不允许模型只说"满足"，必须引用标书原文中的页码和段落作为证据。 这让评分结果可审计——你随时可以回到标书原文档验证每一个判断。
三、Entra → Snowflake 权限复刻：数据不出微软生态
企业级 AI 项目最大的坎不是模型，是安全合规。客户的第一反应永远是："我的客户数据会不会被 AI 模型吃掉？"
我们的答案是：四层安全护栏，端到端同一身份。
架构全貌
行级安全的灵魂：Snowflake Row Access Policy
关键设计：没有服务账号。整个链路从用户登录 Teams → Entra ID 签发 Token → Agent 拿到 on-behalf-of token → Snowflake 根据 Token 中的用户身份字段自动应用 RLS。没有"超级管理员"绕过权限的情况。
四道护栏
|
层次
|
机制
|
解决的问题
|
|
① 身份贯通
|
Entra ID 全链路同一 Token
|
无服务账号代答
|
|
② 数据隔离
|
Snowflake RLS + Dynamic Masking
|
行级 + 字段级双重隔离
|
|
③ 数据驻留
|
Purview DLP + 分类标签
|
数据不出微软生态
|
|
④ 全链路审计
|
trace_id 贯穿所有 Agent 调用
|
满足企业级合规要求
|
这里有一个容易被忽略的工程陷阱：Entra → Snowflake 的 OAuth 集成不是开箱即用的。Snowflake 默认支持外部 OAuth，但需要手动配置 SCIM 同步用户、创建 Security Integration、并为每个角色定义 Row Access Policy。这块我们踩了不少坑，值得单独写一篇文章。
四、Eva → Sales Deal Mate：从单兵到兵团的架构演进
2025 年的 Eva 拿奖后，很多同行说"你们赢在 prompt engineering"。但 2026 年的 Sales Deal Mate 拿奖后，没人再这么说了。
因为这次，架构层面的差异已经大到无法忽视。
Eva（2025）：单智能体，垂直突破
Teams Chat → Copilot Studio Agent → Dynamics CRM + Power AutomateEva 帮销售在 Teams 里找客户、生成跟进摘要、自动写 CRM 活动记录。本质是 "一个聊天 Bot + CRM connector"。
Sales Deal Mate（2026）：多智能体，横向覆盖
核心差异不在技术栈，在架构理念：
|
维度
|
Eva (2025)
|
Sales Deal Mate (2026)
|
|
架构模式
|
单 Agent
|
A2A Multi-Agent
|
|
覆盖范围
|
1 个场景（客户跟进）
|
4 个场景（线索→成单）
|
|
编排方式
|
Topic + Flow
|
Agent Flow + MCP/Connector
|
|
数据层
|
CRM only
|
Snowflake + pgvector + 3 知识库
|
|
安全
|
Entra 基础身份
|
Entra→Snowflake 权限复刻
|
|
可扩展性
|
加功能 = 改 Flow
|
加功能 = 加一个子 Agent
|
真正的技术拐点
Eva 到 Sales Deal Mate 的进化，本质上是回答了同一个问题：企业 AI 应该怎么交付？
一年前的答案是"做一个能解决单一问题的 Agent"。一年后的答案是"做一个能让 Agent 之间互相协作的平台"。平台化之后，边界的扩展成本从 O(n²) 降到了 O(1)——新增一个子 Agent 不需要动其他 Agent 的 Flow。
五、工程方法论：Skill Engine 自进化规则引擎
这篇文章前半部分讲的是「怎么让 Agent 跑起来」，后半部分要讲的是「怎么让 Agent 一直跑得对」。
核心痛点
一个真实的企业报价场景里，报价规则不是写死的：
"A 产品在华东区只能用 Tier 2 以下折扣"
"B 客户过去 12 个月有 3 次逾期，不能给账期"
"C 服务在 Q3 有促销，折扣率额外 -5%"
这些规则随时在变，不能让工程师每次手写。
Skill Engine 的闭环
⚠️ 以上是逻辑示意，实际部署在 Power Automate Cloud Flow + Azure Functions 组合上。
这个设计的巧妙之处在于：不是 AI 替代人类做决策，而是 AI 帮人类"发现"哪些隐性规则已经通过端侧修正被反复实践了。修正 3 次以上才触发，避免了偶发噪声污染规则库。
六、18 个月四阶段规划：AI 项目不是一次交付
很多 AI 项目的问题在于：一上来就要做"完整解决方案"，结果半年后交付了一个没人用的巨兽。
我们的做法是把 18 个月拆成四个阶段，每个阶段独立上线、独立创造价值：
|
阶段
|
时间
|
目标
|
关键交付
|
|
Phase 1
|
月 1-3
|
Excel→报价单，跑通最小闭环
|
Sales Bot + BoQ 解析 + 格式转换
|
|
Phase 2
|
月 4-8
|
GCOE 价格策略自动化
|
Skill Engine v1 + 配置驱动的定价规则
|
|
Phase 3
|
月 9-14
|
销售→成单全流程
|
A2A Multi-Agent + RFP 管线
|
|
Phase 4
|
月 15-18+
|
企业级 AI 平台
|
权限复刻 + 知识沉淀层 + 跨部门复用
|
四阶段规划的工程逻辑
Phase 1 的核心原则：绕开变革阻力。 我们不做"新系统"，而是在销售最熟悉的 Excel 和报价流程上做增强。用户不需要学新工具，工作流不变——只是原来手动填 Excel 变半自动。这个设计让 Phase 1 的采纳率直接上了 90%。
Phase 2 把隐性知识变成可执行的规则。 Skill Engine 的价值在这一阶段集中体现——GCOE 的定价专家不需要"培训 AI"，AI 通过观察端侧修正自动学习。
Phase 3 做横向扩展。 A2A 架构的关键优势在这里显现：新增 Tender Agent、RFP Agent、Compliance Agent，主控 Agent 不需要大规模重构。
Phase 4 做平台化。 权限复刻、知识沉淀层、跨部门复用——这是从"项目"到"产品"的质变。
七、技术选型复盘：几个真实决策
Q: 为什么选 pgvector 而不是 Pinecone/Weaviate/Milvus？
A: 客户已经在用 Azure PostgreSQL。 多引入一个向量数据库 = 多一套运维 + 多一套权限体系 + 多一套备份策略。pgvector 在 3072 维、5000 个 chunk 的规模下，召回率 96%，性能完全够用。
Q: 为什么选 Hybrid Search（pgvector + BM25）？
A: 标书场景有大量精确术语匹配需求。 "ISO 50001"、"BACnet/IP"、"Modbus RTU"——这些术语嵌入向量空间里距离不远的候选很多，但不能靠"语义近似"去猜。BM25 的精确词项匹配 + 向量的语义匹配 = 互补。
Q: 为什么选 Copilot Studio 可视化编排而不是代码编排？
A: 这是交付给客户的系统。 交付后客户 IT 团队需要能看懂、能改、能维护。Copilot Studio 的可视化画布让非 AI 工程师也能调整 Agent Flow 的决策逻辑。AI 项目的长期维护成本往往被低估——代码编排看起来更灵活，但对客户的运维团队来说，看懂一段 Python Agent 编排代码的成本远高于看懂一个可视化画布。
Q: Cross-Encoder 重排值得那 0.4 秒延迟吗？
A: 值。 从 Top-50 到 Top-5 的质量提升是决定性的——NDCG 从 0.73 提升到 0.91。对用户来说，多等 0.4 秒但看到的 5 条结果里有 4 条高度相关，好过秒出 5 条但有 2 条跑偏。
结语
写这篇文章的时候，Sales Deal Mate 的第 4 阶段还在路上。但回过头看这两年的技术决策，我觉得有几个原则值得分享：
AI 项目的用户不是你和你的同事，是客户的业务人员。 他们不关心你的向量数据库是什么，只关心能不能少花 30 分钟填 Excel。
架构选型以可维护性为第一优先级。 Copilot Studio 而不是 LangChain，pgvector 而不是 Pinecone——每个决策背后都是「客户能不能自己维护」。
安全不是附加功能，是第一天就该考虑的架构约束。 数据不出微软生态、端到端身份贯通、行级安全——这些在原型阶段就应该跑通，而不是等客户审计时再补。
渐进交付 > 大爆炸。 18 个月分四阶段，每个阶段独立上线、独立创造价值。客户每个季度都能看到新东西，而不是一年半后打开一个没人用的巨兽。
AI 不是替代人类做决策，是帮人类发现隐性规则。 Skill Engine 的设计哲学就在这里——修正 3 次以上的端侧行为才触发规则生成，剩下的交给人类审批。
关于诺未：我们是一家从 2011 年开始深耕微软生态的AI解决方案提供商，14 年里服务了 1000+ 企业客户。AI 时代到来后，我们把过去积累的工程经验全部"搬"到了 AI Agent 的落地实践里。如果你也在做企业级 AI 项目，欢迎交流。
本文基于真实项目技术架构撰写。部分客户信息已脱敏处理，具体性能数据来自 Azure AI Foundry Trace 记录。
