Wisepanel

Wisepanel MCP 服务

前沿模型与高后果决策之间的决策智能层。

Wisepanel 接收一个问题，围绕它组建一个 AI Agent 小组，让它们展开辩论。你会得到经受住辩论的各方观点、每个观点背后的推理，以及始终未能达成一致的分歧。

此 MCP 服务可供 Claude Code 和任何兼容 MCP 的客户端使用。

为什么

单个模型会流畅地给出一个答案，不管它是否正确。对于大多数问题来说，这没什么问题。但如果答错代价高昂，这就是个糟糕的特性。

问题通常不在于模型不知道答案，而在于模型很早就选定一种思路，然后为之辩护，因此你看不到反对意见、其他可能性，或真正起作用的假设。再问一次，你得到的还是同一种思路，只不过换了种说法。分别询问三个模型，你会得到三个自信满满的答案，却无从判断该选哪一个。

工作原理

Wisepanel 在三个层面上刻意构建分歧。

第一——给每个 Agent 一个需要化解的冲突。 角色根据你的问题推导而来，每个角色都由两种真正相互对立的力量定义：成本与可及性、速度与安全、经过验证与新颖。Agent 不能只拥护一方，而必须找到兼顾两方的立场，因此它给出的不是论点，而是经过充分推敲的见解。

第二——每个 Agent 化解的冲突各不相同，因此它们的立场也不相同。 负责权衡成本与可及性的 Agent，得出的结论会不同于负责权衡速度与安全的 Agent。这并非一场辩论的正反两方，而是对同一个问题做出的多种坦诚权衡。它们对于哪些因素最重要看法不一，但合在一起，便能涵盖问题实际涉及的方方面面。

第三——这种结构让它们彼此交锋。 Agent 被放置在多面体的边上，因此每个 Agent 都参与两个顶点上的讨论，也就是两场独立的对话。在第二个顶点上，Agent 不只是参与者，还是第一个顶点的代表；它会将自己与其他参与者在第一个顶点得出的结论，连同自己的立场一起陈述出来。因此，每个顶点都能听到自己未曾参与的完整讨论，并由亲历者加以阐述。

正是最后这一点，让小型小组发挥出超越人数的作用。六个 Agent 意味着十二个席位，每个席位都会带入另一场讨论——因此，任何地方提出的观点都能在几轮之内传达给整个小组，没有汇总者、总结者或瓶颈。发言顺序经过平衡，不会有任何 Agent 第一个定下讨论基调，也不会有任何 Agent 最后总结发言。 详情。

这不就是询问三个模型吗？

把同一个问题分别粘贴到 Claude、GPT 和 Gemini 中，确实是一种有效的方法，而且它之所以有效是有原因的：不同实验室采用不同的数据和方法进行训练，因此它们的先验确实不同。Wisepanel 也采用同样的做法——默认将不同角色分配给 Anthropic、OpenAI、Google 和 Perplexity，因此不会让任何一家实验室的盲点无人质疑。

但模型只是偏见产生的其中一个环节。一共有四个环节，手动操作只能覆盖一个。

你给出的提问框架会原封不动地发送给所有模型。 你把相同的话粘贴三次，因此是用三种训练基础来回答对问题的同一种解读。当问题带有假设时——而涉及决策的问题通常如此——你会得到三个自信地回答了错误问题的答案。 wisepanel_magic_prompt 会在面板看到问题之前改写提问框架。

每个模型都以自己的身份作答。 你会得到 Claude 的中间立场、GPT 的中间立场、Gemini 的中间立场，而中间立场往往大同小异。面对中性问题，模型会给出平衡的答案；它不会主动提出反对你计划的最有力论据，因为你并没有要求它这么做。分配角色会改变模型的优化目标，从而产生它们在没有提示时都不会提出的论据。

在模型之间传递答案只会加剧锚定效应，而不会改善结果。 把 A 的回答交给 B，B 就会在 A 的框架内推理——模型往往会接受已表明的立场并加以完善，而不是将其舍弃并重新开始。因此，顺序提问比三次独立查询偏见更重，而且你恰好先打开的那个模型会设定讨论的基调。Wisepanel 会平衡发言顺序，并将对话分散到不同的顶点，正是为了避免某个立场成为所有人都要回应的立场。

