Hermes Decision Trace

GanyuanRan/Aegis 项目吸收评估

对 https://github.com/GanyuanRan/Aegis 的建议是：

HTML完整论证

Wiki可检索归档

Feishu短入口交付

🎯

核心结论

对 https://github.com/GanyuanRan/Aegis 的建议是：

🧭

推荐路径

最多三条：

🛡️

关键边界

不调用真实 executor；生产动作另走审批。

关键判断

判断项	摘要
推荐方案	对 `https://github.com/GanyuanRan/Aegis` 的建议是：
关键依据	在隔离 clone 目录执行：
落地方式	最多三条：
风险边界	不跨执行边界；真实执行需另走审批。

证据摘要

在隔离 clone 目录执行：证据点 1
结果：证据点 2
注意：aegis-doctor.py --write-config 会写入 ~/.config/aegis/config.toml。本次评估发现它把本机 active config 指到了 /tmp/aegis_eval_20260529_082547/repo。这属于评估副作用，已备份并移走：证据点 3
这个副作用也说明：如果未来试用 Aegis，不能在主环境随手跑 --write-config；必须用隔离 HOME 或明确恢复配置。证据点 4

行动清单

最多三条：

建立 Aegis Partial Absorb reference，作为后续 skill 治理判例。

只补 Hermes codex-worker-routing / subagent-driven-development 里的 Evidence Card 与 Context Packet，不批量导入 Aegis skills。

如要试 project workspace，只在一个非核心项目跑隔离试点，不写全局 ~/.config/aegis。

边界 / 风险

风险点

未记录额外风险。

完整记录

本节目录结论项目定位当前 repo 事实关键验证放进 Hermes 能力地图四层审计三个专项验证最值得吸收的能力单元明确不吸收的部分和现有 Hermes 技能的关系建议吸收路线最终判断下一步动作

GanyuanRan/Aegis 项目吸收评估

结论

对 https://github.com/GanyuanRan/Aegis 的建议是：

吸收等级：L3 局部能力吸收最终决策：Partial Absorb 落点：Hermes coding-agent workflow / skill governance / project workspace discipline 停止线：不整包安装为默认 Aegis，不让它替代 Hermes 现有 skill / todo / LCM / Hindsight / project dashboard

一句话判断：

Aegis 最值得吸收的是“method-pack 治理纪律”和“runtime-ready artifact contract”，不是它的跨 host 安装壳，也不是让它成为 Hermes 的上层治理权威。

项目定位

Aegis 自己的定位很明确：

Aegis Method Pack (runtime-ready) Baseline-first, evidence-driven workflow discipline for AI coding agents.

它不是：

runtime core
daemon
agent host
authoritative GateDecision
authoritative PolicySnapshot
final completion authority

repo 中的 ADR、AGENTS.md、Runtime Ready Boundary 都反复强调：Aegis 当前只产生 drafts / hints / projections，不拥有最终治理裁决权。

这点很关键：它不是要替掉 Hermes Agent，而是给 coding agent 工作流加一层“纪律包”。

当前 repo 事实

采集时间：2026-05-29 08:27 CST

GitHub 元数据：

字段	值
Repo	`GanyuanRan/Aegis`
URL	`https://github.com/GanyuanRan/Aegis`
Description	Make AI coding agents architecture-aware: baseline-first, evidence-verified, drift-checked, and safe across long tasks.
Created	`2026-04-30T17:40:49Z`
Updated	`2026-05-28T23:19:02Z`
Pushed	`2026-05-28T09:01:57Z`
Stars	`382`
Forks	`16`
Open issues	`0`
Default branch	`main`
Language	`Shell`
License	`MIT`
Commit checked	`7f5997e8fe7b46a2567b73923463f5091fa1609b`

结构统计：

项	数量 / 内容
文件数	268
Markdown	123
Shell	55
JSON	30
Text prompts	30
Python	8
Tests	128 files
Skills	51 files
Docs	33 files

核心目录：

skills/：method-pack skills
docs/current/：当前基线与治理文档
docs/adr/：产品边界 ADR
scripts/：doctor / update / workspace helper
tests/e2e/：触发、边界、doctor、workflow quality 等检查
.claude-plugin/、.codex-plugin/、.opencode/、.cursor-plugin/ 等：跨 host 分发壳

关键验证

在隔离 clone 目录执行：

python3 scripts/aegis-doctor.py --write-config --json bash tests/e2e/aegis-doctor-check.sh bash tests/e2e/boundary-compliance-check.sh

结果：

scripts/aegis-doctor.py --write-config --json: ok=true workspaceSupport: available configStatus: configured Aegis doctor check passed. Boundary compliance check passed.

注意：aegis-doctor.py --write-config 会写入 ~/.config/aegis/config.toml。本次评估发现它把本机 active config 指到了 /tmp/aegis_eval_20260529_082547/repo。这属于评估副作用，已备份并移走：

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

