AI Agent 究竟是什么：从 LLM 到自主系统的演进

概述

系列定位：本文是“AI Agent 基础概念与架构总览”系列的第 1 篇，是整个 AI 应用专家知识体系的认知起点。在深入 LangChain4j 框架、RAG 系统、多 Agent 协作等高级主题之前，必须回答一个根本问题：Agent 究竟是什么？它和普通的 Chatbot 有什么本质区别？为什么它直到现在才迎来工程化爆发？本文将为后续所有系列建立统一的认知框架和术语体系。

总结性引言：如果你写了 10 年 Java 代码，对“服务”“接口”“数据库”“缓存”“消息队列”烂熟于心，当团队开始讨论“Agent”“LLM”“Function Calling”“RAG”“MCP”这些新名词时，可能会有一种熟悉的不适感——和当年微服务刚火的时候很像：所有人都在谈，但很少人能说清它到底是什么、能解决什么、不能解决什么。Agent 本质上是一个“非确定性的后台服务”——它的决策引擎不是写死的 if-else，而是一个能理解自然语言、做出推理的大语言模型（LLM）；它的 Service 层不是预定义的 Dubbo 接口，而是通过 Function Calling 动态调用的工具集合；它的会话管理不是简单的 Redis Session，而是一个能跨对话记住用户偏好和历史决策的 Memory 系统；它的任务编排不是 BPMN 流程图，而是一个能根据执行结果动态调整后续步骤的 Planning 引擎。当你把 Agent 的四个要素（LLM/Tools/Memory/Planning）映射到熟悉的工程概念上，Agent 就不再是“AI 魔法黑盒”，而是一个“具有推理能力的自适应后台服务”。本文将用生活类比建立感性认知，用严格定义建立理性框架，通过完整的信息流示例展示协同过程，并回溯工程化爆发的技术前提，帮助你在 20 分钟内建立起对 Agent 的完整认知。

核心要点：

• Agent 的直观类比：LLM 是大脑（推理与决策），Tools 是手脚（执行动作），Memory 是海马体（跨对话记忆），Planning 是前额叶（任务分解与规划）。
• Agent 与 Chatbot 的本质区别：Chatbot 是“你问它答”的单轮交互，Agent 是“感知→思考→行动→反馈”的闭环系统。
• Agent 的能力分级：L1 简单反应→L2 有状态推理→L3 目标驱动规划→L4 自我进化。
• 工程化爆发的技术前提：LLM 推理突破（GPT-3.5+）+ Function Calling 标准化（OpenAI 2023.6）+ 框架成熟度（LangChain/AutoGPT）+ 算力成本下降 + MCP 协议（2024 底）。
• Agent 的工程化定位：不是替代规则引擎和工作流，而是在“场景多变、需理解自然语言、需自主规划”时互补。

文章组织架构图：

flowchart TD
    n1["1. 直观类比：生活与技术类比建立认知锚点"] --> n2["2. 正式定义：感知→决策→执行→学习的闭环系统"]
    n2 --> n3["3. Agent vs Chatbot：四维度对比"]
    n3 --> n4["4. 能力分级：L1 简单反应→L2 有状态→L3 规划→L4 进化"]
    n4 --> n5["5. 完整信息流推演：一次“订机票”请求走通四要素"]
    n5 --> n6["6. 工程化爆发史：从 GPT-3.5 到 MCP 的五个里程碑"]
    n6 --> n7["7. Agent vs 规则引擎/工作流：何时用 Agent"]
    n7 --> n8["8. 能力边界与安全基础：能做/不能做 + HITL"]
    n8 --> n9["9. 与后续系列的衔接"]
    n9 --> n10["10. 面试高频专题"]

架构图说明：

• 总览：全文 10 个模块从感性认知（类比）出发，到理性定义，再到能力分级与完整信息流推演，然后回溯工程化爆发史，最后以能力边界、系列衔接和面试题收尾。
• 逐模块：模块 1-2 回答“是什么”；模块 3-4 回答“和什么不同、强在哪里”；模块 5 展示“如何工作”；模块 6 解释“为什么现在”；模块 7-8 给出“怎么用、边界在哪”；模块 9-10 承上启下。
• 关键结论：Agent 不是一种新技术，而是一种新的软件架构范式——它用 LLM 的推理能力替代传统后台服务中的硬编码决策逻辑，用 Function Calling 的标准化工具调用替代预定义的微服务调用链，用 Memory 的跨会话记忆替代无状态 Session，用 Planning 的动态任务分解替代固定 BPMN 流程。理解 Agent 的关键不是学习新 API，而是建立一种新思维：“如何设计一个能自主感知、推理、行动和学习的系统”。

---

1. 直观类比：用生活类比与技术类比建立认知锚点

1.1 生活类比：人类助手 vs 计算器

设想你有一位人类行政助理。你说：“帮我订一张明天从北京到上海的机票，靠窗，不要红眼航班。” 助理会：①理解你的偏好（靠窗、避开深夜航班）；②回忆你以前喜欢哪些航空公司（记忆）；③打开多个机票网站查询航班（使用工具）；④比较价格和时间，排除不符合条件的；⑤预订最优选项并告诉你结果；⑥记住这次的选择，下次自动推荐相似航班。

