AI Agent 架构原理详解：从一次提问到任务完成的完整闭环

引言：Agent 到底是什么，它和普通大模型对话有何不同？

很多人第一次接触大模型时，得到的体验是「聊天」：你问一句，模型答一句。这种形态下，大模型（LLM）本质上只是一个会思考、会生成文本的「大脑」——它被封装在一个对话框里，不能联网、不能查数据库、不能发邮件、不能执行代码，甚至记不住上一周你和它说过什么。它所有的「知识」都被冻结在训练完成的那一刻。

而 AI Agent（智能体） 要解决的，正是「让大脑长出四肢、装上记忆、接上外部世界」这件事。一个真正的 Agent，不再只是「回答问题」，而是理解目标 → 自主规划 → 调用工具行动 → 观察反馈 → 反思修正 → 直到把任务真正做完。它从一个「聊天机器人」升级成了一个「能办事的数字员工」。

如果用一句话概括 Agent 的架构本质，那就是：

Agent = LLM（决策大脑） + 规划（Planning） + 执行循环（Action Loop） + 工具（Tools） + 记忆（Memory） + 知识（Knowledge / RAG）

其中 LLM 是唯一的「决策中枢」，其余一切都是它的「外设」：工具是手脚，记忆是经验，知识是外脑，执行循环是它跳动的心脏。理解了这句话，就理解了整张架构图。

下面这张「Agent 搭建—架构流程图」描绘的，正是从用户输入（Query）到生成最终回复（Final Answer）的完整主线。我们就沿着这条主线，一层一层拆开看。

1. 整体架构总览：一条从 Query 到 Final Answer 的主线

1.1 起点——用户输入（Query）

一切始于用户的输入。在流程图的最顶端，是一个绿色的「用户输入（Query）」框。这里要注意的是，「输入」在工程上往往不是一句孤立的文本：它可能携带多模态内容（文字、图片、文件、表格），也可能携带会话上下文（这是第几轮对话、用户之前说过什么）、用户身份与权限信息等。Query 是 Agent 感知世界的「感官信号」，它的质量与完整度，直接决定了后续规划的方向。

1.2 中枢——意图识别与任务规划（LLM）

Query 进入系统后，第一个核心节点是「意图识别与任务规划（LLM）」。这是整张图的「司令部」。它要做两件事：

1. 意图识别：用户到底想要什么？是闲聊、是知识问答、是要执行一个操作、还是要完成一个多步骤的复杂任务？
2. 任务规划：如果任务复杂，就把它拆解成若干可执行的子步骤，并初步规划出一条行动路径——先做什么、后做什么、可能需要哪些工具或知识。

请注意流程图里一个容易被忽略的细节：「意图识别与任务规划」这个框，和右侧的「记忆系统（Memory）」之间是一根双向箭头。这意味着 LLM 在做规划时，并不是「失忆」地只看当前这一句话，而是会主动去读取记忆——调取对话历史（短期记忆）以理解上下文，调取长期沉淀的用户偏好与事实（长期记忆）以做个性化决策；同时，规划产生的重要信息也会写回记忆。这正是 Agent 显得「聪明、连贯、懂你」的根本原因。

1.3 心脏——执行循环（Action Loop）

规划完成后，流程向下进入整张图最核心、也是 Agent 区别于普通对话的标志性结构：执行循环（Action Loop）。

普通对话模型是「一问一答」的直线：输入 → 输出，结束。而 Agent 是循环：它会反复地「想一步、做一步、看一眼结果、再想下一步」，直到任务完成。这个循环在学术上有一个著名的范式叫 ReAct（Reasoning + Acting，推理与行动交替），流程图把它精确地拆成了五个递进的环节，每个环节右侧还标注了它要回答的那个「灵魂问题」：

