Hermes 给我的最大启发:上下文不是仓库,是工作台 ✍ 泊舟🕐 2026-04-28📦 18.8 KB 🟢 已读 𝕏 文章列表 本文指出 Agent 表现不佳往往是因为上下文管理不当,而非模型能力不足。文章引用多项研究证明长上下文不等于高效,并提出应像管理“工作台”而非“仓库”一样管理上下文。作者结合 Hermes 的实践,介绍了外部化记忆、子任务隔离、技能沉淀等策略,并重点推荐使用 XCrawl 等工具清洗网页噪声,以实现低噪、高效的 AI Agent 工作流。 上下文工程AI AgentHermes模型优化网页清洗AI搜索LLMRAG工具与效率泊舟 # Hermes 给我的最大启发:上下文不是仓库,是工作台 **作者**: 泊舟 **日期**: 2026-04-28T07:04:22.000Z **来源**: [https://x.com/bozhou_ai/status/2049021892208521544](https://x.com/bozhou_ai/status/2049021892208521544) ---  你平时用 AI 聊天,大概率遇到过这种情况。 刚开始问得很顺。你让它改一段话、解释一个概念、整理一份资料,它都能接住。 但聊着聊着,它开始不对劲。 前面明明说过的要求,它忘了。你刚刚纠正过的点,它又犯了。材料一多,它开始重复、绕圈、自己发散。 这时候很多人的第一反应是:模型不行,换一个更强的。 其实不完全是。 更常见的问题是:上下文脏了。 Agent 不是吃进去的信息越多越强。很多时候,它变笨,是脑子里塞了太多不该看的东西。 这个问题在普通聊天里已经很明显,到了 Hermes 这种能查网页、调工具、跑长任务的 Agent 里,会被放大很多倍。 所以我觉得,真要把 Agent 用好,得学一下 Hermes 背后的上下文工程做法。 Manus 和 Anthropic 之前一直讲的:Context Engineering,上下文工程。 > 这篇文章只讲一件事:Agent 变笨,很多时候不是模型不够强,而是上下文没有被管理。 ## 一、Agent 的问题,很多时候是上下文问题 Hermes 这类 Agent 好用,是因为它不只是聊天。 它能拆任务,能调工具,能查网页,能读文件,能写代码。大模型从会回答问题,变成了能执行任务。 但是执行系统有一个很现实的问题:它每做一步,都会产生新的上下文。 用户最开始的需求、系统提示词、历史对话、工具调用结果、网页内容、文件内容、报错日志、中间总结,都会慢慢堆进来。 这些东西如果不管,模型最后看到的会是一整张乱糟糟的桌子。  我自己踩坑最多的是三类情况。 第一,输出变长。Agent 开始解释一堆不必要的背景,像是在证明自己很努力。 第二,目标变虚。任务做着做着,原来的约束被新信息冲淡了。 第三,工具污染。网页、JSON、日志、报错原样进上下文,模型还没开始思考,注意力已经被垃圾内容吃掉了。 这不是玄学。 上下文就是模型当前能看到的全部信息。模型每次生成,都要在这些信息里判断什么重要、什么不重要。 所以 Context 不是资料库。 Context 更像工作台。 资料库可以很大,什么都能放。工作台不行。工作台上只应该放你当前要用的工具、材料和图纸。 如果把仓库里的东西全搬到工作台上,工人不会更强,只会更乱。 ## 二、长上下文不是免费的 过去一年,很多模型都在拼上下文窗口。 128K、200K、1M,看起来很爽。好像只要窗口够大,我们就可以把所有资料都塞进去,让模型自己看。 但实际没这么简单。 TACL 2024 的 Lost in the Middle 做过一个很有名的测试:相关信息放在长上下文的开头或结尾时,模型表现更好;放在中间时,表现会明显下降。哪怕是明确支持长上下文的模型,也会遇到这个问题。 这说明模型不是均匀阅读上下文的。 NoLiMa 这个 ICML 2025 接收的工作又往前推了一步。它去掉问题和答案之间的字面匹配,让模型必须做语义关联检索。结果很直接:13 个号称至少支持 128K 上下文的模型,短上下文表现很好,但到 32K 时,11 个模型跌到短上下文强基线的 50% 以下。GPT-4o 也从 99.3% 掉到 69.7%。 还有一篇 EMNLP Findings 2025 的论文,标题更直白:Context Length Alone Hurts LLM Performance Despite Perfect Retrieval。 它控制了检索因素。也就是说,就算模型已经能完美拿到相关信息,只要输入长度增加,数学、问答、代码任务上的表现仍然会下降 13.9% 到 85%。 所以我现在更愿意相信一个朴素判断:少塞 token,本身就是优化。 上下文窗口大,只代表你能塞更多东西进去,不代表模型真的能稳定用好这些东西。 Agent 想稳定,不能只靠更大的窗口。它需要上下文工程。 ## 三、Hermes 真正值得看的,是它怎么管理上下文 Hermes 火,不只是因为它能调工具。 更值得看的地方,是它开始把上下文当成工程问题处理。 从公开资料和我这次整理的材料看,Hermes 的思路大概有几层。 当前任务只保留必要信息。 Agent 每一步不应该都背着完整历史走。当前要做什么、有哪些约束、刚才得到什么关键结果,这些才是该放在工作台上的东西。 长期记忆外部化。 大量历史经验、项目资料、配置、长期偏好,不应该常驻上下文。更好的方式是放到 memory、文件、技能或数据库里,需要时再取。 这点和 Claude Code、很多开发 Agent 的做法很像:上下文里只放路径、摘要和当前片段。大文件、日志、中间结果留在文件系统里。 重复经验沉淀成 skill。 Hermes 这类系统很有意思的一点,是会把重复出现的任务模式沉淀成技能。 这比记住一大段历史更靠谱。 历史对话是杂乱的,skill 是压缩后的经验。下次遇到同类任务,Agent 不需要重新读一堆旧记录,直接调用整理好的做法。 子任务隔离上下文。 复杂任务最好不要全塞进一个窗口。 Research、代码分析、资料整理、验证,可以拆成不同子任务。每个子任务在自己的干净上下文里做事,最后只把结论压缩回主任务。 好处很明显:污染被隔离了。 坏处也很明显:成本会上去,协调也更复杂。所以它适合宽度优先的复杂 research,不适合所有任务。 还有一个很容易被忽略的点:工具结果不能原样灌进对话。 很多 Agent 的上下文失控,问题常常出在工具返回太脏。 网页抓下来一整页 HTML,日志返回几千行,API 返回一大坨 JSON。模型还没开始做判断,先被迫当了一遍清洁工。 所以 Hermes 给我的启发不是让 Agent 记住更多。 恰恰相反。 > 好 Agent 应该让信息在该出现的时候出现,不该出现的时候别出现。  ## 四、其他上下文方案:工具箱,不是银弹 上下文工程不是单一技术。 不同入口脏法不一样,治理方式也不一样。 Rolling Summary 适合长对话。 它的做法很直接:旧消息太多了,就压成摘要,然后保留摘要和最近消息。LangMem 的 SummarizationNode 是这种思路,Anthropic 也把 compaction 当成生产 Agent 的常用方案。 但是 summary 不是魔法。 摘要一定会损失细节。关键事实、具体文件、未解决 bug,最好用结构化字段或外部文件补强。 RAG / 向量库适合大规模知识库。 把知识放在上下文外,用时检索少量材料进来。它的优势是成本低,知识可以更新,也更适合企业文档、产品知识库、历史资料。 但 RAG 不能被神化。 EMNLP Industry 2024 有一篇 RAG 和 Long Context 的对比研究,结论很克制:资源充足时,Long Context 平均表现持续优于 RAG;RAG 的核心优势是成本更低。 所以更稳的判断是:RAG 适合低成本按需检索,长上下文适合需要完整材料的任务。很多时候,混合路由更靠谱。 外部文件系统适合开发 Agent。 代码、日志、大文档、中间结果,都可以放在文件里。上下文里只留路径、摘要和当前必要片段。 Anthropic 在 MCP code execution 那篇文章里给过一个很典型的例子:把工具暴露成文件树和代码 API 后,Agent 只读取当前任务需要的工具定义,token 使用从 150,000 降到 2,000,节省 98.7%。 这个思路很朴素,但非常有效。 别把所有工具说明一次性塞给模型。让它像开发者一样,用到哪个工具,再读哪个工具。 多 Agent 隔离适合复杂 research。 Anthropic 的多 Agent research system 是一个公开案例。lead agent 负责拆任务,subagent 各自探索不同方向,再把结果压缩回来。 他们内部 eval 里,多 Agent 系统比单 Agent 高 90.2%。 但这个数字不能乱用。 同一篇文章也说,多 Agent 系统大约比普通 chat 多用 15 倍 token。它适合高价值、可并行、信息量超过单窗口的复杂研究任务。对很多 coding task,依赖更强,并行空间没那么大。 AI 搜索 / 网页抽取适合治理网页入口。 网页是 Agent 最常见的信息来源,也是最脏的上下文入口。 网页里有正文,也有导航、广告、脚本、评论、推荐阅读、版权声明。你直接把网页塞进上下文,本质上是在让模型自己清垃圾。 所以 AI 搜索的价值,不是多搜一点。 它真正的价值是先渲染、过滤、抽取、结构化,再把低噪声材料交给 Agent。 这几个方案可以这么记: - 对话太长,用 summary。 - 知识库太大,用 RAG。 - 文件太多,用文件系统和按需读取。 - 任务太宽,用多 Agent 隔离。 - 网页太脏,用 AI 搜索/抽取先清洗。  ## 五、网页,是最容易污染 Agent 的上下文入口 为什么我会把 AI 搜索单独拎出来讲? 因为 Agent 做 research 的时候,最常见的动作就是查网页。 竞品分析要查网页,版本追踪要查网页,技术调研要查网页,找用户评价也要查网页。 问题是,大多数网页都不是给 LLM 看的。 它们是给浏览器和人看的。 人打开网页,会自动忽略导航栏、广告、页脚和推荐内容。模型不会。你喂什么,它就看什么。 为了把这件事说清楚,我做了一个对照实验。 任务很简单:用 Hermes Agent 追踪它自身的版本更新,从两个页面(腾讯云开发者文章 + 知乎专栏)提炼 3 个核心更新点。 任务完全相同,Agent 相同,模型相同。 唯一变量是网页获取方式。 1. curl 原始 HTML:整页 HTML 直接扔给 Agent。 2. 浏览器快照:提取页面可见文本,过滤掉 HTML 标签。 3. AI 搜索/抽取:用专门的 AI 搜索工具做结构化抽取,只把干净内容给 Agent。 结果差距很大。 任务:追踪 Hermes 的版本更新,从两个页面提炼 3 个核心更新点 计量口径:counted_context_tokens,也就是实际送进 Agent 上下文的网页材料 token 数。不含系统提示、任务包装、输出这些固定开销。  三种方案都完成了任务。 但是成本完全不是一个量级。  AI 搜索方案的上下文规模,只有 raw HTML 的 1/16,是浏览器快照的 1/2。 这个差距不是省一点钱的问题。 它直接影响 Agent 的工作状态。 上下文越短、越干净,模型越容易把注意力放在真正重要的信息上。反过来,网页噪声越多,模型越容易被无关内容带偏。 ## 六、AI 搜索做的不是搜索,是上下文清洗 AI 搜索/抽取方案的本质,是把上下文工程落到了网页入口。 它先决定 Agent 该看什么。 Agent 拿到的应该是结构化、去噪后的信息,而不是原始 HTML 或乱七八糟的可见文本。导航栏、广告、脚本、页脚、推荐阅读,这些东西不该进上下文。 然后决定什么时候看。 任务一开始就塞所有网页,通常会把上下文搞脏。更好的做法是,需要某个问题的答案时,再触发搜索或抽取。 这就是 just-in-time context。 信息按需出现,不常驻。 还要控制看到多少。 整页搬运没有必要。页面应该先被压缩成可直接推理的 Markdown、JSON、links 或截图。 比如这次实验里,AI 抽取返回的是这样的结构: ``` { "section_title": "自我改进的学习循环", "content": [ "学习循环是 Hermes 与其他自托管 Agent 的根本区别。", "工作原理:任务完成 → 模式提取 → 技能创建 → 技能完善 → 周期性提示(每 15 个任务评估一次)", "缓存感知学习:内存架构在初始化时冻结系统提示快照,以提升缓存命中率" ] } ``` 送进 Agent 上下文的,只有这些结构化、去噪后的信息:共 14,616 字符,约 4,078 tokens。 没有导航栏,没有广告,没有脚本,没有冗余 HTML。 Agent 拿到的是可以直接消费的材料,不用再当一次网页清洁工。 最终 Hermes 给出的结论也更干净: > 分层记忆与可插拔内存架构 > 自 v0.7.0 起内存完全可插拔,支持内置、Honcho、向量存储、自定义数据库等后端,通过 hermes memory setup 切换。 > 自我改进学习循环与技能自动生成 > Agent 完成任务后提取模式,创建 Markdown 技能文件,后续任务中复用并完善,形成“任务 → 模式提取 → 技能创建 → 技能完善”的循环。 > 模型无关架构与 MCP 服务器模式 > 一条命令切换 200+ 模型;v0.6.0+ 新增 MCP 服务器模式,可将 Hermes 暴露为 IDE/工具的 MCP 服务器。 这里的关键不是答案更短。 关键是:来源可追溯,材料低噪声,Agent 不用在垃圾上下文里找重点。 ## 七、XCrawl 在这条链路里的位置 现在再看 XCrawl,就比较清楚了。 它不是一个普通网页抓取工具。 在 Agent 工作流里,XCrawl 更像是网页进入上下文之前的清洗层。 你可以让 Agent 直接用浏览器或 curl 抓网页。 但这么做的问题是,网页会以一种很脏的形态进入上下文。 XCrawl 做的是另一件事:先把网页处理成 Agent 更容易使用的材料。 它覆盖几类常见场景: - search:按查询搜索网页,适合开放式 research。 - scrape:抽取单个 URL,适合文章、文档、产品页。 - map:发现站点 URL,适合先摸清网站结构。 - crawl:批量抓取站点内容,适合文档站、竞品站、资料库。 输出也更适合 Agent: - Markdown:保留正文语义,方便直接阅读。 - JSON:适合结构化提取,比如价格、版本、功能点。 - links:保留引用和后续追踪入口。 - screenshot:需要视觉判断时,可以留截图。 所以它解决的不是能不能抓到网页。 它解决的是:网页抓到以后,能不能变成干净、可引用、可推理的上下文。 这就是为什么我觉得 AI 搜索会变成 Agent 的基础设施。 Agent 越强,越不能把脏数据直接塞给它。 ## 八、怎么在 Agent 里用 XCrawl 如果你想复现类似流程,可以先装 XCrawl Skills。 把这个链接发给 Hermes,让它按 README 安装: https://github.com/xcrawl-api/xcrawl-skills/blob/main/README.zh-CN.md 也可以直接对 Hermes 说: > 安装这个 XCrawl Skills:https://github.com/xcrawl-api/xcrawl-skills/blob/main/README.zh-CN.md 然后去 Xcrawl 官网申请 API Key: 官网注册后有免费额度,可以先跑几个真实任务看看效果。 本地配置文件放这里: ``` { "XCRAWL_API_KEY": "<your_api_key>" } ``` 路径是: ~/.xcrawl/config.json 配置完以后,就可以在 Agent 里用 search、scrape、map、crawl 这些 skill。 我建议先从两个任务开始试。 第一,给一个网页,让 Agent 只抽取正文、关键观点和引用链接。 第二,给一个站点,让 Agent 先 map 出 URL,再挑最相关的页面 scrape。 这两个任务最能看出差距。 因为你会发现,真正影响 Agent 质量的,经常是垃圾上下文有没有挡在门外。 ## 九、最后说人话 Hermes 让我重新理解了 Agent。 以前我会觉得 Agent 的核心能力是推理、规划、调工具。 现在我会再加一条:上下文控制。 上下文越多,不一定越好。 模型能力的上限,不只取决于参数,也取决于它每一步看到的材料质量。 所以未来 Agent 的差距,不只是模型差距,也会是上下文工程差距。 谁能让模型少看垃圾、多看关键,谁的 Agent 就更稳。 这也是 XCrawl 这类 AI 搜索/抽取工具的价值。 它不是让 Agent 看更多网页。 它是让 Agent 少看废话。 参考来源: - Lost in the Middle: https://aclanthology.org/2024.tacl-1.9/ - NoLiMa: https://arxiv.org/abs/2502.05167 - Context Length Alone Hurts LLM Performance Despite Perfect Retrieval: https://aclanthology.org/2025.findings-emnlp.1264/ - Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents - RAG or Long-Context LLMs: https://aclanthology.org/2024.emnlp-industry.66/ - Code execution with MCP: https://www.anthropic.com/engineering/code-execution-with-mcp - Multi-agent research system: https://www.anthropic.com/engineering/multi-agent-research-system - XCrawl Skills: https://github.com/xcrawl-api/xcrawl-skills ## 相关链接 - [雪踏乌云 reposted](https://x.com/Pluvio9yte) - [@bozhou_ai](https://x.com/bozhou_ai) - [3.1K](https://x.com/bozhou_ai/status/2049021892208521544/analytics) - [https://github.com/xcrawl-api/xcrawl-skills/blob/main/README.zh-CN.md](https://github.com/xcrawl-api/xcrawl-skills/blob/main/README.zh-CN.md) - [https://github.com/xcrawl-api/xcrawl-skills/blob/main/README.zh-CN.md](https://github.com/xcrawl-api/xcrawl-skills/blob/main/README.zh-CN.md) - [Xcrawl](https://www.xcrawl.com/?keyword=736zq00n) - [https://aclanthology.org/2024.tacl-1.9/](https://aclanthology.org/2024.tacl-1.9/) - [https://arxiv.org/abs/2502.05167](https://arxiv.org/abs/2502.05167) - [https://aclanthology.org/2025.findings-emnlp.1264/](https://aclanthology.org/2025.findings-emnlp.1264/) - [https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) - [https://aclanthology.org/2024.emnlp-industry.66/](https://aclanthology.org/2024.emnlp-industry.66/) - [https://www.anthropic.com/engineering/code-execution-with-mcp](https://www.anthropic.com/engineering/code-execution-with-mcp) - [https://www.anthropic.com/engineering/multi-agent-research-system](https://www.anthropic.com/engineering/multi-agent-research-system) - [https://github.com/xcrawl-api/xcrawl-skills](https://github.com/xcrawl-api/xcrawl-skills) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [3:04 PM · Apr 28, 2026](https://x.com/bozhou_ai/status/2049021892208521544) - [3,181 Views](https://x.com/bozhou_ai/status/2049021892208521544/analytics) - [View quotes](https://x.com/bozhou_ai/status/2049021892208521544/quotes) --- *导出时间: 2026/4/28 17:46:12*
深 深入理解 AI Agent:设计原理与工程实践 李博杰新书《深入理解 AI Agent:设计原理与工程实践》开源,涵盖从0到1构建生产级AI Agent的原理与代码,包括RAG、工具调用、多Agent协作等实战内容。 技术 › Agent ✍ 李博杰🕐 2026-07-15 AI Agent开源LLMRAG工具调用多模态编程工程实践生产级代码
A Agent 的数据面概念扫盲-建立技术侧认知体系 本文深入解析了 Agent 数据面的核心概念,将其比作操作系统的内存管理单元。文章详细阐述了 Context Engineering 的演变、Session/Thread/Profile 的架构差异,以及 Session Memory 与 Long-term Memory 的区别。作者还重点介绍了 Hermes 中的 Memory 设计方案、SQLite FTS5 与 BM25 算法原理,以及向量检索与关键词检索在 RAG 中的混合应用,旨在为开发者建立一套完整的 Agent 数据面技术认知体系。 技术 › Agent ✍ MateMatt🕐 2026-07-12 AgentContext EngineeringRAGMemoryBM25SQLite FTS5向量检索HermesLong-term MemoryLLM
H Hermes Agent 完全指南:从零到自进化的 AI 员工 这是一份 Hermes Agent 的深度实操指南,涵盖了安装、模型选择、平台配置及最佳实践。文章对比了 Hermes 与 OpenClaw、Claude Code 的差异,强调了其本地化记忆、自我改进能力和多平台支持优势。核心内容涉及通过 Cron 和 /goal 命令实现全天候自主任务执行,助你打造一个能持续进化的 AI 员工。 技术 › Agent ✍ YanXbt🕐 2026-05-28 HermesAI AgentLLM自动化自我进化OpenClawClaude教程模型选择DevOps
Y Your Agent Needs a Wiki and a Recording 文章指出仅依靠扩大上下文窗口无法解决 Agent 的遗忘问题,并提出了 GBrain 和 Lossless 两个解决方案。GBrain 是基于 Wiki 的知识检索层,解决跨对话的长期记忆(如项目背景、决策历史);Lossless 则像会议录音,通过保留原始消息记录,解决长对话中的细节检索与回溯问题。二者结合能让 Agent 拥有类似查阅文档和回溯记录的能力,从而更智能地处理复杂任务。 技术 › Agent ✍ Vox🕐 2026-05-18 GBrainLosslessAgent MemoryOpenClawHermesRAGLLMContext Window
A Agent 记忆架构指南:为什么你需要 Wiki 和 录音 文章探讨了 AI Agent 开发中的记忆瓶颈,指出单纯扩大上下文窗口并不足以解决遗忘问题。作者提出了 GBrain 和 Lossless 两个核心模式:GBrain 像公司 Wiki,用于跨会话查询事实和决策;Lossless 像会议录音,允许在长对话中无损检索原始细节。文章详细解释了二者的区别、应用场景以及如何在 OpenClaw 和 Hermes 运行时中集成。 技术 › Agent ✍ Vox🕐 2026-05-18 AgentGBrainLosslessOpenClawHermes上下文管理记忆架构RAGLLM开发指南
H Hermes Agent Masterclass:架构详解与实战指南 本文是 Hermes Agent 的深度教程。Hermes 是一个能够在使用中不断自我进化的 AI Agent,与 OpenClaw 等其他 Agent 不同,它具备跨会话记忆、自编写/修剪技能以及通过 GEPA 引擎进行离线验证的独特能力。文章详细剖析了其包含 SOUL.md 身份层在内的三层记忆系统,并指导读者如何从零配置运行多个具备独立个性的 Agent。 技术 › Hermes ✍ Akshay🕐 2026-05-14 AI AgentHermesNous ResearchSelf-evolvingGEPAMemory SystemTutorialOpenClawLLM架构
A AI Agent 记忆机制原理与实战解析 文章深入浅出地讲解了 AI Agent 记忆系统的工作原理,从基础的单会话与多会话记忆保持切入,引出 Google 提出的情景、语义与程序性记忆三分法。通过对比 OpenClaw 的实现方式与存在的问题,重点剖析了企业级方案 EverOS 的架构。EverOS 将记忆细分为六大类,并通过语义巩固、主动上下文重建等技术优化记忆的抽取、更新与检索。文章还包含 EverOS 的 API 调用示例及 20 个真实落地场景,为开发者提供了 Agent 记忆系统的全景指南。 技术 › Agent ✍ 铁锤人🕐 2026-05-14 AI Agent记忆系统OpenClawEverOSRAG向量数据库长上下文自进化LLM实战案例
A AI代理内存痛点终于被解决?GBrain + Hermes/OpenClaw真实反馈 作者分享了AI代理工具Hermes和OpenClaw在长期记忆方面的痛点,并介绍了YC总裁Garry Tan开源的GBrain。GBrain作为一个“外挂大脑”,基于Postgres和向量技术,解决了AI代理容易遗忘的问题,实现了跨会话的长期记忆和知识库管理,被视为2026年个人AI生产力的重要突破。 技术 › Agent ✍ loveabit🕐 2026-05-03 AI代理GBrainHermesOpenClawLLM知识管理开源生产力长期记忆RAG
A Agent Memory Engineering 文章探讨了 AI Agent 的记忆机制,解释了为何不同 Agent(如 Claude Code 和 Codex)之间无法直接通过复制文件来迁移记忆。作者指出,这是因为模型在后期训练时与特定的记忆层“融合”了。文章对比了 Hermes、Codex CLI 和 Claude Code 三种实现,并得出结论:最聪明的架构(如向量数据库、知识图谱)输给了最简单的方案(LLM + Markdown + Bash 工具)。核心在于 Agent 遵循的读写规范,而非数据结构本身。 技术 › Agent ✍ Nicolas Bustamante🕐 2026-05-02 AgentMemoryLLMEngineeringClaude CodeCodexRAGPost TrainingMarkdownHermes
2 2026年AI Agent:学什么、做什么、跳过什么 本文探讨了在快速迭代的AI Agent领域中,如何辨别技术的持久价值与暂时噪音。作者提出了过滤新技术的五个维度,强调了“上下文工程”和“工具设计”作为核心原语的重要性。文章主张关注那些能经受时间考验的基础模式,而非追逐每周的新框架,并指出真正的专业技能在于知道该忽略什么。 技术 › Agent ✍ Rohit🕐 2026-05-01 AI Agent上下文工程技术选型LLM方法论架构设计Rohit工具设计技术趋势提示工程
2 2026年AI Agent横评:水星与爱马仕的抉择 文章针对2026年AI Agent红海现状,对比了OpenClaw、Hermes(爱马仕)和Mercury(水星)三款工具。指出OpenClaw成本高易出Bug,Hermes适合进阶玩家追求自我进化,而Mercury(水星)因其安全可控、成本低廉及稳定性,被推荐为普通人的最优解。文章详细分析了选型逻辑并提供了Mercury的安装指南。 技术 › Agent ✍ 弘毅新征程🕐 2026-04-29 AI AgentMercury工具测评OpenClawHermesLLM个人助理技术选型效率工具DeepSeek
H Hermes Agent 完全上手指南:会自己进化的 AI Agent 这是一份关于 Hermes Agent 的深度上手教程。文章介绍了 Hermes 相比 OpenClaw 的核心优势:具备自我进化能力,能从任务中自动创建和优化 Skills,以及拥有强大的 SQLite 全文搜索记忆系统。教程涵盖从环境准备、安装配置、基础对话,到进阶的消息网关配置、定时任务、记忆训练,再到高级的 MCP 服务器集成、多 Profile 管理、浏览器自动化及语音交互等 15 个实践任务,帮助用户全面掌握这一开源 AI Agent 框架。 技术 › Hermes ✍ OneHopeA9🕐 2026-04-22 AI AgentHermesOpenClaw自我进化记忆系统MCP教程自动化SQLiteLLM