基于 Microsoft Foundry 的智能体式 AI——Microsoft Foundry 的核心概念与工具

在本章中，你将学习 Microsoft Foundry 的核心概念以及它所包含的工具。Microsoft Foundry 是一个统一的 Azure Platform as a Service（PaaS）产品，使 developers 能够快速 prototyping，并扩展到不同企业的 production workloads。Microsoft Foundry 的目标，是交付一个全面的 “agent factory”，将前沿 language models、复杂 tooling、enterprise-grade security，以及 multi-agent orchestration 组合到一个 single、integrated development environment 中。

本章将覆盖以下主要主题：

Microsoft Foundry architecture and project structure
Exploring the core development tools and model services
Implementing security, governance, and observability features

Technical requirements

在本章中，你将在第 2 章已经建立的 foundational Microsoft Foundry environment 之上继续学习。我们将探索核心 architecture concepts，浏览关键 development tools，并理解各种 services 如何协同工作，以创建 intelligent applications。

这些知识将构成关键基础，帮助你在后续章节中成功构建 generative AI 和 agentic AI solutions。在深入核心概念之前，请确保你已经完成第 2 章中的 setup，包括在 Microsoft Foundry project 中至少部署一个 model，例如 GPT-4.1。你应该拥有一个 active Microsoft Foundry resource，并已正确配置 Role-Based Access Control（RBAC）permissions。

最低要求是，你需要在 project 上拥有 Azure AI Developer role，才能访问本章将探索的 tools 和 services。如果在跟随操作时遇到 permission issues，请参考第 2 章中的 RBAC configuration section，或咨询你的 Azure administrator。

由于我们将探索各种 models 和 services，请确保你的 Microsoft Foundry resource 部署在支持完整能力的 region。Sweden Central 和 East US2 目前提供最全面的 feature set，包括 computer use preview 和完整 responsible AI tools suite 等高级能力。

关于最新 regional availability 信息，请参考： learn.microsoft.com/en-us/azure…

Microsoft Foundry architecture and project structure

要真正掌握 Microsoft Foundry，你必须先理解它如何组织 resources，以及如何管理不同 components 之间的复杂关系。可以把这种 architecture understanding 看作是在开始装修各个房间之前，先学习一栋建筑的 blueprint。如果没有这个基础，你可能会困惑为什么某些 features 以特定方式工作，或者在扩展 AI applications 时难以做出正确决策。

The hub and project relationship

Microsoft Foundry 实现了两种不同的 project architectures，用于服务不同的 organizational requirements 和 development scenarios。请参考图 3.1。

图 3.1：Hub project and Foundry project architecture

理解这两种方法，可以帮助你在 resource allocation、governance strategies 和 workflow development 方面做出更明智的决策。

Microsoft Foundry project architecture

Microsoft Foundry projects 代表当前推荐的 AI application development 方法。这些 projects 直接构建在 Microsoft Foundry resources 之上，并在单一 resource governance 下统一管理 agents、models 和 tools。

这种 architecture 消除了协调多个 Azure services 的复杂性，同时保留 enterprise-grade capabilities。Microsoft Foundry projects 为 developers 提供 self-serve capabilities，使其能够独立创建新 environments，用于探索想法并构建 prototypes，同时保持 data isolation。Projects 充当 secure units of isolation and collaboration，在其中 agents 共享 file storage、用于 conversation history 的 thread storage，以及 search indexes。

Hub-based project architecture

Hub-based projects 使用 Microsoft Foundry hubs，由 hub 集中管理多个 child projects 的 security、networking、compute resources 和 quota。一个 hub 内的所有 projects 共享相同 security configurations 和 business domain；hub 上配置的 security settings 会自动下传到每个 project。Hub 作为 shared infrastructure，管理到 external resources 的 connections、compute allocations 和 enterprise policies。

当你将一个 model 部署到 hub 时，该 hub 内的所有 projects 都可以访问并使用该 model。这通过 resource sharing 实现 cost efficiency，同时保持清晰的 organizational boundaries。

Architectural decision guidance

Microsoft Foundry projects 应该是 teams 构建 agents 或使用 models 时的理想选择；而 hub-based projects 应在需要与现有 Azure Machine Learning infrastructure 集成时使用，因为这一能力目前在 Microsoft Foundry projects 中不可用。这一 guidance 反映了面向 simplified、API-first development experiences 的战略方向。

组织应根据这些标准评估自身需求。Microsoft Foundry projects 适合优先考虑 rapid development、agent-based applications 和 simplified governance 的 teams。Hub-based projects 仍适合已经投资 Azure Machine Learning、存在复杂 multi-team resource sharing requirements，或具有特定 compliance needs、需要传统 hub governance models 的组织。

Least privilege 原则要求：如果 agents 需要访问不同 resource sets，就应使用独立的 Microsoft Foundry projects，因为单个 project 内的所有 agents 共享同一个 managed identity。无论选择哪种 architecture，这一 security consideration 都会影响 project architecture decisions。

当前使用 hub-based projects 的组织，应评估迁移到 Microsoft Foundry projects，以访问最新 capabilities 和简化的 management experience。Microsoft 提供 migration guidance 和 tools，以帮助完成这一转变，同时保留 existing investments 和 configurations。这两种方法之间的 architecture choice，会从根本上塑造你所有 AI initiatives 中的 development workflows、security implementations 和 operational procedures。

要知道你创建的是哪种 project，可以在 navigation section 中查看，那里会标明是（AI Foundry）还是（Hub），如图 3.2 所示。

图 3.2：Navigation panel to check Project based on AI Foundry or Hub

另一种方式是进入 All resources 页面，查看 parent resource 是 AI Foundry 还是 Hub，具体取决于创建方式。

图 3.3：The All resources page highlighting the type of projects created

请注意，你会看到所有 resources，例如 projects（Hub 或 Foundry）、model deployment endpoint、subscription、region 和 key。

Shared vs. dedicated resources

