krisolo/boss
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
39be49630f7068daa1c92db5e5c9b00399f61da4
boss/docs/architecture/hermes_对_boss_主agent长期融合评估_cn.md

26 KiB
Raw Blame History

Hermes 对 Boss 主 Agent / 业务流的长期融合评估

更新时间：2026-04-14

1. 文档目标

这份文档回答四个问题：

  1. Hermes 对 Boss 主 Agent 的长期参考价值是什么
  2. 哪些能力值得抽象进 Boss 内核，哪些不要借
  3. 第二阶段与第三阶段建议路线
  4. 风险、边界和升级策略

这不是一份“把 Hermes 整体接进 Boss”的实施说明，而是一份长期架构判断文档。结论基于以下输入：

  • Boss 当前运行真相与既有融合策略：
    • docs/architecture/boss_external_runtime_fusion_strategy_cn.md
    • docs/architecture/current_runtime_and_deploy_status_cn.md
    • docs/architecture/api_and_service_inventory_cn.md
    • docs/superpowers/specs/2026-04-14-hermes-backend-mvp-design.md
  • Boss 当前 Hermes MVP 实现：
    • src/lib/execution/backends/hermes-config.ts
    • src/lib/execution/backends/hermes-runner.ts
    • src/lib/execution/backends/hermes-backend.ts
    • src/lib/execution/backend-selector.ts
    • 对应 Web 控制与测试文件
  • Hermes 官方公开文档：
    • README: https://raw.githubusercontent.com/NousResearch/hermes-agent/main/README.md
    • Quickstart: https://hermes-agent.nousresearch.com/docs/getting-started/quickstart/
    • Architecture: https://hermes-agent.nousresearch.com/docs/developer-guide/architecture/
    • Session Storage: https://hermes-agent.nousresearch.com/docs/developer-guide/session-storage/
    • Tools & Toolsets: https://hermes-agent.nousresearch.com/docs/user-guide/features/tools/
    • ACP: https://hermes-agent.nousresearch.com/docs/user-guide/features/acp/
    • API Server: https://hermes-agent.nousresearch.com/docs/user-guide/features/api-server/
    • Security: https://hermes-agent.nousresearch.com/docs/user-guide/security/
    • Honcho Memory: https://hermes-agent.nousresearch.com/docs/user-guide/features/honcho/

2. 证据边界

本次评估有一个必须显式写清楚的边界：

  • 用户指定优先阅读的 /tmp/hermes-agent/README.md、/tmp/hermes-agent/docs/acp-setup.md、/tmp/hermes-agent/docs/honcho-integration-spec.md 在当前工作机上不存在，未能读取。
  • 因此，本文对 Hermes 的判断以 Boss 仓库内已落地的 Hermes MVP 实现，加上 Hermes 官方公开文档为主。
  • 这意味着本文对“上游最近几次提交中的未发布细节”不做强判断，只对已经稳定公开、且确实会影响 Boss 长期架构边界的能力做判断。

换句话说，这份文档适合指导 Boss 第二阶段、第三阶段的融合方向，但不应被当成对 Hermes 私有或未发布能力的最终定论。

3. 当前状态判断

3.1 Boss 侧当前已经做了什么

Boss 已经不是“讨论要不要接 Hermes”的阶段，而是已经完成了一个最小接入：

  • 在 src/lib/execution/ 下已经形成稳定执行底座
  • Hermes 当前以 hermes-runtime 的形式进入 ExecutionBackend
  • 接入范围目前只覆盖 master-agent 的执行后端选择
  • 运行方式是外部命令调用，不 import Hermes Python 代码
  • 当前契约本质上仍是 one-shot：
    • Boss 组装 prompt
    • 调用 Hermes CLI
    • 读取 stdout
    • 去掉 session_id
    • 将正文作为回复写回 Boss

这说明 Boss 当前的判断是对的：先把 Hermes 放在执行层适配器位置，而不是把它当成 Boss 产品层替代物。

3.2 Hermes 上游真正强在哪里

