这是《从 Java 工程师到 Agent 开发者》系列的最后两篇。这两篇将带领读者从“知识检索”跨越到“实际行动”，并最终完成从开发到生产运维（AgentOps）的全链路闭环。

---

从 Java 工程师到 Agent 开发者（四）：Tool Use —— 赋予智能体“手”与“行动力”

前言：
如果说 RAG 为 Agent 提供了“大脑”中的知识，那么 Tool Use（工具调用，又称 Function Calling） 则为它安装了“双手”。

能够对话的 AI 只是聊天机器人，能够自主调用 API、修改数据库、发送邮件的 AI 才是真正的 Agent。对于 Java 工程师而言，这一步是我们的主场：Agent 的“行动力”本质上就是对微服务接口的语义化封装。 本文将深入探讨如何构建稳健、安全且具备闭环控制能力的工具体系。

一、 接口的进化：从“给机器调”到“给语义调”

在 Java 开发中，API 是由 Swagger 定义的硬契约。但在 Agent 体系中，API 是被模型推理出来的动态行为。

1. 语义契约（Semantic Contract）

Agent 决定调用哪个工具，完全取决于你对该工具的 Description（描述）。

• 传统逻辑： 只要参数类型对，接口就能通。

• Agent 逻辑： 如果描述含糊（如将“注销账户”写成“更新状态”），模型可能会在错误的时机误调用。

• 大师级建议： 像写法律条文一样写接口描述。明确输入、输出、副作用以及适用场景。

2. 视觉流：Agent 驱动的微服务调用

code Mermaid

downloadcontent_copy

expand_less

graph LR
    User[用户:帮我取消订单] --> LLM{意图识别}
    LLM -- 命中语义描述 --> Tool[Tool: cancelOrder]
    Tool --> Java[Java Controller/Service]
    Java --> DB[(数据库事务)]
    DB -- 执行成功 --> Result[工具返回: SUCCESS]
    Result --> LLM[模型组织语言]
    LLM --> Out[回复: 订单已为您取消]

---

二、 闭环控制：如何防止 Agent “乱来”？

当 Agent 拥有了修改数据的能力，安全性就成了第一优先级。Java 工程师必须构建三层防御体系：

1. 权限隔离（Sandbox）

不要直接给 Agent 一个拥有 DROP TABLE 权限的数据库账号。

• 最佳实践： 为 Agent 提供一套专用的、经过精简的 SDK 层，只暴露必要的业务方法，并进行严格的 RBAC 校验。

2. 人在回路（Human-in-the-Loop）

对于高风险操作（如转账、删除数据），必须引入人工确认环节。

• 工程实现： 在 Java 侧实现一个“挂起-审批-恢复”的状态机。Agent 发起请求 -> 系统拦截并推送钉钉/企业微信通知 -> 管理员点击确认 -> Java 继续执行回调逻辑。

3. 结构化输出的强约束

模型可能会返回错误的 JSON 格式。

• 防御手段： 利用 Java 的强类型（POJO）配合 JSON Schema 校验。如果模型输出不合规，利用逻辑层自动拦截并返回错误 Prompt 让模型重试，而不是直接让后端崩溃。

---

三、 实战：让 Agent 操作你的 Spring 业务

借助 LangChain4j，你可以将一个普通的 Java Bean 瞬间转化为 Agent 的工具：

code Java

downloadcontent_copy

expand_less

public class OrderTools {
    @Tool("根据订单 ID 查询发货状态")
    public OrderStatus getStatus(@P("订单编号") Long orderId) {
        return orderService.findById(orderId).getStatus();
    }
}

大师视角： 注意这里的 @P 注解。在 Agent 时代，参数的语义解释比参数名更重要。