Microsoft Foundry 的 resource management 方法，为平衡 cost efficiency 和 performance requirements 提供了成熟选项。该 platform architecture 使组织能够优化 resource allocation strategies，同时在不同 application requirements 之间维持适当 isolation 和 governance controls。

Resource sharing in Microsoft Foundry projects

Microsoft Foundry projects 通过 managed services 实现 resource sharing，在提供 enterprise-grade capabilities 的同时简化 allocation decisions。当你在 Microsoft Foundry project 内部署 models 时，platform 会根据 demand patterns 自动管理底层 infrastructure sharing 和 scaling。这种 managed approach 消除了 resource provisioning 的复杂性，同时通过 intelligent resource allocation 保持 cost efficiency。

Microsoft Foundry project architecture 提供内置 resource optimization，对 development teams 透明运行。Model deployments、compute resources 和 storage services 会根据 application requirements 动态 scale，而不需要显式 sharing configurations。这种方式降低了 administrative overhead，同时确保组织内不同 applications 的 resource utilization 保持最佳。

Microsoft Foundry projects 使 teams 可以专注 application development，而不是 infrastructure management。Platform 的 managed services 会处理 resource allocation decisions，通过 shared infrastructure 自动优化 costs，同时为 critical applications 保持适当 performance isolation。这种简化方式尤其适合优先考虑 rapid development cycles 和降低 operational complexity 的组织。

Resource sharing in hub-based projects

Hub-based projects 通过 explicit infrastructure management 实现 resource sharing，也就是部署到 hub 的 resources 可供所有 child projects 使用。当你将 GPT-4.1 等 language model 部署到 hub 时，该 hub 中的所有 projects 都可以访问并使用该 model deployment。这种方式让你可以直接控制 resource allocation decisions，并对多个 teams 和 applications 实现精确 cost management。

Hub-based approach 通过 strategic resource consolidation 带来显著 cost benefits。组织无需为每个 team 维护单独 model deployments，而是可以部署 shared resources，让多个 projects 基于实际 consumption 使用。Usage charges 会根据实际 utilization patterns 分摊，使每个 team 只为消耗的 resources 付费，同时在所有 users 之间摊销 fixed costs。

Hub-based resource sharing 对昂贵 infrastructure components 尤其有利，例如用于 model fine-tuning 的 high-performance computing instances，或每次 deployment 成本较高的 premium model deployments。组织可以通过将这些 expensive resources consolidated 到 hub level，实现有意义的 cost optimization，同时在不同 business units 之间维持清晰 usage tracking 和 cost allocation。

Dedicated resource requirements

某些 application scenarios 无论选择哪种 architecture，都需要 dedicated resources。Performance isolation 是一项关键要求：customer-facing applications 需要 guaranteed response times，且不能受到其他 workloads 的影响而 degraded。Dedicated compute resources 确保 experimental workloads、fine-tuning operations 或 batch processing tasks 不会影响 production application performance。

Security 和 compliance requirements 也经常驱动 dedicated resource decisions。处理高度 sensitive data 的 applications，例如 financial records、healthcare information 或 proprietary research，需要 dedicated infrastructure，以维持严格 access controls 和 data isolation。这些场景会受益于 dedicated compute resources，因为这些 resources 永远不会处理其他组织数据；也会受益于 dedicated storage systems，因为它们提供完整 audit trails 和 access control。

Regulatory compliance considerations 往往要求特定级别的 resource isolation。具有严格 certification requirements 的行业会发现，dedicated infrastructure 可以降低 compliance complexity，并简化 audit preparation。Dedicated resources 的额外成本，可以通过降低 compliance management overhead 和更清晰 regulatory audit trails 来证明其合理性。

Strategic resource allocation

Shared 和 dedicated resources 之间的决策应与具体 application requirements 对齐，而不是采用统一方法。Microsoft Foundry projects 提供 managed resource allocation，可以自动优化 sharing，同时维持适当 isolation。Hub-based projects 则通过 explicit resource management，对 sharing decisions 提供细粒度控制。

组织可以实施 mixed resource strategies，在整个 AI application portfolio 中同时优化 costs 和 performance。Development 和 testing environments 受益于 shared resource approaches，因为它们可以最小化 costs 和 administrative overhead。具有特定 performance 或 compliance requirements 的 production applications，则使用 dedicated resources，以确保适当 isolation 和 control。

Microsoft Foundry 的 flexible architecture 支持随着组织需求变化而演进的 dynamic resource allocation strategies。Teams 可以在 rapid prototyping 和 development 阶段从 shared resource approaches 开始，随着 applications 成熟并需要 production-grade isolation 和 performance guarantees，再转向 dedicated resources。这种 evolutionary approach 使组织可以在 development phases 优化 costs，同时为 production deployments 确保合适的 resource allocation。

Security boundaries and access control

Microsoft Foundry 通过 layered boundaries 和 access controls 实现 comprehensive security framework，用于跨不同 organizational scopes 保护 data、models 和 applications。这种 multilayered approach 使组织能够维护适当 security postures，同时支持 diverse teams 和 use cases 的 scalable AI development。

Identity and access management

Security implementation 从 Azure Subscription level 的 Microsoft Entra ID 开始，它为所有 Microsoft Foundry resources 建立 foundational identity and access management framework。组织在这一层控制 user authentication requirements、resource access permissions 和 deployment policies。Subscription-level policies 可以执行 multi-factor authentication requirements、将 resource deployments 限制在特定 regions 以满足 data sovereignty compliance，并对 sensitive resource creation activities 实施 workflow approval。

Resource Groups 提供下一层 security boundary，使组织能够实施与 team structures 和 functional responsibilities 对齐的 role-based access control policies。正如第 2 章创建 resource group 的流程所展示的，这些 logical boundaries 支持不同 organizational functions 的不同 access levels。AI development teams 通常获得 contributor access，以支持 resource creation 和 modification；finance teams 获得 read-only access，用于 cost monitoring；security teams 则获得 specialized access，用于 compliance auditing activities。