基于官方文档，Hermes 的强项不是 Boss 已经做得好的产品域，而是以下几层：

  • 成熟 agent loop
    • Hermes 官方架构文档明确把核心对话循环、工具注册、provider 解析、session 存储、gateway、ACP 都做成了一套统一 runtime。
  • 丰富的工具与 toolset 体系
    • 官方架构文档写明 Hermes 当前注册了 47 个工具、19 个 toolset，terminal 工具支持 6 种 backend；官方工具文档同时说明这些能力可以按平台启停，并支持 MCP 动态扩展。
  • 持久 session 与可检索历史
    • 官方 session storage 文档说明 Hermes 用 SQLite + FTS5 持久化会话元数据、消息历史和 lineage。
  • 多入口但共享同一运行时
    • CLI、gateway、ACP、API server 共用 provider / tool / state 基础设施；其中 API server 还可以把 Hermes 暴露成 OpenAI-compatible HTTP endpoint。
  • 安全和审批模型
    • 官方 security 文档明确有危险命令审批、容器隔离、MCP 凭据过滤、context file 扫描。
  • 长期记忆体系
    • 官方 Honcho 文档说明 Hermes 不只有本地 memory 文件，还有 memory provider plugin；Honcho 以插件形式提供更深的用户建模和跨 session 结论归纳。
  • 子代理与并行执行
    • README 和工具文档都把 delegation、code execution、cron 作为一等能力。

因此，Hermes 对 Boss 的长期价值，主要不是“多一个能跑的 CLI”，而是“提供一套已经在执行层、会话层、工具层、权限层成型的 agent runtime 参考系”。

4. 总结论

一句话结论：

  • Hermes 对 Boss 主 Agent 的长期参考价值很高
  • 但它更适合作为 Boss 的“执行内核候选 + 运行时能力参考系”
  • 不适合作为 Boss 的“产品骨架、业务状态源或编排真相”

进一步展开：

4.1 Hermes 的长期参考价值是什么

Hermes 对 Boss 的长期价值主要有五层。

第一层：验证 Boss 的执行抽象方向是对的

Boss 已经抽出了 ExecutionBackend / PromptAssembler / PermissionPolicy / RemoteRuntimeAdapter / OrchestrationBackend。Hermes 官方架构恰好证明了这条路是对的：

  • provider 解析可以独立
  • tool registry 可以独立
  • session persistence 可以独立
  • UI / gateway / ACP 只是不同入口，不应倒逼业务层重塑

这意味着 Boss 继续把“业务层稳定、运行时可替换”做深，是有上游现实参照的。

第二层：给 Boss 主 Agent 提供更强的执行上限

Boss 当前默认主链仍偏“Boss 产品逻辑 + 外部执行通道”。Hermes 提供的是一个更完整的 agent runtime：

  • 工具选择能力更强
  • 文件 / 终端 / 浏览器 / MCP / delegation 能力更全
  • 记忆、session search、skills、approval 都在一个 runtime 内

对 Boss 主 Agent 来说，这意味着未来可以把复杂任务逐步从“Boss 先做大量业务编排，再找后端执行一句 prompt”提升到“Boss 给出业务边界，Hermes 在边界内自主完成更多工作”。

第三层：帮助 Boss 定义“会话级执行”的中间层

Boss 当前 Hermes MVP 还是 one-shot，但 Hermes 官方文档显示它天然具备：

  • session 持久化
  • lineage
  • ACP 会话管理
  • API server
  • gateway 统一 routing

这对 Boss 很重要，因为 Boss 以后一定会遇到“主 Agent 到底是一次性回答，还是持续工作中的 agent session”这个问题。Hermes 不能直接成为 Boss 的 session 真相，但它是一个很好的 session 能力参考实现。需要额外注意的是，官方 ACP 文档明确说明 ACP 的 list/load/resume/fork 只在当前 ACP server 进程存活期间有效，这再次证明它更适合作为执行入口参考，而不是 Boss 的长期会话真相。

第四层：为 Boss 的工具能力治理提供成熟参照

