nicobailon/pi-subagents

如果你已经在 Pi 里写代码，想要在不离开对话的情况下获得第二意见或独立的实现环节，这个扩展值得一试。它不是独立工具，价值很依赖 Pi 在你所用环境中的工具激活方式。

解决什么问题

你正在 Pi 会话里处理一个 diff 或一份计划，想同时让评审者、代码侦察者或实现者工作。往常这需要把上下文复制到另一个会话或模型，再把结果粘回来对账。pi-subagents 换了这一步：你用自然语言点名某个角色，Pi 就启动一个带着独立任务的子会话，并把结果带回父对话。于是评审、侦察和实现变成你可以查看、干预或放到后台的独立工作流。

扩展自带 scout、reviewer、worker、oracle 等内置角色，第一次试用不需要写代理配置。README 推荐的实现流程是 clarify → scout → worker → 新的 reviewer → worker 项目说明。

有什么不同

它的机制是分派，不是新模型：每个子代理都是一个专注的子 Pi 会话，前台运行在父进程内流式输出，后台子代理跑在分离的 runner 进程里，之后可以查看 后台执行说明。这种拆分的好处很实际——慢评审或多轮循环不再阻塞父对话，FleetView 或 fleet 检查器还能浏览转录、叫停某个子代理 可观测性。

这里还有一层刻意的激活设计。对于能在对话中途接受新工具的模型，新会话起初只暴露一个小的 subagents_enable 加载器，而不是完整的 subagent schema；完整工具会在下一次模型请求时出现，其他模型则一开始就激活 subagent，以保留 prompt 缓存 toolActivation。这样安装后不会自动开一个评审者，但也意味着只有你的请求或指令授权时才会分派——任务复杂本身不算授权。代价是首次使用没那么直接，换来的是更少的意外。

更大的编排可以用保存的工作流、脚本化链条、任务记录和 council 式的多模型辩论 工作流 任务与调度。自定义代理、按角色选模型和代理记忆在对应文档里配置 代理 模型。网页研究角色要求子代理具备网页访问能力，运行树累计生成上限默认是 64 网页研究前提 生成上限。

谁值得试

适合已经在用 Pi 1.2.0 及以上、想要可重复的评审加实现循环、对不同关注点并行评审，或让后台任务在交还控制权后继续工作的人。只想在别的聊天客户端里要一次第二意见的人，装了用不上。

关于后台执行，文档给了一条影响适用范围的说明：npm 版 Pi 使用自带的分离 Node runner，官方 Pi 1.2.0 Linux x64 standalone 版本则通过 Pi 内置 SDK 加载同一个 runner，无需单独安装 SDK 后台执行说明。其他发行版用户应先确认自己的环境是否在覆盖范围内，再依赖后台子代理。

使用条件与边界

这是 Pi 的扩展，不是通用代理运行时：没有 Pi 就无从安装，且需要 Pi 1.2.0 或更新版本。内置的 researcher 和 evidence-auditor 角色要求子代理装有 pi-web-access 网页研究前提，后台行为也取决于你用的 Pi 发行方式 后台执行说明。

配置层面最影响体验的是累计生成上限、并发数和按角色选模型；默认值有文档，但 64 次生成上限和你的模型分层是否匹配，只有你自己判断 生成上限 模型。安装只需一条命令加一次 /subagents-doctor 检查，但后续要持续决定哪些会话授权分派、查看后台运行结果，而不是默认它们正确。README 没有说明每次运行的成本控制，预算相关行为需要在你的环境里自行核实。

HotRepo 点评

目前唯一的日期信号是 2026-10-26：项目当天出现在日榜，4,071 stars，当日 +31。仅一天的数据不足以判断持续性，应把它当作一次被观测到的关注，而不是趋势；仓库创建于 2026 年 1 月。

采用判断：如果 Pi 已经是你的编码环境，并且你想要按角色分派，值得试；先确认你的 Pi 版本和发行方式支持后台子代理，以及工具激活是否与所用模型的缓存策略相符 toolActivation。