fstack-counselors

/fstack-counselors

三位模型围绕同一个问题组成一个议事会。每位顾问独立作答，然后将这些答案进行比较，并归结为一条明确的建议——同时总结每位顾问的意见，尤其是在他们意见不一致的地方。

何时使用

• 一个决策足够重大，以至于仅凭一个模型的意见还不够。
• 架构选择、棘手的权衡、“我们应该做 X 还是 Y”之类的问题。
• 你希望在敲定一个方案、一个 diff 或一个设计之前，先听听第二意见。

步骤

1. 将问题整理成一份 自包含的简报：问题本身、相关背景（文件、约束、已经尝试过什么），以及你想要的答案格式。每位顾问都拿到这份完全相同的简报，别无其他。
2. 选定议事会成员：此环境中 可用的 3 个最强模型。在派出之前，先告诉用户议事会有哪些成员。如果环境无法混合使用不同模型，就用最强的那个模型运行 3 个独立会话——独立运行仍能暴露分歧。如果环境根本无法运行独立 Agent，就如实说明并直接作答。绝不假造议事会。
3. 设定投入程度。如果用户有指定，就照办。如果没有，默认采用 中等 / 均衡 的推理——既能好好思考，又不必承担全部成本和延迟。只有在用户明确要求，或问题明显事关重大时，才提高到最高级别。
4. 将同一份简报派发给每位顾问，并行且只读。任何顾问都看不到其他人的答案。
5. 阅读全部三份答案。梳理出他们哪些地方一致、哪些地方不一致。
6. 分两部分给出结果：
   • 裁决。 一条明确的答案。当顾问们意见不一致时，选一边并说明理由——不要折中。
   • 议事会。 每位顾问一段总结，每段 2 到 3 行，写明模型名称。标出每一处分歧，以及裁决如何化解它。2 比 1 的分歧就按 2 比 1 来报告。
7. 到此为止。 依据裁决采取行动是另一个决定。如果用户想动手构建，建议使用 /fstack-plan 或 /fstack-build。

绝不可

• 让顾问在给出自己的答案之前看到彼此的答案。独立性正是全部意义所在。
• 把分歧折中成一团糨糊。“所有方案都有可取之处”不是裁决。
• 隐藏异议。如果有一位顾问不同意，用户应当知道，并知道原因。
• 让顾问改动文件。议事会只阅读和发表意见；它绝不写入。
• 为琐碎问题召集议事会。三个模型来讨论“这个变量该叫什么名字”是浪费。

示例

用户：/fstack-counselors 我们应该把认证从服务器会话改为 JWT 吗？

Agent：“议事会：[此处可用的 3 个最强模型]。给每位发送同一份简报：你的认证代码、你提到的扩展约束，以及这个问题。几分钟后回来。”

（三份独立答案返回）

Agent：“裁决：保留服务器会话。 议事会以 2 比 1 分裂。

顾问 1 —— 保留会话。你的应用是服务端渲染，只有一个后端；JWT 会带来吊销问题，并解决一个你并不存在的分布式问题。

顾问 2 —— 保留会话，核心理由相同。补充：如果 API 以后需要令牌，就从会话签发短期令牌，而不是全盘切换。

顾问 3 —— 改为 JWT，理由是未来多服务的情形。我选择反对，因为那种情形只是假设，而吊销成本却是眼前的。

想把这条写成方案里的备注，还是就把它当作一个决定留着？”

致谢

本文提炼自 Aaron Francis 的 counselors 中的顾问议事会模式。他的 CLI 会把一个提示词分发到本地安装的各个 Agent CLI；本技能则使用你的环境已有的一切。如果安装了 counselors CLI，它是执行这种分发的不错方式。