这个副作用也说明：如果未来试用 Aegis，不能在主环境随手跑 --write-config；必须用隔离 HOME 或明确恢复配置。

放进 Hermes 能力地图

Aegis 在 Hermes 体系里不属于主 agent runtime，也不属于长期知识库，而属于：

coding-agent workflow governance layer + project workspace discipline sidecar + skill authoring / verification discipline reference

和现有 Hermes 关系：

Hermes 层	Aegis 关系	判断
主 agent runtime	不替代	Hermes Agent 继续作为执行主体
Skill 系统	补强	吸收部分 skill discipline 和 routing pattern
Todo / plan	补强	可借鉴 goal framing、checkpoint、resume hints
Project Dashboard	补强	可借鉴 project workspace artifact schema，但不替换 registry/dashboard
LCM / session_search	不替代	Aegis 不是 recall 系统
Hindsight / wiki	不替代	Aegis 文档记录不能成为长期知识真相源
Decision Trace	补强	可借鉴 EvidenceBundle、ImpactStatement、DriftCheck 的 contract 思路
Codex-worker routing	补强	可吸收 subagent context packet / verification-before-completion 纪律

四层审计

1. 宣称层

宣称比较克制：它说自己是 method pack，不是 runtime core。

有价值点：

baseline-first
evidence-driven
drift-checked
long task safe
skill-aware hosts 可移植
runtime-ready drafts / hints / projections

没有明显把自己夸成“全自动治理平台”。文档中反复写明不拥有 completion authority，这比很多 agent framework 更成熟。

审计结论：宣称层可信度高。

2. 实现层

真实实现以文档、skills、shell/python helper、测试夹具为主。

它的核心不是复杂程序，而是：

skill prompt / workflow discipline
doctor 检查
workspace helper
host plugin manifests
e2e shell checks
artifact schema conventions

这意味着可拆性很强。最适合吸收的是方法论和 contract，而不是代码整体依赖。

审计结论：实现层支持局部吸收，不支持整包并入 Hermes 主链。

3. 运行层

本地验证显示 doctor 和边界检查能跑通。但也暴露一个真实风险：--write-config 直接写用户级 config。

这对独立用户没问题，对 Hermes 本机生产环境不适合直接试跑。以后要验证 Aegis，应使用：

HOME=/tmp/aegis-home-xxx python3 scripts/aegis-doctor.py --write-config --json

或者先备份并恢复 ~/.config/aegis/config.toml。

审计结论：可运行，但不应直接作为本机常驻配置进入 Hermes。

4. 检索与治理层

Aegis 自身的长期沉淀方式是 repo 文档 + project-local docs/aegis/ workspace。

Hermes 已有更完整的长期治理栈：

skill
wiki
Decision Trace
Hindsight retain
project dashboard / registry
session_search / exact recall

因此 Aegis 的 project workspace 只能作为“项目内 method evidence sidecar”借鉴，不能替代 Hermes 的长期知识治理。

审计结论：只吸 schema / discipline，不迁移知识主层。

三个专项验证

1. 静态面 vs 运行面一致性

静态文档说：Aegis 是 method pack，不是 runtime core。

运行验证显示：doctor 检查的是 skill 目录、配置、workspace helper、trigger health，不启动 daemon，也不产出最终 gate decision。

判断：一致。

2. 精确回捞能力

Aegis 有 docs/aegis workspace、INDEX、artifact schema，但不是跨会话 recall 系统。它不提供 Hermes 这种 session_search / exact recall / Hindsight 查询能力。

判断：不应把它当 memory / recall 中心。

3. 降级与回退路径

Aegis 的降级方式主要是：

不启用 global rules
activation-mode explicit
TDD mode off
不创建 docs/aegis workspace
只复制部分 skills / docs 作为参考

但 --write-config 会写用户级 config，回退时要明确移除或恢复配置文件。

判断：可回退，但要隔离验证。

最值得吸收的能力单元

P0：Verification Before Completion 纪律

吸收内容：

完成前必须有 fresh verification evidence
Evidence Card：Command / Exit Status / Covered / Not Covered / Residual Risk / Confidence
不把“测试跑过”误当 completion authority
对非平凡代码改动做 Complexity Delta / residual risk

Hermes 落点：

requesting-code-review
test-driven-development
systematic-debugging
codex-worker-routing
subagent-driven-development
PR / merge / deploy 回执模板

这块和涛哥当前偏好高度一致：先验证，再说完成。

P0：Runtime-ready artifact contract

吸收内容：

TaskIntentDraft
BaselineReadSetHint
ImpactStatementDraft
EvidenceBundleDraft
TodoCheckpointDraft
ResumeStateHint
DriftCheckDraft
SubagentContextPacket

