前七篇我们把 RAG 和 Function Calling 讲透了。RAG 帮大模型"找资料"，Function Calling 帮大模型"动手做"。有面试候选人看到这里，问了我一个问题：

"大模型又是读文档又是调接口的，那它自己怎么知道每一步该干嘛呢？"

没错。这恰恰是核心技术点。

你给大模型装了一堆工具——查数据库的、搜网页的、发邮件的、计算器的——然后用户说了一个很复杂的任务，比如"帮我安排一趟出差"。

这个大模型需要：① 查天气 ② 查机票 ③ 查酒店 ④ 算预算 ⑤ 生成方案。这五个步骤不是一次性完成的。它需要自己规划先干哪个、后干哪个。

你能在代码里写死这个流程吗？显然不行。每个用户的出差需求都不同——有的要经济舱，有的要头等舱，有人只住连锁酒店，有人只要五星级。

这就是 Agent 要做的事。让大模型自己当项目经理，自己规划、自己执行、自己纠错。

---

一句话说清 Agent

Agent = 给大模型装上一个"自己会想、会做、会纠错"的大脑。

不再是"你问一句，它答一句"的被动模式。而是你给它一个目标，它自己分解问题、调用工具、观察结果、调整策略，直到搞定任务。

打个比方：

RAG 模式： 你问图书管理员"公司的退货政策是什么"——她去书架上找书，翻到一章，读给你听。

Function Calling 模式： 你给助理发消息"查一下订单 20240715 的物流"——她拿起电话打给仓库，问到结果告诉你。

Agent 模式： 你说"帮我安排一趟去北京的出差"——她开始思考：需要先查行程日期对应的天气和机票价格，再订合适的酒店，再算一下总预算，最后形成出差方案。她不只做一件事，她规划一串事，而且如果机票没了会自动换方案。

看懂区别了吗？

---

ReAct：Agent 工作的核心模式

Agent 不是一股脑地把所有事干完。它是一个循环：思考 → 执行 → 观察 → 再思考 → 再执行 → 再观察……直到完成任务。

这个循环在学术界和工业界有正式的名字：ReAct（Reasoning + Acting）。推理+行动交替进行。

用户在 Spring AI 里实现 Agent，代码其实不复杂。核心是给 ChatClient 一个 System Prompt，告诉它："你可以反复调用工具，直到完成任务。"

@Service
public class TravelAgent {

    private final ChatClient chatClient;

    public TravelAgent(ChatClient.Builder builder,
                       WeatherTools weatherTools,
                       FlightTools flightTools,
                       HotelTools hotelTools,
                       CalculateTools calculateTools) {
        this.chatClient = builder
            .defaultSystem("""
                你是一个专业的出差规划Agent。
                
                当用户提出出差需求后，你需要：
                1. 先获取目的地天气信息
                2. 再搜索合适的航班
                3. 搜索合适的酒店
                4. 计算总预算
                5. 生成最终方案
                
                注意：每一步都基于上一步的结果，不要跳过步骤。
                如果某个步骤失败了，尝试备选方案。
                完成所有步骤后，输出完整的出差方案。
                """)
            .defaultTools(
                weatherTools,
                flightTools,
                hotelTools,
                calculateTools
            )
            .build();
    }

    public String planTrip(String userRequest) {
        return chatClient.prompt()
            .user(userRequest)
            .call()
            .content();
    }
}

当用户说"帮我安排下周三去北京出差，待三天"时，大模型内部的 ReAct 循环大致是这样的：

Thought: 用户要去北京出差三天，我需要查天气、查航班、查酒店、算预算。先从天气开始。

Action: call getWeather("北京", "2024-07-30")
Observation: 北京7月30日晴天，28-35°C。7月31日多云，26-33°C。8月1日小雨，24-30°C。

Thought: 天气可以接受，建议带伞（最后一天小雨）。接下来查航班。

Action: call searchFlights("上海", "北京", "2024-07-30")
Observation: 找到3趟航班：① 7:30-9:45 ¥680 ② 11:20-13:30 ¥520 ③ 16:00-18:15 ¥750

Thought: 三趟航班可选，接下来查酒店。

Action: call searchHotels("北京", "2024-07-30", "2024-08-01")
Observation: 找到2家推荐酒店：① 如家快捷 ¥350/晚 ② 全季酒店 ¥580/晚

Thought: 信息收集完毕，计算总预算，生成方案。

Action: call calculate(680 + 580*3)
Observation: 2300（机票加酒店，不含餐饮）

Thought: 信息收集完毕，生成最终方案。

Answer: 为您规划了7月30日-8月1日的北京出差方案：
- 🛫 建议乘坐7:30的航班，¥680，9:45到北京
- 🏨 推荐全季酒店，¥580/晚
- ☀️ 天气28-35°C，最后一天小雨备伞
- 💰 总预算约¥2,300（机票+酒店）

需要我调整方案或增加预算吗？

看到了吗？整个流程不是代码写死的。是大模型自己走完的。 它在每次"思考"之后决定下一步用什么工具，在"观察"到结果之后决定下一步怎么继续。

---

循环终止条件

Agent 不是无限循环的。它有三个停止条件：