这五步构成一个闭环：Observation 的结果会重新喂回 Thinking，于是模型带着「新获得的事实」继续推理。比如模型先思考「要分析销售下滑，得先拿到销售数据」→ 选择「数据库查询工具」→ 填参数 → 调用 → 观察到数据；接着再思考「数据拿到了，但需要行业对比，去搜一下行业报告」→ 选择「搜索工具」……如此往复。Agent 的「智能」，很大程度上就体现在这个循环能自主地、多轮地推进，而不需要人类在每一步都下指令。

1.4 闸门——「任务完成？」的判断

执行循环每跑一轮，都会来到流程图里的菱形判断节点：「任务完成？」。

• 如果判断为「否 / 未完成」，流程沿右侧的箭头回到执行循环的「思考」环节，继续下一轮 ReAct。
• 如果判断为「是」，流程才向下走到「生成最终回复」。

这个菱形节点是 Agent 自主性（autonomy） 的集中体现：模型自己评估「我手里的信息够不够、目标达成了没有」，自己决定何时停。一个设计良好的 Agent，必须在这里有清晰的停止准则，否则就会陷入无意义的空转（这一点我们在第 6 节会专门谈工程上的防护）。

1.5 终点——生成最终回复（Final Answer）

当任务被判定完成，Agent 进入「生成最终回复（Final Answer）」环节。这里要打破一个刻板印象：Agent 的输出不一定是一段文字。流程图在底部列出了四种典型输出形态：

• 文本回复：自然语言的答案或总结；
• 结构化数据：JSON、表格等，便于下游系统直接消费；
• 图表 / 可视化：把数据画成图，直观呈现；
• 文件 / 报告：直接产出一份 PDF、Word、PPT 等交付物。

也就是说，一个成熟的 Agent 不仅能「说」，还能「交付」。它把执行循环里收集、计算、检索到的一切，整合、加工、排版成用户真正能用的成果。

1.6 三大「外挂系统」

把上面这条主线撑起来的，是分布在主流程两侧的三个虚线框系统。流程图左下角的图例用颜色做了分类（输入/输出、核心流程、执行循环、工具/外部、记忆/知识），而这三个外挂系统正是 Agent 能力的「放大器」：

• 工具库（Tools）——左侧：搜索工具、计算工具、查询工具、文档工具、代码工具……它是 Agent 的手脚；
• 记忆系统（Memory）——右上：短期记忆（对话历史）+ 长期记忆（知识库/向量库），它是 Agent 的经验；
• 知识库（Knowledge）——右侧：企业文档、FAQ 问答、业务数据、外部知识……它是 Agent 的外脑。

工具和知识这两块内容太重要，值得各自用一整章深挖。我们先快速过一遍记忆，然后分别展开工具与知识。

2. 记忆系统：让无状态的模型拥有「经验」

LLM 本身是无状态的——每次调用，它都像一个刚睡醒、不记得昨天的人。如果不在外部给它配记忆，它就无法维持一段连贯的长对话，更无法记住「这个用户喜欢简洁风格」「上次他让我把报告存成 PDF」这类跨会话的事实。因此 Agent 架构里必须有一个独立的记忆系统，通常分为两层：

• 短期记忆（对话历史）：存放当前会话的上下文，即「这一轮对话里你我都说了什么」。它一般直接拼进模型的上下文窗口，让模型理解指代、承接上文。它的生命周期短，会话结束或窗口溢出后就会被裁剪或摘要。
• 长期记忆（知识库 / 向量库）：存放需要跨会话持久化的信息，比如用户画像、历史决策、沉淀的事实。它通常以向量化的形式存进向量数据库，在需要时通过检索召回（这又和下一节的 RAG 技术相通）。

记忆系统通过那根双向箭头与 LLM 中枢交互：规划时「读」记忆，行动后「写」记忆。可以这样类比——短期记忆是「工作台上的便签」，长期记忆是「归档的档案柜」，而 LLM 是那个会自己翻档案、自己记笔记的人。

3. 深入一：Agent 如何调用工具（Function Calling）

工具库是 Agent 的「手脚」，但大脑是怎么指挥手脚的？答案就是 Function Calling（函数调用）。第二张图《Agent 如何调用工具？》把这件事讲得非常透彻，它的开篇定义值得反复品味：

