Microsoft Foundry Skill

5天前发布 1 0 0

覆盖 Microsoft Foundry 代理、模型、项目、评测、优化、微调、监控、权限、配额和故障诊断的端到端路由。

收录时间:
2026-09-19

Microsoft Foundry Skill 是什么

Microsoft Foundry Skill 是 Microsoft 官方的总入口 Skill,把 Foundry 项目、AI Services 资源、托管代理、提示代理、模型部署、评测、监控、优化、微调、配额与 RBAC 等任务路由到不同子流程。它强调先识别用户意图和已有项目状态,再只加载真正相关的参考,避免用一条庞大通用流程处理所有 Foundry 工作。

适用场景与选择边界

适合从零创建或继续开发 Foundry 代理、部署和调用代理、建立 CI/CD、运行批量或持续评测、从生产轨迹整理数据集、分析可观测性、部署与微调模型,以及处理容量和权限。普通 Azure Functions、App Service 或非 Foundry 的通用 Azure 部署,应分别交给专用 Azure Skills。

核心能力与工作机制

入口内含 deploy、cicd、invoke、routine、observe、insights、trace、troubleshoot、validate、create、agent-optimizer、eval-datasets、project、resource、private-network、models、quota、rbac 与 finetuning 等路由。它还能根据 azd 服务、.foundry 元数据文件和环境变量定位代理根目录、环境、项目端点、代理名称与版本。

实际工作流

先完成依赖检查并确定目标工作区与环境;新建托管代理走快速开始或高级创建,已有代码则进入创建、部署、调用和观察链路。评测与优化从 eval.yaml、轨迹和元数据读取上下文;生产故障先调用再看日志和遥测。任何部署、权限或资源操作前都要确认目标订阅、项目和环境。

输入、输出与交付物

输入可能是代理源码、azure.yaml、eval.yaml、.foundry/agent-metadata 文件、Foundry 项目端点、模型需求、训练数据或生产轨迹。输出随任务而异,包括代理脚手架、部署版本、调用结果、评测报告、优化候选、数据集、监控洞察、模型部署与权限配置;入口本身负责路由,不假装一次完成所有子任务。

依赖、账号与权限

常见依赖包括 Azure 登录、azd 与 Foundry 扩展、正确的订阅和项目权限,以及代理项目的 Python 或容器环境。模型部署和微调还依赖区域容量、配额、训练数据与费用预算。环境值应从 azd 和元数据逐层解析,不应把密钥写入仓库或提示词。

限制与安全风险

Foundry 操作可能创建计费资源、发布新代理版本、修改 RBAC、上传训练数据或触发大规模评测。选择错环境会影响生产代理;自动优化候选也不能未经审查直接替换线上指令。来源特别把 validate 子流程限制为用户明确要求时才使用,不能偷偷把它插入其他流程。

适合谁使用

适合构建 Azure 上 AI 代理与模型平台的开发者、MLOps、平台团队和评测负责人。只需简单聊天调用的用户可使用 invoke 路线;负责上线治理的人更适合 deploy、observe、trace、eval-datasets 和 CI/CD 组合。

上手与验收建议

先明确要处理的是资源、项目、模型、提示代理还是托管代理,并说明已有代码、环境和最终交付。建议先在开发环境完成创建、调用与小规模评测,再进入部署和持续监控。验收要同时核对目标环境、代理版本、调用结果、评测指标、日志与费用,不只看部署命令是否返回成功。

来源、版本与许可

依据 microsoft/azure-skills 固定提交中的完整 Microsoft Foundry Skill、skills.sh 详情和 MIT 许可证整理。官方清单没有中文展示名,导航保留官方英文标题。

常见问题

1. 它是单一操作 Skill 还是任务路由器?

它是 Foundry 领域的总入口与路由器。创建、部署、调用、评测、追踪、故障诊断、模型部署和微调各有专门子流程,入口先判断用户意图和项目状态,再加载对应资料。

2. 新建托管代理应选择哪条路线?

标准端到端场景走 quick-start-hosted,包含脚手架、资源、部署和冒烟测试;已有代码、迁移、A2A、连接定制或快速流程失败时,改走高级 create,再接 deploy 与 invoke。

3. 如何定位要操作的代理项目?

单个 azd agent 服务使用其 project 文件夹;多个服务必须让用户选择;没有 azd 服务时,再查找含 agent-metadata 文件的 .foundry 目录,不能凭文件名随意挑一个。

4. 如何选择开发、测试或生产环境?

优先采用用户明确指定的环境,其次读取 azd 环境与元数据默认值。若多个环境都可能匹配且没有确定规则,就应询问,不能把本地默认环境自动当成生产目标。

5. 支持哪些评测和优化工作?

observe 可运行批量评测、分析失败、比较版本和持续监控;agent-optimizer 面向现有 Python 托管代理;eval-datasets 可从轨迹生成有版本和血缘的数据集并追踪回归。

6. Foundry validate 会自动加入每次部署吗?

不会。官方入口明确要求只有用户点名验证子流程,或明确要求按该最佳实践验证托管代理代码时才使用;不能为了显得更完整而主动塞进无关工作流。

7. 模型部署失败时只需要换区域吗?

不一定。应结合模型版本、SKU、容量、配额、区域可用性、内容安全配置与权限判断。统一模型部署路由可在预设、定制和容量发现之间选择,而不是盲目反复重试。

8. 上线后如何验证代理真的可用?

至少应执行目标环境调用或冒烟测试,并结合日志、App Insights 轨迹和评测结果核对正确性、延迟与失败。部署命令成功只说明基础操作完成,不代表代理质量达标。

数据统计

相关导航

暂无评论

none
暂无评论...