而一个计算器，你只能按固定格式输入“123+456”，它返回结果，没有上下文，没有主动性，不会使用外部资源。Chatbot 就像计算器：你问它答，没有记忆，没有行动能力。Agent 就像人类助手：理解需求，制定计划，主动执行，从反馈中学习。

1.2 技术类比：Java 工程化视角

如果你熟悉后台服务架构，Agent 的四要素可以这样映射：

• LLM（大语言模型） = 决策引擎。类似于 Strategy 模式中的具体策略实现，它根据输入上下文和记忆做出推理，决定调用哪个工具、传递什么参数。但与传统策略不同，它不是基于显式规则，而是基于概率推理。
• Tools（工具） = Service 层。被决策引擎调用的各个微服务接口，比如航班查询 API、发送邮件服务、数据库操作。Agent 通过 Function Calling 发现和调用这些工具，就像后台服务通过 RPC 调用下游 Dubbo 服务。
• Memory（记忆） = Redis 会话管理。存储对话上下文、用户偏好、历史决策。不只是简单的 KV 缓存，还包括长期记忆的持久化和检索，相当于 Redis + 数据库的混合体。
• Planning（规划） = 工作流引擎（如 Camunda 或 Temporal）。负责任务分解、编排和执行状态追踪。但它不是基于 BPMN 的固定流程，而是 LLM 动态生成的计划，可以在执行中根据反馈自我调整。

至此，Agent = 一个自动感知环境、自主决策、调用 API 的后台服务。LLM 是决策引擎，Tools 是 Service 层，Memory 是会话管理，Planning 是工作流引擎。这个类比将贯穿全文。

Agent 四要素直觉类比图：

flowchart LR
    classDef humanSub fill:#f0f4ff,stroke:#93a3d3,stroke-width:1.5px
    classDef agentSub fill:#f0fff4,stroke:#93c5a3,stroke-width:1.5px
    classDef nodeStyle fill:#f1f5f9,stroke:#334155,stroke-width:1.5px,color:#1e293b

    subgraph Human["人类认知模型"]
        A["大脑（推理决策）"]
        B["手脚（执行动作）"]
        C["海马体（记忆）"]
        D["前额叶（规划）"]
    end
    subgraph Agent["AI Agent 架构"]
        E["LLM"]
        F["Tools"]
        G["Memory"]
        H["Planning"]
    end

    A --> E
    B --> F
    C --> G
    D --> H
    E --> F
    E --> G
    E --> H
    G --> E
    F --> E
    H --> E

    class Human humanSub
    class Agent agentSub
    class A,B,C,D,E,F,G,H nodeStyle

图表说明：

• 主旨：将人类认知能力与 Agent 技术组件一一对应，建立直观认知锚点。
• 逐层分解：上层是人类助手的四大能力，下层是 Agent 的四大模块，箭头表示控制流与数据流（LLM 调用 Tools、读写 Memory、触发 Planning 调整计划）。
• 设计原理：Agent 借鉴了认知科学中的“感知-思维-行动”循环。LLM 作为中枢，协调记忆、工具和规划。
• 工程联系：这四要素的松耦合、高内聚设计，正是 Agent 能够适应多变任务的根本原因。后续所有工程实践，都是围绕这四者的接口和交互进行优化。

---

2. 正式定义：Agent = 感知→决策→执行→学习的闭环系统

严格定义：AI Agent 是一个能够感知环境、自主决策、执行动作并从反馈中学习的闭环系统。核心四要素缺一不可：

• 感知（Perception）：接收用户输入（自然语言）、工具返回结果、Memory 中检索到的上下文、外部环境状态变化。
• 决策（Decision）：LLM 分析意图，决定调用哪些 Tools，生成调用参数，当任务复杂时由 Planning 模块制定并修正计划。
• 执行（Action）：实际调用 Tool，处理返回结果，将必要信息写入 Memory，必要时触发下一步规划。
• 学习（Learning）：从成功或失败中改进策略，更新长期记忆（如用户偏好），甚至通过反思机制修正推理路径（L4 能力）。

四要素缺一不可的论证：

• 缺少 Tools → 只能生成文本的 Chatbot，无法影响外部世界。
• 缺少 Memory → 每次对话都是新用户，无法维持上下文，更无法跨会话学习。
• 缺少 Planning → 只能处理单步简单任务，遇到“策划三天行程”就束手无策。

与规则引擎的数学本质差异：

• 规则引擎：确定性函数 output = f(input)，基于显式规则。
• Agent：概率性函数 P(output | input, memory, tools)，输出取决于上下文和模型推理。

Agent 与 Chatbot 的本质区别对比图：

flowchart TD
    classDef chatbotSub fill:#f0f4ff,stroke:#93a3d3,stroke-width:1.5px
    classDef agentSub fill:#f0fff4,stroke:#93c5a3,stroke-width:1.5px
    classDef nodeStyle fill:#f1f5f9,stroke:#334155,stroke-width:1.5px,color:#1e293b
    classDef decisionStyle fill:#fef3c7,stroke:#d97706,stroke-width:1.5px,color:#92400e

    subgraph Chatbot["Chatbot"]
        C1["用户输入"] --> C2["LLM 推理"] --> C3["文本输出"]
    end
    subgraph Agent["Agent"]
        A1["用户输入"] --> A2["感知：整合文本+记忆+工具返回"]
        A2 --> A3["决策：LLM 推理+Planning"]
        A3 --> A4{"需要行动？"}
        A4 -->|"是"| A5["执行：调用 Tool"]
        A5 --> A6["观察结果，更新 Memory"]
        A6 --> A2
        A4 -->|"否"| A7["输出最终答案"]
    end
    C3 -.->|"单向无反馈"| C1

    class Chatbot chatbotSub
    class Agent agentSub
    class C1,C2,C3,A1,A2,A3,A5,A6,A7 nodeStyle
    class A4 decisionStyle