Function Calling 是大模型连接外部世界的桥梁。当模型发现问题需要外部信息或执行操作时，会自动生成结构化的函数调用参数，交由工具执行，获取结果后再生成最终回复。

3.1 为什么必须有 Function Calling？

回到 LLM 的先天局限：它的知识会过时、它不能实时联网、它做精确计算容易出错、它根本无法「动手」去发邮件或改数据库。如果只靠模型自己「凭空生成」，那么「北京明天天气」这种问题，它要么瞎编，要么只能给一个训练数据里的旧答案。

Function Calling 的意义在于：让模型承认「这件事我不知道/我做不了，但我知道该找谁做」，然后以机器可读的方式，把「该找谁、带什么参数」表达出来，交给真正的系统去执行。模型负责「决策与表达」，外部系统负责「执行与求真」，二者各司其职。

3.2 完整链路：以「查天气」为例的七步走

第二张图用一个清晰的例子串起了全流程，我们逐步拆解：

1. 用户提问：「我想查一下北京明天的天气怎么样？」
2. Agent 大模型理解并判断：模型结合系统提示词和可用工具列表，判断这个问题是否需要调用工具。注意——模型不是「无脑调工具」，它会先评估：闲聊、常识问答这类它自己能答的，就不调；需要实时数据或执行操作的，才调。
3. 分支决策：
   • 3A 需要调用工具：模型生成一段结构化的函数调用请求（参数），例如：

     {
       "name": "get_weather",
       "arguments": {
         "city": "北京",
         "date": "2025-05-20"
       }
     }
     

     注意它精准地填出了函数名 get_weather 和参数 city、date——这正是「结构化」的威力。
   • 3B 无需调用工具：比如用户在闲聊或问常识，模型就直接生成最终回复，不走工具。
4. 工具执行器：系统的 runtime 接收到这段 JSON，解析参数，根据 name 找到对应的工具/接口。
5. 调用外部 API / 工具：执行器真正去请求天气 API（或查询数据库、搜索引擎、计算器等）。这一步发生在模型之外，是真实世界的网络请求或代码执行。
6. 执行结果返回：工具把结果回传给 Agent，例如 {"weather": "晴", "temp": "24℃"}。
7. 最终回复给用户：关键点来了——这份原始 JSON 结果不会直接甩给用户，而是作为新的上下文再次交给大模型，由模型把它「翻译」成自然语言：「北京明天是晴天，气温 24℃，适合出行！」

请特别注意第 7 步所体现的「结果回传闭环」：工具的结果不是终点，而是模型生成最终答案的原料。模型在这里扮演了「理解 + 润色 + 综合」的角色，把冷冰冰的接口返回变成人话，甚至能结合用户原问题做针对性表达（用户问「怎么样」，模型就补了一句「适合出行」）。

3.3 四个核心要点

第二张图左下角的「核心要点」框，把 Function Calling 的精髓浓缩成四条，正好对应链路上的四个关键能力：

• 意图识别：大模型判断问题是否需要借助外部工具解决（对应第 2、3 步的「该不该调」）；
• 函数调用：以结构化 JSON 格式生成函数名和参数（对应 3A，「调哪个、带什么」）；
• 工具执行：由执行器调用真实世界的 API 或工具完成任务（对应第 4、5 步，「真正去干」）；
• 结果回传闭环：结果返回给模型，模型结合结果生成最终回复（对应第 6、7 步，「干完再说」）。

3.4 原理补遗：模型「并没有」在执行

这里有一个初学者最容易误解、却又最关键的认知，值得点破：大模型本身并不执行任何函数。它做的全部事情，是在它的输出序列里，按照约定格式「写出」一段 JSON 文本。真正「解析 JSON、发网络请求、跑代码、拿结果、再拼回 prompt」的，是模型外部的编排程序（runtime / orchestrator）。

那么模型凭什么能「写出」格式正确的 JSON、还能选对函数名和参数？这背后是两件事的配合：