Resource-level security controls

Microsoft Foundry resources 建立关键 security configurations，用于治理 network access、data protection 和 external service connections。这些 resources 控制 AI applications 是否可以通过 public internet connections 访问，或者是否仅通过 virtual network integration 和 private endpoint configurations 在 private organizational networks 内运行。Resource level 配置的 security settings 会自动继承到 child projects，确保所有 development activities 具备一致 security postures。

Data encryption 是在 resource level 实施的基础 security control。Microsoft Foundry 同时支持 Microsoft-managed 和 customer-managed encryption keys，用于保护 data at rest 和 data in transit。具有严格 data governance requirements 或 regulatory compliance obligations 的组织，可以完全控制 encryption key management，这对 highly regulated industries 或 sensitive data processing scenarios 尤其重要。

Project-level access controls

单个 projects 实施 granular、application-specific security controls，使不同 AI initiatives 可以实现精确 access management。Project-level role-based access control configurations 支持不同 access patterns，例如 data scientists 拥有完整 experimental access，而 business stakeholders 获得 read-only access，用于 result review 和 feedback provision。这种 granular approach 在维持 team productivity 的同时确保适当 access levels。

Projects 也控制对特定 AI models 和 deployments 的访问，使 data 和 model 可以基于 application requirements 进行 segregation。Customer service applications 访问基于 general interaction data 训练的 models；financial analysis applications 使用基于 proprietary financial datasets 训练的 models，并通过适当 access restrictions 防止 cross-application model access。这种 model-level access control 在实施 specialized fine-tuning approaches 时尤其重要，这些方法会在第 5 章关于不同 training techniques 和 compute options 的内容中讨论。

Network security architecture

Network security boundaries 贯穿所有 organizational levels，并需要仔细考虑，因为它们控制 AI applications 的基本 data flow patterns。Microsoft Foundry 支持多种 network security models，从 open internet access 到完全运行在 organizational virtual networks 内的 private deployments。合适方法取决于 data sensitivity requirements、regulatory compliance obligations，以及与现有 corporate systems 的 integration needs。

Private endpoints 使 AI applications 可以通过 virtual networks 内的 private IP addresses 与其他 Azure services 通信，确保 sensitive data 永远不会穿越 public internet infrastructure。Virtual network integration 隔离 AI workloads，同时维持对 corporate resources 的受控访问。Network security groups（NSGs）提供 fine-grained traffic control，指定 AI resources 和其他 system components 之间允许的 communication patterns。

Enterprise security implementation

实施 comprehensive security strategies 的组织，通常采用 defense-in-depth approaches，结合多重 security boundaries 和 controls。这类实现可能包括：对 AI workloads 使用 private network isolation；使用 role-based access control 确保 authorized user access 到特定 resources；通过 comprehensive data encryption 保护 storage 和 transmission 期间的信息；以及使用 continuous monitoring capabilities 来检测和响应 security issues。

第 2 章关于 RBAC configuration guidance 的内容展示了，在 resource creation 时正确 permission assignment 如何建立 security foundations，同时支持 development productivity 和 organizational governance requirements。组织可以基于 application sensitivity 和 regulatory requirements 实施不同复杂度的 security controls，同时确保 security controls 支持而不是阻碍 AI development efforts。

Security boundary decision framework

Security implementation decisions 应与具体 organizational requirements 和 application sensitivity levels 对齐。开发 non-sensitive applications 的小 teams 可以实施 simplified security configurations，优先考虑 development velocity 和 ease of use。处理 customer financial data 的大型企业通常需要 comprehensive security controls，包括 private networks、customer-managed encryption keys 和 detailed audit logging capabilities。

关键原则是：让 security implementation complexity 与实际 organizational requirements 匹配，同时确保 security controls 支持而不是阻碍 legitimate AI development activities。这种 balanced approach 使组织能够维持适当 security postures，同时支持不同 teams 和 use cases 的 innovative AI application development。

在本节中，你学习了 Microsoft Foundry 的基础 architecture concepts，包括 Microsoft Foundry projects 与 hub-based projects 的区别、resources 如何 shared 或 dedicated，以及保护 AI applications 的 multilayered security boundaries。理解这些 architecture foundations 非常关键，因为它们决定你如何组织 teams、管理 costs、实施 security controls，并在组织中 scale AI solutions。具备这些 architecture knowledge 后，你现在可以继续探索让 AI applications 真正运行起来的 core development tools 和 services：也就是将 architecture concepts 转化为 working intelligent solutions 的 models、frameworks 和 capabilities。

Exploring the core development tools and model services

继续之前，请确保你已经具备以下内容：

一个 Azure subscription。
能访问 Microsoft Foundry Resource，并带有默认的 firstProject。
一个支持你计划使用 models 的可用 region。

Model availability 经常变化；请始终在 Microsoft Learn 上验证 region support。

如果你更倾向于从代码开发，请安装 VS Code 和 Microsoft Foundry SDK。

Model catalog and selection

Microsoft Foundry 暴露一个统一的 Model Catalog，其中包含广泛且快速增长的 foundation 和 task models：Azure OpenAI（GPT-4.1 / 4o、o-series、Image-1）、Microsoft Research 的 Phi family、Meta Llama、Mistral（包括 OCR / Document AI）、Cohere、NVIDIA、DeepSeek、xAI Grok、Stability、Bria 等。内部 field 和 conference decks 一直引用 Foundry 中可用的 1,800–1,900+ models，这反映了 first-party 和 partner offerings 都汇聚在一个 single pane 中。

Evaluate and compare

在 portal 中，可以使用 Leaderboards、Model cards 和 Compare models view，查看 standardized benchmarks，并按 capability（reasoning、tool calling、multimodal、embeddings）、provider 或 deployment mode（serverless、provisioned、batch、managed compute）进行 filter。这是根据 task、latency 和 cost profile 缩小 candidate models 范围的最快方式。

