pi-ai-meeting

Pi 的多模型会议 skill：把 3–5 个不同模型（各带自己的供应商与思考档位）拉进同一场会议，并行独立表态 → 匿名交叉质询 → 投票定案 → 验收修改。

用于需要多个独立视角的判断题：方案选型、设定审稿、文案定稿、风险挑错；也用于需要互相拆解的真实分歧。

什么时候该开会，什么时候别开

最适合：判断题。 你自己拿不定、而且"再多几个独立视角"真有可能改变结论的场合。

• 技术选型 / 方案取舍：几个互斥方案里挑一个，或者"要不要动这块"这类判断。多模型独立表态最容易暴露你没想到的代价。
• 文案与表达：简介、标题、卖点、slogan。作者看不见"读者实际读到什么"，多视角能挑出来。
• 设定 / 逻辑自洽审查：找出真实存在的冲突、推导不出来的地方。
• 验收：改完之后有没有引入新矛盾（要求引用改后原文）。

别用它做代码审查。 这是实践下来最明确的禁区：会议会把代码系统性地推向"更完备"，产出经常是冗余代码、过度防御、过度设计——给不可能发生的分支加兜底、给内部字段加兼容别名、给一次性脚本加三层抽象。原因不是模型不行，而是投票这个机制本身偏好"更安全"的方案，而代码的正确性偏好恰好相反（能被删掉的代码才是好代码）。

代码该用能给出客观判据的手段：单一审阅者、静态检查、测试、以及真的跑一遍。开会给出的是口味共识，在代码上口味共识只会往里加东西。

⚠️ 开会非常耗时，这是它最大的代价。

• 实测：4 席通读一个代码仓库 562 秒；4 席读 4 个文件的文档复审 400 秒；一场 3 席、不读任何材料的纯判断会也要 423 秒。
• 原因：整场等最慢的席位（runs.all），一个慢席位能绑架全场——实测某席 436 秒，比你另外三席加起来还久。
• 所以：一次追问就能问清的问题不要开会。会议是拿 7–10 分钟换"多几个独立视角"，只对值这个价的判断题用。

安装

先装它依赖的 pi-subagents（本包不自带，pi 也不内置，缺了就没法开会）：

pi install npm:pi-subagents     # 提供 subagent 工具与 oracle agent

缺它的现象：工具列表里没有 subagent；就算绕过也会报 Unknown agent 'oracle'。注意不要把它写进本包的 dependencies——那样会和你自己装的那份重复注册。

# git（推荐，跟着仓库 ref 走）
pi install git:github.com/ArnoldRedman/pi-ai-meeting

# git，钉住某个版本
pi install git:github.com/ArnoldRedman/pi-ai-meeting@v1.4.1

# npm（尚未发布到 npm，发布后可用）
pi install npm:pi-ai-meeting

管理：

pi list                          # 查看已安装
pi update git:github.com/ArnoldRedman/pi-ai-meeting
pi remove git:github.com/ArnoldRedman/pi-ai-meeting

移除时会残留一个配置文件：pi remove 只清包目录和 settings 条目，不动 ~/.pi/agent/ai-meeting.json（那是你自己配的席位表，扩展也没有卸载钩子能清自己）。想干净移除就先删它：

rm ~/.pi/agent/ai-meeting.json      # Windows: del "%USERPROFILE%\.pi\agent\ai-meeting.json"
pi remove git:github.com/ArnoldRedman/pi-ai-meeting

没跑过 /ai-meeting:config 就不会有任何残留。

配置席位

席位不写死在 skill 里，装完先配一次：

/ai-meeting:config

交互式逐席选择 供应商 → 模型 → 思考档位（只列出你本机真实可用、且该模型确实支持的档位）。也可以用 /ai-meeting:config raw 直接用编辑器改 JSON。

配置写在 pi 配置目录下的 ai-meeting.json（通常是 ~/.pi/agent/ai-meeting.json）：

{
  "version": 1,
  "seats": [
    { "provider": "anthropic", "model": "claude-opus-4", "thinking": "high", "name": "opus", "note": "结构最清，保守" }
  ]
}

