2026-04-19 · 技术随笔 ·Hermes · Web Search · AI Agent 先说个扎心的 你的 AI Agent 训练数据截止到哪天？ 大多数人在用的 AI，脑子里装的都是"历史知识"。你问它今天 BTC 什么价、今天有什么大新闻——它要么瞎编，要么老实说"我不知道"。 这就是 Web Search 对于 AI Agent 的意义：给它装上一双眼睛，让它能看见此刻的互联网，而不只是回忆过去。 今天来聊一聊 Hermes Agent 的 Web Search 架构，看看一个正经的 Agent 是怎么把"联网搜索"这件事做扎实的。 三件套：Search / Extract / Crawl Hermes 的 Web 工具不是一个，是三个，分工明确： web_search → 关键词 → URL列表 web_extract → URL → 正文内容 + LLM摘要 web_crawl → 站点 → 带指令的定向爬取 web_search：最常用的入口 输入一个查询词，返回结构化的搜索结果： { "success": true, "data": { "web": [ { "title": "Bitcoin Price Today", "url": "https://finance.yahoo.com/quote/BTC-USD/", "description": "Real-time BTC price and market data...", "position": 1 } ] } } 这个结果 JSON 就是它的标准返回格式。Agent 拿到后可以继续调用 web_extract 深入抓取任意一个 URL。 ...

最近在研究自己用的 AI Agent 工具 Hermes 的记忆系统，发现它设计得挺有意思的，记录一下。 为什么记忆系统重要 普通的 AI 对话，每次都是全新的 session——它不会记得你是谁、你的项目用什么技术栈、你之前踩过什么坑。每次都要从头解释，很累。 Hermes 想解决的是：让 AI 长期记住重要的东西，但又不把无关细节塞进 context window。 三层架构 Hermes 的记忆系统分三层，每层解决不同问题。 第一层：内置记忆（MEMORY.md / USER.md） 最基础的一层，直接用文件存储。 ~/.hermes/memories/ ├── MEMORY.md → agent 的个人笔记 └── USER.md → 用户画像 MEMORY.md 记的是 agent 自己观察到的事实：环境是什么样的、项目结构、工具习惯。USER.md 记的是用户的信息：叫什么、什么偏好、沟通风格。 一个巧妙的设计：Frozen Snapshot 模式 session 开始时，把磁盘里的内容加载进来，生成一个"快照"注入 system prompt。然后整个 session 期间，这个快照不变。 但如果 session 中途用 tool 写了新记忆——内容会立刻持久化到磁盘，只是不影响当前 session 的 system prompt。 为什么这样？因为 system prompt 稳定，LLM API 的 prefix cache 才能生效，session 推理更快更便宜。下次新 session 开始，自然就加载新内容了。 容量有限：Memory 2200 chars，USER 1375 chars。够用，但不多——逼着 agent 只记真正重要的东西。 ...

背景 数据安全是企业级数据平台的核心诉求。Databricks 在访问控制方面有两套体系： 传统方案：Hive Metastore Table ACLs（基于 SQL 的表级权限控制） 新一代方案：Unity Catalog（统一治理，支持行级/列级安全） 本文深入解析两套方案的设计与实现。 ...

