数据孤岛，跨系统难拉通
ERP / MES / PLM / SCADA 各自为政，设备、工艺、质量与订单数据难以关联。问题定位靠人工串联多套系统，AI 拿不到完整上下文。
Microsoft Foundry · 企业级 AI 智能体平台
买工具，只是第一步
GitHub Copilot 让开发者更快地做出原型。Microsoft Foundry 让原型变成有身份、可观测、能被治理的生产系统。诺未做的是中间这一段——从一个能跑的 demo，到一个公司敢放进生产的系统。
Reality Check
原型到生产之间的那道坎
卡住企业的从来不是「模型不够聪明」。是原型跑通之后，没人敢让它碰真实数据、真实系统、真实产线。
知识流失，经验难以复用
故障处理依赖老师傅经验。SOP、设备手册与历史工单没有沉淀为可检索、可溯源的知识资产——人员流动，能力就跟着流失。
治理与观测缺位
智能体缺少统一身份、日志与调用链治理，行为不可解释、不可问责。过不了生产环境的安全审计，就永远停在 POC。
根因
断点不在单点工具的智能水平，而在缺少贯通「数据 — 智能 — 编排 — 治理」的企业级底座。
From Copilot to Foundry
从 Copilot 到 Foundry：一条完整的路径
如果你们已经在用 GitHub Copilot，这一段说的就是下一步。
阶段一 · 原型
GitHub Copilot
开发者用 agent 模式两三天做出一个能跑的东西。这一步现在很快，不是瓶颈。
→
断层 · 为什么停在这里
IT 不批
原型跑在个人机器上：用谁的身份访问数据？调了几次模型、花了多少钱？出错了怎么追？——一个都答不上来。
→
阶段二 · 生产
Microsoft Foundry
Hosted Agents 直接接收 MAF、GitHub Copilot SDK、LangGraph、Claude Agent SDK 写的 agent，不需要重写。
部署即获得
每个 agent 一个独立的 Entra Agent ID，不用在镜像里存密钥 · OpenTelemetry 全链路追踪直接流入 Application Insights · 闲置 scale-to-zero 不计费，下次请求自动拉起，会话状态与文件保留。
Capability
Microsoft Foundry 关键能力
完整功能清单微软官网有。这里只讲决定「能不能上生产」的四件事。
Foundry Models
11,000+ 基础、开源、推理、多模态与行业模型，一套 API 切换。今天用 GPT，明天成本压不住换别的，业务代码不用重写。
Foundry Agent Service
Hosted Agents 把你的代码打包成容器跑在托管基础设施上，自带身份、自动扩缩、会话状态持久化与版本管理。
Foundry IQ
统一检索层，一个 SLA 端点打通 Work IQ、Fabric IQ、Azure SQL、File Search 与 MCP 数据源，RAG 不再各建各的。
Foundry Tools / Toolboxes
单一托管 MCP 端点承载所有工具类型；skills 在项目级目录中版本化，项目内任意 agent 可发现调用。
Security & Governance
AI 安全与治理：微软真正拉开差距的地方
大模型能力在快速趋同，安全与治理不会。这是 Foundry 相对于自建方案最难被追上的一层——因为它不是一个功能，是身份、数据、威胁、合规四条线同时收口。
01
模型层 · Foundry Guardrails
内容过滤、提示注入防护（Prompt Shields）、滥用检测，直接保护托管推理端点。
更关键的是 Guardrail Policies：可在订阅或资源组级别强制最低护栏标准，由 Azure Policy 驱动自动评估合规状态，违规部署可一键跳转修复——安全不靠开发者自觉，是平台强制的。
Content FiltersPrompt ShieldsAbuse DetectionGuardrail Policies
02
威胁层 · Microsoft Defender for Cloud
安全态势建议识别配置错误与风险；为 Foundry Tools 开启威胁防护后，可检测越狱（jailbreak）与用户输入攻击，以 Defender 告警形式呈现。
告警可与 Purview 的 AI 交互审计记录关联，支撑事后调查与追责。
安全态势管理Jailbreak 检测输入攻击检测告警关联调查
03
数据层 · Microsoft Purview
在订阅上启用后，该订阅下所有应用与 agent 的 AI 交互数据统一流入 Purview，一次打通企业级数据合规能力。
审计 Audit敏感信息分类 SITDSPM for AI内部风险管理通信合规数据生命周期eDiscovery
04
身份层 · Entra Agent ID
每个 agent 是一等身份主体，纳入 Entra Agent Registry 统一清点（含第三方 agent），走 RBAC、条件访问与最小权限，密钥集中托管于 Key Vault。
Entra Agent IDAgent RegistryRBAC / 条件访问Key Vault 密钥托管
诺未做什么
这四层能力微软都给了，但默认不会自动配好。护栏策略怎么定、Defender 与 Purview 怎么接、身份与网络边界怎么划——这是诺未在每个项目里实际交付的部分。
Reference Architecture
一家全球制造业企业的多智能体平台
Microsoft Foundry + Microsoft Agent Framework
背景
该企业在多地拥有生产基地，面临的正是上文那三个断点：数据分散在多套系统、故障处置经验难以复用、智能体缺少统一治理无法通过安全审计。
架构：统一编排层 + 六大业务智能体
以 Microsoft Foundry 为平台底座、Microsoft Agent Framework 为统一编排层，全部智能体原生注册至编排层，由编排层统一路由、定级与升级管理——杜绝新的孤岛产生。
监控诊断排障预测性维护生产优化自主执行
端到端闭环：从告警到工单
- 1告警产生
- 2监控 Agent 异常确认
- 3诊断 Agent 多源关联
- 4知识图谱检索
- 5RAG 检索
- 6排障 Agent 生成方案
- 7建议处置（带置信度）
- 8执行 Agent · 人工确认
- 9自动工单回写业务系统
RAG 在这里是什么
Azure AI Search + Embedding / Hybrid Search / Rerank，把分散的手册、SOP、历史工单变成可检索、带引用溯源的知识资产；上面再叠一层「设备-工艺-故障-SOP」知识图谱，让诊断结论能说清「依据是什么」。
MCP 在这里是什么
Azure API Management 作为统一出入口，同时承载 REST / gRPC / MCP Server / Webhook；Agent 接入区预留 MCP 原生注册，后续新增能力可平滑扩展，不改编排层。
交付哲学
先跑通闭环，再规模复制。成熟一个，上线一个。每个场景以一个可量化的业务指标验收，不追求一次性铺开。
NovaHub Gateway
诺未差异化：跨生态的模型网关
Foundry 解决了微软生态内的统一。但你们的现实是——不会只用一个模型，也不会只用一个生态。
问题
复杂推理用 GPT，成本敏感的批量任务用 DeepSeek 或 Kimi。结果是 Key 散在各个团队手里，没人说得清这个月花了多少、谁花的、值不值。
NovaHub Gateway
诺未自研，NovaHub 企业 AI 能力整合平台的组件之一。
- 统一 Key 分发——不再让开发者各自持有厂商密钥
- 分级配额——按团队 / 项目设上限，防止单个实验烧掉整月预算
- Token 级精准计量——用量与成本归集到部门，FinOps 可核算
- 多模型统一入口——GPT、DeepSeek、Kimi 等一个端点接入，切换不改业务代码
和 Foundry 的关系
互补，不是替代。Foundry 统一微软生态内的模型、护栏与治理；NovaHub Gateway 统一跨生态的调用与成本——包括不在 Foundry 目录里的国产模型。两者在真实项目里通常同时存在。
Delivery
诺未怎么交付
不是卖订阅就完事。场景怎么选、架构怎么设计、安全怎么配、成本怎么管，这些才是真正的活儿。
场景选型与可行性
- 盘点现有系统与数据源，确认数据可达性
- 选高频、见效快的单一场景先跑
- 明确一个可量化的验收指标
可行性评估 · 场景优先级清单
01
02
架构与模型选型
- Foundry 底座与编排层设计
- 模型选型与成本方案（含 NovaHub Gateway）
- 安全与合规架构：身份、网络、数据边界
架构设计 · 安全合规方案
Agent / RAG / MCP 开发集成
- 智能体开发与多智能体编排
- 知识资产化与 RAG 构建，带引用溯源
- 经 APIM 打通业务系统（REST / MCP）
可运行系统 · 集成契约文档
03
04
生产化与持续运营
- 护栏策略与 Defender / Purview 接入
- 全链路可观测与告警
- 成本复盘与配额调优
上线运行 · 月度运营报告
Why NovaTech
为什么是诺未
诺未科技（NovaTech）是微软解决方案合作伙伴，自 2011 年起深耕微软技术栈，为超过 1000 家企业提供从战略咨询到持续运维的端到端服务。
全栈微软资质，端到端交付能力
微软云全六项 Solution Partner 认证：
- Modern Work · Data & AI (Azure) · Digital & App Innovation
- Infrastructure (Azure) · Business Applications · Security
Advanced Specialization 与双通道资质：
- AI on Azure · Infra & Data Migration
- Adoption & Change Management · Custom Solutions for Microsoft Teams
- 21V CSP / OSPA / NCEI · HK 1T/2T CSP · SG 2T CSP · ECIF Certified Partner
连续两年微软黑客松冠军
2025 年
「Eva」智能体在微软中国区 Copilot AI 创新大赛获第一名
2026 年
「Sales Deal Agent」多智能体方案在微软 Frontier Agentic Hackathon 摘得「智胜全能金奖」（第一名），同年获FY26 微软市场拓展先锋奖
连续两年在微软中国黑客松夺冠，证明的不只是技术领先，更是把前沿技术落地为可交付、可运营、可扩展方案的能力。
FAQ
常见问题 FAQ
Q1：和我们自己搭一套有什么区别？
A：自建最贵的从来不是模型调用，是三件事：给每个 agent 一个能被审计的企业身份、把全链路调用变成可追溯的日志、以及让安全护栏成为平台强制而不是开发者自觉。Foundry 把这三件事变成了平台能力——Entra Agent ID、OpenTelemetry 追踪、Guardrail Policies。自己搭这三层，通常比业务逻辑本身更耗时间，而且做完还要长期维护。
Q2：模型能不能换？会不会被锁死在一家？
A：Foundry Models 提供 11,000+ 模型的统一 API，换模型不改业务代码。如果你们还要用不在 Foundry 目录里的模型（比如某些国产模型），诺未的 NovaHub Gateway 可以在其上再做一层跨生态统一入口，让切换成本进一步降低。我们不建议把自己锁在任何一家。
Q3：企业数据在哪？会不会被用于训练？
A：客户数据不会被用于训练模型。Foundry 支持专属部署与私有网络配置（BYO VNet / Private Endpoint），密钥集中托管于 Key Vault；启用 Microsoft Purview 后，AI 交互数据的审计、敏感信息分类与数据安全态势管理可统一纳管。具体的数据边界与网络方案，诺未会在架构阶段和你们逐项确认后写进方案。
Q4：已有的业务系统怎么接？MCP 是什么？
A：MCP（Model Context Protocol）是让 agent 调用外部工具与数据的标准协议。实际项目里我们通常用 Azure API Management 作为统一出入口，同时承载 REST / gRPC / MCP Server / Webhook——已有系统按现有协议接入，新增能力走 MCP 注册，两者并存，不需要为了上 AI 先改造业务系统。
Q5：多久能看到东西？
A：我们的做法是先选一个高频、见效快的单一场景跑通闭环，用一个可量化的业务指标验收，再按产线或部门复制推广——成熟一个，上线一个。具体周期取决于数据可达性与集成复杂度，会在可行性评估阶段给出明确排期，而不是先承诺一个数字。
Q6：怎么计费？
A：分两部分。Azure 侧按 token、算力与各项服务用量计费，随架构方案不同差异很大；诺未侧是实施与运维服务费。因为变量太多，我们不在页面上给一个看起来精确的估算数字——可行性评估阶段会基于你们的真实场景给出成本模型与区间。