图表说明：

• 主旨：对比 Chatbot 的线性流程与 Agent 的循环反馈流程。
• 分解：Chatbot 是一次性“输入-推理-输出”；Agent 包含感知、决策、执行、观察、记忆更新循环，可多轮迭代。
• 设计原理：Agent 的控制流借鉴了控制论中的“反馈回路”，使其能够在动态环境中适应。
• 工程联系：Agent 的循环结构意味着必须管理状态（Memory）和失败重试（Planning），这正是后台服务设计中需要重点考虑的复杂性。

---

3. Agent vs Chatbot：四维度对比

维度	Chatbot（如基础 ChatGPT）	Agent（如 ChatGPT + Function Calling）
主动性	被动响应，一问一答	可主动追问、提示、自动执行多步计划
推理能力	单轮文本理解，缺乏深层多步推理	多步逻辑推导，能分解复杂任务
环境感知	仅当前对话文本	文本 + 工具实时数据 + 记忆库 + 外部状态
工具使用	无	通过 Function Calling / MCP 调用任意 API

代码示例：同样的问题“明天北京天气怎么样？”，Chatbot 只能依据训练数据生成过时或拒绝回答；Agent 会实际调用天气 API。

用 curl 展示 Agent 的工具调用（OpenAI Function Calling）：

curl https://api.openai.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "明天北京天气怎么样？"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "获取指定城市和日期的天气",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {"type": "string"},
            "date": {"type": "string", "format": "date"}
          },
          "required": ["city", "date"]
        }
      }
    }],
    "tool_choice": "auto"
  }'

响应中会包含 tool_calls 字段，LLM 生成如 {"name":"get_weather","arguments":{"city":"北京","date":"2026-05-25"}} 的结构化调用。这就是 Agent 的行动能力——不是返回话术，而是生成可执行的 API 调用参数。

---

4. Agent 能力分级：L1 简单反应→L2 有状态→L3 规划→L4 进化

Agent 能力分级递进图：

flowchart TD
    L1["L1 简单反应<br/>关键词/意图触发固定动作"]
    L2["L2 有状态推理<br/>维护会话上下文与短期记忆"]
    L3["L3 目标驱动规划<br/>自主分解复杂任务，动态调整"]
    L4["L4 自我进化<br/>从失败学习，自动发现新工具"]
    L1 --> L2 --> L3 --> L4

图表说明：

• 主旨：展示从简单反射到自我进化的四级能力阶梯，每级建立在前一级的技术基础之上。
• 逐级分解：
  • L1：基于 if-else + 意图识别的规则触发，无状态。类似静态路由。
  • L2：引入 Memory（类似 Redis Session），能处理指代消解和多轮对话。
  • L3：引入 Planning（动态任务分解），能应对“北京三日游”这种开放目标。
  • L4：引入反思和学习机制，从错误中调整策略，接近元认知。
• 设计原理：分级受自动驾驶 L1-L5 启发，每一级解锁新的核心能力，同时也带来新的工程挑战（成本、延迟、可控性）。
• 工程联系：目前生产落地主要处于 L2 和 L3 之间。L3 的实现依赖 ReAct 等推理范式，成本较高；L4 仍以研究为主。选型时需根据任务复杂度选择合适级别。

能力分级表：

级别	技术前提	核心能力	局限性	典型框架/产品	Java 工程类比
L1	LLM 可 Follow Instructions	识别意图，触发单一 Tool	无状态，无法多轮交互	早期 GPT-3 + 简单脚本	无状态的 REST 接口
L2	Function Calling + ChatMemory	多轮对话，记住上下文，指代消解	无法自主规划多步任务	LangChain4j AiServices+memory	带 Session 的后台服务
L3	ReAct/Plan-Solve + 多工具协作	分解任务为子步骤，监控执行，失败自动重规划	推理成本高，规划质量依赖模型	AutoGPT, LangChain Agent Executor	工作流引擎动态编排微服务
L4	Reflexion + 工具学习	反思失败，改进策略，跨领域迁移，学习新工具	工程化不成熟，实时性、可靠性挑战	AutoGPT 的自我提示链，Reflexion	自适应系统，尚难比拟

---

5. 完整信息流推演：一次“订机票”请求走通四要素协同

场景：用户说：“帮我订一张明天从北京到上海的机票，尽量便宜但不要红眼航班。”

信息流推演（7 步）：

