Hermes 开发工作流与 AI Office Control Plane：历史架构构想

记录 2026-08-21 曾构思的 Hermes Brain + Development Workflow + AI Office Control Plane + Agent Bridge/ACP 自研北极星方案，作为后续开源拼装路线的历史对照基线。

#type / synthesis #status / growing #tech / ai #tech / architecture #resource / agent

[!info] related notes

所属 MOC: ai-agent-application-moc

相关概念: model-router、llm-provider-abstraction、workflow-orchestration、ai-service-observability、agent-configuration-and-execution-provenance

易混淆概念:

相关资源:

Hermes 开发工作流与 AI Office Control Plane：历史架构构想

历史定位

这是 2026-08-21 围绕 Hermes 开发自动化曾形成的一版 North-Star Architecture。它的目标不是让 Hermes 自己承担主要编码执行，而是把 Hermes 定位为长期对话与语义决策的大脑，把软件开发方法固化成 Development Workflow，把模型与 Provider 资源调度集中到 AI Office，再通过 Agent Bridge 驱动 Codex、OpenCode、DSH、Claude Code 等专业 Coding Agent。

这份方案作为历史架构构想保留，不代表当前最终实施方向。后续因为自研 Execution Lifecycle、Agent Bridge、Telemetry、Secret、Recovery 和 UI 的维护成本较高，设计开始向“尽量复用 OpenHands + LiteLLM + Langfuse，只保留薄适配层”演进。

四层职责模型

原方案把系统分为四个长期稳定的边界：

Hermes Brain
    ↓
Development Workflow
    ↓
AI Office Control Plane
    ↓
Agent Harness / Coding Runtime

Hermes Brain

Hermes Brain 负责理解用户意图、判断任务复杂度、选择要进入的软件开发阶段，并综合阶段产物决定下一步。它不直接管理 Provider、API Key、模型健康和执行进程。

例如用户提出“页面白屏时间较长，调查原因并审查一下”，Brain 先识别这是 software-development / investigate 类型任务，再触发开发工作流，而不是自己直接开始大量 shell、grep 和代码修改。

Development Workflow

Development Workflow 表达软件工程方法论与阶段状态，而不是模型供应商逻辑。核心阶段收敛为：

INVESTIGATE_PLAN
      ↓
IMPLEMENT
      ↓
VERIFY_REVIEW
      ↓
FINALIZE

INVESTIGATE_PLAN 默认把调查、根因分析和方案规划放进同一个 Coding Agent session 中，避免重复读取仓库与重新建立上下文，也尽量保留 provider cache / warm context。实施后的 VERIFY_REVIEW 则默认使用 fresh session，必要时换 Agent 或模型，以减少“自己证明自己正确”的确认偏差。

Skill 负责告诉 Hermes 何时采用这套流程，但关键生命周期不应只依赖 Prompt 约定。真正的“申请资源 → 启动 → 跟踪 → 完成登记”应由确定性 runtime/tool 强制执行。

AI Office Control Plane

AI Office 的定位不是 Workflow Engine，而是模型和执行资源的 Control Plane。它回答的是“如果现在需要执行这个阶段，应该使用哪个 Harness + Model + Provider”，而不是“下一阶段应该是什么”。

它负责：

Provider Registry 与 Credential Reference
Model / Model Deployment Registry
Harness Registry 与 Compatibility
Availability、cooldown、quota、budget、cost
Routing Policy 与 Route Decision
Execution Ledger 与 Usage/Health observability

路由单位不是单独的 Model，而是：

Execution Target
= Harness × Model Deployment × Provider × Credential × Session Policy

Agent Harness

Codex、OpenCode、DSH、Claude Code 等属于真正执行任务的 Coding Runtime。它们拥有自己的 context management、tool loop、shell、file editing、diff/test loop 等能力。Hermes 不需要复制这些专业 agent runtime。

Execution Lease

原方案的核心领域对象是 ExecutionLease。Workflow 先向 AI Office 提交 AcquireExecutionRequest，携带：

workflow_run_id
phase_run_id
phase
task_summary
workspace
complexity / risk
capability requirements
parallelism
budget_class
affinity_key

AI Office 路由后返回：

ExecutionLease
├─ lease_id
├─ execution_id
├─ harness
├─ model
├─ provider / deployment
├─ endpoint
├─ credential_ref
├─ session_policy
├─ expires_at
└─ route_reason

API Key 不进入 Hermes Brain 的上下文。Agent Bridge 根据 credential_ref 在进程边界处解析并注入 Secret。

强制执行生命周期