Hermes 的 toolset 分组、审批、安全边界、terminal backend 分层都很成熟。Boss 不一定要照搬工具名和实现，但值得吸收它的治理模型：

  • 工具不是平铺权限，而是按风险级别和运行场景分层
  • 本地、容器、SSH、云执行是同一工具能力的不同 backend
  • 审批与持久 allowlist 是 runtime 级能力，而不是前台零散开关

这正是 Boss 后续把主 Agent 从“能说”升级到“能稳定干活”时最需要的部分。

第五层：提供“可升级外部 runtime”的实际样板

Hermes 不只是功能点集合，它还是一个活跃上游。Boss 如果能把 Hermes 视作“外部 runtime 插件族”之一，而不是一次性集成项目，那么 Boss 未来可以用相同方法吸收：

  • Hermes
  • Claw
  • OMX
  • 其他 ACP / API / CLI agent runtime

这会让 Boss 逐步形成自己的执行生态，不再被某一个上游实现绑死。

5. 哪些能力值得抽象进 Boss 内核

这里的原则不是“哪个能力厉害就搬哪个”，而是：

  • 只抽象 Boss 必须长期拥有主导权的层
  • 只抽象对多个 runtime 都成立的层
  • 只抽象不会把 Boss 业务真相外包给 Hermes 的层

5.1 值得抽象进 Boss 内核的能力

5.1.1 Runtime Capability Profile

Boss 现在已经有 backend selectable / availability，但还不够系统。应该继续抽象成统一的 runtime capability profile，例如：

  • 是否支持 one-shot
  • 是否支持 session resume
  • 是否支持 delegation
  • 是否支持 toolsets
  • 是否支持 structured approval
  • 是否支持 remote terminal backend
  • 是否支持 memory provider
  • 是否支持 MCP

原因：

  • 这是 Boss 做“后端选择、灰度、回退、UI 呈现”的稳定基础
  • 这层应该由 Boss 控制，不应把 Hermes 的内部概念直接泄漏到前台

5.1.2 Session Binding Interface

Boss 现在把 Hermes session_id 去掉是对的，但长期不能永远停在这里。应该抽象一层通用 session binding interface，而不是 Hermes 专用字段：

  • createSession
  • resumeSession
  • closeSession
  • sessionMetadata

原因：

  • 未来不止 Hermes 会有 session
  • Boss 需要控制“哪个业务项目/线程绑定哪个 runtime session”
  • 但 session 的生命周期必须由 Boss 业务事件驱动，而不是由 Hermes 自己的 SQLite 状态反向决定

5.1.3 Tool Capability Registry

Boss 现在有 ToolRegistry 雏形，但后续应该升级成“工具能力注册表”，重点不是工具实现，而是能力治理：

  • 能力类别
  • 风险等级
  • 是否需要审批
  • 哪些 runtime 支持
  • 哪些业务场景允许

原因：

  • Hermes 的 toolsets 给了很好的上游样板
  • Boss 必须把“业务权限”与“runtime 工具能力”中间再插一层自己的治理

5.1.4 Permission Policy 到 Runtime Policy 的映射层

Hermes security 文档说明审批、安全扫描、allowlist 是 runtime 一等能力。Boss 也需要形成自己的 policy mapping 层：

  • Boss 业务策略：
    • 这个项目允许不允许写文件
    • 当前群聊是否允许直接 dispatch
    • 当前设备是否允许远程终端
  • Runtime 执行策略：
    • Hermes toolsets 开哪些
    • Hermes terminal backend 用本地还是 SSH
    • 需要哪些审批模式

原因：

  • 这是 Boss 产品真相和 Hermes runtime 真相之间最关键的隔离层

5.1.5 记忆分层接口

Boss 不应该直接吃 Hermes 的记忆文件或 Honcho 结构，但应该把“Boss 业务记忆”和“外部 runtime 记忆能力”拆分成两层：

  • Boss 业务记忆：
    • 项目目标
    • 项目记忆
    • 线程状态文档
    • 最近进展事件
    • 用户级主 Agent 偏好
  • 外部 runtime 记忆：
    • Hermes local memory
    • session search
    • Honcho profile / context

Boss 内核需要的是统一接口，而不是固定供应商实现。

5.1.6 Runtime Health / Fallback / Telemetry