1. 感知（Perception）：用户输入进入 Agent。Memory 检索到历史：用户偏好经济舱、靠窗座位，曾选择国航。
2. 决策（Decision - LLM + Planning）：LLM 理解意图：“订机票”，目的地北京→上海，日期 2026-05-25，约束：便宜、非红眼。Planning 分解任务：①搜索航班 ②过滤红眼航班 ③按价格排序 ④预订最优选项。
3. 执行（Action - 调用 Tool）：调用 searchFlights(from: "北京", to: "上海", date: "2026-05-25")。
4. 感知（Observation）：Tool 返回 10 个航班，包含时间、价格、舱位。Memory 暂存结果。
5. 决策（LLM 再次推理）：LLM 根据约束过滤：排除起飞时间在 23:00-06:00 的航班。剩余 6 个航班。结合 Memory 中用户偏好“靠窗”，进一步检查是否有靠窗座位可选（需要第二个 Tool checkSeatAvailability）。调用该 Tool 检查价格最低的三个航班。
6. 执行与观察：checkSeatAvailability 返回只有两个航班有靠窗位。LLM 选择价格最低且有靠窗位的航班，生成预订请求。
7. 执行与记忆更新：调用 bookFlight(flightId, seatPreference)，预订成功。Memory 写入本次选择的航班偏好，用户界面输出最终结果：“已为您预订明天 14:30 北京→上海 MU5101 航班，经济舱靠窗，价格 ¥680。”

完整信息流时序图：

sequenceDiagram
    participant User as 用户
    participant Agent
    participant LLM
    participant Tools
    participant Memory
    participant Planning
    User->>Agent: “帮我订明天北京到上海的机票，便宜非红眼”
    Agent->>Memory: 检索用户偏好
    Memory-->>Agent: 偏好：经济舱靠窗
    Agent->>Planning: 请求任务分解
    Planning-->>Agent: 计划：搜索→过滤→排序→预订
    Agent->>LLM: 生成 searchFlights 调用
    LLM-->>Agent: tool_call: searchFlights(北京,上海,2026-05-25)
    Agent->>Tools: searchFlights
    Tools-->>Agent: 10个航班数据
    Agent->>Memory: 存储航班列表
    Agent->>LLM: 过滤红眼航班、结合偏好选择
    LLM-->>Agent: tool_call: checkSeatAvailability(航班A,靠窗)
    Agent->>Tools: checkSeatAvailability
    Tools-->>Agent: 航班A有靠窗
    Agent->>LLM: 决定预订
    LLM-->>Agent: tool_call: bookFlight(航班A,靠窗)
    Agent->>Tools: bookFlight
    Tools-->>Agent: 预订成功
    Agent->>Memory: 写入新偏好记录
    Agent->>User: “已预订MU5101，靠窗，¥680”

图表说明：

• 主旨：展示一次多步骤任务中四要素的协同交互，突出感知-决策-执行的循环。
• 分解：用户输入后，Agent 先查 Memory 获取历史偏好，Planning 分解任务，LLM 生成工具调用，Tools 执行并返回结果，Memory 持续记录，Planning 监控状态，最终输出结果。
• 设计原理：Agent 的智能体现在循环决策：每次工具返回都可能改变下一步计划，而非预设流程。Planning 在这里扮演“监督者”角色，决定何时任务完成。
• 工程联系：这个时序图在工程上可以映射为一个异步事件驱动架构，Agent 循环是一个状态机，Tools 是下游微服务，Memory 是 Redis+DB。实现时需要处理超时、重试、工具调用失败等异常，Planning 需具备容错和回退策略。

---

6. 工程化爆发史：从 GPT-3.5 到 MCP 协议的五个里程碑

里程碑 1：LLM 推理能力突破 (2022.11, GPT-3.5) GPT-3.5 的 Instruction Following 能力让 LLM 能够可靠地理解复杂指令，并生成结构化的输出。相比 GPT-3，它可以被“编程”而不仅是“提示”。这为 Agent 的决策引擎提供了基础。正如后台服务需要一个可靠的业务逻辑层，Agent 需要 LLM 能遵循指令。

里程碑 2：Function Calling 标准化 (2023.6, OpenAI) OpenAI 推出 Function Calling，使 LLM 能够输出标准的 JSON 函数调用参数，而不是依赖不可靠的 Prompt Engineering。这相当于定义了一套 RPC 协议——LLM 可以声明式地调用后端服务。Anthropic 的 Tool Use 进一步丰富了交互模式。工具调用从“黑魔法”变成了“标准 API”。

里程碑 3：框架成熟 (2022.10 LangChain, 2023.3 AutoGPT) LangChain 提供了 Agent 开发的标准抽象：Chain、Agent、Tool、Memory。AutoGPT 则展示了自主 Agent 的雏形——给定目标，自动生成任务链并执行。尽管早期版本不稳定，但它点燃了工程化尝试。Java 生态通过 LangChain4j (2023) 迅速跟进，使 Java 开发者也能用熟悉的模式构建 Agent。

里程碑 4：算力成本断崖式下降 (2023-2024) GPT-4 的 API 价格从 2023 年 3 月的 $0.03/1K tokens 降至 2024 年 GPT-4o 的$0.005/1K tokens，降幅达 83%。Agent 的多轮推理往往需要数十次 LLM 调用，成本曾是最大障碍。降价使生产部署在经济上可行，类似于云计算成本下降推动了微服务架构普及。

里程碑 5：MCP 协议 (2024.11, Anthropic) Anthropic 推出 Model Context Protocol (MCP)，试图标准化 Agent 与外部工具的通信方式。它类比 USB-C 统一接口，让任何工具都可以被任何 Agent 发现和调用。这有望解决工具碎片化问题，未来可能形成 Agent 工具生态。系列二的第 5-8 篇将深度解析 MCP。

LangChain4j 最小 Agent 示例（10 行代码），展示当前工程化已极为简洁：

import dev.langchain4j.model.openai.OpenAiChatModel;
import dev.langchain4j.service.AiServices;
import dev.langchain4j.agent.tool.Tool;
import dev.langchain4j.memory.chat.MessageWindowChatMemory;

public class MinimalAgent {
    // 定义一个工具：天气查询
    static class WeatherTools {
        @Tool("获取指定城市当天天气")
        String getWeather(String city) {
            return city + "：晴，25°C"; // 模拟返回
        }
    }

    public static void main(String[] args) {
        var model = OpenAiChatModel.withApiKey(System.getenv("OPENAI_API_KEY"));
        // 构建 Agent：LLM + 工具 + 记忆
        var agent = AiServices.builder(Assistant.class)
                .chatLanguageModel(model)
                .tools(new WeatherTools())
                .chatMemory(MessageWindowChatMemory.withMaxMessages(10))
                .build();
        String answer = agent.chat("明天北京天气如何？");
        System.out.println(answer);
    }

    interface Assistant {
        String chat(String message);
    }
}

代码解读：AiServices.builder 装配了一个 Agent，它使用 OpenAiChatModel 作为决策引擎，WeatherTools 作为 Service 层，MessageWindowChatMemory 作为内存会话管理。这就是一个 L2 级 Agent 的完整骨架——对应 Java 工程中的依赖注入组装一个后台服务。

---

7. Agent vs 规则引擎/工作流：何时用 Agent，何时用传统方案

对比图：

flowchart LR
    subgraph 传统方案
        A[规则引擎 Drools]
        B[工作流引擎 Camunda]
        C[确定性决策]
        D[预定义流程]
        E[高可解释性]
        F[变更需改规则/流程定义]
    end
    subgraph Agent 方案
        G[LLM 推理]
        H[Planning 动态规划]
        I[非确定性决策]
        J[适应非结构化输入]
        K[低可解释性]
        L[变更只需调整 prompt 或工具]
    end
    A --- C
    A --- E
    B --- D
    B --- F
    G --- I
    G --- J
    H --- I
    H --- L
    C -.->|互补| I
    D -.->|互补| I

图表说明：

• 主旨：展示两种范式的核心差异及互补关系。
• 分解：规则引擎与工作流都依赖显式定义，输出可预测；Agent 依赖概率推理，灵活性高但可解释性弱。
• 设计原理：软件工程追求“控制”与“适应”的平衡。传统方案适合场景已知且稳定；Agent 适合场景多变、输入不确定。
• 工程联系：实际落地方案往往是“工作流调度 Agent”，即用 Camunda 管理主流程，在需要理解自然语言或动态决策的节点调用 Agent，兼顾可审计性与灵活性。

选型决策框架：

• 业务规则明确、逻辑稳定 → 规则引擎（如风控规则）。
• 流程固定、需审计追踪 → 工作流引擎（如审批流）。
• 用户输入多变、需要理解意图、执行多步信息检索或操作 → Agent。
• 复杂业务可结合：例如客服系统中，工作流定义工单流转，Agent 处理用户模糊投诉并推荐解决方案。

---

8. Agent 的能力边界与安全基础

能做：

• 辅助决策：分析大量非结构化数据给出建议。
• 自动执行确定性操作：查询数据库、发送邮件、调用 API。
• 灵活处理自然语言输入，无需事先穷举所有情况。

不能做：

• 承担法律/安全后果：Agent 的决策基于概率，不具备法律主体资格。
• 完全替代人类判断：没有真正的“理解”和“意图”，可能产生幻觉。

Human-in-the-Loop (HITL) 是落地的关键安全机制：高危操作（删除数据、发送生产邮件、修改配置）必须经人工审批。实现上可在 Agent 决策流水线中加入“确认节点”，当操作风险等级超过阈值时暂停，等待人类确认。系列四第 7 篇将详解 HITL 的工程实现。

---

9. 与后续系列的衔接

• 本系列第 2 篇：四要素全景图（架构图 + 信息流时序图 + 最小代码骨架）。
• 本系列第 3-6 篇：逐一深入 LLM、Memory、Tools、Planning。
• 系列二：LangChain4j 框架源码分析与 MCP 协议详解。
• 系列三：RAG 系统（Agent 最核心的知识检索 Tool）。
• 系列四：提示词工程与 Agent 深度实战，含安全与 HITL。
• 系列五：多 Agent 系统与商业解决方案。

---

10. 面试高频专题

题 1：Agent 和普通 Chatbot 的本质区别是什么？为什么 Function Calling 是 Agent 的核心能力？

• 回答：Agent 是具备感知、决策、执行、学习闭环的系统，Chatbot 只是文本生成器。Function Calling 让 LLM 能够生成结构化的工具调用，将自然语言指令转换为 API 调用，是 Agent 行动能力的基石。
• 详细解释：Chatbot 的 f(input)=text，无法影响外部世界。Agent 通过 Function Calling 输出 {"name":"get_weather","arguments":{"city":"北京"}}，服务端执行实际调用，获取实时数据。这使 LLM 从“言语巨人”变成“行动者”。
• 追问：
  • 追问 1：如果不用 Function Calling，用 Prompt Engineering 能否实现工具调用？可以但不稳定，需要复杂的解析和重试，标准化程度低。
  • 追问 2：Function Calling 的 JSON Schema 约束如何保证参数正确性？模型遵循 schema 生成，但需结合校验层和重试机制。
  • 追问 3：多轮工具调用如何管理状态？通过 Memory 存储工具返回，作为后续 LLM 的上下文。
• 加分回答：Function Calling 本质是“意图识别 + 槽位填充”的端到端版本，替代了传统 NLP 流水线。Java 中可通过 @Tool 注解声明式定义，框架自动处理调用链路，类似于声明式事务管理。

题 2：Agent 的四个核心要素分别扮演什么角色？缺一不可吗？

• 回答：LLM 是大脑，负责推理决策；Tools 是手脚，执行动作；Memory 是海马体，保持状态；Planning 是前额叶，分解任务。缺少任何一个都会退化：缺 Tools 就是 Chatbot，缺 Memory 是无状态服务，缺 Planning 只能处理单步任务。
• 详细解释：在工程上，LLM 被封装为策略类；Tools 是微服务接口；Memory 是 Redis/数据库的组合；Planning 是工作流引擎的替代。四要素协同形成一个事件驱动循环。
• 追问：
  • 追问 1：Planning 能完全替代工作流引擎吗？不能，Planning 动态但不可审计，关键流程仍需传统引擎。
  • 追问 2：Memory 的短期和长期如何划分？短期用滑动窗口聊天记录，长期用向量数据库存储偏好和事实。
  • 追问 3：工具调用失败时 Agent 如何处理？Planning 应检测失败，生成回退或重试策略。
• 加分回答：可以借鉴“Hexagonal Architecture”设计 Agent，LLM 和 Tools 分别作为核心和适配器，Memory 和 Planning 作为内部领域服务，使系统可测试、可替换。

题 3：Agent 的能力分级是怎样的？当前业界主流处于哪个级别？

• 回答：L1 简单反应，L2 有状态推理，L3 目标驱动规划，L4 自我进化。主流生产落地在 L2 和初步 L3，L4 多为研究。
• 详细解释：L2 通过记忆实现多轮交互，L3 引入 ReAct 或 Plan-Solve 实现任务分解，但成本较高。LangChain4j 的 AiServices 内置 Memory 支持 L2，结合 Agent Executor 可达到 L3。
• 追问：
  • 追问 1：L3 的实现有哪些典型模式？ReAct（推理和行动交替）、Plan-Execute（先计划后执行）、Tree-of-Thought 等。
  • 追问 2：L2 到 L3 的最大挑战是什么？规划质量不稳定，LLM 容易产生幻觉或遗漏步骤，需要多轮验证。
  • 追问 3：L4 自我进化的主要方法有哪些？Reflexion（失败反思），Self-Refine，以及模型微调。
• 加分回答：可将 Agent 级别与自动驾驶 SAE 分级类比，帮助非 AI 人员理解。选择分级时需权衡任务关键性与成本：金融交易可能需要 L2 加严格审计，内容生成可用 L3 探索。

题 4：为什么 Agent 直到 2023 年才开始工程化爆发？

• 回答：五个里程碑共同作用：GPT-3.5 的推理突破、Function Calling 标准化、LangChain/AutoGPT 框架成熟、算力成本骤降、MCP 协议推动工具标准化。
• 详细解释：之前 LLM 能力不足或工具调用需黑魔法；成本高企无法多轮调用；缺乏统一框架，每个团队重复造轮子。2023 年这些瓶颈逐一解除。
• 追问：
  • 追问 1：如果没有 Function Calling，Agent 能实现吗？能，用 Prompt 拼接和解析，但极不稳定，生产不可行。
  • 追问 2：LangChain4j 对 Java 生态的影响是什么？让 Java 开发者无需转向 Python，能用熟悉的依赖注入和声明式开发构建 Agent。
  • 追问 3：MCP 协议解决了什么问题？工具发现的标准化，使 Agent 能即插即用第三方工具。
• 加分回答：爆发类似于 Spring 框架出现后微服务架构的流行——基础设施一旦标准化，创新便聚焦在业务实现上。

题 5：Agent 和规则引擎、工作流引擎有什么区别？什么场景用 Agent？

• 回答：规则引擎基于确定性规则，工作流基于预定义流程；Agent 基于 LLM 的概率推理和动态规划。当输入多变、需要理解自然语言且无法穷举规则时用 Agent；场景固定、可审计要求高时用传统方案。
• 详细解释：结合 Java 生态：Drools 决策表，Camunda BPMN。如果用 if-else 能覆盖所有情况，用 Agent 反而增加不确定性。但用户意图模糊时，Agent 的泛化能力是关键。
• 追问：
  • 追问 1：两者能结合吗？能，工作流调度 Agent，Agent 处理非结构化节点。例如审批流中，Agent 分析合同文本，结果送回工作流。
  • 追问 2：Agent 的不确定性如何监控？记录决策日志，使用 Embedding 检测异常，或设置置信度阈值触发人工介入。
  • 追问 3：规则引擎维护成本高，Agent 能降低吗？能，在规则边界模糊的场景，Agent 减少人工梳理规则的工作量。
• 加分回答：可以设计“决策路由”模式：先由分类器判断问题是否在已知规则内，是则走规则引擎，否则走 Agent，兼顾效率和灵活性。

题 6：Agent 能做什么、不能做什么？为什么 Human-in-the-Loop 关键？

• 回答：能做辅助决策、自动化操作性任务；不能承担法律后果、完全替代人类判断。HITL 确保高风险操作有人类监督，防止幻觉或误判导致损失。
• 详细解释：Agent 没有真实意图，可能错误推理。HITL 可通过审批节点、风险评分、人在循环的 UI 实现。例如删除操作必须人工确认。
• 追问：
  • 追问 1：HITL 如何工程实现？可在 Tool 定义中标注风险等级，Agent 调用高风险 Tool 时挂起，发送审批请求到外部系统。
  • 追问 2：低风险操作是否也需要 HITL？可配置策略，如连续执行阈值，或基于置信度自动放行。
  • 追问 3：如何审计 Agent 的决策？记录每个步骤的输入、LLM 推理、工具调用和结果，存入不可变日志。
• 加分回答：HITL 模式可借鉴“断路器”模式，当 Agent 错误率上升，自动关闭自动执行，强制人工介入。

题 7：什么是 MCP 协议？它解决了什么？

• 回答：MCP（Model Context Protocol）是 Anthropic 提出的 Agent 工具标准化协议，旨在统一工具发现、调用和数据交换格式，解决工具碎片化问题。
• 详细解释：类比 USB-C，不同工具只要遵循 MCP，就能被任何支持 MCP 的 Agent 使用，无需为每个工具写适配器。包括工具列表描述、调用参数 schema、结果格式。
• 追问：
  • 追问 1：MCP 与 Function Calling 的关系？Function Calling 是 LLM 内部的调用格式，MCP 是 Agent 与外部工具间的通信协议，可视为传输层规范。
  • 追问 2：MCP 会替代 OpenAI 的 Function Calling 吗？可能是互补，Function Calling 作为 LLM 的输出格式，MCP 作为工具实现端的接入标准。
  • 追问 3：Java 中如何实现 MCP 客户端？可用 LangChain4j 的工具适配器，实现 MCP 定义的接口，封装 HTTP 或 gRPC。
• 加分回答：MCP 的思想类似于服务网格中的 Sidecar，解耦 Agent 与工具，使工具可以独立演进、安全升级。

题 8：用 Java 工程化语言描述 Agent 架构。

• 回答：Agent 相当于一个后台服务，LLM 是策略引擎，Tools 是 Service 层的实现，Memory 是 Redis+DB，Planning 是动态工作流引擎。整体可看作一个事件驱动的反应式系统。
• 详细解释：请求进入，Agent 通过 Spring 管理的 Bean 组装。LLM 作为一个调用外部模型的服务；Tool 用 @Tool 注解暴露，类似 @RestController；Memory 使用 ChatMemoryStore 接口，可实现 Redis 支持。Planning 可通过自定义 AgentExecutor 实现。
• 追问：
  • 追问 1：如何保证 Agent 的性能？使用异步非阻塞调用 LLM 和工具，缓存常见推理结果，采用流式响应。
  • 追问 2：如何测试 Agent？可模拟 LLM 返回固定工具调用，验证工具执行和状态变更，类似于微服务的集成测试。
  • 追问 3：如何在微服务体系中部署 Agent？Agent 本身可打包为一个微服务，通过 MCP 或内部 API 暴露工具，或作为边车代理。
• 加分回答：可采用“CQRS”分离决策与执行：LLM 决策部分作为命令模型，工具执行和记忆更新作为查询模型，提高扩展性。

题 9：什么是 ReAct？它和传统 CoT 有什么区别？

• 回答：ReAct（Reason+Act）是融合推理和行动的 Agent 循环，交替生成思考和行动步骤；CoT（Chain-of-Thought）只是让 LLM 输出推理链，不执行外部动作。Agent 需要 ReAct 才能获取外部反馈。
• 详细解释：ReAct 的 Prompt 结构包含 Thought, Action, Observation 循环。这在工程中可用 while 循环实现，直到得到最终答案。LangChain4j 的 Agent 默认支持 ReAct。
• 追问：
  • 追问 1：ReAct 如何避免无限循环？设置最大步数，或在 Prompt 中加入停止条件。
  • 追问 2：ReAct 和 Planning 的关系？ReAct 是一种简单的规划执行方式，复杂任务需要 Plan-Solve 先制定完整计划。
  • 追问 3：如何优化 ReAct 的效率？使用缓存避免重复 Tool 调用，或让 LLM 一次性调用多个独立 Tool。
• 加分回答：ReAct 可视为“思考-行动”的 Observer 模式，Agent 观察环境变化，调整后续动作，与响应式编程异曲同工。

题 10（系统设计题）：设计一个“个人智能助理”Agent，能查询天气、管理日程、记住用户偏好。

要求：

