2026 年企业 Agent 上线前，Microsoft Foundry Agent Service 怎么验收？

开发环境能运行，但生产链路未验证：先按端到端证据验收，关键项缺证据就只进受控试点。
适用条件：你正准备将 Microsoft Foundry Agent Service 用于企业试点或生产，并需要把技术检查结果交给上线审批人。

负责部署的工程师，可以按模块收集验收证据。
负责上线审批的平台负责人，可以据此区分放行、补验和暂缓。
参与数据与安全评审的人员，可以重点核对身份、网络和数据流向。

Microsoft Foundry Agent Service 验收：先划清发布边界

本清单用于上线前技术验收，不代替组织自己的合规、安全或风险审批。微软文档描述了从创建、测试、追踪到发布和监控的 Agent 生命周期；本地运行或 Playground 测试只是其中一段，不能代替已发布端点的生产调用验证。官方生命周期说明

这里最容易漏掉的，是开发阶段与发布后可能使用不同身份或权限范围。你应以实际发布对象和真实调用方为准，而不是把开发项目中的授权结果直接当成生产证据。Foundry 的发布与部署方式、可用角色及字段可能因 Agent 类型和当前对象模型而不同，具体状态名称以对应官方文档为准。发布 Agent 的说明

发布与调用证据

把“已部署”拆成可以复查的请求链路：谁调用了哪个端点、端点实际提供哪个版本、请求使用什么身份，以及返回结果是否符合预期。对托管 Agent，微软部署文档提供查看 Agent 和版本信息的方式；验收时应保存与你的部署方法相匹配的版本与端点记录。托管 Agent 部署与验证

准备三类调用样例，并记录请求、身份、响应或错误信息：

• ✅ 有效请求：用预期生产调用身份访问稳定端点，确认返回结果来自预期 Agent。
• ⚠️ 无效输入：提交不符合业务约束的输入，核实处理结果是否可解释、可追踪。
• ❌ 未授权请求：使用未获授权的身份尝试调用，确认访问被拒绝，并保留拒绝证据。

端点稳定不等于所有请求都能成功。通过标准应包括“允许的身份能按预期调用”与“未授权身份不能调用”；不要用未经来源支持的延迟、成功率或并发数字代替这些行为证据。

身份、权限与数据边界

为每条调用路径画一张权限表：调用方身份、Agent 运行身份、工具连接身份、目标资源、授权范围、授权负责人。若只需要调用 Agent 的用户或服务主体，应核查是否采用了适合调用场景的最小权限角色；开发、管理和调用端点是不同的访问需求，不能默认都发相同权限。Foundry RBAC 角色与范围说明

重点复核两类隐性边界：

• 身份边界：发布后实际使用的 Agent 身份，是否已获得访问模型、存储或外部工具所需的授权？开发身份下有效的角色分配，不应被推定为发布身份也有效。Agent 身份及授权说明
• 数据边界：提示内容、会话状态、检索结果和工具输出分别流向哪里？Agent Service 的数据处理与存储方式会随功能和配置而变；外部工具也可能适用自己的数据处理条款。数据、隐私与安全说明

别把“使用托管服务”理解成“数据不会经过其他资源”。如果 Agent 会调用外部工具，你要检查发送了什么数据、由什么身份认证、工具侧如何处理，并确认这些流向符合组织边界要求。工具返回内容还应按不可信输入处理；对会触发关键操作的结构化结果，先做格式与字段校验。Agent 工具安全实践

网络检查也要按路径逐条做，不能只看 Foundry 项目的一项网络设置。可选网络方案和验证方法取决于资源配置；如果还要发布到 Microsoft 365 或 Teams，相关协议的网络可达性可能与私有调用路径不同，须按实际发布方式复核。Foundry Agent 网络选项；Microsoft 365 与 Teams 发布网络说明

故障观测与版本恢复

验收不是只证明正常路径可用，还要证明失败后有人能定位。先确认部署状态、应用日志和调用失败信息是否可查询，再准备一份正常运行记录和一份受控失败记录。对于需要查看 Agent 追踪或指标的团队，也要核实关联的监控资源和访问权限；相关监控能力依赖配置与权限，不能把“日志功能存在”当成“当前团队已经看得到日志”。Foundry Agent 监控说明

对回退不要停留在“控制台里看得到旧版本”。核对当前 Agent 类型和发布方式是否支持你计划采用的版本恢复路径，再实际演练一次：谁能操作、操作后端点指向哪里、如何验证旧版本恢复可用。托管 Agent 的版本和端点行为有具体配置条件，不应据某一种部署方式推断所有项目都能以相同方式回退。

Agent 部署检查清单：七步留下可复核记录

1. 固定验收对象：记录项目、Agent、部署类型、发布端点、协议及预期调用方。
2. 核对发布信息：保存当前发布状态与版本标识；确认信息来自实际部署对象，而非本地配置文件。
3. 执行调用测试：按成功请求、无效输入和授权失败准备测试样例，留存请求与响应证据。
4. 复核权限范围：列出调用方、Agent 与工具各自的身份，核对授权资源与范围。
5. 画出数据和网络路径：标注模型、存储、检索源、外部工具及入口之间的流向；明确仍需组织审批的边界。
6. 验证可观测性：分别检查正常调用和受控失败能否在团队有权访问的位置查到，并确认记录足以关联到待排查链路。
7. 演练变更与回退：比较候选版本与已知可用版本，在受控环境验证回退权限、端点状态和调用结果。

如果你的团队还需要核对部署准备和访问方式，可以从本站的基础设施说明和帮助中心查看相应信息；这些内容不能替代 Microsoft Foundry 的项目角色、网络和数据配置验收。

常见验收问题

发布端点能调用，但是否代表可以放行？

不代表。还要从预期生产调用身份验证实际发布版本，检查未授权调用是否被拒绝，并确认请求与失败都能留下可供团队查询的证据。端点可达只能证明链路的一部分，不等于权限边界、数据路径或回退条件都通过。

网络已配置为私有，是否还要核对工具和渠道？

要。分别检查 Agent 到模型、存储、检索源与外部工具的路径，并确认调用端使用的协议和渠道是否有不同的可达性要求。网络方案要按当前项目和集成方式验证；不能仅凭一项私有网络设置推断整条链路均为私有。

旧版本还在列表中，是否已证明能够回退？

没有。列表只能证明你看到了版本记录；还要按实际部署方式确认可用的恢复路径，并在受控环境演练。记录执行权限、端点最终版本和恢复后的调用结果，才能证明团队在需要时知道如何操作且能验证结果。

放行记录与临时测试环境

为每项检查标记“通过”“待验证”或“不通过”，同时写明证据位置、负责人和处理方式。关键身份授权、数据流向或回退流程尚未验证时，只保留边界明确的受控试点；涉及敏感数据或不可逆操作时，先暂缓上线，等责任人完成复核再重新判断。

如果你目前靠开发者共用的本地电脑测试，环境差异和本地凭证管理会让复测与交接更难；但租用 Mac 也不能替代 Foundry 的云端身份、网络和生产回退验收。只有当团队确实需要独立的 macOS 客户端、浏览器或命令行测试环境时，才适合考虑Kvmjet 的 Mac 云端环境作为临时测试工具；已有稳定 CI 环境、无需 macOS 验证，或需要长期固定重负载及物理接口的团队，不必为了这份验收清单租用 Mac。