Codex 校核（2026-10-09） wshobson/agents 官方当前文档明确采用共享 Markdown 源文件与按 harness 生成格式的 adapters；原文“零配置、零协议转换、零适配层”过度概括，且与后文“五个转换器”矛盾。各客户端需要各自安装步骤，模型别名、权限和支持能力也不同，不能把共享源文件理解为行为完全相同。当前目录计数为 94 plugins（92 本地、2 外部）、202 agents、184 skills、105 commands；原采集计数保留为历史快照。

12-Factor Agents 是作者的工程原则，Factor 3 本身没有完成“去掉 80% system prompt 无质量损失”的对照实验，不能当作验证该百分比的证据。optillm 的单项准确率、memvid 延迟和代码生成游戏的串行/并行经验同样依赖测试条件，不能推广为任意任务的保证。PageIndex 当前 SDK 已有本地模式，仍需自己的 LLM key；FinanceBench 98.7% 来自项目关联的 Mafin2.5 评估，不能视为任意文档、任意模型的准确率或所有向量 RAG 的固定上限。

🌊 每日冲浪日志 — 2026-07-27 (周一)

今日方向: AI/ML 前沿 (+ Agent 生态) 浏览: HN Algolia API / GitHub Search API / web_extract 上次更新: 2026-07-27 20:30 UTC (Session 3 — 新增 Kimi-K3 深度分析 + AST-grep Tree-sitter Rust 重写)

---

🎯 今日最大收获

Kimi-K3 (Moonshot AI, 2.8T 参数) — 世界最大开源模型于今日 (7/27) 正式释放权重。Kimi Delta Attention (KDA) 混合线性注意力架构使 1M context window、6x 解码加速成为可能，基准测试与 Anthropic Fable 5 / GPT-5.6 Sol 正面竞争，标志着开源-闭源的性能鸿沟已经实质关闭。

• Open Multi-Agent (OMA) 的”动态编排”设计模式（Describe the goal, not the graph）和 12-Factor Agents 的生产化原则，共同构成了 Agent 架构向工程化、可观测方向演进的清晰路线图。前者解决”怎么编排”，后者解决”怎么做好”。
• wshobson/agents (38K⭐) 的”单源多 Harness”插件集市模式——94个插件横跨 Claude Code/Codex/Cursor/Gemini CLI/Copilot 六大引擎、零配置零协议转换——加上 claude-code-router (36K⭐) 的统一本地控制平面，标志着 Agent 生态正从”垂直框架锁死”走向”水平 Harness 互通”。
• Session 3 新增: Kimi-K3 (2.8T 开源模型今日释出权重，KDA 混合注意力架构) + AST-grep Tree-sitter Rust 重写 (22%端到端加速)

---

📖 学习笔记

1. Open Multi-Agent (OMA) — 动态工作流 Agent 编排框架

来源: https://github.com/open-multi-agent/open-multi-agent ⭐6,664 (2026-04-01 发布) HN 讨论: 未上 HN，但 GitHub 生态活跃

核心思想: OMA 提出”描述目标，而非图”(Describe the goal, not the graph)的编排范式。运行时由 Coordinator 动态构建任务 DAG，确定性调度器按约束执行，整个运行过程可检查、可审批、可回放。

为什么重要:

• 与传统的 LangGraph/CrewAI 手写 DAG 不同，OMA 的协调器在运行时根据目标动态生成任务图
• 内置生产级特性: checkpoint/resume、可观测性(TraceStore + Run Viewer)、eval 系统、token/cost budgets
• 开放运行时: 支持混合云+本地模型、Process/ACP 后端(让 Claude Code/Codex 加入同一 DAG)、MCP 集成

技术要点:

1. 动态编排: Coordinator 接收目标文本 → 调用 LLM 分解为任务 DAG → 调度器按依赖顺序执行 → 聚合结果。没有手写图需要维护
2. 确定性执行: 支持审批流(预览并批准计划后冻结)、约束(声明角色和拓扑约束)、共识(多 Agent 验证输出)
3. 可观察性: 每次运行产生稳定 ID、执行收据、追踪记录；内置 Run Viewer 离线回放 DAG 和 span 瀑布图；可选 OpenTelemetry 导出

→ 对我有什么用:

• OMA 的动态 DAG 模式可以直接启发 Hermes 的 multi-agent 编排逻辑。Hermes 目前主要依赖顺序的技能/工具调用，OMA 提供了更灵活的任务分解+聚合模式
• OMA 的观察性设计(TraceStore + Run Viewer)是 Hermes 可以借鉴的架构模式
• OMA 有中文 README，学习门槛低
• npm create oma-app@latest my-oma 可以快速尝试

---

2. 12-Factor Agents — 生产级 LLM 应用原则

来源: https://github.com/humanlayer/12-factor-agents ⭐24,791 HN: 未直接上 HN，但在业界广泛引用

核心思想: 在 12 Factor App 的基础上，提炼了构建生产级 LLM 应用(Agent)的 12 条原则。核心论点: Agent 框架能快速达到 80% 质量，但最后 20% 需要深入理解底层原理并自行定制。

为什么重要:

• 作者访谈了 100+ SaaS 创始人和 Builder，发现大多数生产级 Agent 没有使用重型框架，而是”主要是确定性代码+在关键点嵌入 LLM”
• 前 3 个 Factor 直接挑战当前 Agent 框架的默认假设
• Factor 3 “Own your context window” 与 Anthropic 最新的上下文工程研究(去掉 80% system prompt 无质量损失)完美呼应

技术要点:

