一家企业准备建设“制度与流程助手”。员工先问：“这项业务应该按哪个流程办理？”系统检索获准制度，给出带出处的回答；下一步，它还可以整理材料、填写工单草稿，甚至在审批后向业务系统提交事项。

看起来，这只是同一个助手逐步增加功能。真正落到架构上，企业却面临三种不同的实施方式：直接采用服务商提供的工作空间；自行开发应用，调用云端模型服务，并按需使用智能体开发与运行服务；或者把模型推理放到员工设备或企业本地基础设施中，再自行组装应用与智能体。

三种方案都能展示一个聊天窗口，也都可能使用“Agent”名称，但企业需要投入的建设能力、能够控制的环节、数据经过的位置和长期运营责任并不相同。企业首先需要回答的，不是“哪个模型最强”，而是：

企业应该选择哪条实施路径？在这条路径中，哪些能力可以采购或托管，哪些建设、控制和运营责任必须由企业自己承担？

本文从企业实施视角，把 AI 应用落地归纳为三条路径：采用托管式 AI 应用及可配置智能体功能、使用云端模型服务及可选的智能体开发与运行服务、自建基于本地推理运行环境或基础设施的智能体应用。这是为了比较企业选择、建设和运营方式而采用的工作性描述，不是官方产品分类，也不是由低到高的行业等级。

一、选模型不是第一步，先确定企业要负责到哪一层

如果只比较模型名称和参数，三个关键问题会被掩盖。

第一，企业准备直接采用现成工作空间，还是建设自己的业务应用？一套员工可以直接登录的企业工作空间，与一个供开发人员调用的模型 API，代表两种不同的实施起点。

第二，企业需要自己建设哪些组件，才能把模型变成可运行的业务系统？模型可以生成回答或提出工具调用请求，但身份校验、知识检索、任务状态、参数校验、人工审批、日志和失败恢复通常位于模型之外。

第三，系统发生错误时，企业由谁阻断、恢复和举证？如果模型建议“创建工单”，企业还要知道：谁授权它代表员工操作，是否限制对象和金额，重复请求会不会创建两张工单，失败后如何重试或撤销，日志能否还原全过程。

因此，企业首先要确定的是实施与责任边界：哪些能力直接采用，哪些能力由平台托管，哪些组件必须自行建设和运营。企业采用的服务越接近成品应用，需要自建的组件通常越少，但对服务端运行的直接控制也越有限；企业采用的服务越接近模型或基础设施，设计空间越大，同时也要承担更多集成、验证和运营责任。

二、先把企业 AI 拆成四层

理解三条路径之前，需要先把容易混在一起的四层分开。

业务应用与用户界面          → 智能体编排与运行          → 模型推理服务          → 计算、网络与存储基础设施

本文所称的智能体应用，是围绕任务目标，把模型、指令、企业数据、工具、会话或任务状态、身份权限和验证机制组合起来的应用系统。行业对“智能体”的范围尚无完全统一的定义，因此判断一个系统时，不应只看名称，而应看它实际能读取什么、能调用什么、能否改变外部状态，以及由谁批准和验证。

智能体开发与运行平台用于构建、部署、运行和管理这类应用；智能体运行时则是执行任务、协调模型与工具调用并维护运行状态的软件组件或服务。平台可以包含运行时，运行时却不等于整个平台，更不等于已经完成业务应用。

工具调用也要分成两步：模型可以生成结构化调用请求，智能体运行时或业务应用再校验参数、身份和权限，实际调用外部 API。模型提出动作，不等于动作已经获授权，更不等于外部系统已经正确执行。

先分清产品处在架构的哪一层

产品名称之所以容易混淆，是因为它们分别位于业务应用、智能体平台、模型服务和基础设施等不同层次。下面只介绍理解三条实施路径所必需的几个名称；其余术语在首次出现时再作解释。产品名称保留官方英文名称，括号中的中文用于说明其定位，不作为官方中文译名。

把这些名称放回四层架构后，三条路径的差别就清楚了：企业究竟是直接采用应用，从模型和平台开始建设，还是连推理环境也自己运营。

