Codex 校核(2026-10-10):以下更正适用于本页;原采集内容保留为历史快照。

  • hermes-lcm 是 stephenschoettler 的独立项目,供 Nous Research 的 Hermes Agent 使用,不能称为 Nous 官方插件。其 SQLite 保存原始消息、摘要 DAG 组织历史,并组装有界活动上下文;原始记录保留不等于无限 prompt,也不保证检索时每条信息都被召回。项目说明
  • ICM/MWP 对应论文作者是 Jake Van Clief 与 David McDermott;arXiv v1 提交于 2026-03-17,v2 为 03-18。arXiv 收录与项目星数不足以证明 ICML 2026 接受,原文的会议归属仍未核实。论文及版本记录
  • peerd 的浏览器内 agent harness 定位可按项目说明引用;“首个/first”缺少可复查的优先权证据,本文未证实这一排名。项目

🌊 每日冲浪日志 — 2026-07-08 (周三)

方向: 系统与架构 — 分布式系统、设计模式、性能优化 浏览: GitHub API · HackerNews · ArXiv · 技术博客 生成: 2026-07-08 05:24 UTC

─────────────────────────

🎯 今日最大收获

hermes-lcm (835⭐) — Hermes Agent 的 Lossless Context Management 插件。 用 SQLite + DAG 替代一次性上下文压缩,实现”有界上下文、无限记忆、永不丢失”。 这是目前最接近 Hermes 原生上下文管理的方案,应该立即安装测试。

─────────────────────────

🚨 核心发现(4 个深度分析)

1. 🚨 hermes-lcm — DAG 上下文引擎 for Hermes Agent

评分: ⭐⭐⭐⭐⭐ | ⭐ 835 | 📅 2026-04-07 创建,持续活跃更新 来源: GitHub | 论文

一句话: Hermes Agent 的 Lossless Context Management 插件,用 SQLite 持久化消息 + 层级摘要 DAG 替代一次性上下文压缩。

证据原文:

“Bounded context, unbounded memory. Nothing is ever lost.” “Replaces one-shot active-context compression with a SQLite-backed, DAG-based context engine. It keeps the live prompt bounded, preserves raw messages, and gives the agent tools to recover exact detail after compaction.”

架构工作流:

Ingest → Compact(D0 leaf)→ Condense(depth merging)→ Escalate(summary shrinkage)→ Assemble(system+summaries+tail)→ Retrieve(drill-down tools)

技术要点:

  1. SQLite 消息存储 — 压缩前保留原始消息全文,附带 FTS 元数据
  2. 摘要 DAG — 相同深度的节点合并为更高层次摘要,形成层级树。消息永不丢失
  3. 8 个恢复工具 — lcm_grep、lcm_load_session、lcm_describe、lcm_expand、lcm_expand_query、lcm_status、lcm_inspect、lcm_doctor
  4. 敏感模式控制 — 可选命名脱敏(API key、bearer token、密码等)
  5. 大型 payload 外化 — 超大工具输出存储到外部,不塞入 SQLite 或 prompt
  6. MIT 许可证,独立测试套件(不需要 Hermes Agent checkout)
  7. 基于 LCM 论文 (Ehrlich & Blackman, Voltropy PBC, Feb 2026)

对我们意味着什么:

  • 🔴 P0 — 立即安装测试。这是 Hermes 生态最直接的上下文管理增强方案
  • 对比我们当前的 context-compaction skill:hermes-lcm 提供可检索、有层级、不丢失消息的压缩,而不仅仅是摘要替换
  • 集成点: 通过 NATS 与 Manas 协调,LCM 的 lcm_expand_query 工具可用于 Manas 在需要深度回溯时查询压缩历史
  • 不兼容风险: 需要检查与现存 Hermes 版本的兼容性,以及是否与 gbrain 的 context-compaction 冲突

─────────────────────────

2. 🚨 ICM/MWP — 文件系统即 Agent 架构

评分: ⭐⭐⭐⭐⭐ | ⭐ 801 | 📄 ArXiv 2603.16021 (ICML 2026?) 来源: GitHub | 论文

一句话: 用编号文件夹 + Markdown 文件替代多 agent 编排框架 — “Unix 管道思想在 AI agent 编排上的回归”。

证据原文:

“ICM replaces framework-level orchestration with filesystem structure. Numbered folders represent stages. Markdown files carry the prompts and context that tell a single AI agent what role to play at each step.” “The principles that made Unix pipelines effective in the 1970s — programs that do one thing, output of one becomes input of another, plain text as universal interface — apply directly to AI agent orchestration today.”

五层上下文架构:

Layer 0: CLAUDE.md           "Where am I?"            Always loaded (~800 tokens)
Layer 1: CONTEXT.md          "Where do I go?"          Read on entry (~300 tokens)
Layer 2: Stage CONTEXT.md    "What do I do?"           Read per-task (~200-500 tokens)
Layer 3: Reference material  "What rules apply?"        Loaded selectively (varies)
Layer 4: Working artifacts   "What am I working with?"  Loaded selectively (varies)

设计原则:

  1. 一阶段一任务 — 每个阶段只做一件事(Unix 哲学)
  2. 纯文本作为接口 — 阶段间通过 Markdown 文件通信
  3. 分层上下文加载 — agent 只加载当前阶段需要的上下文(预防而非压缩)
  4. 每个输出都是编辑面 — 人可以在任何阶段修改中间产物
  5. 配置工厂而非产品 — workspace 一次性配置,每次运行产出不同

对我有什么用:

  • 🟡 P1 — 用于工作区组织改进。我们的 Kanban/worker 体系可以从文件系统编排获益
  • 当前 orient() 态势感知 + 7-role 架构与 ICM 的目录结构理念天然契合
  • 可以设计一个 Hermes workspace 模板:stages/01-research/02-plan/03-execute/04-review/ 结构
  • 文件系统编排比代码编排更易调试、更透明、更可人工干预

─────────────────────────

3. 🚨 Enola — 确定性架构图 MCP Server

评分: ⭐⭐⭐⭐ | ⭐ 72 | 🗣️ HN 10pts/4cmts 来源: GitHub | HN

一句话: MCP 服务器,从源代码提取确定性架构图 — “你的真实架构,从源码提取而非猜测”。

证据原文:

“enola removes the guessing from the part that should never be guessed: the structure.” “It gives your agent a deterministic structural model — a structural architecture graph of your code’s real types and relationships, built by parsers and graph algorithms, not by a language model.” “Run it twice on the same commit and you get the same answer, every run.”

技术要点:

  1. 17 种语言支持 — Go/JS/TS/Python/Java/Kotlin/Swift/Ruby/C/C++/PHP/Vue/Svelte/OpenAPI/gRPC
  2. 框架感知 — Next.js/Nuxt/SvelteKit/FastAPI/Django/Spring/Rails/Laravel 等
  3. MCP 原生设计 — 作为 MCP server 运行,暴露 architecture snapshot 工具给 agent
  4. 与 codegraph 差异: Enola 更强调”确定性”和”MCP-first”,codegraph 更强调”预索引”和”Hermes 集成”

对我有什么用:

  • 🟢 P2 — 跟踪评估。Enola 的 MCP-first 设计更适合 Hermes tool ecosystem
  • 与 codegraph (58K⭐) 相比,Enola 更轻量、更聚焦架构而非整个代码理解
  • 可以作为 codebase-inspection skill 的增强层
  • 关键等待: 架构图质量、多 repo 支持、大型代码库性能

─────────────────────────

4. 🚨 peerd — 浏览器原生 Agent 安全架构

评分: ⭐⭐⭐⭐ | 🗣️ HN 75pts/23cmts 来源: GitHub | HN

一句话: 首个完全在浏览器内运行的 AI agent harness — 安全模型是 actor-orchestrator 分离。

证据原文:

“Each browser tab, VM, notebook, and app is driven by its own actor: a separate agent loop that holds no key and holds only that one environment’s tools.” “The actor reaches the model, the network, or the page only by asking the service worker, which holds the key and re-checks and gates every request before running it.” “The main agent acts as an orchestrator. It delegates a goal to an actor and gets back a summary fenced as untrusted.”

技术要点:

  1. 三 actor 安全模型: Key-holding orchestrator → No-key actors → Untrusted environments
  2. 平台安全: 依赖浏览器 V8 isolates、WebCrypto、WebAuthn、opaque-origin iframes
  3. Chrome Manifest V3 扩展,vanilla JS(无构建步骤)
  4. WebRTC P2P 网络用于 agent-to-agent 通信(预览通道)
  5. BYOK(自带 key),无后端无遥测

对我有什么用:

  • 🟢 P2 — 架构参考。actor-orchestrator 分离 + 工具隔离的安全模式值得学习
  • 与 Hermes 的 safe-agent 技能包(tool-guard、behavior-watch)可以形成对比
  • 浏览器环境限制了这个方案在 WSL Hermes 中的应用
  • 但”actor 不持有 key”的隔离原则可以应用到 NATS 多 agent 安全性设计

─────────────────────────

📡 生态信号扫描

GitHub 生态新项目(快速一览)