由你来综合各方意见。 三个答案摆在面前，却没有人比较过它们。你得自己完成这项工作，带着自己的先验判断，通常是在漫长的一天结束时，面对一个你本来就倾向于某个答案的决策。面板会先让各方交锋，再把经受住检验的观点交给你。

还有一件事，手动操作无法规模化。三个模型就是三个样本。一个面板则由 6 到 30 个角色组成，旨在从不同角度探讨问题；每个角色都持有一个对立观点，并与另一个顶点展开第二场对话——最小规模也有 12 个席位。你不会手动运行这么多角色，更不可能在每个值得认真对待的决策中都始终如一地这么做。

手动操作的优势： 它免费、即时，而且你可以完全掌控措辞。对于大多数问题，这种权衡是正确的。但有些问题并非如此。

论证中的检查机制

• 首先检查问题是否存在偏见。 wisepanel_magic_prompt 会在面板看到问题之前，改写带有倾向性的提问框架、内含的假设和虚假的二选一。带有偏见的问题会让模型自信地回答错误的问题。
• 推理过程可供审查。 Agent 会标注主张、揭示假设，并指出彼此推理中的漏洞——默认启用。请参阅 show_and_audit_reasoning。
• 可以根据来源核查主张。 可选的原生网页搜索功能会核实日期、引文、数字和规则，而不是依赖记忆。请参阅 web_search_enabled。

何时使用

当犯错代价高昂时——例如需要多年沿用的架构决策、迁移、安全与隐私权衡、供应商选择，以及任何你想在做出决定前听到反对自身直觉的最有力论据的情况。它比单次查询更慢、成本也更高。这就是你要做出的权衡。

以下情况不要使用： 问题已有明确答案，或者即使听到不同意见，你也不会改变行动。

运行过程会实时流式显示，因此你可以观看论证逐步展开，而不必等待最终结论。 已完成的审议也可以发布到 Wisepanel Commons。

快速开始

在 wisepanel.ai/settings 获取 API 密钥，然后：

claude mcp add wisepanel --scope user \
  --env WISEPANEL_API_KEY=wp_sk_ExampleOnly0000-replace-with-your-own-key \
  -- npx -y wisepanel-mcp

请完全按照设置页面上的显示粘贴密钥——只粘贴完整的 wp_sk_… 字符串，不要附带其他内容。密钥两侧的引号可加可不加，不会造成影响。不要添加 Bearer 前缀：服务会自行发送 Authorization: Bearer <your-key>，因此添加前缀会变成 Bearer Bearer wp_sk_…，导致身份验证失败。

重启 Claude Code 并运行 /mcp——wisepanel 应显示为已连接。

✔ Connected 仅表示服务进程已启动。首次调用之前不会检查 API 密钥，因此即使密钥无效，也会显示为已连接。若要确认身份验证确实有效，请运行一次研讨，并检查是否返回了 run_id。

这是一个 stdio 服务，不是远程服务。 它没有 HTTP 端点——无论提供什么 URL，claude mcp add --transport http 都无法使用。 -- 后面的所有内容都是在本地启动服务的命令。

{
  "mcpServers": {
    "Wisepanel": {
      "command": "npx",
      "args": ["-y", "wisepanel-mcp"],
      "env": {
        "WISEPANEL_API_KEY": "your-api-key"
      }
    }
  }
}

配置

故障排除

'url' is not a valid URL——添加服务时使用了 --transport http。 请移除该服务，并使用上面的 stdio 命令重新添加：

claude mcp remove wisepanel --scope user

WISEPANEL_API_KEY environment variable is required——密钥未传递给服务进程。请按示例使用 --env 传递，而不要将其作为 Authorization 标头传递；标头仅适用于远程服务。

API 401 / 使用有效密钥仍未通过身份验证——使用 claude mcp get wisepanel 检查已保存的值。它必须是未添加前缀的 wp_sk_… 字符串。常见原因包括添加了 Bearer 前缀、末尾带有空格，或粘贴不完整。

