小白也能看懂！掌握 Agent 内部机制，收藏这份进阶指南！-平芜编程栈

本文深入解析了 Agent 的六大核心支柱：Agent Loop、记忆系统、工具系统、Context Engine、推理引擎和上下文压缩。通过底层原理讲解，帮助读者理解 Agent 的运作机制，避免只停留在“会用框架”的层面。文章穿插了 Hermes、OpenClaw 等实际案例，适合想要深入掌握 Agent 技术的小白和程序员学习。

“很多人用 Agent，但很少人理解 Agent 内部是怎么运作的。搞懂这些，你才能设计出真正有用的 Agent。”

最近我面试了很多候选人。聊到 Agent，几乎所有人都说：“我用过 LangChain、LangGraph，能搭 workflow。”

但当我问：“Agent 内部是怎么运作的？Agent Loop 是什么？Context 怎么管理？” —— 大部分人答不上来。

这让我意识到一个普遍问题：很多人用 Agent，但很少人理解 Agent 内部机制。他们把 Agent 当成"框架API调用"，而不是一个完整的系统。

所以，我决定写这篇文章。我要从底层原理讲清楚 Agent 的六大核心支柱，让你不只是"会用框架"，而是真正理解 Agent 是什么、怎么运作、为什么这样设计。

为了避免只讲抽象概念，文中会穿插 Hermes、OpenClaw 这类 Agent 的实现作为例子。需要注意：六大支柱是通用架构视角，MEMORY.md、USER.md、SOUL.md、Frozen Snapshot 等是具体实现方式，不是所有 Agent 的统一标准。

1. Agent Loop——心跳
2. 记忆系统——长期大脑
3. 工具系统——手脚
4. Context Engine——调度中枢
5. 推理引擎——思考核心
6. 上下文压缩——内存管家

理解这六点，你才能真正理解 Agent，才能设计出有用的 Agent 系统。

一、Agent Loop——Agent 的"心跳"

先从最核心的概念开始：Agent Loop。

1.1 什么是 Agent Loop？

想象一个场景：你要让 AI 帮你"部署一个网站"。

一轮 LLM 调用通常会怎么做？它直接输出一堆部署步骤，然后你就得自己去执行。你执行到一半遇到问题，再回去问 AI，AI 再给你一个答案……

Agent 不一样。它会自己执行：

1. 推理（Reason）：分析任务，制定计划
2. 行动（Act）：调用工具，执行操作
3. 观察（Observe）：看执行结果，判断是否成功
4. 迭代（Iterate）：如果失败，调整策略，继续循环

这就是 Agent Loop——一个持续运行的"推理-行动-观察"闭环。

用伪代码表示：

def agent_loop(task, max_iterations=50): context = {"task": task, "history": [], "state": "planning"} for i in range(max_iterations): # 1. 推理：分析当前状态，决定下一步 thought = model.reason(context) # 2. 行动：调用工具或生成回复 if thought.action_type == "tool_call": result = execute_tool(thought.tool_name, thought.tool_args) else: result = thought.response # 3. 观察：记录结果，更新状态 context.history.append({"thought": thought, "result": result}) # 4. 判断：任务完成了吗？ if is_task_complete(context): return final_response(context) # 5. 迭代：继续循环 return "任务超时，未能完成"

1.2 Agent Loop 的关键设计

迭代上限：防止无限循环（不同系统差异很大，常见做法是按任务类型设置 10-100 次不等）

状态管理：记录每次迭代的 thought + result

早停机制：任务完成或遇到不可恢复错误时提前退出

人机交互：高危操作需要用户确认（approval）

1.3 与普通 LLM 调用的本质差异

这里的"普通 LLM"，指的是没有工具、没有循环控制、没有状态管理的一轮模型调用。现代 ChatGPT、Claude、Gemini 等产品本身也可能内置工具能力，所以更准确的对比是：

一轮 LLM 调用	Agent 系统
输入一次，输出答案	多轮循环，持续推进
用户负责执行步骤	Agent 可调用工具执行
状态主要靠对话历史	有显式任务状态和观察结果
主要产出文本	可以操作文件、命令、浏览器、API

比喻：一轮 LLM 调用像"租来的顾问"，给你方案但不动手；Agent 像"带工具的执行者"，会边做边看结果，再调整下一步。

二、记忆系统——Agent 的"长期大脑"

Agent Loop 解决了"如何执行"的问题。但还有一个关键问题：Agent 怎么记住你的偏好、历史、上下文？

这就是记忆系统。

2.1 记忆系统的三个组件

Agent 的记忆由三个组件构成：

