Semantic-Kernel | The .NET Blog

.NET的Agent Skills变得真正灵活了

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

如果你一直在用Microsoft Agent Framework构建代理，那你已经熟悉流程了：定义技能，连接到provider，让代理决定调用哪个。新的是你如何创建这些技能——灵活性的提升非常显著。

最新更新引入了三种agent skill编写模式：基于文件的、基于类的和内联代码定义的。三种都连接到单一的 AgentSkillsProviderBuilder，意味着你可以自由混搭，无需路由逻辑或特殊粘合代码。让我带你了解每种模式以及何时使用。

基于文件的技能：起点

基于文件的技能顾名思义——磁盘上的一个目录，包含 SKILL.md 文件、可选脚本和参考文档。给代理添加新能力最直接的方式：

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

SKILL.md 的frontmatter声明技能名称和描述，指令部分告诉代理如何使用脚本和参考：

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

然后用 SubprocessScriptRunner.RunAsync 连接脚本执行：

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

代理自动发现技能并在需要检查账户状态时调用配置脚本。干净简单。

基于类的技能：通过NuGet分发

这里对团队来说变得有趣了。基于类的技能继承自 AgentClassSkill<T> 并使用 [AgentSkillResource] 和 [AgentSkillScript] 等属性，让框架通过反射发现一切：

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

妙处在于团队可以将其打包为NuGet包。你添加到项目中，放入builder，它就能和基于文件的技能一起工作，无需协调：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

两个技能都出现在代理的系统提示中。代理根据对话决定使用哪个——不需要路由代码。

内联技能：快速桥接

你知道那个时刻吗，另一个团队正在构建你需要的技能，但要到下个sprint才能完成？AgentInlineSkill 就是你的桥梁：

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

和其他技能一样添加到builder：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

当NuGet包最终发布时，你只需将内联技能替换为基于类的版本。代理不会注意到区别。

但内联技能不仅仅用于桥接。当你需要在运行时动态生成技能——想想从配置加载的每个业务单元一个技能——或者当脚本需要捕获不属于DI容器的本地状态时，它们也是正确的选择。

脚本审批：人在回路中

对我们构建生产代理的.NET开发者来说，这是真正打开部署讨论的部分。有些脚本有实际后果——给某人注册福利、查询生产基础设施。开启 UseScriptApproval，代理在执行任何脚本前会暂停：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

当代理想执行脚本时，它会返回一个审批请求。你的应用收集决定——批准或拒绝——代理相应继续。在受监管的环境中，这就是"我们可以部署这个"和"法务说不行"之间的区别。

为什么这种组合很重要

真正的力量不在于任何单一模式——而在于组合。你可以：

用基于文件的技能从小处开始，迭代指令，不写C#就能发布
将可复用的技能作为NuGet包分发，其他团队一行代码就能添加
当现在需要某样东西时，用内联技能填补空白
用谓词过滤共享目录，让代理只加载应该加载的
为触及生产系统的脚本添加人工监督

这一切都通过 AgentSkillsProviderBuilder 组合。没有特殊路由，没有条件逻辑，没有技能类型检查。

总结

.NET中的agent skills现在拥有了真正灵活的编写模型。无论你是用基于文件的技能做原型的独立开发者，还是通过NuGet分发打包能力的企业团队，这些模式都能适配。脚本审批机制使其在需要人工检查点的环境中也能投入生产。

查看原始公告、Microsoft Learn上的Agent Skills文档和GitHub上的.NET示例开始动手吧。

Microsoft Agent Framework 正式发布 1.0 — 这些才是 .NET 开发者真正需要关注的

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

本文为自动翻译。如需查看原文，请点击此处。

如果你一直在关注 Agent Framework 从早期 Semantic Kernel 和 AutoGen 时代走来的历程，这次的消息意义重大。Microsoft Agent Framework 刚刚发布了 1.0 版本 — 生产就绪、API 稳定、长期支持承诺。它同时支持 .NET 和 Python，并且真正可以承载实际工作负载。

让我跳过公告的噪音，专注于你用 .NET 构建 AI 驱动应用时真正重要的内容。

简短版本