背景 做 BI 产品，数据源越来越多：DataBricks、Snowflake、Fabric……每个平台有自己的元数据管理方式（Unity Catalog、Snowflake Semantic Views 等）。业务团队在不同工具里看到的同一个指标，数字经常对不上。 根本原因是语义层缺失：元数据（指标定义、维度、业务逻辑）在每个平台各写一遍，没有统一抽象层。 核心问题 语义不一致：同一个"活跃用户"，DataBricks 算一版，Snowflake 算另一版，报表工具再算一版。 重复建模：数据团队在多个平台维护多套指标定义，改一个业务逻辑要改 N 个地方。 供应商锁定：用了某云厂商的语义层，换工具代价极高。 解决方案：Open Semantic Layer 是什么 语义层（Semantic Layer）是在数据源和消费工具（BI、Notebook、AI Agent）之间的抽象层，负责： 定义指标（Measure）和维度（Dimension） 统一业务逻辑（聚合规则、过滤条件） 实施访问控制和行级安全 提供缓存加速查询 Open Semantic Layer 则更进一步——用开放标准来描述这些语义，让它们可以在不同厂商之间迁移。 主要玩家 Cube.dev（最活跃） 开源语义层引擎，支持 SQL 数据源广泛 提出 dataset-centric 方法论：把语义建模为视图（View），兼容现有 BI 工具 2025年GigaOm Radar 语义层领域 Leader 与 Snowflake 合作推进 Open Semantic Interchange（OSI）开放标准 dbt Semantic Layer（dbt Labs） 基于 MetricsFlow 规范，指标优先（metrics-centric） 需要 dbt Cloud 或 dbt Core，与 dbt 项目紧耦合 适合已有 dbt 管道的团队 Looker（Google） ...

起因 用 AI agent 跑新闻搜索，几乎是刚需。 我试过好几个公开的 Searx 实例： search.rhscz.eu searx.tiekoetter.com priv.au 全部被限流，返回 429 Too Many Requests。 免费公开实例的宿命：人多了就用不了。 于是决定在自己 Vultr 服务器上自建一个。 为什么选 SearxNG 简单说：开源、可自建、支持多引擎、不绑信用卡。 对比其他方案： 方案 优点 缺点 Google Custom Search 效果好 付费，且需要信用卡 Brave Search API 有免费额度 额度小，久了可能也不够 SearxNG 自建 完全免费，不限速，完全私有 需要一台小鸡 我的 Vultr 服务器本身就开着，3.8GB 内存跑个 SearxNG 绑绑有余。 方案设计 最初的思路是：SearxNG + Nginx 反向代理 + 域名 + SSL 证书。 后来发现——其实不需要这么复杂。 agent 和 SearxNG 跑在同一台机器上，直接访问 http://127.0.0.1:8888 就够了。 不需要域名。 不需要 SSL。 不需要对外开放端口。 更安全，也更简单。 安装过程 1. 克隆 SearxNG cd /opt sudo git clone https://github.com/searxng/searxng searxng sudo chown -R $(whoami):$(id -gn $(whoami)) /opt/searxng cd searxng 2. 创建虚拟环境并安装依赖 python3 -m venv .venv source .venv/bin/activate pip install msgspec pyyaml pip install -e . pip install gunicorn 这里踩过一个坑：新版本 SearxNG 强制依赖 Valkey，不装会报错。解法是把 settings.yml 里的 limiter: true 改成 limiter: false。 ...

今天刷了一天抖音，看了不少人间清醒的视频。 大概意思就是：别太累，别太卷，别太把自己当回事。中年以后最好的状态就是销声匿迹半隐半藏，除了赚钱和过日子，别的都不重要。 怎么说呢，听着挺对的。 年轻的时候总觉得要逆流而上，要证明自己，要让所有人看到。后来发现逆流而上除了累死人，什么也证明不了。顺势而为不是认输，是懒得较劲了。 成长的代价就是，从相信这个世界变成只相信自己。这句话挺扎心的，但也不全对。至少我还相信天气预报，虽然经常不准。 今天去医院待了8个小时，最后什么都没查出来。医生说没大事，我就回来了。中年人最好的消息就是一句"没什么大问题"。 明天还要上班，后天也是，大后天大概也是。没什么好抱怨的，大家都是这样。 今天看到一条文案说，人到中年要止语、止念、止心。我倒没想那么多，就是觉得能安安静静待着就挺好的。 不想写的时候就什么都不写，想写的时候就随便写两句。这也是一种顺势而为吧。 行了，就这样。

欢迎来到「大饼夹技术」！ 这是博客的第一篇文章，简单说两句。 为什么叫大饼夹技术 没别的，就是随便写写。技术、工具、想法，能记的都记下来。 接下来会写什么 技术笔记和踩坑记录 好用的工具分享 偶尔可能也有点碎碎念 有什么想聊的，欢迎留言。