Pi Agent 扩展选型指南：联网、记忆、子 Agent、MCP 与上下文优化

Pi Agent 的吸引力之一，是它把很多原本固定在产品里的能力拆成了可以自己组合的扩展。你可以按自己的工作方式增加联网、记忆、待办、子 Agent、MCP 和上下文管理能力，也可以隐藏不常用的模块，让主会话保持干净。

但扩展越多不一定越高效。每个扩展都可能引入新的工具、权限、上下文、依赖和维护成本。真正值得安装的扩展，应该能明确解决一个重复出现的问题，并且能够被验证、观测和回滚。

本文整理炎朗 Gavin 于 2026 年 8 月 30 日发布的 Pi Agent 扩展推荐，按“能力—场景—风险—验收”的方式重新编排。文中第三方扩展名称和能力以原帖描述为参考，具体版本、命令、许可证、兼容性和安全范围请以各自项目当前说明为准。它们不代表 GPT88 的官方背书。

一、先看六类扩展分别解决什么问题

能力	代表扩展	解决的问题	适合的任务
联网访问	pi-web-access	搜索、抓取、仓库、PDF 和视频内容	研究、资料核对、代码库调查
长期记忆	pi-memory	保存长期记忆、每日记录和临时笔记	长项目、个人工作习惯、连续研究
任务管理	rpiv-todo	将任务列表放在 Agent 可读、可持续的状态层	多步骤改造、迁移、交付任务
子 Agent 编排	pi-subagents	并行、串行、隔离 worktree 和预算管理	复杂开发、审查、研究分工
MCP 接入	pi-mcp-adapter	动态连接 MCP Server，避免一次加载全部工具	多工具工作台、企业内部服务
上下文优化	context-mode	压缩工具结果、文件内容和中间执行过程	长会话、大文件、批量工具调用

可以把它们放进一条工作流：

联网获取资料
  → 记忆和 scratchpad 保存关键结论
  → Todo 记录阶段目标
  → 子 Agent 分工执行
  → MCP / Tool 调用外部能力
  → Context Mode 压缩中间结果
  → 主 Agent 汇总并验证

这条链路的前提是每一层职责清楚。联网扩展不应该偷偷修改代码，记忆扩展不应该保存密钥，子 Agent 不应该绕过权限，Context 压缩也不应该丢失验收所需的事实。

二、pi-web-access：给 Agent 一套联网工具箱

它适合做什么？

原帖将 pi-web-access 描述为一套网络访问扩展，可能覆盖：

• 网页搜索；
• URL 抓取；
• GitHub 仓库克隆；
• PDF 文本提取；
• YouTube 视频理解；
• 本地视频处理；
• 多种搜索后端。

它的价值不在于“让 Agent 可以上网”，而在于把研究任务和代码任务连接起来。例如：

搜索官方文档
  → 抓取正文
  → 提取 API 字段
  → 对照本地代码
  → 生成实现建议

推荐使用方式

研究任务最好与写代码任务分离：

1. Researcher 负责搜索和抓取；
2. 将来源、日期、结论和不确定性保存为短报告；
3. Worker 只使用已经确认的结论修改代码；
4. Reviewer 检查引用和实现是否一致。

这样可以减少外部网页中的错误信息直接影响代码的风险。

安全边界

联网扩展通常会引入网络访问、网页内容解析、仓库下载甚至本地媒体读取能力。使用前要确认：

• 哪些域名允许访问；
• 是否会自动执行网页中的代码或脚本；
• GitHub 仓库是否只读克隆；
• PDF 和视频是否会上传到第三方服务；
• 搜索 API Key 保存在哪里；
• 抓取内容是否会进入 Prompt 或长期记忆；
• 大型响应是否有大小限制。

不要把网页抓取结果视为事实本身。对价格、API、许可证、法律条款和安全建议，仍应回到官方来源核对。

三、pi-memory：让长项目拥有可检索记忆

它记录什么？

pi-memory 的典型设计包括：