三、三条实施路径不是等级，而是三种责任安排

企业可以用同一组问题比较三条路径：能够直接获得什么、还要自行建设什么、为什么选择它，以及需要接受哪些边界。

这三条路径并不互斥。企业可以让通用办公场景采用托管式应用，让特定业务流程使用云端自建智能体，同时把少量严格受限的推理任务放在本地。组合方案的关键不是产品越多越好，而是企业能为每类数据和动作规定清晰的路由、授权和责任。

图 1 把三条路径放到同一套四层结构中。企业可以据此判断：每条路径需要自己建设和运营到哪一层，哪些层可以直接采用服务商能力。

图1：三种实施路径的四层责任切分

图中蓝色表示服务商托管，灰色表示企业建设和运营，绿色表示在企业控制环境中本地运行，紫色表示企业设计但可以使用平台托管能力。最下方的橙色区域横跨三条路径：无论采用哪条路径，身份、数据权限、工具范围、人工审批、审计和业务验收标准都不能仅由模型或产品默认值决定。

四、路径一：采用托管式 AI 应用及可配置智能体功能

企业选择这条路径，最像“使用一套已经装修好的办公空间”：不再从模型接口开始建设，而是直接引入员工可以使用的界面、组织工作空间、服务端模型和应用运行环境。企业主要完成组织接入、人员管理、使用策略和数据源配置。

OpenAI 公司提供的 ChatGPT 企业版（ChatGPT Enterprise）可以作为这类产品的一个熟悉实例。OpenAI 为企业管理员提供专门的上线说明，并通过应用与连接器文档说明外部内容和服务的接入方式。具体可用的身份、管理员、应用、连接器、驻留和审计功能会随计划、地区、配置与合同变化，不能把某一时点的功能清单写成永久承诺。

企业如何配置和上线托管式应用

托管式应用看起来开箱即用，但企业上线时仍应完成一套明确的配置和验证工作。可以按以下顺序实施。

1. 先定义任务边界。 把“问制度”“生成材料草稿”“提交业务事项”分成三个权限等级。第一阶段通常只开放带出处的问答，第二阶段允许生成草稿，第三阶段才考虑写入外部系统。

2. 接入组织身份。 配置企业账号、单点登录、用户组和离职停用流程。至少用普通员工、部门负责人和管理员三个测试身份验证可见内容，避免只用高权限管理员账号验收。

3. 配置获准数据源。 只连接已经明确所有者、访问规则和更新机制的制度库。记录系统是请求时读取、预先同步还是建立搜索索引，并测试源文档修改、撤权和删除后，产品侧的内容何时失效。

4. 配置助手规则。 规定回答必须引用制度名称、版本或生效日期；找不到依据时应明确说“不确定”，不能自行补出流程。对固定业务可以要求按“适用制度—所需材料—下一步—出处”返回。

5. 分开读取工具和写入工具。 查询制度、查询工单状态属于读取；创建工单、发送通知或修改记录属于写入。写入工具应使用单独的允许清单、参数范围和人工确认，不应因为已连接数据源就自动获得写权限。

6. 用真实角色做小范围试运行。 测试正确问题、模糊问题、越权问题、过期制度、无答案、重复提交和工具失败。上线后持续检查共享范围、异常调用、人工驳回原因和制度更新是否及时生效。

这套方法的重点是“配置并验证”，而不是开发一个新的模型。企业需要形成的配置和治理成果通常包括用户组映射、数据源清单、助手规则、工具允许清单、审批矩阵、测试问题集和停用方案。

示例：从制度问答到采购工单

在制度助手场景中，员工从托管工作空间提问。系统可能只使用会话输入，也可能按配置从获准的数据源读取相关资料，再由服务端模型生成回答。如果产品支持可配置助手、连接器或工具，企业还可以限定允许使用的知识源和外部服务。

假设员工输入：“购买一台 8,000 元的研发电脑，需要走什么流程？请帮我准备申请。”一个受控的托管式应用可以这样工作：

