• AI Agent
• 多智能体
• Agent 编排
• 网络安全
• 渗透测试
• 认证鉴权
• 后端
• 前端

Muteki（無敵）是开源 AI 驱动的进攻性安全框架，它像蜂群一样调度多个 AI Agent 完成自动化渗透测试与 CTF 求解。它最被低估的能力之一，是兼容 8 种主流 Agent CLI——Claude、Codex、Cursor、Grok、Pi、OpenCode、Kimi、OMP，让不同厂商的 Agent 引擎可以统一接入同一个调度体系。本文带你从源码层面看懂 Muteki 的兼容方案：引擎注册表、ACP/RPC 适配层与提示桥（Prompt Bridge）分别解决了什么问题。

上图是 Muteki 的“出战配置”页面：每一枚 Worker 背后对应一种 Agent CLI（Claude Code、Codex、Cursor、Pi、OMP……），你可以在这里为它们绑定凭据、模型与并发上限。这 8 种引擎能力差异很大——有的支持结构化 SDK，有的只暴露终端 stdin，有的走 ACP 协议。Muteki 用三层架构把这些差异“抹平”了。

一、先看全貌：8 个引擎、6 种传输方式

Muteki 把每个引擎的传输方式抽象为 6 种类型：rpc、sdk、acp、http、http+ws、cli，定义在 descriptors.py 中。

这些映射集中在 factory.py 的STRUCTURED_ADAPTER_ENGINES中：Conversation（对话）场景走结构化传输，Worker（解题）场景统一走 CLI——两套默认值刻意保持独立，因为解题 Worker 需要更强的大规模并发稳定性。

二、引擎注册表：一切兼容性的入口

要兼容一个引擎，第一步是“登记”。Muteki 在产品级注册表 engine_registry.py 中声明了每个引擎的身份：

• EngineDescriptor：id、显示名、支持状态（supported/temporarily_disabled）、禁用原因；
• canonical_engine_id()：把cli.dsh、codex-sub-container这类历史/派生写法统一归一到标准引擎 id；
• ensure_engine_supported()：对暂停支持的引擎抛出带稳定机器码的错误（如engine_temporarily_unsupported），而不是静默失败。

一个值得一提的细节：DeepSeek Harness（dsh）目前处于“只登记、不可执行”状态——旧数据仍能正常渲染，但任何新配置/执行入口都会被统一拒绝。这正是注册表“区分可识别”与“可执行”的价值所在。

在 CLI 一侧，cli_engines/registry.py 里的DRIVERS字典为每个引擎挂了一个具体的CliDriver实现（如 ClaudeCodeDriver）。所有 Driver 继承自 CliDriver 基类，它统一处理二进制解析、--help预检（secure prompt capability probe）与流式输出解析，子类只需描述“如何拼参数、如何读事件”。

三、ACP/RPC 适配层：把协议差异变成一行配置

不同引擎的“对话协议”差异巨大。Muteki 的解法是共享传输层 + 协议适配基类：

1. 共享 stdio JSONL 传输（rpc.py）

rpc.py 是整个适配层的地基，它只做三件事、不碰任何业务语义：

1. 严格 LF 分帧：只按\n切分 JSON 记录，容忍行尾\r——避免按行读取器把 JSON 字符串内合法的U+2028/U+2029误当换行；
2. 请求/响应关联：出站消息分配单调递增id，入站按is_response路由给等待方，其余（通知、事件流、Agent→Client 反向请求）交给on_message回调；
3. 反向请求应答：ACP 的session/request_permission这类 Agent 反向请求，通过respond写回结果。

2. ACP 协议适配（acp.py）

acp.py 在传输层之上实现了完整的 Agent Client Protocol v1：initialize能力协商、session/new/session/load/session/resume三种注入点、session/prompt流式正文，以及审批（request_permission）。

它的两大设计亮点：

• replay 与 live 事件区分：历史回放事件只进回放清单、不进入事件投影，恢复会话时不会重复写历史消息；
• 能力硬门控：initialize协商后不支持的能力一律不调用。

最妙的是复用：Grok 和 Cursor 各写一个 ACP Adapter 后，RUNTIME-04 的Kimi ACP 与 OMP ACP 直接继承BaseAcpAdapter，只覆盖 argv、认证选择与能力差异钩子——新增一个 ACP 引擎的成本降到“一份配置”。

3. 适配基类与能力探测（base.py）

所有结构化 Adapter 继承 BaseExternalAgentAdapter，它统一实现：

• 实例身份：adapter_id + instance_id唯一定位一个 Runtime 实例（registry.py）；
• 能力探测（probe）缓存：能力真相来自运行时探测而非按引擎 id 猜测，交互矩阵（interaction_matrix.py）据此向用户展示 supported / limited / unsupported；
• 降级显式化：结构化传输不可用时，probe 报告里明确列出 degradations，不静默关闭审批、会话恢复等能力。

四、提示桥（Prompt Bridge）：给“只会收 stdin”的引擎开一扇门

有些引擎没有结构化传输可用，Worker 又必须保证提示词原样、安全地送达。Muteki 的做法是为这些引擎各写一个极薄的“提示桥”脚本，通过 stdin/stdout 与引擎原生协议对话：

以 Pi 为例：桥进程启动pi --mode rpc，先发送get_state拿到sessionId，再把完整提示词作为一条prompt命令写入 stdin，同时把引擎输出逐行透传给上层。桥还负责失败语义——get_state拿不到 session id、prompt返回success: false都会转为明确的错误信息。

配套的 CliDriverAdapter 再把整个 CLI Driver 包装成与结构化 Adapter 同一接口的ExternalAgentAdapter，上层调度代码完全感知不到“这个引擎没有 SDK”。

五、想接入一个新引擎？按图索骥即可

通读源码后，接入流程其实很清晰：

1. 登记：在 engine_registry.py 加一条EngineDescriptor；
2. 实现传输：有 ACP 的引擎继承BaseAcpAdapter；有原生 RPC 的引擎复用StdioJsonlPeer；纯终端的引擎写一个CliDriver+ 提示桥；
3. 描述能力：在 descriptors.py 声明AdapterDescriptor（传输类型、能力基线、认证方式、模型发现）；
4. 注册映射：在 factory.py 中登记 adapter id → engine 映射，UI 与 Worker 配置自动生效。

这正是 Muteki 兼容 8 种 Agent CLI 的核心哲学：协议差异封装在传输层，能力差异交给运行时探测，历史差异用注册表兜住——上层调度永远只面对一套统一的 Agent 事件契约。如果你想继续深入，可以从 muteki/external_agents/ 目录的factory.py入手，顺着adapter_id找到每个引擎的完整实现。

• AI Agent
• 多智能体
• Agent 编排
• 网络安全
• 渗透测试
• 认证鉴权
• 后端
• 前端