• MEMORY.md：长期稳定信息；
• 每日日志：按日期记录工作过程；
• Scratchpad：当前任务的临时状态；
• 语义检索：通过类似 memory_search 的能力找回历史内容。

它解决的是“每次都重新解释背景”的问题，但记忆系统不是越完整越好。应该区分：

类型	应该保存什么	不应该保存什么
长期记忆	稳定偏好、项目约定、重要决策	一次性临时猜测
每日日志	日期、任务、结果、阻塞和下一步	完整密钥和原始敏感响应
Scratchpad	当前任务、假设、待验证事项	永久事实
检索索引	可复用结论和来源	未验证的传闻

记忆写入原则

建议每次写入记忆时带上：

• 事实或结论；
• 来源；
• 日期；
• 置信度；
• 适用范围；
• 失效或复核条件。

例如：

结论：项目使用 pnpm，而不是 npm。
来源：仓库 packageManager 字段。
日期：2026-08-30。
范围：当前仓库。
复核条件：package.json 或锁文件发生变化。

不要让 Agent 自动把所有对话写进长期记忆。错误信息、临时 Prompt 和未验证推断一旦被长期检索，后续任务会不断重复错误。

隐私与清理

记忆目录应加入明确的忽略和备份策略：

• API Key、密码、Cookie 和 Token 不进入记忆；
• 客户数据和生产日志只保存脱敏摘要；
• 记忆文件应纳入访问控制；
• 定期清理过时结论；
• 支持按项目删除和导出；
• 检查语义索引是否复制了原始敏感内容。

四、rpiv-todo：把待办变成 Agent 可用的状态

普通待办列表解决的是“人记不记得要做什么”，而 Agent 任务还需要记录：

• 当前阶段；
• 依赖关系；
• 阻塞原因；
• 产物位置；
• 验证证据；
• 下一步动作。

因此，一个适合 Agent 的 Todo 不应该只有 checkbox，而应该包含结构化状态：

任务：迁移博客文章
状态：in_progress
依赖：确认原文与目标栏目
产物：src/data/blog/posts/example.md
验证：lint、build、route audit
阻塞：等待来源字幕

如果 Todo 能以实时 overlay 显示，并且跨 /reload 和上下文压缩存活，它就能帮助用户快速了解长任务状态。但它仍然不能代替测试、日志和实际产物。

什么时候使用 Todo？

适合：

• 多个文件和多个阶段的迁移；
• 需要等待外部事件的任务；
• 需要多个子 Agent 协作的工作；
• 长时间运行的部署或批量处理；
• 需要明确交付物和验收证据的项目。

不适合：

• 一行配置修改；
• 可以在一个短会话内完成的查询；
• 用待办掩盖没有明确目标的任务。

五、pi-subagents：把复杂任务拆成可控工作流

子 Agent 编排是这组扩展中最容易带来效率提升，也最容易失控的一类能力。

推荐的角色分工

父 Agent
  ├── scout：只读侦察结构、调用链和风险
  ├── researcher：只读查找外部资料
  ├── worker：在明确范围内修改代码
  └── reviewer：使用全新上下文审查 diff、测试和边界

并行和串行要区分：

• 独立任务可以并行；
• 有依赖的阶段必须串行；
• reviewer 可以并行读取，但不应与 worker 同时写同一目录；
• 需要隔离时使用 worktree；
• 父 Agent 负责汇总和最终拍板。

预算和停止条件

每个子 Agent 应明确：

• 输入范围；
• 输出格式；
• 最大时间或 Token 预算；
• 是否允许联网；
• 是否允许写文件；
• 完成条件；
• 阻塞条件；
• 失败后是否重试。

不要把同一句 Prompt 复制给多个 Agent 就称为并行。更有意义的拆分是一个 Agent 看本地代码，一个 Agent 查外部资料，一个 Agent 审查实现，三者拥有不同输入和产物。

关键并发规则

