跳到正文

Agent 核心组件与工作流程?

大模型 Agent 的基本概念、规划与工具调用机制详解

原题：请谈谈您对大语言模型Agent的理解，包括Agent的基本概念、核心组件以及在实际应用中的工作流程。

Agent · 商汤科技真题

30 秒回答

  1. Agent的定义：大模型作为"大脑"，具备感知、规划、行动、记忆四大能力
  2. 核心组件：规划模块、记忆模块、工具调用模块、行动执行模块
  3. 典型架构：ReAct推理-行动循环、Reflexion自我反思
  4. 实际工作流程：任务理解→拆解规划→工具调用→观察反馈→迭代优化

回答与解析

答案要点

  • Agent的定义：大模型作为"大脑"，具备感知、规划、行动、记忆四大能力
  • 核心组件：规划模块、记忆模块、工具调用模块、行动执行模块
  • 典型架构：ReAct推理-行动循环、Reflexion自我反思
  • 实际工作流程：任务理解→拆解规划→工具调用→观察反馈→迭代优化
  • 与RAG的区别：Agent强调动态决策和工具交互，RAG侧重静态知识检索

基本概念

大模型Agent = LLM作为"大脑" + 外部工具/环境交互能力。区别于单次问答，Agent能自主决策、多步执行、动态调整以完成复杂任务。

核心特征用四个字概括：感知-规划-行动-记忆。

核心组件

模块 作用 典型实现
规划 任务拆解、策略制定 CoT、ReAct、ToT
记忆 短期上下文+长期知识存储 向量数据库、摘要缓存
工具调用 扩展模型能力边界 Function Calling、API接口
行动执行 与外部环境交互 代码执行、浏览器操作、数据库查询

典型工作流程（以ReAct为例）

思考(Thought) → 行动(Action) → 观察(Observation) → ... → 完成

实例：查询"某公司最新股价并分析是否适合买入"

  1. 理解意图：识别需要股价数据+分析判断
  2. 规划拆解：先查股价 → 获取财报 → 综合评估
  3. 工具调用：调用金融API获取实时数据
  4. 观察反馈：API返回结果，检查是否满足需求
  5. 迭代推理：数据不足则补充查询，最终生成结论

与RAG的关键区别

RAG Agent
知识来源 静态文档库 动态工具+实时API
决策能力 单次检索生成 多步规划、错误恢复
适用场景 知识问答 复杂任务执行（数据分析、自动运维等）

实际项目中两者常结合使用：Agent负责流程 orchestration，RAG作为其中一个工具节点提供领域知识。

口语版讲法(约4分钟)

  • 一句话点题：Agent的本质是让大模型从问答走向执行
  • 核心组件：规划、记忆、工具调用、行动
  • 工作流程：ReAct循环加一个具体业务例子
  • 边界划分：Agent vs RAG，落地常结合
  • 落地风险与判断收尾

这道题其实是在问，怎么让大模型从一个只会回答问题的聊天机器人，变成一个能真正动手干活的智能体。我的理解是，Agent的核心就是让大模型拥有感知、规划、行动和记忆这四样东西，说白了就是给它一个大脑，再给它手脚和记事本，让它能自主决策、多步执行、动态调整，去完成一个复杂的任务。

具体说一下核心组件。先看规划，就是任务拆解和策略制定，比如用 ReAct 或 Chain-of-Thought 来引导模型一步步想。接着说记忆，分短期和长期，短期就是上下文窗口，长期可以存到 Vector Database 里，方便后续复用。再补充工具调用，通过 Function Calling 去调用外部 API、执行代码、查数据库，这是扩展能力边界的关键。最后补充行动执行，就是实际跟环境交互，比如操作浏览器、发请求。这四个模块配合起来，才能让Agent真正跑起来。

工作流程的话，最经典的还是ReAct循环，就是思考、行动、观察、再思考，直到任务完成。我举个例子，比如一个客服场景，用户问“我上周买的手机降价了，能退差价吗？”Agent首先要理解意图，识别出这是价格保护政策。然后拆解任务：查用户订单、查当前价格、查价保规则。接着调用工具，比如订单系统API和价格API。观察到返回数据后，再推理判断是否满足价保条件。如果信息不够，比如规则没写清楚，它可能再去查知识库。最后生成回复，并执行退款操作。整个过程是动态的，每一步的观察结果都会影响下一步的决策。

这里有个重要的边界划分，就是Agent和 RAG 的区别。很多人容易混，其实RAG更适合静态知识问答，比如查公司政策、手册内容，它是单次检索加生成。而Agent强调的是动态决策和工具交互，适合需要多步推理、调用外部系统的场景。但实际落地时，我通常会把两者结合：Agent做流程编排，RAG作为其中一个工具节点提供领域知识。比如刚才的客服例子，价保规则就可以用RAG从文档库里检索出来，再交给Agent做判断。

但这里有个前提，就是Agent的稳定性问题。如果规划步骤太多，模型很容易在中间跑偏或者陷入死循环。所以上线前我会特别关注错误恢复机制，比如设置最大步数、加入自我反思，像 Reflexion 那样让模型能意识到自己错了并重试。常见失败场景就是工具调用返回了意外格式，模型没处理好，直接崩了。所以我的做法是给每个工具调用加严格的输入输出校验，并且兜底一个“我不知道”的回复，避免瞎编。

所以说，我更倾向于把Agent看作一个轻量级的任务编排引擎，而不是万能解决方案。它的价值在于让大模型从“会说话”变成“会办事”，但前提是任务边界清晰、工具稳定、有足够的容错机制。如果让我选，我会优先在那些步骤明确、反馈闭环的场景上Agent，比如自动运维、数据分析，而不是一上来就做开放式的复杂任务。

关键一句:Agent的稳定性问题，尤其是错误恢复和死循环风险

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你在做一个智能客服Agent，用户问“帮我查下订单，然后如果超时了就退款”。你打算怎么让大模型一步步去调用查订单API、判断超时、再触发退款？这里面Agent是怎么工作的？

  2. 问法 2 · 层层追问

    大模型做单轮问答你肯定熟，但如果要让模型自主完成一个多步骤任务，比如先搜索再计算最后写报告，你觉得模型需要哪些能力……那这些能力具体怎么组织起来？像记忆、规划这些模块是怎么配合的？

  3. 问法 3 · 直球架构

    请从架构角度谈谈你对大模型Agent的理解：它由哪些核心组件组成？典型的工作流程是怎样的？和RAG相比，本质区别在哪？

同模块相关题目