Hermes 当前已经接入 availability 与 fallback，但长期应升级成统一能力：

  • 启动健康探测
  • capability 探测
  • 最近失败原因
  • 版本信息
  • smoke 测试结果
  • 自动回退规则

原因：

  • 这决定 Boss 是否能安全地长期吸收外部 runtime 的升级成果

5.2 有条件再考虑、但现在不该内核化的能力

5.2.1 Delegation / Subagent Contract

Hermes 的 delegation 很强，但 Boss 现在不该直接把“子代理体系”写死进内核。更合理的做法是：

  • 第二阶段只把它视为 runtime capability
  • 第三阶段再评估是否需要 Boss 自己定义统一 subagent contract

因为一旦定义过早，就容易被某个 runtime 的行为模型绑死。

5.2.2 Memory Provider Plugin

Hermes 已经有 memory provider plugin 和 Honcho。Boss 长期可以参考“memory provider 可插拔”这个方向，但不建议在第二阶段就把 Boss 记忆系统插件化。当前 Boss 的项目理解、线程状态文档、进展事件还在快速演化，过早插件化会锁死模型。

6. 哪些能力不要借，或者只可作为外部能力存在

这里是最重要的边界。Hermes 很强，但 Boss 不能被 Hermes 反向塑形。

6.1 不要借来当 Boss 产品骨架的能力

6.1.1 Gateway / 多平台消息入口

Hermes 有 CLI、Telegram、Discord、Slack、WhatsApp、Signal、Email、API server、ACP 等多入口能力，但 Boss 不应该把这些入口当作自己的前台路线。

原因：

  • Boss 已经有 Web / Android / local-agent / 群聊 / 审批 / 设备导入等产品主链
  • 如果把 Hermes gateway 当成 Boss 主入口，产品模型会被即时通讯平台语义反向塑形

判断：

  • 可以作为外部执行入口参考
  • 不应该成为 Boss 主业务入口

6.1.2 Hermes 的 SQLite Session Store

Hermes 官方 session storage 很成熟，但 Boss 不能把它当成业务真相库。

原因：

  • Boss 的真相不是“agent 对话历史”这么简单
  • Boss 还有项目、线程、设备、审批、群聊、导入、记忆、账本、投影视图
  • 一旦让 Hermes state.db 成为真实会话源，Boss 会失去对业务生命周期的主导权

判断：

  • 可以参考 schema 和 lineage 思路
  • 不能作为 Boss 核心账本或主状态库

6.1.3 Honcho 用户建模作为 Boss 主记忆

Honcho 的优势是跨 session、跨设备、跨 peer 的用户建模，但 Boss 不能直接拿它替代自己的主 Agent 记忆体系。

原因：

  • Boss 关心的是业务记忆，不只是人格/偏好/沟通风格
  • Honcho 适合“用户画像 + 深层偏好”
  • Boss 更需要“项目事实、线程事实、设备事实、审批事实”

判断：

  • 可以作为外部补充记忆源
  • 不能成为 Boss 记忆主真相

6.1.4 ACP Session Manager 语义

Hermes ACP 文档明确说 ACP 会话只在 ACP server 进程存活期间有效，list/load/resume/fork 也限定在该 server 生命周期内。

这对 Boss 来说只能作为编辑器集成参考，不能直接拿来做主 Agent 长期会话模型。

原因：

  • Boss 会话生命周期是业务驱动，不是 editor server 驱动
  • ACP 进程级 session manager 太短命

6.1.5 Cron 与平台投递系统

Hermes 自带 cron 调度和任意平台投递，但 Boss 当前不应该把这部分纳入主 Agent 内核。

原因：

  • Boss 当前最核心的问题是执行层、业务状态、审批和项目理解，不是调度器丰富度
  • 过早接入 cron 会把“任务调度”和“业务执行”耦合

判断：

  • 可作为未来运维或后台任务参考
  • 不应进入第二阶段主线

6.2 不要照搬的设计风格

6.2.1 不要把 Hermes 的工具名和 slash command 暴露成 Boss UI 概念

Boss 前台不应该出现：

  • toolsets
  • session_search
  • honcho_profile
  • delegate_task
  • allow once / allow always