同一目录同一时间只保留一个 writer
reviewer 可以并行只读
多个 writer 必须使用隔离 worktree
最终合并由父 Agent 统一完成

如果一个 Agent 能解决小任务，就不要强行引入并行。并行的成本包括上下文复制、结果汇总、冲突处理和额外模型调用。

六、pi-mcp-adapter：动态接入 MCP，而不是预加载全部工具

MCP 让 Agent 可以连接数据库、项目管理、消息系统、内部 API 和其它外部服务，但工具数量增长后，全部加载 Schema 会造成上下文膨胀。

动态 MCP 适配器的目标是：

当前任务
  → 判断需要哪类工具
  → 动态连接对应 MCP Server
  → 只加载必要工具
  → 调用并返回摘要

这样可以减少：

• 初始 Prompt 的工具定义；
• 每轮重复发送的 Schema；
• 工具选择歧义；
• 无关服务的权限暴露。

MCP 接入的审查清单

连接一个 MCP Server 前，先确认：

• 它能读取哪些数据；
• 它能执行哪些写操作；
• 是否会访问网络；
• 鉴权信息如何保存；
• 工具参数是否有 Schema 校验；
• 写操作是否支持审批和幂等；
• 返回结果是否脱敏和限量；
• Server 断开后是否会残留进程或权限。

动态加载减少上下文，并不等于自动安全。MCP Server 仍然是可执行的外部能力，应当按第三方代码和外部集成来审查。

七、context-mode：减少中间结果对主上下文的污染

长会话中，工具结果、文件内容、轮询响应和中间日志会不断进入上下文。即使最终答案只需要一个摘要，模型也可能在后续每一轮重复携带这些内容。

Context Mode 的核心思想是把执行过程和主上下文分离：

主 Agent 发起任务
  → 工具或脚本在执行上下文中工作
  → 中间结果在子进程 / MCP 侧处理
  → 只把结论、错误和必要证据带回主上下文

它特别适合：

• 读取大文件；
• 批量搜索；
• 多页网页抓取；
• 数据库查询与轮询；
• 图片、视频或文档处理；
• 生成大量候选结果后做摘要。

压缩不能丢掉什么？

压缩时至少保留：

• 输入条件；
• 执行命令或工具名；
• 成功或失败状态；
• 关键错误；
• 结果摘要；
• 影响验收的数值和路径；
• 下一步动作；
• 原始证据的可追溯位置。

不要只返回“执行成功”。如果后续需要判断是否真的完成，主 Agent 必须能够看到足够的证据。

八、如何组合这些扩展？

场景一：研究并改造一个陌生仓库

推荐流程：

1. pi-web-access 查官方文档和相关仓库；
2. Researcher 保存来源和结论；
3. pi-subagents 派 Scout 检查本地目录；
4. Todo 记录发现、风险和改造阶段；
5. Worker 实施最小修改；
6. Reviewer 检查 diff 和测试；
7. pi-memory 保存项目级稳定决策。

场景二：长期维护一个 Coding Agent 项目

建议使用：

• AGENTS.md 记录固定纪律；
• pi-memory 保存稳定架构决策；
• Todo 保存当前迭代状态；
• pi-context-mode 控制长会话和大结果；
• pi-subagents 分离研究、实现和审查。

场景三：管理大量企业工具

当 Agent 需要连接多个内部 API、数据库和 SaaS 工具时：

1. 用 pi-mcp-adapter 动态选择 MCP Server；
2. 用工具搜索或 CLI 只暴露当前需要的能力；
3. 用 Context Mode 处理分页、轮询和批量结果；
4. 对写操作保留审批和幂等键；
5. 在状态栏或日志中显示调用成本、失败和重试。

场景四：接入 GPT88 API 的 Agent 工作台

对于通过 GPT88 API 运行的 Pi 或其它 Agent，可以先使用 GPT88 快速开始 验证 API Key、Base URL 和模型，再逐步增加扩展：

