Aegis → Hermes 完整吸收方案与边界协议
本方案不是“安装 Aegis”,而是把 Aegis 中已经验证有价值的 method-pack 纪律吸收到 Hermes 现有体系里。
本方案不是“安装 Aegis”,而是把 Aegis 中已经验证有价值的 method-pack 纪律吸收到 Hermes 现有体系里。
建议按下面顺序实际落地:
不调用真实 executor;生产动作另走审批。
关键判断
| 判断项 | 摘要 |
|---|---|
| 推荐方案 | 建议按下面顺序实际落地: |
| 关键依据 | 见完整记录中的评分依据、状态摘要和证据链。 |
| 落地方式 | 建议按下面顺序实际落地: |
| 风险边界 | 不跨执行边界;真实执行需另走审批。 |
证据摘要
- 由 Hermes 会话生成。证据点 1
- 如涉及外部事实,应在正文中保留来源或验证路径。证据点 2
行动清单
边界 / 风险
未记录额外风险。
完整记录
Aegis → Hermes 完整吸收方案与边界协议
结论
本方案不是“安装 Aegis”,而是把 Aegis 中已经验证有价值的 method-pack 纪律吸收到 Hermes 现有体系里。
最终方案:
一句话:
Aegis 作为高质量 coding-agent workflow casebook 进入 Hermes;Aegis 不作为 Hermes 的运行时、默认路由器、记忆系统、项目管理系统或最终裁决系统进入。
背景
已完成对 GanyuanRan/Aegis 的独立评估:
- repo 已 clone 到隔离目录
- 已检查 README、docs/current、ADR、scripts、skills、tests
- 已运行 doctor / boundary 检查
- 已发布评估报告
评估结论:
因此,正确吸收方式不是安装它,而是把它的成熟治理方法拆成 Hermes 可控的局部增强。
总体吸收边界
允许吸收
| 类型 | 是否吸收 | 原因 |
|---|---|---|
| workflow discipline | 是 | 对 coding-agent 稳定性有直接收益 |
| evidence contract | 是 | 与 Hermes 验证优先偏好一致 |
| subagent context packet | 是 | 可增强 delegate / codex-worker 任务边界 |
| trigger health diagnostic chain | 是 | 可改善 skill / profile / gateway 路由排障 |
| rule layering model | 是 | 可改善 skill、AGENTS.md、项目规则分层治理 |
| project workspace advisory pattern | 有条件 | 只做 evidence sidecar 参考,不做默认项目真相源 |
| multi-host packaging pattern | 观察 | 暂不落地,未来 Hermes skills 分发时再参考 |
禁止吸收
| 类型 | 是否吸收 | 原因 |
|---|---|---|
| 整包 global install | 否 | 会引入平行 skill/rule 系统 |
| Aegis 默认 router | 否 | Hermes 已有 skill routing / profile / tools |
| Aegis runtime core 概念 | 否 | 项目自身也没有 runtime core |
| Aegis completion authority | 否 | 会越过 Hermes 和用户显式指令 |
~/.config/aegis 常驻配置 | 否 | 本次验证已证明会污染本机 active config |
docs/aegis 默认植入所有项目 | 否 | 会与 project registry / wiki / dashboard 平行化 |
| Aegis memory / recall 替代 | 否 | Aegis 不是 memory system |
| 全量导入 Aegis skills | 否 | 与 Hermes 现有 skill 大量重名/重叠 |
目标状态
吸收完成后,Hermes 应新增的是一组“纪律增强”,不是新系统。
目标状态:
非目标状态:
体系落点
| Aegis 能力 | Hermes 落点 | 吸收方式 |
|---|---|---|
| Verification Before Completion | requesting-code-review / test-driven-development / systematic-debugging / PR 回执 | 补回执结构和验证口径 |
| Evidence Card | code-review / deploy / PR / codex-worker 结果回执 | 模板化字段 |
| SubagentContextPacket | delegate_task 使用规范 / codex-worker-routing | 任务包 contract |
| TaskIntentDraft | plan / codex-worker task contract | 简化版字段 |
| BaselineReadSetHint | project incubation / codebase inspection / debugging | 读前基线提示 |
| ImpactStatementDraft | Decision Trace / architecture decision / PR review | 风险影响面模板 |
| ResumeStateHint | long task continuation / project dashboard | 恢复任务上下文 |
| DriftCheckDraft | migration drift audit / project status closure | 漂移检查模板 |
| Trigger Health | Hermes skill / cron / profile / gateway routing 排障 | 新 reference 或 skill patch |
| Rule Layering | skill governance / AGENTS.md / project rules | 治理准则 |
| Project Workspace | project dashboard evidence bundle | 非默认试点 |
分阶段执行方案
Phase 0:基线冻结与安全边界
目标:确保吸收不会污染现有 Hermes 运行态。
动作:
- 明确不运行 Aegis global install。
- 不再在主 HOME 下运行:
```bash
python3 scripts/aegis-doctor.py --write-config
```
- 如果必须运行,使用隔离 HOME:
```bash
HOME=/tmp/aegis-home-$(date +%s) python3 scripts/aegis-doctor.py --write-config --json
```
- 当前已发现并处理过一次污染:
```text
backup: /home/ht/.config/aegis/config.toml.aegis-eval-polluted-20260529_082657.bak
disabled: /home/ht/.config/aegis/config.toml.disabled-aegis-eval-20260529_082657
active_config_after: 0
```
验收:
~/.config/aegis/config.toml不指向/tmp/aegis_eval_*- Hermes config / skill / gateway 没有新增 Aegis 运行依赖
Phase 1:Reference-only 吸收
目标:先把 Aegis 作为判例和方法参考纳入 Hermes 知识体系,不改运行路径。
已完成:
建议新增或补充:
验收:
- Aegis 的吸收边界可以被后续 skill 查到
- 不出现 Aegis 与 Hermes skill 的同名平行入口
Phase 2:P0 能力吸收
目标:先吸收收益最大、风险最低的两类能力。
#### 2.1 Evidence Card 回执结构
标准字段:
进入 Hermes 的位置:
- code review 完成回执
- PR/merge/deploy 前回执
- codex-worker 执行结果
- subagent 代码任务总结
- 测试/验证类任务最终回复
边界:
- Evidence Card 是证据组织,不是 completion authority。
- 低风险短任务可以压缩成 1–2 行,不强制展开完整卡。
- 用户明确要求极简回执时,保留核心证据即可。
验收:
- 典型 coding task 结束时能看到验证命令、退出码、覆盖范围、剩余风险。
- 不再出现“看起来好了 / 应该可以”式完成声称。
#### 2.2 Subagent / Codex Worker Context Packet
标准字段建议:
进入 Hermes 的位置:
delegate_task调用前的 context 组织走 codex-worker的 task contract- 长任务切片派发
- 多 agent review / implementation 分工
边界:
- Context Packet 是输入包,不是项目状态真相源。
- 不要求所有 subagent 任务都生成文件;多数情况下只作为 prompt contract。
- 不能把整段会话塞给子 agent;只传 bounded evidence。
验收:
- 子任务上下文更短、更准,有明确 non-goals 和 stop condition。
- subagent 输出更容易验证,减少“自称完成但不可核验”。
Phase 3:P1 治理能力吸收
目标:把 Aegis 更成熟的诊断和分层治理方法融入 Hermes 运维/skill 治理。
#### 3.1 Trigger Health 诊断链
Hermes 化版本:
进入 Hermes 的位置:
hermes-skill-governance-audithermes-runtime-effect-checkhermes-cronjob-safe-update- profile / gateway / WebUI / Feishu 行为不一致排查
边界:
- 触发失效时,不允许默认“加关键词”。
- 先定位失败层,再改 owner 层。
#### 3.2 Rule Layering
Hermes 化版本:
进入 Hermes 的位置:
- skill authoring / governance
- AGENTS.md 注入规则审计
- 项目规则冲突诊断
- 外部项目吸收 stopline 判断
边界:
- 不把 repo-local 规则升级成全局 skill。
- 不把 host-specific 行为写进 portable method core。
- 用户显式指令永远高于方法包建议。
Phase 4:可选 Project Evidence Bundle 试点
目标:只在一个非核心项目里试 docs/aegis 风格 evidence bundle,看是否增强项目连续性。
建议试点对象:
- 不选 Hermes 主仓
- 不选 gateway / config 敏感项目
- 选一个低风险、任务边界清晰、需要多轮推进的小项目
目录可参考,但不照搬为标准:
Hermes 化边界:
docs/aegis是项目内证据包,不是项目 registry。- 项目状态仍以
/home/ht/.hermes/projects/projects.yaml和 project dashboard 为准。 - 长期知识仍进 wiki / skill / Hindsight。
- Decision Trace 仍负责决策归档。
验收:
- 是否减少长任务恢复成本
- 是否减少“项目状态散落在聊天里”
- 是否与现有 wiki/dashboard 重复
- 如果重复度高,停止试点,不推广
具体改造清单
必做 P0
| 编号 | 改造项 | 文件 / skill | 类型 | 风险 |
|---|---|---|---|---|
| P0-1 | 增加 Evidence Card 回执规范 | code-review / TDD / debugging 相关 skill | skill patch | 低 |
| P0-2 | 增加 SubagentContextPacket 精简 contract | subagent-driven-development | reference + skill patch | 低 |
| P0-3 | 增加 codex-worker task contract 字段 | codex-worker-routing | reference + skill patch | 中低 |
应做 P1
| 编号 | 改造项 | 文件 / skill | 类型 | 风险 |
|---|---|---|---|---|
| P1-1 | Trigger Health Hermes 化 | skill governance / runtime effect check | reference | 低 |
| P1-2 | Rule Layering Hermes 化 | skill lifecycle governance | reference | 低 |
| P1-3 | 将 Aegis 判例纳入 casebook | external-project absorption casebook | reference index | 低 |
可选 P2
| 编号 | 改造项 | 文件 / skill | 类型 | 风险 |
|---|---|---|---|---|
| P2-1 | project evidence bundle 试点 | 某个非核心项目 | trial | 中 |
| P2-2 | 多 host plugin packaging 观察 | 暂无 | watch | 低 |
验收标准
整体吸收不能以“写了方案”算完成,必须满足下面标准。
功能验收
- Hermes 现有 skill 没有出现 Aegis 同名平行 skill。
- codex-worker / delegate task 任务包能表达 goal、stop condition、known facts、unknowns、non-goals、verification expected。
- coding task 完成回执至少包含验证证据和 residual risk。
- skill 触发问题有 Trigger Health 诊断链可用。
边界验收
- 没有新增
~/.config/aegis/config.tomlactive 依赖。 - 没有把 Aegis 作为默认 router。
- 没有把
docs/aegis写入 Hermes 主项目或所有项目。 - 没有把 Aegis 文档当长期知识真相源。
- 没有让 Aegis 产生 completion authority。
回归验收
- 相关 Hermes skill frontmatter audit 通过。
- 修改后的 skill 可被
skills_list/skill_view正常读取。 - 若 patch 影响 codex-worker,跑最小 codex-worker dry contract 检查。
- 若 patch 影响 subagent,跑一个 no-side-effect delegate packet 样例验证。
风险与对策
| 风险 | 表现 | 对策 |
|---|---|---|
| 规则膨胀 | 简单任务也被强制走复杂流程 | fast-path 保留,Evidence Card 可压缩 |
| 平行系统 | Aegis skill 与 Hermes skill 同名共存 | 禁止全量导入,只 patch canonical Hermes skill |
| 配置污染 | ~/.config/aegis 指向临时 repo | 不运行 global write-config;必要时隔离 HOME |
| 过度治理 | workflow 成本高于任务收益 | 按风险分层:low / medium / high |
| 知识分裂 | docs/aegis、wiki、dashboard 各说各话 | docs/aegis 只做 evidence sidecar,wiki/dashboard 仍为主 |
| 权威越界 | verification 被误当 final authority | 明确 evidence ≠ completion authority |
停止线
出现以下任一情况,停止吸收,不继续推进:
- 需要把 Aegis 整包安装进主 HOME。
- 需要让 Aegis 接管 skill routing。
- 需要把 Aegis workspace 设为项目默认真相源。
- 需要让 Aegis 输出 gate decision / completion authority。
- 修改导致简单任务明显变慢或回复明显变重。
- 与 Hermes 现有 skill / wiki / Hindsight / project dashboard 形成长期重复。
推荐执行顺序
建议按下面顺序实际落地:
不要一次性大改所有 skill。
最终边界声明
Aegis 进入 Hermes 的身份是:
Aegis 不进入 Hermes 的身份是:
最终建议:
做小、做准、做进现有 canonical skill;不要新建一套 Aegis-Hermes 平行治理系统。
关联记录
- 评估报告:
/home/ht/llm-wikis/knowledge-ops/queries/aegis-absorption-evaluation-2026-05-29.md - HTML:<https://decision.ht1072.top/2026-05-29-aegis-absorption-evaluation.html>
- Reference:
/home/ht/.hermes/skills/integration/external-project-absorption-eval/references/aegis-method-pack-partial-absorb-2026-05-29.md
更新时间:2026-05-29 08:45:47 CST