当你比较 models 时，Microsoft Foundry 提供多个 dashboards 供你选择 models：

Quality leadership dashboard，会基于 quality index score 排名 models。该 score 是 benchmark datasets 上 accuracy scores 的平均值，用于衡量 reasoning、knowledge 和 coding 等 model capabilities。
Highlights，用来标识哪个 model 在每项 criterion 中表现最佳，例如 quality、safety、cost 和 throughput。
Trade-off charts，用于在相同 criteria 之间交叉比较 models：quality、cost、safety 和 throughput。
按 scenario 排列的 leadership boards，用于深入分析 model 在特定 categories 上的 performance，包括但不限于 coding、reasoning、harmful behavior、math 和 summarizations。

When to use which model

理想情况下，每种 model type 都应根据 developer 想解决的问题类型来考虑。例如，o4-mini 和 Phi-4 等 reasoning models 非常适合 multistep problem solving、tool orchestration 和 agent decision loop，尤其是在 correctness、decomposition 和 traceability 比 raw tokens per second 更重要时。它们也适合作为 multi-agent topologies 中的 controller models。

如果 use case 涉及 conversational apps、drafting、structured QnA，以及在 balance、quality 和 latency 之间做复杂 summarization，那么可以使用 GPT-4o、Llama 3.x 或 Mistral Large 等 LLM models，并且可以与 RAG 结合实现 enterprise grounding。

Embedding models 非常适合提升 retrieval quality、indexing content，并在 RAG、hybrid search 和 semantic navigation 中提升 top-k relevance。如果你的 use case 涉及 document processing，可以考虑 GPT-4o 或 Mistral Document AI 等 multi-modal models，它们适用于 forms、invoices、contracts、parsing、tables、figures extraction 和 multi-modal chat。Document AI 专门用于生成 structured outputs in JSON，以供 agents 或 RAG pipelines 使用。

Cost vs. performance trade-offs

Serverless 是 pay-per-call，适合 prototyping 和 variable workloads。Provisioned 或 reserved capacity 可以在 steady、high-throughput scenarios 中降低 unit cost。Foundry 和 Azure OpenAI（AOAI）materials 强调 live capacity visibility 和 provisioned throughput unit（PTU）management，以支持 predictable service level agreements（SLAs）。

当面对 fine-tune vs. RAG vs. prompt-only 的选择时，对于 dynamic knowledge、governance 和更低 total cost of ownership（TCO），优先选择 prompting 和 RAG。只有当你必须改变 model behavior，例如 format fidelity、style / voice、instruction-following，或者在 narrow task 上以更小、更便宜的 inference 达到相同 quality 时，才转向 fine-tuning。

Development tools deep dive

Developers 拥有可用于创建自己的 end-to-end AI projects 的工具至关重要。

图 3.4：Microsoft Foundry Core Development Tools and Services

这些工具帮助 developers 加快流程，确保他们能够快速从 prototyping 到 proof of concept（POC），再到 production，并实现这些工具的价值。下面是帮助 scale 和 delivery 的 developer tools。

Prompt flow（visual authoring and evaluation）

可以把 prompt flow 理解为 AI logic 的 flowchart builder：它可以将 LLM calls、Python tools、retrieval steps 和 evaluators 串联成 executable graph；可以 debug traces；运行 bulk tests；并将 flow promote 为 API。你可以在 portal 中 author，也可以通过 VS Code（extension）和 open-source SDK 在本地 author。它提供以下 features：

使用 prompt variants 和 side-by-side evaluation 进行 rapid iteration。
Built-in tools，包括 LLM、embeddings、content safety、index lookup、Python、rerank，用于减少 glue code。
CI/CD hooks，用于运行 bulk evaluation，并基于 quality metrics 阻断 promotions。

Agent service（autonomous, tool-using AI）

Microsoft Foundry Agent Service 是 managed runtime，用于构建 autonomous agents。这些 agents 能够 plan、call tools，并在 development 和 production 中完成 goals。它处理 threads、tool orchestration、content safety enforcement、identity、networking 和 observability，使你能够更快从 demo 走向 durable automation。

Connected agents（specialization and delegation across boundaries）

Connected agents 支持 multi-agent systems，其中 primary controller 可以将 tasks 委派给 specialized agents，例如 retrieval、extraction、analysis 或 action agents。这些 agents 可能运行在不同 projects 或 stacks 中。通过 standardized handoff protocols 和 identity，它们可以协调 plans、共享 intermediate artifacts，并返回带有清晰 provenance 的 results。

这种 pattern 可以扩展复杂 workflows，而不会让单一 prompt 或 toolset 过载；它也改善 fault isolation，并允许 teams 在自己的 release 和 governance cycles 下独立演进 agents。

AI Search（RAG you can trust）

Azure AI Search 是 RAG pipelines 的 enterprise retriever：它会 index 你的 data，例如 files、websites、DBs，支持 vector 和 hybrid search，并为 LLM 返回 compact、relevant chunks。相关 guidance 描述了 agentic retrieval pipelines，以及在 Foundry、OpenAI 和 prompt flow 中集成 Search 的多种 built-in ways。

RAG 使你能够通过 citations 将 model 限制在你的 facts 之上，减少 hallucinations，并将 knowledge refresh 与 model lifecycle 解耦。可以使用 catalog 中的 embeddings 和 re-rankers，然后通过 evaluation flows 监控 quality。

Grounding with Bing search tool（fresh, open-web grounding with citations）

Bing Search tool 将 current、public web context 引入 Foundry apps 和 agents。它执行 policy-aware queries，包括 site / domain filters 和 query rewriting，返回带 URLs 的 ranked snippets，并提供 LLM 可以在答案中直接引用的 citations。

当 freshness 和 breadth 很重要时，可以使用它，例如 market news、product specs 或 regulatory updates，同时仍然控制 content safety 和 result filtering。应与 groundedness checks 配合使用，确保只有被佐证的 web passages 影响 final responses。

