夏哉ke: bcwit.top/21698

很多开发者在接触大模型时，都经历过同样的路径：一开始用API写个聊天框，觉得惊艳；接着接上知识库（RAG），觉得有点实用价值了；但很快就会触达天花板——大模型是个“只说不练的秀才”，它无法读取你公司的数据库，不能调用内部的审批接口，更不能替你发一封邮件。

为了让AI从“陪聊”进化为“干活”，我们引入了Agent（智能体）和Skills（技能）的概念。而在Java生态中，SpringAI无疑是目前将这两者优雅整合的最强基石。

今天，我将以纯架构和业务流的视角，复盘一次基于SpringAI搭建自主决策智能体的实战过程。不贴一行代码，只谈最核心的设计心法与踩坑经验，带你搞懂如何让AI真正“长出双手”。

第一步：认知重塑——从“指令执行者”到“自主决策者”

在传统的软件工程中，所有的流程都是确定性的：用户点按钮A，系统执行方法B。这是“硬编码路由”。

而Agent的核心在于“自主决策”。你不再告诉它该走哪条路，而是给它一个目标、一组工具，让它自己思考（Thought）、决定用哪个工具（Action）、观察结果（Observation），并循环往复直到完成任务。这就是著名的ReAct循环。

SpringAI的强大之处在于，它把复杂的ReAct循环封装成了优雅的抽象，让开发者只需关注“定义目标”和“定义工具”，而不用去手写复杂的提示词解析和状态机。

第二步：Skills设计——给AI打造趁手的“兵器库”

Skills（或称为Tools/Functions）是Agent感知世界、改变世界的触角。在SpringAI中，整合Skills的第一步，不是想“我能写什么方法”，而是想“AI需要什么动作”。

实战中，定义Skill有三个黄金法则：

1. 动作要原子化，拒绝大杂烩

不要写一个名为handleOrderProcess的技能，包含了查库存、算价格、下订单、发通知所有逻辑。大模型没有能力一次性准确地传入十几个复杂参数。
正确的做法是拆解： queryInventory（查库存）、calculatePrice（算价格）、placeOrder（下订单）、sendNotification（发通知）。让AI像搭积木一样组合它们。

2. 描述比实现更重要

大模型是根据技能的“描述”来决定是否调用该技能的。如果你的描述是“查询数据库”，AI根本不知道什么时候该用。
正确的描述方式： “当用户询问某件商品是否还有货，或者想知道能否购买时，调用此技能。需要提供商品的SKU ID。”
你要像给一个聪明但不懂业务的实习生写SOP一样，把技能的触发场景、输入参数的含义、输出的格式，用自然语言写得清清楚楚。

3. 返回结果要“说人话”

技能执行后的结果，是AI进行下一轮推理的输入。如果你的技能返回一堆包含外键ID的复杂JSON，AI大概率会“幻觉”。
正确的做法： 在Service层对返回结果进行业务语义化转换。把{"status": 200, "data": {"stock": 0}}转换成"当前商品库存为0，已售罄"。AI理解了，才能做出正确的下一步决策（比如向用户推荐其他商品）。

第三步：Agent编排——让大脑与双手无缝协同

有了Skills，接下来就是把它们交给Agent。在SpringAI的架构下，Agent的编排核心在于系统提示词与对话上下文的配合。

1. 赋予明确的角色与约束

如果不加约束，Agent很容易陷入“工具依赖症”——用户问“你好”，它可能都会去调一遍搜索工具。因此，必须在System Prompt中明确界定：

• 你是谁： 你是一个严谨的电商售后客服。
• 你的边界： 你只能处理退换货和物流查询，绝不能修改用户密码。
• 你的决策逻辑： 遇到退款请求，必须先调用queryOrder验证订单状态，如果是已发货，再调用checkReturnPolicy。不要跳步。

2. 利用Spring生态的护城河

SpringAI最大的优势是生在Spring生态。你的Skill不需要去调陌生的微服务，你可以直接通过@Autowired注入你公司现有的Service。这意味着，你的老代码、老事务管理、老安全框架，统统可以无缝成为Agent的底层能力。这是其他脚本语言很难企及的企业级护城河。

第四步：实战避坑——如何防止Agent“发疯”？

在亲手搭建的过程中，你一定会遇到Agent“失控”的时刻。以下是三个典型问题及无代码层面的解法：

坑1：无限死循环（AI疯狂调用同一个无效工具）

原因： 工具返回了错误信息，AI理解不了，以为没调用成功，于是再次调用，陷入死循环。
解法： 在SpringAI中设置maxIterations（最大迭代次数）。同时在Prompt中强行植入终止条件：“如果工具返回报错，请停止调用，直接向用户说明当前无法处理，并建议转人工。”

坑2：参数幻觉（AI编造不存在的参数去调工具）

原因： 用户没提供订单号，AI为了完成任务，自己编了一个。
解法： 在Skill定义中，将关键参数标记为必填，并在Prompt中强调：“如果用户未提供必要参数（如订单号、手机号），绝对禁止自行编造，必须反问用户索要。”

坑3：技能选择困难（AI在相似技能间选错）

原因： 技能描述的边界模糊。比如“查询物流”和“查询订单”包含大量重叠词汇。
解法： 重新打磨技能描述，刻意拉开差异。比如在“查询物流”的描述中加入强调词“仅当用户询问包裹当前地理位置时使用”；在“查询订单”中加入“仅当用户询问购买记录或商品明细时使用”。

结语

从调用大模型API，到搭建基于SpringAI的自主决策智能体，这不仅仅是技术的升级，更是开发范式的跃迁。

过去的开发者是“修路者”，穷尽所有if-else铺设一条唯一的轨道；现在的开发者是“造物者”，提供大脑、双手和规则，让AI自己去探索到达终点的最优路径。

整合Agent与Skills的过程，本质上就是将你深厚的业务理解，通过自然语言和接口定义，注入到AI的血液中。当你的Agent第一次自主思考、调用正确的内部接口、完成了一笔真实的业务流转时，你就会明白——真正的AI应用时代，才刚刚开始。