• 首次运行任何一次 /ai-meeting:config（或在无配置时开会）会自动生成一份默认配置：从你已认证的模型里挑最多 4 个不同模型（优先当前供应商）作为默认席位。
• name 是席位简称，必须唯一；note 只给人看。
• 改过模型配置后，在 pi 里按一次 /model 重载注册表，否则席位会硬失败（Unknown subagent model ...）。
• 席位数 3–5 合适；同一个模型挂在两个供应商别名下不算独立视角。

每场会结束时给什么

不是"总结一次"就完了，而是四件东西：

1. 谁在拖时间 / 谁在摸鱼 / 这场会花了多少（见下面「耗时与成本」一节）；
2. 票型图——先说清统一还是未统一；未统一就列 A「保留原机制」2 票 —— sol、grok / B「换新机制」1 票 —— astra / C「先不动」1 票 —— ds，每方向一句话主张 ＋ 代价，并说清分歧的实质（争的是改动幅度？代价归属？还是信息不够？）；
3. 三类分：真洞 / 已知取舍 / 空话 ＋ "谁改了什么主意"；
4. 下一步菜单（带代价，不替你选）：

1. 采用 A —— 直接出具体改法
2. 四席二轮会：A/B/C 匿名重投，看票型是否移动
3. 三席两轮会（交叉验证）：移出最边缘一席让 A/B 对撞，目标收敛 —— 只传 seats 子集，不用改配置
4. 只深挖某一方向：把它写成待验证假设，让各席找反例与失效条件
5. 你给一个新方向：写进问题单开二轮

上限两轮（表态 + 收敛）：第二轮仍分裂就不再开会，把分歧和各自代价摆给你拍板。

耗时与成本：会自动报什么

每场会开完，skill 都会报这三样。

谁在拖时间

拿中位数比各席耗时：

• 某席 ≥ 中位数 × 2.0（且多出 60 秒以上）→ 报它拖时间；如果它的 thinking 档明显高于其他席，先判定是档位问题，建议降档而不是踢人（实测降档不一定治慢，见下）。
• 阈值是实测校准过的：旧版写 2.5×，一场会里某席 2.46×（436.7s vs 中位数 177.5s，比其他三席之和还多）刚好漏报，所以降到 2.0×。

谁在摸鱼（只看直接证据）

判据是"它到底碰没碰过材料"（从工具调用参数里数材料命中数）：

• 命中满 → 不是摸鱼，无论它多快。实测有席位 5 turns / 4 次批量 bash 就翻完了整个仓库，还自己写脚本复现出一个 bug——凭"快、答案短、token 少"判它摸鱼就是误伤。
• 0–1 命中且工具调用极少 → 才报"疑似没读材料"，并把命中情况摆出来（"它一次都没打开过 X"是事实，不是推断）。
• 不要用轮数 / token / 字符数当判据：一个 turn 里可以并发多个工具调用，轮数会严重少算工作量（同类基准：4 次批量调用 vs 47/67 轮，干的是同一件事）。

顺带一个反直觉事实：慢的主因常是调用碎，不是干得多（实测 4 次批量 bash = 65 秒，79 次细碎 grep/read = 437 秒）。另外"降档"不一定治慢：实测某席 xhigh→high 后仍是全场最慢（同题下 423 秒 vs 另两席 40 / 57 秒）。

这场会花了多少

一个席位的花费 ≈ 它的请求次数 × 每次重发的上下文量 × 该模型的单价结构。碎步调用最多的席位通常就是花钱最多的那位，但不能只看工具调用次数（工具次数 ≠ API 请求数），要按下面的方法实测。

耗时不在脚本返回值里（run 结果没有时间字段），但每个席位的 asyncDir 下都有 status.json（用时、请求数）与 events.jsonl（每次请求的 token）；脚本另外提供 chars / turns / lastInputTokens / cost 作为配套证据——注意 lastInputTokens 只是最后一次请求的新增输入，不能当账单用。

一场会花多少钱（实测三档）

⚠️ 下面所有金额都是某一台机器 + 某一个网关的实测。换供应商、换模型、换渠道，数字会变，排序甚至可能反转（原因见下面「缓存计价的坑」）。请按自己的网关复算。