这类原生 Hermes 概念可以存在于适配层和运维界面，但不应直接成为 Boss 面向用户的产品语言。

6.2.2 不要让 Hermes 的 context files 决定 Boss 提示词层级

Hermes 有自己的 context files / skills / memory 注入方式。Boss 不能因此削弱现有的：

  • 管理员全局主提示词
  • 用户私有主提示词
  • 当前对话附加提示词
  • 项目记忆
  • 线程状态文档

Boss 的提示词优先级必须继续由 Boss 掌控。

7. 第二阶段建议路线

第二阶段的关键词不是“接更多功能”，而是“把 Hermes 从最小可用后端升级成可长期运营的受控后端”。

7.1 第二阶段目标

目标应收敛为三件事：

  1. 把 Hermes 从 demo 级 one-shot backend 升级为受控运行时后端
  2. 让 Boss 对 Hermes 的能力感知、配置、回退、观测更完整
  3. 仍然不让 Hermes 进入 Boss 编排层与业务真相层

7.2 第二阶段建议任务

7.2.1 补齐 Runtime Capability Profile

为 Hermes 增加稳定 capability 描述，而不是只暴露 selectable / reasonLabel：

  • supportsOneShot
  • supportsSessionResume
  • supportsDelegation
  • supportsToolsets
  • supportsMemoryProvider
  • supportsMcp
  • supportsApprovalBridge
  • supportsRemoteTerminal

这样 Boss 后续前台、策略、实验、灰度都能统一处理。

7.2.2 引入最小 Session Metadata 捕获，但不直接业务化

建议第二阶段开始捕获 Hermes session_id，但只作为内部诊断元数据，不立刻绑定业务主链：

  • 记录最近一次执行返回的 session_id
  • 记录 Hermes command/model/toolsets/skills
  • 记录运行耗时、退出码、fallback 原因

不做：

  • 不做 Boss 项目线程到 Hermes session 的强绑定
  • 不做 resume 主链

这样能为第三阶段做准备，但不会过早扩大范围。

7.2.3 做一层 Boss -> Hermes policy mapping

把 Boss 的业务约束映射成 Hermes 运行时约束：

  • 项目级只读 / 可写
  • 是否允许 terminal
  • 是否允许 web / browser
  • 是否允许 delegation
  • 是否允许外部 MCP

第二阶段可以先从静态配置开始，不必一开始就做动态全量映射。

7.2.4 建立 Hermes 专属 smoke / health / version 检查

当前 availability 只检查命令、cwd、脚本存在。第二阶段应该加入：

  • hermes --version 或等价 version check
  • 最小真实 prompt smoke
  • toolset 启动 smoke
  • provider 可用性检查
  • 可选的 API server / ACP 旁路探测

这会把“能选”升级成“可运营”。

7.2.5 限定场景开展 A/B 对照实验

第二阶段只建议在主 Agent 的少数高价值场景做 Hermes 对照：

  • 长提示词理解
  • 需要文件/终端/浏览器联动的问题
  • 需要多步工具执行的问题
  • 需要更强自主探索的问题

不要一上来把所有主 Agent 请求默认切到 Hermes。

7.3 第二阶段明确不做

  • 不接 dispatch_execution
  • 不接群聊编排
  • 不接设备导入审核链
  • 不接 Honcho 作为 Boss 默认记忆
  • 不接 ACP 成为 Boss 主前台
  • 不把 Hermes API server 暴露成 Boss 对外 API 主链

8. 第三阶段建议路线

第三阶段的关键词是“选择性深化”，不是“全面融合”。

8.1 第三阶段前提

只有在第二阶段满足以下条件后，才建议进入第三阶段：

  • Hermes 后端运行稳定
  • fallback 和 kill switch 可靠
  • Boss 已形成 capability / policy / telemetry 的统一抽象
  • 已明确哪些任务在 Hermes 上明显优于当前默认后端

8.2 第三阶段可以做什么

8.2.1 引入 Session-Aware Backend Contract

