ACP JSON-RPC 消息流：四类消息与完整生命周期#

ACP 不是请求-响应循环——它是双向的、流式的状态机，客户端和 runtime 都可以主动发起请求。

0. 一句话先讲明白#

ACP 连接建立后，线路上来回流动的是四种形态的 JSON-RPC 消息：client request、response、notification、server-to-client request。这四种消息共用同一条 stdio 通道，靠有没有 id、有没有 method 来区分——dispatch 顺序写错一步，runtime 就会静默卡住。

本节把每种消息的结构、用途、易错点都讲清楚，并用一条标准 ACP 流程加一条 Grok 0.1.220 扩展 trace 走一遍从 initialize 到最终回复的全流程。

本节示例已按 2026-05-28 的 ACP SDK schema、Grok 0.1.220 wire fixture 与 runtime 源码重新校准；复制代码时以这里的字段名和 sessionUpdate 枚举为准。

你将学到#

• 四类 JSON-RPC 消息的精确区分逻辑（有 id、有 method 的各种组合）
• initialize → authenticate → session/new → session/prompt 完整时序
• session/update notification 的 payload 结构：agent_message_chunk、agent_thought_chunk、tool_call、tool_call_delta_chunk、tool_call_update
• server-to-client request 的三个已知方法：fs/read_text_file、fs/write_text_file、session/request_permission
• 完成信号的双信号判断逻辑，以及为什么单靠 JSON-RPC response 不够安全