尧图网站建设 
使用 goose 接入 Council of Mine搭建 9 位性格各异的 LLM「议员」来帮你辩论决策【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose在 goose 这个可扩展 AI Agent 中你可以像安装普通工具一样接入任意 MCP Server让 Agent 在真实任务里调用它的全部能力。本文将以官方扩展教程 Council of Mine MCP 为主线完整演示如何把Council of Mine——一个内置 9 位拥有不同人格的 LLM「议员」、能够围绕议题展开辩论、互相投票并产出综合结论的 MCP Server——注册为 goose 扩展。读完本文你将掌握 Desktop 一键安装与 CLI 手动配置两种接入方式、扩展在 goose 配置文件中的底层存储结构type: stdiocmd/args/timeout并理解一场「开场辩论 → 投票 → 结果汇总」多智能体决策流程的真实输出形态。Council of Mine 是什么Council of Mine 是一个通过 AI 驱动的深思熟虑deliberation来辅助决策的 MCP 服务器。它模拟了一场「委员会议事」9 位 LLM 议员各自拥有截然不同的思维倾向与表达风格围绕你提出的任意议题每位议员先发表独立观点随后议员们阅读彼此观点并投票每人附上投票理由系统统计票数、宣布获胜意见并汇总成一份统一的综合结论synthesis。它非常适合帮你做两难选择无论是产品路线取舍、技术方案选型还是像教程示例中「AI 助手该不该拥有个性」这样的理念之争都能从多角度获得有依据的参考。因为它是标准 MCP Servergoose 通过 ExtensionConfig 以Stdiotype: stdio本地命令的方式拉起它Agent 即可按需调用其工具。前置条件在安装之前确认你的系统满足两点goose 已安装Desktop 或 CLI 均可本教程两种界面都覆盖已安装 uv。因为该扩展通过uvx运行——uvx是 uv 提供的工具运行器可以从 git 仓库把 Python 包临时拉取到隔离环境并直接执行其入口模块无需手动建虚拟环境、也无需全局安装用完即走。接入方式一goose Desktop 一键安装在 goose Desktop 中接入最简单直接点击下面的安装器链接goose 会解析其中的扩展描述并自动完成注册。goose://extension?cmduvxarg--fromarggit%2Bhttps%3A%2F%2Fgithub.com%2Fblock%2Fmcp-council-of-mineargmcp_council_of_mineidcouncil-of-minenameCouncil%20of%20MinedescriptionLLM%20Debate上述goose://extension深链接实际编码了如下注册参数对应 Desktop 安装器组件 GooseDesktopInstaller.tsx 中的buildGooseUrl逻辑参数值含义type未传默认stdio本地命令型扩展cmduvx启动命令arg--from、githttps://github.com/block/mcp-council-of-mine、mcp_council_of_mine依次传入的命令参数idcouncil-of-mine扩展唯一标识nameCouncil of Mine扩展显示名descriptionLLM Debate扩展描述操作步骤点击该安装器链接goose Desktop 弹出确认框点击Yes确认安装此扩展无需 API Key 或环境变量直接确认即可点击Add Extension完成添加点击窗口左上角的侧边栏按钮进入聊天界面即可开始使用。接入方式二goose CLI先直接验证运行命令Council of Mine 的启动命令为uvx --from githttps://github.com/block/mcp-council-of-mine mcp_council_of_mine拆开看--from githttps://github.com/block/mcp-council-of-mine指定包来源是 git 仓库mcp-council-of-minemcp_council_of_mine指定要执行的包入口模块即该 MCP Server 的实现。你可以先在终端单独跑一次这条命令做冒烟测试——如果命令能正常驻留并输出 MCP 握手信息说明网络与运行环境没问题。通过 goose configure 交互式添加官方推荐的 CLI 流程是用goose configure命令按向导逐步注册每一步的界面文本详见文档站组件 CLIExtensionInstructions.tsx运行goose configure选择Add Extension在「What type of extension would you like to add?」中选择Command-line Extension本地命令型即 stdio输入扩展名称例如Council of Mine输入要运行的命令uvx --from githttps://github.com/block/mcp-council-of-mine mcp_council_of_mine设置超时时间向导默认给出300 秒直接回车确认。这与 goose 内部常量 DEFAULT_EXTENSION_TIMEOUT: u64 300 一致足够uvx完成首次拉取与启动输入描述例如LLM debate询问是否添加环境变量时选择No本扩展无需任何密钥看到Added Council of Mine extension即注册成功。底层存储扩展是如何写进配置的无论走 Desktop 还是 CLI扩展最终都会被持久化到 goose 本机配置文件中的extensions键下。从 extensions.rs 的实现看每条记录对应一个ExtensionEntry外层是enabled开关内层#[serde(flatten)]则是按type标签反序列化的ExtensionConfig。Council of Mine 属于Stdio变体落地后大致形如extensions: council-of-mine: enabled: true type: stdio name: Council of Mine description: LLM debate cmd: uvx args: - --from - githttps://github.com/block/mcp-council-of-mine - mcp_council_of_mine timeout: 300对照 ExtensionConfig::Stdio 的定义这些字段的语义为type: stdio通过标准输入输出与本地子进程通信该枚举还支持builtin、platform、streamable_http等类型cmd/args要执行的程序与参数列表name/description用于在会话中识别该扩展并向模型展示其用途timeout可选单次工具调用等待上限秒CLI 向导默认填 300不填则使用上文默认值envs可选兼容env别名环境变量映射此扩展用不到cwd可选子进程工作目录。两个值得一提的底层细节key 的归一化配置解析时会调用 name_to_key把名称中的空白剔除、非法字符替换为_并转小写再与映射 key 匹配因此「名称」与「key」的查找都做了容错解析容错parse_extensions_map 会跳过格式错误的条目并打日志但不会影响同配置中其他合法扩展的加载。9 位议员谁在为你辩论Council of Mine 的核心资产是这 9 位性格化议员每一票背后都是一种独立的思维模型议员头像思维倾向The Pragmatist 实用主义者务实、以结果为导向The Visionary 远见者关注宏大蓝图The Systems Thinker 系统思考者洞察相互关联与级联效应The Optimist 乐观主义者积极、关注机会The Devils Advocate 魔鬼代言人挑战一切假设The Mediator 调解者寻求共识The User Advocate 用户代言人捍卫可访问性与可用性The Traditionalist 传统主义者重视被验证过的方法The Analyst 数据分析师数据驱动、讲逻辑正因为人格差异被刻意放大同一议题才会碰撞出互相对抗、互相补充的观点最终的综合结论才更有参考价值。使用示例让议员们争论「AI 该不该有性格」扩展装好后你只需在 goose 里用自然语言发起请求Agent 会自动编排「开场辩论 → 投票 → 出结果」三步工具调用。官方示例的提示词为Use the council to debate on should AI assistants have distinct personalities, or should they remain neutral and personality-free?也就是说你可以直接说用 Council 辩论一下AI 助手应该拥有鲜明的个性还是保持中立、不带任何性格流程一9 位议员各抒己见goose 首先调用辩论工具输出带有唯一Debate ID示例中为20251203_230105的讨论记录。9 位议员从各自立场给出了代表性观点例如 The Pragmatist主张折中——「AI 助手该有些个性但个性必须服务于用户。完全中性、机械式的助手让人难以交互而夸张的『角色』又可能变成噱头最佳点是既专业又带温度像一位得力的同事而非舞台化的演员。」 The Visionary力挺个性——「中立的工具只是过眼云烟个性才能建立有意义的连接解锁人与 AI 之间更深层的协作。」 The Systems Thinker跳出二元对立——「『中立』本身就是一种设计选择它向外传递权威与客观的信号反而可能导致用户过度信任输出。真正的问题不是要个性还是中立而是我们想优化什么样的系统动力学。」 The Devils Advocate反向质询——「如果『绝对中立』根本不存在呢假装没有个性的 AI比坦诚展示个性的 AI 更危险——它把必然存在的倾向藏在虚假的客观性之后。」 The Mediator提出第三条路——「为什么不采用自适应个性提供稳定可信的基线同时允许根据用户偏好调节交流风格。双方真正的共识是赋权用户。」 The Traditionalist守护中立价值——「从百科全书到计算器历史上最耐用的工具恰恰因为不带编辑部式的主观渲染。若没坏何必修」 The Analyst引用证据——「数据强烈支持带个性的 AI一致的个性特征能提升参与度、延长会话时长、提高任务完成率它本质上是帮助用户预测系统行为、校准预期的认知捷径。」辩论结束时会明确提示All 9 council members have shared their opinions下一步是调用get_results()获取投票与最终综合结论。流程二议员互相投票随后议员对彼此的观点投票每个投票都携带结构化 JSON含status、total_votes、individual_votes每位投票者的voter、voted_for、reasoning以及next_step。节选关键结构{ status: voting_complete, total_votes: 9, individual_votes: [ { voter: The Pragmatist, voted_for: The Mediator, reasoning: The Mediators position is the most practically implementable...adaptive personality gives users control... }, { voter: The Visionary, voted_for: The Devils Advocate, reasoning: ...exposes that neutrality is itself a design fiction... } ], next_step: Call get_results() to see the winning opinion and synthesis }有意思的是议员投票时常会「英雄惜英雄」The Devils Advocate 特意投给了与自己立场相反、但最需要被捍卫的 The Traditionalist以保证少数派声音被认真审视。流程三出结果与综合结论goose 再调用get_results()得到完整结果每位议员收获的票数、获胜观点、汇总后的综合结论Council Synthesis以及投票统计。本场辩论的投票结果议员得票 The Mediator3胜出 The Systems Thinker2 The Pragmatist / The Visionary / The Devils Advocate / The Traditionalist各 1 The Optimist / The User Advocate / The Analyst各 0 胜者The Mediator 提出的自适应个性方案——AI 能在亲和与中立之间按用户偏好灵活切换把控制权交还给用户。 综合结论原文要点AI assistants should embrace thoughtfully designed,transparentpersonalities with user-adjustable parameters, recognizing that the goal isnt personality versus neutrality, but rather empowering users with appropriate feedback mechanisms and control. 统计总投票数 9获胜者数量 1。整场辩论同时被保存到历史记录history中方便后续回看。可以看到这份结论并不仅仅是「多数派赢了」——它把 The Systems Thinker 关于「中立也是一种设计」的洞见、The Traditionalist 对可靠性的关切、The User Advocate 对包容性的强调都吸收进了统一表述这正是多智能体投票 综合synthesis环节的价值所在。验证扩展是否工作在 goose 会话中你可以用一句话确认接入是否成功若 Agent 能正确调用辩论并输出️ COUNCIL OF MINE DEBATE风格的结构化文本说明 stdio 进程通信正常若出现超时可回到配置中把该扩展的timeout调大——首次uvx需要从 git 拉取依赖网络较慢时 300 秒可能不够若命令本身报错先单独在终端运行uvx --from githttps://github.com/block/mcp-council-of-mine mcp_council_of_mine排除 uv 版本或网络问题后再回到 goose 里重试。小结Council of Mine 把「群体智慧」做成了可被 Agent 编排的 MCP 能力注册一个type: stdio的本地命令扩展即可。接入 goose 后它就不再是孤立的 Python 工具而是能嵌入你任意工作流的一个「多视角决策顾问」——无论你在做技术选型、产品判断还是方案权衡都能让 9 位虚拟议员帮你把正反两面与中间地带摊开再投票出一个带论证链路的综合结论。关于扩展配置底层机制如extensions映射的解析与容错逻辑可继续阅读 crates/goose/src/config/extensions.rs若想参考同目录下其他 MCP 扩展的接入写法可浏览 documentation/docs/mcp 下的系列文档。【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 goose 接入 Council of Mine：搭建 9 位性格各异的 LLM「议员」来帮你辩论决策
使用 goose 接入 Council of Mine搭建 9 位性格各异的 LLM「议员」来帮你辩论决策【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose在 goose 这个可扩展 AI Agent 中你可以像安装普通工具一样接入任意 MCP Server让 Agent 在真实任务里调用它的全部能力。本文将以官方扩展教程 Council of Mine MCP 为主线完整演示如何把Council of Mine——一个内置 9 位拥有不同人格的 LLM「议员」、能够围绕议题展开辩论、互相投票并产出综合结论的 MCP Server——注册为 goose 扩展。读完本文你将掌握 Desktop 一键安装与 CLI 手动配置两种接入方式、扩展在 goose 配置文件中的底层存储结构type: stdiocmd/args/timeout并理解一场「开场辩论 → 投票 → 结果汇总」多智能体决策流程的真实输出形态。Council of Mine 是什么Council of Mine 是一个通过 AI 驱动的深思熟虑deliberation来辅助决策的 MCP 服务器。它模拟了一场「委员会议事」9 位 LLM 议员各自拥有截然不同的思维倾向与表达风格围绕你提出的任意议题每位议员先发表独立观点随后议员们阅读彼此观点并投票每人附上投票理由系统统计票数、宣布获胜意见并汇总成一份统一的综合结论synthesis。它非常适合帮你做两难选择无论是产品路线取舍、技术方案选型还是像教程示例中「AI 助手该不该拥有个性」这样的理念之争都能从多角度获得有依据的参考。因为它是标准 MCP Servergoose 通过 ExtensionConfig 以Stdiotype: stdio本地命令的方式拉起它Agent 即可按需调用其工具。前置条件在安装之前确认你的系统满足两点goose 已安装Desktop 或 CLI 均可本教程两种界面都覆盖已安装 uv。因为该扩展通过uvx运行——uvx是 uv 提供的工具运行器可以从 git 仓库把 Python 包临时拉取到隔离环境并直接执行其入口模块无需手动建虚拟环境、也无需全局安装用完即走。接入方式一goose Desktop 一键安装在 goose Desktop 中接入最简单直接点击下面的安装器链接goose 会解析其中的扩展描述并自动完成注册。goose://extension?cmduvxarg--fromarggit%2Bhttps%3A%2F%2Fgithub.com%2Fblock%2Fmcp-council-of-mineargmcp_council_of_mineidcouncil-of-minenameCouncil%20of%20MinedescriptionLLM%20Debate上述goose://extension深链接实际编码了如下注册参数对应 Desktop 安装器组件 GooseDesktopInstaller.tsx 中的buildGooseUrl逻辑参数值含义type未传默认stdio本地命令型扩展cmduvx启动命令arg--from、githttps://github.com/block/mcp-council-of-mine、mcp_council_of_mine依次传入的命令参数idcouncil-of-mine扩展唯一标识nameCouncil of Mine扩展显示名descriptionLLM Debate扩展描述操作步骤点击该安装器链接goose Desktop 弹出确认框点击Yes确认安装此扩展无需 API Key 或环境变量直接确认即可点击Add Extension完成添加点击窗口左上角的侧边栏按钮进入聊天界面即可开始使用。接入方式二goose CLI先直接验证运行命令Council of Mine 的启动命令为uvx --from githttps://github.com/block/mcp-council-of-mine mcp_council_of_mine拆开看--from githttps://github.com/block/mcp-council-of-mine指定包来源是 git 仓库mcp-council-of-minemcp_council_of_mine指定要执行的包入口模块即该 MCP Server 的实现。你可以先在终端单独跑一次这条命令做冒烟测试——如果命令能正常驻留并输出 MCP 握手信息说明网络与运行环境没问题。通过 goose configure 交互式添加官方推荐的 CLI 流程是用goose configure命令按向导逐步注册每一步的界面文本详见文档站组件 CLIExtensionInstructions.tsx运行goose configure选择Add Extension在「What type of extension would you like to add?」中选择Command-line Extension本地命令型即 stdio输入扩展名称例如Council of Mine输入要运行的命令uvx --from githttps://github.com/block/mcp-council-of-mine mcp_council_of_mine设置超时时间向导默认给出300 秒直接回车确认。这与 goose 内部常量 DEFAULT_EXTENSION_TIMEOUT: u64 300 一致足够uvx完成首次拉取与启动输入描述例如LLM debate询问是否添加环境变量时选择No本扩展无需任何密钥看到Added Council of Mine extension即注册成功。底层存储扩展是如何写进配置的无论走 Desktop 还是 CLI扩展最终都会被持久化到 goose 本机配置文件中的extensions键下。从 extensions.rs 的实现看每条记录对应一个ExtensionEntry外层是enabled开关内层#[serde(flatten)]则是按type标签反序列化的ExtensionConfig。Council of Mine 属于Stdio变体落地后大致形如extensions: council-of-mine: enabled: true type: stdio name: Council of Mine description: LLM debate cmd: uvx args: - --from - githttps://github.com/block/mcp-council-of-mine - mcp_council_of_mine timeout: 300对照 ExtensionConfig::Stdio 的定义这些字段的语义为type: stdio通过标准输入输出与本地子进程通信该枚举还支持builtin、platform、streamable_http等类型cmd/args要执行的程序与参数列表name/description用于在会话中识别该扩展并向模型展示其用途timeout可选单次工具调用等待上限秒CLI 向导默认填 300不填则使用上文默认值envs可选兼容env别名环境变量映射此扩展用不到cwd可选子进程工作目录。两个值得一提的底层细节key 的归一化配置解析时会调用 name_to_key把名称中的空白剔除、非法字符替换为_并转小写再与映射 key 匹配因此「名称」与「key」的查找都做了容错解析容错parse_extensions_map 会跳过格式错误的条目并打日志但不会影响同配置中其他合法扩展的加载。9 位议员谁在为你辩论Council of Mine 的核心资产是这 9 位性格化议员每一票背后都是一种独立的思维模型议员头像思维倾向The Pragmatist 实用主义者务实、以结果为导向The Visionary 远见者关注宏大蓝图The Systems Thinker 系统思考者洞察相互关联与级联效应The Optimist 乐观主义者积极、关注机会The Devils Advocate 魔鬼代言人挑战一切假设The Mediator 调解者寻求共识The User Advocate 用户代言人捍卫可访问性与可用性The Traditionalist 传统主义者重视被验证过的方法The Analyst 数据分析师数据驱动、讲逻辑正因为人格差异被刻意放大同一议题才会碰撞出互相对抗、互相补充的观点最终的综合结论才更有参考价值。使用示例让议员们争论「AI 该不该有性格」扩展装好后你只需在 goose 里用自然语言发起请求Agent 会自动编排「开场辩论 → 投票 → 出结果」三步工具调用。官方示例的提示词为Use the council to debate on should AI assistants have distinct personalities, or should they remain neutral and personality-free?也就是说你可以直接说用 Council 辩论一下AI 助手应该拥有鲜明的个性还是保持中立、不带任何性格流程一9 位议员各抒己见goose 首先调用辩论工具输出带有唯一Debate ID示例中为20251203_230105的讨论记录。9 位议员从各自立场给出了代表性观点例如 The Pragmatist主张折中——「AI 助手该有些个性但个性必须服务于用户。完全中性、机械式的助手让人难以交互而夸张的『角色』又可能变成噱头最佳点是既专业又带温度像一位得力的同事而非舞台化的演员。」 The Visionary力挺个性——「中立的工具只是过眼云烟个性才能建立有意义的连接解锁人与 AI 之间更深层的协作。」 The Systems Thinker跳出二元对立——「『中立』本身就是一种设计选择它向外传递权威与客观的信号反而可能导致用户过度信任输出。真正的问题不是要个性还是中立而是我们想优化什么样的系统动力学。」 The Devils Advocate反向质询——「如果『绝对中立』根本不存在呢假装没有个性的 AI比坦诚展示个性的 AI 更危险——它把必然存在的倾向藏在虚假的客观性之后。」 The Mediator提出第三条路——「为什么不采用自适应个性提供稳定可信的基线同时允许根据用户偏好调节交流风格。双方真正的共识是赋权用户。」 The Traditionalist守护中立价值——「从百科全书到计算器历史上最耐用的工具恰恰因为不带编辑部式的主观渲染。若没坏何必修」 The Analyst引用证据——「数据强烈支持带个性的 AI一致的个性特征能提升参与度、延长会话时长、提高任务完成率它本质上是帮助用户预测系统行为、校准预期的认知捷径。」辩论结束时会明确提示All 9 council members have shared their opinions下一步是调用get_results()获取投票与最终综合结论。流程二议员互相投票随后议员对彼此的观点投票每个投票都携带结构化 JSON含status、total_votes、individual_votes每位投票者的voter、voted_for、reasoning以及next_step。节选关键结构{ status: voting_complete, total_votes: 9, individual_votes: [ { voter: The Pragmatist, voted_for: The Mediator, reasoning: The Mediators position is the most practically implementable...adaptive personality gives users control... }, { voter: The Visionary, voted_for: The Devils Advocate, reasoning: ...exposes that neutrality is itself a design fiction... } ], next_step: Call get_results() to see the winning opinion and synthesis }有意思的是议员投票时常会「英雄惜英雄」The Devils Advocate 特意投给了与自己立场相反、但最需要被捍卫的 The Traditionalist以保证少数派声音被认真审视。流程三出结果与综合结论goose 再调用get_results()得到完整结果每位议员收获的票数、获胜观点、汇总后的综合结论Council Synthesis以及投票统计。本场辩论的投票结果议员得票 The Mediator3胜出 The Systems Thinker2 The Pragmatist / The Visionary / The Devils Advocate / The Traditionalist各 1 The Optimist / The User Advocate / The Analyst各 0 胜者The Mediator 提出的自适应个性方案——AI 能在亲和与中立之间按用户偏好灵活切换把控制权交还给用户。 综合结论原文要点AI assistants should embrace thoughtfully designed,transparentpersonalities with user-adjustable parameters, recognizing that the goal isnt personality versus neutrality, but rather empowering users with appropriate feedback mechanisms and control. 统计总投票数 9获胜者数量 1。整场辩论同时被保存到历史记录history中方便后续回看。可以看到这份结论并不仅仅是「多数派赢了」——它把 The Systems Thinker 关于「中立也是一种设计」的洞见、The Traditionalist 对可靠性的关切、The User Advocate 对包容性的强调都吸收进了统一表述这正是多智能体投票 综合synthesis环节的价值所在。验证扩展是否工作在 goose 会话中你可以用一句话确认接入是否成功若 Agent 能正确调用辩论并输出️ COUNCIL OF MINE DEBATE风格的结构化文本说明 stdio 进程通信正常若出现超时可回到配置中把该扩展的timeout调大——首次uvx需要从 git 拉取依赖网络较慢时 300 秒可能不够若命令本身报错先单独在终端运行uvx --from githttps://github.com/block/mcp-council-of-mine mcp_council_of_mine排除 uv 版本或网络问题后再回到 goose 里重试。小结Council of Mine 把「群体智慧」做成了可被 Agent 编排的 MCP 能力注册一个type: stdio的本地命令扩展即可。接入 goose 后它就不再是孤立的 Python 工具而是能嵌入你任意工作流的一个「多视角决策顾问」——无论你在做技术选型、产品判断还是方案权衡都能让 9 位虚拟议员帮你把正反两面与中间地带摊开再投票出一个带论证链路的综合结论。关于扩展配置底层机制如extensions映射的解析与容错逻辑可继续阅读 crates/goose/src/config/extensions.rs若想参考同目录下其他 MCP 扩展的接入写法可浏览 documentation/docs/mcp 下的系列文档。【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考