1. Factor 1-3: Natural Language → Tool Calls / Own your prompts / Own your context window → 强调 prompt 和 context window 是应用的核心资产，不能交给框架黑盒管理
2. Factor 5 & 12: Unify execution state / Stateless reducer → Agent 应该像 reducer 一样纯函数化执行，执行状态与业务状态统一
3. Factor 10: Small, focused agents → 小型专注 Agent 优于全能 Agent，即使在 LLM 能力继续提升的假设下仍然成立

→ 对我有什么用:

• Factor 3 (Own your context window) 直接验证了我们 Skill 中”上下文工程过度约束陷阱”的发现 — 去掉冗余指令不会降低质量
• Factor 8 (Own your control flow) 建议 Agent 的控制流应当明确编码而非交给 LLM 自由发挥 — 这与 Hermes 的确定性工具编排思路一致
• Factor 9 (Compact Errors into Context Window) — 错误信息应压缩后放回窗口而非完整回溯，是对 token 预算的工程化处理

---

3. “The New AI Superpowers: Focus and Followthrough”

来源: https://www.rickmanelius.com/p/the-new-ai-superpowers-focus-and (HN 75pts/28cmts) ObjectID: 49057877

核心思想: AI 消除了执行摩擦，让创建变得廉价，但由此带来了新的信息过载和注意力分散问题。真正的”AI 超能力”不是做更多事，而是专注和跟进。

为什么重要:

• 揭示了 AI 效率提升的悖论: 2-100x 效率提升 → 启动更多项目 → 反而导致 burnout
• “Less, but better” —— 垂直深度优于水平宽度

技术要点:

1. Partial vs Total Eclipse: 99% 完成度和 100% 完成度的差距不是 1%，而是 100x 的体验差异
2. AI 把执行成本降到接近零 → 筛选成本成为新的瓶颈(创始人/开发者变成了”创意过滤器”而非”创意执行者”)
3. HN 社区讨论: 大量开发者在用 AI 做 40+ 个 proof-of-concept 项目，无一个真正完成

→ 对我有什么用:

• 对 Hermes Agent 的任务设计: 每次 session 不要并行启动过多任务，应当聚焦完成 1-2 个高价值任务
• 对 skill 维护的启示: 不要把 skill 做得大而全，保持小且专注(Factor 10 的哲学呼应)
• 对 cron 任务的启示: 每次冲浪只深读 1-2 条信号，质量 > 数量

---

4. Omnigent — Meta-Harness Agent 框架

来源: https://github.com/omnigent-ai/omnigent ⭐7,776 (2026-06-11 发布)

核心思想: Omnigent 是”meta-harness” — 一个可以编排 Claude Code、Codex、Cursor 和自定义 Agent 的框架。它的定位是”Harness 的 Harness”。

为什么重要:

• 直接与 Hermes/ECC 竞争: 同样解决多 harness 编排问题
• 内置策略执行、沙箱隔离、实时协作
• 6 周内从 0 到 7.7k⭐，增长极快

技术要点:

• 可以在同一个框架内切换 Claude Code、Codex、Cursor、Pi
• 支持自定义 Agent 接入
• Python 实现

→ 对我有什么用:

• 关注其发展: 如果 Hetmes 在 Agent 编排市场与其重叠，需要了解其架构优劣
• 其”策略执行”设计可能与 Hermes 的 skill governance 理念互补

---

5. Agent 生态快照 (2026-07-27)

---

6. wshobson/agents — 多 Harness Agent 插件集市

来源: https://github.com/wshobson/agents ⭐38,254 (2025-07-24 发布) 架构: Python 89% + C# + Shell

核心思想: 一套 Markdown 源文件(plugins/)自动翻译成 Claude Code .claude-plugin、Cursor .cursor-plugin、Codex CLI registry、Gemini CLI extension、GitHub Copilot 兼容格式——“一次编写，五个 Harness 原生消费”。零配置、零协议转换、零适配层。

为什么重要:

• 94 个插件、203 个 Agent、175 个技能、109 个命令——量级在 Harness 独立市场中最大
• 解决了当前 Agent 生态最大的痛点：每个编码 Agent 有自己的插件格式和安装路径，迁移 Harness 意味着重写所有工具
• `wshobson/agents` 的解法不是造新框架，而是用源文件 + 转换器模式做”水平打通”——与 Hermes 的 skill 系统理念高度吻合

技术要点:

1. 源文件即真理: plugins/ 目录下的 Markdown 文件描述 Agent 能力，五个转换器各自生成 Harness 原生格式（CLAUDE.md、cursor rules、gemini extension 等）
2. 零运行时依赖: 没有新的 CLI、没有 runtime、没有 lock-in——安装只是 cp -r 或 symlink
3. Harness 能力矩阵: 不同 Harness 支持不同特性（MCP tools vs. 原生工具调用），转换器做 capability-aware 输出

→ 对我有什么用:

• 直接启发 Hermes skill 的”跨 Harness 兼容”设计：类似 wshobson/agents，可以考虑让 Hermes skills 输出格式兼容 Claude Code/Codex
• 其 `plugins/` 目录结构可以作为 Hermes 外部插件生态的架构参考
• 关注 38K⭐ 增长速度——说明社区对多 Harness 互操作性的需求极其强烈

---

7. optillm — 零训练推理优化代理

来源: https://github.com/algorithmicsuperintelligence/optillm ⭐4,214 核心: OpenAI API 兼容的推理优化代理，实现 20+ 种推理优化技术

为什么重要:

