给 Hermes Agent 装上"万能模型适配器"——hermes-agent-acp-bridge
一句话讲清楚：让你的 CLI AI Agent 调用任何编程助手，就像调用 OpenAI 一样自然。
一、Hermes Agent 的"模型饥渴"
Hermes Agent 是一个运行在终端里的 AI 助手。它能在你的终端里读代码、写代码、跑命令——但它自己不会思考，每一步都要调用一个「大模型」来生成回答。
调用大模型需要一个标准接口。业界最通用的就是 OpenAI 兼容 HTTP API：
ounter(lineounter(lineounter(lineounter(lineounter(line
POST /v1/chat/completions
{
"model": "gpt-4o",
"messages": [{"role": "user", "content": "帮我写个 Python 脚本"}]
}Hermes Agent 可以配置任意 OpenAI 兼容的 API provider。所以理论上，它可以调用 OpenAI、DeepSeek、Ollama 本地模型……任何提供这个接口的服务。
但问题来了： 我们每天在 IDE 里用的编程助手——Cursor、Copilot、CodeBuddy——它们用的不是 OpenAI HTTP API，而是一个叫 ACP（Agent Client Protocol） 的协议，由zed提出的一种agent之间的通信协议 acp。
如果你想在 Hermes Agent 里用 CodeBuddy 的模型，怎么办？
二、旧方案：tmux 刮屏——每一次对话都在烧钱
在 hermes-agent-acp-bridge 之前，也有办法让 Hermes Agent 调用 CodeBuddy。办法很原始：
ounter(lineounter(lineounter(line
tmux send-keys → 往 CodeBuddy 的终端窗口里敲字
sleep 3s → 等它反应
tmux capture-pane → 截取整个终端画面然后从截下来的画面里抠出 CodeBuddy 的回复。
每次交互，截下来的画面里挤满了：
-
之前的对话历史
-
ANSI 颜色转义码
-
光标和提示符
-
各种 UI 装饰
结果是：一次简单提问就要把 2000-4000 个 token 的屏幕垃圾塞进 model context，其中真正有用的回复可能只有 200 个 token。按 DeepSeek-V3 的价格（约 $0.27/百万 token），看起来不多——但如果你每天和 Hermes Agent 交互 100 轮，一天就浪费掉 30 万 token 的屏幕垃圾，一个月近 1000 万 token。
而且 tmux 方案完全不可靠：ANSI 颜色码会乱、输出截断要看运气、新行刷新不及时导致回复不完整。每次调试都像在猜谜。
三、ACP 协议：结构化的救星
ACP（Agent Client Protocol） 是 CodeBuddy、Copilot 等 IDE 编程助手内部使用的通信协议。它走 JSON-RPC over stdio，定义了一套标准消息：
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
Client → Agent:
initialize → 握手，协商协议版本
new_session → 开启一个新对话
prompt → 发送用户消息
set_session_config_option → 切换模型
Agent → Client:
AgentMessageChunk → 文本流式输出
RequestPermission → 请求危险操作授权ACP 的好处是结构化。你收到的就是干净的文本，没有 ANSI 转义码、没有 UI 装饰、没有屏幕垃圾。一条 AgentMessageChunk 只包含模型输出的纯文本。
四、hermes-agent-acp-bridge：架一座桥
这个项目做的事用一句话概括：
把 ACP 协议包装成 OpenAI 兼容 HTTP API，让任何 OpenAI 客户端（包括 Hermes Agent）都能无缝调用 ACP agent。
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
┌──────────────────────────────┐
│ Hermes Agent │
│ POST /v1/chat/completions │
└──────────┬───────────────────┘
│ HTTP (OpenAI format)
▼
┌──────────────────────────────┐
│ hab (hermes-agent-acp │
│ -bridge) │
│ http://127.0.0.1:7800 │
└──────────┬───────────────────┘
│ ACP (JSON-RPC over stdio)
▼
┌──────────────────────────────┐
│ CodeBuddy / Copilot │
│ (子进程) │
└──────────────────────────────┘它提供的 API
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
GET /health 健康检查
GET /v1/models 列出所有可用模型
POST /v1/chat/completions 流式对话 (SSE)
POST /v1/completions 非流式对话
POST /v1/sessions 创建持久 session
GET /v1/sessions 列出所有活跃 session
DELETE /v1/sessions/{id} 关闭 session完全是标准 OpenAI 接口。任何支持自定义 API endpoint 的工具都可以直接用它。
模型命名
ounter(lineounter(lineounter(line
acp/codebuddy → CodeBuddy 的默认模型
acp/codebuddy/Claude-Sonnet-4.6 → 指定模型
acp/copilot → Copilot 的默认模型五、在 Hermes Agent 中配置使用
Hermes Agent 的 provider 配置很简单。假设 bridge 跑在本机 7800 端口：
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
# ~/.hermes/config.yaml
providers:
- id: "acp"
name: "ACP Bridge"
api_base: "http://127.0.0.1:7800/v1"
api_key: "not-needed" # bridge 不需要密钥
protocol: "openai"然后就可以像用 OpenAI 一样选择模型：
ounter(line
hermes agent --model acp/codebuddy/Claude-Sonnet-4.6Hermes Agent 发送给 bridge 的请求：
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
POST /v1/chat/completions
{
"model": "acp/codebuddy/Claude-Sonnet-4.6",
"messages": [
{"role": "user", "content": "帮我重构这段 Rust 代码"}
]
}Bridge 收到后：
-
解析出 agent:
codebuddy，model:Claude-Sonnet-4.6 -
启动
codebuddy --acp子进程 -
走 ACP initialize → newSession → setSessionConfigOption → prompt
-
把 AgentMessageChunk 实时转成 SSE chunk 发回 Hermes
-
Hermes Agent 流式显示回复，跟用 GPT-4o 一模一样
流式输出的效果
ounter(lineounter(lineounter(lineounter(lineounter(line
assistant: 我来分析一下这段代码的问题...
1. 第 23 行的 unwrap() 在 Err 分支会 panic
2. 第 45 行的循环可以用 iterator 改写成更 Rust 的风格
3. ...（逐字流式输出，打字机效果）完全不需要等全部输出完成才看到结果，体验和原生 ChatGPT 一样。
六、Rust 技术亮点
关键设计决策
**1. spawn_blocking + **LocalSet
ACP SDK 的 Client trait 是 ?Send 的（内部有 Rc/RefCell），不能跨线程。所以每个 ACP 调用都跑在 tokio::task::spawn_blocking 新建的独立线程里，线程内部再开一个单线程 runtime + LocalSet。这保证了并发性和 SDK 的兼容性。
2. DashMap 无锁 session 存储
Session 读写是高频操作（每次 chat 都要查 session）。用 std::sync::Mutex 包装 HashMap 会串行化所有请求。DashMap 是无锁并发 HashMap（类似 Java ConcurrentHashMap），支持真正的并行读写。
3. 并发模型查询
GET /v1/models 需要启动所有 agent 子进程来探查模型列表。Rust 版用 futures::future::join_all 真正并发等待所有 agent，比原版的 async serial 快一个数量级。
4. 零拷贝 SSE 流
用 async-stream + Body::from_stream 构建 SSE 响应，不在内存里缓存完整输出，chunk 到达后即时推送给客户端。
5. Token 估算
与其引入重量级的 tiktoken 库，直接用 ceil(text_len / 4) 估算。大多数中英文混合场景下误差在 10% 以内，够用了。
七、快速上手
安装
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
# 确保已安装 Rust toolchain
cd /path/to/hermes-agent-acp-bridge
cargo build --release
# 二进制文件在 target/release/hab
# 建议放到 PATH 里
cp target/release/hab ~/.local/bin/配置
创建 ~/.config/hermes-agent-acp-bridge/config.json：
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
{
"port": 7800,
"agents": {
"codebuddy": {
"command": "codebuddy",
"args": ["--acp"]
},
"copilot": {
"command": "copilot",
"args": ["--acp", "--stdio"],
"env": {
"HTTPS_PROXY": "http://127.0.0.1:1087",
"HTTP_PROXY": "http://127.0.0.1:1087"
}
}
}
}启动
ounter(lineounter(lineounter(line
hab
# 或后台运行
nohup hab &输出：
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
╔══════════════════════════════════════╗
║ hermes-agent-acp-bridge v0.1.0 ║
║ ACP → OpenAI Protocol Gateway ║
╚══════════════════════════════════════╝
Listening: http://127.0.0.1:7800
Agents: codebuddy, copilot, continue验证
ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
# 列出模型
curl http://127.0.0.1:7800/v1/models
# 直接对话
curl -N http://127.0.0.1:7800/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"acp/codebuddy","messages":[{"role":"user","content":"hello"}]}'八、不只是 Hermes Agent
虽然这篇文章主要讲 Hermes Agent 的用法，但 hermes-agent-acp-bridge 是一个标准 OpenAI API 网关。它可以用在任何地方：
-
Continue.dev — 配置为 custom provider，直接在 VS Code/JetBrains 里用 CodeBuddy 的模型
-
Aider — AI 结对编程工具，
--openai-api-base http://127.0.0.1:7800/v1 -
Open Interpreter — 自然语言终端
-
任何支持 OpenAI API 的工具 — ChatBox、NextChat、LangChain……
九、总结
每次交互浪费 token 2000-4000 ~300（协议开销）
可靠性 靠运气 结构化协议，无歧义
性能 阻塞等待 流式输出，实时性好
多 agent 支持 改脚本 加一行配置
模型切换 手动 API 自动
Hermes 集成 需要适配 原生支持
如果你的工作流依赖 Hermes Agent，又想用 CodeBuddy/Copilot 的模型能力，hermes-agent-acp-bridge 几乎是必选项。它把终端 AI Agent 和 IDE 编程助手之间的裂缝补上了，而且补得很干净。
项目地址:hermes-agent-acp-bridege（https://github.com/xnzone/hermes-agent-acp-bridge）
二进制名:hab（Hermes Agent Bridge 的缩写，读音 /hæb/）
许可证: 开源，欢迎 PR。
- END -