到达输出 token 上限时，出现“本轮运行失败invalid pi-ai replay state: block count does not match assistant content”

[l1005268416]

[denial123789]

可以确认：这不是“输出被截断”本身的正常报错，而是 max-token 截断后的 durable content 与 pi-ai replay metadata 不一致。

当前 master 47f943859bef60e4160492346772ded9b24f765a 上的链路是：

1. pi-ai 收到 provider 的 done 后，无论 stop reason 是否为 length，都会用原始 event.message.content 生成 replay state：stream.ts#L188-L195。
2. 公共 BlockAssembler.blocks() 遇到 max-tokens 时，会主动过滤所有 tool-call block，避免执行一个被截断、参数可能不完整的工具调用：assembler.ts#L128-L139。
3. agent-loop 随后把“过滤后的 content”和“未过滤的 replayState”一起持久化：agent.ts#L373-L389。
4. 下一轮请求重放历史消息时，pi-ai 严格要求 state.blocks.length === message.content.length，因此命中截图里的错误：replay.ts#L159-L167。

因此，最可能的触发条件不是任意 length stop，而是 到达输出上限时，响应里已经开始产生一个 tool call；durable message 安全地丢掉了它，但 replay state 仍记录着它。

临时恢复建议：

1. 新建会话，或从发生截断的 assistant message 之前创建分支，再继续任务；在当前已写入不一致历史的会话里反复重试，下一轮仍会重放同一条坏状态。
2. 在新会话中提高该 route 的输出 maxTokens，或要求模型分段输出、先给摘要再执行工具，降低在 tool call 中途撞上上限的概率。
3. 如果 provider 和模型配置里有不同的 context/output 上限，检查最终 resolved config，而不是只看模型宣传的 context window；这里是输出 cap，不等同于输入上下文上限。
4. 不建议手工编辑 session JSON，除非先完整备份并能校验事件链；直接从截断前分支恢复更稳妥。

修复方向也比较明确：在 max-tokens 路径中，附加到 durable assistant message 的 replay metadata 必须与 assembler.blocks() 的最终内容保持同一投影。最小做法可以是在内容被过滤时不持久化该 replay state；更完整的做法是同步过滤对应的 replay blocks，并补一个“text + 截断 tool-call + length → 下一轮可重放”的回归测试。