过去一年Agent智能体突然火了起来。Claude Code、Codex、OpenCode、OpenClaw、Hermes Agent 这些项目陆续出现大家开始把大模型从“聊天窗口”推进到真实的开发、搜索、文件操作、自动化和长期任务里。但对技术人员来说只是凭感觉使用产品是不够的我们需要了解它的底层实现才能用得更好。Agent 设计的好坏往往直接决定了复杂任务的完成度同样的模型放在不同 Agent 系统里表现差异可能会非常大。一个 Agent 到底是怎么跑起来的它如何拆任务、调工具、保存记忆、压缩上下文想真正理解这些问题最好的办法还是自己手搓一个 Agent。自己实现一个 Agent至少有三层价值。第一是深度理解 Agent 的工作原理不再停留在“模型好像会自己干活”的直觉层面第二是满足特定领域的定制化需求比如内部系统、私有数据、本地软件、行业流程这些往往不是通用产品开箱就能覆盖的第三是培养系统设计能力因为一个可用的 Agent 牵涉模型、工具、记忆、上下文、权限、安全和失败恢复它本质上是一个小型软件系统。这篇文章选了一条比较适合动手学习的路线Hello-Agents - GenericAgent - Hermes Agent。 这三个项目在Github上分别有 58k、12k和193k stars都是目前比较受欢迎的项目。它们都由 Python 实现代码相对直接部署和调试门槛不高。先用 Hello-Agents 理解 Agent Loop、ReAct、Plan-and-Solve、Reflection再看 GenericAgent 如何用极少的原子工具和分层记忆做自进化最后对比 Hermes Agent 这种更平台化、产品化的长期运行 Agent。按这个路径走一遍对 Agent 的理解会扎实很多。学习路径从教程到真实 AgentAgent 最小内核Agent Loop一个最简单的 Agent Loop 可以写成这样pythonwhile not done:response llm(messages, toolstools) if response.tool\_calls: result run\_tool(response.tool\_calls) messages.append({role: tool, content: result}) else: done True answer response.content这段循环里有三个关键点第一LLM 不只是回答问题而是可以决定下一步要不要调用工具。第二工具执行结果会重新进入上下文成为下一轮推理的依据。第三Agent 的智能不只来自模型本身还来自“循环”带来的反馈。Hello-Agents 第四章从 ReAct 讲起本质就是让模型在“思考 - 行动 - 观察”的轨迹里运行。模型先思考再行动工具返回观察结果模型再基于观察结果继续思考。这个结构非常适合搜索、查询、API 调用、网页操作这类需要外部信息的任务。Agent Loop让模型在反馈中继续行动三种经典 Agent 范式三种经典 Agent 范式ReAct边想边做ReAct 的核心是“推理和行动交替进行”。它适合探索性任务比如帮我查一下某个产品的最新价格并总结优缺点。这类任务一开始并不知道答案需要搜索、读取、比较、再判断。ReAct 的优势是灵活缺点是容易绕圈所以工程上必须加最大轮数、工具错误处理、终止条件。一个极简 ReAct 实现可以写成这样pythondef react_agent(question, tools, max_steps5):messages [{role: user, content: question}] for \_ in range(max\_steps): response llm(messages, toolstools) if not response.tool\_calls: return response.content messages.append({ role: assistant, content: response.content, tool\_calls: response.tool\_calls, }) for call in response.tool\_calls: result run\_tool(call.name, call.arguments) messages.append({ role: tool, tool\_call\_id: call.id, content: str(result), }) return 达到最大步数任务未完成这段代码的关键不是 for 循环本身而是每次工具调用后都把“观察”放回上下文。模型下一轮看到新观察再决定继续搜索、换工具还是输出最终答案。Plan-and-Solve先规划再执行Plan-and-Solve 更像“三思而后行”。模型先把任务拆成计划然后按步骤执行text理解目标拆分子任务逐步执行汇总答案它适合路径比较明确的任务比如数学推理、报告生成、流程化分析。优点是结构稳定缺点是如果初始计划错了后续会一路错下去。所以更强的实现通常会加入“动态重规划”。一个简化版实现如下pythonimport jsondef plan_and_solve_agent(task, tools):plan\_prompt f请把任务拆成可执行步骤输出 JSON 数组。每个元素包含 id 和 task 两个字段。任务{task}“”plan\_text llm([{role: user, content: plan\_prompt}]).content steps json.loads(plan\_text) results [] for step in steps: solve\_prompt f原始任务{task}整体计划{json.dumps(steps, ensure_asciiFalse, indent2)}已有结果{json.dumps(results, ensure_asciiFalse, indent2)}现在执行这一步{json.dumps(step, ensure_asciiFalse)}“”messages [{role: user, content: solve\_prompt}] response llm(messages, toolstools) if response.tool\_calls: messages.append({ role: assistant, content: response.content, tool\_calls: response.tool\_calls, }) for call in response.tool\_calls: tool\_result run\_tool(call.name, call.arguments) messages.append({ role: tool, tool\_call\_id: call.id, content: str(tool\_result), }) response llm(messages) step\_result response.content results.append({ step: step, result: step\_result, }) final\_prompt f请根据以下执行过程给出最终答案{json.dumps(results, ensure_asciiFalse, indent2)}“”return llm([{role: user, content: final\_prompt}]).contentPlan-and-Solve 的重点是把“规划”和“执行”拆开。规划阶段让模型先获得全局视角执行阶段再逐步推进。这里让计划输出 JSON是为了避免 parse_steps() 依赖自然语言格式工具调用后再把工具结果回灌给模型是为了让模型基于“观察”形成这一步的结论。真实工程里还可以在每一步后检查计划是否需要调整。Reflection执行后自我反思Reflection 给 Agent 加了一个自我修正回路text执行 - 反思 - 优化例如让 Agent 写代码第一版可能能跑但效率低反思阶段可以让模型扮演代码评审者指出复杂度、边界条件、可读性问题优化阶段再生成新版。Hello-Agents 也强调Reflection 往往要配合短期记忆因为它需要保存每轮执行和反馈轨迹。一个极简 Reflection 实现如下pythondef reflection_agent(task, max_rounds3):answer llm([ {role: user, content: f请完成任务{task}} ]).content for \_ in range(max\_rounds): critique llm([ {role: system, content: 你是严格的评审者只检查答案是否满足任务。}, {role: user, content: f请评审下面的答案。如果已经足够好只输出无需修改否则输出具体问题和修改建议。任务{task}答案{answer}“”}]).content if 无需修改 in critique: break answer llm([ {role: system, content: 你是谨慎的修改者只根据评审意见改进答案。}, {role: user, content: f请根据评审意见改进答案。必须保留原任务要求不要引入无关内容。任务{task}原答案{answer}评审意见{critique}“”}]).content return answerReflection 的关键是把模型分成两个角色一个负责生成一个负责评审和改进。这里让评审者可以输出“无需修改”是为了避免无意义的循环改写修改提示里强调“保留原任务要求”是为了减少答案越改越偏。它适合写作、代码生成、方案设计等需要打磨质量的任务但会增加调用成本和延迟。这三种范式不是互斥关系。真实 Agent 往往会组合使用先 Plan-and-Solve 拆解任务再用 ReAct 执行每个子任务最后用 Reflection 检查质量并沉淀经验。工具调用Agent 的手和脚没有工具的 Agent只是一个会聊天的模型。有工具之后它才开始能“做事”。最基础的工具系统包括三层textTool Schema告诉模型有哪些工具、参数是什么Tool Router把模型输出的工具调用分发到对应函数Tool Result把执行结果返回给模型Hello-Agents 在第七章里把工具调用做成框架能力还提出“万物皆为工具”搜索是工具记忆是工具终端是工具RAG 也可以是工具。一个最小工具路由器大概长这样pythondef run_tool(name, arguments):if name search: return search\_web(arguments[query]) if name calculator: return eval\_math(arguments[expression]) if name read\_file: return read\_file(arguments[path]) raise ValueError(f未知工具{name})这里的关键不是工具越多越好而是工具边界要清楚。一个好工具应该满足·名字清晰模型一看知道什么时候用·参数结构稳定最好能被 function calling schema 描述·返回结果简洁不把无关信息塞回上下文·失败时有明确错误信息方便模型修正记忆让 Agent 不再每轮重开人生LLM API 本身是无状态的。你不把历史传进去它就不知道之前发生了什么。Agent 要长期可用必须有记忆。Hello-Agents把记忆拆成几类·工作记忆当前任务上下文生命周期短·情景记忆过去发生过的交互和经验·语义记忆长期稳定的知识、偏好、规则·感知记忆图像、音频等多模态信息一个简单实现可以先从两层开始pythonclass Memory:def \_\_init\_\_(self): self.working {} self.long\_term [] def update\_working(self, key, value): self.working[key] value def remember(self, text): self.long\_term.append(text) def build\_context(self): return { working\_memory: self.working, long\_term\_memory: self.long\_term[-5:], }更进一步记忆不是“越多越好”。真正困难的是什么时候写入写到哪里下次什么时候召回错误记忆会长期污染 Agent所以记忆系统必须谨慎。上下文工程把正确的信息放进有限窗口很多人以为上下文工程就是写 prompt。其实它更像一个运行时信息管理系统。Hello-Agents提到的 GSSC 思路很实用textGather收集候选信息Select选择当前最相关的信息Structure组织成模型容易理解的结构Compress压缩冗余内容Agent Loop 跑久以后历史、工具结果、文件内容、用户偏好都会膨胀。如果直接全塞给模型首先会挤占有限的上下文窗口。大语言模型再长的上下文也不是无限的一旦无关内容占满窗口真正关键的任务约束、工具结果、代码片段反而可能被截掉。更麻烦的是就算还没达到最大上下文长度过多的无关信息也会稀释模型注意力。模型需要在一堆噪音里找重点越找越容易偏。最后表现出来就是该遵守的约束漏掉了该引用的工具结果没用上甚至开始根据上下文里的碎片信息编造一个看似合理但实际错误的答案。所以上下文工程不是简单地“塞更多资料”而是每次模型调用前拼出最有用、最少干扰的那一小包信息。这也是很多 Agent 从 Demo 走向真实可用时绕不开的分水岭。上下文工程与 GenericAgent 压缩GenericAgent极简种子如何长成自进化 Agent理解完上面的基础再看 GenericAgent 会很有意思。GenericAgent 的 README 把自己定位为“极简、自进化的自主 Agent 框架”核心约 3K 行代码9 个原子工具一个约百行的 Agent Loop。它的设计哲学很鲜明不预设技能靠进化获得能力。GenericAgent 的能力不是靠一开始内置大量专用插件而是靠少量原子工具获得系统级控制能力textcode_run执行代码file_read / file_write / file_patch读写修改文件web_scan / web_execute_js观察和控制网页ask_user必要时请求人类确认update_working_checkpoint短期工作记忆start_long_term_update长期记忆沉淀这里容易有个误解工具少并不等于能力弱。GenericAgent 的厉害之处恰恰在于它把工具设计得很原子然后让模型自己组合。code_run 可以写脚本、装依赖、调用系统命令文件工具可以读代码、改配置、沉淀 SOP浏览器工具可以观察页面、执行 JS、保留真实登录态。几个工具组合起来就能做网页自动化、数据抓取、文件整理、代码修改、定时任务、桌面流程自动化这类高级任务。尤其是浏览器控制和电脑控制这一块GenericAgent 的执行力很强。它不是只在一个沙盒网页里点点按钮而是尽量接管真实环境浏览器、终端、文件系统甚至可以继续扩展到键鼠、屏幕视觉和移动设备。对个人自动化来说这种“能碰到真实电脑”的能力比预置一堆漂亮但封闭的插件更有想象空间。它的核心架构可以概括为text分层记忆 × 最小工具集 × 自主执行循环记忆层也很有意思textL0元规则L1记忆索引L2全局事实L3任务 Skills / SOPsL4会话归档也就是说GenericAgent 不是只把聊天记录塞进数据库而是把经验分层管理。高频规则、稳定事实、任务 SOP、历史会话各自有位置。除了记忆分层GenericAgent 还专门做了上下文预算管理。它的思路不是一味追求更大的上下文窗口而是把每一轮的信息密度做高宁可让模型看到少一点、但更关键的信息也不要把低价值历史全塞进去。GenericAgent把这套机制总结成四阶段压缩流水线textStage 1工具级截断先控制每次工具返回值的大小Stage 2Tag 级压缩把旧轮次里的 thinking、tool_use、tool_result 等标签压短Stage 3消息驱逐超预算时先激进压缩再按时间移除最早的消息Stage 4工作记忆锚点用最近轮次摘要、轮次号和 key_info 保留任务状态这里最值得注意的是 Stage 4。早期消息被驱逐以后模型并不是完全“失忆”而是依靠工作记忆锚点继续知道当前目标、关键发现和约束条件。也就是说GenericAgent 不是把所有历史都留下而是把真正影响下一步行动的信息留下。它还在信息进入上下文之前就做过滤。比如网页工具 web_scan 不会把完整 HTML 原样塞给模型而是先做 DOM 级选择性提取尽量移除脚本、样式、隐藏元素、广告和无关导航只保留对当前决策更有价值的页面内容。工具 Schema 也会在合适场景下做省略优化避免每一轮重复发送完整工具定义。这套机制和前面讲的上下文工程是一脉相承的Agent 不是靠“记住一切”变强而是靠主动管理信息预算让模型每一轮都看到高密度、低噪音的上下文。它的自进化路径大概是text新任务- 自主探索- 安装依赖 / 写脚本 / 调试 / 验证- 把成功路径固化成 Skill 或 SOP- 下次遇到类似任务直接召回这就把 Reflection、记忆、上下文工程串起来了执行过程中积累轨迹任务结束后压缩成经验下次通过记忆索引召回进入新的上下文。GenericAgent 的 agent_loop.py 里可以看到一个很直接的 Agent Loop模型输出工具调用框架把工具调用 dispatch 到 handler工具结果和下一轮提示再回到模型。它没有把复杂性藏进庞大的调度框架而是把核心控制流暴露得很清楚。GenericAgent 和 Hermes Agent 有什么不同Hermes Agent 也强调 self-improving。官方介绍为 built-in learning loop从经验创建 skills在使用中改进 skills持久化知识搜索过去对话并跨 session 建立用户模型。两者相似点很明显·都重视长期记忆·都强调 skill / procedure 的沉淀·都不是一次性聊天机器人而是面向长期使用·都希望 Agent 能从过往任务中变强但它们的气质不同。GenericAgent 更像“极简种子”。它用很少的工具让模型自己探索环境、写脚本、沉淀 SOP。它适合个人电脑、本地浏览器、文件系统、真实 GUI 操作这类场景。它追求的是给模型一个足够底层的控制面让能力自己长出来。Hermes Agent 更像“Agent OS / 平台化产品”。它支持 CLI、Telegram、Discord、飞书、钉钉、微信 等多入口有定时任务能生成 subagents 并行处理任务支持本地、Docker、SSH、Singularity、Modal、Daytona 等终端后端还有更丰富的工具系统、MCP、Skills Hub、持久记忆和用户画像。它的记忆实现也更偏产品化。Hermes 默认会把会话历史保存在本地 SQLite 里并提供 session_search让 Agent 可以按需搜索过去会话而不是把所有历史一次性塞进当前上下文。除此之外它还会在工作目录里维护可编辑的上下文文件比如 MEMORY.md 用来记录项目知识、长期偏好和操作经验USER.md 用来保存用户画像和个人偏好也支持接入外部记忆系统把长期记忆从本地文件扩展到更独立的后端。简单说Hermes 的记忆不是单一数据库而是一组“本地 SQLite 会话库 可读写上下文文件 历史会话检索 外部记忆后端”的组合。简单说textGenericAgentseed-first少量原子工具 自我演化Hermes Agentplatform-first完整运行时 跨平台长期服务GenericAgent vs Hermes Agent如果你要自己写一个 Agent建议路线第一步不要急着接框架。先写一个最小 Agent Loop。第二步加工具调用。先支持 2 到 3 个工具比如搜索、计算器、文件读取。第三步实现 ReAct。让模型学会在“思考、行动、观察”之间循环。第四步加 Plan-and-Solve。让复杂任务先生成计划再执行。第五步加 Reflection。对高价值任务做自我评审和优化。第六步加记忆。先做工作记忆和长期偏好再考虑向量检索、会话归档、Skill 沉淀。第七步做上下文工程。不要把所有历史都塞给模型而是学会选择、组织和压缩。第八步学习 GenericAgent 或 Hermes Agent。前者帮你理解极简自进化后者帮你理解平台化 Agent 工程。真正的 Agent不是一个 prompt也不是一个模型 API 封装。它是一套闭环系统text理解目标- 构造上下文- 调用模型- 选择工具- 执行动作- 观察反馈- 更新记忆- 继续循环当这个循环能稳定运行、能从失败中恢复、能把经验沉淀为下一次的捷径时一个“自己的 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%免费】