如果第二阶段观察证明 Hermes 在持续任务里明显更有优势，第三阶段可以升级为 session-aware backend：

  • Boss 为项目或线程保存 runtime session binding
  • 支持显式 resume / compact / close
  • 主 Agent 在少数项目上变成“持续运行的工作线程”

但必须坚持：

  • Boss 决定何时创建、恢复、关闭
  • Hermes 不直接拥有业务生命周期

8.2.2 选择性开放 Delegation

第三阶段可以考虑让 Hermes delegation 进入 Boss，但只作为受限能力：

  • 只在主 Agent 内部使用
  • 只对特定项目开放
  • 必须经过 Boss policy 层约束
  • 子代理产物回写必须标准化

换句话说，Boss 可以借 Hermes 的“多步执行能力”，但不能把 Boss 的编排主权交给 Hermes。

8.2.3 引入可插拔 Memory Provider Adapter

第三阶段可以评估把 Honcho 或其他 memory provider 作为外部补充记忆源接入：

  • 用于用户偏好、工作习惯、长期画像
  • 不用于项目事实和审批真相

Boss 应保持“双层记忆”：

  • Boss 事实记忆
  • 外部推理型记忆

8.2.4 评估 ACP / API Server 作为受控旁路入口

如果未来 Boss 需要编辑器直连、桌面 IDE 集成或本地私有 agent service，第三阶段可以评估：

  • ACP 作为开发态集成通道
  • Hermes API server 作为受控本地后端

但必须保持：

  • Boss 是业务真相层
  • ACP / API server 只是执行入口

8.3 第三阶段仍然不要做什么

  • 不让 Hermes 替代 Boss 群聊编排
  • 不让 Hermes 替代 Boss 审批流
  • 不让 Hermes 替代 Boss 设备导入逻辑
  • 不让 Hermes state.db 替代 Boss 状态账本
  • 不让 Hermes gateway 替代 Boss Web / Android 产品层

9. 风险与边界

9.1 最大风险：上下文主权混乱

Boss 有自己的 prompt、memory、project understanding、thread status。Hermes 也有：

  • system prompt
  • skills
  • MEMORY / USER
  • Honcho
  • context files
  • session search

如果不加边界，很容易出现：

  • Boss 明明要求 A
  • Hermes 自己的 memory / skill / context file 又暗示 B
  • 最终输出谁在主导不清楚

所以必须坚持：

  • Boss 决定业务上下文主权
  • Hermes 只在 Boss 明确授权的范围内做 agentic 执行

9.2 第二大风险：权限模型不一致

Boss 的审批流是业务审批，Hermes 的 approval 是 runtime 审批。这两者不是一回事。

如果直接混用，会出现：

  • Boss 以为“已批准执行”
  • 但 Hermes 还在等危险命令批准

或者：

  • Hermes 因本地 allowlist 放过了命令
  • Boss 却并未允许该业务动作

因此必须分层：

  • Boss 负责业务许可
  • Hermes 负责运行时危险动作许可
  • 中间靠 policy mapping 对齐

9.3 第三大风险：状态与观测割裂

如果 Hermes 执行内部发生：

  • 自动记忆写入
  • session 压缩
  • subagent delegation
  • tool 失败重试

但 Boss 只能看到最终一段 stdout，那么 Boss 无法做审计、归因和用户解释。

因此长期必须补：

  • 最小运行元数据
  • 最小工具活动摘要
  • 明确失败分类

但这不等于把 Hermes 全量内部日志搬进 Boss。

9.4 第四大风险：运维依赖扩张

Hermes 引入的是一整套 Python runtime、provider 凭据、tool dependencies、MCP、optional extras。对 Boss 来说，这会带来：

  • 安装复杂度增加
  • 服务器镜像和本地设备环境差异
  • 版本升级不一致
  • provider 凭据与 Boss 账号配置割裂

所以 Hermes 长期必须维持“可选、可探测、可回退”，不能成为 Boss 单点依赖。

9.5 第五大风险：成本和上下文膨胀

Hermes 的强项也是风险点：

  • 更强工具调用
  • 更多记忆注入
  • session search
  • Honcho
  • delegation