1. 工具描述（Function Schema）：在调用模型前，系统会把所有可用工具的「说明书」——包括函数名、功能描述、参数的名称/类型/含义/是否必填（通常用 JSON Schema 表达）——连同系统提示词一起喂给模型。模型是「看着说明书」来决定调哪个、怎么填参的。工具描述写得好不好，直接决定了模型选工具、填参数的准确率，这是工程上极重要却常被低估的一环。
2. 模型的训练对齐：现代大模型在预训练与指令微调阶段，见过海量「给定工具描述与用户问题 → 输出正确函数调用」的样本，从而学会了在恰当的时机、以恰当的格式产出调用请求。

把这两点合起来看，Function Calling 的本质就是：用自然语言把「能力菜单」告诉模型，模型用结构化语言「点菜」，外部系统「上菜」，模型再「点评」。第二张图右下角那句点睛之笔说得很到位：「有了 Function Calling，Agent 才能真正『行动』，而不只是『聊天机器人』！」

3.5 典型应用场景

凡是「需要实时信息」或「需要执行动作」的场景，都是 Function Calling 的用武之地：天气查询、航班订票、订单查询、数据库查询、发送邮件、生成报表、代码执行……可以说，工具库有多丰富，Agent 的能力边界就有多宽。

4. 深入二：Agent 如何接入知识库（RAG）

工具解决了「能动手」的问题，而知识库解决的是「知道得对、知道得新、知道得私密」的问题。第三张图《Agent 如何接入知识库？》讲的核心技术就是 RAG（Retrieval-Augmented Generation，检索增强生成）。它的原理一句话概括：

在大模型回答问题前，先从知识库中检索相关信息，将检索到的内容作为上下文，让大模型生成更准确、更可靠的答案。

4.1 为什么需要 RAG？

模型参数里「记住」的知识有三大硬伤：有限（不可能装下全世界）、过时（训练截止后发生的事它不知道）、会幻觉（不知道时倾向于编得头头是道）。更要命的是，企业的私有数据（内部规章、产品手册、客户记录、业务报表）根本不在任何公开训练集里，模型天生就不知道。

RAG 的思路非常务实：与其把知识「塞进」模型脑子里，不如在回答时「翻书」。需要的时候去知识库里检索相关段落，把段落贴给模型，让模型「照着书答」。这样既保证了答案有据可依、可追溯，又能随时更新知识、纳入私有数据，还大幅缓解了幻觉。

4.2 离线流程：数据预处理与入库（只需跑一次或定期更新）

RAG 不是一条流水线，而是两条：一条离线、一条在线。第三张图右半部分画的「数据预处理与入库（离线流程）」，是把原始文档变成「可被检索」形态的准备工序，共五步：

1. 数据源：收集各种来源的原始文档——PDF、Word、网页、表格等。这是知识的「原料」。
2. 文档切分（Chunk）：把长文档切成小片段。为什么必须切？因为整篇文档太长，既塞不进模型上下文，也无法做精细的语义匹配。切分时要权衡 chunk 大小与重叠（overlap）：切太碎会丢失上下文，切太大会稀释语义、引入噪声；适当重叠可以避免一句话被拦腰截断。
3. 文本清洗：去除页眉页脚、乱码、无关符号等噪声，标准化文本，保证后续向量化与检索的质量。「垃圾进、垃圾出」在 RAG 里体现得淋漓尽致。
4. 向量化（Embedding）：用 Embedding 模型把每个文本片段转换成向量（一串高维浮点数）。向量的妙处在于：语义相近的文本，向量在空间里也靠得近。于是「语义相似」这件事，就被转化成了「向量距离近」这个可计算的问题。
5. 入库存储：通常双库并存——
   • 向量数据库（如 FAISS、Milvus）存储向量索引，用于快速的相似度检索；
   • 文档库存储原始文本片段，用于检索命中后把「原文」取出来贴给模型。

第三张图右下角的「小贴士」点出了离线流程的特性：它只需执行一次或定期更新。也就是说，知识是「提前备好」的，在线回答时不必临时处理文档，从而保证响应速度。

