Amogus：基于MCP的多智能体结构化辩论框架，提升AI决策质量-平芜编程栈

1. 项目概述：为AI智能体引入“结构化辩论”的决策层

如果你用过AI编程助手，比如Cursor或者Claude Code，肯定遇到过这种情况：你给它一个复杂的任务，比如“帮我用React和Node.js搭建一个电商后台，要包含用户认证和支付”，它很快就能给你生成一份看起来非常详尽的计划。这份计划通常步骤清晰、技术栈明确，读起来很有说服力。但问题在于，这份计划是单一视角、未经挑战的产物。它可能忽略了某个关键依赖项的版本冲突，可能低估了某个模块的复杂度，也可能选择了一个看似流行但即将被淘汰的库。在真实的工程团队里，一份计划会经过产品经理（要快）、架构师（要稳）、资深工程师（要靠谱）和新人（会问为什么）的多角度审视和辩论，最终形成的方案才是经得起推敲的。而单个AI智能体，恰恰缺少了这种“内部张力”。

今天要介绍的这个项目——Amogus，就是为了解决这个问题而生的。它不是一个全新的AI模型，也不是一个复杂的编排框架，而是一个基于Model Context Protocol (MCP)的“结构化审议层”。你可以把它理解为一个AI智能体的“议会”或“评审委员会”。当你的主AI智能体（比如Cursor里的AI）需要做一个重要决策或制定复杂计划时，它可以调用Amogus这个工具。Amogus会模拟四个拥有不同思维定式和职责的“议员”，让他们在完全隔离的环境下独立分析问题、提出批判和修改意见，并进行多轮辩论，最终投票合成一个最优方案。这个方案会附带详细的审议记录、每个议员的观点以及置信度评分，返回给你的主智能体去执行。

这个项目在Cursor Hack London 2026黑客松上获得了亚军，赛道是“Agent Runtime Tools”，完美契合了“让智能体在行动前为其决策提供充分理由”的命题。它最吸引我的地方在于其架构的简洁和有效：不依赖复杂的强化学习或微调，而是通过精心设计的流程和角色隔离，强制引入多元视角，用“制度”而非“提示词技巧”来对抗LLM（大语言模型）固有的趋同倾向。对于任何正在构建或使用AI智能体进行复杂任务开发的开发者、项目经理或技术负责人来说，理解并应用这种“多智能体审议”模式，能显著提升AI产出方案的质量和可靠性。

2. 核心设计思路：用“制度性隔离”对抗思维趋同

在深入代码之前，我们必须先理解Amogus解决核心问题的设计哲学。多智能体系统一个众所周知的失败模式是“回声室效应”或“观点收敛”。即使你初始化了四个不同的AI角色，如果让它们能看到彼此的推理过程，那么后发言的智能体有很大概率会简单地附和前者的观点，说“我同意，因为……”。这并不是智能体“偷懒”，而是LLM基于概率生成文本的本质所决定的——顺着已有的、合理的论述继续下去，是概率上最可能的路径。

Amogus的创始人洞察到了这一点，并提出了一个根本性的解决方案：结构性隔离。它不是靠提示词里写“请务必提出不同意见”这种苍白的要求，而是通过架构设计，在物理和流程上阻止智能体在形成独立观点前进行任何信息交换。

2.1 四议员架构与强制评估框架

项目的核心是四位固定的“议员”，每位都被赋予了一个鲜明的工程原型和一套强制评估框架。这套框架是一组该议员必须在形成任何立场前回答的特定问题。正是这些不同的问题，引导着同一个底层LLM（比如Claude）走向不同的推理路径。

RAZOR（刀锋，红色）：交付至上者。他的核心问题是：“实现可工作产品的最快路径是什么？”“计划中哪里隐藏了复杂性？”“哪些可以推迟到v2？”“真实的工时估算是多少？”他的目标是砍掉一切不必要的部分，追求最快交付。
GHOST（幽灵，紫色）：悲观主义者。他的思考围绕失败展开：“在10倍负载下什么会崩溃？”“每一步的回滚计划是什么？”“哪些依赖项可能会出问题？”“哪些错误情况没有被处理？”他负责寻找所有可能的失败点。
SCOUT（侦察兵，绿色）：研究员。他关注外部世界：“现有哪些解决方案可以解决这个问题？”“基准测试数据怎么说？”“相关技术的采用趋势如何？”“我们是否忽略了已有的最佳实践？”他确保团队不重复造轮子，并能利用最新的社区成果。
BISHOP（主教，黄色）：架构师。他思考系统的长期健康度：“执行后的依赖关系图是怎样的？”“这会产生耦合吗？”“步骤的顺序正确吗？”“应该定义哪些抽象层？”他负责确保方案的结构清晰、可维护。

