1. 这个项目到底在做什么：先厘清 Agent Skills 的定位

最近在捣鼓 .NET 上的 AI Agent 项目，发现很多人把 Agent Skills 和普通的函数调用（Function Calling）、插件（Plugin）混为一谈，结果一上来就踩坑。这个标题里说的"基于 Microsoft Agent Framework 集成 Agent Skills"，核心不是教你调一个 API，而是让你理解：当一个 Agent 需要"具备某种能力"时，你该怎么把能力包装成它可以自主调用的技能，并且让这个技能可以被框架统一管理、统一调度。

我自己的理解是：Agent Skills 就是把一组"原来需要你手动写死逻辑"的操作，封装成 Agent 可以按需决策、按需执行的模块。比如你的 Agent 要能查天气、要能算数学、要能操作某个文件——这些都可以做成一个 Skill。Agent 在跑任务时，会根据用户的意图，自动决定"我现在要不要调用这个 Skill"。这就是它比普通函数调用更"智能"的地方：调用与否、调用顺序、参数填充，都是模型在运行时决定的，不是你在代码里提前写死的。

那为什么选 Microsoft Agent Framework？因为它是 .NET 生态里现阶段把"Agent 运行时 + 技能注册 + 对话流程编排"结合得比较顺手的方案。你不用自己从零去搭状态机、去管理多轮上下文、去处理工具的 schema 描述，框架已经把很多脏活累活干了。对于做 .NET 的老手，或者团队里本来就以 C# 为主的工程团队，这个选型在长期维护上会比"Python 一套、.NET 一套"的混合栈省心很多。

这篇文章适合谁？适合已经跑通了一个最简单的 Agent Demo（比如能聊天、能回答几个固定问题），但不知道下一步怎么让它"真正干点活"的人。也适合架构师和技术负责人——你需要评估"把 Agent Skills 引入现有 .NET 服务"的成本和收益。文章里我不会贴完整的官方文档，而是从"我实际怎么一步步把它跑起来"的角度写，踩着坑的地方我会重点标出来。

2. 设计思路拆解：为什么是"技能注册 + 运行时调度"而不是硬编码

2.1 先搞清楚 Agent、Skill、Tool 这三者的关系

很多人一开始会被概念绕晕。我换一个生活化的类比：Agent 是一个"实习生"，你要交给他一个目标（比如"把这份数据整理成周报"）。Skill 是"这个实习生掌握的技能"（比如会用 Excel、会写 PPT、会查数据库）。Tool 则是"执行技能时用到的工具"（Excel 软件、PPT 模板、数据库连接器）。

但在 Microsoft Agent Framework 里，Skill 和 Tool 并不是严格的上下位关系。Skill 是一个更完整的"能力单元"，它可以内部包含多个 Tool 的协作；而 Tool 通常是最小的可调用单元。如果你只是给 Agent 挂一个孤立的函数，那叫 Tool；如果你把"查询数据库 → 处理结果 → 生成摘要"这一串流程打包成一个语义明确、Agent 一看就知道何时该用的模块，那才叫 Skill。

我在实际项目里一开始犯过糊涂：把每个工具函数都注册成了"Skill"，结果 Agent 在决策时出现了选择困难——待办事项一多，它自己都分不清该先调哪个、参数该按什么格式传。后来我调整思路：Skill 的粒度要跟"用户目标"对齐，而不是跟"函数粒度"对齐。比如"生成周报"是一个 Skill，内部包含"拉取数据""汇总指标""调用模板渲染"三个步骤，Agent 只需要决定"要不要生成周报"，至于里面每一步怎么串，那是 Skill 内部的事。

2.2 为什么要把 Skill 的"描述"写到位：模型是靠描述做决策的

这是我觉得最核心也最容易被忽略的一点。Agent 本身没有"读过你的代码"，它只知道你给它的 Skill 描述（Description）和参数 Schema。也就是说，你写 Description 的水平，直接决定了 Agent 会不会在正确的场景调用它。

我自己调试过印象很深的一次：一个"获取项目进度"的 Skill，我在描述里写的是"GetProjectProgress"。Agent 面对"小明今天干了什么"这种问题时，完全没触发这个 Skill，因为它觉得"这个问题和 GetProjectProgress 无关"。后来我把描述改成："当用户查询某个成员在某段时间内的工作产出、任务完成比例、里程碑状态时使用。输入参数为成员姓名和时间范围。"再试，Agent 的命中率明显提升。这个细节值得反复打磨，多花半小时写描述，比事后调 prompt 调一晚上有效得多。

