1. 项目概述一个为AI代理引入“结构化辩论”的决策引擎如果你用过Cursor、Claude Code这类AI编程助手或者自己捣鼓过AI Agent肯定遇到过这个场景你给AI一个复杂任务比如“帮我用Next.js 15和Tailwind从头搭建一个带用户认证的博客系统”AI会立刻给你吐出一个洋洋洒洒的计划。这个计划听起来头头是道步骤清晰但你心里总会犯嘀咕——“它真的考虑周全了吗有没有更好的库这个部署步骤会不会在云环境里卡住万一用户量突然上来数据库设计能扛住吗”问题就出在这里。单个AI代理的决策过程是“独裁式”的。它基于自己的知识库和当前提示词生成一个看似合理的单一方案但这个方案缺乏挑战、没有辩论、更没有不同视角的碰撞。在真实的软件工程团队里一个技术方案要经过产品经理要快、架构师要稳、资深工程师知道坑在哪和新手会问出最基础但关键的问题的多轮“拷问”才能最终拍板。这种“张力”恰恰是产生稳健方案的关键。Amogus — The Council这个项目就是为了把这种“团队辩论”机制注入到AI代理的决策流程里。它不是一个独立的应用而是一个基于Model Context Protocol的“决策增强层”。你可以把它理解为一个虚拟的、高度结构化的技术评审会任何支持MCP的AI工具如Cursor、Claude Code、Windsurf都可以随时调用它让四个性格迥异的“AI议员”对你的任务计划进行隔离辩论、相互挑战最终产出一个经过多维度审视的、带详细理由和备选方案的执行计划。这个项目在Cursor Hack London 2026上获得了Agent Runtime Tools赛道的第二名核心目标直指比赛悬赏#08“让AI代理在行动前为其决策提供理由”。它不只是让AI“解释”一下而是强制它经历一个完整的、防止“群体思维”的辩论流程并把所有正反论据透明地呈现给你。2. 核心设计思路用架构强制多样性对抗LLM的趋同本能设计多智能体系统的最大陷阱就是你以为搞了四个AI一起讨论结果它们“英雄所见略同”迅速达成一致。这本质上是因为大多数LLM在看到了其他AI的推理过程后其概率分布会自然而然地倾向于生成“我同意因为…”这类延续性文本。这根本不是真正的辩论而是“回声室效应”的加速版。Amogus的核心设计哲学就是通过架构层面的隔离与约束而非简单的提示词工程来强制产生多样化的观点。它认识到仅仅给AI赋予不同“角色”比如“乐观者”、“悲观者”是不够的必须用制度让它们“不得不”从不同角度思考。2.1 辩论流程的“两轮制”与结构隔离项目的核心流程是一个精心设计的两轮制辩论其精髓在于“隔离”第一轮隔离审议输入所有四位议员RAZOR, GHOST, SCOUT, BISHOP同时收到完全相同的原始需求、通过“侦察兵”阶段收集的上下文信息以及一个由单个AI生成的“原始计划”。关键约束在这一轮四位议员被完全隔离。它们看不到彼此无法进行任何形式的交流。每个议员都必须根据其独有的“强制评估框架”回答问题。输出每个议员独立提交一份包含“批判意见”、“修订后的计划”和“投票赞成/反对原始计划”的结构化输出JSON格式。第二轮挑战与反驳触发条件只有当第一轮的投票结果出现分歧非全票通过或否决时才会进入第二轮。过程所有议员第一轮的立场和理由被同时公开。每个议员必须选择另一个立场不同的议员进行针对性挑战并提出反驳。之后它们进行最终投票可以选择“坚持己见”或“改变立场”。防从众机制这里引入了一个“叛变惩罚”机制。如果一个议员在第二轮改变了自己的投票即“叛变”它的信誉分会受到惩罚。这从制度上抑制了无原则的跟风行为。这个设计模拟了高效的会议先让每个人独立思考形成观点再集中讨论碰撞。隔离确保了观点的独立性而结构化的挑战环节确保了讨论的针对性和深度。2.2 议员的“人设”与强制评估框架让四个AI产生不同观点的关键不是起不同的名字而是给它们截然不同的、必须回答的问题清单。这就是“强制评估框架”。即使底层是同一个Claude模型实例回答不同的问题必然导致不同的推理链条和结论。议员 (代号/颜色)核心人设强制评估框架必须回答的问题示例RAZOR (红色)执行者/交付狂1. 实现可运行产品的最快路径是什么2. 计划中哪里隐藏了复杂性3. 哪些部分可以明确推迟到V24. 每一步的现实工作量估算是否准确GHOST (紫色)悲观主义者/风险官1. 当负载增长10倍时什么会最先崩溃2. 每一步的兜底回滚计划是什么3. 哪些依赖项可能突然断供或出现重大变更4. 哪些错误情况被忽略了SCOUT (绿色)研究员/生态通1. 现有开源方案哪些能直接解决部分问题2. 相关技术栈的基准测试数据说明了什么3. 社区的趋势和采用率如何4. 是否忽略了某些重要的先前案例BISHOP (黄色)架构师/系统思维者1. 执行后的系统依赖图会变成什么样2. 这个方案是否会制造不必要的耦合3. 步骤的顺序在技术逻辑上是否正确4. 应该定义哪些清晰的抽象层这种设计天然形成了“2v2”的张力RAZOR和SCOUT通常倾向于“用现成方案快速上线”而GHOST和BISHOP则倾向于“设计稳健打好基础”。这种张力正是产出平衡方案所需要的。2.3 “死神”机制引入进化压力这是项目中最具游戏化色彩也最体现系统思维的一环。系统不会让议员们永远固步自封。评分每次决策后会根据议员的投票是否与最终采纳的方案一致、是否“叛变”等行为更新其个人得分。淘汰与进化每经过5次决策系统会进行一次评估。得分最低的议员如果低于阈值会被“处决”——从议会中移除。繁衍同时系统会“繁衍”一个新议员。这个新议员会随机继承一个基础人设但会从当前得分最高的议员那里继承一个“强制评估问题”。它的“族谱”会被记录例如GHOST-v3 (paranoid RAZOR traits)。这个机制模拟了“适者生存”。糟糕的思维模式会被淘汰成功的思考角度体现为某个好的评估问题会像基因一样在议会中传播。通过人类用户使用council_override工具对历史决策进行纠正系统还能间接学习到用户的真实偏好让议会整体向更有用的方向进化。3. 技术架构与实现拆解Amogus不是一个庞然大物它的架构清晰且高效在5小时的黑客松中完成体现了良好的工程取舍。3.1 协议层基于Model Context Protocol的轻量集成选择MCP是项目的关键决策这决定了它的定位和可用性。为什么是MCPMCP是一个新兴的、旨在标准化AI应用与工具之间通信的协议。它使用简单的stdio或HTTP作为传输层通过JSON-RPC进行通信。这意味着任何实现了MCP客户端的AI工具如Cursor、Claude Code都可以无缝调用Amogus而无需复杂的插件系统或API集成。Amogus将自己暴露为一组MCP工具完美契合了黑客松“Agent Runtime Tools”的赛道要求。核心工具council_plan: 核心工具触发完整的辩论流程。council_members: 查看当前议会成员状态和“族谱”。council_history: 审计日志查看历史决策细节。council_override: 人类反馈回路用于纠正历史决策影响议员评分。council_sandbox: 打开实时可视化沙盘。3.2 服务端Node.js与并发的LLM编排服务端使用TypeScript开发核心是高效、可靠地并行协调多个LLM调用。并发控制第一轮审议中四个议员的LLM调用是通过Promise.allSettled并发执行的这最大程度减少了等待时间。这是实现“隔离”的技术基础——它们物理上就是同时、独立发起的请求。结构化输出调用Claude API时严格使用JSON Schema来约束输出格式。这确保了无论模型生成多么冗长的文本最终都能被解析成程序可处理的标准化数据投票、批判点列表、修订计划避免了“用自然语言处理自然语言”的复杂性。上下文侦察在辩论开始前有一个独立的“侦察”阶段。这里直接利用了Claude API内置的联网搜索工具对任务涉及的关键词进行并行搜索获取最新的库信息、GitHub动态、文档等。项目明智地没有引入向量数据库或嵌入模型因为对于这种一次性的、任务相关的信息检索实时搜索的准确性和时效性更高架构也更简单。状态与通信服务端内置了一个轻量的HTTP/WebSocket服务器。它负责两件事一是托管可视化沙盘的静态文件二是通过WebSocket向沙盘推送实时事件如“议员A开始思考”、“进入第二轮”、“BISHOP挑战了GHOST”。这种设计将可视化与核心逻辑解耦沙盘只是一个“客户端”。3.3 可视化沙盘Next.js与Canvas的实时演绎可视化部分用“Among Us”游戏风格呈现极大地增加了项目的趣味性和演示效果。技术选型采用Next.js 15进行开发但构建为静态导出。这意味着沙盘的所有前端资源HTML, JS, CSS都是静态文件由上述的Node.js服务器直接托管。无需单独启动一个前端服务降低了部署复杂度。渲染核心游戏化的场景飞船地图、船员走动、会议桌动画使用HTML5 Canvas绘制而不是DOM。Canvas在处理大量动态图形和动画时性能更好也更适合这种“小游戏”风格的渲染。实时同步通过WebSocket与服务端连接。服务端在辩论的每个关键节点共定义了约18种事件类型都会推送事件前端根据事件类型更新Canvas动画和右侧的文本面板显示批判内容、投票进度等。这种事件驱动的方式保证了视图与后端状态的强一致性。自动寻址服务器启动时会自动探测可用端口避免了手动配置端口可能导致的冲突提升了用户体验。4. 实操如何集成并使用Amogus让我们抛开理论看看如何真正把它用起来。假设你是一个使用Cursor进行开发的工程师。4.1 安装与配置最快捷的方式是一行命令安装curl -fsSL https://raw.githubusercontent.com/ViktorSmirnov71/amogus/main/setup.sh | bash这个脚本会帮你完成克隆仓库、安装依赖、配置环境变量等所有步骤。如果你想手动操作步骤也很清晰克隆项目git clone https://github.com/ViktorSmirnov71/amogus.git安装依赖进入mcp-server目录运行npm install。配置API密钥在项目根目录创建.env文件填入你的ANTHROPIC_API_KEY。配置MCP客户端以Cursor为例将项目提供的.cursor/mcp.json.example复制为.cursor/mcp.json并修改其中的路径指向你本地的Amogus服务器入口文件。注意确保你的Claude API有足够的权限和额度因为一次完整的council_plan调用可能会消耗多次4的Claude API请求。4.2 在Cursor中发起一次议会辩论安装配置完成后重启Cursor。现在你的AI助手就具备了调用议会的能力。提出一个复杂需求在Cursor的Chat界面你可以直接输入“使用council_plan工具来帮我规划一下我要开发一个个人财务追踪Web应用后端用Python FastAPI前端用React需要包含交易导入、分类和简单报表功能。请确保方案考虑周全。”观察过程Cursor的Agent会识别到这个工具调用并启动Amogus服务。此时你的浏览器可能会自动弹出展示Among Us沙盘界面。你会看到四个小船员开始忙碌侦察阶段他们跑向不同的“研究站”Web搜索、文档、GitHub等收集信息。第一轮隔离船员们走进隔离舱头顶冒出思考气泡右侧面板开始滚动显示每位议员的批判意见。例如RAZOR可能会说“直接用Plaid API导入交易太复杂初期可以手动CSV上传。” GHOST则会警告“CSV解析必须处理各种日期格式和字符编码错误。”第二轮辩论如果需要船员们围到会议桌彼此之间出现挑战连线进行反驳。投票与合成投票条动态填充最终一个综合了所有意见、并带有颜色标注指出每条建议来自哪位议员的详细计划文档在屏幕中央“敲定”。获取结果最终Cursor会收到一个结构化的、可直接执行的“产品需求文档”。这个文档不仅包含步骤还会附注“RAZOR建议将‘实现投资账户同步’移至V2阶段。”“GHOST警告在交易分类算法中必须添加人工复核覆盖机制。”“SCOUT发现可以考虑使用react-chartjs-2库快速实现图表社区活跃。”“BISHOP设计应在后端明确划分数据导入层、业务逻辑层和API路由层。”现在你得到的不是一个平铺直叙的计划而是一个经过多角度辩论、风险被标识、备选方案被评估的增强版决策。你可以基于这个更有深度的计划继续让Cursor或你自己来执行。4.3 高级用法与系统维护查看议会状态如果你好奇当前议会的构成可以在Cursor里问“调用council_members看看。” 你会看到每个议员的胜率、被“处决”次数和遗传谱系。纠正历史决策如果你发现之前某次议会给出的最终建议在实际操作中是个坏主意你可以使用council_override工具来“翻案”。系统会调整相关议员的分数影响未来的进化方向让议会更贴合你的判断标准。审计与复盘通过council_history你可以回顾过去的每一次辩论看看当时每位议员的具体理由和投票情况这对于理解AI的决策逻辑非常有帮助。5. 开发心得与避坑指南在复现或借鉴这个项目时有几个关键点需要特别注意这些是从项目设计和我们实践经验中总结出的干货。5.1 确保真正的“隔离”坑最容易犯的错误是“伪隔离”。比如在代码中不小心让后一个LLM调用的提示词里包含了前一个调用的输出或者使用了全局变量导致信息泄露。解法像Amogus一样使用Promise.allSettled或Promise.all发起完全并行的请求。确保每个请求的提示词模板是独立的所有输入数据在调用前就已准备就绪。将每个议员的上下文、问题框架、原始计划作为独立的变量传入避免任何串行依赖。5.2 结构化输出是生命线坑依赖LLM生成自由格式的文本来进行后续解析是一场噩梦。格式的轻微不一致就会导致解析失败整个流程崩溃。解法不惜一切代价使用结构化输出。无论是通过Claude的JSON模式、OpenAI的函数调用工具调用还是Llama的grammar必须强制模型返回一个格式预定义的JSON对象。Amogus中每个议员的输出都严格定义了{critique: string[], revisedPlan: string[], vote: ‘approve’ | ‘reject’}这样的结构。这大大提升了系统的可靠性。5.3 评估框架的设计比角色名称更重要心得不要满足于给AI起个“魔鬼代言人”或“乐观派”的名字。这几乎没用。你必须设计出具体、可操作、互斥的问题列表。RAZOR的“哪里可以推迟”和GHOST的“什么会崩溃”就是绝佳的例子。好的问题才能引导出不同维度的思考。5.4 控制成本与延迟注意一次完整的council_plan调用涉及至少1次侦察搜索 1次原始计划生成 4次第一轮调用 (可能)4次第二轮调用 1次合成。这可能会消耗大量token并增加响应时间。优化建议设置超时和回退对每个LLM调用设置严格的超时限制并使用Promise.allSettled确保单个成员失败不会导致整个流程失败。缓存侦察结果对于常见或相似的任务可以缓存侦察阶段的结果避免重复搜索。提供“快速模式”选项在不需要极高可靠性的场景可以提供跳过第二轮辩论或减少议员数量的选项。5.5 可视化是“可观测性”的体现心得Amogus的Among Us沙盘不仅是噱头。对于这种多步骤、异步的复杂系统可视化是至关重要的调试和信任构建工具。它能让你直观地看到流程进行到哪一步、每个AI“在想什么”。如果你构建类似的系统即使不做游戏化也强烈建议提供一个能实时显示状态和中间结果的简单界面。这比查看日志文件直观得多。6. 常见问题与排查实录在实际运行或借鉴开发时你可能会遇到以下问题Q1: 调用council_plan后Cursor没反应也没弹出浏览器。排查步骤检查.cursor/mcp.json配置文件中的路径是否正确指向了mcp-server目录下的编译输出通常是dist/index.js或源码src/index.ts如果配置了直接运行ts-node。在终端手动进入项目目录运行npm start或node dist/index.js查看服务器是否正常启动有无报错如API密钥缺失、端口占用。查看Cursor的“MCP Server”日志通常可以在设置或开发者工具中找到看是否有连接错误。Q2: 议会辩论结果看起来还是很趋同四个议员说的都差不多。原因与解决评估框架不够有力检查你为议员设计的“强制评估问题”是否足够具体和差异化。尝试让问题更尖锐、更聚焦于不同阶段如RAZOR只关心“本周”GHOST只关心“明年”。提示词泄露再次确认隔离性。确保在构造每个议员的提示词时没有意外混入其他角色的信息。模型温度尝试适当提高LLM调用的“temperature”参数例如从0.2调到0.7增加输出的随机性。但要注意太高会导致输出不稳定。Q3: WebSocket连接失败沙盘不更新。排查打开浏览器开发者工具查看Console和Network标签页确认WebSocket连接是否成功建立状态码101。确保服务端HTTP服务器成功启动并且沙盘前端连接的是正确的WS地址通常是ws://localhost:[端口]/ws。检查服务端是否有CORS问题虽然项目设计为本地托管通常不会有此问题。Q4: 运行一段时间后API调用频繁失败或超时。可能原因API限额检查你的Anthropic API套餐的每分钟/每天请求限制。一次议会辩论消耗多次调用频繁使用可能触发限流。网络问题确保网络稳定。可以考虑为LLM调用添加重试逻辑例如指数退避重试2-3次。服务端资源如果并发请求太多Node.js进程可能占用较高内存。确保你的运行环境资源充足。这个项目最吸引我的地方在于它用一种优雅且可复用的方式解决了一个AI应用中的普遍痛点——单一代理决策的盲目自信。它没有试图打造一个全能AGI而是选择做一个专注的“决策增强器”。通过MCP协议它可以像乐高积木一样嵌入到现有的AI工作流中这种设计思路非常值得借鉴。在实际尝试将其思想应用到自己的项目中时最大的收获是对抗AI的趋同性需要的是制度设计而不仅仅是角色扮演。