这种设计巧妙地形成了天然的对立阵营：RAZOR和SCOUT通常倾向于“用现成的库，快速上线”，而GHOST和BISHOP则倾向于“构建得更稳健，加上安全护栏”。这种张力模拟了真实工程团队中的动态辩论，是产生高质量方案的催化剂。

2.2 两轮审议流程：从隔离到对抗

有了角色定义，审议流程的设计确保了隔离和对抗的有效性。整个流程是一个清晰的管道：

第一阶段：侦察用户输入提示词（如“构建一个无错误的Cursor插件”）后，首先进入“侦察”阶段。系统会提取任务中的关键主题，并并行进行网络搜索（利用Claude的联网搜索工具），收集GitHub仓库、npm包、技术博客、基准测试等上下文信息，合成一份背景简报。这确保了所有议员的讨论都基于事实，而非空想。

第二阶段：原始计划生成一个由单一智能体制定的“原始计划”。这个计划是后续审议的基线，代表了“未经挑战的常规AI输出”，用于与最终方案进行对比，直观展示审议带来的价值。

第三阶段：第一轮 - 隔离审议这是最关键的防收敛机制。四位议员并行且完全隔离地被调用。他们各自收到：原始任务提示、侦察阶段收集的上下文简报、以及那份“原始计划”。然后，他们必须严格按照自己角色的“强制评估框架”回答问题，并基于此生成：1) 对原始计划的批判；2) 自己修订后的计划；3) 对“是否采纳原始计划”的投票（赞成/反对）。在此轮中，任何议员都无法看到其他议员的任何输出。他们的推理链在隔离环境中独立生长。

如果第一轮投票出现一致（全票赞成或反对），则流程直接跳至最终合成阶段。但通常会出现分歧，这时就进入下一轮。

第四阶段：第二轮 - 挑战与反驳所有议员第一轮的立场（批判、修订计划、投票）被同时公开。每个议员必须选择另一个与自己立场不同的议员进行针对性挑战。例如，投赞成票的RAZOR可能会挑战投反对票的GHOST：“你提到的负载问题，我们可以通过增加缓存层来解决，这并不影响初期MVP的交付。”被挑战者可以进行反驳。最后，所有议员提交最终投票，他们可以选择“坚持”原立场，或“叛变”到另一方。

这里引入了叛变惩罚机制：“死神”模块会记录议员的叛变行为。在最终计分时，叛变会损害该议员的“声誉”得分。这从制度上防止了无原则的跟风，鼓励议员基于论据而非票数来决策。

第五阶段：裁决与合成最终投票不是简单的一人一票，而是加权投票：最终权重 = 置信度 × 历史战绩。一个长期表现优秀的议员（高历史战绩）的投票权重会更高。裁决产生后，一个中立的“书记员”角色会工作。它不参与辩论，只负责将所有议员的批判、修订意见进行汇总、去重和整合，生成一份结构化的最终计划文档。这份文档会清晰标注每一条建议来源于哪位议员，让用户一目了然地看到不同视角的贡献。

2.3 进化压力：“死神”与成员迭代

一个静态的议会可能会僵化。Amogus引入了“死神”机制来模拟进化压力。每经过5次决策，系统会计算每个议员的综合得分：得分 = (获胜次数 + 与人类覆写一致的次数) / 总决策次数 - (叛变次数 × 0.5 / 总决策次数)得分最低且低于阈值（如0.3）的议员会被“处决”。随后，系统会“孵化”一名新议员，其基础原型随机，但会从当前得分最高的议员那里继承一个“强制评估框架”问题。同时，系统会记录其“血统”，例如“GHOST-v3（具有RAZOR特质的幽灵）”。

