pstack多模型Panel机制：让3个模型协作完成同一个任务

pstack多模型Panel机制：让3个模型协作完成同一个任务

【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Poteto's pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude

在 AI 编程助手越来越强的今天，pstack 多模型 Panel 机制提供了一种新思路：不再依赖单一模型单打独斗，而是让3 个不同模型（默认opus、fable、sonnet）组成 Panel（面板），并行完成同一个任务，再交叉评审、择优合成。这套机制默认服务于arena、architect、interrogate、how等技能，是 pstack 工作流中对抗盲点、提升产出质量的核心设计。

什么是 Panel：3 个模型的"陪审团"

Panel（面板）是 pstack 术语表中的一个正式概念：多模型技能默认运行的三模型多样性面板，其定义只有一处——plugins/pstack/models.json：

"tiers": { "default": "opus", "strongest": "fable", "panel": ["opus", "fable", "sonnet"] }

设计上有两个关键点 🧠：

• 跨家族多样性：Panel 的三个模型来自不同能力层级，而不是同一模型的三份拷贝。对抗性信号来自模型本身的差异，而非人为分配"角色人设"（这一点在 plugins/pstack/skills/interrogate/SKILL.md 中写得很明确）。
• 单一事实源：Panel 的成员名单只维护在models.json一处，生成器 tools/generate.mjs 会把它"盖章"到每个技能的 Models 段落中，发现游离副本会直接报错，杜绝各文档之间的版本漂移。

哪些技能默认启用 Panel

在models.json的roles列表中，"models": "panel"标记了所有默认走 Panel 的角色：

技能	Panel 角色	用途
arena	arena runners / arena cross-judge pool	并行候选 + 交叉评审池
architect	architect runners	设计草图多方案竞争
interrogate	interrogate reviewers	多模型对抗式代码审查

三个典型协作场景

🏆 竞技场模式（arena）：并行出稿，交叉评审，嫁接择优

arena是 Panel 机制最直观的体现，共六个阶段：Frame（定框）→ Fan out（扇出）→ Cross-judge（交叉评审）→ Pick（选基线）→ Graft（嫁接）→ Verify（验证）。

1. 给 N 个候选分配同样的提示词，Panel 中每个模型各跑一个候选（默认opus、fable、sonnet各一份），且必须产出交付物加简短理由；
2. 所有候选完成后，从cross-judge pool中挑一个与父会话不同家族的模型担任评审，按量规给每个候选打分并推荐基线；
3. 父会话逐字读完所有候选，与交叉评审互相校验——一致则确认，不一致说明某一方有偏或量规模糊；
4. 把落选方案中值得保留的一两个亮点手动"嫁接"进基线，最后照常验证。

当 N 个候选收敛到同一形状时，本身就是强烈的共识信号，可以直接采用。

🛠 架构模式（architect）：先画蓝图，再写代码

architect走"设计先行"路线：先用how技能把周边系统的真实运行链路摸清（Grounding），然后把"设计草图"任务交给arena 的 runner Panel，每个模型各自产出一份类型、签名、模块结构级的设计包。

它有一条硬规则："Design it twice"——哪怕第一个方案看起来够用，也必须至少要求两份结构上不同的候选再进入合成，避免单模型的第一反应锁死整个架构走向。

🔍 审讯模式（interrogate）：多模型对抗式代码审查

interrogate把 Panel 用作评审团：每个配置模型各起一个只读（readonly）评审子代理，默认对应 Reviewer A/B/C =opus/fable/sonnet，所有评审拿到的是同一份提示词、量规和代码质量检查视角。

合成判定时的信号分级非常实用：

• 2 个以上模型独立提出的发现→ 最高信号，优先处理
• 单个模型独有的发现→ 值得读，但按权重酌情采纳
• 模型之间的分歧→ 本身也是有价值的判定上下文

最终由父会话以"务实的资深工程师"身份输出合成结论，而不是简单汇总。

如何自定义 Panel：override 覆盖表

不想用默认三模型？pstack 提供了完整的运行时覆盖机制，入口是 setup-pstack 技能：

• 它会生成一份pstack-models.md覆盖表（各运行时路径不同，如 Claude Code 下为<config>/pstack-models.md），其中每个角色一行，Panel 角色的值是列表——列表多长，Panel 就扇出几个子代理；
• 每个条目可以独立指定推理力度，例如arena runners: opus @xhigh, fable @max，每个条目通过插件对应的 effort 子代理（见 plugins/pstack/effort-agents/）独立运行；
• 写inherit-parent或auto可让该席位跟随父会话模型；
• 在 Codex 上，Panel 默认对应gpt-6-astra、gpt-6-sol、gpt-6-luna三个不同家族模型；Pi 运行时则由models.json的pi段把别名映射到各提供方的具体模型 ID。

一个值得注意的兜底设计：如果你只有一个模型家族可用，可以改为用不同的推理力度制造差异，但需要在结论中注明"多样性已降低"——诚实面对能力边界。

一致性如何保证：生成器 + 测试

Panel 名单之所以敢"只写一份"，靠的是工程化的防漂移体系：

• 生成器盖章：tools/generate.mjs 把models.json中的角色、层级、默认值统一写入每个技能的## Models段落、setup-pstack覆盖表和interrogate的评审员表格，技能正文只允许出现"角色名"，不允许出现裸模型 slug；
• CI 校验：生成器以--check模式运行，任何过期副本都会让构建失败；tests/models.test.mjs 则验证了重复 slug、层级引用错误等畸形配置会被拒绝并指明具体角色；
• 修改纪律：官方贡献规范（CONTRIBUTING.md）明确要求"改模型默认值只改models.json，永远不改技能正文"。

小结

pstack 的 Panel 机制回答了一个朴素的问题：如何让 AI 编程助手少犯"自信的错误"？答案是引入模型间的多样性——3 个不同模型并行做同一件事，用交叉评审和共识分级来过滤噪声，用单一事实源加生成器来保证配置不漂移。对于想要把 AI 代理工作流从"能用"提升到"可信"的开发者，这套多模型协作面板的设计值得借鉴。

【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Poteto's pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude