企业官网建设流程全解析

Agent 不是"会调 API 的 Chatbot"——重新理解 AI Agent 的本质

Hi，我是小z。最近几个天在学习 Agent 过程中攒了一些笔记，零零散散记在 Notion 里也没人看。不如整理出来，写成系列。这是第一篇，聊聊一个最基础但也最容易吵起来的问题：Agent 到底是个什么东西。
声明：本文中的"机票退改签智能助手"为虚构教学案例，仅用于串联知识点。

目录

• 一、从 Chatbot 到 Agent：一个案例看懂三级跃迁
• 二、解剖 Agent：LLM + 规划 + 工具 + 记忆
• 三、RAG 与 Agent：知识 vs 任务
• 四、工程决策：什么时候该用 Agent？
• 五、30 行伪代码看懂 Agent 本质
• 六、总结

一、从 Chatbot 到 Agent：一个案例看懂三级跃迁

2024 年以来，“Agent"成了 AI 领域最泛滥的词。几乎每一个接入了 LLM API 的产品都在宣称自己是 Agent。但如果你的系统只是"用户输入一句话 → LLM 调用一个 API → 返回结果”，那它和一个带联网功能的 Chatbot 有什么本质区别？

我们用同一个场景来体验三种形态的差异。

场景：用户想退掉今天下午的机票，改签一个更便宜的航班。

第一阶段：Chatbot（聊了个寂寞）

用户输入：“我要退票，帮我改签今天最便宜的航班。”

Chatbot 做的事：检索到退改签政策文档，通过 LLM 生成一段"友好但无用"的回复——

“您好！根据我司退改签政策，特价经济舱退票需收取票面价 30% 的手续费，改签需收取 10% 手续费加差价。您可以通过以下链接自助办理：https://xxx.com/self-service。如有疑问请联系客服热线。”

用户读完，还得自己去查航班、比价、填表单、点确认。Chatbot 给了信息，但交还了全部执行成本。

第二阶段：RAG（精准的知晓，无力的执行）

RAG 增强后：系统精准检索到了该用户的订单详情和实时航班数据。

用户输入同样的话，RAG 系统回复：

“您好！您的订单号 PN20260607001，票面价 ¥1,580，属于特价舱。退票手续费 ¥474（30%），可退 ¥1,106。目前同日 MU5102 航班最低票价 ¥1,280。退票重买总成本 ¥1,754，改签总成本 ¥1,438。建议您选择改签，可节省 ¥316。”

比 Chatbot 强太多了——准确、有计算、有建议。但用户还是得自己去操作。

核心困境：知识检索做到了极致，但执行能力为零。

第三阶段：Agent（交托目标，闭环执行）

用户输入：“帮我退了，改签今天最便宜的航班。”

Agent 做的事情：

1. 理解目标：退票 + 改签最便宜航班，而不是"查政策"
2. 查订单和航班：获取当前订单详情和同日所有可用航班
3. 计算成本：退票手续费 ¥474，退票重买 vs 改签的两种方案成本
4. 自主决策：发现改签比退票重买便宜 ¥316，选择改签方案
5. 执行操作：锁定 MU5102 座位，发起改签请求
6. 请求确认：向用户推送扣款确认，用户只需点一次"同意"

用户要做的事从"理解政策→比价→填表→支付→等待"降维到"看一眼，点确认"。

三种形态的本质差异：

Agent 和 Chatbot 的关键分界线不在于"有没有调用 API"，而在于"谁在承担执行的任务和决策"。Chatbot 告诉你路线，Agent 直接把你送到目的地。

二、解剖 Agent：LLM + 规划 + 工具 + 记忆

2.1 四个核心组件

一个合格的 Agent 由四个组件构成，缺一个都会导致能力坍塌：

• LLM（大语言模型）：Agent 的"大脑"，负责推理和决策。但它不是全部——只是一个组件。
• Planning（规划能力）：将用户目标分解为可执行的子任务序列。规划不是一次性的，而是在执行过程中根据工具返回的结果不断修正。
• Tools（工具）：Agent 的"手脚"，包括 API 调用、代码执行、数据库查询、网页浏览等。
• Memory（记忆）：短期记忆（当前对话上下文）+ 长期记忆（用户偏好、历史决策），让 Agent 的每次决策有据可依。

Agent 的本质：在 LLM 这个"概率引擎"外面包裹了一层确定性的状态机。LLM 负责推理，状态机负责控制循环和边界约束。

2.2 图：Agent 四要素 + ReAct 动态飞轮

这张图最关键的不是四个方块，而是箭头。

Agent 不是"LLM 想了想 → 调用工具 → 结束"的线性流水线。它是一个 ReAct（Reasoning + Acting）动态循环：

1. Think（推理）：基于当前状态和记忆，LLM 决定下一步做什么
2. Act（执行）：调用对应工具
3. Observe（观察）：获取工具返回结果
4. Reflect（反思）：结果符合预期吗？如果工具报错，换一套参数重试；如果发现新信息，修正后续计划

这个循环持续运转，直到 LLM 自己判断"目标已达成"并输出FINISH。

2.3 Function Calling 不是 Agent

这是本文最想澄清的一个误区。

Function Calling 是 2023 年 OpenAI 推出的能力，让 LLM 输出结构化的函数调用请求。它给 LLM 装上了"手指"，但拥有手指不意味着大脑知道怎么弹钢琴。

来看区别：

传统 Function Calling 模式：程序员在服务端写死了判断逻辑——先调用 A，A 返回结果后根据 if-else 决定是否调用 B。LLM 的角色是分类器：把用户意图映射到预定义的 if 分支里。

