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┌─────────────────────────────────────────────────┐ │ Microsoft Teams (唯一入口) │ │ 销售用自然语言对话 ← 所有输入/输出 │ └──────────────┬──────────────────────────────────┘ │ ┌──────────────▼──────────────────────────────────┐ │ 主控 Agent (Orchestrator) │ │ Copilot Studio 可视化编排画布 │ │ · 意图路由 · 上下文管理 · 子Agent调度 │ └───┬──────────┬──────────┬──────────┬────────────┘ │ │ │ │ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ ┌───▼────┐ │Tender │ │ KA │ │ RFP │ │Compl. │ │Agent │ │Agent │ │Agent │ │Agent │ │每日扫标│ │客户全景│ │标书解析│ │双文档 │ │线索推送│ │关系挖掘│ │需求抽取│ │合规审查│ └───────┘ └───────┘ └───────┘ └────────┘1.1 Agent-to-AgentA2A不是 Tool-to-Tool这是整个架构最核心的设计决策。传统做法Tool-to-Tool把每个功能封装成 REST API由一个中央调度器按 if-else 或状态机调用。问题是每次新增能力调度器的路由逻辑都要改。三个子模块还行十个就变成意大利面条。我们的做法Agent-to-Agent在 Copilot Studio 的可视化编排画布上主控 Agent 像技术主管一样调度子 Agent只管谁擅长什么不关心内部实现。子 Agent 之间也可以互相调用——比如 KA Agent 发现客户近期有招标公告可以直接触发 Tender Agent 的扫描任务。// 伪代码主控 Agent 的调度逻辑不是真实代码是 Copilot Studio 画布上的节点连接 // 主控只做路由不关心子 Agent 内部怎么干活 const orchestrate async (userIntent, context) { switch (classifyIntent(userIntent)) { case daily_tender_scan: return await agents.tender.scanAndPush({ region: context.userRegion }); case ka_deep_dive: return await agents.ka.buildProfile({ accountId: context.accountId }); case rfp_parse: return await agents.rfp.parse({ documentUrl: context.uploadedFile }); case compliance_check: return await agents.compliance.crossCheck({ proposalId: context.proposalId, rfpId: context.rfpId, }); } };⚠️ 注意以上是逻辑示意。实际编排在 Copilot Studio 的低代码画布中完成不是手写 JS。1.2 为什么选 Copilot Studio 而非 LangChain/LlamaIndex这是每次分享都会被问到的问题。我们的决策逻辑维度Copilot StudioLangChain/LlamaIndex企业身份集成Entra ID 原生对接零配置需要自己接 OAuth/OIDCTeams 集成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 能力: - OCR Layout Table Extraction (标准三件套) - 技术规格章节自动识别 (自定义模型) - BoQ 表格结构还原 (合并单元格必须解开) - 图章/印章/手写批注剥离 (这些东西对 NLP 是噪音)这里有一个工程细节值得说Azure Document Intelligence 默认不支持 技术规格章节 的语义识别。我们针对客户标书的版式特征固定字体、固定缩进层级、固定编号规则训练了一个轻量的自定义模型准确率从 72% 提高到 94%。Stage 2 — 语义切片 向量化 (Chunk)工具: Azure OpenAI text-embedding-3-large 策略: section-aware chunking (按章节边界切分非固定窗口) 元数据: 每片携带 { doc_id, 章节标题, 页码 } 向量: 3072 维 → pgvector 入库 切分结果: 487 chunks为什么不按固定 token 窗口切因为标书的结构性太强——「第三章 技术要求」和「第四章」语义断点非常明确。如果按 512-token 固定窗口硬切一条完整的技术需求可能被切成两半。section-aware chunking 的语义完整性大幅提升代价是为每个文档类型维护一份章节边界配置文件。Stage 3 — 混合检索 (Retrieve)这是召回质量最关键的一步Round 1: pgvector BM25 Hybrid Search - 语义检索 (vector) 关键词检索 (BM25) 并行 - 召回 Top-50 候选文档 - Recall: 96% Round 2: Cross-Encoder 重排 - 对 Top-50 做精细语义匹配 - 精排 Top-5 - NDCG: 0.91为什么不用纯向量检索因为标书中有大量术语精确匹配的需求比如 ISO 50001、Niagara Framework、BACnet/IP这些术语即便语义空间里距离不远但我们不能依赖语义近似去猜必须精确命中。BM25 解决了精确匹配向量解决了语义匹配Cross-Encoder 做最终仲裁。三管齐下NDCG 达到 0.91。Stage 4 — 应答判分 (Score)模型: Azure OpenAI GPT-4 class Prompt 策略: 结构化判分 强制解释链 输出: 逐条 { 需求ID, 评分(满足/部分/缺失), 引用出处, 修订建议 } 消耗: 1840 tokens / 次 结果: 47 条需求, 3 缺失, 5 部分满足判断分 Prompt 的设计原则是不允许模型只说满足必须引用标书原文中的页码和段落作为证据。这让评分结果可审计——你随时可以回到标书原文档验证每一个判断。三、Entra → Snowflake 权限复刻数据不出微软生态企业级 AI 项目最大的坎不是模型是安全合规。客户的第一反应永远是我的客户数据会不会被 AI 模型吃掉我们的答案是四层安全护栏端到端同一身份。架构全貌Layer 1: 销售用户 (usercompany · Sales-East) ↓ OAuth 2.0 / OIDC Layer 2: Microsoft Entra ID (Identity Provider) ↓ on-behalf-of token Layer 3: Agent Delegated Connector ↓ Snowflake RLS Layer 4: Snowflake Row Access Policy Dynamic Masking行级安全的灵魂Snowflake Row Access Policy-- Snowflake Worksheet: row_access_demo.sql · LIVE QUERY -- 销售用户 · East region · 仅可见自己负责的 60 KA SELECT opp_id, account_name, amount, owner FROM SALES_DB.OPPORTUNITY_VW; -- Snowflake 自动应用 Row Access Policy ↓ -- OPP-1023 │ Shanghai BizPark │ ¥ 2.8M │ usercompany -- OPP-1041 │ Nanjing Tower │ ¥ 1.2M │ usercompany -- [masked] │ ████████████████ │ ███████ │ ████ ← 跨区记录关键设计没有服务账号。整个链路从用户登录 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 拿奖后没人再这么说了。因为这次架构层面的差异已经大到无法忽视。Eva2025单智能体垂直突破Teams Chat → Copilot Studio Agent → Dynamics CRM Power AutomateEva 帮销售在 Teams 里找客户、生成跟进摘要、自动写 CRM 活动记录。本质是一个聊天 Bot CRM connector。Sales Deal Mate2026多智能体横向覆盖Teams Chat → 主控 Agent → Tender Agent / KA Agent / RFP Agent / Compliance Agent ↓ Snowflake Azure AI Foundry Document Intelligence pgvector核心差异不在技术栈在架构理念维度Eva (2025)Sales Deal Mate (2026)架构模式单 AgentA2A Multi-Agent覆盖范围1 个场景客户跟进4 个场景线索→成单编排方式Topic FlowAgent Flow MCP/Connector数据层CRM onlySnowflake 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 的闭环# 伪代码Skill Engine 的工作原理 # 1. 自动扫描端侧修正记录 feedback azure_functions.timer_trigger( cron0 */6 * * *, # 每 6 小时 query SELECT skill_name, corrected_value, context FROM sfdc.skill_feedback WHERE correction_count 3 -- 被修正 3 次以上才触发 AND status pending_review ) # 2. Azure OpenAI 生成候选规则 for item in feedback: candidate azure_openai.complete(promptf 基于以下修正记录生成一条报价规则 原始建议: {item.original_value} 修正后值: {item.corrected_value} 业务上下文: {item.context} 输出格式: JSON {{ rule: ..., priority: ... }} ) # 3. 经审批后写入规则库 sfdc.skill_rules.insert({ Content: candidate.rule, Priority: candidate.priority, Status: approved })⚠️ 以上是逻辑示意实际部署在 Power Automate Cloud Flow Azure Functions 组合上。这个设计的巧妙之处在于不是 AI 替代人类做决策而是 AI 帮人类发现哪些隐性规则已经通过端侧修正被反复实践了。修正 3 次以上才触发避免了偶发噪声污染规则库。六、18 个月四阶段规划AI 项目不是一次交付很多 AI 项目的问题在于一上来就要做完整解决方案结果半年后交付了一个没人用的巨兽。我们的做法是把 18 个月拆成四个阶段每个阶段独立上线、独立创造价值阶段时间目标关键交付Phase 1月 1-3Excel→报价单跑通最小闭环Sales Bot BoQ 解析 格式转换Phase 2月 4-8GCOE 价格策略自动化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 的定价专家不需要培训 AIAI 通过观察端侧修正自动学习。Phase 3 做横向扩展。A2A 架构的关键优势在这里显现新增 Tender Agent、RFP Agent、Compliance Agent主控 Agent 不需要大规模重构。Phase 4 做平台化。权限复刻、知识沉淀层、跨部门复用——这是从项目到产品的质变。七、技术选型复盘几个真实决策Q: 为什么选 pgvector 而不是 Pinecone/Weaviate/MilvusA: 客户已经在用 Azure PostgreSQL。多引入一个向量数据库 多一套运维 多一套权限体系 多一套备份策略。pgvector 在 3072 维、5000 个 chunk 的规模下召回率 96%性能完全够用。Q: 为什么选 Hybrid Searchpgvector BM25A: 标书场景有大量精确术语匹配需求。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 而不是 LangChainpgvector 而不是 Pinecone——每个决策背后都是「客户能不能自己维护」。安全不是附加功能是第一天就该考虑的架构约束。数据不出微软生态、端到端身份贯通、行级安全——这些在原型阶段就应该跑通而不是等客户审计时再补。渐进交付 大爆炸。18 个月分四阶段每个阶段独立上线、独立创造价值。客户每个季度都能看到新东西而不是一年半后打开一个没人用的巨兽。AI 不是替代人类做决策是帮人类发现隐性规则。Skill Engine 的设计哲学就在这里——修正 3 次以上的端侧行为才触发规则生成剩下的交给人类审批。关于诺未我们是一家从 2011 年开始做微软技术服务的公司14 年里服务了 1000 企业客户。AI 时代到来后我们把过去积累的工程经验全部搬到了 AI Agent 的落地实践里。如果你也在做企业级 AI 项目欢迎交流。本文基于真实项目技术架构撰写。部分客户信息已脱敏处理具体性能数据来自 Azure AI Foundry Trace 记录。