Hermes + clawhip + LazyCodex：把 Discord 频道做成 Linux 贡献中枢
用 Discord 作为唯一入口，Hermes 作为中枢，clawhip 作为事件路由层，LazyCodex 作为代码执行与验证层，设计一个面向 Linux 修复、优化与上游贡献的多代理系统。
   AI   Hermes LazyCodex Codex AI Agent 软件工程 系统设计   9 min

Hermes + clawhip + LazyCodex 系统封面

如果把上一篇关于 claw-code 的核心思想抽出来，它其实不是“某个 agent 写代码很快”，而是：人类只负责方向、约束和异常处理，系统负责把计划、执行、审查、通知和重试连成闭环。

这篇文章把这个思想换一套组件重新设计：用 Discord 频道作为人类入口，用 Hermes 作为中枢，用 clawhip 作为消息和事件运输层，用 LazyCodex 把 Codex 变成可验证的代码执行层。示例场景不是写一个玩具应用，而是对 Linux 做代码修复、性能优化和上游贡献。

先说明一个术语边界：这里的 clawhip 指的是用户给出的 zcxGGmu/clawhip 项目在本文架构中的定位：事件运输和路由层。它不是模型，不负责推理，也不应该把自己塞进 agent 上下文。它只做消息规范化、路由、状态投递和审计。

一句话设计

这个系统的核心判断是：Hermes 是指挥室，clawhip 是运输线，LazyCodex 是工程车间，Codex 是其中一个强编码工人。

Discord 频道里只有一个可见角色：Hermes bot。用户不需要打开终端，也不需要记住哪个 agent 适合哪个任务。用户只在 #linux-lab 里发一句目标，例如：

@hermes 看一下这个 Linux 内核警告：
drivers/net/foo.c 在断开设备时 refcount 可能泄漏。
目标：先复现，再给出最小修复，不能直接发邮件，先给我 patch 和验证证据。

Hermes 收到消息后，不应该立刻让 Codex 改代码。它要先做四件事：

  1. 把自然语言请求转换成结构化任务。
  2. 判断任务类型：bug 修复、性能优化、文档修订、驱动适配，还是补测试。
  3. 给任务选择 worker：Codex + LazyCodex、只读 reviewer、静态分析器、邮件打包器。
  4. 把所有状态交给 clawhip 投递到正确频道和审计日志里。

在这个设计里，Codex 不再是“整个系统”。Codex 是一个可被调度的执行器。真正的系统价值在于调度、隔离、验证和反馈。

为什么要拆成三层

如果让一个 agent 同时负责 Discord 消息、任务规划、代码修改、日志投递、邮件发送和长期记忆，系统很快会失控。原因不是模型不够强，而是职责边界太混。

层 核心职责 不应该做什么
Hermes 接收用户意图、规划任务、选择 worker、维护记忆和策略 不直接承担所有代码修改细节
clawhip 事件路由、频道投递、状态规范化、审计日志、通知降噪 不做复杂推理，不消耗 agent 上下文
LazyCodex 项目记忆、计划执行、工作树隔离、工具调用、测试与证据账本 不直接面对 Discord 用户和跨任务调度
Codex worker 读代码、改代码、跑测试、解释 diff、生成 patch 不自行决定是否上游提交

拆层之后，系统有一个很重要的性质：通知和编排不进入编码 agent 的有限上下文。一个正在修 Linux 内核 race condition 的 Codex worker，不需要知道 Discord 上谁点了哪个表情，也不需要负责把进度消息格式化成频道更新。clawhip 会读 worker 的状态事件，把它变成“已复现”“测试失败”“需要人工确认”等短消息，投到频道里。

这就是 claw-code 那类系统最值得学的部分：不是“谁能写得更快”，而是“谁能把模型劳动放进可靠流程里”。

总体架构

下面这张图是系统控制面。Discord 是人类入口，Hermes 是中心决策器，clawhip 把所有任务状态从 worker 世界运回频道，LazyCodex 则负责让 Codex 在隔离工作树里执行工程任务。