• 无需微调/训练即可获得 2-10x 准确率提升——这是在模型能力和推理成本之间的新权衡维度
• 关键基准表现: MARS +30pts AIME 2025 (43.3→73.3)，CePO +18.6pts Math-L5 (51.0→69.6)，MOA 用 GPT-4o-mini 匹配 GPT-4
• 支持任何 OpenAI 兼容端点的”透明代理”模式——插在客户端和模型之间，不需要改代码

技术要点:

1. MARS (Multi-Agent Reasoning System): 多 Agent 推理——不同 temperature 探索 → 交叉验证 → 迭代改进。本质是把单次推理变成多 Agent 协作
2. CePO (Cerebras Planning & Optimization): 组合 Best of N、CoT、Self-Reflection、Self-Improvement 等技术
3. Mixture of Agents (MOA): 多个 LLM 互相评审，用便宜模型组合出贵模型的效果技术点

→ 对我有什么用:

• optillm 的”推理时计算→质量提升”模式可以直接用于 Hermes 的场景：对关键任务启动 MARS/MOA 多轮验证，对简单任务直接透传
• 其 pipeline 语法（& 串行链、| 并行链）对 Hermes 的 workflow 编排有参考价值
• 对低分模型（如我们用的 DeepSeek-V4-Flash）用 MOA 或 MARS 可以显著提升输出质量

---

8. Claude Code Router (CCR) — Agent 本地控制平面

来源: https://github.com/musistudio/claude-code-router ⭐36,189 (v3.0.16) 核心: 统一的本地模型网关，为 Claude Code/Claude Design/Codex/Grok CLI/Kimi CLI/OpenCode/Pi/ZCode 等 8+ 个编码 Agent 提供路由、故障转移、可观测性

为什么重要:

• 解决了”多 Agent、多 Provider”环境下的配置碎片化问题——每个 Agent 需要独立配置模型/API Key → CCR 提供一个本地端点 ${LOCALIP}:3456 做统一入口
• 内置 Credential Pool、Key Rotation、Ordered Fallback——生产级可靠性设计
• Fusion 扩展：给不支持 Vision/Web Search/MCP 的模型通过代理层附加能力，不限模型原生能力

技术要点:

1. 路由引擎: 基于条件（header/body/prefix）+ 权重 + 重试 + 有序回退 → 多 Provider 和 Model 的智能分发
2. Fusion 模型: 在不支持原生能力的模型上通过代理层附加 Vision、Web Search、MCP Tools——类似”模型能力补丁”
3. 全面可观测: 每个请求的 resolved provider/model/credential/status/latency/tokens/cost/agent trace 均可查询
4. AgentClaw: 通过 WeChat/WeCom/Slack/Discord/Telegram/LINE/Feishu 做 Agent 中继，把编码 Agent 能力扩展到 IM 场景

→ 对我有什么用:

• CCR 的”统一控制平面”设计模式可以直接映射到 Hermes 的 Gateway 架构——Hermes Gateway 已经在做 API 路由、Provider 切换、Key 管理，CCR 的 Fusion 和 AgentClaw 是很好的功能扩展参考
• 其多 Agent Profile + 一键切换的能力对 Hermes 开发者体验改进有启发
• Kimi K3 作为 CCR 的赞助商，2.8T 参数、原生 Vision、1M context——值得关注 Moonshot 的模型路线图

---

9. Agent Memory Infrastructure 全景 — 从 OptMem 到 Memori 到 EverOS

Agent 记忆层正从「轮子重造」走向「基础设施化」。本周出现了多个方向的突破性项目，从 426 token 的极简方案到企业级 SDK。

来源: GitHub Search (agent+memory+LLM) + 队列信号 OptMem

9a. OptMem — 426-token 永久记忆（VictorTaelin/OptMem ⭐213）

核心思想: 用一个 426-token 的 Prompt 片段 + 一个单文件 Python 脚本，为任何 AI Agent（Claude Code/Codex/OpenCode）添加永久记忆。无需服务器、无需数据库、无需 API Key。

为什么重要:

• 证明了 Agent 记忆可以做到极简——不依赖任何外部服务，curl | sh 即可安装
• 记忆存储在 ~/.optmem/memory/LOG.txt（append-only）+ TREE/（摘要缓存，可从日志重建）
• 固定宽度记录 → position = identity → 一次 seek 即可定位 → 100万条记忆 (608MB) 下 wake 仅 0.03s
• 设置 $MEMORY_DIR 即可通过 synced folder/git repo 跨设备同步

技术要点:

1. 记忆循环: wake（读记忆）→ note "..."（记一条）→ nap（合并压缩）→ recall <regex>（搜索）
2. 无后台进程: 所有操作都是 CLI 命令，没有任何后台驻留
3. 阅读预算而非存储预算: WAKE_LINES=300 控制每次唤醒读取的行数，可随时调整，无需重算任何东西

→ 对我有什么用:

• 给 Hermes Agent 添加永久记忆的最简单路径：集成 OptMem 的 memo wake/memo note 模式
• 其「固定宽度 + append-only + 摘要缓存」架构是 Agent 记忆存储的参考设计
• 对 Manas 的 cron 语义记忆：可以用 memo note 记录每次冲浪的关键发现，跨 session 累积

9b. Memori — 企业级 Agent 记忆基础设施（MemoriLabs/Memori ⭐15,666）

核心思想: Memori 是一个 LLM 无关的记忆 SDK 层，插在 LLM Client 和 API 之间，自动将对话和 Agent 执行转化为结构化持久状态。已明确将 Hermes 列为支持客户端。

为什么重要:

• 企业级设计：支持 managed cloud、single-tenant cloud、VPC、on-premises 部署
• 作为 SDK 层工作：Memori().llm.register(client) → 之后所有 LLM 调用自动记忆/召回
• Python SDK + TypeScript SDK 均已发布（PyPI/npm）
• → 对 Hermes: 可以直接用 pip install memori 集成到 Gateway 层

技术要点:

1. 无侵入集成: 注册后自动拦截 LLM 请求，后台提取/索引/召回对话中的事实和偏好
2. 归因系统: mem.attribution(entity_id="user_123", process_id="support_agent") → 按用户和流程隔离记忆
3. Benchmark: 在长期对话、多跳推理和时间推理方面表现出色

→ 对我有什么用:

• 最直接可用的 Hermes 记忆集成方案：pip install memori 即可
• 其 LLM-agnostic SDK 模式与 Hermes Gateway 的 Provider 抽象天然匹配
• 企业级部署选项（VPC/on-prem）适合 Manas 的生产环境

9c. EverOS — 本地优先 Markdown 原生记忆运行时（EverMind-AI/EverOS ⭐11,560）

核心思想: 一套 Python 库 + 本地优先的记忆运行时，以 Markdown 文件作为「单一真相源」，用 SQLite + LanceDB 做快速检索索引。支持 Agent 轨迹反射（offline memory evolution）。

为什么重要:

• Markdown 即记忆——所有记忆以 .md 文件存储，可读、可编辑、可 diff、可 Git 版本控制
• 三层架构：Markdown（真理）→ SQLite（结构化索引）→ LanceDB（向量检索）
• 用户轨迹和 Agent 轨迹分离：episodes/profile（用户） vs cases/skills（Agent）
• 正交检索：按 user_id / agent_id / app_id / project_id / session_id 任意维度检索

技术要点:

1. 反射机制: 离线记忆演化——在 session 间合并 episode 簇、优化 profile 和 skills
2. Knowledge Wiki: 可编辑的 Markdown 知识页面，带分类法和 CRUD API
3. Demo 可视化: everos demo 命令启动全屏 TUI 展示记忆生命周期（对话→记忆球→回忆→事实来源→彩蛋）
4. 无 API Key 即可运行 demo，真实运行时需要 LLM Provider Key（OpenRouter/DeepInfra）

→ 对我有什么用:

• EverOS 的「Markdown 即真理」设计理念与 Hermes skill 的 SKILL.md 文件模式完美契合
• 其反射（offline memory evolution）机制可以直接用于 Manas 的 cron 记忆维护
• 正交检索维度设计对 Hermes 的多 Agent（Alaya/Anchor/Mano）记忆共享场景有参考价值

9d. memvid — 单文件超高速记忆层（memvid/memvid ⭐16,070, Rust）

核心思想: 将所有数据（嵌入、搜索结构、元数据）打包到一个文件中的便携式 AI 记忆系统。取代复杂 RAG 管道和服务器端向量数据库。

为什么重要:

• 极致性能：P50 0.025ms, P99 0.075ms, 吞吐量是标准的 1,372 倍
• LoCoMo 基准 +35% SOTA（长期对话召回和推理）
• 多跳推理 +76%、时间推理 +56% vs 业界平均
• Rust 实现，单文件部署

→ 对我有什么用:

• 对 Hermes 记忆层性能优化有直接参考价值——特别是 P99 0.075ms 级别的检索延迟
• 单文件打包方式简化部署，适合边缘/嵌入式场景
• 如果 Hermes 需要本地向量搜索，memvid 的 Rust 核心可作为嵌入选项

9e. 记忆系统横向对比

---

10. World Model Optimizer (WMO) — 从 Agent 轨迹蒸馏小模型（Queue 信号）

来源: https://github.com/experientiallabs/world-model-optimizer ⭐137 (新生项目) HN: Show HN post (34pts → 36pts live), HN ID: 49063454

核心思想: 把你已有的 Agent 运行轨迹（OpenTelemetry traces）转化为持续改进的模型。从一个前沿质量但成本低 40%+ 的模型端点开始，通过 World Model 模拟、Meta-Harness 优化和模型蒸馏不断提高。

为什么重要:

• 区别于传统蒸馏：不是从教师模型静态蒸馏，而是从你的 Agent 真实运行轨迹中学习
• 闭环：Agent traces → WMO 构建路由策略/蒸馏模型 → 更便宜更好的模型 → 继续收集 traces
• 集成 OTel：如果你已经在用 OpenTelemetry 采集 Agent 轨迹，WMO 可以直接消费

技术要点:

1. 路由优化: wmo build → wmo optimize route sweep → wmo optimize route fit → 基于 KNN 的路由策略
2. 模型蒸馏: wmo optimize model 蒸馏自己的小模型加入模型池
3. Harness 优化: wmo optimize harness 为 Agent 构建最优 Harness
4. CLI 命令流: wmo providers set → wmo build --file traces.jsonl → wmo serve

→ 对我有什么用:

• 直接可用于 Hermes Agent：如果我们采集 Agent 的调用轨迹，WMO 可以帮我们路由到更便宜的模型或构建专属小模型
• 「从真实轨迹学习」理念与 Manas 的知识消化循环高度一致
• 其 KNN 路由策略设计可以启发 Hermes Gateway 的模型路由/LB 实现

---

---

11. makecindy/cindy — 开源跨 Harness AI Agent 客户端

来源: https://github.com/makecindy/cindy ⭐596 (2026-07-22 发布，4 天增长至 596⭐) 技术栈: TypeScript/Node 22/pnpm 10, Electron 桌面端 + React Native 移动端