Grounding with Bing custom search tool（curated web within boundaries）

Bing Custom Search 将 grounding 限制在你批准的一组 domains、paths 或 pages 内，生成一致且 brand-safe 的 retrieval，而无需维护自己的 index。它适合 public-facing documentation、partner portals 或 marketing sites：你希望使用 open-web coverage，但又需要严格 scope。

该 tool 会返回简洁、高相关性 snippets 和 citations，减少来自更广泛 web 的 noise，并且相比运行完整 enterprise index 简化了 governance。当 precision 和 policy compliance 最重要时，可以将它作为 general web search 的受控替代方案。

Microsoft Fabric Data Agent（governed data access for agents and RAG）

Fabric Data Agent 将 OneLake 中的 governed data 暴露给 LLMs 和 agents，例如 tables、files 和 semantic models，同时保留 lineage、labels 和 row-level permissions。它通过 Fabric 的 security model 路由 structured queries 和 lookups，使 agents 能够 ground answers、compute KPIs 或 summarize data，而无需将 datasets 复制到 ad hoc stores。

这保留了 single source of truth，与 enterprise compliance 对齐，并将 refresh、quality 和 access policies 集中在 Fabric 中，而不是 application layer。

OpenAPI Spec tool（safe action-taking via typed APIs）

OpenAPI Spec tool 将任何由 OpenAPI 描述的 endpoint 转换为 agent 可以 plan 和 execute 的 callable tool。它执行 request / response schemas、处理 parameter binding 和 validation，并可在 calls 发出前应用 Entra-based authentication 和 policy。

使用它可以让 agents 执行 verifiable actions，例如 create tickets、submit orders、fetch records，同时保持严格 guardrails、auditability 和 traceability。对于 production 中的 transactional capabilities，这是首选路径。

Logic App trigger（workflow orchestration as an agent tool）

Logic Apps 提供 low-code action surface，LLM 可以通过 Logic App Trigger tool 调用它来运行 enterprise workflows，例如 approvals、notifications 和 system integrations。你可以获得丰富 connector library、built-in retries 和 idempotency，以及 model runtime 之外的 durable execution。

它特别适合需要 systems of record、human approval gates 或 SLA-backed automation 的 multi-step handoffs，同时将 governance、observability 和 change control 保持在 first-class Azure service 中。

Browser Automation Tool（structured browsing with guardrails）

Browser Automation Tool 允许在 APIs 不可用时，对 live websites 和 internal portals 进行受控、可审计的 navigation 和 extraction。它捕获 pages、跟随 allowed links、提取 structured DOM content，并只将 policy-permitted data 返回给 LLM。

它应谨慎使用，适合 legacy forms 或 gated docs 等 edge cases，在这些场景下你需要 just-in-time evidence 或 inputs。应配合 allowlists、rate limits 和 content safety 使用，防止 drift into untrusted flows，并维持 clean audit trail。

Fine-tuning services（customize what the model is）

Microsoft Foundry 提供两种 fine-tuning approaches，它们有不同 infrastructure models：Serverless 和 Managed Compute。

Serverless fine-tuning 提供完全托管的 infrastructure，由 Microsoft 处理所有 GPU provisioning 和 scaling；你只需为 training 中处理的 tokens 付费，不需要 quota requests。

Managed Compute 要求你自行 provision 和 manage Azure Machine Learning VMs，并具备 GPU quotas。它提供对 hyperparameters 和 VM selection 的完全控制，但完全不支持访问 OpenAI models。

两种方式都支持第 5 章中会覆盖的 fine-tuning techniques：supervised fine-tuning（SFT），用于 domain adaptation 和 tone customization；direct preference optimization（DPO），用于 instruction-following improvements；以及 reinforcement fine-tuning（RFT），用于 reasoning optimization。目前 global training options 已覆盖 24 个 Azure regions，以降低 costs。

现在我们已经理解 development tools，接下来深入了解如何以 collaborative approach 将这些 tools 组合起来，用于开发 enterprise-grade solutions。

Tool integration for collaborative development

Market and compliance intelligence copilot：使用 Connected Agents 编排来自 Bing Search（fresh public web）和 Bing Custom Search（curated domains）的 grounding；在允许的 legacy portals 中 fallback 到 Browser Automation Tool；再通过 Azure AI Search 与 internal policies 融合，生成带丰富 citations 的 daily briefs。

Output / KPIs：更快 time-to-brief、更高 source coverage、更低 groundedness defect rate，以及用于 compliance 的 auditable citations。

Finance and operations KPI assistant with action taking：通过 Microsoft Fabric Data Agent 查询 governed measures，从 Azure AI Search 检索 SOPs / runbooks，然后通过 OpenAPI Spec Tool（typed ERP / ITSM calls）执行已批准的 remediations，并通过 Logic App Trigger 驱动 approvals 和 notifications；Coordinating Connected Agent 管理 planning、evidence 和 handoffs。

Output / KPIs：降低 MTTR、缩短 approval cycle time、降低 rework rate，并实现每个 incident 可衡量的 cost savings。

Field service resolution and knowledge capture：Troubleshooter（Connected Agent）从 Azure AI Search 中获取 guidance，通过 Bing Search 补充 current vendor advisories；当 APIs 不存在时，使用 Browser Automation Tool 提取 exact bulletin text。修复后，它通过 OpenAPI Spec Tool 更新 work orders，并通过 Logic App Trigger 路由 confirmations，然后将 structured post-mortem 捕获回 knowledge base。

Output / KPIs：提高 first-contact resolution、减少 truck rolls、提升 knowledge reuse rate，并实现 sources 和 actions 的端到端 traceability。

Developers 通常可以选择使用 Software Development Kit（SDK）或 Azure portal interface 来使用这些 integrated tools。下面讨论这些 approaches。

SDK vs. Portal development approaches