Hermes Discord Linux 系统架构图

这套架构里有三个分离：

第一，控制面和执行面分离。Hermes 决定任务、权限和 worker，LazyCodex 负责在具体仓库里执行。Linux 仓库、构建目录、测试环境和补丁文件都属于执行面。

第二，对话状态和工程证据分离。Discord 消息只能说明人说了什么，不能证明代码真的通过测试。工程证据必须落在文件系统和日志里，例如 diff、命令退出码、失败日志、测试矩阵、review 结论、patch series。

第三，开发者上下文和审查者上下文分离。写补丁的 worker 不应该自己宣布补丁可上游。至少要有一个只读 reviewer 从零读取任务、diff 和测试证据，挑战实现假设。

Discord 频道协议

系统可以只用一个频道，但长期使用时建议拆成四类频道：

频道 用途
#linux-intake 用户提交任务、贴日志、贴 issue、确认目标
#linux-lab Hermes 发布任务计划、worker 状态和阻塞点
#linux-review 人工审查 patch、测试证据和提交说明
#linux-ops 定时任务、失败告警、资源占用和队列状态

Hermes bot 在频道里只输出高价值状态，不刷屏。典型状态应该像这样：

[linux-20260615-001] 已完成复现
仓库：torvalds/linux
子系统：drivers/net
证据：repro.log, dmesg-before.txt
下一步：启动 LazyCodex worker 生成最小补丁
需要人工：否

注意，这里没有贴完整日志。完整日志应该作为 artifact 存在，由 clawhip 维护链接、摘要和校验值。频道里只放判断和下一步。

任务状态可以定义成有限状态机：

intake -> triage -> reproduce -> plan -> patch -> verify -> review -> package -> human-approval -> submit -> monitor

Hermes 只允许任务沿状态机推进。worker 不能从 patch 跳到 submit。如果测试失败，状态回到 patch 或 plan。如果人工否决，状态回到 triage 或直接归档。

LazyCodex 在这里做什么

LazyCodex 的价值不是“替 Codex 起一个别名”，而是给 Codex 加一层工程纪律。Linux 这种仓库特别需要纪律，因为一次小改动可能影响 ABI、锁、内存模型、驱动初始化顺序或架构相关行为。

在这套系统里，Hermes 不直接调用 codex exec "fix it"。它应该让 LazyCodex 为目标仓库准备一套可恢复流程：

  1. 用 /init-deep 或等价流程为 Linux 源码局部建立项目记忆，尤其是子系统目录、维护者规则、测试入口和反模式。
  2. 用规划模式产出可审查计划，说明要读哪些文件、复现什么、修改范围在哪里、不碰哪些边界。
  3. 用隔离 worktree 执行补丁，所有写操作都限制在任务工作树里。
  4. 在每次工具调用后保留证据：命令、退出码、日志路径、diff 摘要。
  5. 用独立 review worker 进行对抗审查，而不是让实现者自证成功。
  6. 只有在人工确认后，才进入邮件或 PR 相关动作。

换句话说，LazyCodex 是“把 Codex 变成工程流程”的层，而不是 Hermes 的替代品。Hermes 负责跨任务和跨频道的长期调度，LazyCodex 负责单个仓库任务内的执行纪律。

Linux 修复任务怎么跑

下面这张图描述一个 Linux 内核 bug 修复从 Discord 消息到上游 patch 的完整闭环。

Linux 贡献流程图

第一步是 triage。Hermes 需要先判断问题属于哪个子系统，是否已有类似报告，目标分支应该是 master、linux-next、稳定分支，还是某个 subsystem tree。clawhip 在这里记录任务 ID，绑定 Discord thread、仓库路径、worktree 路径和 artifact 目录。

第二步是复现。Linux 贡献里，复现比修改更重要。worker 需要保留复现命令、内核配置、硬件或模拟环境、dmesg、失败前后对比。没有复现证据的补丁，最多只能算猜测。