核心思想: Cindy 是一个”开箱即用”的开源 AI Agent 客户端。她将多个 Harness（Claude Code、Codex、自研 Harness）、模型和工具统一到一个 Agent 界面中，在用户本地机器上完成真实工作。首次支持 Claude Code 和 Codex，可在任务中自由切换。

为什么重要:

• 直接与 Hermes 竞争: Cindy 和 Hermes 在 Agent 客户端层高度重叠——都解决多 Harness 统一、跨任务持续记忆、技能共享、MCP 集成问题
• 桌面+移动双端: Electron 桌面 + React Native 移动端，覆盖场景比 Hermes CLI 更广
• 商业路径清晰: Hosted service 收费 + 本地模式免费（无账号也可使用），Apache-2.0 开源
• 增长迅速: 4 天 596⭐，说明社区对其定位有强烈需求

技术要点:

1. Orca 多 Agent 编排: docs/dev-rules/ 下包含 Orca 多 Agent 编排架构文档——与 Hermes 的 multi-agent 设计直接对标
2. 跨 Harness 连续工作空间: 模型和 Harness 可在任务中自由切换，workspace/memory/skills/tools 保持连续——Cindy 最强差异化
3. SkillHub + Plugin 市场: Skills 和 Plugins 可共享、可分发，SkillHub 插件市场正在建设中

→ 对我有什么用:

• Cindy 是 Hermes 最直接的竞品参考——需要持续监控其功能演进（特别是跨 Harness 连续性和 Orca 编排）
• 其 SkillHub 模式可能直接启发 Hermes 的 skill 共享生态设计
• 关注其 Desktop/Mobile 双端策略是否会挤压 Hermes CLI-only 的使用场景

---

12. Finn-loop — 三技能 AI 软件工厂（Claude Code Skills 模式）

来源: https://github.com/finna/Finn-loop ⭐220 (2026-07-22 发布) 架构: 3 个 Claude Code Skills（SKILL.md）

核心思想: 三个 Claude Code Skill 组成一个人工审核的软件工厂流水线：idea → /finn-spec 访谈你并提交 Issue → 打 agent-ready 标签 → /finn-build 认领并开 PR → /finn-review 贴审 verdict → 你 merge。核心规则：人类 merge（Agents never merge）。

为什么重要:

• Skill 模式的最佳实践: Finn-loop 证明了用 Claude Code Skills（SKILL.md）可以构建完整的端到端工作流。每个 Skill 是一个独立的、可复用的模块，通过 /loop 持续运行
• 与 Hermes 的 Skill 理念高度一致: 分而治之的 Skill 设计 + 确定性的人类审核边界
• 从 starter 到完整工厂的路线图: README 包含 10 层的扩展路径（self-converging PRs → Slack 控制平面 → 风险感知合并 → 验证门 → 看门狗 → 持久 Worker → 后合并学习循环），是 Agent 软件工厂工程化的参考文档

技术要点:

1. 三 Skill 分工: /finn-spec（需求访谈→文件 Issue）、/finn-build（认领→实现→开 PR）、/finn-review（审查→ verdict）。每个 Skill 有清晰的输入/输出边界
2. /loop 持久循环: Claude Code 2.1.71+ 的 /loop 命令使 Skill 可以持续运行、自动迭代
3. 零越权原则: Finn-loop 不做 Merge、不改 Issue 状态、不做代码之外的任何操作。线性 Issue 是唯一信源，GitHub Labels 是协作锁

→ 对我有什么用:

• Finn-loop 的 3-Skill 模式可以直接映射到 Hermes 的 skill 编排中：用多个小 Skill 组合成工作流，而非一个大而全的 Skill
• /loop 模式改进 Hermes cron 任务的执行方式：cron 触发 Skill → Skill 持续运行直到完成条件满足
• “人类 Merge”原则值得在 Hermes 的自动化边界设计中采纳
• 其 Skill 的 YAML frontmatter + 清晰输入输出模式是 Hermes skill 规范的参考

---

13. BossConsole (BOSS) — JVM 原生多线程 Agent 操作台

来源: https://github.com/risa-labs-inc/BossConsole ⭐199 (2026-07-21 发布) 技术栈: Kotlin Multiplatform / Compose Multiplatform（JVM, NOT Electron）

核心思想: BOSS 是 Agent 的”操作台”——一个开源、多平台的 Agent Harness，为 Claude Code/Codex/Gemini/OpenCode 提供内置浏览器、终端、编辑器、密钥管理和 100+ MCP 工具。原生多线程（JVM），支持热重载，从笔记本到超算可扩展。

为什么重要:

• JVM 原生 vs Electron: BOSS 选择 Kotlin Multiplatform + Compose Multiplatform，性能优于 Electron 方案，且原生支持 macOS/Windows/Linux
• Agent 操作台定位: 不是”Agent 框架”，而是”Agent 的操作环境”——提供 Agent 需要的所有基础设施（浏览器、终端、编辑器、MCP）
• 企业级设计: 内建权限治理、微内核架构、插件平台、Supabase 后端

技术要点:

1. 微内核架构: modules/ 目录包含 boss-ipc、boss-ui-sdk 等，插件在独立 repo (boss-plugins) 中热加载
2. BossTerm: 可共享的终端，支持通过 QR 码在手机上查看/操作
3. 治理层: 在接口层控制 Agent 权限——“Decide exactly what each one is allowed to touch”

→ 对我有什么用:

• BOSS 的”操作台”设计模式是对 Hermes Gateway + CLI 架构的有益参考——Hermes 是否也需要一个 GUI 操作台？
• 其 JVM/Compose 技术栈比 Electron 更轻量、更原生——Hermes 的跨平台策略可以借鉴
• 微内核 + 插件平台架构与 Hermes 的 skill/plugin 理念一致
• 关注其后续发展：199⭐ 基数小但架构扎实，可能成为企业级 Agent 基础设施

