Part IV · Interface & Extensions

14 headless 四条无 UI 路径,以及文档为什么劝你别用 RPC

已发布无头路径 4 条协议包 experimental
§1 Mental Model 一句话心智模型

先记住这一句

pi 提供了四条无 UI 的接入路径,而且文档明确告诉你别选错:Node/TS 应用应该直接用 AgentSession 类,而不是起一个子进程走 RPC。
路径形态适合
-p "prompt"一次性执行,纯文本输出脚本、CI
--mode json事件流,JSON Lines 到 stdout接进其它工具、自定义 UI
--mode rpcstdin/stdout 上的 JSON 协议,双向非 Node 语言、IDE 插件
SDK(AgentSession)直接当库用,同进程Node/TS 应用(首选)

另外还有一个 packages/protocol + packages/server 的二进制协议,标着 experimental——那是给「会话服务端」用的,与上面四条不是一回事。

锚点之后这套二进制协议没有留下来:7472cda(2026-10-12)删除了 client / protocol / server 三个包和 coding-agent 的 experimental 服务端栈,v1.2.0 是第一个不含它们的发布。§4 说「基于它们做集成是在赌路线图」,这一注的结果是被移除。上面四条路径都还在(SDK 见下一句的引用):cli.md:30。RPC 文档在 25cc5c7(2026-09-22)的文档重写中被拆成几份、大幅缩短,劝 Node/TS 集成方别起子进程的那句仍在第 5 行,改成了「优先用 SDK 或导出的 RpcClient」:rpc.md:5。

§2 Evidence 代码实证

文档主动劝退 RPC

packages/coding-agent/docs/rpc.md原文 L3 与 L5(并置)
RPC mode enables headless operation of the coding agent via a JSON protocol over
stdin/stdout. This is useful for embedding the agent in other applications, IDEs, or custom UIs.

**Note for Node.js/TypeScript users**: If you're building a Node.js application, consider
using `AgentSession` directly from `@earendil-works/pi-coding-agent` instead of spawning
a subprocess.
一份 1578 行的 RPC 文档(锚点版本),在第 5 行告诉你的一大类读者别用它。这是好文档的标志——它优化的是读者的结果,不是自己特性的使用率。rpc.md:5

JSON 模式是事件流,不是结果

pi --mode json "prompt" 把全部会话事件按 JSON Lines 输出。json.md:7 事件种类与 第 03 章的循环事件同源——agent_start / turn_start / message_update / tool_execution_*。

换句话说,无头模式暴露的是循环的内部结构,而不是一个封装好的「答案」。要拿最终文本,你得自己从事件流里挑。

实验性的二进制协议

packages/protocol/README.md原文 L5–L10(节选)
Protocol version `1` uses binary messages with this wire layout:
1. A four-byte unsigned big-endian payload length.
2. One definite-length CBOR item containing the message.

… Session and server snapshots are authoritative. Progress events are transient UI
hints and must not be reduced into authoritative state.
最后那句是整段里最重要的设计约束:快照是权威,进度事件只是 UI 提示,不许归约进权威状态。protocol/README.md:10

这条规则与 第 08 章harness-v2 的 UI 模型是同一条:客户端拿一次原子快照,然后接实时事件流;事件不重放,重连就是拿新快照。两处独立表述了同一个约束,说明它是这套架构里想清楚了的部分。

§3 Design 设计动机与权衡

为什么四条路径都要有

看似冗余,实际对应四种不同的调用方约束:

关键在最后一条:如果 SDK 可用,RPC 就是纯粹的开销。文档把这件事说破,而不是让每个 Node 用户自己踩一遍。

「快照权威 + 事件瞬态」是这类系统的核心约束

一个流式 agent 的客户端有两个信息来源:初始快照和实时事件。允许客户端把事件归约进状态,就等于要求事件流无丢失、无重复、严格有序——那是分布式系统里最贵的保证之一。

pi 的做法是拒绝支付这个成本:事件只用来更新界面,权威状态永远来自快照;断线了就重新拿快照。代价是重连成本高(要传整个快照),收益是事件通道可以不可靠。

对一个「事件是 token 级、每秒几十条」的系统,这个取舍显然正确。

§4 Limits 边界与失效条件
§5 Takeaway 拿走什么
§ Self-check 自测

给场景,判断 pi 会怎么做

场景你在写一个 Node.js 应用要嵌入 pi。按文档,首选哪条路径?

看答案

B。rpc.md:5 SDK 可用时,RPC 的进程边界和序列化是纯开销。

场景pi --mode json 跑完了一个任务。「最终答案」在输出的哪里?

看答案

B。无头模式暴露的是循环的事件结构(agent_start / message_update / tool_execution_*),「什么算完成」由调用方定义。简单场景请用 -p。

基于 earendil-works/pi @ ac4ac9e(2026-08-07 快照)。
仓库 commit 速度约 428/月,行号引用仅对该 SHA 有效。