第三步是最小修改。Codex worker 应该优先读局部调用链、锁语义、错误路径和已有模式，不做横向重构。Linux 上游更容易接受小而清楚的 patch。一个修 bug 的 patch 不应该顺手改命名、移动代码或格式化整个文件。

第四步是验证矩阵。基础验证至少包括编译、相关子系统测试、scripts/checkpatch.pl、静态分析信号、复现脚本回归。更高风险的改动需要扩大到 kselftest、lockdep、KASAN、UBSAN、性能基准或多架构交叉编译。验证矩阵由 Hermes 决定，LazyCodex 执行，clawhip 记录。

第五步是上游包装。Linux 仍然高度依赖邮件式 patch 流程。系统需要生成清楚的 commit message、Fixes tag、Reported-by、Tested-by、Cc stable 条件判断，并用 scripts/get_maintainer.pl 找出维护者和邮件列表。但真正发送邮件前必须人工确认。

第六步是 review 循环。patch 发出后，Hermes 定时检查邮件线程或人工贴回的 review 意见。clawhip 把 review 意见转换成新 turn，LazyCodex 在同一个任务 ID 下生成 v2、v3。每一版都必须保留 changelog，不能覆盖历史证据。

代理角色分工

这个系统至少需要五类 worker。它们可以都由 Codex 承担，也可以混用其他 coding agent，但角色必须分开。

角色 目标 权限
Triage Agent 判断子系统、风险、复现路径、测试矩阵 只读
Reproducer Agent 写复现脚本、跑失败样例、收集日志 写 artifact，不改源码
Patch Agent 在隔离 worktree 里做最小修改 写源码和测试
Review Agent 独立审查 diff、证据和上游兼容性 只读
Submission Agent 生成 patch series、收件人和 cover letter 草稿 写邮件草稿，不发送

这里最容易犯的错误，是把 Patch Agent 产出的“看起来没问题”当成最终结论。真正的完成条件应该是：

复现成功
+ 修改范围合理
+ 相关测试通过
+ 独立 reviewer 没有 P0/P1 问题
+ 人工确认可提交

只要缺一项，Hermes 就不能把任务标记成 done。

数据模型

为了让系统可恢复，clawhip 应该把每个任务规范化成一个 task envelope。它不需要复杂，关键是稳定。

task_id: linux-20260615-001
source:
  platform: discord
  channel: linux-intake
  message_id: "..."
repo:
  name: linux
  upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  worktree: /srv/agent-worktrees/linux/linux-20260615-001
state: reproduce
policy:
  direct_push: false
  send_email: requires_human_approval
  max_patch_scope: single_subsystem
artifacts:
  - repro.log
  - dmesg-before.txt
  - patch-v1.diff
workers:
  triage: hermes-readonly
  patch: codex-lazycodex
  review: codex-reviewer-readonly

这个 envelope 的作用不是给人看，而是防止系统靠聊天记录维持状态。Hermes 可以压缩上下文，worker 可以重启，Discord 可以断线，但任务状态必须还在。

安全边界

对 Linux 这种上游贡献场景，最大的风险不是 agent 写错代码，而是 agent 在错误时机做了不可逆动作。

所以系统默认规则应该很硬：

  1. worker 只能在任务 worktree 写代码，不能直接改主仓库。
  2. worker 不能直接 push 到公开远端。
  3. worker 不能直接发送邮件到 LKML 或维护者列表。
  4. 所有凭据只暴露给最小必要组件，不进入普通 agent prompt。
  5. 任何带网络写入的动作都需要 Hermes gate 和人工确认。
  6. review worker 必须只读，不能修改 patch 后再自己批准。
  7. clawhip 的审计日志只能追加，不能由 worker 覆盖。

这里要把“提示词要求”升级成“运行环境限制”。不要只告诉 agent “不要 push”。应该在 shell wrapper、Git remote、权限配置和网络出口上让它做不到。

为什么 Hermes 必须是中枢