如果当前产品或合同不支持安全的写入工具，也可以停在“生成草稿”这一步，让员工手工复制到采购系统。自动化程度较低不代表方案失败；只要责任边界清楚，它往往比勉强打通一个无法审计的写入连接更可靠。

这里有三个容易忽略的边界。

第一，连接数据源不等于复制整个知识库。不同集成可能采用请求时读取、预先同步、建立索引或企业自建接口，身份传递、权限继承、更新删除和保留规则并不相同。

第二，管理员能配置工作空间，不等于企业接管服务端运行。企业可以决定谁使用、连接什么、共享什么，但服务端应用、模型和相关基础设施仍由服务商运营。

第三，可配置智能体功能不等于无限自主操作。即使系统能够调用工具，企业仍应为高影响动作设置对象范围、参数约束、人工审批、日志和停止条件。产品名称中的“Agent”不能替代这些控制。

因此，这条路径适合希望较快向员工提供通用 AI 工作空间、并接受服务商托管模式的组织。评审重点不是“是不是企业版”，而是当前合同和配置下，身份、数据源、工具、状态、日志和处理地域分别如何管理。

如果流程需要复杂事务、跨多个内部系统的补偿操作、企业专有的长时间任务状态，或者界面必须嵌入核心业务系统，托管式应用通常只能承担其中一部分。此时可以保留它作为通用办公入口，把高定制流程转到路径二，而不是在一个工作空间中不断堆叠难以验证的连接器。

五、路径二：使用云端模型服务及可选的智能体开发与运行服务

第二条路径不是购买一个现成工作空间，而是获得用于建设业务系统的模型服务，并按需要叠加智能体开发与运行服务。企业可以只调用模型 API，也可以使用平台提供的编排、工具接入、状态管理等能力；无论如何，员工入口、知识检索、业务流程、工具和审批规则仍要围绕本企业的需求设计。

微软（Microsoft）的 Microsoft Foundry Agent Service 是用于构建、部署和扩展 AI 智能体的托管平台。其文档把能力拆成多个部分：Agent Runtime（智能体运行时）负责托管和扩展智能体，并管理会话、工具调用与生命周期；Toolboxes（工具箱）管理可复用工具；可观测性功能提供追踪、指标和评估；身份与安全功能结合 Microsoft Entra 身份服务、基于角色的访问控制（RBAC）和网络隔离。这个例子说明，“智能体平台”不是一个模型接口的别名，而是一组开发与运行服务。

企业如何组装云端业务应用

这条路径的实施对象不是一个“万能智能体”，而是一条可测试的业务任务链。推荐按下面的顺序建设。

1. 写清任务合同。 明确输入字段、允许读取的数据、允许执行的动作，以及什么证据算完成。对采购工单来说，完成标准应是“业务系统返回唯一工单编号”，而不是“模型说已经创建”。

2. 先建企业应用和身份入口。 员工登录企业 Web、移动端或原有业务系统，由企业应用识别用户、部门和角色。不要让浏览器直接持有模型密钥，也不要用一个高权限服务账号代表所有用户执行动作。

3. 建设带权限过滤的知识检索。 企业应用按用户权限读取制度文档，形成带来源标识的检索片段，再送给模型。模型不应获得整个文档库的无差别访问权。

4. 调用模型并约束输出。 问答可以生成自然语言；进入业务动作时，应要求模型输出固定字段结构，例如事项类型、金额、理由和缺失字段清单，并由普通程序校验类型、范围和必填项。

5. 把工具封装成最小动作。 与其提供一个“任意调用采购系统”的工具，不如提供“创建采购草稿”“查询工单状态”等边界明确的接口。每个工具都要验证调用身份、参数、目标对象和幂等标识。

6. 把审批放在执行之前。 界面向用户或审批人展示最终字段、目标系统和影响范围。审批通过后，运行时才调用工具；审批过期或任务内容改变时，应重新确认。

7. 保存状态、追踪和结果证据。 分开记录模型输入输出、任务状态、工具请求、业务回执和人工决定。设定超时、重试上限、取消、转人工和恢复策略，并用测试集持续评估制度引用和业务字段的正确性。