Agent Framework 1.0 将之前的 Semantic Kernel 和 AutoGen 统一为一个开源 SDK。一个代理抽象。一个编排引擎。多个 AI 提供商。如果你之前一直在 Semantic Kernel（企业模式）和 AutoGen（研究级多代理工作流）之间来回切换，现在可以停了。这就是那个唯一的 SDK。

入门简单得几乎不公平

这是一个在 .NET 中运行的代理：

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

就这些。几行代码，你就有了一个在 Azure Foundry 上运行的 AI 代理。Python 的等效代码同样简洁。随着需求增长，逐步添加函数工具、多轮对话和流式输出 — API 表面会平稳地扩展，不会变得奇怪。

多代理编排 — 这才是真正的核心

单个代理对演示来说够了，但生产场景通常需要协调。Agent Framework 1.0 附带了经过实战考验的编排模式，直接来自 Microsoft Research 和 AutoGen：

顺序执行 — 代理按顺序处理（写手 → 审核 → 编辑）
并发执行 — 并行分发给多个代理，汇聚结果
移交 — 一个代理根据意图委托给另一个代理
群组聊天 — 多个代理讨论并收敛到一个解决方案
Magentic-One — 来自 MSR 的研究级多代理模式

所有这些都支持流式处理、检查点、人机回路审批以及暂停/恢复。检查点部分至关重要 — 长时间运行的工作流在进程重启后依然可以恢复。对于我们这些用 Azure Functions 构建过持久工作流的 .NET 开发者来说，这感觉很熟悉。

最重要的功能

以下是我认为值得了解的要点：

中间件钩子。 你知道 ASP.NET Core 有中间件管道吗？同样的概念，但用于代理执行。拦截每个阶段 — 添加内容安全、日志记录、合规策略 — 而无需触碰代理的提示词。这就是让代理达到企业级标准的方式。

可插拔内存。 对话历史、持久键值状态、基于向量的检索。选择你的后端：Foundry Agent Service、Mem0、Redis、Neo4j，或者自己实现。内存是将无状态的 LLM 调用变成真正能记住上下文的代理的关键。

声明式 YAML 代理。 在版本控制的 YAML 文件中定义代理的指令、工具、内存和编排拓扑。通过单个 API 调用加载和运行。这对于想要在不重新部署代码的情况下迭代代理行为的团队来说是颠覆性的。

A2A 和 MCP 支持。 MCP（Model Context Protocol）让代理能够动态发现和调用外部工具。A2A（Agent-to-Agent 协议）实现跨运行时协作 — 你的 .NET 代理可以与其他框架中运行的代理进行协调。A2A 1.0 支持即将推出。

值得关注的预览功能

1.0 中有些功能以预览形式发布 — 功能可用但 API 可能会演进：

DevUI — 一个基于浏览器的本地调试器，用于实时可视化代理执行、消息流和工具调用。可以把它想象成 Application Insights，但用于代理推理。
GitHub Copilot SDK 和 Claude Code SDK — 直接从编排代码中使用 Copilot 或 Claude 作为代理工具。在同一工作流中将编程代理与其他代理组合在一起。
Agent Harness — 一个可定制的本地运行时，为代理提供对 shell、文件系统和消息循环的访问。可以理解为编码代理和自动化模式。
Skills — 可复用的领域能力包，为代理提供开箱即用的结构化能力。

从 Semantic Kernel 或 AutoGen 迁移

如果你有现有的 Semantic Kernel 或 AutoGen 代码，有专门的迁移助手可以分析你的代码并生成逐步迁移计划。Semantic Kernel 迁移指南和 AutoGen 迁移指南会引导你完成所有步骤。

如果你一直在使用 RC 包，升级到 1.0 只需更改版本号。

总结

Agent Framework 1.0 是企业团队一直在等待的生产里程碑。稳定的 API、多提供商支持、真正能在大规模下运行的编排模式，以及从 Semantic Kernel 和 AutoGen 的迁移路径。

该框架已在 GitHub 上完全开源，你今天就可以通过 dotnet add package Microsoft.Agents.AI 开始使用。查看快速入门指南和示例来动手实践。

如果你一直在等待"可以安全用于生产"的信号 — 就是现在。