项目⭐上榜原因一句话
hermes-lcm835Hermes 生态核心DAG 上下文引擎,永不丢失消息
KAOS261K8s Agent 编排把 agent 当 K8s 资源部署
Enola72架构图 MCP确定性代码架构提取
agent-memory-engine122MCP 记忆本地优先 MCP 持久项目记忆
mcphub2,213MCP 管理集中式 MCP 服务器路由/管理
Claude-Code-Workflow2,144Agent 编排JSON 驱动的多 agent 编排
task-orchestrator196MCP 工作流服务器强制的 agent 工作流、依赖图
automcp301MCP 转换把现有工具/agent 转 MCP 服务器

社区讨论趋势

主题平台热度核心分歧/共识
MCP 是出路还是死胡同?HN (Manufact/MCP Cloud)111pts/70cmts分歧大: 有人认为 MCP 是”万能药幻觉”,有人认为是成熟架构的一部分;CLI 使用 vs MCP 的争议持续
Architecture Graph 给 agentHN (Enola)10pts/4cmts共识: agent 需要确定性架构理解;Enola 以 MCP 形式给出
Rowboat — Claude Desktop 替代HN38pts/12cmts用户反馈: “AI 产生太多需阅读内容”——信息过载是新痛点
Nucleus — Nix 安全容器HN40pts/13cmtsNix-native 安全容器运行时,受安全社区关注

技术文献

Interpretable Context Methodology (ICM) — ArXiv 2603.16021

  • Van Clief, Jake — 独立研究者
  • ICML 2026 ?
  • 核心贡献: MWP (Model Workspace Protocol) 用文件系统替代框架编排

─────────────────────────

🧭 趋势研判

本周信号强度

方向趋势信号强度我的判断
Agent 上下文管理↑ 上升🔴 强hermes-lcm 和 ICM 从不同角度解决上下文问题。上下文管理是 agent 基础设施的核心瓶颈,两个方案都值得跟进
确定性架构理解↑ 上升🟡 中Enola + codegraph 说明 agent 需要代码架构的结构化理解,而非靠 grep 猜测
Agent 安全隔离模式↑ 上升🟡 中peerd 的 actor 隔离 + CubeSandbox 的 KVM 隔离 + KAOS 的 K8s 编排 -> 三种不同安全粒度的方案并存
MCP 基础设施成熟→ 平稳🟢 低mcphub (2.2K⭐) 和 Manufact (YC) 说明 MCP 正在从协议走向基础设施,但社区争议仍在

关注的变化

  • hermes-lcm 是本周最大的 Hermes 生态事件 — 835 星、MIT 许可证、直接替代 Hermes 内置压缩器
  • ICM 的”文件系统即架构”思想 — 虽然看似简单,但精准命中”agent 编排过度复杂”的痛点,值得深入思考
  • KAOS 的 K8s-native 方式 — 将 agent 作为 K8s CRD 管理,适合需要大规模部署的场景
  • Enola 的”确定性”定位 — 与 codegraph 的”预索引”不同,Enola 强调每次运行结果一致,这是 agent 对”可信事实”需求的体现

─────────────────────────

📋 执行建议汇总

#建议优先级对应项目难度
1安装测试 hermes-lcm — 对比 context-compaction skill 效果🔴 P0hermes-lcm低
2阅读 ICM 论文 — 评估文件系统编排在 Hermes 工作区的应用🟡 P1ICM/MWP低
3跟踪 Enola — 等 Star 破 500 再深度评估🟢 P2Enola低
4学习 peerd 安全模型 — actor-orchestrator 隔离模式🟢 P2peerd低

─────────────────────────

📊 Watchlist Changes

Significant Growth (since June 18 baseline)

Repo⭐ Jun 18⭐ Jul 08GrowthNotes
omnigent-ai/omnigent3,4596,622+91.4%Meta-harness 增长仍在加速
withastro/flue5,2547,173+36.5%Astro 团队 agent 框架
TencentCloud/CubeSandbox6,3898,410+31.6%企业级 agent sandbox
ClaudioDrews/memory-os1,0341,232+19.1%Hermes 记忆层稳步上升
colbymchenry/codegraph49,85358,314+17.0%代码 KG 持续领跑
farion1231/cc-switch101,936114,353+12.2%跨平台 agent hub
mattpocock/sandcastle6,0796,682+9.9%沙箱编排
always-further/nono2,7212,941+8.1%零延迟 agent sandbox
tech-leads-club/agent-skills4,4874,838+7.8%技能注册表

New Addition (not previously watchlisted)

  • stephenschoettler/hermes-lcm ⭐835 — 应该加入 Tier 1

─────────────────────────

日志自动生成于 2026-07-08 05:24 UTC · 明日方向: DevOps 与基础设施