通过这个循环，糟糕的推理模式会被淘汰，成功的思维特质得以传承。议会能够通过council_override（人类覆写）反馈循环，逐渐适应其服务对象的真实偏好。如果用户经常推翻GHOST的保守意见，那么GHOST的得分就会降低，其特质被继承的可能性也变小，整个议会会慢慢向更激进的方向演化。

3. 技术实现深度解析

理解了设计理念，我们来看看这套精妙的系统是如何用代码构建的。项目采用TypeScript/Node.js开发，核心是一个MCP服务器。

3.1 基于Model Context Protocol的集成

MCP是一个新兴协议，旨在标准化AI智能体与外部工具、数据源之间的通信。Amogus选择MCP是极具远见的，这使得它编辑器无关。无论是Cursor、Claude Code、Windsurf还是任何自定义的智能体运行时，只要支持MCP客户端，就可以无缝集成Amogus的审议能力。

Amogus服务器通过stdio（标准输入输出）与MCP客户端通信，暴露了五个工具：

council_plan: 核心工具，触发完整的审议流程。
council_members: 查看当前议员阵容和战绩。
council_history: 查看决策审计追踪。
council_override: 人类反馈接口，用于纠正历史决策，影响议员评分。
council_sandbox: 打开实时可视化沙盒。

这种设计将复杂的多智能体审议能力封装成了一个简单的“工具调用”，对主智能体来说，就像调用一次搜索引擎或计算器一样简单。

3.2 并发LLM调用与状态管理

审议流程的核心是并行LLM调用。在“隔离审议”轮，系统需要同时调用四次Claude API。项目使用Promise.allSettled来管理这些并发请求，确保即使某个调用失败，流程也能继续（例如，记录该议员弃权），而不是整体崩溃。

每个议员的“强制评估框架”被实现为一组精心设计的系统提示词（System Prompt），这些提示词定义了角色的性格、职责和必须回答的问题列表。调用时，用户提示、上下文和原始计划会作为用户提示词（User Prompt）注入。LLM被要求以严格的JSON格式输出，包括critique、revised_plan和vote字段。这种结构化输出避免了自然语言输出的模糊性，便于程序化处理投票和合成。

状态管理（当前议员、历史记录、得分）被封装在独立的模块中。由于MCP服务器可能是常驻进程，需要妥善处理内存中的状态持久化问题。项目采用了相对简单的内存存储，对于黑客松项目来说足够，但在生产环境中可能需要考虑引入Redis等外部存储来实现状态持久化和多会话支持。

3.3 可视化沙盒：用游戏化降低理解门槛

技术项目最难的部分之一是演示。Amogus的“Among Us”可视化沙盒是其一大亮点。它不是一个事后生成的录像，而是一个由MCP服务器直接提供静态文件服务并推送WebSocket事件的实时可视化系统。

技术栈：使用Next.js 15构建，并静态导出为纯HTML/JS/CSS资源。这些资源由MCP服务器内置的一个简易HTTP服务器提供。这意味着不需要启动额外的Node进程或复杂的后端。
渲染：核心动画使用HTML5 Canvas绘制，实现了“太空狼人杀”游戏中的经典场景：船员（议员）在不同工作站（研究、文档、基准测试、GitHub）间移动、进入隔离舱、围绕会议桌辩论等。
实时性：审议流程的每一个关键步骤（开始侦察、议员A完成思考、开始投票等）都会触发一个类型化的事件，通过WebSocket从服务器推送到前端浏览器。前端根据事件类型更新Canvas动画和右侧的文字面板（显示批判内容、投票进度等）。
“死神”动画：当触发淘汰机制时，画面会变红，得分最低的船员角色会被拖到绞刑架动画处，然后一个新的角色从孵化器中诞生，视觉效果非常直观。

这个沙盒不仅让演示极具观赏性，更重要的是，它让原本黑盒般的多智能体辩论过程变得透明、可观察，极大地增强了用户对系统的信任感和控制感。

3.4 错误处理与健壮性考量

虽然是一个黑客松项目，但代码中体现了一些生产级的思考：

端口管理：可视化沙盒的HTTP/WebSocket服务器启动时，会动态探测可用端口（从3000开始），如果被占用则自动尝试下一个，避免了常见的EADDRINUSE错误。
路径遍历保护：在提供静态文件服务时，对请求的路径进行了解析和验证，防止恶意用户通过../../../这样的路径访问服务器上的敏感文件。
API错误处理：对Claude API的调用有基本的错误处理和重试逻辑，并发调用使用allSettled确保局部失败不影响整体。

