如何将Hermes Agent从协议到生产集成实践？

Hermes Agent 集成实践：从协议到生产 分享 HagiCode 集成 Hermes Agent 的完整实践，包括 ACP 协议适配、会话池管理、前后端契约同步等核心经验。 背景 在构建 AI 辅助编码平台 HagiCode 的过程中，团队需要集成一个既能在本地运行又能扩展到云端的 Agent 框架。经过调研，Nous Research 的 Hermes Agent 被选为综合 Agent 的底层引擎。 其实选型这事儿，说难也不难，说简单也不简单。毕竟市面上能打的 Agent 框架也不少，只是 Hermes 那个 ACP 协议和工具系统确实有点东西，刚好契合 HagiCode "既要又要"的需求场景——本地开发、团队协作和云端扩展。但要把 Hermes 真正融入生产系统，还需要解决一系列工程问题，这可不是闹着玩的。 HagiCode 的技术栈基于 Orleans 构建分布式系统，前端使用 React + TypeScript。集成 Hermes 需要在保持现有架构统一性的前提下，让 Hermes 成为与 ClaudeCode、OpenCode 等并行的"一等公民"执行器。说起来容易，做起来嘛，也就那样吧。 本文分享我们在 HagiCode 项目中集成 Hermes Agent 的实践经验，希望能给面临类似需求的团队提供参考。毕竟，踩过的坑，没必要让别人再踩一遍。 关于 HagiCode 本文分享的方案来自我们在 HagiCode 项目中的实践经验。HagiCode 是一个 AI 驱动的编码辅助平台，支持多种 AI Provider 的统一接入和管理。在集成 Hermes Agent 的过程中，我们设计了一套通用的 Provider 抽象层，使得新的 Agent 类型可以无缝接入现有系统。 如果你对 HagiCode 感兴趣，欢迎访问 GitHub 了解更多。多个人看，多份力量罢了。 架构设计 分层设计思路 HagiCode 的 Hermes 集成采用了清晰的分层架构，每层各司其职： 后端核心层 HermesCliProvider: 实现 IAIProvider 接口，作为统一的 AI Provider 入口 HermesPlatformConfiguration: 管理 Hermes 可执行文件路径、参数、认证等配置 ICliProvider<HermesOptions>: HagiCode.Libs 提供的底层 CLI 抽象，处理子进程生命周期 传输层 StdioAcpTransport: 通过标准输入输出与 Hermes ACP 子进程通信 ACP 协议方法：initialize、authenticate、session/new、session/prompt 运行时层 HermesGrain: Orleans Grain 实现，处理分布式会话执行 CliAcpSessionPool: 会话池，复用 ACP 子进程，避免频繁启动开销 前端层 ExecutorAvatar: Hermes 视觉标识和图标 executorTypeAdapter: Provider 类型映射逻辑 SignalR 实时消息传递：保持 Hermes 身份在消息流中的一致性 这种分层设计使得各层可以独立演进，比如未来要添加新的传输方式（如 WebSocket），只需修改传输层即可。毕竟，谁愿意因为改一个传输方式就把整个系统都翻一遍呢？多累啊。 统一接口抽象 所有 AI Provider 都实现 IAIProvider 接口，这是 HagiCode 架构的核心设计： public interface IAIProvider { string Name { get; } ProviderCapabilities Capabilities { get; } IAsyncEnumerable<AIStreamingChunk> StreamAsync( AIRequest request, CancellationToken cancellationToken = default); Task<AIResponse> ExecuteAsync( AIRequest request, CancellationToken cancellationToken = default); } HermesCliProvider 实现了这个接口，与 ClaudeCodeProvider、OpenCodeProvider 等处于平等地位。