可以不用 Hermes 吗？理论上可以。你可以写一个 Discord bot，直接调 Codex CLI，再把结果贴回来。但这会把系统做成一次性胶水。

Hermes 作为中枢的价值在于四点：

第一，它是常驻 gateway。Discord、cron、webhook、CLI 都可以进入同一个 agent host，而不是散落在不同脚本里。

第二，它有长期记忆和 skills。Linux 贡献不是一次性任务。每个子系统的风格、维护者偏好、常用测试、历史失败，都应该沉淀成可复用经验。

第三，它可以统一调用多种 coding agent。Codex 擅长复杂代码修改，但有些任务可能适合只读 reviewer、专门静态分析器、本地脚本或其他模型。Hermes 负责选择，而不是让用户手选。

第四，它能处理无人值守和人工接管。夜间任务可以自动跑到 review gate，早上人只看证据和 diff。遇到不确定问题，Hermes 在 Discord 里提问，而不是让 worker 自己猜。

失败模式

这个系统不会因为用了多代理就自动可靠。相反，它的失败模式更隐蔽，需要提前设计。

第一类是任务漂移。用户说的是一个驱动错误，agent 最后变成大规模重构。解决方法是给每个任务设置修改范围和退出条件。

第二类是验证幻觉。agent 说“测试通过”，但实际只是跑了无关命令。解决方法是证据必须包含命令、退出码、日志和 artifacts，reviewer 必须能复验。

第三类是频道噪音。所有工具输出都贴到 Discord，会让人失去注意力。解决方法是 clawhip 只投递状态摘要，完整日志走 artifact。

第四类是上游礼仪错误。Linux patch 邮件格式、收件人、commit message、版本 changelog 都有习惯。解决方法是 Submission Agent 只生成草稿，并强制人工确认。

第五类是记忆污染。一次错误经验被写进长期 memory，会持续影响后续任务。解决方法是把 memory 写入放在任务结束后，由 Hermes 生成候选总结，再由人或 reviewer 接受。

最小可行部署

一个可跑的 MVP 不需要一开始就做完整平台。可以从这几个组件开始：

1. 一个 Discord server 和 #linux-lab 频道
2. 一个 Hermes gateway 进程，绑定 Discord bot
3. 一个 clawhip router，负责 task_id、event log、channel update
4. 一个 Linux bare repo + worktree 根目录
5. 一个 LazyCodex/Codex worker profile
6. 一个只读 reviewer profile
7. 一个 artifacts 目录和每日状态汇总

第一阶段只允许“生成 patch，不发送”。等复现、补丁、测试、review gate 都稳定后，再接入邮件草稿生成。最后一步才是半自动提交，而且必须保留人工确认。

如果要长期运行，还应该加上：

  1. 队列限流，避免多个大编译任务抢资源。
  2. 每任务独立容器或用户权限。
  3. artifact 保留周期和脱敏规则。
  4. 模型成本和工具耗时统计。
  5. 每周 memory review，删除错误经验。
  6. 上游反馈监控和 v2/v3 patch 版本管理。

结论

这套系统真正想解决的问题，不是让 AI “会写 Linux 代码”。强模型已经能读很多代码，也能生成相当不错的 patch。真正难的是让它在真实开源贡献流程中可控、可验证、可恢复、可审查。

Hermes 负责把人类意图变成可执行任务。clawhip 负责把事件从 agent 世界运回人类频道，同时保持上下文干净。LazyCodex 负责让 Codex 在仓库里按计划、证据和验证循环工作。Linux 贡献流程则提供了足够高的标准，迫使系统认真处理复现、最小修改、测试矩阵、邮件提交和 review 循环。

这就是上一篇 claw-code 思想的延伸：不要只盯着文件和模型输出看。真正值得设计的是那条无人盯守时仍能运行、出错时能收束、提交前能证明自己的工程流水线。

参考资料

本文整理于 2026-06-15。它是一篇系统设计稿，不构成对任何上游项目行为的自动提交建议；所有外部写操作都应经过人工确认。