“很多人用 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 的统一标准。Agent Loop——心跳记忆系统——长期大脑工具系统——手脚Context Engine——调度中枢推理引擎——思考核心上下文压缩——内存管家理解这六点你才能真正理解 Agent才能设计出有用的 Agent 系统。一、Agent Loop——Agent 的心跳先从最核心的概念开始Agent Loop。1.1 什么是 Agent Loop想象一个场景你要让 AI 帮你部署一个网站。一轮 LLM 调用通常会怎么做它直接输出一堆部署步骤然后你就得自己去执行。你执行到一半遇到问题再回去问 AIAI 再给你一个答案……Agent 不一样。它会自己执行推理Reason分析任务制定计划行动Act调用工具执行操作观察Observe看执行结果判断是否成功迭代Iterate如果失败调整策略继续循环这就是Agent Loop——一个持续运行的推理-行动-观察闭环。用伪代码表示defagent_looptask,max_iterations50taskhistorystateplanningforinrange# 1. 推理分析当前状态决定下一步 # 2. 行动调用工具或生成回复 if tool_call else # 3. 观察记录结果更新状态thought result # 4. 判断任务完成了吗 if return # 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 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 不是天然知道有什么工具可用。多数工程实现会把工具注册成结构化描述让模型在推理时看到工具名、用途和参数约束# 工具注册 name execute_command description 在终端执行 shell 命令 parameters commandtype string description 要执行的命令 timeouttype integer default 30000 risk_level high # 高危操作 requires_approval True# 工具发现execute_command3.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核心逻辑defcompress_contexthistory,max_tokens10000# 1. 识别关键节点 # 工具调用、重要决策 # 2. 有损摘要 # 3. 合并 summary key_events recent_messages10 # 保留最近 10 条 return6.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 还在快速演进。几个值得关注的趋势MCP 标准化MCP 已进入 Linux Foundation 旗下 AAIF主流 Agent 生态会越来越多兼容自我进化DSPy GEPA 自动优化 Skill 和 Prompt仍在实验阶段多 Agent 协作Subagent 隔离上下文分工协作持续压缩Context Budget 管理越来越智能行动建议如果你想深入理解 Agent理解 Agent Loop这是 Agent 的核心抓住这个就抓住了本质观察 Context Budget看看不同任务消耗多少 tokens配置一个 MCP Server连接 PostgreSQL 或 GitHub体验统一接口体验记忆系统跨会话对话感受持久化的威力理解原理才能设计出真正有用的 Agent。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
AI 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 的统一标准。Agent Loop——心跳记忆系统——长期大脑工具系统——手脚Context Engine——调度中枢推理引擎——思考核心上下文压缩——内存管家理解这六点你才能真正理解 Agent才能设计出有用的 Agent 系统。一、Agent Loop——Agent 的心跳先从最核心的概念开始Agent Loop。1.1 什么是 Agent Loop想象一个场景你要让 AI 帮你部署一个网站。一轮 LLM 调用通常会怎么做它直接输出一堆部署步骤然后你就得自己去执行。你执行到一半遇到问题再回去问 AIAI 再给你一个答案……Agent 不一样。它会自己执行推理Reason分析任务制定计划行动Act调用工具执行操作观察Observe看执行结果判断是否成功迭代Iterate如果失败调整策略继续循环这就是Agent Loop——一个持续运行的推理-行动-观察闭环。用伪代码表示defagent_looptask,max_iterations50taskhistorystateplanningforinrange# 1. 推理分析当前状态决定下一步 # 2. 行动调用工具或生成回复 if tool_call else # 3. 观察记录结果更新状态thought result # 4. 判断任务完成了吗 if return # 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 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 不是天然知道有什么工具可用。多数工程实现会把工具注册成结构化描述让模型在推理时看到工具名、用途和参数约束# 工具注册 name execute_command description 在终端执行 shell 命令 parameters commandtype string description 要执行的命令 timeouttype integer default 30000 risk_level high # 高危操作 requires_approval True# 工具发现execute_command3.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核心逻辑defcompress_contexthistory,max_tokens10000# 1. 识别关键节点 # 工具调用、重要决策 # 2. 有损摘要 # 3. 合并 summary key_events recent_messages10 # 保留最近 10 条 return6.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 还在快速演进。几个值得关注的趋势MCP 标准化MCP 已进入 Linux Foundation 旗下 AAIF主流 Agent 生态会越来越多兼容自我进化DSPy GEPA 自动优化 Skill 和 Prompt仍在实验阶段多 Agent 协作Subagent 隔离上下文分工协作持续压缩Context Budget 管理越来越智能行动建议如果你想深入理解 Agent理解 Agent Loop这是 Agent 的核心抓住这个就抓住了本质观察 Context Budget看看不同任务消耗多少 tokens配置一个 MCP Server连接 PostgreSQL 或 GitHub体验统一接口体验记忆系统跨会话对话感受持久化的威力理解原理才能设计出真正有用的 Agent。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