真正的 Agent 模式：程序员只给 LLM 一个目标和一组工具描述。LLM 自己决定先调 A 还是 B，根据 A 的结果决定要不要调 C，C 报错了换参数重试，最终发现所有工具都解决不了时——自己告诉用户"这个我办不到，原因如下"。

一句话总结：Function Calling 是 LLM 被代码调用；Agent 是 LLM 主动调用代码。

三、RAG 与 Agent：知识 vs 任务

很多人会问：“Agent 就是 RAG 的升级版吗？”

这是一个范畴错误。RAG 和 Agent 解决的是不同维度的问题。

RAG 本质上是 Agent 的一个工具。当 Agent 在规划阶段发现自己缺乏某块知识来做决策时，它会主动调用一个名叫search_internal_knowledge()的工具——这个工具的底层实现就是 RAG。

所以正确的层级关系是：

Agent ├── LLM（大脑） ├── Planning（规划器） ├── Tools（工具集） │ ├── search_knowledge_base() ← 这就是 RAG │ ├── send_email() │ ├── query_database() │ └── ... └── Memory（记忆）

RAG 解决的是"意识"问题（消除幻觉，提供上下文），Agent 解决的是"生产力"问题（决策链 + 执行链）。两者是互补关系，不是替代关系。

四、工程决策：什么时候该用 Agent？

不是所有场景都适合 Agent。在实际项目中，我使用一个 2×2 矩阵来做架构选型。

两个核心维度：

• 任务动态性：执行路径是否固定？任务中是否会出现意外情况需要重新决策？
• 容错度：搞砸了的成本多高？能不能接受 Agent 的试错？

4.1 低动态 × 低容错 → 传统 Workflow

任务步骤固定，搞砸了代价高。

典型场景：财务报表自动报销流。流程是"提交 → 审核 → 入账"，每一步有明确的规则校验。用代码写死流程，零决策空间。

方案：不用 Agent。传统规则引擎或 DAG 工作流足矣。

4.2 高动态 × 高容错 → 纯 Agent

任务多变，试错成本低。

典型场景：竞品市场数据自主调研、创意文案多轮迭代。调研方向可能根据初步结果不断调整，文案的好坏没有唯一标准。

方案：让 Agent 自主规划、执行、迭代。人类只在最后审阅结果。

4.3 高动态 × 低容错 → Human-in-the-loop Agent

任务多变，但搞砸了代价高——这是企业级场景中最常见也最棘手的一类。

典型场景：智能代码重构、自动化漏洞修复、金融交易决策。Agent 可以提方案，但不能直接执行。

方案：Agent 负责"提议"，人类负责"批准"。这是目前生产环境中 Agent 落地最稳健的模式。

核心原则：不要为了用 Agent 而用 Agent。决策矩阵的底层逻辑是——让机器的归机器，让确定性的归确定性，让需要人类判断的保持人类判断。

五、30 行伪代码看懂 Agent 本质

讲再多理论，不如一段代码直观。下面是 Agent 核心循环的最小实现骨架。

classMinimalAgent:def__init__(self,llm,tools,memory):self.llm=llm# 大语言模型self.tools=tools# "{工具名: 函数}" 字典self.memory=memory# 短期 + 长期记忆defrun(self,user_goal):self.memory.add("user",user_goal)whileTrue:# ← Agent 的本质：一个有退出条件的死循环# 1. 感知与规划 (Think)context=(f"目标:{user_goal}\n"f"历史与环境状态:{self.memory.get_all()}\n"f"可用工具:{self.tools.list()}")thought,action,action_input=self.llm.decide(context)print(f"[思考]:{thought}")# 2. 终止条件 (Finish)ifaction=="FINISH":returnaction_input# 最终结果# 3. 执行 (Act) & 观察 (Observe)try:print(f"[执行]: 调用{action}，参数:{action_input}")observation=self.tools.execute(action,action_input)exceptExceptionase:observation=f"工具执行报错:{e}，请修正参数或更换方法。"# 4. 记忆更新self.memory.add("environment",f"执行{action}的结果:{observation}")

这段代码暴露了 Agent 核心的三个真相：

1. Agent 就是一个while True。只要 LLM 觉得任务没完成，它就会一直 “思考 → 尝试 → 失败 → 重试”。这个循环是 Agent 区别于传统程序的最根本特征——传统程序按固定路径执行，Agent 按目标驱动执行。

2. Agent 的容错能力来自异常捕获。注意try/except块：工具报错不是终点，而是新的环境信息。LLM 下一轮推理时会看到"上次调用失败了"，然后自动换参数或换策略。

3. 终止权在 LLM 手里。什么算"任务完成"？不是代码判断的，是 LLM 自己输出FINISH。这意味着同一段代码，不同的 LLM、不同的系统提示词，会产生完全不同的行为——这也是 Agent 的不可控性之源。

六、总结

回到标题：Agent 不是"会调 API 的 Chatbot"。

本文的核心结论可以浓缩为三句话：

1.Chatbot 改变了我们获取信息的方式，Agent 正在改变我们交付工作的方式。
2.Function Calling 只是给 LLM 装上了手指，但拥有手指不意味着大脑知道怎么弹钢琴。
3。Agent 的本质是在概率引擎外面包裹了一层确定性状态机。LLM 负责推理，状态机负责循环和边界。

如果你正在评估自己的业务是否需要 Agent，请回到第四节的决策矩阵：你的任务动态性多高？容错度多高？这两个问题回答清楚了，架构选型的答案自然浮现。

感谢看到这里。这个系列后面应该还有几篇，边学边写。如果你也在做 Agent 相关的东西，或者对文章里的观点有不同看法，欢迎留言。拍砖比点赞更有价值。