# pi-team

<p align="center">
  <a href="https://github.com/Kurptas/pi-team/releases"><img src="https://img.shields.io/github/v/release/Kurptas/pi-team?style=flat-square&color=32CD32" alt="Release"></a>
  &nbsp;
  <a href="https://www.npmjs.com/package/pi-team"><img src="https://img.shields.io/npm/v/pi-team?style=flat-square&color=CB3837&logo=npm" alt="npm"></a>
  &nbsp;
  <a href="./LICENSE"><img src="https://img.shields.io/badge/license-MIT-32CD32?style=flat-square" alt="License"></a>
  &nbsp;
  <img src="https://img.shields.io/badge/node-%3E%3D22.19-6C757D?style=flat-square&logo=node.js&logoColor=white" alt="Node">
</p>

[English](./README.md) · **简体中文**

> 你让最强的模型审一段代码，它说没问题。你又让同一个模型再审一遍，它还是说没问题。
>
> 你换了一个模型。这个模型说：这里有个竞态条件。

这不是运气。不同的模型有不同的"读法"——结构、训练、对齐各不相同，一个模型的盲区，往往正是另一个模型的本能。你要的从来不是三份相同的意见，而是三个各自不同的视角。

**pi-team 是 Pi 的一个扩展。它让 Pi 化身"队长"，为你召集一支跑在不同模型上的 AI agent 小队，一起完成同一个任务。**

## 安装

### Pi

**推荐方式**

```bash
pi install npm:pi-team
```

**固定版本安装**

```bash
pi install npm:pi-team@0.6.11
```

装完在 Pi 里敲 `/reload` 就生效了。

### Oh My Pi

pi-team 也可以作为 Oh My Pi 扩展使用。安装时使用 `omp` 命令。

```bash
omp install pi-team
```

**固定版本安装**

```bash
omp install pi-team@0.6.11
```

安装后重启或 reload Oh My Pi。

## 两句话就能跑起来

最直接的方式是敲 `/team` 命令，后面跟上你的任务。或者干脆用平时跟 Pi 说话的方式，只要带上"组队"两个字：

```
/team 用三个不同的模型组队评审这个 PR，把发现汇总给我。
```

```
组队帮我对 $NVDA 做多空分析——一个看多、一个看空、一个专门挑刺，最后给我一个综合判断。
```

就这样。Pi 会自己规划角色、挑模型、派活、收结果。你从头到尾都能实时看到每个成员在干什么，谁跑偏了就拽回来，或者随时喊停——全程由你掌舵。

## 小队真正的用武之地

代码评审是最直接想到的场景，但 pi-team 的射程更宽——任何"只听一个声音心里没底"的事，都值得派一支小队：

| 场景 | 小队怎么干 |
|---|---|
| **调研一个硬问题** | 几个模型各自从不同角度挖，最后由一个来交叉验证、汇总——不是某个模型的即兴答案，而是互相校对过的结论 |
| **金融与市场分析** | 多头、空头、唱反调的各执一词，在你下判断之前先把它辩透 |
| **追一个顽固 bug** | 一个读日志、一个追代码调用链、一个提修复方案，三条线并行推进 |
| **权衡一个重大决策** | 每个选项都给独立的赞成/反对分析，然后一个有理有据的定论，不是拍脑袋也不是抛硬币 |

## 为什么派一支小队，而不是给同一个模型塞更长的 prompt

**第一，不同模型的不同盲区，只有换模型才能补。** 独立 agent 之间的分歧，正是隐藏假设浮出水面的信号。同一个模型的十份拷贝，只会把同一处遗漏齐声重复十遍——那不叫交叉验证，那叫回声。

**第二，合适的活交给合适的模型。** 你把最强的模型放在判断和综合上，让又快又便宜的去做扫描、grep、阅档——不必为跑腿的活付推理顶配的账单。

**第三，有人拍板，不是投票。** 分歧出现之后，有一个角色来权衡证据、判断轻重、给出综合结论。你得到的是一个经过审视的定论，而不是各方意见除以人数的算术平均——后者谁也不得罪，也谁都帮不上。

举个实际的例子：让*一个*模型审这个 PR，它审得很仔细，然后说没问题——但那是透过它自己的习惯审的。同样一件事交给小队，第二个模型揪出了第一个径直走过的竞态条件，第三个确认了修复方案。同样的任务，少一个盲区。

## 你在掌舵，全程可见

一支你看不见、也插不了手的队伍，跟没有差不多。

pi-team 的后台小队采用 push-first：完成时主动通知；队友超过两分钟没有有效 RADIO/ACK 通信时提醒一次，不需要你反复轮询。同一段静默不会重复轰炸；队长观察或干预已提醒成员后，才为相关成员开启一个新的两分钟观察窗口。多个成员的通信债务会集中汇报；TUI 优先显示仍在推进和待启动的成员，已结束成员后置；队长请求既可定向也可广播，并主动注入目标 session，区分排队、已投递与 ACK。某个 worker 模型失败时，pi-team 会先尝试通过其他已配置 provider 或渠道调用相同的模型 ID，再切换到不同模型。提醒不会替你取消或改派成员，判断权始终在你手里。

## 更进一步

pi-team 自带几种现成的"阵型"——评审小组、调研圆桌、分诊调试链——拿来就能用。你也可以自己设计，或让 Pi 为当前任务当场编排。每个角色都能有自己的工作指引，工具权限也能按角色限死——评审员只读代码，绝碰不到你的终端。

想灵活时它灵活，不想操心时它稳妥。

## 许可证

MIT · [Issues](https://github.com/Kurptas/pi-team/issues)