4.3 在线流程：实时检索与回答（每次提问都跑）

第三张图左半部分的「Agent 实时检索与回答（在线推理流程）」，是用户每次提问时真正发生的事，共七步：

1. 用户输入：用户提出问题。
2. 意图识别：理解问题、识别关键信息（这一步与整体架构里的规划环节呼应，判断是否需要去检索、检索什么）。
3. 问题向量化：把用户的问题也用同一个 Embedding 模型转成向量——只有用同一把「尺子」，问题向量和文档向量才能在同一空间里比较距离。
4. 检索召回：这里第三张图给出了一个工程上很关键的设计——BM25 关键词检索 + 向量相似度检索双路并行。
   • 向量检索擅长捕捉语义相似（换个说法也能找到）；
   • BM25 关键词检索擅长捕捉精确词匹配（专有名词、编号、术语等向量容易「模糊掉」的东西）。
     两者互补，称为混合检索（Hybrid Search），召回率与准确率通常都优于单路。
5. 重排序拼接 Prompt（Rerank + 构造上下文）：召回的候选片段往往较多且良莠不齐，于是用一个重排序模型（Reranker） 对它们按「与问题的相关性」重新打分排序，挑出最相关的若干条，再拼接成上下文，与用户问题一起组装成最终的 Prompt。
6. LLM 大模型：基于这份「带着参考资料」的 Prompt 生成回答。模型此时是「开卷考试」，答案 grounded 在检索到的内容上。
7. 输出答案：返回给用户。

注意图中那根从在线检索指向离线条目的虚线箭头，以及底部「知识库持续更新迭代」的循环箭头——它们说明：在线检索读的是离线条目建好的库，而库本身会随着新文档不断增量更新，形成一个活的、自我演进的知识系统。

4.4 RAG 与 Agent 的关系

在整体架构图里，知识库（Knowledge）是右侧的一个独立模块，用虚线箭头接入执行循环。这揭示了一个深刻的事实：在 Agent 中，RAG 既可以是一个被「执行循环」调用的能力（把「检索知识库」当作一种工具/动作），也可以作为规划与生成阶段的上下文增强。换句话说，工具调用让 Agent 能「做事」，RAG 让 Agent 能「查书」，二者在执行循环里被 LLM 统一调度——该动手时动手，该查书时查书，该既动手又查书时就交替进行。

5. 把一切串起来：一个综合例子看 Agent 如何协同

抽象讲完，我们用一个综合任务，把规划、执行循环、工具调用、知识检索、记忆、多形态输出一次性串起来，看看它们如何协同。

用户（一位销售总监）对 Agent 说：「帮我分析一下公司上季度销售下滑的原因，并出一份报告。」

Agent 内部大致会这样运转：

1. 意图识别与规划（中枢）：LLM 读取记忆，知道这位用户是销售总监、偏好图表+结论先行的报告风格；判断这是一个多步骤的复杂分析任务，规划出路径——①取销售数据 ②取行业/竞品信息 ③查内部复盘文档 ④做分析与归因 ⑤生成报告。
2. 执行循环第 1 轮：思考「先拿内部销售数据」→ 选择查询工具→ 填参数（上季度、按区域/品类）→ Function Call 查数据库 → 观察到明细数据。
3. 执行循环第 2 轮：思考「需要外部行业对比」→ 选择搜索工具→ 调用 → 观察到行业趋势。
4. 执行循环第 3 轮：思考「看看内部有没有现成的复盘/口径说明」→ 触发 RAG：把「上季度销售下滑 复盘」向量化 → 混合检索企业文档库 → 重排序 → 召回相关段落作为上下文。
5. 执行循环第 4 轮：思考「数据齐了，做归因计算」→ 选择代码/计算工具→ 跑一段分析 → 观察到归因结果（如某区域某品类同比 -30% 是主因）。
6. 任务完成判断：LLM 评估「数据、对比、归因都已具备，可以成稿」→ 判定是。
7. 生成最终回复：结合记忆里的风格偏好，产出一份带图表的文件报告，并把本次结论写回长期记忆，供下次复用。