Portal-first（fastest path） ：使用 Model Catalog、Prompt Flow canvas 和 built-in evaluators 进行 prototype，然后将 flows 发布为 endpoints。

SDK-first（industrialization） ：使用 Microsoft Foundry SDK 创建 project clients、调用 models、instrument tracing，并集成 CI/CD，同时对 Search、agents 和 evaluations 提供 parity。这与第 2 章从 portal setup 走向 repeatable project scaffolding 的路径一致。

下面是一个最小 SDK 示例（Python）：

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

project = AIProjectClient(
    endpoint="https://<your-project-endpoint>", # Foundry project Overview
    credential=DefaultAzureCredential()
)

# Example: obtain chat client bound to your Foundry project's default model
chat = project.models.get_chat_completions_client("gpt-4o-mini")
resp = chat.complete(messages=[
    {"role": "user", "content": "Summarize our policy in 3 bullets."}
])

print(resp.choices[0].message.content)

当 developers 想使用 code-first approach 时，可以使用自己喜欢的 editor VS Code，并结合 GitHub。Microsoft Foundry 支持这两个平台的集成，也支持前面讨论过的 tools 用于 development。

Integration with Visual Studio Code and GitHub

VS Code and Prompt Flow extension：在本地创建并编辑 flows，debug Python tools，并运行 bulk tests；随后 push 到 GitHub，进行 CI evaluation 和 deployment。

Samples and repos：使用 open samples，加速 scaffolding。这些 samples 展示 hubs / projects、tracing、basic RAG、agents 和 Semantic Kernel integrations。

现在你已经探索了 Microsoft Foundry 中的关键 development tools，包括全面的 model catalog、SDKs，以及 agent orchestration frameworks 的基础。掌握这些 tools 使你能够快速 prototype AI solutions，为 use cases 选择合适 models，并构建解决复杂 business problems 的 sophisticated multi-agent systems。随着 architecture understanding 和 hands-on development capabilities 都已建立，下一步关键任务是实施 security、governance 和 observability features，以确保 AI applications 在 production environments 中安全、合规、可靠运行。

Implementing security, governance, and observability features

本节覆盖将 AI 转化为 secure、governed 和 observable service 的关键概念。

图 3.5：Microsoft Foundry governance and observability lifecycle

AI governance framework 将 security、evaluation、monitoring、mitigation 和 optimization capabilities 集成到 plan-develop-operate cycle 中，并通过 continuous governance controls，确保整个 application lifecycle 中的 compliance 和 security。当你想设置该 framework 时，需要建立 identity 和 network boundaries，编码 policy，并 instrument quality / safety，使 operations 能够信任最终发布的内容。下面我们深入 security fundamentals，理解这一过程。

Security fundamentals

本节展示 Microsoft Foundry 中如何应用 security，从 identity and access management 到 content safety、network isolation 和 data protection。

Identity and access management（IAM）

Microsoft Foundry 使用 Microsoft Entra ID（formerly Azure Active Directory），并在 account（infrastructure）和 project（build）scopes 中使用 Azure Role-Based Access Control（RBAC）。这种集成提供几个关键好处：centralized identity management 消除了对独立 AI-specific credentials 的需求，从而减少 password sprawl 带来的 security vulnerabilities；通过 built-in roles（Azure AI User、Azure AI Project Manager、Azure AI Account Owner）实现 granular permission control，确保 team members 只访问必要 resources；audit trails 会自动跟踪所有 access attempts，用于 compliance reporting。

只有在必要时才使用 custom rules，并且始终从 least-privileged access principles 开始，只授予每个 role 所需的最低 permissions。对于 autonomous agents，Microsoft Entra ID 会为每个 agent 提供 managed、non-human identity，用于一致 authentication 和 lifecycle control。这种方式避免了使用 shared credentials 的 service accounts 所带来的 security risks，使 credential rotation 可以自动完成且无需修改 application code，并提供清晰 audit trails，显示哪个 agent 执行了每个 action。

Content safety（inline and configurable）

Azure AI Content Safety 通过多层 defense，保护 users 和 systems 免受 harmful outputs 影响。该 service 提供显著 operational benefits：automated content filtering 会在 harmful outputs 到达 users 前阻断它们，以防止 reputational damage 和 legal liability；configurable policies 可以适配特定 use case，例如 customer-facing chatbots 使用 strict filtering，而 internal research tools 可以使用较宽松 settings；real-time threat detection 可以识别 evolving attack patterns，例如 jailbreak attempts。

启用针对 hate / unfairness、sexual content、violence 和 self-harm 的 category filters，以建立 baseline protection。实施 Prompt Shields，用于检测 direct jailbreak attempts 和嵌入 retrieved documents 中的 indirect attacks。部署 groundedness detection，通过验证 responses 与 source documents 是否对齐，减少 RAG applications 中的 hallucinations。添加 protected material checks，以防止复制 copyrighted text 或 code。所有 policies 都可以通过 customizable thresholds、domain-specific blocklists，以及适合你行业需求的 custom safety categories，按 application 调优。

Network security（private by default）

将 AI resources 放在 private endpoints 和 virtual networks 后面，执行 NSGs，并在适用时对 compute resources 使用 managed network isolation。这种 architecture 确保 AI workloads 不会暴露 public endpoints，除非明确需要，从而防止 unauthorized access 和 data exfiltration。

对于涉及 sensitive data 的场景，例如 “bring your own data” implementations，即使用 proprietary information 为 AI responses 提供 grounding，应将 virtual network / private link connectivity 与 Azure AI Search 中的 document-level access control 结合起来。这种 dual-layer approach 确保 network-level isolation 阻止 unauthorized connections，同时 identity-based permissions 根据 user 和 group claims 控制 retrieval。结果是，即使 users 具备 network access，也只能检索其 Active Directory group membership 授权的 documents，从而提供 defense-in-depth security，并满足 IT security requirements 和 data segregation 的 compliance mandates。