会议类型	席位数	席位实收合计	墙钟
纯判断（不读材料，1 轮）	3	$0.34	423 秒
审文档（读 4 个文件，2 轮交叉质询）	4	$2.24	400 秒
通读整个代码仓库（2 轮）	4	$14.05	562 秒

逐席明细 · 重任务会（4 席 × 2 轮，席位通读一个仓库）

席位	请求数	输入侧 token（其中缓存重发）	实收	占比
ds	73	5,253,605（96%）	$10.73	76%
grok	50	3,084,451（93%）	$2.12	15%
astra	6	140,144（50%）	$0.97	7%
sol	6	164,059（54%）	$0.23	2%
合计	135		$14.05

逐席明细 · 轻任务会（3 席 × 1 轮，纯判断）

席位	请求数	输入侧 token	实收
grok	1	7,088	$0.162
astra	1	9,698	$0.145
sol	1	9,762	$0.030
合计	3		$0.34

同样是"一场会"，差 40 倍。差异主要不在模型单价：重任务会里单价最便宜的席位（$2/M）占了 76%，而单价贵 5 倍的那个（$10/$50）只占 7%——因为前者发了 73 次碎步调用、每次把 7 万 token 的上下文整个重发一遍，后者 6 次批量调用就看完了同样的材料。

但注意轻任务会反过来：每席只有 1 次请求时，单价与输出长度就是主因（同样 1 次请求，最贵与最便宜席位差 5 倍）。所以结论是"先看请求次数，再看单价"，不是"单价无关"。

要省钱，按效果排序：① 要求席位批量读材料（最大的杠杆）→ ② 少席位 → ③ 少跑交叉轮次（cross: true 大约把时间和花费都翻倍）。

⚠️ 缓存计价的坑（这条能直接改变结论）

各渠道对"缓存命中"的计价完全不同。实测这台网关上（同一场会里的四条渠道）：

模型渠道	新增输入	缓存命中
deepseek	$2 / M	$2 / M（与新增同价）
astra	$10 / M	≈ $1 / M
grok	$2 / M	≈ $0.5 / M
sol	$2 / M	≈ 0（近乎免费）

含义：缓存折扣大的渠道，"反复重发上下文"（长会话、碎步席位）会便宜得多，贵与便宜的排序可能整个反过来。所以请查自己网关的价目，不要照抄上面的数字与排序。

我们不能下"开会比一个模型自己干更省"的结论

有一个观察：同一 10 分钟窗口里，一个模型在长会话（常驻 20–40 万 token）里自己调研、跑脚本、读日志花了 $17.40，而同时段一场 3 席判断会只花 $0.34。

但这是同一时段并行发生的两件不同工作，不是"用开会替换掉那件工作"，工作量也不同（一边在通读与跑脚本，一边只做判断）。所以它不能证明"同一个任务开会更省"——我们没做过同任务对照实验，本节也就不给这个结论。

目前站得住的只有三条：

1. 开会的席位花费实测落在 $0.3–$14，取决于席位被要求读多少材料；
2. 成本结构是请求次数 × 每次重发量 × 该渠道的单价结构；
3. 长会话里反复重发的上下文是另一个独立的大头，与开会无关；在"缓存全额计价"的渠道上尤其明显，在缓存近乎免费的渠道上则几乎不存在。

怎么用你自己的网关复核

每个席位的 asyncDir 下有 status.json 与 events.jsonl。两个必知的统计口径（不然会算错一倍以上）：

• 只数 message_end。同一次 API 请求的用量会在 message_end 与 turn_end 里各出现一次（message_start 是全零），全算上会把 token 翻倍、请求数变三倍。
• 分项计价：输入侧 = input + cacheRead + cacheWrite，而且新增与缓存命中要按不同单价乘（缓存价各渠道不同），再加 output × 输出单价。拿不到单价就只报 token 量，不要报金额。

内容

extensions/
└── ai-meeting.ts                 # /ai-meeting:config 命令
skills/ai-meeting/
├── SKILL.md                      # 何时开会、三条硬规矩、流程
└── references/
    ├── question-design.md        # 问题单写法 + 六类会议模板 + 汇总规则
    ├── meeting.js                # 会议脚本本体（并行表态 + 匿名互评 + 单席位兜底）
    └── pitfalls.md               # 实战坑与修法