2.3 选 Microsoft Agent Framework 而不自己造轮子的三个理由

第一，它帮你解决了"并发状态下 Agent 状态的隔离"。你自己写 Agent 循环时，多用户同时访问，session 状态非常容易串。框架内部的状态管理机制至少给了你一个可靠的基线，而不是让你从零开始处理并发问题。

第二，它的 Skill 注册机制和 DI（依赖注入）结合得比较顺。在 .NET 里，你本来就习惯用IServiceCollection管理依赖，Agent Framework 允许你把 Skill 作为服务注册进去，Agent 运行时再按需解析。这让 Skill 之间可以共享服务、共享配置，而不是每个 Skill 自己 new 一堆依赖。

第三，它和 Semantic Kernel 的衔接比较平滑。如果你之前已经在用 Semantic Kernel 做 prompt 或插件管理，你可以在 Agent Framework 的 Skill 内部调用 Semantic Kernel 的 function，复用已有的 prompt 资产。这一点对已经在 .NET 生态里沉淀了东西的团队特别友好。

3. 环境准备与最小工程搭建

3.1 一套能跑起来的最简环境组合

我这次用的组合是：.NET 8 + Microsoft.Extensions.AI（如果没有这个库，很多底层抽象要自己写）+ Microsoft.Agent.Framework 的预发布包。建议直接建一个 ASP.NET Core 空项目或者控制台项目都行——如果只是验证流程，控制台更轻；如果你最终要对外提供接口，ASP.NET Core 更合适。我自己的习惯是先控制台跑通，再迁到 Web API 里，因为控制台里打印 Agent 的中间思考过程更方便。

需要装的包大致如下（具体版本以官方 NuGet 上的最新预发布版为准，这里只列关键项）：

dotnet add package Microsoft.Agent.Framework --prerelease dotnet add package Microsoft.Extensions.AI --prerelease dotnet add package Microsoft.Extensions.AI.OpenAI --prerelease

如果你用的是 Azure OpenAI，再加一个Microsoft.Extensions.AI.AzureOpenAI。这里提醒一句：预发布包的 API 变动会比较频繁，不同周之间的示例代码可能对不上。我的建议是锁定一个你验证过能跑的版本，然后在工程里统一引用，不要追新追到一半发现接口全变了。

3.2 注册基础服务：让 Agent 框架先认识聊天模型

Agent Framework 本身不绑定模型厂商，它通过IChatClient这个抽象来跟模型对话。所以在搭建工程时，第一步是注册一个IChatClient到依赖注入容器里。下面是控制台程序里典型的最小配置：