Private network configuration 为 enterprise deployments 提供几个关键收益：data in transit 永远不会穿越 public internet infrastructure，从而消除 man-in-the-middle attack vectors；与现有 corporate virtual networks 集成，使其能通过 ExpressRoute 或 VPN connections 与 on-premises systems 无缝通信；NSG rules 提供 fine-grained traffic filtering，只允许 AI services 和其他 resources 之间的 approved communication patterns；managed virtual network isolation for compute 确保即使 training jobs 被 compromised，也无法将 data exfiltrate 到 unauthorized destinations。

Data protection（encryption and keys）

Data in transit 和 data at rest 都会被 encrypted；如果需要更严格控制，可以通过 Azure Key Vault 启用 Customer-Managed Keys（CMK），要求启用 soft-delete + purge protection，并向 resource 的 managed identity 授予 wrap / unwrap / get 权限。Azure OpenAI 支持 FIPS 140-2 AES-256，以及用于 model artifacts 和 fine-tunes 的 CMK；Foundry projects 也支持跨 hub storage 使用 CMK。

Governance and compliance

Microsoft Foundry 提供 comprehensive governance 和 compliance capabilities，使组织能够在满足 regulatory requirements 的同时构建 trustworthy AI systems。这些 features 覆盖完整 AI lifecycle，从控制 teams 可以部署哪些 models，到监控 production applications 是否存在 safety violations，再到为 compliance teams 维护 auditable records。以下小节解释如何有效实施每一层 governance。

Model governance（catalog policies and gated releases）

Model governance 控制 development teams 可以访问和部署哪些 AI models，防止未经授权使用未批准或 high-risk models。这项能力解决了一个关键 enterprise challenge：如果没有 centralized controls，不同 teams 可能部署未经 security、cost efficiency 或 organizational standards compliance 审查的 models。

使用 Model Catalog Governance（可通过 Microsoft Foundry portal 的 Management | Governance | Model catalog policies 访问），可以执行 approved models allow-list。例如，只允许 Models-as-a-Service（MaaS）和 Models-as-a-Platform（MaaP）deployments，同时禁用 non-approved models 的 “Deploy” 功能。这确保 internal standards 能在 developers 使用的 catalog user interface 中被执行。

结合 evaluation gates，可以在 promotion 到 production 之前评估 quality 和 safety metrics，并保留 auditable trail，记录哪些 models 何时通过 validation。组织可以配置 approval workflows，要求 security team sign-off 后，teams 才能将 new model versions 部署到 customer-facing applications。

Policy management（organization-wide）

应用 Microsoft Foundry security baseline 和 Azure Policy，执行 continuous posture checks，包括 network、identity 和 logging。通过 Microsoft Purview，将 governance 扩展到 runtime data（可以通过 Foundry 中的 native switch 或 Purview APIs）：捕获 prompt / response telemetry，用于 DLP、auditing、comms compliance，以及从 grounding sources 继承 labels。

Audit and compliance（evidence, trails, approvals）

集中管理 evidence：将 evaluation runs（quality、safety）和 risk scans 作为 release checklist 的一部分归档；与可信的 governance systems 集成，例如 Saidot / Credo AI，以及 Defender for Cloud 的 Regulatory Compliance view。在 Foundry 内保留一个统一的 “Risks + alerts” pane，使 product teams 在构建过程中就能看到 issues。

Responsible AI（fairness, reliability, transparency）

Responsible AI practices 确保 AI systems 能够 fair、reliable 和 transparent 地运行。这些要求不仅关乎 regulatory compliance，也关乎 organizational reputation 和 user trust。这些 capabilities 帮助 teams 识别和缓解 bias、防止 harmful outputs，并保持 AI decisions 的 explainability。

在 Foundry 的 lifecycle checkpoints 中 operationalize Microsoft Responsible AI Standard，该标准文档位于 microsoft.com/ai/responsible-ai：使用 automated safety evaluations 发现 risks（配置在 Build | Evaluations | Safety evaluators 中）；使用 safety filters 和 shields 保护 systems（通过 Protect | Content Safety 管理）；并使用 tracing、monitoring 和 compliance integrations 治理 deployments（通过 Manage | Monitoring 访问）。

使用当前处于 preview 的 Risk and Safety Evaluators（位于 Build | Evaluations | Create evaluation），在 curated test sets 上量化 harmful content，包括 jailbreak susceptibility、code vulnerabilities 和 ungrounded attributes。这些 evaluators 提供 quantitative metrics，compliance teams 可以随时间跟踪这些指标，从而展示 AI safety posture 的 continuous improvement。

Observability and operations

Production AI applications 需要 continuous monitoring 和 operational oversight，以维持 reliability、performance 和 safety。不同于传统软件的 failures 通常是 binary 的，例如系统工作或崩溃；AI systems 可能会 subtle degrade：生成 lower-quality responses、表现出 bias 或产生 hallucinations，却不会触发常规 error alerts。

Microsoft Foundry 的 observability capabilities 提供了早期检测这些 quality regressions、优化 resource utilization，并维护 service level agreements 所需的 instrumentation。以下小节覆盖 performance monitoring、evaluation workflows 和 incident response mechanisms，用于保持 AI applications 在 production 中可靠运行。

Performance monitoring（end-to-end）

Foundry 为 apps 和 agents 提供 built-in observability，包括 structured tracing、latency / throughput / tokens，以及 cost 和 safety summaries，并与 Azure Monitor 集成，用于 dashboards 和 alerting。你可以在 development 中 instrument inner-loop traces，并将 Azure Monitor workbooks promote 到 production。

Quality metrics（measuring metrics）

Quality metrics 包括对不同指标的测量，例如 groundedness、relevance、coherence / fluency、retrieval score / similarity，以及 classical NLP metrics（F1、BLEU、ROUGE、GLEU）。应将这些 metrics 视为 release criteria，而不是 vanity metrics；“evaluation-first” posture 有助于在替换 models 或 prompts 时防止 regressions。