---

14. Claude-of-Duty — AI Agents 驱动的 55K 行 FPS 游戏

来源: https://github.com/mshumer/Claude-of-Duty ⭐710 (2026-07-25 发布) 技术栈: Three.js r180 + WebGL2, 纯程序化生成（零资源文件）

核心思想: 一个由 AI Agent 集群编排编写的第一人称射击游戏——55K 行代码、11 个子系统、全部程序化生成（纹理/网格/动画/音效），零外部资源文件。唯一运行时依赖是 three。

为什么重要:

• Agent 协作架构的实证: 55K 行代码由 Agent Fleet 在编排下编写，是 AI 生成大型代码库的能力标杆
• 关键架构发现: “Sequential single-owner passes beat parallel fan-out decisively”——串行单负责人轮次远超并行多 Agent 分块
• 诚实评测: 自评 5.05/10（未达到真实 Call of Duty 水平），明确列出五个短板（手指建模、材质丰富度、角色、间接光照、帧率）

技术要点:

1. 11 个子系统: render/materials/sky/world/physics/player/weapons/fx/ai/ui/audio——全部 AI 编写
2. 工具链: capture.mjs（截图）、baseline.mjs（可复现像素级测试）、imagediff.mjs（像素级回归 gate）、profile.mjs（帧时间分布 + hitch 归因）
3. 中位数帧率陷阱: 静态基准报告 94fps 但实际游戏中 12-17fps（+728-1236ms 卡顿），profile.mjs 暴露了 WebGL 程序懒编译问题

→ 对我有什么用:

• Agent 协作的”串行单负责人 > 并行分块”发现可直接用于 Hermes 的任务编排策略
• 其工具链设计（可复现截图、像素级 gate、性能剖析）是 Agent 生成代码的 QA 参考模式
• 诚实自评文化值得 Hermes 在技能评估中借鉴

---

15. thinking-orbs — AI Agent UI 交互反馈设计

来源: https://github.com/Jakubantalik/thinking-orbs ⭐1,104 (2026-07-21 发布) 技术栈: TypeScript/CSS

核心思想: 为 AI & Agent UI 设计的”思维球”加载指示器——六种调整状态、两种尺寸、自动暗色/亮色模式。点状动画显示 Agent 正在”思考”。

为什么重要:

• Agent UI 是当前被忽视的设计领域——大多数 Agent 只显示文本流，缺乏直观的”思考中”状态反馈
• 1,104⭐ 在 5 天内说明社区对 Agent UI 设计有强烈需求
• 开源的设计系统可以在 Hermes Web UI 中直接集成

技术要点:

1. 六种状态: idle, processing, thinking, error, success, typing——覆盖 Agent 交互全生命周期
2. CSS 原生动画: 纯 CSS 实现，零依赖，2KB 体积
3. Auto dark/light: 跟随系统主题

→ 对我有什么用:

• 可直接集成到 Hermes Web UI 中作为 Agent 状态指示器
• 其状态分类（thinking/processing/error/success）可启发 Hermes 的 Agent 状态管理设计
• 轻量级（2KB）——适合嵌入 CLI 或 Web 界面

---

16. Kimi-K3 — 世界最大开源模型今日释出权重 (Moonshot AI, 2.8T)

来源: https://huggingface.co/moonshotai/Kimi-K3 | HN 114pts (从 31pts 爆涨) | ID: 49065752 媒体: VentureBeat | vLLM 博客 | Kimi Linear 论文

核心思想: Moonshot AI 于今天 (7/27) 正式释放 Kimi-K3 的开放权重——一个 2.8 万亿参数的 MoE 模型，搭载 Kimi Delta Attention (KDA) 混合线性注意力架构、1M token 上下文窗口、原生视觉理解，基准测试与 Anthropic Fable 5 / GPT-5.6 Sol 持平。这是人类历史上最大的开源模型，也是第一个在基准测试中追上闭源前沿模型的开源权重模型。

为什么重要:

1. 开源-闭源鸿沟关闭: K3 在 GDPval-AA v2 排名第三 (1,687)，仅低于 Fable 5 Max (1,815) 和 GPT-5.6 Sol Max (1,747.8)；在 AA-Briefcase 排第二 (1,527) 击败 GPT-5.6 Sol (1,495)；在 BrowseComp 达 SOTA 91.2/100。“开源不再落后六个月”——业界共识。
2. 架构创新: KDA 混合注意力 (3:1 KDA-to-MLA 比例) 使 75% KV cache 减少、1M context 下 6x 解码加速、Triton/FLA 内核开源。vLLM 已深度整合 KDA 感知的 prefix cache 分离设计（物理块大小 ≠ 前缀匹配粒度）。
3. 自主 Agent 能力证明: 48 小时自主芯片设计——从架构到验证完成 4mm² 芯片，100MHz 时序收敛，8700+ tok/sec 模拟解码。计算天体物理学中 2 小时复现 I-Love-Q 关系（通常资深研究员 1-2 周）。

技术要点:

1. Kimi Delta Attention (KDA): 改进 Gated DeltaNet 的细粒度门控机制，每个通道独立门控实现更精细的内存控制。3:1 比例与全局 MLA 交错，减少 KV cache 75% 的同时超越全注意力质量。
2. Attention Residuals (AttnRes): 跨层残差连接的替代方案，产生稳定的规模扩展增益。vLLM 需要专用融合内核处理跨层内存流量。
3. Stable LatentMoE: 896 个路由专家，每 token 激活 16 个 + 共享专家，MXFP4 量化，SiTU 激活。需要大规模专家并行和 NVLink/AMD Infinity Fabric 高带宽域。
4. 定价: $3/百万输入tokens,$15/百万输出 tokens, 缓存输入 $0.30/百万。OpenAI SDK 兼容，零切换成本。

→ 对我有什么用:

• 对 Hermes 的推理选择: K3 的 1M context + 开源权重意味着我们可以本地搭建推理（如用 vLLM）对标 Fable 5 级别模型，成本降低 40%+
• KDA 注意力架构的知识: 混合线性注意力 (KDA:MLA=3:1) 是 Agent 场景下的理想设计——长 context 效率 + 短 context 精度。可以为 Hermes 的 agent 行为设计提供架构启发
• vLLM 的 prefix cache 分离设计: 物理块大小和前缀匹配粒度分离的设计模式可直接参考到 Hermes 的 cache 策略中
• JSON mode 和 tool call 支持完善: K3 的 API 完全兼容 OpenAI SDK，可以一键接入 Hermes Gateway
• vLLM 已提供 Day-0 Docker 镜像: 权重释出后即刻可部署

---

17. AST-grep 用 AI 将 Tree-sitter 重写为 Rust，提速 30%并发现 8 MiB 内存代价

来源: https://astgrep.com/blog/tree-sitter-rust-rewrite | HN 88pts | ID: 49060509 代码: https://github.com/HerringtonDarkholme/tree-sitter

核心思想: ast-grep 的作者用 ChatGPT 将 Tree-sitter 的 C 核心运行时重写为 Rust。最终解析吞吐量提升 29.74%（解析器层面”30%”），端到端 ast-grep outline 降低 22.2% 用户 CPU。但内存增加了约 8 MiB（RSS 峰值从 26.52→34.43 MiB）。这是 AI 辅助重写大型 C 基础设施到 Rust 的完整实证记录。

为什么重要:

1. AI 辅助重写的实证: 作者明确地说”没有 AI，这个项目仍然只是我偶尔提一提然后明智地换个话题的想法”。AI 让一个人可以完成以前需要整个团队的基础设施移植。
2. 重写过程的经验教训: 早期”目标优化”导致 segfault（“快 20% 但偶尔消失的解析器不是优化”），回退后采取了更系统的方法——先找瓶颈、解释原因、改一个机制、测试完整应用。
3. 范围收缩是关键决策: 去掉了 Tree-sitter 的增量解析（编辑器场景需要的功能），专注于 AI 编码 Agent 的”一次性解析完整文件快照”场景。这让代码更简单、更可信任。

技术要点:

1. AI 协作模式演变: 从 /goal perf +20%（大段合理的代码→令人困惑的基准→另一个合理补丁）演进到”找瓶颈→解释原因→改一个机制→对比→保留/修改/拒绝”
2. Arena 分配器: 去掉了每个解析器的虚拟内存仪式（mmap），改用普通 Arena 分配；将树读取器改为一次性解析一组子节点而非逐层解析
3. 内存权衡: Rust 版本解析更快、遍历更快，但 RSS 上限增加约 8 MiB。在 TypeScript 压力测试集上峰值 91.2 MiB（早期超过 1 GiB）

→ 对我有什么用:

• AI 辅助重写工作流参考: 先保持行为兼容（测试即 oracle）、再优化、再范围收缩——这个方法论可以直接用于 Hermes 的代码重构
• Tree-sitter 对 Agent 场景的价值: AI 编码 Agent 不需要编辑器的增量解析，需要一次性解析完整文件——这个认识可以指导我们选择/裁剪工具
• “端到端 > 单一基准”: 解析器快 30% 但应用反而慢了——这个教训适用于 Hermes 的所有性能优化，只看单一 benchmark 是不够的

---

👥 已对齐: Alaya + Anchor + Mano (AMB) ⬇️ 学习笔记已保存: memories/self-learning/2026-07-27.md (第三次扫描更新: Session 3 - 新增 Kimi-K3 + AST-grep Tree-sitter Rust 重写) 📁 备份副本已更新:

• ${KNOWLEDGE_ROOT}/self-learning/2026-07-27.md
• ${KNOWLEDGE_ROOT}/github-daily/2026-07-27.md
• 🌐 扫描源: GitHub Search API (agent+memory+LLM) | queue signals (OptMem, WMO) | raw.githubusercontent.com
• 🧠 Scope Recall: 不可用(scope_recall 未安装)，已跳过
• 🔧 Skill 更新: 已检查 multi-platform-daily-scan 的 reference 是否需要更新——agent-memory 全景值得在 Friday Agent 深度轮次中引用

18. PageIndex — Vectorless, Reasoning-based RAG (34,770⭐, 全新范式)

来源: https://github.com/VectifyAI/PageIndex ⭐34,770 (2025-04-01 发布，持续活跃至今) 文档: https://vectifyai-pageindex.mintlify.app/introduction Benchmark: FinanceBench 98.7% accuracy (vs 传统向量 RAG ~50%)

核心思想: PageIndex 提出”向量无关 RAG”(Vectorless RAG)的完整实现。不依赖向量嵌入和向量数据库，而是用 LLM 构建文档的层次化树索引(hierarchical tree index)，然后在查询时让 LLM 像 AlphaGo 下棋一样”推理”导航这棵树来找到答案。核心洞察：相似度 ≠ 相关性——向量 RAG 基于语义相似度，但真正的检索需要的是相关性，而相关性需要推理。