• 提供 Agent 四要素设计。
• 完整信息流时序图（“帮我订明天下午飞上海的机票，靠窗”）。
• 架构图。
• Memory 写入与检索策略。

架构图：

flowchart TD
    User[用户] --> API[REST API]
    API --> AgentCore[Agent Core]
    AgentCore --> LLM[OpenAI GPT-4o]
    AgentCore --> Tools[Tool Set]
    subgraph Tools
        WeatherTool[天气查询]
        CalendarTool[日程管理]
        FlightTool[机票预订]
    end
    AgentCore --> Memory[Memory]
    subgraph Memory
        ChatHistory[短期记忆<br/>MessageWindow]
        UserProfile[长期记忆<br/>偏好/事实 DB]
    end
    AgentCore --> Planning[Planning<br/>ReAct Executor]
    Planning --> LLM
    Planning --> Tools
    Tools --> External[外部 API]
    Memory --> Redis[(Redis)]
    Memory --> DB[(MySQL/向量DB)]

业务时序图：

sequenceDiagram
    participant U as 用户
    participant A as Agent Core
    participant M as Memory
    participant P as Planning
    participant L as LLM
    participant T as Tools
    U->>A: “订明天下午飞上海机票，靠窗”
    A->>M: 检索偏好（座位偏好、常用航司）
    M-->>A: 偏好：靠窗，国航优先
    A->>P: 启动规划：订机票任务
    P->>L: 生成第一步：搜索航班
    L-->>P: tool_call: searchFlights(北京,上海,明天下午)
    P->>T: 执行 searchFlights
    T-->>P: 返回航班列表
    P->>L: 结合偏好过滤（靠窗，非红眼）
    L-->>P: tool_call: checkSeats(航班A)
    P->>T: checkSeats
    T-->>P: 航班A有靠窗
    P->>L: 决策预订
    L-->>P: tool_call: book(航班A, 靠窗)
    P->>T: 执行预订
    T-->>P: 成功
    P->>M: 写入本次选择
    P->>A: 返回结果
    A->>U: “已预订 CA1234，下午15:30，靠窗”

流程说明与组件职责：

• API 层：接收用户指令，同步或异步返回结果。
• Agent Core：协调各组件，实现主循环。
• LLM：使用 GPT-4o，负责意图理解与工具调用决策。
• Tools：三个独立服务，通过 Function Calling 暴露，各自连接真实 API（如和风天气、Google Calendar API、航班供应商接口）。工具定义使用 @Tool 注解，框架自动管理调用。
• Memory：短期记忆使用 LangChain4j 的 MessageWindowChatMemory，存储最近 20 轮对话；长期记忆使用关系型数据库存储结构化偏好（如座位偏好、常用航司），同时可将文本偏好 Embedding 后存入向量数据库支持语义检索。
• Planning：采用 ReAct 模式，最多 10 步循环，失败时重试或降级。

技术选型权衡：

• LLM 选型：GPT-4o 成本低、支持并行 Function Calling，适合多工具场景；也可用 Claude 3.5 Sonnet 获得更好的指令遵循。
• Memory 方案：对于偏好这类需要快速检索的长期信息，使用 Redis + 定期持久化；对于模糊记忆，用向量数据库做相似度搜索，成本稍高但灵活。
• Planning 策略：简单任务直接用 ReAct；复杂行程规划可引入“Plan-then-Execute”模式，先让 LLM 生成整个计划，再逐步执行并调整。执行过程中需监控单步超时和工具异常，触发重规划。
• 安全与 HITL：预订操作标记为高风险，在工具执行前通过回调通知用户确认；可加入审批流，保证关键操作受控。

Memory 写入与检索策略：每次交互后，Agent 将用户反馈和最终选择作为事实写入 user_profile 表（字段：user_id, key, value, timestamp）。检索时，先查短期记忆（最近对话），若短期记忆无法覆盖（如跨会话偏好），则用 SQL 查询 user_profile 获取对应 key。同时可使用轻量级 Embedding 对用户自然语言偏好进行向量化，支持模糊查询。

---

速查表：AI Agent 基础认知

概念	定义/类比	关联后续篇章	面试要点
Agent	感知→决策→执行→学习的闭环系统	本系列第2篇全景图	与 Chatbot 的本质差异
LLM	决策引擎，类比 Strategy 策略	本系列第3篇	推理能力与温度参数
Tools	执行动作的服务层，通过 Function Calling 调用	本系列第5篇	工具定义最佳实践
Memory	跨会话记忆，Redis+数据库类比	本系列第4篇	短期/长期记忆分层
Planning	任务分解与动态规划，类比工作流引擎	本系列第6篇	ReAct 循环原理
Function Calling	让 LLM 输出标准工具调用 JSON	系列二 LangChain4j	如何保证参数正确
MCP 协议	Agent 工具标准化协议，类比 USB-C	系列二第5-8篇	与 Function Calling 关系
L1-L4 分级	简单反应到自我进化	全系列贯穿	当前主流 L2-L3
HITL	人在环中，高危操作需审批	系列四第7篇	实现架构与风险控制

延伸阅读：

• Lilian Weng,《LLM Powered Autonomous Agents》(2023.6)
• AutoGPT GitHub 仓库
• Anthropic MCP 协议介绍 (2024.11)
• 《Building LLM Apps》第 1 章