本文详细解析了 Agent 的六大核心支柱Agent Loop、记忆系统、工具系统、Context Engine、推理引擎和上下文压缩。通过底层原理的讲解和实际案例帮助读者理解 Agent 的工作原理和设计思路避免仅停留在框架API调用的表面使用从而设计出真正有用的 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 调用通常会怎么做它直接输出一堆部署步骤然后你就得自己去执行。你执行到一半遇到问题再回去问 AIAI 再给你一个答案……Agent 不一样。它会自己执行1. 推理Reason分析任务制定计划2. 行动Act调用工具执行操作3. 观察Observe看执行结果判断是否成功4. 迭代Iterate如果失败调整策略继续循环这就是 Agent Loop——一个持续运行的推理-行动-观察闭环。用伪代码表示def agent_loop(task, max_iterations50): 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早停机制任务完成或遇到不可恢复错误时提前退出人机交互高危操作需要用户确认approval1.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.mdAgent 的笔记2,200 chars │ │ - USER.md用户画像1,375 chars │ ├────────────────────────────────────────────┤ │ 第二层外部 Memory Provider │ ← 可选扩展 │ - mem0、letta 等 │ ├────────────────────────────────────────────┤ │ 第三层Session SearchSQLite FTS5 │ ← 本地兜底 │ - 所有历史对话 → 关键词搜索 LLM 摘要 │ └────────────────────────────────────────────┘2.2 Frozen Snapshot 模式有个问题如果每一轮请求都把频繁变化的记忆混在 prompt 前缀里就很难利用 LLM 的 prefix cache如果完全实时读取又会增加 token 成本和上下文噪音。Hermes 的解决方案Frozen Snapshot。Session 启动时把 MEMORY.md USER.md 注入 system promptSession 运行期间记忆修改即时持久化到文件当前 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生态会很碎片化。MCPModel Context Protocol 解决了这个问题类比MCP AI 界的 USB-C好处工具可以按统一协议暴露Agent 侧只需对接 MCP Client架构数据源、API、开发工具等可以封装成 MCP Server供支持 MCP 的 Agent 调用┌──────────────┐ ┌──────────────┐ │ Agent │ │ MCP Server │ │ (MCP Client)│◄────►│ (工具提供者) │ └──────────────┘ └──────────────┘ │ │ │ ┌───────────┴───────────┐ │ │ │ ▼ ▼ ▼ PostgreSQL GitHub Slack3.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 SnapshotSession 启动时固定注入基础上下文SOUL/USER/MEMORY动态注入每次迭代实时更新Session History Dynamic Context为什么分两种Frozen 部分可以利用 Anthropic Prompt Caching节省成本Dynamic 部分必须实时更新否则 Agent 不知道发生了什么4.3 Context Budget 管理有个现实问题当模型支持 200K tokens 级别上下文时应该怎么分配一个可参考的分配策略内容预算说明System PromptFrozen10K固定可缓存Tool Declarations5-20KMCP 按需加载Session History50-100K动态增长Working Memory10K当前任务上下文响应输出10KAgent 输出空间4.4 缓存策略Anthropic 提供 Prompt Caching。它的核心价值是当 prompt 前缀稳定、缓存命中时可以减少重复处理长上下文的成本和延迟。Frozen 部分尽量放在稳定前缀中提高缓存命中率官方说法是长 prompt 场景下成本最高可降低约 90%但前提是缓存命中、前缀稳定、缓存未过期五、推理引擎——Agent 的思考核心Context 组装好了工具就绪了。接下来是推理引擎——Agent 的大脑。5.1 模型选择不同任务用不同模型不是所有任务都需要最强模型。很多 Agent 系统会采用 Auxiliary 模型 机制主模型负责复杂推理辅助模型负责图片理解、网页抽取、压缩、摘要等子任务。以 Hermes 的配置思路为例辅助模型用途示例配置vision图片分析Claude Haikuweb_extract网页抓取轻量模型compression上下文压缩便宜且长上下文友好的模型session_search历史搜索摘要轻量模型approval危险命令审批GPT-4o-mini省钱原理主模型专注复杂决策低成本模型处理可拆分的辅助任务。5.2 DSPy GEPA自我进化实验注意这是 Hermes 的独立项目hermes-agent-self-evolution目前只有 Phase 1Skill 文件优化已实现Phase 2-5 尚在规划中。DSPy把 LLM 当成可编程模块自动优化 promptGEPAGenetic-Pareto一种反思式 prompt 优化方法用演化搜索和 Pareto 选择改进文本组件核心思路读取执行轨迹来理解为什么失败然后针对性改进 Skill 文件。工作流程读取当前 skill ──► 生成 eval 数据集 │ ▼ GEPA Optimizer │ ▼ Candidate variants ──► 评估 │ 防护措施测试、大小限制 │ ▼ Best variant ──► PR 提交人工审核成本每次优化运行 $2-10不需要 GPU。现状Phase 1 已实现Skill 文件Phase 2-5Tool description、System prompt、代码、持续循环仍在规划。5.3 推理链策略策略特点适用场景CoTChain-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_tokens10000): # 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 compressed6.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 管理越来越智能行动建议如果你想深入理解 Agent1. 理解 Agent Loop这是 Agent 的核心抓住这个就抓住了本质2. 观察 Context Budget看看不同任务消耗多少 tokens3. 配置一个 MCP Server连接 PostgreSQL 或 GitHub体验统一接口4. 体验记忆系统跨会话对话感受持久化的威力理解原理才能设计出真正有用的 Agent。最后2026 年一晃已经过半AI 大模型的热潮不仅没有降温反而持续升温金融行业用大模型做风控、医疗依靠 AI 解析影像电商、制造、教育各行各业都在把 AI 融入日常业务。曾经热闹的 “百模大战”早就告别单纯比拼模型参数正式进入落地应用时代。现在企业疯狂紧缺一类人才懂业务、懂 AI、能做出可上线项目的大模型开发工程师岗位缺口大薪资待遇十分可观。风口再好不如手握高薪 offer 实在。行情火热普通人、程序员该怎样从零入门大模型抓住这波机会今天整理好【2026 最新版】AI 大模型全套免费学习资源覆盖零基础入门、项目实战、理论知识、大厂面试从基础一路进阶。所有资料分类归档没有多余杂料无套路免费分享给想要入局 AI 赛道的程序员与零基础小白扫码免费领取全部内容1、大模型系统化完整学习路线2、大模型经典书籍文档3、AI 大模型最新行业研究报告4、企业级实战项目 完整配套源码5、大厂大模型面试真题汇总6、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】