4. 实战：从零集成与调用Amogus

理论说了这么多，我们来实际操作一下，看看如何将Amogus集成到你的开发环境中，并实际调用它来评审一个AI生成的计划。

4.1 环境准备与安装

假设你使用的是Cursor编辑器，这是该项目最原生的集成环境。

第一步：克隆项目并安装依赖

# 克隆仓库 git clone https://github.com/ViktorSmirnov71/amogus.git cd amogus # 安装MCP服务器依赖 cd mcp-server npm install cd ..

第二步：配置API密钥你需要一个Anthropic Claude的API密钥。

# 在项目根目录创建.env文件，填入你的密钥 echo "ANTHROPIC_API_KEY=sk-ant-your-actual-api-key-here" > .env

注意：请妥善保管你的API密钥，不要将其提交到版本控制系统。.env文件已被添加到.gitignore中。

第三步：配置Cursor的MCP设置Cursor通过一个JSON配置文件来发现和管理MCP服务器。

# 复制示例配置 cp .cursor/mcp.json.example .cursor/mcp.json

然后编辑.cursor/mcp.json文件，确保command指向你本地mcp-server目录下的入口文件，并将API密钥作为环境变量传入。文件内容大致如下：

{ "mcpServers": { "amogus": { "command": "node", "args": [ "/ABSOLUTE/PATH/TO/YOUR/amogus/mcp-server/build/index.js" ], "env": { "ANTHROPIC_API_KEY": "sk-ant-your-actual-api-key-here" } } } }

提示：使用绝对路径更可靠。你也可以在args中直接指向编译后的JS文件（如果执行了npm run build）。

第四步：重启Cursor配置完成后，完全关闭Cursor并重新打开。打开设置（Cmd+,或Ctrl+,），搜索“MCP”，你应该能在“Model Context Protocol Servers”下看到amogus已连接。

4.2 发起第一次审议

现在，你可以在Cursor的AI聊天框中，直接要求AI使用council_plan工具。最经典的测试提示就是项目本身的口号：

“Use thecouncil_plantool to plan: build me Cursor, make no mistakes.”

发送后，Cursor的AI（通常是Claude）会识别到可用的council_plan工具，并发出调用请求。此时，你会看到：

终端或后台：MCP服务器启动，开始执行侦察、多轮审议流程。
浏览器：可能会自动弹出一个窗口，显示Among Us沙盒界面，你可以实时观看四个船员（议员）忙碌、辩论、投票的动画。
Cursor聊天框：最终，AI会收到一个结构化的响应。这个响应不是简单的文本，而是一个包含以下内容的复杂对象：
- verdict: 最终裁决（通过/拒绝）。
- confidence: 总体置信度。
- synthesized_plan: 集大成的、可执行的详细计划，通常以PRD（产品需求文档）或技术方案的形式呈现。
- deliberation_transcript: 完整的审议记录，包括每一轮每位议员的批判、修订计划和投票。
- vote_breakdown: 最终的投票统计。

你可以要求AI将这个计划解析并展示给你。你会发现，相比于直接让AI生成一个计划，这份经过审议的计划通常会：

更可行：包含了RAZOR提出的分阶段交付建议。
更健壮：包含了GHOST提出的错误处理和回滚步骤。
更现代：包含了SCOUT推荐的最新、最合适的库或框架。
更清晰：包含了BISHOP绘制的模块依赖图和接口定义。

4.3 审查历史与施加人为影响

审议不是一锤子买卖。你可以使用其他工具来监督和引导这个议会。

查看历史：在Cursor中询问“Show me thecouncil_history”。AI会调用工具，返回过去所有决策的摘要，包括提示词、投票结果和最终裁决。这就像一个审计日志。
覆写决策：如果你认为某次审议的最终裁决是错误的，你可以使用council_override工具。例如，假设议会以微弱优势否决了一个你认为应该通过的计划，你可以提供该决策的ID（从历史中获取）和你认为正确的裁决（通过）。系统会记录这次覆写，并相应调整相关议员的得分（支持你决定的议员得分增加，反对的得分减少）。这是系统学习和适应你偏好的关键机制。
观察进化：每隔5次决策，关注一下council_members的输出。你会看到议员的“世代”数在增加，可能某个原始成员已经被“处决”，替换成了一个带有混合特质的新成员。这展示了系统的动态适应性。