在微软产品组合中，模型端点可以承担推理，Foundry Agent Service 可以按需承担部分会话、工具调用、身份和追踪能力，Microsoft Entra 与 RBAC 可以参与平台访问控制。但业务规则、下游系统授权、审批有效性和完成证据仍要由企业应用定义。

但平台功能丰富，不等于业务应用已经完成。企业仍需决定：

·员工以什么身份进入系统，智能体代表谁调用下游接口；

·哪些制度、字段和工具对当前用户可见；

·哪些动作可以自动执行，哪些必须由人工审批；

·如何验证模型回答和工具结果；

·如何处理重复请求、超时、部分成功和回滚；

·保存哪些会话或任务状态，保留多久，谁能审计。

示例：企业自建采购助手如何完成一次提交

下面是概念性伪代码，用来说明控制顺序，不对应某个厂商的可直接运行 SDK：

用户请求 = “购买一台 8,000 元的研发电脑，请创建采购申请”          1. 验证用户身份，并检查其是否有“发起采购申请”权限          2. 按用户可见范围检索采购制度，保存制度版本和引用片段          3. 调用云端模型，生成固定结构的申请草稿和缺失字段清单          4. 普通程序校验金额、成本中心、物品类别和必填字段          5. 在企业界面展示最终参数，等待用户或负责人审批          6. 审批通过后，携带幂等标识调用“创建采购工单”接口          7. 读取业务系统返回的工单编号并再次查询状态          8. 有编号且状态一致 → 标记完成；否则停止、限次重试或转人工

这里的“幂等标识”可以理解为一次业务请求的唯一编号。网络超时后，系统用同一编号重试，采购系统据此判断这是不是同一次申请，避免重复创建两张工单。模型可以生成字段，但唯一编号、重试规则和最终状态核对应由确定性的应用代码处理。

还要核对数据由谁处理、在哪里保存

完成业务流程设计后，还要分层说明数据路径。员工请求先进入企业应用，应用或智能体编排与运行层读取获准数据、调用模型，再根据结果决定是否调用工具。模型输出返回后，企业应用负责把证据、处理状态和审批信息展示给用户。

微软关于由 Azure 销售的模型（Models sold by Azure）的数据、隐私与安全说明指出，客户的提示、输出、嵌入和训练数据不提供给 OpenAI 等模型提供方，也不在未经客户许可或指示时用于训练生成式基础模型。这里的“由 Azure 销售的模型”是微软通过 Azure 提供并运营的一类模型服务，不是 OpenAI 自营的 ChatGPT 或 OpenAI API。微软在 Azure 环境中托管相关模型，它们不与 OpenAI 运营的 ChatGPT 或 OpenAI API 服务交互。这个事实回答的是服务运营与数据提供对象，不能被扩大解释为“数据只存在企业自己的虚拟网络中”。

同一份文档还区分了无状态模型推理和有状态平台功能：模型本身不保存提示与输出，但 Responses（响应记录）、Threads（对话线程）、Files（文件）、向量库（可检索索引）和 Stored completions（持久化的完成结果）等可选功能可以建立数据存储。这些名称指平台中的状态或存储功能，不是不同的大模型。企业应用自己的日志、知识库和任务状态又是另一层。因此，“模型无状态”绝不等于“整套系统零保留”。

处理位置也不能只看资源名称。Global（全球范围）和 DataZone（指定数据区域范围）是模型服务的部署类型，会影响提示和响应可能在哪些地域或区域处理；它们不是存储产品名称。静态存储位置与推理处理位置是不同问题。正式设计必须分别核对部署类型、状态存储、日志、内容安全处理和企业自有数据源。

这条路径适合需要把 AI 深度嵌入业务流程、并有能力长期开发和运营应用的企业。它提供更多控制点，同时也把任务设计、工具授权、结果校验和事件响应责任交给企业。

