每日 Agent 核心知识 · 第 01 期Agent 基础架构
🔥个人主页：代码不加冰（欢迎来访）
🎬作者简介：java后端学习者
❄️个人专栏：LeetCode刷题日记 ， 苍穹外卖日记，SSM框架深入，JavaWeb，
✨命运的结局尽可永在，不屈的挑战却不可须臾或缺！
前言：
大家好我是代码不加冰，agent已经火了挺长一段时间，对我自己而言，并没有开始系统的学习，也不能这么说，毕竟刚出，也没有所谓的系统，这里是我自己的整理的路线，从网上搜集的，每天给大家分享一下agent的核心知识，这一章讲的主要就是Agent基础架构：它到底是什么，骨子里长什么样
从一个 LLM API 调用，到能够自主完成多步骤任务的系统，中间发生了什么，本文从架构层拆解 Agent 的全貌。
目录
01 从 LLM 到 Agent：差在哪里
02 Agent 的精确定义
03 四大核心组件深度拆解
3.1 推理核心（Brain / LLM）
3.2 记忆系统（Memory）
3.3 工具集（Tools）
3.4 规划模块（Planning）
04 Agent 的运行循环
05 和传统 Pipeline 的本质区别
06 面试高频问题
01 从 LLM 到 Agent：差在哪里
绝大多数开发者第一次接触 AI 开发，写的是这样的代码：
# 典型的 LLM 调用 —— 无状态、单轮、无工具 response = client.chat.completions.create( model="gpt-4o", messages=[{"role": "user", "content": "帮我写一份周报"}] ) print(response.choices[0].message.content)这本质上是一个f(prompt) → text的函数。LLM 是无状态的，它不知道上一轮发生了什么，不能查数据，不能执行代码，不能发邮件。它只是一个极其强大的文本变换器。
Agent 要做的事情完全不同。给 Agent 下达"帮我整理本周所有 Jira 工单，按优先级写成周报发给团队"，它会自己去：
调用 Jira API 拉取工单按优先级排序整理生成周报文本调用邮件 API 发送确认发送成功
这中间涉及多步骤、多工具、有状态、有反馈。LLM 是大脑，但 Agent 是能自己动手的完整系统。
关键区分：LLM 是 Agent 的核心组件，但 Agent ≠ LLM。就像 CPU 是计算机的核心，但计算机不等于 CPU。
02 Agent 的精确定义
学术界和工程界对 Agent 的定义有微妙差异，搞清楚这两层才能在面试和实战中都说对。
学术定义（Russell & Norvig《AIMA》）
Agent 是一个能够感知环境（percept）并通过行动（action）影响环境的实体，目标是最大化某个性能度量（performance measure）。核心是感知-行动循环。
工程定义（LLM Agent 语境）
以 LLM 为推理核心，能够自主规划子任务、调用外部工具、读写记忆、并在多轮循环中迭代执行，直到完成用户目标的软件系统。核心是自主性 + 工具使用。
深度视角
LLM Agent 和传统 RL Agent 的本质区别在于「规划能力的来源」。RL Agent 通过奖励信号学到规划策略（隐性的）；LLM Agent 直接用语言推理做显式规划，规划过程可读可解释，这是 LLM Agent 的核心工程价值。
03 四大核心组件深度拆解
目前工程界最主流的 Agent 架构来自 Weng Lilian（OpenAI）2023 年的博文，将 Agent 拆成四个模块。这个拆法已成为事实上的标准框架。
3.1 推理核心（Brain / LLM）
Agent 的核心是 LLM，但不是简单地调用一次 API。LLM 在 Agent 里承担三件事：
# LLM 在 Agent 里扮演的三个角色 1. 规划者（Planner） 给定目标 → 拆分子任务 → 决定执行顺序 2. 推理者（Reasoner） 观察工具返回的结果 → 判断是否满足条件 → 决定下一步 3. 生成者（Generator） 最终生成结构化输出或自然语言回复1. 规划者（Planner） 给定目标 → 拆分子任务 → 决定执行顺序
2. 推理者（Reasoner） 观察工具返回的结果 → 判断是否满足条件 → 决定下一步
3. 生成者（Generator） 最终生成结构化输出或自然语言回复
这三个角色在一次 Agent 循环里可能轮流出现多次，而不是"调一次 LLM，用结果"那么简单。这是很多初学者搭 Agent 时忽视的地方，导致写出来的"Agent"其实只用了 LLM 的生成能力，没有推理能力。
陷阱：把复杂任务一股脑扔给 LLM 生成，不做任何规划分解。这不是 Agent，这是一个复杂 prompt 的 LLM 调用。Agent 的核心价值在于「迭代推理」，而不是「一次生成」。
3.2 记忆系统（Memory）
LLM 本身无状态，Agent 的「记忆」是通过外部存储注入 context 实现的。记忆分四类，面试经常考：
class AgentMemory:
1. 感知缓冲区 —— 当前 context window 里的内容 in_context: list[Message] ，最新 N 轮对话、工具调用结果
2. 外部长期记忆 —— 向量数据库 vector_store: VectorDB 语义搜索，召回相关历史记录
3. 程序性记忆 —— 固化在 System Prompt 里的规则/SOP system_prompt: str 角色设定、工具描述、约束条件
4. 实体记忆 —— 结构化的知识（KV/图数据库） entity_store: dict 用户偏好、项目信息等结构化数据
工程关键点
Context window 是 Agent 真正的「工作内存」，所有推理都在这里发生。外部记忆的核心工程挑战是「检索质量」——怎么在正确的时机检索到正确的内容注入 context。RAG 准确率低，是目前 Agent 在生产环境最大的单点故障之一。
3.3 工具集（Tools）
工具是 Agent 的「手脚」，让 LLM 能够与外部世界交互。工具本质上是一个函数签名 + 描述，LLM 根据描述决定何时调用、传什么参数。
| 字段 | 类型 | 说明 |
|---|---|---|
| type | String | 固定为function |
| function.name | String | 函数名称 |
| function.description | String | 函数描述 |
| function.parameters | Object | 参数 Schema |
| properties | Object | 参数列表 |
| required | Array | 必填参数 |
| tool_calls | Array | 模型返回的工具调用 |
| arguments | JSON String | 调用参数 |
| tool_call_id | String | 调用唯一标识 |
工具类型按能力分层，理解这个分层对设计 Agent 系统很有帮助：
读取类工具（只读）
搜索引擎、数据库查询、API 读取、文件读取。风险低，可以大量使用，失败了重试即可。
写入类工具（有副作用）
发邮件、数据库写入、代码执行、API 写操作。有不可逆风险，需要 human-in-the-loop 确认或沙箱隔离。
生产陷阱：不区分工具的副作用级别，让 Agent 无限制地调用写入类工具。一个错误规划会导致真实数据被修改、邮件被误发。生产 Agent 系统必须对写入类工具做权限控制和确认机制。
3.4 规划模块（Planning）
规划是 Agent 和普通 LLM 调用最核心的差别。规划分两个维度：
维度一：任务分解策略
方式 A：顺序分解（Sequential） Task → [Step1, Step2, Step3] 串行，简单，适合强依赖链
方式 B：层级分解（Hierarchical） Task → [SubTask1, SubTask2] ↓ ↓ [S1.1, S1.2] [S2.1, S2.2] # 树状，适合复杂任务
方式 C：并行分解（Parallel） ← 多 Agent 系统的基础 Task → [SubTask1 ‖ SubTask2 ‖ SubTask3] 并发，提速但需协调
维度二：规划时机 静态规划：执行前一次性规划完（CoT/ToT） 动态规划：每步执行后根据结果重新规划（ReAct）← 更常用
深度视角
静态规划依赖 LLM 对任务的「全局预见能力」，在复杂、不确定场景下经常规划失败。动态规划（ReAct 模式）每步观察工具返回值再决定下一步，代价是多轮 LLM 调用，latency 和 cost 更高。这是工程设计里的核心 tradeoff，下一期专门讲 ReAct。
04 Agent 的运行循环
把四个组件组合起来，Agent 的运行本质是一个循环：
def agent_loop(goal: str) -> str: memory.add_to_context(f"目标: {goal}") while True:
| 阶段 | Agent 行为 | 示例 |
|---|
| 1. 接收任务（Observe） | 接收用户目标并理解需求 | 「帮我规划北京三日游」 |
| 2. 思考分析（Think） | 拆解任务，制定执行计划 | 需要查询景点、天气、酒店 |
| 3. 选择工具（Plan） | 判断是否需要调用外部工具 | 调用搜索、地图、酒店 API |
| 4. 执行工具（Act） | 调用 Function Calling 执行任务 | 查询热门景点和酒店 |
| 5. 获取结果（Observe） | 接收工具返回的数据 | 获得景点、天气、价格信息 |
| 6. 结果评估（Reflect） | 判断信息是否足够完成任务 | 酒店信息不足，继续搜索 |
| 7. 再次行动（Act） | 继续调用工具补充信息 | 查询酒店评价和交通情况 |
| 8. 生成答案（Respond） | 整合结果输出最终方案 | 生成完整旅游攻略 |
| 9. 任务结束（Finish） | 满足目标后退出循环 | 返回最终结果 |
这个循环没有固定终止条件，理论上可以无限运行。实际工程里必须加：最大迭代次数（防止死循环）、超时限制、异常捕获和降级策略。
05 和传统 Pipeline 的本质区别
传统 DAG Pipeline
固定的节点拓扑，数据流向在代码里写死。A→B→C，步骤数量和顺序不变。适合结构高度稳定的任务，可靠性高，但无法处理「运行时才知道需要哪些步骤」的场景。
LLM Agent
运行时动态决定步骤数量、顺序、工具选择。适合开放式、不确定性高的任务，灵活性高，但引入了「LLM 规划失误」的不确定性。可靠性需要通过评估体系保障。
实际工程里，两者不是对立的——复杂 Agent 系统内部往往混用：确定性强的子任务用 Pipeline 固定，不确定性高的子任务用 Agent 动态处理。
06 面试高频问题
Q：Agent 和 RAG 有什么区别
RAG 是 Agent 记忆系统的一种实现方式（外部长期记忆的检索增强）。Agent 包含 RAG，但 Agent 还有规划、工具调用、循环执行等能力，RAG 只解决「知识注入」问题。
Q：Agent 的上下文窗口满了怎么办？
三种策略：① 滑动窗口截断（丢弃最早的 messages）；② 摘要压缩（用 LLM 把历史对话压缩成摘要再插入）；③ 外部化存储（把工具调用结果存到外部 DB，只在 context 里保留 summary）。三种策略各有信息损失，是生产 Agent 的重要工程点。
Q：怎么评估一个 Agent 的质量
不能只看最终输出，需要分层评估：① 工具调用准确率（对的工具、对的参数）；② 规划合理性（是否走了弯路）；③ 任务完成率（最终目标达成比例）；④ Token 效率（完成同等任务消耗的 token 数）。生产 Agent 系统必须有 trace 和 eval pipeline，盲飞不可接受。
Q：单 Agent 和多 Agent 怎么选
单 Agent 适合任务链清晰、工具数量可控（<10个）的场景；多 Agent 适合任务可以并行、子任务需要专门角色（如「搜索 Agent」+「写作 Agent」）的场景。多 Agent 引入协调复杂性，不要过早引入——先让单 Agent 跑通，再拆。
结语
下一篇，我们分享一下ReAct框架的深度拆解，希望对大家有帮助！