层级	存储	生命周期	用途
短期	Context Window	单次对话	当前任务上下文
中期	Session	会话期间	本次对话历史
长期	持久化存储	永久	跨会话记忆

下面用 Hermes 的记忆设计举例，它大致可以拆成三层：

┌────────────────────────────────────────────┐ │ 第一层：MEMORY.md + USER.md │ ← 长期记忆 │ - MEMORY.md：Agent 的笔记（2,200 chars） │ │ - USER.md：用户画像（1,375 chars） │ ├────────────────────────────────────────────┤ │ 第二层：外部 Memory Provider │ ← 可选扩展 │ - mem0、letta 等 │ ├────────────────────────────────────────────┤ │ 第三层：Session Search（SQLite FTS5） │ ← 本地兜底 │ - 所有历史对话 → 关键词搜索 + LLM 摘要 │ └────────────────────────────────────────────┘

2.2 Frozen Snapshot 模式

有个问题：如果每一轮请求都把频繁变化的记忆混在 prompt 前缀里，就很难利用 LLM 的 prefix cache；如果完全实时读取，又会增加 token 成本和上下文噪音。

Hermes 的解决方案：Frozen Snapshot。

Session 启动时，把 MEMORY.md + USER.md 注入 system prompt
Session 运行期间，记忆修改即时持久化到文件
当前 session 继续使用启动时的快照，下一个 session 才读取新版本（保证缓存友好）

2.3 检索策略

方案	优点	缺点
向量检索	语义匹配，适合模糊召回	依赖 embedding，成本和维护复杂度更高
FTS5 关键词	粒度细，速度快，容易本地化	缺少语义理解，依赖关键词命中
混合方案	兼顾召回和精度	系统复杂度更高

Hermes 更偏向本地 FTS5 + LLM 摘要；OpenClaw 这类系统通常会把本地记忆、会话搜索和更细粒度的检索能力结合起来，避免只依赖一种召回方式。

2.4 记忆管理实战

大小限制：例如 Hermes 默认MEMORY.md约 2,200 chars（避免长期记忆无限膨胀）

压缩策略：定期用 LLM 摘要，提炼精华

遗忘机制：低价值信息自动清理（flush_memories）

三、工具系统——Agent 的"手脚"

Agent Loop 解决执行循环，记忆系统解决持久化。但要真正"做事"，Agent 还需要工具。

3.1 工具注册与发现

Agent 不是天然"知道"有什么工具可用。多数工程实现会把工具注册成结构化描述，让模型在推理时看到工具名、用途和参数约束：

# 工具注册 tool_registry.register({ "name": "execute_command", "description": "在终端执行 shell 命令", "parameters": { "command": {"type": "string", "description": "要执行的命令"}, "timeout": {"type": "integer", "default": 30000} }, "risk_level": "high", # 高危操作 "requires_approval": True }) # 工具发现 available_tools = tool_registry.list_all() tool_schema = tool_registry.get_schema("execute_command")

3.2 MCP 协议：统一接口标准

有个痛点：如果每个 Agent 都要为每个工具写 custom integration，生态会很碎片化。

MCP（Model Context Protocol）解决了这个问题：

类比：MCP = AI 界的 USB-C
好处：工具可以按统一协议暴露，Agent 侧只需对接 MCP Client
架构：数据源、API、开发工具等可以封装成 MCP Server，供支持 MCP 的 Agent 调用

┌──────────────┐ ┌──────────────┐ │ Agent │ │ MCP Server │ │ (MCP Client)│◄────►│ (工具提供者) │ └──────────────┘ └──────────────┘ │ │ │ ┌───────────┴───────────┐ │ │ │ ▼ ▼ ▼ PostgreSQL GitHub Slack

3.3 工具选择策略

LLM 怎么决定调用哪个工具？

核心机制：Tool Description + 参数 Schema + LLM 推理

{ "tools": [ { "name": "execute_command", "description": "在终端执行 shell 命令。适合文件操作、系统管理、脚本执行。", "input_schema": { "type": "object", "properties": { "command": {"type": "string"} } } }, { "name": "web_search", "description": "搜索互联网获取信息。适合查询实时数据、新闻、文档。", "input_schema": { "type": "object", "properties": { "query": {"type": "string"} } } } ] }

LLM 根据任务语义 + 工具描述，选择最合适的工具。

3.4 如何设计一个好的 Tool

清晰描述：让 LLM 能理解工具用途

参数 Schema：明确输入类型和约束

风险评估：高危操作标记requires_approval

错误处理：失败时返回清晰错误信息

四、Context Engine——Agent 的"调度中枢"

工具、记忆都有了。但 Agent 怎么把所有信息组装成一个完整的 prompt？