一个可进入试运行的最小版本，至少应同时具备：员工入口、身份映射、带权限的制度检索、结构化输出校验、一个低风险工具、人工审批、结果回读、任务日志和一套失败测试。只有聊天界面和模型端点的演示，不能算这条路径已经落地。

六、路径三：自建基于本地推理运行环境          或基础设施的智能体应用

如果企业要求模型计算在员工设备或自有站点内完成，就进入第三条路径。但“本地”不是一个单一产品形态：设备端方案面向单台终端，站点集群方案面向多个用户或应用。无论选择哪一种，企业都要分清本地基础设施、容器集群、模型推理服务和智能体应用，不能把它们统称为“私有化系统”。

设备端推理

Foundry Local 面向在用户设备上运行的本地 AI 应用。官方文档说明，它提供 SDK、经过优化的模型目录和自动硬件加速，可以利用 GPU、NPU 或 CPU，在模型准备完成后离线工作；提示与模型输出在设备上处理。

这不意味着它是一套多用户服务器推理平台。官方 FAQ 明确说明，Foundry Local 主要针对单用户设备端场景，不为多用户并发排队、连续批处理和 GPU 共享而设计。首次使用时还可能下载模型或执行组件，诊断信息则要按适用产品条款核对。因此，准确说法是“设备端本地推理”，而不是笼统写成“整套系统完全私有部署”。

设备端方案：离线制度查询和材料草拟

设备端方案可以按“准备设备—分发模型—建立本地知识—离线运行—联网后受控同步”的顺序实施。

1. 核对设备能力。 根据 CPU、GPU、NPU、内存和磁盘选择可运行的模型，并测试首字延迟、完整响应时间、耗电和长文本处理能力。模型能启动不代表体验可接受。

2. 预先分发运行时与模型。 如果目标环境会离线，应在进入离线区域前完成模型、执行组件、许可证和必要依赖的下载与校验，并保存版本和哈希记录。

3. 准备本地知识包。 把获准制度转换为设备可检索的本地索引，保留文档版本、生效日期和来源。知识包应支持过期、撤回和重新发布，不能只在安装时复制一次后永久使用。

4. 在本地应用中编排任务。 应用负责接收问题、检索本地资料、调用本地模型、展示引用并保存草稿。即使模型离线运行，应用仍要校验输出并限制可访问的本地文件。

5. 分开离线草稿和联网动作。 离线时可以回答制度问题、整理材料和生成工单草稿；真正提交采购系统时，应在恢复网络后重新校验用户身份、制度版本和草稿内容，再进入审批与工具执行。

6. 管理更新和设备风险。 规定模型与知识包更新周期、丢失设备的密钥撤销、缓存清理和诊断信息策略。设备端推理减少了请求离开设备的需要，但也把模型文件、索引和本地日志带到终端安全范围内。

例如，员工出差到弱网现场前，企业应用下载已批准的采购制度包和适配模型。员工离线询问流程，应用在设备上检索制度并生成申请草稿，同时标记“尚未提交”。恢复企业网络后，应用先检查制度是否更新，再要求员工确认金额和成本中心，最后调用采购系统。这个例子中，本地模型解决的是离线阅读和草拟，不应在无法验证身份和业务状态时声称工单已经创建。

企业本地基础设施与集群推理

Azure Local 是微软提供的、延伸到客户自有环境的分布式基础设施，支持连接和断开连接的部署形态，并使用 Azure Arc（跨环境统一管理服务）作为管理控制面。它可以承载虚拟机、容器和本地 AI 工作负载，但它本身不是模型，也不自动提供智能体应用。

Azure Arc-enabled Kubernetes 用于把运行在本地、边缘或其他云中的 Kubernetes 集群接入 Azure 管理体系。连接部署中，集群内的 Arc 代理建立到 Azure 的安全出站连接，集群会在 Azure Resource Manager（Azure 资源管理服务）中显示为可管理资源。这条管理路径可以承载资源注册、配置、策略和运行状态，但不等于员工的提示和模型回答必须经过 Azure。

