Agent 不是会调 API 的 Chatbot——重新理解 AI Agent 的本质Hi我是小z。最近几个天在学习 Agent 过程中攒了一些笔记零零散散记在 Notion 里也没人看。不如整理出来写成系列。这是第一篇聊聊一个最基础但也最容易吵起来的问题Agent 到底是个什么东西。声明本文中的机票退改签智能助手为虚构教学案例仅用于串联知识点。目录一、从 Chatbot 到 Agent一个案例看懂三级跃迁二、解剖 AgentLLM 规划 工具 记忆三、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属于特价舱。退票手续费 ¥47430%可退 ¥1,106。目前同日 MU5102 航班最低票价 ¥1,280。退票重买总成本 ¥1,754改签总成本 ¥1,438。建议您选择改签可节省 ¥316。”比 Chatbot 强太多了——准确、有计算、有建议。但用户还是得自己去操作。核心困境知识检索做到了极致但执行能力为零。第三阶段Agent交托目标闭环执行用户输入“帮我退了改签今天最便宜的航班。”Agent 做的事情理解目标退票 改签最便宜航班而不是查政策查订单和航班获取当前订单详情和同日所有可用航班计算成本退票手续费 ¥474退票重买 vs 改签的两种方案成本自主决策发现改签比退票重买便宜 ¥316选择改签方案执行操作锁定 MU5102 座位发起改签请求请求确认向用户推送扣款确认用户只需点一次同意用户要做的事从理解政策→比价→填表→支付→等待降维到看一眼点确认。三种形态的本质差异对比维度ChatbotRAGAgent输入Prompt指令Prompt 知识库Goal目标 Constraints约束核心能力检索 生成文本精准检索 上下文生成感知 → 规划 → 执行 → 反馈输出一段回复文本带数据的精确回复已完成的任务结果用户感受“还得我自己干”“知道了但我还得操作”“这就办完了”执行闭环无无有Agent 和 Chatbot 的关键分界线不在于有没有调用 API而在于谁在承担执行的任务和决策。Chatbot 告诉你路线Agent 直接把你送到目的地。二、解剖 AgentLLM 规划 工具 记忆2.1 四个核心组件一个合格的 Agent 由四个组件构成缺一个都会导致能力坍塌LLM大语言模型Agent 的大脑负责推理和决策。但它不是全部——只是一个组件。Planning规划能力将用户目标分解为可执行的子任务序列。规划不是一次性的而是在执行过程中根据工具返回的结果不断修正。Tools工具Agent 的手脚包括 API 调用、代码执行、数据库查询、网页浏览等。Memory记忆短期记忆当前对话上下文 长期记忆用户偏好、历史决策让 Agent 的每次决策有据可依。Agent 的本质在 LLM 这个概率引擎外面包裹了一层确定性的状态机。LLM 负责推理状态机负责控制循环和边界约束。2.2 图Agent 四要素 ReAct 动态飞轮这张图最关键的不是四个方块而是箭头。Agent 不是LLM 想了想 → 调用工具 → 结束的线性流水线。它是一个 ReActReasoning Acting动态循环Think推理基于当前状态和记忆LLM 决定下一步做什么Act执行调用对应工具Observe观察获取工具返回结果Reflect反思结果符合预期吗如果工具报错换一套参数重试如果发现新信息修正后续计划这个循环持续运转直到 LLM 自己判断目标已达成并输出FINISH。2.3 Function Calling 不是 Agent这是本文最想澄清的一个误区。Function Calling 是 2023 年 OpenAI 推出的能力让 LLM 输出结构化的函数调用请求。它给 LLM 装上了手指但拥有手指不意味着大脑知道怎么弹钢琴。来看区别传统 Function Calling 模式程序员在服务端写死了判断逻辑——先调用 AA 返回结果后根据 if-else 决定是否调用 B。LLM 的角色是分类器把用户意图映射到预定义的 if 分支里。真正的 Agent 模式程序员只给 LLM 一个目标和一组工具描述。LLM 自己决定先调 A 还是 B根据 A 的结果决定要不要调 CC 报错了换参数重试最终发现所有工具都解决不了时——自己告诉用户这个我办不到原因如下。一句话总结Function Calling 是 LLM 被代码调用Agent 是 LLM 主动调用代码。三、RAG 与 Agent知识 vs 任务很多人会问“Agent 就是 RAG 的升级版吗”这是一个范畴错误。RAG 和 Agent 解决的是不同维度的问题。维度RAGAgent核心问题“我不知道让我查一下”“我要完成一件事让我想想怎么做”本质知识检索增强任务自主执行输出更准确的文本已完成的任务结果典型场景问公司报销政策是什么说帮我把这张发票报销了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.llmllm# 大语言模型self.toolstools# {工具名: 函数} 字典self.memorymemory# 短期 长期记忆defrun(self,user_goal):self.memory.add(user,user_goal)whileTrue:# ← Agent 的本质一个有退出条件的死循环# 1. 感知与规划 (Think)context(f目标:{user_goal}\nf历史与环境状态:{self.memory.get_all()}\nf可用工具:{self.tools.list()})thought,action,action_inputself.llm.decide(context)print(f[思考]:{thought})# 2. 终止条件 (Finish)ifactionFINISH:returnaction_input# 最终结果# 3. 执行 (Act) 观察 (Observe)try:print(f[执行]: 调用{action}参数:{action_input})observationself.tools.execute(action,action_input)exceptExceptionase:observationf工具执行报错:{e}请修正参数或更换方法。# 4. 记忆更新self.memory.add(environment,f执行{action}的结果:{observation})这段代码暴露了 Agent 核心的三个真相Agent 就是一个while True。只要 LLM 觉得任务没完成它就会一直 “思考 → 尝试 → 失败 → 重试”。这个循环是 Agent 区别于传统程序的最根本特征——传统程序按固定路径执行Agent 按目标驱动执行。Agent 的容错能力来自异常捕获。注意try/except块工具报错不是终点而是新的环境信息。LLM 下一轮推理时会看到上次调用失败了然后自动换参数或换策略。终止权在 LLM 手里。什么算任务完成不是代码判断的是 LLM 自己输出FINISH。这意味着同一段代码不同的 LLM、不同的系统提示词会产生完全不同的行为——这也是 Agent 的不可控性之源。六、总结回到标题Agent 不是会调 API 的 Chatbot。本文的核心结论可以浓缩为三句话1.Chatbot 改变了我们获取信息的方式Agent 正在改变我们交付工作的方式。2.Function Calling 只是给 LLM 装上了手指但拥有手指不意味着大脑知道怎么弹钢琴。3。Agent 的本质是在概率引擎外面包裹了一层确定性状态机。LLM 负责推理状态机负责循环和边界。如果你正在评估自己的业务是否需要 Agent请回到第四节的决策矩阵你的任务动态性多高容错度多高这两个问题回答清楚了架构选型的答案自然浮现。感谢看到这里。这个系列后面应该还有几篇边学边写。如果你也在做 Agent 相关的东西或者对文章里的观点有不同看法欢迎留言。拍砖比点赞更有价值。
【Agent】不是“会调 API 的 Chatbot“——重新理解 AI Agent 的本质
Agent 不是会调 API 的 Chatbot——重新理解 AI Agent 的本质Hi我是小z。最近几个天在学习 Agent 过程中攒了一些笔记零零散散记在 Notion 里也没人看。不如整理出来写成系列。这是第一篇聊聊一个最基础但也最容易吵起来的问题Agent 到底是个什么东西。声明本文中的机票退改签智能助手为虚构教学案例仅用于串联知识点。目录一、从 Chatbot 到 Agent一个案例看懂三级跃迁二、解剖 AgentLLM 规划 工具 记忆三、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属于特价舱。退票手续费 ¥47430%可退 ¥1,106。目前同日 MU5102 航班最低票价 ¥1,280。退票重买总成本 ¥1,754改签总成本 ¥1,438。建议您选择改签可节省 ¥316。”比 Chatbot 强太多了——准确、有计算、有建议。但用户还是得自己去操作。核心困境知识检索做到了极致但执行能力为零。第三阶段Agent交托目标闭环执行用户输入“帮我退了改签今天最便宜的航班。”Agent 做的事情理解目标退票 改签最便宜航班而不是查政策查订单和航班获取当前订单详情和同日所有可用航班计算成本退票手续费 ¥474退票重买 vs 改签的两种方案成本自主决策发现改签比退票重买便宜 ¥316选择改签方案执行操作锁定 MU5102 座位发起改签请求请求确认向用户推送扣款确认用户只需点一次同意用户要做的事从理解政策→比价→填表→支付→等待降维到看一眼点确认。三种形态的本质差异对比维度ChatbotRAGAgent输入Prompt指令Prompt 知识库Goal目标 Constraints约束核心能力检索 生成文本精准检索 上下文生成感知 → 规划 → 执行 → 反馈输出一段回复文本带数据的精确回复已完成的任务结果用户感受“还得我自己干”“知道了但我还得操作”“这就办完了”执行闭环无无有Agent 和 Chatbot 的关键分界线不在于有没有调用 API而在于谁在承担执行的任务和决策。Chatbot 告诉你路线Agent 直接把你送到目的地。二、解剖 AgentLLM 规划 工具 记忆2.1 四个核心组件一个合格的 Agent 由四个组件构成缺一个都会导致能力坍塌LLM大语言模型Agent 的大脑负责推理和决策。但它不是全部——只是一个组件。Planning规划能力将用户目标分解为可执行的子任务序列。规划不是一次性的而是在执行过程中根据工具返回的结果不断修正。Tools工具Agent 的手脚包括 API 调用、代码执行、数据库查询、网页浏览等。Memory记忆短期记忆当前对话上下文 长期记忆用户偏好、历史决策让 Agent 的每次决策有据可依。Agent 的本质在 LLM 这个概率引擎外面包裹了一层确定性的状态机。LLM 负责推理状态机负责控制循环和边界约束。2.2 图Agent 四要素 ReAct 动态飞轮这张图最关键的不是四个方块而是箭头。Agent 不是LLM 想了想 → 调用工具 → 结束的线性流水线。它是一个 ReActReasoning Acting动态循环Think推理基于当前状态和记忆LLM 决定下一步做什么Act执行调用对应工具Observe观察获取工具返回结果Reflect反思结果符合预期吗如果工具报错换一套参数重试如果发现新信息修正后续计划这个循环持续运转直到 LLM 自己判断目标已达成并输出FINISH。2.3 Function Calling 不是 Agent这是本文最想澄清的一个误区。Function Calling 是 2023 年 OpenAI 推出的能力让 LLM 输出结构化的函数调用请求。它给 LLM 装上了手指但拥有手指不意味着大脑知道怎么弹钢琴。来看区别传统 Function Calling 模式程序员在服务端写死了判断逻辑——先调用 AA 返回结果后根据 if-else 决定是否调用 B。LLM 的角色是分类器把用户意图映射到预定义的 if 分支里。真正的 Agent 模式程序员只给 LLM 一个目标和一组工具描述。LLM 自己决定先调 A 还是 B根据 A 的结果决定要不要调 CC 报错了换参数重试最终发现所有工具都解决不了时——自己告诉用户这个我办不到原因如下。一句话总结Function Calling 是 LLM 被代码调用Agent 是 LLM 主动调用代码。三、RAG 与 Agent知识 vs 任务很多人会问“Agent 就是 RAG 的升级版吗”这是一个范畴错误。RAG 和 Agent 解决的是不同维度的问题。维度RAGAgent核心问题“我不知道让我查一下”“我要完成一件事让我想想怎么做”本质知识检索增强任务自主执行输出更准确的文本已完成的任务结果典型场景问公司报销政策是什么说帮我把这张发票报销了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.llmllm# 大语言模型self.toolstools# {工具名: 函数} 字典self.memorymemory# 短期 长期记忆defrun(self,user_goal):self.memory.add(user,user_goal)whileTrue:# ← Agent 的本质一个有退出条件的死循环# 1. 感知与规划 (Think)context(f目标:{user_goal}\nf历史与环境状态:{self.memory.get_all()}\nf可用工具:{self.tools.list()})thought,action,action_inputself.llm.decide(context)print(f[思考]:{thought})# 2. 终止条件 (Finish)ifactionFINISH:returnaction_input# 最终结果# 3. 执行 (Act) 观察 (Observe)try:print(f[执行]: 调用{action}参数:{action_input})observationself.tools.execute(action,action_input)exceptExceptionase:observationf工具执行报错:{e}请修正参数或更换方法。# 4. 记忆更新self.memory.add(environment,f执行{action}的结果:{observation})这段代码暴露了 Agent 核心的三个真相Agent 就是一个while True。只要 LLM 觉得任务没完成它就会一直 “思考 → 尝试 → 失败 → 重试”。这个循环是 Agent 区别于传统程序的最根本特征——传统程序按固定路径执行Agent 按目标驱动执行。Agent 的容错能力来自异常捕获。注意try/except块工具报错不是终点而是新的环境信息。LLM 下一轮推理时会看到上次调用失败了然后自动换参数或换策略。终止权在 LLM 手里。什么算任务完成不是代码判断的是 LLM 自己输出FINISH。这意味着同一段代码不同的 LLM、不同的系统提示词会产生完全不同的行为——这也是 Agent 的不可控性之源。六、总结回到标题Agent 不是会调 API 的 Chatbot。本文的核心结论可以浓缩为三句话1.Chatbot 改变了我们获取信息的方式Agent 正在改变我们交付工作的方式。2.Function Calling 只是给 LLM 装上了手指但拥有手指不意味着大脑知道怎么弹钢琴。3。Agent 的本质是在概率引擎外面包裹了一层确定性状态机。LLM 负责推理状态机负责循环和边界。如果你正在评估自己的业务是否需要 Agent请回到第四节的决策矩阵你的任务动态性多高容错度多高这两个问题回答清楚了架构选型的答案自然浮现。感谢看到这里。这个系列后面应该还有几篇边学边写。如果你也在做 Agent 相关的东西或者对文章里的观点有不同看法欢迎留言。拍砖比点赞更有价值。
