1. MCP (Model Context Protocol) 本质
1.1 核心设计理念
MCP全称:Model Context Protocol (模型上下文协议)
- 设计目标:为大型语言模型(LLM)提供丰富的上下文信息和工具访问能力
- 核心思想:让模型能够访问和操作外部环境中的各种资源
- 架构模式:C/S架构 - 模型作为客户端,工具/环境作为服务端
1.2 协议特征
js
// MCP协议核心概念 - 以模型为中心
interface MCPProtocol {
// 模型可以发现和使用的资源
resources: {
// 文件系统访问
fileSystem: {
read: (path: string) => Promise<string>,
write: (path: string, content: string) => Promise<void>,
list: (path: string) => Promise<Array<{name: string, type: 'file' | 'directory'}>>
},
// 网络资源访问
network: {
fetch: (url: string) => Promise<Response>
},
// 工具调用
tools: {
list: () => Promise<Tool[]>,
call: (toolName: string, params: any) => Promise<any>
}
};
// 模型可以使用的提示模板
prompts: {
list: () => Promise<Prompt[]>,
get: (name: string) => Promise<Prompt>
};
// 模型可以感知的系统状态
system: {
logs: () => Promise<string[]>,
metrics: () => Promise<SystemMetrics>
};
}
1.3 Codex对MCP的实现
从Codex源码可以看出:
- MCP Server角色:Codex实现了MCP服务端,为模型提供上下文
- 标准化接口:遵循MCP标准方法调用(tools/call, resources/read等)
- JSON-RPC传输:使用JSON-RPC 2.0协议进行通信
2. ACP (Agent Control Protocol) 本质
2.1 核心设计理念
ACP全称:Agent Control Protocol (代理控制协议)
- 设计目标:为人类用户提供控制和管理AI代理的能力
- 核心思想:让人能够安全地监督、授权和控制AI代理的行为
- 架构模式:控制架构 - 人作为控制者,AI代理作为被控制者
2.2 协议特征
js
// ACP协议核心概念 - 以人为中心的控制
interface ACPProtocol {
// 会话管理 - 控制代理的生命周期
session: {
new: (config: SessionConfig) => Promise<Session>,
end: (sessionId: string) => Promise<void>,
status: (sessionId: string) => Promise<SessionStatus>
};
// 权限控制 - 人在环路的授权机制
permission: {
request: (request: PermissionRequest) => Promise<void>,
approve: (requestId: string, decision: PermissionDecision) => Promise<void>
};
// 消息传递 - 双向通信控制
message: {
send: (message: UserMessage) => Promise<void>,
receive: (callback: (agentMessage: AgentMessage) => void) => void
};
// 工具执行控制 - 安全执行管理
tools: {
call: (toolCall: ToolCall) => Promise<ToolResult>,
monitor: (toolCallId: string) => Promise<ToolExecutionStatus>
};
}
### 2.3 iFlow对ACP的实现
从代码可以看出:
1. ACP Client角色:iFlow作为ACP客户端,被人类控制
2. 标准化接口:遵循ACPI标准方法调用(session/new, permission/request等)
3. JSON-RPC传输:使用JSON-RPC 2.0协议进行通信
3. 根本差异对比
3.1 设计视角差异
维度 | MCP (Codex) | ACP (iFlow) |
---|---|---|
中心视角 | 以模型为中心 | 以人为中心 |
控制方向 | 模型主动获取信息 | 人主动控制代理 |
权限模式 | 模型请求访问资源 | 人授权代理行为 |
交互模式 | 查询-响应 | 命令-控制 |
3.2 协议语义差异
js
// MCP语义 - 模型视角
{
"method": "tools/call", // 模型调用工具
"params": {
"name": "read_file",
"arguments": { "path": "/file.txt" }
}
}
// ACP语义 - 控制视角
{
"method": "permission/request", // 请求人授权
"params": {
"toolCall": {
"name": "read_file",
"arguments": { "path": "/file.txt" }
},
"options": ["allow_once", "reject_always"]
}
}
3.3 数据流向差异
MCP数据流:
graph LR
模型 --> 请求上下文 --> MCP服务端 --> 访问资源 --> 文件系统/工具
ACP数据流:
graph LR
人类 --> 控制指令 --> ACP客户端 --> 执行动作 --> 文件系统/工具
ACP客户端 --> 请求授权 --> 执行动作
4. 实现层面的根本冲突
4.1 协议角色冲突
js
// Codex在MCP中是服务端角色
class CodexMcpServer {
// 为模型提供服务
async handleToolCall(toolName: string, params: any) {
// 直接执行,无需人类授权(在MCP语义中)
return await this.executeTool(toolName, params);
}
}
// iFlow在ACP中是客户端角色
class IFflowAcpClient {
// 被人类控制
async requestToolExecution(toolName: string, params: any) {
// 必须等待人类授权
const approval = await this.requestHumanApproval(toolName, params);
if (approval.granted) {
return await this.executeTool(toolName, params);
}
throw new Error('Permission denied');
}
}
4.2 权限处理冲突
js
// MCP权限处理 - 隐式权限(模型信任环境)
class CodexMcpPermission {
async checkPermission(resource: string): Promise<boolean> {
// MCP假设模型已经在可信环境中
return true; // 直接允许
}
}
// ACP权限处理 - 显式授权(人在环路)
class AcpPermission {
async requestPermission(action: string): Promise<boolean> {
// ACP要求人类明确授权
return await this.askHumanForApproval(action);
}
}
5. 结论
Codex不能也不应该复用ACP架构的根本原因:
5.1 协议本质不兼容
- MCP:服务于模型的上下文获取协议
- ACP:服务于人的代理控制协议
- 角色冲突:Codex既要作为MCP服务端(为模型服务),又要作为ACP客户端(被人控制)
5.2 设计理念冲突
-
控制方向相反:
- MCP:模型主动获取 → Codex提供服务
- ACP:人主动控制 → Codex接受控制
-
权限模式不同:
- MCP:隐式信任 → 直接访问资源
- ACP:显式授权 → 必须等待批准
5.3 正确的架构应该是:
graph LR
人类用户 --> ACP控制器 --> CodexMCP客户端 --> Codex引擎
CodexMCP客户端 --> 转换协议 --> Codex引擎
这就是为什么Codex应该保持其MCP实现的独立性,而在应用层通过适配器与ACP系统集成,而不是强行复用ACP架构!