using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.AI; using Microsoft.Agent.Framework; var builder = Host.CreateApplicationBuilder(args); builder.Services.AddSingleton<IChatClient>(sp => { // 这里以 OpenAI 兼容接口为例 return new OpenAIChatClient( new Uri("https://your-endpoint"), "your-api-key", "your-model-name" ); }); builder.Services.AddAgentFramework(); // 注册框架核心服务 var host = builder.Build(); await host.RunAsync();

这段代码的作用很简单：把模型客户端注册成单例，然后调用AddAgentFramework()把 Agent 运行时、状态管理、Skill 调度等核心组件注入容器。你不需要自己手动把框架的每一个接口都注册一遍，一个扩展方法搞定，这也是我为什么说框架省心的原因之一。

如果你用的是 Azure OpenAI，OpenAIChatClient换成AzureOpenAIChatClient，参数调整为 endpoint、apiKey、deploymentName 即可。接口形状基本类似，迁移成本不大。

3.3 创建第一个最简单的 Agent 实例

在注册好服务和模型之后，创建一个 Agent 只需要指定它的指令（Instruction）和名称。这里的"指令"就是 Agent 的系统提示词，决定了它的角色定位和决策边界。举一个非常简单的例子：

var agent = new Agent( id: "assistant-demo", name: "小助", instruction: "你是一个负责协助用户查询信息的助手。当你认为有必要时，可以调用技能来获取数据。" );

这里有一个经验：别把指令写得太满，给模型留出调用 Skill 的自主性。如果你在指令里写"你必须永远先调用技能再回答"，遇到无关闲聊时模型也会强行调用，反而拉低响应速度、增加 token 消耗。更好的做法是写清楚"什么情况下可以调用"，而不是"必须调用"。

4. 核心实操：一步步把一个 Agent Skill 集成进来

4.1 先写一个最简单的技能：查询本机时间

第一个 Skill 不建议做太复杂，选一个"参数少、逻辑明确、容易验证结果对错"的功能。我选的是"查询当前时间"。这样做的好处是：你能清楚地看到 Agent 是否在正确场景下调用了它，一旦调用，你也能立刻比对返回结果是否正确，从而排查是"模型决策问题"还是"代码执行问题"。

先定义一个输入和输出的类型：

public class TimeQueryInput { public string? TimeZone { get; set; } } public class TimeQueryOutput { public string CurrentTime { get; set; } = string.Empty; public string TimeZoneApplied { get; set; } = string.Empty; }

然后定义一个 Skill 类，实现框架规定的接口。不同版本的接口签名有差异，但核心思想是一致的：你告诉框架这个技能的执行函数是什么，以及它的 JSON Schema 长什么样。

下面是一个典型写法（接口用ISkill）：

public class CurrentTimeSkill : ISkill { public string Name => "GetCurrentTime"; public string Description => "获取指定时区的当前日期和时间。当用户询问现在几点、今天的日期等时间相关信息时使用。"; public JsonElement InputSchema { get; } = JsonDocument.Parse(""" { "type": "object", "properties": { "timeZone": { "type": "string", "description": "IANA 时区名称，例如 Asia/Shanghai", "nullable": true } } } """).RootElement; public async Task<SkillResult> ExecuteAsync( JsonElement input, CancellationToken cancellationToken = default) { var query = input.Deserialize<TimeQueryInput>(); var tz = string.IsNullOrEmpty(query?.TimeZone) ? "Asia/Shanghai" : query.TimeZone; var time = TimeZoneInfo.ConvertTimeBySystemTimeZoneId(DateTime.UtcNow, tz); return SkillResult.Success(JsonSerializer.Serialize(new TimeQueryOutput { CurrentTime = time.ToString("yyyy-MM-dd HH:mm:ss"), TimeZoneApplied = tz })); } }

整个过程其实就是三步：定义 schema，告诉模型"这个技能接收什么参数"；实现执行方法，真正干活；返回一个结构化结果，让模型能读懂输出。框架不关心你这个技能内部是查数据库、调 HTTP 接口还是读文件，它只需要你提供标准的输入输出边界。

4.2 把 Skill 注册到 Agent 上：这一步千万别漏

Skill 类写完之后，要把它挂在 Agent 实例上。最常用的方式是直接通过 Agent 的构造参数传入：

var agent = new Agent( id: "assistant-demo", name: "小助", instruction: "你是一个负责协助用户查询信息的助手。当你认为有必要时，可以调用技能来获取数据。", skills: new List<ISkill> { new CurrentTimeSkill() } );

这里有一个常见的坑：有人会把 Skill 注册到 DI 容器里，就以为 Agent 能自动发现它。至少在目前版本里，Agent 不会自动扫描容器中的所有 Skill，你必须显式告诉它"你这个 Agent 能用哪几个技能"。这反而是个好设计——不同 Agent 可以有不同的技能集合，避免 A 场景的 Agent 误调 B 场景的技能。

如果你有多个 Agent，又希望每个 Agent 使用统一的技能集合，可以抽一个工厂方法统一构建，比如：

public static class AgentFactory { public static Agent CreateDefaultAgent() { var skills = new List<ISkill> { new CurrentTimeSkill(), new WeatherSkill(), new ReportSkill() }; return new Agent( id: "assistant-default", name: "小助", instruction: "...", skills: skills ); } }

这样一来技能列表只需要维护一处，以后加新技能时改一个地方就够了。

4.3 运行 Agent：看看模型是怎么自主选择调用技能的

Skill 注册好之后，就可以跑对话了。为了看到内部细节，我会把ChatOptions里的工具相关设置打开，并打印每次模型返回的中间内容。下面是一段完整的控制台调用代码：

var chatHistory = new List<ChatMessage>(); while (true) { Console.Write("你："); var userInput = Console.ReadLine(); if (string.IsNullOrEmpty(userInput)) continue; chatHistory.Add(new ChatMessage(ChatRole.User, userInput)); var response = await agent.RunAsync( chatHistory, new ChatOptions { Tools = true, ToolMode = ToolMode.Auto }, cancellationToken: CancellationToken.None ); chatHistory.Add(new ChatMessage(ChatRole.Assistant, response.Text)); Console.WriteLine($"Agent：{response.Text}"); }

我实际跑的时候，输入"现在几点了"，模型返回了类似这样的过程：先解析出用户意图是查时间，然后决定调用GetCurrentTime技能，参数里的 timeZone 没有显式给出，于是模型用了默认值。最终 Agent 把技能的返回结果组织成一句人话："当前时间是 2025-06-01 14:23:45（Asia/Shanghai）。"

这里要注意的一个细节是：在ToolMode.Auto模式下，模型并不是"必定调用"技能，而是"按需调用"。如果你希望强制先调用某个技能再做回答，可以把 mode 改成ToolMode.Force并指定工具名称。但在多技能场景下，我更推荐 Auto，因为强制调用会压制模型的自主判断力。

4.4 用一个稍微复杂的 Skill 演示"多步骤能力打包"

只查时间太简单，我们升级一下：做一个"查询项目进度并生成摘要"的 Skill。这个 Skill 内部包含两个步骤——先从模拟的数据源拉取进度数据，再根据数据生成一段摘要文本。关键是：这两步对模型都不透明，模型只看到"我调用了一个技能，它返回了一段摘要"。

实现上，我模拟了一个数据源，用一个字典存储成员的任务完成情况：

public class ProjectProgressInput { public string MemberName { get; set; } = string.Empty; } public class ProjectProgressOutput { public string Summary { get; set; } = string.Empty; } public class ProjectProgressSkill : ISkill { private static readonly Dictionary<string, List<(string Task, int Percent)>> Data = new() { ["张三"] = new() { ("需求评审", 100), ("接口开发", 80), ("联调测试", 40) }, ["李四"] = new() { ("UI 设计", 100), ("组件封装", 90), ("文档编写", 60) } }; public string Name => "GetProjectProgress"; public string Description => "查询指定成员在当前迭代中的任务完成度和整体进度摘要。当用户询问某人干了什么、进度如何时使用。"; public JsonElement InputSchema => JsonDocument.Parse(""" { "type": "object", "properties": { "memberName": { "type": "string", "description": "成员姓名" } }, "required": ["memberName"] } """).RootElement; public async Task<SkillResult> ExecuteAsync(JsonElement input, CancellationToken ct) { var req = input.Deserialize<ProjectProgressInput>(); if (req is null || !Data.ContainsKey(req.MemberName)) { return SkillResult.Failure("未找到该成员的数据"); } var tasks = Data[req.MemberName]; var avg = tasks.Average(t => t.Percent); var summary = $"{req.MemberName} 当前迭代共 {tasks.Count} 个任务，平均完成度 {avg:0}%，其中已完成 {tasks.Count(t => t.Percent == 100)} 个。"; return SkillResult.Success(JsonSerializer.Serialize(new ProjectProgressOutput { Summary = summary })); } }

这个例子想说明一件事：Skill 内部可以是任意复杂度的逻辑，但暴露给模型的一定是一个语义清晰的"动作"。模型不需要关心你从哪个表查数据、怎么算平均值，它只需要知道"查进度"这个动作返回了什么结论，然后基于结论回答用户。这其实就是 Agent Skills 跟普通 API 接口最大的差别——API 是给程序员用的，Skill 是给 Agent 用的。

5. 实操中的坑与排查技巧：这些问题我基本都踩过

5.1 描述写得不够好，模型就是不调用你的 Skill

这是最隐蔽、也最让人抓狂的问题。表现是：你的 Skill 代码完全正确，注册也没问题，但运行起来模型就是视而不见。排查思路特别简单——先问自己：如果我是模型，我只看这个技能的 Name 和 Description，我能判断出"什么场景该用它"吗？

我自己曾经写过这样一个描述："Processes data related to projects." 这种描述给程序员看还行，但给模型看等于没说。模型不知道"related to projects"具体指什么，自然不敢贸然调用。

改进后的写法是："当用户希望获取项目列表、查询某个项目的状态、更新项目信息时，调用此技能。如果用户只是闲聊或询问与项目无关的内容，请不要调用。"

记住一个原则：描述里要写清楚触发器（trigger），也要写清楚非触发器（non-trigger）。光有正向触发条件还不够，负向排除条件能显著降低误调用率。

5.2 参数 Schema 写错了，模型传参传得乱七八糟

Schema 是模型生成参数的唯一依据，它必须清楚、完整、无歧义。最常见的问题是：忘了标记required，导致模型漏传必填参数；或者参数描述写得太笼统，模型不知道该填什么格式。

我建议每个参数都写明三件事：类型、含义、取值范围/格式。比如：

{ "type": "object", "properties": { "memberName": { "type": "string", "description": "成员姓名，必须是系统内已存在的成员，例如：张三", "minLength": 1 }, "startDate": { "type": "string", "description": "开始日期，格式为 YYYY-MM-DD，例如 2025-06-01" } }, "required": ["memberName"] }

模型不是人，它没有"常识"来判断字段含义，你写得多细，它就能传得多准。这跟你在团队里带新人一样：需求文档写不清楚，新人做出来的东西一定跑偏。

5.3 技能内部抛异常，Agent 直接"懵"了

有一种情况是：技能逻辑在某个边界条件上抛了异常，Agent 拿到异常信息后不知道怎么处理，于是开始"编"答案。这非常危险——模型会一本正经地告诉你一个错误的结果，而你完全看不出它调用技能失败了。

解决方法是：在 Skill 内部做好异常捕获，把错误转换成标准化的返回值，而不是让异常直接冒泡到 Agent 运行时。

public async Task<SkillResult> ExecuteAsync(JsonElement input, CancellationToken ct) { try { // 业务逻辑 } catch (Exception ex) { return SkillResult.Failure($"获取数据失败，原因：{ex.Message}"); } }

当模型收到一个Failure结果时，它的反应通常是"技能执行失败，我如实告诉用户并询问下一步"，而不是强行编造一个答案。这虽然不是 100% 保险，但比让异常裸奔好太多了。

5.4 多技能冲突：模型选错了技能

当你有三五个技能时，模型偶尔会把两个相似的技能搞混。比如你有"查询天气"和"查询空气质量"两个技能，用户问的是"今天适合跑步吗"，模型可能调用天气技能，也可能调用空气质量技能。

解决手段有两个。第一是加强描述的区分度，明确说"这个技能只负责 X，不负责 Y"。第二是考虑合并技能——如果两个技能经常被同时调用，干脆合并成一个"查询户外运动条件"的技能，内部同时查天气和空气质量，对外只暴露一个入口。技能不是越多越好，而是越贴合用户意图越好。

5.5 官方示例版本不一致

由于这个框架还处于快速迭代期，我在网上找资料时经常遇到"示例代码跟我本地编译不过"的情况。这不是你写错了，多半是包版本升级导致接口签名变了。碰到这种情况，我的建议是：

先看你本地实际安装的包版本，再看该版本的官方文档或 GitHub 示例，别拿一个月前的教程硬套。如果你只是验证概念，直接锁定一个已知可用的版本号，把--prerelease换成具体版本再装一遍。

6. 参数与经验参数速查：我把常用的配置项都整理成了一份表

6.1 Runtime 与模型参数参考

温度这个参数我单独说说。Agent 场景和纯文本生成场景不同，Agent 需要的是"确定性决策"，而不是"创造性表达"。温度太高，模型可能今天调技能 A、明天同样的提问却调技能 B，行为不可控。所以 Agent 类的温度我一般压到 0.3 以下，宁可它回答得干巴巴，也不要让它随机发挥。

6.2 我总结的 Skill 描述模板

下面是我自己写技能描述时常用的模板，不一定适合所有场景，但可以当起点：

当用户[触发场景描述]时，使用此技能。 输入参数包括：[参数清单及格式]。 返回结果为：[返回内容说明]。 如果用户只是[排除场景]，不要调用此技能。

举个例子：

当用户询问"某个成员的迭代进度""任务完成情况""开发状态"时，使用此技能。 输入参数包括：成员姓名（必须为系统的成员）。 返回结果为：该成员的任务列表和平均完成度摘要。 如果用户只是问"项目整体"或"组织架构"，不要调用此技能。

这套模板的好处是：它强迫你把"决策边界"想清楚，而不是随手写一句"GetProgress"糊弄模型。很多人技能命中率低，根源不是模型笨，而是你根本没给它足够清晰的决策依据。

7. 进阶思路：如何让 Agent Skills 在真实项目中发挥更大价值

7.1 给技能加上"缓存"和"降级"策略

真实项目里，很多技能调用是重复的。比如用户的 Agent 每次都要查同一份报表数据，如果每次都实时拉取，响应慢不说，还可能把下游系统压垮。我的做法是在技能内部加一层缓存：数据源返回后缓存 5 分钟，5 分钟内的重复查询直接走缓存。

降级策略也很重要：当技能依赖的外部服务挂了，不要让 Agent 直接报错，而是返回一个降级结果（比如"当前数据源暂时不可用，以下为 2 小时前的快照"）。模型拿到这个降级结果，会诚实地告诉用户"数据不是最新的"。这比一个冷冰冰的错误提示体验好很多。

7.2 技能的"多轮状态"怎么管理

有些技能天然需要多轮交互，比如"下单"技能，用户可能先说"我要买一个白色的杯子"，Agent 需要确认颜色、确认数量、确认地址，最后才真正下单。这时你不能让"下单"技能在一轮内完成所有事，而要让 Agent 跟用户多轮澄清。

我的经验是：把"下单"拆成两个技能——"收集订单信息"和"确认并提交订单"。第一个技能负责解析用户意图、生成一个待确认的订单对象；第二个技能只负责最终提交，并且要求参数里带上"用户已确认"的标记。这样既避免了一次性要求用户提供太多信息，也让流程更可控。

框架自带的状态管理机制可以帮你保存对话上下文，但技能内部如果依赖中间状态（比如用户选了颜色还没选数量），你需要把状态存到技能内部的服务里，而不是依赖模型去"记住"。因为模型的上下文窗口再大，也是有限的，而且每次调用的 token 都会消耗成本。

7.3 从"单技能"到"技能编排"：让技能之间互相协作

更进阶的玩法是：让 Agent 的某一个技能内部去调用另一个技能。这在框架里是允许的，只要你在技能实现里注入ISkillExecutor或者直接拿到其他技能实例。

举个例子：我有一个"生成周报"技能，它内部需要先调用"查询项目进度"技能拿到数据，再调用"渲染 Markdown"技能把数据变成周报格式。对模型来说，它只需要决定"要不要生成周报"；至于周报内部需要哪些数据、怎么渲染，都是技能内部的事。

这种"技能组合拳"模式，我觉得是 Agent Skills 真正拉高智能上限的地方。它让 Agent 不是"会一两个孤立的工具"，而是"具备完成一个完整工作流的能力"。

7.4 多 Agent 场景下如何共享技能库

如果你有多个 Agent（比如客服 Agent、运维 Agent、数据分析 Agent），它们之间的技能肯定有重叠，也有各自私有的部分。我的建议是把技能拆成公共技能和私有技能两类。公共技能放在一个共享的项目目录里，通过 DI 注册一次；私有技能各自挂在对应 Agent 下。

这样既能减少重复代码，又能确保每个 Agent 的行为边界清晰——客服 Agent 不会去调用运维 Agent 的日志查询技能。框架在技能注册上没有做强制隔离，所以这个边界要靠你自己的组织方式来保证。

8. 关于这套方案，我最后想聊几句

说实话，Agent Skills 这个概念并不神秘，本质上就是把"工具调用"做得更规范、更语义化。但它的价值恰恰体现在这种"规范化"上：当你把技能描述、参数 Schema、错误处理、超时控制都做扎实之后，你得到的不仅仅是一个"能调 API 的聊天机器人"，而是一个"能在复杂任务里自主拆解步骤并逐步执行的智能体"。

从实际效果看，真正拉开两个 Agent 项目体验差距的，往往不是模型选得多强，而是技能体系设计得多合理。模型是所有人的同一起跑线，但"把业务能力封装成一套 Agent 能理解的技能库"这件事，每个团队做出来的质量千差万别。

如果你现在正准备开始做，我的建议是：先挑一个哪怕很简单的技能（比如查时间、查天气）完整跑通注册到调用的流程，然后马上做一个参数稍微复杂一点、内部逻辑稍微多一点的技能（比如查询项目进度并生成摘要）。这两个技能跑完之后，你对 Agent Skills 的掌控感会完全不同。

最后留一个小技巧：做技能描述时，你可以在草稿里放两三个"用户可能会问的示例问题"，然后看这些问题是否都能从你写的描述里推断出"该调用这个技能"。如果有一个示例问题连你自己都觉得模糊，那就是描述需要补充的信号。这个技巧我几乎每次都用，省去了很多来回调试的功夫。