references/meeting.js 是直接调用的脚本文件，不需要把代码复制进回复：

subagent({
  workflow: "<本 skill 目录>/references/meeting.js",
  async: true,
  timeoutMs: 1800000,
  args: {
    seats: [ /* 粘贴 ai-meeting.json 里的 seats */ ],
    brief: "问题单全文（自包含；长材料写绝对路径让席位自己 read）",
    cross: true,   // true = 第一轮表态 + 第二轮匿名互评一次跑完
    tag: "设定-0725"
  }
})

前置条件

依赖	为什么需要	缺了怎么办
pi-subagents（额外安装，非 pi 内置）	开会用的 subagent 工具、oracle agent、runs.all 编排都来自它；耗时甄别读的 status.json 也是它写的	pi install npm:pi-subagents
至少 3 个已认证的不同模型	少于 3 席分不出独立视角，也判不了耗时异常	/ai-meeting:config 会自动从你已认证的模型里选；不够就去配供应商
pi 编码代理（宿主）	扩展 import 宿主接口；已在 peerDependencies 里声明	无

维护

改动流程（本地仓库在 D:\pi-ai-meeting）：

cd /d D:\pi-ai-meeting
git add -A && git commit -m "..." && git push
pi update git:github.com/ArnoldRedman/pi-ai-meeting   # 让已安装的 checkout 跟上

在会话中改了 SKILL.md 后，/reload 生效。不要再往 ~/.pi/agent/skills/ 里放一份同名副本 —— 同名 skill 冲突时 Pi 保留先发现的并只打个警告，本地副本会静默盖掉包里的版本。

改了 references/meeting.js 里的文本处理（cleanText / stanceOf）或扩展里的配置读写（readConfig / validate）后跑自检：

node tests/clean-text.test.mjs   # 抹 harness 报告块、抽【结论】行
node tests/config.test.mjs       # 坏配置不被误当成"没配置"，校验不抛异常

两个测试都是直接从产品源码里抠出函数来跑（tests/extract.mjs），不在测试里重写一份，所以不会漂移。

破坏性变更：v1.4.0 起 meeting.js 的返回值统一用 round1（旧版 cross: false 时叫 seats），字段 inputTokens 改名 lastInputTokens。自己写过脚本读这些字段的话需要同步改。

发 npm 包前留意 package.json 的 files：新增资源目录（如 extensions/）必须加进去，否则 npm 路线装出来的包会缺东西。

发版：改 package.json 的 version → 提交 → git tag -a v1.4.1 -m v1.4.1 && git push --tags；钉版本的用法是 pi install git:github.com/ArnoldRedman/pi-ai-meeting@v1.4.1。

发到 npm 后即可用 pi install npm:pi-ai-meeting：

npm login        # 需要交互
npm publish

为什么目前只做 Pi

这个 skill 的核心需求是：让不同模型在同一场会议里并行独立表态，再互相质询，并支持各席位分别选择供应商、模型和思考档位。同一个模型开几个独立上下文也能讨论，但不能替代这里追求的模型多样性。

Pi 可以在同一套环境里配置多个供应商及其认证，再通过 pi-subagents 为每个席位分别指定 provider/model/thinking。模型选择、并行执行和子会话续接都有现成能力，本项目可以集中处理问题单、交叉质询和会议结果。

移植到 Codex、Claude Code 等平台，会议规则和提示词容易复用，执行层却不能直接照搬。目标平台是否允许子 agent 分别选择不同供应商，要看它的具体版本和接口；不能因为支持多个子 agent，就默认具备同样的跨供应商调度能力。

跨平台并非做不到：可以启动多个 CLI 进程，或直接调用不同供应商的 API。但这意味着本项目还要负责跨进程调度、认证接入、超时与取消、会话恢复、结果格式和用量统计，并持续适配各平台的变化。工作范围会从一个会议 skill 扩大成一套多模型运行工具。

因此，目前只维护 Pi 版本。 Pi 已有的多供应商能力，加上 pi-subagents 的编排能力，正好承接本项目的需求。其他平台适配留待有明确需求时再评估；会议方法本身并不依赖 Pi，欢迎复用。

License

MIT