可以看到，整张架构图里的每一个模块，都在这一个任务里被点亮了：中枢在规划，循环在推进，工具在动手，RAG 在查书，记忆在读写，最终交付在成型。这就是 Agent 的完整形态——它不是某个单点技术，而是一套以 LLM 为大脑、以循环为节律、把多种能力编排起来的系统。

6. 落地实践：原理之外，那些决定成败的工程细节

讲完原理，必须诚实地谈一谈：把这套架构真正跑稳，难点往往不在「懂不懂」，而在「细不细」。以下是落地时最该警惕的几个方面。

• 规划与模型能力是天花板：执行循环再精巧，也架不住中枢模型推理太弱。复杂任务对模型的规划、指令遵循、结构化输出能力要求极高，模型选型与提示工程是地基。
• 工具描述即产品：Function Calling 的准确率高度依赖工具 schema 的撰写。函数名是否自解释、描述是否说清「何时用/何时不用」、参数定义是否严谨，直接决定模型会不会「选错工具、填错参数」。要把工具描述当成写给模型看的「API 文档」来认真打磨。
• 循环必须有「刹车」：执行循环若没有最大步数限制与清晰的停止准则，模型可能陷入反复调用、原地打转的死循环，烧钱又超时。务必设置步数上限、重复动作检测、超时熔断。
• 错误处理与重试：工具会失败、接口会超时、检索会召回空。Agent 必须能「看见」失败（把错误信息作为 Observation 喂回思考），并自主决定重试、换工具或向用户求助，而不是直接崩掉。
• 记忆与上下文管理：上下文窗口有限，对话越长越要会裁剪、摘要、检索式记忆，否则要么爆窗口，要么被无关历史干扰。
• RAG 的召回质量是生命线：「检索不到，模型就答不对」。chunk 策略、Embedding 模型选型、混合检索、Rerank、甚至查询改写（query rewriting），每一环都影响最终答案。RAG 的优化往往是一个持续调参、持续评测的过程。
• 安全与权限边界：工具能「动手」，就意味着风险——误删数据、越权操作、对外发送敏感信息都可能发生。必须做权限控制、敏感操作二次确认、人类在环（human-in-the-loop），让 Agent 在受控的边界内行动。
• 可观测性与调试：Agent 是多步、非确定的系统，出问题难定位。务必记录每一步的思考、工具调用、参数、返回、检索命中（trace），否则线上排障将无从下手。
• 成本与延迟：多轮循环 + 多次模型调用 + 检索 + 重排，意味着更高的 token 消耗与更长的响应时间。需要在体验、质量、成本之间做权衡，必要时用缓存、并行调用、小模型分流等手段优化。

7. 结语：Agent 的本质，是一个「会自我推进的闭环系统」

回顾全文，三张图其实是从三个视角画了同一件事：

• 架构图给了骨架——一条从 Query 到 Final Answer 的主线，和一个不断跳动的执行循环；
• 工具调用图给了手脚的原理——Function Calling 让模型以结构化方式指挥外部世界；
• 知识库图给了外脑的原理——RAG 让模型在回答前先检索、有据可依。

把它们合起来，AI Agent 的架构原理可以凝练成一句话：

Agent 是一个以大语言模型为决策大脑、以「思考—行动—观察」的执行循环为心脏、以工具为手脚、以知识库为外脑、以记忆为经验的自主闭环系统。它不满足于「回答」，而是通过一轮轮的推理与行动，把模糊的目标一步步推进为确定的成果。

理解了这个闭环，你就掌握了 Agent 的「第一性原理」：无论未来框架如何更迭、模型如何升级，「LLM 决策 + 循环推进 + 工具与知识增强 + 记忆沉淀」 这套结构，仍将是智能体架构的主干。剩下的，无非是把这个闭环做得更稳、更快、更安全、更聪明而已。

而这，正是构建下一代 AI 应用最值得深耕的方向。