Hermes 落点：

codex-worker task contract
delegate_task context packet
project dashboard work record
Decision Trace evidence/risk section
long task handoff / resume

建议不是照搬 Aegis 字段，而是映射进 Hermes 现有 contract。

P1：Trigger Health 诊断链

吸收内容：

install/version host discovery activation/bootstrap router entry task-to-skill routing skill execution depth context pressure and re-entry false-positive over-triggering

Hermes 落点：

skill 触发失效排查
cron job skill loading 排查
gateway tool / profile routing 排查
WebUI / Feishu 多入口行为不一致排查

这比“加关键词到 description”更靠谱。

P1：Rule Layering 模型

吸收内容：

portable method rules host/profile rules repo contribution rules

Hermes 落点：

skill governance
AGENTS.md / project rules 审计
Hermes config/profile 分层
external project absorption stopline

这能减少“把某个项目里的临时规则误升成全局规则”的问题。

P1：Project Workspace advisory sidecar

吸收内容：

docs/aegis/README.md
INDEX.md
BASELINE-GOVERNANCE.md
work / plans / specs / baseline 目录结构
advisory-only 边界

Hermes 落点：

project dashboard 的项目内证据包
本地项目 incubation
长任务 evidence bundle

但要注意：Hermes 已有 /home/ht/.hermes/projects/projects.yaml 和 ~/llm-wikis，不要再引入一个平行 project truth source。

P2：多 host plugin packaging 参考

吸收内容：

.codex-plugin
.opencode
.claude-plugin
host install docs
plugin-installable 测试纪律

Hermes 落点：

如果后续要把 Hermes skills 分发给 Codex / Claude Code / OpenCode，可借鉴它的打包结构。

当前不是优先项。

明确不吸收的部分

不吸收项	原因
整包 global install	会污染本机规则层，与 Hermes skill 系统重叠
Aegis 作为默认上层 router	Hermes 已有技能路由、memory、profile 和工具体系
`~/.config/aegis` 常驻配置	评估已证明会写用户级配置，生产环境不宜默认引入
跨 host plugin 壳	当前 Hermes 不缺多 host 分发壳
`docs/aegis` 作为所有项目默认目录	会与 Hermes project registry / wiki / dashboard 形成平行系统
Aegis completion authority / gate decision	项目自己也明确不拥有该权威
Aegis memory / recall 替代	它根本不是这类系统

和现有 Hermes 技能的关系

Aegis 和 Hermes 现有 skill 有重叠：

Aegis test-driven-development vs Hermes test-driven-development
Aegis systematic-debugging vs Hermes systematic-debugging
Aegis writing-plans vs Hermes writing-plans
Aegis subagent-driven-development vs Hermes subagent-driven-development
Aegis verification-before-completion vs Hermes 多个 completion / review 规则

所以不能直接把 Aegis skills 整批导入。更好的方式是：

只抽差异点
更新 Hermes canonical skill
用 reference 记录 Aegis 来源和边界
不创建同名平行 skill

建议吸收路线

Step 1：先做 reference，不改 runtime

新增一个 Hermes reference：

external-project-absorption-eval/references/aegis-method-pack-partial-absorb-2026-05-29.md

记录：

P0/P1/P2 吸收清单
不吸收项
--write-config 副作用
Hermes 映射表

Step 2：挑 2 个 Hermes skill 做小补丁

优先补：

codex-worker-routing

加 Evidence Card / SubagentContextPacket 字段

verification / code review / subagent-driven-development 相关 skill

加 fresh verification before completion 与 residual risk 结构

不要批量改所有 skill。

Step 3：项目工作区只做试点

如果未来要试：

只在一个非核心项目里启用 docs/aegis 风格 evidence bundle
不把它提升为 Hermes 项目默认结构
观察它和 project dashboard / wiki 是否重复

最终判断

Final: Partial Absorb Level: L3 局部能力吸收 Confidence: A-

原因：

文档和实现高度一致：method pack，不是 runtime
本地 doctor / boundary checks 通过
能力单元可拆，适合进入 Hermes skill governance
与 Hermes 现有 skill 大量重叠，不适合整包安装
--write-config 有本机副作用，必须隔离验证

最终建议：

把 Aegis 当成“高质量 coding-agent workflow discipline casebook”，吸收 verification、artifact contract、trigger-health、rule-layering；不要把它当成 Hermes 的新上层控制面。

下一步动作

最多三条：

建立 Aegis Partial Absorb reference，作为后续 skill 治理判例。
只补 Hermes codex-worker-routing / subagent-driven-development 里的 Evidence Card 与 Context Packet，不批量导入 Aegis skills。
如要试 project workspace，只在一个非核心项目跑隔离试点，不写全局 ~/.config/aegis。