📌 项目地址：nicobailon/pi-subagents | ⭐ 1,812 颗星 | 🔧 TypeScript | 📜 未标注
不是又一个AI Agent框架
我见过太多AI agent项目了。它们通常要求你：定义工具函数，写YAML配置文件，给每个agent设置角色prompt，再跑一个调度器。
pi-subagents 走了另一条路。安装只需要一行：
pi install npm:pi-subagents没有任何配置步骤。没有斜杠命令需要记忆。装完之后，你对Pi说一句日常话就能调用子代理：
Use reviewer to review this diff.Pi 立刻启动一个子代理（一个全新的Pi会话），把diff扔进去，结果流式返回在当前对话里。
这意味着什么？你不必学习“如何创建agent”，你只需要学会怎么说人话。
子代理的设计：独立会话，自包含指令
每个子代理都是独立的Pi会话。它看不到你和主Pi之前说了什么。好处是不会被对话历史污染——任务边界清晰。坏处是你给子代理的任务指令必须自包含。
举个例子，如果你想用 oracle 对当前计划给出第二意见，不能只说“review my plan”，因为子代理不知道你的计划是什么。你需要把计划内容写进prompt里，或者告诉主Pi先把计划总结好，再传给子代理。官方的推荐prompt就是这种风格：
Ask oracle for a second opinion on my current plan. Challenge assumptions and tell me what I might be missing.注意，这句话包含了“计划”的具体内容吗？没有。但主Pi在处理这条指令时，会把自己的当前对话上下文（包含你之前提到的计划）当作任务的一部分传给子代理。实际上，主Pi扮演了“封装指令”的角色——它知道怎么把当前讨论的关键信息打包给子代理。
这一点很重要：你不是直接对子代理说话，而是告诉主Pi去调用子代理，主Pi会替你构造指令。
两种运行模式：前台流式，后台持久
子代理有两种运行方式：
- Foreground（前台）：子代理的结果像正常对话一样实时流式显示。适合你等着看输出的场景，比如review一个很小的diff。
- Background（后台）：子代理在后台悄悄干活，你继续和主Pi聊别的，随时可以问“刚才那项工作结果如何”。适合长时间任务，比如审查一个大型代码库，或者你不想被打断思路。
README没明确说后台任务如何检查，但从设计上看，Pi会保留后台结果可供后续查询。我理解是：Pi会将后台子代理的结果作为一次独立的对话记录，方便你随时查询。
自然语言调度策略：Pi自己做决策
你不需要指定用哪个子代理。你只需要描述任务，Pi决定是否调用 subagent、调用哪个agent、以及并行还是串行。
比如，你想并行审查，说：
Run parallel reviewers on this diff. I want one focused on correctness, one on tests, and one on unnecessary complexity.Pi会自动启动三个并行子代理，各关注一个角度，然后把结果汇总回来。
如果你想要链式工作流：
Implement this, then review it.这句话没有指定子代理类型，Pi会先用 worker 实现，再用 reviewer 审查。整个编排由Pi决定。
你甚至可以跑一个迭代循环：
Run a review loop on this change until reviewers stop finding fixes worth doing, with a max of 3 rounds.Pi会反复启动 reviewer，直到发现问题或达到上限。
实际工作流：从单步到循环
官方列了几个典型场景，我挑三个你觉得最有用的：
场景1：第二意见。 你有一个复杂的技术方案，不敢确定。用 oracle 挑战你的假设：
Ask oracle for a second opinion on my current plan. Challenge assumptions and tell me what I might be missing.场景2：实现+自动审查。 你写好一个plan，让 worker 实现，实现后自动跑 reviewer 和 oracle，并把结果反馈回来。官方给出的prompt：
Have worker implement this approved plan. Afterward, run parallel reviewers, summarize their feedback, and apply the fixes that make sense.场景3：理解代码后制定计划。 你面对一个不熟悉的模块，先用 scout 理解代码结构，再用 planner 制定实现计划：
Use scout to understand the auth flow, then have planner turn that into an implementation plan.自动化需要你明确说
装完扩展，Pi 不会自动在后台做任何事。如果你希望每次实现后都自带动审查，需要在你的项目指令里（或每次对话开始）写清楚：
When you finish implementing, run a reviewer subagent before summarizing.这是值得养成的习惯：在项目描述里加一句这个，你后续每次用Pi实现功能时都会自动获得代码审查。
潜在局限
- 子代理上下文隔离：优势是任务独立，劣势是你必须学会把当前讨论的上下文显式交给子代理。如果你指令写得不够清晰，子代理可能得不到足够信息。
- 后台任务检查机制：README只说“can be checked later”，没给具体语法。我推测Pi会保留后台子代理的对话记录可供查询，但不确定是否需要特定指令。
- 子代理类型有限：目前只有
reviewer、oracle、scout、worker、planner等几个。如果你的任务不在这些类型里，Pi可能无法自动选择合适的子代理。
不过，这已经是目前最接近“自然语言驱动多AI协作”的工具了。它去掉了一切配置负担，把调度决策交回给Pi本身。你只要会说人话，就能用上专业的代码审查、架构质疑、自动化工作流。