5. 扩展思考与潜在应用场景

Amogus虽然诞生于一个“为AI智能体规划代码项目”的语境，但其“结构化多角色审议”的模式具有广泛的通用性。我们可以跳出编程的范畴，思考它的潜力。

5.1 模式抽象：一个通用的决策增强层

Amogus的核心可以抽象为一个“决策增强层”：

输入：一个待决策的议题、一个初始方案（可选）、相关的上下文信息。
处理：通过多个具有不同视角和评估框架的“代理”进行隔离分析和对抗辩论。
输出：一个经过优化的决策或方案，附带完整的正反方理由和置信度。

这个模式可以应用于：

商业决策：输入一个市场进入策略，让“增长黑客”、“风险控制官”、“财务分析师”、“合规专家”四个角色进行审议。
内容创作：输入一篇新闻稿草稿，让“编辑”、“公关专家”、“法律顾问”、“目标读者代表”进行评审。
产品设计：输入一个功能原型，让“用户体验设计师”、“工程师”、“产品经理”、“客服代表”进行评估。

关键在于定义好角色的“强制评估框架”。这些框架问题就像一个个棱镜，将同一个信息源折射出不同的光谱。

5.2 与现有AI工作流集成

除了作为Cursor等编辑器的MCP工具，Amogus的服务器可以很容易地被集成到其他自动化工作流中。

GitHub Actions / CI/CD：在代码合并（Merge）前，自动调用Amogus对本次变动的架构影响、测试覆盖率、潜在风险进行审议，并将审议报告附加到Pull Request中。
LangChain / LlamaIndex：作为这些AI应用框架中的一个自定义“工具”或“代理”，在链式调用中为关键决策点提供复核。
独立评审服务：部署为一个独立的HTTP API服务，任何系统都可以通过RESTful接口提交议题，获取结构化审议报告。

5.3 局限性、挑战与改进方向

当然，Amogus作为一个概念验证项目，也有其局限性和可改进之处：

成本：每轮审议需要调用多次LLM API（侦察1次 + 原始计划1次 + 4议员 * 2轮 = 至少9次调用），成本较高。优化方向包括：对简单议题跳过第二轮；使用更小、更便宜的模型进行初步筛选；缓存常见问题的审议结果。
延迟：并行调用虽然快，但整个流程仍需要数十秒。不适合需要毫秒级响应的交互场景。
角色固化：四个预设角色可能无法覆盖所有问题领域。改进方向是允许用户自定义角色和评估框架，甚至让系统根据历史数据自动演化出最适合当前任务的角色组合。
“假性共识”风险：即使有隔离和叛变惩罚，如果底层LLM的“价值观”或“知识库”本身存在强烈偏见，所有角色仍可能得出相似的错误结论。需要引入更多样化的知识源或模型（如混合使用Claude、GPT、开源模型）来降低这种风险。

6. 总结：从工具到思维模式

回顾整个项目，Amogus带给我的最大启发不是其具体的技术实现（虽然其MCP集成和可视化做得非常出色），而是它提出的一种对抗AI思维单一性的方法论。它告诉我们，提升AI决策质量的关键，未必是等待下一个万亿参数的模型，而是如何更好地组织和使用现有的模型。

它把人类团队决策中的“头脑风暴”、“红队演练”、“设计评审”等最佳实践，翻译成了AI能够理解和执行的算法流程。通过结构产生张力，通过隔离保护多样性，通过进化实现适应。这为所有AI应用开发者提供了一个极具参考价值的范式。

当你下次看到AI生成一个天衣无缝的计划时，不妨在内心启动一个“微型Amogus”：问问自己，一个追求速度的我会怎么改？一个担心风险的我会怎么改？一个关注外部技术的我会怎么改？一个考虑长期架构的我会怎么改？或许，这就是人机协作中最有价值的部分——人类负责定义流程和框架，AI负责在框架内进行穷举和演绎，共同抵达一个更优的解。