ARTICLE · 981023
我给AI派了7个“分身”,最后却把它卸载了——pi‑subagents深度实测
pi‑subagents，它可以把侦察、编码、审查拆成独立分身。我经过多方对比最终选用这个扩展，原本希望用它把脏活移出主会话，保护主Agent的上下文。但一次真实Bug调试完整实测下来，算完时间与Token两笔账才发现：很多场景，花哨的多代理不仅不提速，反而徒增巨大隐性开销。在开始前，先记下我最后复盘出的两句话——如果你也在考虑上子代理，不妨先问自己：
这个任务，是否真的可以拆分成多项互相独立、可以并行推进的工作？ 我是否愿意承担代理启动、上下文重建、常驻Schema带来的时间与Token成本？
先简单介绍主角 pi‑subagents：它是Pi编码助手的热门第三方扩展，也是圈子里被广泛推荐的子代理方案。它内置多套专用角色：scout负责只读代码勘察、worker负责代码实现修改、reviewer做独立代码评审，还支持workflow编排、同步/异步任务、多工作区隔离。设计初衷是将部分任务委派给隔离的子进程执行，把阅读、大规模分析、试错类工作剥离出主会话，以此保护主Agent的上下文窗口，让主模型专注做高层决策。市面上还有不少其他子代理实现，本文体验结论仅针对 pi‑subagents，不代表全部同类工具。
说实话，我不是一时兴起。子代理工具我对比了好几家，最后才选了 pi‑subagents。而且我从一开始就清楚：子代理并不能省Token——我看中的是另一件事，把大量阅读、分析、试错从主会话里挪出去，保护主Agent的上下文空间。上下文是 AI 干活的本钱，越干净，它对当前问题的理解就越准。
于是我安装了 pi‑subagents，拿一个真实线上缺陷，开启了这场“AI团队协作”的调试。
一、热闹的“团队协作”，实际却是反复返工
我遇到了一个比较棘手的程序Bug：某一项功能第一次执行就报错失败，第二次重新执行又能够正常跑通。
从日志可以看到很典型的异常现象：首次运行时使用了超出有效范围的参数，直接导致执行失败；第二次运行经过内部状态刷新，参数回归正常，流程就成功了。问题根源属于典型的时序、数据状态归属类缺陷，会跨好几个业务模块，排查链路比较绕。
完整会话导出日志记录了全部交互过程。整个调试周期，一共发起 7次扩展交互，其中5次为实际任务调用：
2次 list：查询 pi‑subagents 可用代理能力；
3次 worker：先后输出三版修复代码；
1次 scout：后台异步只读分析代码、提交记录与逻辑链路；
1次 reviewer：对最终代码Diff做独立审查。
纸面分工十分完备，但真实执行链路完全没有并行效果：
worker 1：初版修复，在A环节做问题处理（构建通过，0错误）↓主AI读取日志，发现处理时机设计错误，整套方案作废↓worker 2：第二版修复，换到B环节统一处理（构建通过，0错误）↓再次发现缺陷：改动会引入新的副作用↓scout：启动后台异步分析，但是主流程继续向前推进，分析结果未被决策使用↓worker 3：第三版修复，调整到C环节完成之后再做状态刷新↓reviewer：审查任务运行速度很慢，我手动将它中止，没有输出审查报告
修复方案前后历经四次迭代，不断调整处理的时机与入口。
第一个worker足足执行18轮工具调用，消耗大量输入Token，最终只改动几十行代码，编译完全通过，输出报告也十分规范。可整套方案从根源上选错处理时机，全部工作直接作废。
pi‑subagents 的 worker 可以把一个错误方案执行得非常漂亮，还附带完整的构建成功证据，但它不会主动判断大方向是否正确。
更值得注意，几次worker任务均使用同步模式。这就意味着主Agent必须原地阻塞等待子代理全部执行完毕，才可以继续思考下一步。这不是并行多任务，仅仅是换一个进程完成工作，还额外叠加进程启动、上下文重建、重新理解业务代码的高额固定开销。 启动子代理需要拉起新进程、把任务背景和业务上下文重新喂给它，这部分成本在每一次调用时都要结构性付出——即便子代理干得又快又好，单论“启动这一轮”本身就比主Agent原地继续干要慢。
这个Bug属于典型强串行依赖任务：后一步修复思路，完全建立在上一版失败日志、Diff结果之上。同一个代码工作区，不能同时让多个代理随意修改代码。即便启动异步scout后台勘察，如果主流程不会等待、不会消费它输出的结论，异步也仅仅是白白消耗资源，并不会带来效率提升——“开了异步”不等于“实现了并行”，这一点比worker返工更隐蔽，因为它在账面上甚至“看起来在并行工作”。
本次会话最后的 reviewer 是我主动手动中止的：运行速度太慢，我选择不再等它，因此没有输出风险检查结论。这属于我的使用取舍，不能算 reviewer 本身不可用；但也暴露了一个现实问题——独立审查的价值，和它所需的时间成本之间，需要使用者自己掂量。
二、看不见的账单：就算一次不用，也要为它付费
我原本寄希望于 pi‑subagents 的隔离能力，把繁重阅读试错移出主会话，守护主会话上下文。复盘之后我才意识到一个反直觉事实：在alwaysEnabled常驻模式下，哪怕从头到尾一次子代理都没有调用，每一轮请求依旧要背负巨额的Schema Token开销。
我的配置使用 compact 精简工具描述，并且开启 alwaysEnabled: ["subagent"]，pi‑subagents 的整套工具定义永久常驻工具列表。
开销大头并不是磁盘上一大堆skills、prompts、agents的Markdown源码文件——这些文件大多只有调用对应功能的时候才会加载。
真正常驻注入每轮请求的成本估算（统计方法：从会话导出日志中逐条提取注入主会话的工具定义与系统元数据，按标准Token分词口径折算）：
合计每轮常驻成本约：7000‑12000 Token。一旦切换为full完整模式，开销会飙升至10000‑17000 Token。
讽刺的是，整套扩展里价值很高的自定义使用策略，只有几百字节；最昂贵的部分，恰恰是那一大堆平时很少用到的workflow、mission、lane、watchdog编排能力的工具Schema。
我本想用 pi‑subagents 节省主Agent上下文，结果它自己先永久性占掉上万Token的上下文。
这是本次实测里最颠覆认知的一点：它设计目标是保护主会话上下文，但常驻开启时，自身就会持续消耗主会话宝贵的上下文预算。
三、公道话：pi‑subagents 并非一无是处，这些场景价值巨大
写到这里并不是全盘否定 pi‑subagents。它的角色体系、隔离子进程、工作区隔离、丰富编排能力都做得很完整，只是有明确的适用边界，不是所有任务都适合上子代理。
✅ 适合启用 pi‑subagents 的场景
大规模独立只读代码勘察：同时多路分析互不干扰的代码链路，面对海量陌生模块，把繁重阅读工作移出主会话，保护主上下文干净。
真正互相独立，可以并行拆分的任务：多项任务互不依赖，不会修改同一批文件。多方向同时开展，最后主Agent汇总结论。
实现完成后的独立对抗审查：代码方案已经完全固化，调用reviewer做只读评审。全新的上下文更容易跳出实现者的思维定势，发现空值、生命周期、业务回归隐患。
多工作区大规模重构：隔离多个工作目录，不同代理在隔离环境修改，避免互相干扰，降低主Agent误改风险。
后台长时间任务：构建、批量测试、海量日志扫描，放到后台异步执行，主Agent可以继续处理别的工作。
❌ 不建议使用 pi‑subagents 的场景
单一Bug连续调试排错，每一步方案依赖上一步输出；
小规模单/双文件改动，改动量很小，代理启动开销大于修改本身；
需要频繁根据日志、反馈迭代调整方案；
多个代理需要操作同一个工作区，任务强串行无法拆分。
本次Bug调试，几乎全部命中不适合使用的条件。
四、pi‑subagents 实战可用的使用守则
经过完整踩坑，针对 pi‑subagents 我整理了一套务实使用准则：
取消alwaysEnabled常驻配置，默认关闭子代理，需要处理适合的任务再临时启用。这是降本收益最高的操作，直接消除每轮7000+的常驻Token负担。
先定位，再派活，不要边诊断边交给worker试错。主Agent完成问题分析、方案确认之后，再派遣worker执行；切忌还没想清楚方向，直接扔给子代理反复试错。
reviewer放在流程末尾使用，方案还在剧烈变动的时候做审查没有意义；审查过程如果运行过慢可以主动终止，审查完成之后主Agent必须亲自核对输出结果。
构建、编译、最终业务验证，交给主Agent亲自确认，不要完全依赖 pi‑subagents worker输出报告。
配置上保持
compact精简工具描述，不要开启full完整模式。异步scout侦察不要当做流程强依赖，只作为补充信息，不要把业务决策完全寄托在异步子代理返回结果。
反模式一定要避开：
worker改完→worker再改→worker继续改，连续多次派遣worker迭代修改，会反复付出高昂上下文重建成本——而正如第一节所说，这笔成本每一次调用都要结构性付出。
五、写在最后：多代理是重装备，不是默认快捷键
故事的结局，我最终把 pi‑subagents 卸载了。
不是这个扩展本身做得差：worker执行任务恪守工作区约束，不会伪造编译结果，角色、工作流、隔离机制这些工程细节做得相当出色。只是我的日常绝大多数工作，都是单Bug调试、小范围迭代修改，并不满足并行拆分的前提。它带来的交接损耗、常驻Token开销，远远盖过它带来的收益。
当下AI圈子很流行“给AI组建一支分身团队”的叙事，不少文章也在推荐 pi‑subagents。但我们要分清纸面架构能力和工程现实代价。pi‑subagents 本质是一套上下文调度重装备，不是提效默认快捷键。它的价值不在于把任务拆给更多Agent就跑得更快；而在于把真正独立、可并行、适合后台执行的工作剥离出去。
很多时候，一份连续、完整不被打断的上下文，远比花哨的多代理编排更加高效稳定。
回到开头那两句话：
这个任务，是否真的可以拆分成多项互相独立、可以并行推进的工作？ 我是否愿意承担代理启动、上下文重建、常驻Schema带来的时间与Token成本？
两个答案里有任何一个是否定的，就先别急着派分身。
互动话题：你有没有实际用过 pi‑subagents 或者其他AI子代理工具？是实实在在提升效率，还是遇到过开销大、效果不及预期的情况？有没有哪个场景，是你觉得子代理真正“真香”、离开了就不行的？ 欢迎评论区聊聊你的真实体验。
注：文中全部数据来源于真实会话日志脱敏整理；Token为基于原始文件统计与折算的合理估算，不同版本配置数值会存在浮动；本文仅针对 pi‑subagents，不代表所有子代理类工具。