第四版之后又用了一个月，Pi 也从 0.85.0 一路更新到了 1.0.2 。这段时间除了跟着升级插件，我又调整了一轮自己的工作流，继续记录一下。 第一次安装 Pi 的佬友可以先看前四篇。 前四版 （点击了解更多详细信息） 本版：编写于 2026 年 10 月 5 日，Pi 1.0.2 。 实际上 Pi 更新到 1.0.0 大版本以来都是一些新可选特性，这篇记录的是我自己的升级选择。新增能力、插件替换和参数偏好都可以按需取用；决定迁移某一部分后，再做对应的配置调整，不用整套照搬。 这次最大的变化是 Pi 已经有了原生支持的 MCP 和工具编排能力，原来要靠插件实现的 MCP，现在直接使用原生能力即可；顺便换了个 Goal 和回退的 rewind 插件。 项目 第四版 当前状态 MCP pi-mcp-adapter ，用 lifecycle/directTools 配置 移除插件，使用原生 mcp.json 和 exposure/toolExposure 工具编排 主要由模型逐次调用，部分任务交给 context-mode 显式启用原生 codemode 和 tool_search 持续执行 pi-until-done 换成 @narumitw/pi-goal 文件回退 pi-rewind 换成 pi-rewind-hook ，通过 /tree 、 /fork 选择文件恢复 Plan 子代理桥接 根据 Plan 工具是否可见判断模式 改读当前会话分支的 plan-mode-state.enabled 普通子代理 第四版仍在补齐模型继承 现有角色统一 model: inherit ，思考等级统一为 low Magic Context 0.41.3 0.45.0 ，清理旧字段，开启 smart_drops 结束通知 @pi-unipi/notify 同时开启 agent_end 和 agent_settled 关闭 agent_end ，减少重复提醒 简化插件 使用 pi-simplify 已移除 这次迭代移除/替换的插件共四个： pi-mcp-adapter 、 pi-until-done 、 pi-rewind 和 pi-simplify 。 第四版以来，Pi 本体更新了什么 先简单过一下这一个月本体的变化。这里挑的是和我这套工作流关系比较大的几项。 版本与日期 主要变化 0.86.0 支持按模型设置压缩预留量和最近内容保留量，新增可配置的提示缓存保温；会话中的提示词与工具声明变更也能随恢复、分支切换保留 0.87.0 上下文扩展有了正式的编辑接口，可以调整发给模型的内容而保留原始历史；修复扩展过滤上下文后丢失提示词和工具声明的问题 0.99.0 原生 MCP、 codemode 和 tool_search 加入内置扩展； defaultTools 支持 +工具名 、 -工具名 的增量配置 0.99.2 优化 MCP 工具按需发现，默认 Codemode 暴露的服务不再阻塞首轮请求；修复 Windows 独立可执行版无法启动 Codemode 脚本进程的问题 1.0.0 TUI 默认全屏；精简 Codemode 的工具说明与提示词，改善调用错误提示，并加入脚本调用图像生成模型的能力 1.0.1 项目可以通过 .pi/mcp.json 单独覆盖全局 MCP 服务的启用状态和工具暴露方式 1.0.2 新增 samplingParamsByThinkingLevel ，可在 OpenAI 兼容接口中按思考等级设置采样参数 对我来说，影响工作流比较大的是原生 MCP 和工具编排。 使用 Pi 本体原生 MCP 能力 Pi 既然已经提供了原生 MCP，那我个人觉得就没必要保留插件了， 因为其实每次更新都要等插件适配，插件越多，越难跟上迭代，所以还不如少装点插件。 下面的卸载和配置步骤适用于准备迁移到原生 MCP 的佬友；仍需要 MCP 插件特有功能的，可以先评估再决定是否迁移。 而且原来的 MPC 插件只要仍被加载并注册了 /mcp ，就会接管会话里的 MCP，Pi 不会按原生方式读取 mcp.json 。所以我直接卸载原来用的 pi-mcp-adapter 。 pi remove npm:pi-mcp-adapter 卸载后，再把 ~/.pi/agent/mcp.json 改成原生格式。第四版用 lifecycle: eager/lazy 控制连接时机，用 directTools 决定工具是否直接出现在模型面前；迁移后，这两个概念不能直接套到原生格式里，为此我们需要先了解一下 原生格式的 MCP 配置 如何写。 原生 MCP 会在会话启动时，后台连接所有启用的服务。 exposure: deferred 延后的是工具声明，不代表等到调用时才启动服务。首轮请求只会为具有 direct 工具的服务等待，最多 10 秒；其他服务在需要时等待连接。 所以，如果只是想少给模型塞工具定义，可以用 deferred 或 codemode ；如果根本不想启动某个服务，要用 enabled: false 。 原生工具暴露方式有这几种： exposure 用法 direct 直接把工具声明给模型，也能在 Codemode 中调用 deferred 先通过 tool_search 找到，再为后续模型请求加载工具声明 codemode 默认方式，通过脚本发现并调用，不预先直接声明完整工具 hidden 工具不可调用；不等于关闭服务连接 codemode 和 deferred 都可以通过原生的间接发现机制访问。 我个人用的 MCP 迁移后，各个服务的工具暴露方式我是这样分配： 服务 当前配置 context-mode direct sequential-thinking direct mcp-server-time direct shrimp-task-manager direct mcp-deepwiki direct context7-1 服务为 deferred ，两个常用文档工具单独设为 direct playwright deferred chrome-devtools-mcp deferred 经常用的文档、时间、任务和上下文工具直接给模型，浏览器那一大组工具需要时再找。各位可以参考。 mcp.json （点击了解更多详细信息） 配置位置是 ~/.pi/agent/mcp.json 。上面的用户名和数据目录要换成自己的实际路径。我这里用的是 cmd /c 启动 Windows 的 npx 服务。 Context7 的 toolExposure 要注意：键名是服务器原始工具名，所以写 resolve-library-id ，不是完整的 mcp__context7_1__resolve_library_id 。 迁移完成后建议先重新启动 Pi，再用会话里的 /mcp 查看连接、工具名和暴露方式。终端里的 pi mcp list 也能检查。 Codemode 和 tool_search：按需找工具，批量处理调用 顺便介绍一下这两个特性，它们都是最近 Pi 更新的新特性，也有一些讨论，先简单介绍一下这两个能力。 介绍 一句话，你可以把它们理解为： tool_search 帮 AI 找到合适的工具， codemode 帮 AI 把多个工具调用组织起来。 比如你让 AI“查阅某个库的官方文档，再结合项目配置提出修改建议”，AI 需要先知道有哪些工具可以用( tool_search )，然后决定如何调用（ codemode ）。 能力 tool_search codemode 主要用途 找工具，了解工具怎么调用 用一小段代码调用工具、处理结果 典型场景 不知道哪个 MCP 工具能查文档 同时查几份独立资料，再提取需要的内容 返回什么 匹配的工具及其调用说明 脚本选择输出的执行结果 带来的好处 不必一开始就把所有工具说明塞给 AI 减少来回调用，减少无关结果进入上下文 tool_search 像工具目录里的搜索框。 你的 Pi 接入了很多工具，包括文件操作、文档查询、浏览器操作等。如果把每个工具的完整说明都提前交给 AI，会占用上下文。 有了 tool_search ，部分工具可以先不展开说明。AI 需要查库文档时，再搜索“查找库的官方文档”，获取对应工具的名称、参数和说明，然后调用它。 这里要分清两件事： 搜索“查文档的工具”，是在找工具。 调用找到的文档工具，才是在查文档。 codemode 像让 AI 写一张可以执行的工作单。 普通调用可能是： 读取文件 A，拿到结果。 读取文件 B，拿到结果。 读取文件 C，拿到结果。 从三份内容中整理出需要的信息。 用 codemode ，AI 实现： 同时读取 A、B、C，提取各自的模型配置，只把这部分内容返回。 这里真正读取文件的仍然是 Pi 的读取工具。 codemode 只是负责安排调用顺序、并行执行和整理结果。对于大结果，它还可以先筛选，避免把整份内容都送进 AI 的上下文。 它同样能安排编辑，但有依赖的操作仍要按顺序进行。例如必须先读到当前文件内容，才能据此构造准确的修改。 两者可以配合使用，也可以各自使用。 例如你要求“查三个库的最新版配置方式”： tool_search 找到合适的文档查询工具，取得调用说明。 codemode 并行查询三个互不依赖的库。 脚本提取相关配置段落和来源，交给 AI 整理答案。 如果只是“读取这个文件”，直接调用读取工具就够了。如果查询工具已经明确，也可以直接通过 codemode 调用，省去搜索步骤。 想尝试这两个新特性，可以在 settings.json.defaultTools 里添加 codemode 和 tool_search ，按需选择其中一个或同时启用。下面是我同时启用的配置： 当前默认工具配置 （点击了解更多详细信息） mode: on 会保留原本直接声明的工具。例如，简单读一个文件，模型仍然可以直接调用 read ；需要批量读取几个独立文件、并行查询，或者从很大的返回结果里挑出必要字段时，再用 Codemode。 如果选择 only 则会把其他工具从直接声明中隐藏，主要通过脚本调用。 对 Codemode 感兴趣的还可以看官方文档了解更多 Codemode Plan 同步工具名，更新本地桥接 这一节适用于使用 Plan 且迁移了 MCP 的配置；后面的本地桥接代码，也只需要复制过第三版扩展的佬友更新。 原生 MCP 的工具名改成了 mcp__<服务>__<工具> ，连字符等字符会归一化。以前写进 Plan 工具列表的名字，也要跟着调整。 旧插件工具名示例 现在的原生名称 context7-1_query-docs mcp__context7_1__query_docs context-mode_ctx_index mcp__context_mode__ctx_index context-mode_ctx_execute mcp__context_mode__ctx_execute mcp-deepwiki_ask_wiki_question mcp__mcp_deepwiki__ask_wiki_question 遇到工具名冲突时 Pi 还可能追加标识，所以最终以 /mcp 或工具发现结果为准。 我的 ~/.pi/agent/pi-plan-mode.json 如下，各位可以参考： defaultPlanTools 的相关条目 （点击了解更多详细信息） 注意： 编排工具和被调用工具要分别选择。 只允许 codemode ，不代表允许它调用任意工具； Plan 会在工作流第一次向模型发送上下文时解析并冻结可执行工具列表。修改配置后，不能在原来的 Plan 中通过 /reload 就能放行新工具。 同时，针对第三版的本地 plan-subagent-ceiling 扩展检查 plan_mode_question 、 plan_mode_complete 是否在 active tools 中。新版 Plan 为了保持工具声明稳定，会在普通模式中继续保留这些工具，真正调用时才判断工作流状态。 因此旧判断可能把普通模式也当成 Plan，继续限制只能启动三个 plan-* 角色。现在改为读取当前会话分支最后一条 plan-mode-state 的 enabled ，并在退出 Plan、切换会话树时释放旧限制。 如果你复制过第三版的本地扩展，下面这份可以完整替换自己的 ~/.pi/agent/extensions/plan-subagent-ceiling/index.ts 。 当前 plan-subagent-ceiling/index.ts （点击了解更多详细信息） 两个插件替换 这两个插件的替换的最直接原因就是其作者更新迭代对齐 pi 版本太慢了，更新太慢了，当时的 pi-rewind 只把 write/edit/bash 纳入变更工具集合，没有覆盖我已经在用的原生 powershell pi-until-done 则是当时声明的适配版本落后于我的 Pi 版本，看了 github 很久也没适配，所以我干脆换成了更新适配更加积极的 @narumitw/pi-goal 。 这是按我实际使用需求做的替换，可以分别选择。决定更换哪一项，就执行对应旧插件的卸载和新插件的安装命令： pi remove npm:pi-rewind pi remove npm:pi-until-done 再安装对应的替代插件：文件回退用 pi-rewind-hook ，goal 用 @narumitw/pi-goal 。 pi install npm:pi-rewind-hook pi install npm:@narumitw/pi-goal 完成替换后，再分别配置下面的 Goal 续跑限制和 Rewind 检查点显示。 Goal 边界 配置在 ~/.pi/agent/pi-goal.json ： 下面是我显式写下的默认限制，次数可以按任务调整；后面的 token 预算也是每个目标可单独选择的设置。 { "rpc": { "enabled": false }, "continuationLimits": { "automaticTurns": 25, "noProgressTurns": 3 } } 日常在 Pi 输入

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/10/5 17:09:16