在 AI Agent 的工程化道路上，开发者们往往会经历从兴奋到困惑的过程。最初，我们惊叹于大模型能通过 Function Call 调用一个简单的 getMessage(String id) 函数；但很快，在构建复杂的企业级应用时，我们会发现：散落在各处的函数（Functions）并不能构成真正的智能，它们缺乏组织、缺乏状态、更缺乏业务边界。
为了解决这一痛点，Solon AI Skills 诞生了。它不仅仅是一套 API 封装，更是为 Java 开发者定义了一套全新的“AI 能力组织范式”。
一、 为什么我们需要 Skill，而不只是 Tool？
在传统的 LLM 开发中，我们习惯于直接向模型推送一组 Tools（工具）。但这在复杂业务中会遇到三个问题：
- 能力的“碎片化”： 如果你有 100 个函数，全部丢给模型，它会因为上下文过载而变得混乱。
- 指令的“脱节”： 工具告诉模型“怎么做”，但模型不知道在什么业务背景下“该不该做”。
- 生命周期的缺失： 一个简单的函数无法感知对话的开始、结束，也无法根据当前用户身份动态调整自己的行为。
Skill（技能）的诞生，就是为了将“工具”升华为“逻辑单元”。
二、 Solon AI Skill 的核心构成
一个 Solon AI Skill 是由 行为（Tools）、 指令（Instructions） 和 感知（Context Awareness） 构成的复合体。
1. 声明式的能力导出
开发者不再需要手动编写繁琐的 JSON Schema。通过 @ToolMapping 注解，普通的 Java 方法可以瞬间转化为 AI 可理解的技能点。
2. 动态指令注入 (getInstruction)
这是 Skill 的灵魂。它允许技能在被挂载时，自动向大模型的 System Prompt 中注入一段“潜意识”。
例子：一个“客服技能”在挂载时，会自动告诉模型：“你现在的身份是高级售后，请始终保持礼貌，并在结尾询问用户是否满意。”
3. 智能准入控制 (isSupported)
技能可以“拒绝”服务。它可以根据当前的 Prompt 属性（如角色、租户、会话状态）决定自己是否出现在模型的工具列表中。
三、 实战：定义你的第一个 Skill
让我们通过一段代码，看看 Solon AI 是如何优雅地定义一个“订单管理技能”的。
// 定义一个具备业务感知能力的技能
public class OrderSkill extends AbsSkill {
@Override
public boolean isSupported(Prompt prompt) {
// 只有在处理订单相关会话，且用户已登录时才激活此技能
return prompt.attr("user_id") != null;
}
@Override
public String getInstruction(Prompt prompt) {
// 动态注入业务规则
return "执行订单操作时，请务必核对订单号格式（A-加数字）。";
}
@ToolMapping(description = "根据ID查询订单状态")
public String getOrderStatus(String orderId) {
// 纯粹的业务逻辑
return "订单 " + orderId + " 正在配送中";
}
}
在调用侧，你只需要简单地“挂载”这个技能：
chatModel.prompt("查询订单 A100 的进度")
.options(o -> o.skillAdd(new OrderSkill())) // 乐高式挂载
.call();
四、 诞生背后的架构哲学
Solon AI Skills 的设计参考了人类获取知识的过程：我们不是在脑子里存了一堆孤立的 API，而是掌握了一项项 完整的技能。
- 封装性： 技能是自包含的。你可以将“财务报表技能”打成一个 Jar 包，分发给不同的项目组，他们即插即用，无需关心内部的 Prompt 怎么写。
- 工程化： 它完美契合 Java 的强类型和面向对象思想。你可以利用继承、组合来构建更复杂的“复合技能”。
- 分布式感知： 配合 MCP 协议，Solon AI 进一步衍生出了 Remote Skills，让你的 AI 技能可以跨越进程、跨越网络，在任何地方被感知和调用。
五、 总结：从“调包侠”到“技能架构师”
Java AI Skills 的诞生，标志着 Java 开发者在 Agent 开发中告别了原始的手工拼凑阶段。
通过将 AI 的能力模块化、结构化、协议化，Solon AI 让开发者能够以 架构师 的视角去规划 Agent 的智能边界。在接下来的系列文章中，我们将深度探讨这些技能如何通过“远程分发”实现真正的分布式智能。