这就是 Context Engine。

4.1 Prompt 组装流程

以 Hermes 为例，prompt_builder.py负责把多类上下文组装成完整 prompt：

┌────────────────────────────────────────────┐ │ System Prompt 组装 │ ├────────────────────────────────────────────┤ │ 1. SOUL.md — Agent 身份和风格 │ │ 2. USER.md — 用户偏好 │ │ 3. MEMORY.md — 长期记忆 │ │ 4. Skills — 按需加载的领域知识 │ │ 5. MCP Tools — 当前可用的工具声明 │ │ 6. Session History — 本次对话历史 │ │ 7. Dynamic Context — 任务相关的动态信息 │ └────────────────────────────────────────────┘

4.2 Frozen Snapshot vs 动态注入

方案	特点	适用场景
Frozen Snapshot	Session 启动时固定注入	基础上下文（SOUL/USER/MEMORY）
动态注入	每次迭代实时更新	Session History + Dynamic Context

为什么分两种？

Frozen 部分可以利用 Anthropic Prompt Caching（节省成本）
Dynamic 部分必须实时更新（否则 Agent 不知道发生了什么）

4.3 Context Budget 管理

有个现实问题：当模型支持 200K tokens 级别上下文时，应该怎么分配？

一个可参考的分配策略：

内容	预算	说明
System Prompt（Frozen）	10K	固定，可缓存
Tool Declarations	5-20K	MCP 按需加载
Session History	50-100K	动态增长
Working Memory	10K	当前任务上下文
响应输出	10K	Agent 输出空间

4.4 缓存策略

Anthropic 提供 Prompt Caching。它的核心价值是：当 prompt 前缀稳定、缓存命中时，可以减少重复处理长上下文的成本和延迟。

Frozen 部分尽量放在稳定前缀中，提高缓存命中率
官方说法是长 prompt 场景下成本最高可降低约 90%，但前提是缓存命中、前缀稳定、缓存未过期

五、推理引擎——Agent 的"思考核心"

Context 组装好了，工具就绪了。接下来是推理引擎——Agent 的"大脑"。

5.1 模型选择：不同任务用不同模型

不是所有任务都需要最强模型。很多 Agent 系统会采用 Auxiliary 模型机制：主模型负责复杂推理，辅助模型负责图片理解、网页抽取、压缩、摘要等子任务。

以 Hermes 的配置思路为例：

辅助模型	用途	示例配置
vision	图片分析	Claude Haiku
web_extract	网页抓取	轻量模型
compression	上下文压缩	便宜且长上下文友好的模型
session_search	历史搜索摘要	轻量模型
approval	危险命令审批	GPT-4o-mini

省钱原理：主模型专注复杂决策，低成本模型处理可拆分的辅助任务。

5.2 DSPy + GEPA：自我进化实验

注意：这是 Hermes 的独立项目hermes-agent-self-evolution，目前只有 Phase 1（Skill 文件优化）已实现，Phase 2-5 尚在规划中。

DSPy：把 LLM 当成可编程模块，自动优化 prompt

GEPA（Genetic-Pareto）：一种反思式 prompt 优化方法，用演化搜索和 Pareto 选择改进文本组件

核心思路：读取执行轨迹来理解为什么失败，然后针对性改进 Skill 文件。
工作流程：

读取当前 skill ──► 生成 eval 数据集 │ ▼ GEPA Optimizer │ ▼ Candidate variants ──► 评估 │ 防护措施（测试、大小限制） │ ▼ Best variant ──► PR 提交（人工审核）

成本：每次优化运行 $2-10，不需要 GPU。

现状：Phase 1 已实现（Skill 文件），Phase 2-5（Tool description、System prompt、代码、持续循环）仍在规划。

5.3 推理链策略

策略	特点	适用场景
CoT（Chain-of-Thought）	显式推理步骤	复杂逻辑问题
ReAct	推理 + 行动交替	需要调用工具的任务
Plan-and-Execute	先规划再执行	大型多步骤任务

六、上下文压缩——Agent 的"内存管家"

Context 不会无限增长，历史越长越接近 token limit。这时候需要压缩。

6.1 为什么需要压缩？

问题：

200K tokens 是上限，不是无限
Session History 会持续增长
成本随 tokens 增加（Prompt Caching 只覆盖 Frozen 部分）

后果：

超过限制 → 早期信息被截断或必须被摘要
成本上涨 → 长任务的 API 调用费用明显增加

6.2 压缩策略

策略	原理	代价
有损摘要	LLM 提炼核心信息	损失细节
关键信息提取	只保留重要节点	可能漏掉有用信息
滑动窗口	只保留最近 N 条	丢失历史
分层压缩	不同层级不同策略	复杂度高

