获课：xingkeit.top/17630/

从"聊天"到"干活"：Skills让Agent有了专业分工

接触Spring AI的Skills机制之前，我见过太多AI应用长什么样——一个大模型挂一堆工具，提示词里揉进各种指令，最后变成一锅"提示词粥"。维护起来全靠感觉，改一处不知道会影响到哪。

Skills这套东西给我的第一个冲击，是它把"能力"做成了独立模块。一个Skill本质上就是一个文件夹，里面放一个SKILL.md文件，包含元信息（名称和描述）和执行指令。设计上遵循"渐进式披露"原则：系统启动时只把技能的名称和描述加载进来，模型判断需要哪个技能时，再按需加载完整的指令文档，最后才能访问脚本和资源。

这个机制解决了一个很现实的问题——上下文膨胀。你不需要把几百个技能的操作手册都塞给AI，它只需要知道"有哪些技能可用"，用的时候再取完整内容。这就像团队里有个工具箱，你不需要把所有工具都拿在手上，你需要的是知道每个工具能干什么、放在哪里。

Skills把"靠感觉"变成"靠流程"。以前让AI做事，很大程度依赖提示词写得巧不巧；现在有了清晰的三层结构——元信息定义边界、指令定义流程、资源定义外部能力——任务的执行变得可预期、可复用、可迭代。

Spring AI的落地方式：我熟悉的那些东西还在

对Java开发者来说，Spring AI最大的吸引力不在于它多炫酷，而在于它没有逼你离开舒适区。

Spring AI的调用链其实很熟悉：用户输入→PromptTemplate组装提示词→ChatClient发送给模型→EmbeddingClient做文本向量化→VectorStore存/搜向量→返回结果。每一个概念都可以映射到你已有的Java知识上——ChatClient像RestTemplate之于HTTP，PromptTemplate像String.format()，ConversationMemory像HttpSession。

在代码层面，接入Skills的方式也保持了Spring风格：通过SkillsTool注册技能目录，配合FileSystemTools和ShellTools给Agent读写文件和执行命令的能力，然后注入到ChatClient里。核心代码量很少，15行就能跑通一个聊天应用。

多Agent协作：从"单兵作战"到"组织协同"

单智能体遇到复合型请求时很容易"上下文混乱"。比如用户既问硬件故障又问软件问题，一个Agent要同时理解两个领域，效果往往不好。

这门课里讲的多Agent协作方式，让我觉得像在设计微服务的拓扑结构——主管Agent（Supervisor）负责拆解任务、评估子Agent返回结果、决定下一步；专项Agent（SubAgent）只深耕自己的领域，比如路线规划、酒店查询、费用核算。配合MCP协议挂载外部工具，整个系统有了"组织层级"的味道。未来的后端工程师可能要像设计微服务那样去设计Agent拓扑——谁有权决策、谁只负责执行、消息如何在Agent间透传且不丢失上下文，这些都是新的架构能力。

真实的边界：Spring AI还在"青涩期"

说实话，这门课也诚实地暴露了Spring AI做Agent时的"青涩"。Tool Calling的Schema自动生成虽然方便，但对复杂嵌套对象、泛型集合的支持还需要手动打磨；多轮对话的Memory管理，在跨Agent传递时要注意隔离用户上下文和Agent内部"自言自语"，否则Token会悄悄炸掉。

还有一点必须提醒：ShellTools会直接在本地执行脚本，没有沙箱隔离。如果技能脚本里有恶意代码或者被你自己的Agent误操作，后果可能很严重。Spring团队建议的做法是把应用容器化，或者仔细审查暴露给Agent的每个脚本。

写在最后

学完之后我最大的感触是：2026年Java开发者做AI Agent，核心竞争力不在"跑通一个大模型"，而在把Agent当作普通业务组件纳入现有Spring生态的能力。你要懂如何把Skill做成公司内部共享的知识资产，如何结合Nacos做动态配置，如何在公司既有鉴权、审计、日志体系下嵌入Agent调用链路。

这场技术演进让我感觉到：AI智能体正在从"实验室玩具"变成"工程工具"。Skills给了它可复用的能力，Spring AI给了Java开发者入场的门票。关键问题已经不是"Java能不能做Agent"，而是"你能把Agent做得多么像你熟悉的那套东西"——可维护、可扩展、可治理。这门课给了一个很好的起点。