Hermes vs Google SRE Agentic Incident Response
Summary
本页源于 2026-04-16 的 Hermes/SRE 对照讨论。可复用的问题是：通用 AI Agent 接入事故响应时，需要怎样的领域工具、动作约束、审批与复盘边界？Google 案例提供事故响应模式；本仓库提供知识组织设计。两者不能合并成 Hermes 原生能力清单，也不足以支持产品优劣排名。
Evidence scope
- 来源案例：google-sre-gemini-cli-incident-response 基于其公开文章快照，描述 Gemini CLI 参与事故响应的模式；这里复述的是来源案例，不核验当前产品能力。
- 仓库设计：hermes-knowledge-architecture 与 hermes-knowledge-base-operating-flow 说明本 Wiki 的知识分层与维护流程；它们不是 Hermes 产品接口的证据。
- 采用建议：下面的通用 Agent 映射均为
[推论]，不表示某个 Hermes 实例已部署，也不构成执行授权。
旧版将“工具更多”“知识沉淀更强”“缺少专用事故层”等定性判断写成 Hermes 当前事实，但没有相同任务、版本、配置和验收口径下的可复验证据。本次撤回这些能力与排名断言；历史文本由 Git 保留。不能仅加历史日期，就把无依据的判断变成可信历史事实。
Comparison by design responsibility
| 维度 | Google 来源案例描述 | 通用 Agent 接入时需验证的职责 [推论] |
|---|---|---|
| 目标 | 优先缓解用户受损，再做根因、修复与复盘 | 明确事故目标与验收，不以工具调用成功代表事故已缓解 |
| 工具 | 以 playbook、指标、日志分析等领域接口组织上下文 | 核对目标部署实际可用的只读数据与领域工具；不假定工具名相同 |
| 动作空间 | 将重启、回滚、流量切换、扩容等纳入有限缓解集合 | 按目标系统定义受限动作、输入校验与停止条件 |
| 权限与安全 | 受约束工具、风险标记、策略、人类批准和审计 | 分别验证建议、授权和执行；通用命令审批不等于事故专用策略 |
| 外部接入 | 文章讨论通过 MCP 接入监控及运维系统 | 优先复用已授权 API、CLI 或连接器；MCP 是可选实现 |
| 复盘 | 将修复、postmortem 与 action items 纳入流程 | 私有事故记录留在原系统，公开可复用结论经准入后才进 Wiki |
表中第一列事实范围由来源案例限定，第二列是待验证的设计要求。它不说明 Hermes 或其他产品已经实现、缺少或优于某一项。
Knowledge ownership
本仓库的 raw/、正式页面、index.md、log.md 和 SCHEMA.md 共同承担公开知识维护。Wiki 是这套仓库设计的正式知识层，不是由某个 Agent 品牌自动提供的原生功能。
[推论] 对事故响应，至少区分三类内容：
- 当前告警、指标、日志与处置进度：读取目标系统的实时证据。
- 私有事故时间线、授权与执行记录：留在获授权的项目或事故系统。
- 脱离具体实例仍成立的公开方法：按 wiki-ingestion-workflow 编译到现有知识页。
拥有上述知识组织方式，不能证明某产品的 postmortem 能力更强；同样，文章未描述某能力，也不能证明产品不具备它。
Adoption checks
[推论] 若将此模式用于 Hermes 或其他 Agent，应先完成以下核对：
- 明确目标版本、部署环境、现有工具与数据访问授权。
- 选一个有现成 playbook 的窄场景，定义只读取证和允许提议的动作。
- 验证策略、审批、执行回读、失败处理与回滚，而不是只确认工具可调用。
- 以目标项目的实际结果判断是否值得推广，不从本文推断已有生产能力。
- 方法稳定且有对应授权时才考虑调度、通知或其他外部写操作。
本页不提供当前 Hermes 命令、审批 API、内置工具或默认配置清单；采用具体接口时须另查对应版本的官方资料与实际工具列表。
Relations
- depends_on: google-sre-gemini-cli-incident-response
- depends_on: hermes-knowledge-architecture
- depends_on: hermes-knowledge-base-operating-flow