一个阶段只需要由 Brain 调用一次类似 dev_run_phase() 的确定性工具，其内部强制完成完整协议：

Acquire Lease
    ↓
RESERVED
    ↓
Launch Agent
    ↓
STARTED
    ↓
HEARTBEAT / PROGRESS / USAGE
    ↓
SUCCEEDED | FAILED | CANCELLED | LOST | TIMED_OUT
    ↓
Result → Hermes Brain

Execution Event 统一携带 schema_version、event_id、workflow_run_id、phase_run_id、execution_id、sequence、时间戳以及 harness/model/provider 信息，并要求幂等与单调序列，避免重试导致 Usage 重复累计。

Agent Bridge 与 ACP

Agent Bridge 负责把标准 Execution Lease 转换成具体 Coding Agent 的启动、session、cancel、progress、result 与 usage 行为。原方案倾向使用 Agent Client Protocol（ACP）作为统一 agent wire protocol，使 Codex、OpenCode、Claude Code 等尽可能通过统一接口被控制，只对不支持 ACP 的执行器补小型 adapter。

AI Office domain 不直接依赖某个具体 ACP client/runtime，而只依赖稳定的 AgentBridge port，从而允许后续替换实现。

原方案的数据平面与 Telemetry

最初设计明确区分 Control Plane 与 Data Plane：AI Office 只做路由，不代理真实 LLM 流量。

AI Office ──route──> Agent
                    │
                    └────────> Provider

Agent Bridge 在执行完成或运行期间把 input/output/cache/reasoning tokens、request count、latency、cost 和错误回传到 AI Office。Provider Billing API 用于周期性 reconciliation；没有原生 usage 时才允许估算并标记 usage_source=estimated。

这一设计避免中央 Proxy 成为数据平面的单点，但代价是每个 Agent Harness 都要可靠暴露 usage，且需要自行解决聚合、对账和丢事件问题。这后来成为方案向 LiteLLM Gateway 演进的重要原因之一。

并行实施

Workflow 可以一次请求多个 Implementation Lease，但所有会写代码的并行执行默认使用隔离 worktree/workspace：

repo
├─ worktree/execution-a
├─ worktree/execution-b
└─ worktree/execution-c

最终进入 Integration + Test + Fresh Review，避免并发 Agent 在同一 working tree 中相互覆盖。

AI Office UI 的岗位模型

“员工占岗位”不是长期创建虚拟 coder/reviewer profile，而是对运行中 Execution 的投影：

PhaseRun
   ↓
Execution
   ↓
Harness + Model + Provider

UI 可以展示：当前阶段、任务摘要、Agent/Harness、模型、Provider、开始时间、运行时长、Token、Cost、状态与最终结果。岗位只是 Phase/Capability Slot，员工是当前实际占据它的 Execution Target。

方案优势

这版方案在领域边界上非常干净：Hermes 决策、Workflow 管方法、AI Office 管资源、Coding Agent 真正执行；并且 Execution Lease、事件契约与统一 telemetry 可以形成很强的可追踪性、可测试性和可替换性。

它尤其适合需要长期自主演进、严格定制路由策略、复杂配额经济模型以及多种 Agent Harness 的场景。

自研成本与演进压力

真正的风险并不在 Router 本身，而在为了实现完整效果必须长期维护的基础设施：

Agent session / subprocess / ACP 生命周期与兼容性
heartbeat、cancel、retry、timeout、crash recovery
workspace / worktree 隔离与 cleanup
Secret 注入和 credential rotation
不同 Harness 的 token/cost 语义差异与可靠对账
append-only execution ledger、事件幂等和 replay
实时 UI projection 与状态一致性

如果主要目标是个人 Hermes 开发流程，而不是打造一套通用 Agent Platform，那么这些维护面很可能超过收益。因此后续更现实的演进方向是保留上述清晰的领域边界和开发阶段语义，但尽量把 Agent Hosting、Model Gateway 和 Observability 分别交给成熟开源项目，只保留很薄的 Hermes Adapter 与策略配置。

后续演进方向

新的候选路线是：

Hermes Brain
    ↓
Development Skill / thin runtime
    ↓
OpenHands Agent Server / ACP
    ↓
LiteLLM Proxy
    ↓
Provider

LiteLLM / Agent Server
    ↓
Langfuse

其中 OpenHands 替代大部分自研 Agent Bridge，LiteLLM 替代 Provider/Deployment Gateway 与 usage metering，Langfuse 替代大部分自研 trace/cost observability；AI Office 则从重型基础设施收敛成轻量 policy/facade/dashboard。这样仍保留原 North-Star 的职责分离，但显著降低自建与长期维护成本。