mcp-acp-bridge

一个为任何使用MCP的编码智能体提供前端的ACP服务器。

该桥接器为智能体托管一个MCP服务器，并通过 ACP 与编辑器或客户端通信。由于智能体的 每次工具调用都会经过它，桥接器可以挂起每次调用并先请求客户端批准——从而将工具调用转化为 驱动界面的真实权限提示。

client (T3 Code, Zed, …) ──ACP──► bridge ──MCP──► agent (agy, claude, codex, …)
                                    │
                                    └─ spawns and supervises the agent process

状态：MCP部分已可用。ACP部分尚不存在。

工具拦截和权限门控已实现，并针对作为实时MCP客户端的Claude Code进行了端到端验证——调用被拦截、 挂起、允许或拒绝，拒绝结果以可读文本形式返回给智能体。缺失的部分是将这些挂起转化为 session/request_permission 给真实客户端的ACP服务器，以及智能体监督器。 参见 docs/design.md。

尝试运行

npm install
npm test              # unit tests, no agent required
npm run test:live     # drives the real `claude` CLI against the gateway
npm run test:live deny

test:live 需要 claude CLI 在 PATH 中并已认证。它会为Claude Code 提供一个每次会话的MCP端点，要求它调用一个工具，并展示拦截过程：

[tool] requested magic_word
[gate] DENY magic_word {}
[tool] denied magic_word (denied by test policy)
[claude] said: The tool call was denied. The error returned was exactly:
         `Error: permission denied: denied by test policy`

Related MCP server: agentic-governance-gateway

为什么

某些编码智能体不产生结构化输出。Google的Antigravity CLI (agy) 是典型例子：它没有ACP模式 （上游请求）， 在无头模式下它输出纯文本，并且自动拒绝任何无法提示的权限。因此，从GUI驱动它意味着要么抓取TUI， 要么放弃审批。

这个桥接器采取了第三条路径。它忽略智能体说的内容，而是拦截智能体做的内容：MCP工具调用已经是结构化的、 可观察的，并且——关键的是——已经可以拦截。MCP服务器不是监听器，而是一个门。

这种方法并不特定于某个智能体。任何可以指向MCP服务器的智能体都能工作。

它能看见什么，不能看见什么

MCP是一个工具通道，而不是智能体输出通道。

智能体的内置文件和shell工具不经过MCP，因此不会产生 tool_call。这是一个可见性缺口，而非正确性问题——那些对工作区进行快照的客户端（T3 Code在轮次边界上对工作区进行差异比较）仍然会记录发生了什么变化。丢失的是实时的每个操作进度，而非记录。

通过将内置工具作为MCP工具路由到桥接器，可以弥补这一缺口，并将安全模型从常驻授权升级为每次操作审查。这是计划中的加固措施，而非先决条件。

MCP版本支持

当前版本和即将到来的版本都受支持，因为桥接器从不依赖MCP传输状态：

ACP会话通过路径作用域的端点URL（每个智能体运行一个）进行关联，因此两个版本行为相同。参见 docs/design.md。

许可证

MIT。参见 LICENSE。