.NET+AI | Agent Skills | Inline Skill 如此轻快，带你体验 Agent Skills 的魅力
以下内容选自我精心打造的《.NET+AI | 智能体开发进阶》课程，如需系统学习，不妨阅读原文了解详情。
很多人第一次接触 Agent Skills，会把它理解成“给大模型多挂几个工具”。
这个理解不能说错，但还不够。因为在 MAF 里，Skill 不只是一个可调用函数，更是一种让 Agent 感知、选择并使用能力的组织方式。
如果要给整个 Agent Skills 体系找一个最适合入门的起点，我会选 Inline Skill。
原因很简单：它不一定最强，但一定最快。
一、为什么 Inline Skill 是最好的第一站？
Inline Skill 最大的特点，不是复杂，而是轻。
它通常直接写在当前示例或业务代码附近，不需要先搭完整文件结构，也不需要先把 Skill 做成独立模块。对于刚接触 Agent Skills 的开发者来说，这种方式几乎是最自然的：先把能力接进来，先让 Agent 跑起来，再考虑后续怎么治理。
换句话说，Inline Skill 解决的不是“如何把 Skill 做得最工程化”，而是“如何最低成本地把 Skill 用起来”。
这也是为什么它特别适合：
• 课堂演示
• Demo 示例
• PoC 验证
• 新能力试验
• 小范围业务探索
在这些场景里，速度比结构更重要，跑通比完美更重要。
二、Inline Skill 到底在做什么？
很多人会把 Inline Skill 理解成“把一段方法暴露给模型”。
这句话只说对了一半。
更准确地说，Inline Skill 是把一个原本只存在于当前代码上下文里的能力，包装成 Agent 可以识别和使用的 Skill。模型在回答问题时，不是无脑执行这段代码，而是会结合当前问题、Skill 描述和 Agent 指令，判断要不要调用它。
也就是说，Inline Skill 的重点不只是“执行”，而是“让能力进入 Agent 的决策链路”。
比如在跨境物流场景里，你可以先内联一个最小换算能力，让 Agent 回答里程问题：
#pragma warning disable MAAI001 using Microsoft.Agents.AI; using Microsoft.Extensions.AI; var unitSkill = new AgentInlineSkill( frontmatter: new AgentSkillFrontmatter( "unit-converter", "Convert miles to kilometers for logistics questions."), instructions: "当用户询问里程换算时，调用 convert-mile-to-km 并返回原始值、系数和结果。") .AddScript( "convert-mile-to-km", "将英里换算为公里。公式：kilometers = miles * 1.60934", (double miles) => JsonSerializer.Serialize(new { miles, factor = 1.60934, kilometers = Math.Round(miles * 1.60934, 4) })); var provider = new AgentSkillsProvider(unitSkill);这个例子里，Inline Skill 的意义并不是“帮你写一个换算函数”，而是让 Agent 在回答“26.2 英里是多少公里”这类问题时，知道自己手里有一个可调用能力。
这也是它和普通工具函数最不一样的地方：
• 工具函数是你手动调用
• Inline Skill 是模型按上下文决定是否调用
别小看这个差别。很多 Agent 项目的核心问题，不在“有没有能力”，而在“模型能不能在合适的时候正确用上能力”。
三、它为什么特别适合快速验证？
Inline Skill 的核心优势，可以概括成三个字：改得快。
第一，定义集中。
你通常不需要在多个目录之间来回切换，能力、说明和调用场景离得很近，理解成本低。
第二，调试直接。
当你在试一个新场景时，比如订单查询、物流换算、库存计算，Inline Skill 很适合先验证：模型会不会选它、描述是否清楚、结果是否符合预期。
第三，迁移成本低。
如果这个 Skill 未来只是一次性实验，那 Inline 就够了；如果后面证明它值得长期存在，再往 File-based 或 Class-based 演进也不迟。
所以 Inline Skill 最适合承担的角色，不是“最终形态”，而是“第一形态”。
先让能力跑起来，再决定要不要把它沉淀下来。
四、Inline Skill 的边界也很明显
但也正因为它轻，Inline Skill 的边界其实很快就会出现。
当 Skill 数量开始变多时，你会发现几个问题：
• 能力定义容易分散在代码里
• 不同 Skill 的说明和结构不容易统一
• 团队协作时，不够利于共享和复用
• 一旦进入长期维护，治理成本会明显上升
这意味着，Inline Skill 并不适合承担“长期核心能力”的角色。
它更适合的是：
• 先验证一个想法
• 先打通一个场景
• 先完成一次演示
• 先确认 Agent 会不会正确使用这类能力
一旦你开始关注可分发、可共享、可维护，Inline Skill 就会显得不够了。
五、怎么判断该不该用 Inline Skill？
你可以用一个很简单的判断标准：
如果你现在最关心的是“能不能尽快跑通”，优先 Inline。
如果你已经开始关心下面这些问题：
• 这个 Skill 要不要给别人复用？
• 这个 Skill 要不要沉淀成资产？
• 这个 Skill 后面会不会持续迭代？
• 这个 Skill 要不要纳入统一治理？
那就说明，你可能已经快走到 Inline Skill 的边界了。
换句话说，Inline Skill 更像一个“启动器”，而不是“终局方案”。
六、总结
Inline Skill 最重要的价值，不是功能最强，而是进入门槛最低。
它让开发者可以用最小成本，把一个能力接进 Agent，快速验证模型会不会用、用得对不对、值不值得继续投入。
如果说 Agent Skills 的第一步是“先把能力接进来”，那么 Inline Skill 就是这一步里最高效的起点。
下一篇，我们继续聊 File-based Skill：为什么当能力不再只是临时代码，而要变成可共享、可分发的资产时，文件化组织就开始变得重要。