GPT88 API 最小请求
  → Pi 基础对话
  → 联网扩展
  → 记忆和 Todo
  → 子 Agent
  → MCP
  → Context 压缩

不要同时引入全部扩展。每增加一个扩展，就运行一次最小任务和安全检查，这样出现问题时容易定位。

九、安装顺序与最小可用组合

建议从最小组合开始：

第一阶段：规则和验证

• 写好全局、项目级 AGENTS.md；
• 明确模型、工具、文件和 Shell 权限；
• 先完成一个只读任务和一次测试验证。

第二阶段：一个控制面扩展

根据最常见痛点选择一个：

• 长任务多：先加 Todo；
• 任务拆分多：先加子 Agent 编排；
• 工具太多：先加动态 MCP；
• 上下文经常爆：先加 Context Mode；
• 需要长期积累：先加 Memory；
• 研究工作多：先加 Web Access。

第三阶段：逐步组合

每次只增加一个扩展，记录：

• 包名和版本；
• 来源仓库；
• 安装脚本；
• 读取、写入和网络权限；
• 配置文件位置；
• 首次测试任务；
• 卸载和回滚方法。

十、常见误区与故障排查

安装后 Agent 变慢

先检查是否新增了大量工具 Schema、长期记忆内容或索引初始化。解决方式通常是隐藏低频扩展、动态加载工具、压缩大结果或减少常驻 Prompt。

子 Agent 越多，结果越乱

检查任务是否真的独立、输入是否明确、输出是否结构化，以及是否出现多个 writer 同时修改同一目录。减少并行数量通常比继续增加 Agent 更有效。

Memory 让 Agent 反复犯旧错误

检查记忆是否包含未验证推断、过期配置或缺少来源和日期。为记忆增加置信度、适用范围和复核条件，并定期清理。

MCP 工具调用失败

先单独验证 MCP Server，再检查鉴权、参数 Schema、网络、权限和超时。不要一开始同时更换模型、MCP Server 和 Prompt。

Context 压缩后无法验收

检查压缩摘要是否丢失了路径、状态码、错误、测试结果或关键数值。压缩的目标是减少冗余，不是删除证据。

十一、安全验收清单

• 每个扩展的源码、许可证、版本和维护状态已经检查；
• API Key、Cookie、Token 和密码不会进入 Memory 或日志；
• 联网扩展有明确的域名和数据上传边界；
• MCP Server 的读写权限和网络权限已审查；
• 高风险工具调用需要人工确认；
• 同一目录同一时间只有一个 writer；
• 子 Agent 有输入、输出、预算和停止条件；
• Todo 记录产物和验证证据，而不只是 checkbox；
• Context 压缩保留关键错误、状态和验收信息；
• 记忆内容带有来源、日期和适用范围；
• 每个扩展都能单独禁用或回滚；
• 扩展升级后重新完成最小回归任务；
• GPT88 的模型、价格、配额和 API 路径以当前控制台和文档为准。

总结：扩展的价值在于让工作流更可控

Pi Agent 扩展可以把一个简单的对话工具，逐步扩展成具备联网、记忆、任务管理、子 Agent、MCP 和上下文治理能力的 Coding Harness。

但真正的效率来自合理分层：

AGENTS.md 管纪律
Skills 管方法
Extensions / Packages 管控制面
Tools 管受控动作
Tests、Logs 和 Review 管证据

如果只记住一条建议，就是：先根据最常见的痛点选择一个扩展，跑通一个可验证任务，再逐层增加能力。联网、记忆、并行、MCP 和上下文压缩都很有价值，但每一种能力都应该有明确边界、可观察结果和安全回滚路径。

本文整理自 炎朗 Gavin 在 X 发布的 Pi Agent 扩展推荐。原帖中的第三方扩展名称、功能、安装命令和兼容性可能随项目更新变化；本文是结构化实践整理，不代表 GPT88 对这些项目的官方推荐或安全保证。使用前请查看对应仓库的源码、README、权限、许可证和最新发行说明。