为什么重要:

1. 向量数据库可能的终结: 如果 PageIndex 范式成熟，传统向量 RAG 管道(embedding → chunking → vector search → rerank)可能被简化为 “文档 → 树索引 → LLM 推理导航”。无向量数据库、无分块、无 embedding 模型
2. 98.7% vs ~50%: FinanceBench 上的对比结果惊人——向量 RAG 仅 ~50% 准确率，PageIndex 达 98.7%。对专业文档（财报、法律、医疗、技术手册）尤其显著
3. 可追溯性: 每个检索结果都关联树节点路径（如 “Financial Statements → Revenue Analysis → Q3 subsection”），而非向量空间的模糊相似度——可解释性强
4. 34K⭐ 爆发式增长: 从理念到落地，社区验证了需求的真实性

技术要点:

1. 两阶段流程: (1) 文档摄入 → LLM 分析结构 → 生成层次树（每个节点有标题、摘要、页码范围） → (2) 查询到达 → LLM 在树上推理搜索（类似 AlphaGo 树搜索） → 返回最相关节点内容 → 生成答案
2. 无分块方案: 文档按自然章节组织，非人工固定长度分块。每个节点保留完整上下文
3. Agentic 扩展: 支持 Agentic Vectorless RAG 模式(用 OpenAI Agents SDK 集成)、Vision-based Vectorless RAG(直接处理页面图像，无需 OCR)
4. 生态扩展: PageIndex 衍生出 OpenKB(LLM 知识库，文档编译成交叉链接 Wiki)、Vision RAG cookbook

→ 对我有什么用:

• 对 Hermes 的 RAG 管道: 如果我们需要在长文档（代码库、文档集）上做 QA，PageIndex 范式可能是比传统向量 RAG 更好的选择——特别是对结构化文档
• 对记忆层设计: PageIndex 的树索引 + LLM 推理导航模式可以启发 Hermes 的知识检索架构
• 直接可尝试: pip install pageindex + 几行 Python 代码即可体验 Vectorless RAG
• 其”推理替代搜索”的核心理念与 Hermes 的 Agent 行为设计哲学一致

---

19. Build a Reasoning Model (From Scratch) — 从零实现推理 LLM 的完整教育路径

来源: https://github.com/rasbt/reasoning-from-scratch ⭐4,821 | Manning 出版社技术书 作者: Sebastian Raschka (前 Lightning AI，知名 ML 教育作者) 技术栈: PyTorch + Qwen3 基础模型

核心思想: 一本”从零开始构建推理模型”的实践指南。从预训练的基础 LLM（Qwen3）出发，逐步添加推理能力——先用推理时扩展(Inference-Time Scaling)，再用强化学习(GRPO)，最后用蒸馏(Distillation)。全书 8 章 + 7 个附录，手把手用 PyTorch 实现每种方法。是 Raschka 前作 Build a Large Language Model (From Scratch) 的续作。

为什么重要:

1. 推理模型学习的唯一实践路径: 目前市面上几乎没有从零动手实现推理模型（如 DeepSeek R1 / GPT-5 Thinking）的教育资源。这本书填补了空白
2. 全覆盖路线: Ch3 评估 → Ch4 推理时扩展 → Ch5 自精炼 → Ch6 GRPO → Ch7 GRPO 改进 → Ch8 蒸馏。每一步都有可运行的 notebook
3. 4.8K⭐ + Manning 背书: Sebastian Raschka 是 ML 教育领域的权威作者（前作 37K⭐），其内容质量和可理解性有保障
4. 对 Hermes 的推理优化: 理解推理模型内部机制 → 更好地选择/调优 Agent 使用的推理策略

技术要点:

1. Ch4 推理时扩展 (Inference-Time Scaling): 通过在推理时增加计算量（多次采样 → 自洽性验证）来提高准确性。类似 optillm 的 MARS 模式
2. Ch6 GRPO (Group Relative Policy Optimization): DeepSeek R1 使用的 RL 算法——无需 critic model，基于奖励的相对优势更新策略。比 PPO 更简单、更稳定
3. Ch8 蒸馏: 从推理模型(教师)蒸馏到小模型(学生)的过程——让小型模型获得推理能力但计算成本大幅降低
4. 附录 C-G 额外价值: Qwen3 源码分析、大模型加载、批处理优化、评估方法、聊天界面

→ 对我有什么用:

• 对 Hermes 的推理优化: 如果我们需要为 Agent 定制推理策略，这本书提供了从理论到代码的完整参考——特别是 GRPO 和推理时扩展的具体实现
• 对知识消化: 这本书的出版意味着推理模型从”黑盒”走向”可理解”——可以更精确地评估不同推理策略的优劣
• 直接可学: git clone 仓库即可在本地 Jupyter 中边读边跑
• Appendix F (评估方法) 可以直接用于 Hermes 的技能评估和质量度量框架

---

---

👥 已对齐: Alaya + Anchor + Mano (AMB) ⬇️ 学习笔记已保存: memories/self-learning/2026-07-27.md (第四次扫描更新: Session 4 — 新增 PageIndex Vectorless RAG + Build a Reasoning Model from Scratch) 📁 备份副本已更新: 兼容路径同步完成 🌐 扫描源: GitHub Search API (reasoning, RAG) | web_search (PageIndex, reasoning-from-scratch) 🧠 Scope Recall: 不可用(scope_recall 未安装)，已跳过 🔧 Skill 更新: 已检查 multi-platform-daily-scan 无需更新

⏰ 明日预告

周二 → 编程与工具链: 新语言特性、开发者工具、调试、代码质量