6.3 Hermes 的 context_compressor

核心逻辑：

def compress_context(history, max_tokens=10000): # 1. 识别关键节点 key_nodes = identify_key_events(history) # 工具调用、重要决策 # 2. 有损摘要 summary = auxiliary_model.summarize(history, max_tokens) # 3. 合并 compressed = { "summary": summary, "key_events": key_nodes, "recent_messages": history[-10:] # 保留最近 10 条 } return compressed

6.4 实战建议

何时压缩：当 Session History 接近 budget 上限

压缩什么：低价值对话（闲聊）、冗余信息

保留什么：关键决策、工具调用结果、任务状态

总结：六大支柱协同运作

回顾一下 Agent 的完整架构。更准确地说，这不是一条严格的单向流水线，而是一组相互协作的模块：

┌──────────────────────────┐ │ 用户输入 │ └────────────┬─────────────┘ ▼ ┌────────────────────────────────────────────────────────┐ │ Context Engine │ │ 组装 System Prompt、用户偏好、记忆、Skills、Tools、历史 │ └──────────────────────────┬─────────────────────────────┘ ▼ ┌────────────────────────────────────────────────────────┐ │ Agent Loop │ │ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ 推理引擎 │ ──► │ 工具系统 │ ──► │ 观察结果 │ │ │ │ Reason │ │ Act │ │ Observe │ │ │ └─────▲──────┘ └────────────┘ └─────┬──────┘ │ │ │ │ │ │ └──────────── Iterate / Update ◄──────┘ │ └──────────────────────────┬─────────────────────────────┘ ▼ ┌──────────────────────────┐ │ 输出给用户 │ └──────────────────────────┘ 旁路能力： - 记忆系统：沉淀用户偏好、项目事实、历史经验 - 上下文压缩：在历史过长时摘要、提取关键节点 - Session Search / Retrieval：在需要时召回历史信息

核心洞察：

Agent Loop 是骨架——持续循环是 Agent 的本质
记忆系统是大脑——持久化让 Agent"越用越懂你"
工具系统是手脚——真正做事的能力
Context Engine 是调度——统筹所有信息
推理引擎是思考——决定策略和模型
上下文压缩是管家——管理有限资源

架构演进趋势

Agent 还在快速演进。几个值得关注的趋势：

1. MCP 标准化：MCP 已进入 Linux Foundation 旗下 AAIF，主流 Agent 生态会越来越多兼容
2. 自我进化：DSPy + GEPA 自动优化 Skill 和 Prompt（仍在实验阶段）
3. 多 Agent 协作：Subagent 隔离上下文，分工协作
4. 持续压缩：Context Budget 管理越来越智能

行动建议

如果你想深入理解 Agent：

1. 理解 Agent Loop：这是 Agent 的核心，抓住这个就抓住了本质
2. 观察 Context Budget：看看不同任务消耗多少 tokens
3. 配置一个 MCP Server：连接 PostgreSQL 或 GitHub，体验统一接口
4. 体验记忆系统：跨会话对话，感受持久化的威力

理解原理，才能设计出真正有用的 Agent。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

为什么要学习大模型？

我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。

大模型入门到实战全套学习大礼包

1、大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

2、大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

3、AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

4、大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

5、大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

适用人群

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

大模型 AI 能干什么？
大模型是怎样获得「智能」的？
用好 AI 的核心心法
大模型应用业务架构
大模型应用技术架构
代码示例：向 GPT-3.5 灌入新知识
提示工程的意义和核心思想
Prompt 典型构成
指令调优方法论
思维链和思维树
Prompt 攻击和防范
…

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

为什么要做 RAG
搭建一个简单的 ChatPDF
检索的基础概念
什么是向量表示（Embeddings）
向量数据库与向量检索
基于向量检索的 RAG
搭建 RAG 系统的扩展知识
混合检索与 RAG-Fusion 简介
向量模型本地部署
…

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

为什么要做 RAG
什么是模型
什么是模型训练
求解器 & 损失函数简介
小实验2：手写一个简单的神经网络并训练它
什么是训练/预训练/微调/轻量化微调
Transformer结构简介
轻量化微调
实验数据集的构建
…

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

硬件选型
带你了解全球大模型
使用国产大模型服务
搭建 OpenAI 代理
热身：基于阿里云 PAI 部署 Stable Diffusion
在本地计算机运行大模型
大模型的私有化部署
基于 vLLM 部署大模型
案例：如何优雅地在阿里云私有部署开源大模型
部署一套开源 LLM 项目
内容安全
互联网信息服务算法备案
…

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。