传输层
Agent 和客户端之间相互通信的机制
ACP 使用 JSON-RPC 编码消息。JSON-RPC 消息 必须 以 UTF-8 编码。协议目前定义了以下用于 Agent-客户端通信的传输机制：
- stdio，通过标准输入和标准输出进行通信
- Streamable HTTP（草案提案进行中）
Agent 和客户端 应该 尽可能支持 stdio。
Agent 和客户端也可以实现自定义传输。
stdio
在 stdio 传输中：
- 客户端将 Agent 作为子进程启动。
- Agent 从其标准输入（
stdin）读取 JSON-RPC 消息，并将消息发送到其标准输出（stdout）。 - 消息是单个 JSON-RPC 请求、通知、响应或批处理数组。
- 消息以换行符（
\n）分隔，且 不得 包含嵌入的换行符。 - Agent 可以 将 UTF-8 字符串写入其标准错误（
stderr）用于日志目的。客户端 可以 捕获、转发或忽略此日志。 - Agent 不得 向其
stdout写入任何非有效 ACP 消息的内容。 - 客户端 不得 向 Agent 的
stdin写入任何非有效 ACP 消息的内容。
JSON-RPC 批处理消息
JSON-RPC 2.0 允许发送方在单个批处理数组中组合多个请求和通知对象。ACP 遵循 JSON-RPC 2.0 批处理规则。客户端或 Agent 可以 发送填充了 Request 对象的数组。通知是没有 id 的 Request 对象，因此纯通知批处理和混合请求/通知批处理都是有效的。
接收批处理调用时：
- 如果批处理本身是无效 JSON，返回单个
Parse error响应（code: -32700），id: null。 - 批处理 必须 是至少包含一个值的数组。空数组收到单个
Invalid Request响应（code: -32600），id: null，而不是响应数组。 - 接收方 可以 将批处理条目作为并发任务处理，以任意顺序和任意并行度。
- 接收方 应该 在所有批处理 Request 对象处理完毕后，响应包含相应 Response 对象的数组。
- 每个 Request 对象 应该 有对应的 Response 对象，但通知 不应该 有 Response 对象。
- 接收方 不得 回复通知，包括批处理中的通知。
- Response 对象在响应数组中 可以 以任意顺序出现。发送方 应该 通过
id匹配响应与请求。 - 如果没有要发送的 Response 对象（例如纯通知批处理），接收方 不得 返回空数组，应不返回任何内容。
- 非空批处理中的无效条目产生自己的
Invalid Request响应（code: -32600），id: null；它们不会导致整个批处理失败。
客户端和 Agent 不应该 批处理对生命周期敏感的消息，如 initialize、auth/login、session/new、session/resume 和 session/prompt。这些消息作为单个传输消息更容易推理，且可能改变后续哪些消息是有效的。
Streamable HTTP
讨论中，草案提案进行中。
自定义传输
Agent 和客户端 可以 实现额外的自定义传输机制以满足其特定需求。协议与传输无关，可以在支持双向消息交换的任何通信通道上实现。选择支持自定义传输的实现者 必须 确保它们保留 ACP 定义的 JSON-RPC 消息格式和生命周期要求。自定义传输 应该 记录其特定的连接建立和消息交换模式，以辅助互操作性。