条件一：任务完成。 大模型觉得自己已经拿到所有需要的信息，可以输出答案了。此时它直接输出 Answer，不调任何工具。

条件二：达到最大轮次。 生产环境里你必须设一个最大步数限制（比如 10 轮）。防止 Agent 陷入死循环。

Spring AI 里可以通过 Prompt 来限制：

.defaultSystem("""
    你是一个出差规划Agent。
    最大工具调用次数为 8 次。
    超过 8 次仍未完成，输出当前进度并终止。
    """)

条件三：出现不可恢复的错误。 比如关键的 API 全部不可用。这时 Agent 应该输出错误信息，而不是卡住。

---

多 Agent 协作：别让一个 Agent 干所有事

上面讲的单 Agent 方案在简单场景下够用。但真实业务场景里，一个 Agent 管所有事很快会出问题：

- Prompt 太长：你要在一个 System Prompt 里交代所有工具的使用场景

- 工具列表膨胀：几十个工具塞给一个 ChatClient，模型选错的概率越来越高

- 上下文污染：上一个请求的上下文可能影响下一个请求

解决方案：多 Agent 架构。

一个主管 Agent 负责"决策谁来做"，多个子 Agent 各司其职。

@Service
public class MultiAgentOrchestrator {

    private final ChatClient orchestrator;

    public MultiAgentOrchestrator(ChatClient.Builder builder,
                                  SearchAgent searchAgent,
                                  DatabaseAgent databaseAgent,
                                  WritingAgent writingAgent,
                                  CalculateAgent calculateAgent) {
        this.orchestrator = builder
            .defaultSystem("""
                你是一个主管Agent。用户提出需求后，判断需要哪个子Agent来处理。
                把任务分发给对应的Agent，收集结果后返回给用户。
                
                可用的子Agent：
                - searchAgent：搜索实时信息、网页内容
                - databaseAgent：查询业务数据库
                - writingAgent：生成文章、报告、邮件
                - calculateAgent：精确计算
                """)
            .defaultTools(orchestratorTools)
            .build();
    }
}

每个子 Agent 内部可以有自己的 ChatClient 和自己的工具集：

@Component
public class SearchAgent {

    private final ChatClient chatClient;

    public SearchAgent(ChatClient.Builder builder,
                       SearchTool searchTool) {
        this.chatClient = builder
            .defaultSystem("你是一个搜索专家，只负责搜索和整理信息。")
            .defaultTools(searchTool)
            .build();
    }

    public String execute(String task) {
        return chatClient.prompt().user(task).call().content();
    }
}

多 Agent 的优势：

Prompt 精简。 每个子 Agent 的 Prompt 只描述自己的职责，没那么长。大模型不会因为上下文太长而"走神"。

工具隔离。 搜索 Agent 只知道搜索工具，数据库 Agent 只有数据库访问权限。不会出现"搜索 Agent 意外调了数据库写操作"的安全问题。

可以复用。 写一个搜索 Agent，所有项目都能用。不像一个大 Agent 里塞几十个工具，换个场景就得重新写。

容易调试。 哪个子 Agent 出错了，直接看它自己的日志就行。不用从几千行的上下文里扒原因。

---

Agent 的应用场景

说了这么多理论，实际生产中 Agent 能干什么？

场景一：客户服务 Agent。

用户说"我上周买的手机到了，但屏幕有一条线"——Agent 自动：查订单信息 → 检查是否在退换期内 → 查询退换政策 → 指导用户提交退换申请。

场景二：数据分析 Agent。

用户说"帮我看看上个月哪个品类的销售额增长最快"——Agent 自动：查数据库 → 跑数据 → 分析趋势 → 生成图表描述 → 输出结论。

场景三：代码生成 Agent。

用户说"帮我写一个根据用户查询条件动态拼接 SQL 的工具类"——Agent 自动：分析需求 → 查找相关代码库 → 生成代码 → 自测 → 格式化输出。

所以别把 Agent 想得太玄乎。Agent = 大模型 + 工具 + 自主决策循环。 仅此而已。

---

🎯 面试官视角的标准回答

如果面试官问："RAG、Function Calling、Agent 有什么区别？你们项目里怎么用的？"

RAG 是让大模型能"读"内部文档。适用于回答知识库问题。

Function Calling 是让大模型能"动手"调用系统方法。适用于执行单一操作，如查订单、发邮件。

Agent 是让大模型能"自主规划执行"。适用于需要多步推理的复杂任务，如出差安排、数据报表、客户服务。

我们项目的做法是：对于单一查询走 RAG 或 Function Calling，对于多步任务走 Agent。Agent 内部使用 ReAct 循环——思考、执行、观察、再思考。

对于工具多的场景，用了多 Agent 架构。一个主管 Agent 负责任务分发，多个子 Agent 各司其职。每个子 Agent 有独立的工具集和 Prompt，互不干扰。

限制方面：Agent 设了最大 8 轮循环，防止死循环。每个子 Agent 的超时控制在 15 秒以内。关键操作走人工确认。

---

下篇聊一个必须重视但不能在面试里翻车的话题：AIGC 安全。Prompt 注入怎么防？用户数据怎么脱敏？大模型输出怎么审核？