Foundry Local on Azure Local 则是在 Azure Local 的 Arc-enabled Kubernetes 集群中运行本地模型推理的具体组合。它以 Azure Arc 扩展安装，并使用 Kubernetes operator——一种把部署和运维规则封装为集群控制程序的机制——协调模型和部署资源；应用再通过受保护的推理端点调用模型。截至 2026 年 9 月 25 日，官方页面仍将其标为预览，并说明部署需申请访问。

站点集群方案：提供共享推理能力

集群方案不是把设备端软件搬到服务器上，而是要建设一套面向多应用的运行服务。实施时至少包括以下工作。

1. 先决定连接方式。 明确站点是否允许连接 Azure 管理控制面，还是运行期必须断开连接。这个决定会影响身份、证书、制品导入、更新、监控和故障支持方式，应在采购硬件前确定。

2. 准备集群和容量。 规划 Kubernetes 集群、GPU 或其他加速资源、共享存储、网络分区、负载上限和高可用。用代表性提示长度和并发量做容量测试，不只看模型参数规模。

3. 建立受控的软件与模型供应链。 记录模型来源、许可证、版本、校验值和批准状态；镜像、扩展包和依赖进入本地制品库前完成扫描。升级时保留回退版本。

4. 部署受保护的推理端点。 端点只接受获准应用身份访问，设置请求大小、并发、超时和配额。模型端点负责推理，不直接获得任意数据库或业务系统权限。

5. 在端点之外建设应用。 企业仍需提供用户界面、身份映射、知识检索、智能体编排、工具网关、审批、状态和日志。多个应用共用推理端点时，要隔离各自的数据、配额和日志。

6. 建立运行与恢复机制。 监控容量、延迟、错误率和模型版本，演练节点故障、模型回滚、证书过期、知识库不可用和工具部分成功。断开连接环境还要验证离线更新包和本地身份系统是否可用。

例如，某受限网络站点希望让内部员工查询制度并创建维修工单。站点内应用读取本地制度库，调用集群内推理端点生成维修描述和分类建议，再由企业编排服务校验设备编号和人员权限。负责人在本地审批入口确认后，工具网关调用站点维修系统，并把工单编号写入审计日志。如果维修系统位于外部网络，那么工具调用仍然会跨越站点边界；本地模型不会自动消除这条外部数据流。

设备端和站点集群都属于本地推理，但使用方法明显不同：

管理方式：连接部署与断开连接部署

连接部署中，本地集群承载推理工作负载，Azure Arc 参与管理。业务请求与数据流、管理控制路径应画成两条线：前者包括提示、检索片段、模型输出和工具结果；后者包括资源注册、配置、策略、扩展和运行状态。

如果运行期不得依赖公网 Azure，需要评估 Microsoft 单独定义的断开连接部署。官方文档说明，这种部署要预先导入扩展包、模型包和网络依赖，使用本地制品库与本地身份体系；文档同时注明遥测不发送给 Microsoft。它不是给普通 Arc 连接部署简单关闭网络，而是另一套制品、证书、身份、容量和运维安排。

选择时可以用一项实际演练来验证边界：在测试环境中切断外部连接，分别检查用户登录、模型推理、知识检索、工具执行、日志查看、证书校验、扩容和故障恢复是否仍能工作。某个页面仍能打开，不等于整个系统具备断开连接运行能力。

评估连接方式时，至少要回答五个问题：软件和模型如何进入环境，身份与证书如何签发和轮换，诊断信息在哪里保存，更新失败后如何回退，以及业务请求是否跨越本地边界。连接部署需要说明哪些能力依赖云端控制面；断开连接部署则要说明谁负责下载、扫描、签名、转运和导入离线制品，并证明本地身份、监控和恢复机制能够独立工作。

无论采用哪一种本地形态，企业仍需建设应用、智能体编排、知识检索、工具接入、状态管理、审批和验证，还要负责硬件、网络、容量、补丁、模型许可、软件供应链、备份和故障恢复。模型在哪里运行，只回答了整套系统中的一个问题。

七、同一个任务，在三条路径中如何流动