这些能力如果没有边界，会直接带来更高 token 成本和更长响应尾延迟。Boss 当前主 Agent 的部分场景并不需要这么重。

10. 升级策略

10.1 采用“能力 checkpoint”而不是“整仓跟随”

不要用“Boss 跟随 Hermes 最新版”这种策略，而要用能力 checkpoint：

  1. 选定一个 Hermes 版本
  2. 验证一组 Boss 关心的能力：
    • CLI one-shot
    • model/provider 解析
    • toolsets
    • approvals
    • session metadata
    • optional MCP
  3. 通过后才升级 Boss 适配层

这能避免 Boss 被 Hermes 高频演进拖着走。

10.2 维持严格的单向边界

推荐长期坚持以下边界：

  • Boss -> Hermes：
    • ExecutionRequest
    • policy 映射后的 runtime config
    • 明确的 prompt 与 memory 注入
  • Hermes -> Boss：
    • 标准化结果
    • 最小 session metadata
    • 最小 telemetry

不要让 Boss 直接依赖：

  • Hermes 内部 SQLite schema
  • Hermes 内部 Python 类
  • Hermes 内部工具注册过程

10.3 先扩可观察性，再扩能力

每一次升级顺序都应是：

  1. 先补 health / telemetry / fallback
  2. 再开放新能力

例如：

  • 想接 session resume，先能看见 session 元数据
  • 想接 delegation，先能看见子任务摘要和失败分类
  • 想接 Honcho，先定义 Boss 侧的记忆归属边界

10.4 始终保留 kill switch

Hermes 长期必须是可关闭的：

  • 配置级关闭
  • 项目级关闭
  • 运行时自动回退
  • 前台明确提示回退原因

这是 Boss 能放心吸收外部 runtime 的前提。

10.5 用受控试点项目推进，而不是全局切换

升级节奏建议：

  • 只在 master-agent 的少量项目启用
  • 先对复杂任务启用
  • 按项目或账号白名单试点
  • 保留默认后端作对照

Boss 不应该出现“大版本直接切 Hermes 为默认”的动作。

11. 最终判断

11.1 长期定位

Hermes 在 Boss 中的长期定位应是：

  • 第一身份：执行 runtime 候选
  • 第二身份：运行时抽象设计参考
  • 第三身份：未来 session-aware agent backend 候选

而不是：

  • Boss 产品层替代者
  • Boss 编排层替代者
  • Boss 状态账本替代者

11.2 值得吸收的核心东西

Boss 最值得从 Hermes 吸收的，不是某个具体命令，而是这四个长期结构：

  • runtime capability 分层
  • tool / approval / backend 的统一治理
  • session-aware agent runtime 的中间层设计
  • 业务真相与外部 runtime 分离的架构纪律

11.3 不该动摇的 Boss 主权

Boss 必须继续自己掌握：

  • 会话与项目模型
  • 群聊与审批
  • 设备导入
  • 业务记忆与线程状态文档
  • 用户可见产品语言
  • 账本与聚合投影视图

Hermes 可以把 Boss 主 Agent 变强，但不应该把 Boss 变成 Hermes 的 UI 外壳。

12. 建议的下一步

建议按优先级做三件事。

12.1 先做一份第二阶段实施设计

主题应收敛为：

  • Hermes Runtime Capability / Policy / Telemetry 第二阶段设计

只覆盖：

  • capability profile
  • session metadata 捕获
  • policy mapping
  • smoke / health / version 探测
  • telemetry 与 fallback

不扩大到 dispatch、群聊、Honcho。

12.2 补齐真实上游证据

等 /tmp/hermes-agent 可用后，重新核对：

  • README.md
  • docs/acp-setup.md
  • docs/honcho-integration-spec.md

重点看是否存在与官方公开文档不一致、且会影响 Boss 边界判断的实现细节。

12.3 建一个 Hermes 受控试点矩阵

至少分三类任务做对照：

  • 纯问答型主 Agent 任务
  • 多步工具执行任务
  • 需要较强上下文整合的复杂任务

用实际结果决定 Hermes 在 Boss 中应该停留在“高级可选后端”，还是继续推进到“session-aware 主 Agent runtime”。