Pi 1.0：更轻的工具编排，仍需逐项恢复

Pi 1.0 于 10 月 1 日发布。一个工具脚本可以查资料、整理结果，再把需要的部分交给模型。发行说明提到压缩 codemode 提示、提供更明确的错误恢复提示，并修复会话恢复或 reload 时丢失延迟加载 MCP 工具的问题。这些变化解决了调用入口与会话连续性中的具体问题，尚不能说明所有业务的交付成本都会下降。 [1]

对开发者和内容团队，更值得关注的是多步工作如何交接。工具描述少占一些上下文，有机会把预算留给资料和判断；但一次脚本里跑了几项工作，最后一句“失败”并不能说明每项工作都失败了。效率改善越明显，越需要看清局部结果。

假设一个内容团队同时检索四份资料，再生成选题表。把独立查询放进一次编排，可以减少模型逐条接收大量原始材料的负担。这是适用场景推演，并非我们的 Pi 实测。对于大量重复查询，入口开销值得优化；资料复杂、核对费时的工作，收益也可能被后续修订抵消。

所以比较的单位应当是一份能使用的选题表，或一个通过审查的改动。除了模型请求，还应计算漏掉的结果、补查次数、重复写入和人的核对时间。如果一次提示更精简的运行留下两个状态不明的动作，团队可能只是把成本从生成阶段移到了接手阶段。

锁定在 v1.0.0 的 codemode 文档说明：失败脚本保留部分输出，失败前已经执行的工具调用不会自动撤销；脚本结束时仍在运行的调用会取消，未等待的 Promise 会被丢弃。这是该版本文档描述的现有执行语义，不能说成 1.0 新增能力，也不能据此判断远端服务已撤销请求或副作用。 [2]

设想脚本先把资料存入工作区，再创建任务，最后整理摘要时遇到错误。摘要失败不会让前面的资料和任务消失。若下一轮照原样重跑，可能产生重复任务；若直接接受部分输出，又可能漏掉没有完成的资料。需要恢复的是具体动作的状态，单个脚本的成功或失败标记不够。

工具接口应当返回可核对的对象，例如文件路径、任务编号或服务端状态。恢复过程先查询这些对象，辨认已经完成、明确未完成和仍然未知的动作，再决定补跑范围。这里的建议针对外部系统的工程设计，不是宣称 Pi 已经替所有工具实现了这套机制。

四次资料查询彼此独立，适合并行；上传文件后取得编号，再用编号创建记录，则有明确依赖。把两类调用混在同一批里，可能让后续动作抢在前置条件成立之前执行。编排减少往返，不代表原有业务顺序可以省略。

在独立查询的场景里，团队可以保留每一项的结果和错误，避免一项失败遮住其他已完成的工作。还应检查“请求成功但内容为空”“接口返回错误字段”等情况。Promise 已完成只能说明程序取得了返回值，是否满足业务请求，需要读取工具的实际结果。

更具体的错误提示可以缩短查错过程，例如帮助模型辨认成员名或参数形状。但模型修好脚本后，仍需知道上一次留下了什么。错误消息解释代码为什么停下，外部回执解释工作实际上走到了哪里；两者承担不同职责。

发行说明中的延迟 MCP 工具恢复修复，也不应被解读成所有业务状态都已恢复。工具重新出现在会话中，解决了继续调用的可用性问题；任务是否重复创建、文件是否完整上传，仍需要相应系统确认。把工具清单恢复和业务结果恢复分开，才能判断下一步依赖什么。

一个小实验比一长串功能表更能说明编排是否适用。选两项只读查询和一项在隔离环境中的写入，让其中一次查询故意失败，观察最终记录能否准确指出各项状态。随后重新进入会话，尝试只补做缺失的一项，而不是把整个脚本再运行一遍。

再增加一种更难的情况：外部写入已完成，但客户端没有拿到回执。此时正确结果可以是先查询、暂缓重试，或交给负责人判断。实验应检查程序如何处理未知状态，而不是强求模型每次都立即继续。没有重复动作、没有遗漏结果，才是这次实验真正需要确认的变化。

工具编排不必给用户展示每一次底层调用。内容团队需要的是资料来源和缺项说明；开发者需要的是改动、检查结果和尚未完成的依赖。可以把详细调用记录留在后台，只在交接处呈现影响下一步判断的结果，让界面保持简洁。

一个合理的反对意见是：对成本低、没有副作用的只读查询，整批重试往往更简单，逐项台账也会增加维护负担。恢复设计应随动作的后果和重做成本变化。优先为写入、依赖链或昂贵步骤保留明确回执，不必把所有检索都变成复杂的事务流程。

我们没有安装运行 Pi，也没有复现官方样例或恢复修复。本文提出的是采用前值得验证的工程问题。Pi 1.0 提供了一个具体机会：缩小调用入口的负担，同时让团队重新检查批量执行的交接质量。调用入口更精简之后，下一位接手者仍应能够判断哪些已经完成，哪些需要继续。