回到“制度与流程助手”，从业务执行顺序看，可以把同一项任务拆成七个节点：用户与身份、知识读取、模型推理、草稿与校验、人工审批、工具执行和结果证据。会话或任务状态、日志和权限控制则贯穿整条链路。

图 2 把“查制度并创建采购工单”画成三条泳道。三条路径的组件所有者不同，但关键控制顺序相同：身份和权限在前，人工审批位于写入动作之前，业务系统返回的编号或回执位于最后。

图2：同一采购工单任务在三条路径中的执行链

图中实线蓝箭头表示业务请求与数据流，灰色虚线表示管理控制路径，橙色表示审批和失败控制，绿色表示本地运行或已经取得的成功证据。右侧三条失败分支共同汇入“停止、限次重试或转人工”，说明任何路径都不能把无编号、权限不足或结果不确定的请求标记为完成。最下方的 Azure Arc 虚线只表示站点集群采用连接部署时的一种管理控制路径，不代表主要业务请求必须经过 Azure。

例如，员工要求“根据制度创建一张采购审批工单”。可靠流程不是模型直接连接工单系统，而是：

识别用户与任务          → 检索适用制度并保留出处          → 生成工单草稿          → 校验必填字段和权限          → 员工确认或审批          → 使用幂等标识调用工单接口          → 核对返回编号并记录证据          → 失败时停止、重试或转人工

模型可以参与检索、归纳和生成参数，但业务系统返回的工单编号才是“创建成功”的证据。没有授权、校验和结果回读，工具调用只能说明系统尝试过某个动作，不能证明任务已经正确完成。

八、企业如何评审和选择

项目评审可以先固定使用以下四问，避免被产品名称带偏。

其中，第四问不能只写合同中的“服务商负责平台、企业负责应用”。运行阶段还要回答失败如何暴露。一个系统即使有身份和网络控制，如果没有动作结果回读、幂等设计、重试上限、人工接管和恢复路径，仍然可能在业务层失控。

完成边界核对后，再根据不可妥协的约束筛选路径，而不是先选产品再为它寻找场景。

最终选择不应追求一条“最高级”的路径。更成熟的做法是，先把业务任务拆成数据读取、模型推理、状态保存和外部动作，再为每一环确定控制主体与证据要求。

九、提交方案前，再检查五个常见误解

在方案进入试运行或采购评审前，可以用下面五项做最后复核：

·企业版不等于私有部署。 它通常说明产品面向组织提供身份、管理或合同能力，不直接说明应用、模型、状态和基础设施都部署在企业机房。

·模型端点不等于智能体应用。 模型端点提供推理能力，业务应用、工具、状态、身份、验证和运营后台仍需由平台服务或企业补齐。

·模型提出动作不等于动作已经执行。 只有经过参数校验、授权、审批并收到业务系统的可验证结果，才能确认动作完成。

·本地推理不等于整个系统都不出域。 知识源、外部搜索、SaaS 工具、身份服务、状态存储、日志、更新和管理控制面仍可能跨越本地边界。

·企业控制更多，不等于服务商不再承担责任。 自建应用会增加企业责任，但服务商仍对其实际交付的模型服务、平台或软件承担相应的产品和合同责任。

企业真正需要的也不是一个看起来更像人的系统，而是一条可以说明、限制和审计的任务链：

谁发起，谁授权，在哪里执行，谁验证，失败后谁停止和恢复。

当这五个问题有明确答案时，托管式应用、云端自建或本地推理才从产品名称变成可评审、可运营的企业架构。

参考资料

1. OpenAI Docs：Enterprise 管理员上线

2. OpenAI Docs：应用与连接器控制

3. Microsoft Learn：What is Microsoft Foundry Agent Service?

4. Microsoft Learn：Data, privacy, and security for Models sold by Azure

5. Microsoft Learn：What is Foundry Local?

6. Microsoft Learn：What is Foundry Local on Azure Local?

7. Microsoft Learn：Foundry Local on Azure Local in disconnected environments

8. Microsoft Learn：Overview of Azure Arc-enabled Kubernetes

9. Microsoft Learn：What is Azure Local?