未通过身份验证——请在 wisepanel.ai/settings 确认密钥仍然有效。密钥属于机密信息：切勿将其粘贴到聊天、问题帖或截图中。如果密钥泄露，请撤销并重新签发。

工具

wisepanel_start

开始一次研讨。召集由多个 AI 模型组成的讨论小组，让它们从指定视角辩论一个问题。立即返回 run_id。

拓扑

Agent 位于多面体的边上，因此 Agent 数量等于边数：

时间和成本随 Agent 数量增长——large 是 small 的 5 倍。只有当问题确实需要更多不同的观点时才升级，而不是为了从相同的 Agent 那里得到更好的答案。

为何选择边而非顶点。 柏拉图立体的每条边在立体的对称群作用下都等价，而且发言顺序经过平衡，因此没有 Agent 会一贯地先入为主，也不会一贯地拥有最后发言的优势。这里没有中心节点，也没有特殊席位。图的直径始终较小——分别为 1、2 和 3——因此，无论在哪里提出的见解，都能在几跳之内传遍整个讨论组。由于每个 Agent 都位于一条边上，它既是参与者，也是桥梁：传播是参与带来的副作用，无需信使或聚合者角色。

全互联以二次成本实现相同的覆盖范围和均衡性。在规则多面体上按边分配席位，能够以线性成本同时实现这两点。

模型组

成本相对于默认选项 smart：

单一提供商组（openai、anthropic、google、perplexity）会将每个席位固定到同一家厂商，从而消除跨厂商的多样性——而这通常正是组建讨论组的目的。

轮次

Agent 位于多面体的边上，而非顶点上。每个 Agent 连接两个顶点（对话节点），并在每轮的两个端点都作出贡献——因此，rounds: 1 已能产生大约 num_agents × 2 条响应。

轮次是完整遍历多面体的过程，而不是聊天轮次。rounds: 1 已足以进行充分讨论。只有当 Agent 需要回应其他 Agent 的完整立场时才使用 2 轮或更多轮——例如，对一项正反观点鲜明的二元战略决策进行讨论。

wisepanel_magic_prompt

改写问题，去除可能使讨论组倾向于预设答案的表述——带有倾向性的措辞、嵌入的假设、错误的二选一——同时保留原意。 可选的预处理步骤，可在 wisepanel_start 之前执行。

返回以下三种结果之一。每种情况下都会回传原问题，因此你始终可以使用原问题：

向用户展示两个版本，并让他们自行选择。 改写可能会改变用户不希望改变的侧重点，因此绝不能在用户不知情的情况下替换原问题。这与 Web 应用的做法一致：只有用户明确点击后才会执行转换，且会先确认费用，并提供还原选项。

与审议过程分开计费，且仅在文本实际发生变化时计费。

wisepanel_poll

对正在进行的审议执行长轮询（最多等待 15 秒以获取新事件）。返回陆续收到的讨论组成员回复。

wisepanel_result

获取已完成审议的完整结果。仅在未实时轮询时需要调用。

wisepanel_cancel

取消正在进行的审议。

wisepanel_publish

将已完成的审议发布到 Wisepanel Commons。发布后内容将公开可见并可供分享。

wisepanel_list_runs

列出当前会话中的所有审议运行记录。

典型流程

1. wisepanel_start    -> returns run_id
2. wisepanel_poll     -> (repeat) returns panelist responses as they arrive
3. On completion, poll includes publish_available: true
4. wisepanel_publish  -> publishes to Commons, returns public URL

环境变量

开发

git clone https://github.com/ikoskela/wisepanel-mcp.git
cd wisepanel-mcp
npm install
npm run dev

专利申请中

Wisepanel 的多 Agent 审议架构——包括多面体拓扑结构以及推理审计和验证子系统——是 QuROI, Inc. 已提交的美国专利申请的主题。

许可证

MIT——参见 LICENSE。

MIT 许可证仅适用于本代码库中的客户端。它不授予任何专利的明示或默示许可，也不适用于 Wisepanel 平台及其实现的方法。