例如，考虑一个 healthcare benefits chatbot，它必须回答 patients 关于 coverage 的问题。在将 prompt change 或 model upgrade 发布到 production 前，应运行 evaluation tests，测量：

Groundedness（75%+ threshold） ：确保 responses 只引用 benefits documentation 中存在的信息，防止 AI 编造 policy details。

Relevance（80%+ threshold） ：验证 answers 直接回应 patient question，而不是提供相关但跑偏的信息。

Coherence（90%+ threshold） ：确认 responses 阅读自然，没有 contradictory statements。

Retrieval score（0.7+ similarity） ：验证 AI Search index 能针对每类 query 返回正确 policy documents。

如果你的 evaluation run 显示，在从 GPT-4o 切换到 GPT-4.1-mini 后，groundedness 从 78% 降到 68%，你就知道这个 model change 会增加 hallucinations，从而在 patients 收到错误 coverage information 之前捕获 regression。这个 “evaluation gate” 可以在节省 model 成本的同时，防止 quality degradation。

Cost management

使用 Foundry 的 Management Center 和 Azure cost tooling 按 project / environment 跟踪 usage；规划 capacity（serverless vs. provisioned throughput），并设置 budgets / alerts。Observability 会暴露 request distribution、tokens 和 failure patterns，以便及早捕获 runaway costs。

Automated evaluations（CI/CD）

将 evaluations shift left，并接入 CI/CD。Foundry 的 Evaluation service + GitHub Action for Agent Evaluation，使你能够比较 agent 或 prompt versions、计算 confidence intervals，并在 safety / quality regression 时让 builds fail。Evaluation corpus 应与 flow 或 agent config 一起 versioned。

Alert systems（security and quality incidents）

启用 Defender for Cloud – AI threat protection，使所有 jailbreak attempts、credential leaks、malicious URLs 和 data-leak patterns 都能实时触发 alerts（以及 prompt-level blocking），并直接在 Foundry 和 Defender XDR 中可见。将这些 alerts 与 incident response 中的 runbooks 对齐。

Enterprise scenarios and reference blueprints

实施 Microsoft Foundry 的大型组织，会受益于 standardized governance frameworks 和 security blueprints，以确保多个 teams 和 projects 之间保持一致性。与其让每个 development team 独立决定 security policies 和 compliance controls，enterprise-grade deployments 需要 centralized guardrails，在 innovation velocity 和 risk management 之间取得平衡。以下 blueprints 为实施 organization-wide governance，以及保护处理 sensitive data 的 AI applications，提供 prescriptive guidance。

以下是 organization-wide governance framework：

Establish policy：定义 allowed models / providers（catalog governance）、network stance（private endpoint + virtual network），以及每个 release stage 的 mandatory evaluators。

Provision with guardrails：Project templates 编码 Role-Based Access Control（RBAC）、Customer-Managed Keys（CMK）和 network defaults。

Gate deliveries：Continuous Integration（CI）pipelines 必须通过 quality / safety thresholds，并将 evaluation evidence 附加到 change records。

Monitor & audit：Security baselines + Defender AI alerts + Purview auditing 创建 continuous trail。

Security policies for sensitive data（finance / health / intellectual property）

以下是针对 sensitive data（finance / health / IP）的 security policies：

Identity：使用 Entra Agent ID 和 managed identities；通过 search filters 或 application programming interfaces（APIs）限制 data access scope。

Network：将所有 model endpoints 限制在 Private Link 后面；不允许 public ingress；通过 private domain name system（DNS）对等连接 virtual networks。

Data：启用 Customer-Managed Keys（Key Vault）；在 Purview 中对 prompts / responses 执行 label inheritance 和 Data Loss Prevention（DLP）；对于 RAG，在 Azure AI Search 中启用 document-level access。

Safety：收紧 category thresholds；启用 Prompt Shields；在每次 RAG call 上添加 groundedness checks。

Production monitoring dashboards for apps / agents

构建一个 workbook，将 Foundry traces（latency、tokens、tool calls）、quality / safety eval trends（defect rate、groundedness）、cost / usage 和 Defender alerts 融合起来。从 basic patterns 开始，再加入 release-gate metrics，使 Site Reliability Engineers（SREs）可以看到 new prompt / model 何时降低了 quality。

这些 unified dashboards 服务于 production operations 的三个关键目的：

第一，它们支持 proactive quality monitoring，将 technical metrics（latency spikes、increased token consumption）与 quality degradation（groundedness scores dropping、defect rates rising）相关联，使 SREs 能够在 customer complaints 到来之前，就检测到某个 recent model deployment 正在导致 hallucinations。

第二，它们提供 cost governance visibility，通过对照 budget thresholds 跟踪 token usage trends，在 inefficient prompts 或 unnecessary tool calls 导致 AI spending 异常加速时，提醒 finance teams。

第三，它们通过将 Foundry traces 与 Defender security alerts 结合，创建 incident response context，使 on-call engineers 能够快速判断 performance issues 是来自 infrastructure problems、prompt engineering changes，还是 security threats。这通过消除跨多个 monitoring systems 手工关联的需要，降低 mean time to resolution。

Summary

本章介绍了 Microsoft Foundry 的核心 architecture，用于构建 generative 和 agentic AI applications。它澄清了 Foundry 和 hub-based projects 的区别，重点关注 resource management 和 governance。我们探索了 resource sharing models，从 managed services 到 explicit infrastructure control，并回顾了覆盖 identity、network 和 encryption 的 multilayered security framework。

本章还强调了关键 development tools：Model Catalog（1,900+ models）、Prompt Flow、Agent Service、用于 RAG 的 Azure AI Search，以及 grounding tools。通过 market intelligence copilots 和 finance automation 等示例，我们看到这些 components 如何集成进高级 AI solutions。最后，我们覆盖了 enterprise-grade features，即 content safety、policy management、observability 和 automated evaluation，它们支持 secure 和 scalable AI deployments。