Paseo Committee Skill：以双高推理 Agent 委员会做根因分析与复杂规划

Paseo Committee Skill以双高推理 Agent 委员会做根因分析与复杂规划【免费下载链接】paseoOrchestrate multiple coding agents from desktop and mobile项目地址: https://gitcode.com/gh_mirrors/pa/paseo导读当主 Agent 陷入死循环、反复兜圈子、视野收窄tunnel vision或面对难以拆解的规划难题时单线程的思考往往无法自我突破。Paseo 的paseo-committee技能提供了一种委员会式解法同时拉起两个来自不同配置画像profile、思维风格互补的高推理 Agent在全新上下文中并行分析同一问题、互相质证分歧最终收敛出一份共识方案。读完本文你将掌握该技能的使用时机、委员会成员的挑选规则、两条硬性纪律以及完整的五步工作流并了解其背后的 Agent Profile 数据模型与 MCP 工具实现。技能定位何时应该组建委员会paseo-committee是 Paseo 内置的编排技能orchestration skill其 frontmatter 中的 description 精确划定了适用边界Form a committee of two high-reasoning agents to step back, do root cause analysis, and produce a plan. Use when stuck, looping, tunnel-visioning, or facing a hard planning problem.典型触发场景包括卡住stuck当前任务推进不下去主 Agent 已尝试多种方案但都无法闭合死循环looping反复在相同的推理路径上打转输出没有实质进展视野收窄tunnel-visioning过度聚焦局部细节丢失了问题全局硬规划问题hard planning problem需要多步骤、多约束权衡的复杂拆解。与同族技能paseo-advisorskills/paseo-advisor/SKILL.md单 Agent 提供第二意见不驱动工作不同委员会是双 Agent 并行两份独立的高推理上下文互不污染各自给出判断再由主 Agent 作为协调者推动它们互相质证、收敛。委员会的分歧不是噪音而是设计目标——对比本身contrast就是委员会存在的意义。该技能以user-invocable: true暴露用户可直接通过类似/paseo-committee 补充上下文的形式调用$ARGUMENTS会被注入到技能正文的 Users additional context 中。前置条件先读 paseo 技能再读 profiles技能的第一条铁律是顺序先读paseo技能skills/paseo/SKILL.md它定义了本次操作所需的全部 MCP 工具语义list_profiles、create_agent、send_agent_prompt、provider 发现工具等在选定委员会成员之前必须调用list_profiles并逐个阅读每个 profile 的notes在读完已配置 profiles 及其 notes 之前严禁创建委员会 Agent。list_profiles是 Agent 侧的 MCP 工具返回由人类配置的命名启动包named launch bundle。在 packages/server/src/server/agent/mcp-server.test.ts 的测试中可以看到其典型返回结构与notes的写法{ profiles: [ { name: UI work, provider: claude, model: claude-test-model, modeId: bypassPermissions, thinkingOptionId: high, featureValues: { fast_mode: true }, notes: Use for UI work: components, layout, design tokens. Not for backend. } ] }notes是list_profiles专门暴露给编排 Agent 的自由文本见 agent-profile.ts 的注释 Free text, surfaced to orchestrating agents by thelist_profilesMCP tool它决定了主 Agent 能否为当前问题匹配合适的成员——这也是不读 notes 不选人这条前置纪律的根本原因。同一文件中的测试还验证了两种边界情形未配置任何 profiles 时返回空数组{ profiles: [] }未提供 daemon 配置存储时同样返回空数组mcp-server.test.ts。委员会构成两个风格相反的高推理成员委员会固定为两名成员且刻意追求差异而非相似成员选择标准成员 A其notes匹配规划planning、研究research或根因分析root-cause analysis的 profile成员 B来自另一 provider 家族、风格形成对比的高推理 profile选人规则按优先级排序用户点名若用户在$ARGUMENTS中直接指定了 profiles则使用用户指定的notes 匹配否则挑选 notes 与当前工作最契合的 profile家族对比尽量让两位成员来自不同的 provider 家族例如 Anthropic 系与 OpenAI 系保证second opinion 真正新鲜降级兜底如果可用配置不足两个合适的 profiles缺失的成员改用 Paseo 的provider discovery 兜底list_providers/list_models/inspect_provider并且必须明确告知用户发生了降级用户覆盖只有当用户明确要求更换成员时才覆盖以上默认选择。将 profile 物化materialize到 create_agent需要注意create_agent工具没有profile参数profile 只是启动配置launch configuration不能直接引用。选中的 profile 必须物化为create_agent的实际字段映射规则由paseo技能明确规定AgentProfile 字段映射目标providermodel拼接为create_agent.provider的provider/model值如claude/opus、codex/gpt-5.4modeIdsettings.modeIdthinkingOptionIdsettings.thinkingOptionIdfeatureValuessettings.features不存在的字段直接省略选中某个 profile 后不得在后续长期记忆它或臆测其漂移——profile 只是一次性的启动配置。packages/protocol/src/agent-profile.ts 的 schema 证实了这一点AgentProfileSchema包含id、name、icon、color、provider必填、model、modeId、thinkingOptionId、featureValues、notes且字段名刻意与AgentSessionConfig对齐applying a profile is a copy rather than a translation table应用 profile 是拷贝而非翻译映射。该文件还解释了为何 profile刻意不携带 systemPromptsystemPrompt仅创建时可写若 profile 携带它应用到运行中的 Agent 时会静默失效。两条硬性规则Hard rules规则一只分析不修改No edits委员会是分析性机构不产生任何代码变更。给每位成员的所有 prompt 必须以 no-edits 后缀结尾This is analysis only. Do NOT edit, create, or delete any files. Do NOT write code.这条后缀同时出现在paseo-committee与paseo-advisor两个技能中是整个外部视角评审技能族共用的安全边界委员会只负责想清楚落地执行仍由主 Agent 基于共识方案进行。规则二信任完成通知绝不轮询Trust the finish notification高推理模型单次推理可能长达15–30 分钟。委员会工作期间不要轮询polllist_agents或get_agent_status去查进度不要催促hurry-ups或中途打断interrupt主 Agent 可以转入空闲Paseo 会在成员完成、出错或需要权限时主动推送通知。这与paseo技能 Waiting 一节的原则一致Agent 运行 10–30 分钟是常态应优先采用异步工作流。Agent 作用域内的create_agent默认notifyOnFinish为truepaseo-tools.ts 中notifyOnFinish Boolean(callerAgentId)的默认行为也在测试中验证委员会成员作为被编排的子 Agent完成通知会自动送达主 Agent。五步工作流委员会的标准执行流程是一个清晰的五步循环第 1 步撰写问题级 promptproblem-level prompt不要把委员会成员的 prompt 写成帮我看看这段代码而要写到问题层级陈述问题本身、已知约束、已尝试过且失败的方案、期望的输出形态根因分析结论 行动计划。成员上下文是全新的fresh context因此 prompt 必须自包含self-contained就像给零上下文的同事做简报一样。第 2 步并行创建两位成员通过 Paseo 的create_agent并行创建两个 Agent要求标题统一使用[Committee] task前缀便于在 Agent 列表中识别委员会会话同一个 prompt原样发给两位成员保证可比性差异只来自推理风格依据上文规则分别物化两个不同风格的 profile。create_agent的核心参数见 paseo-tools.ts 的 schema 校验provider必须形如provider/modelinitialPrompt为必填且不能为空字符串{ title: [Committee] Root cause: intermittent relay disconnect, provider: claude/opus, initialPrompt: 问题级 prompt以 no-edits 后缀结尾, notifyOnFinish: true }若不指定workspaceId子 Agent 默认进入主 Agent 当前工作区如需隔离可传入create_workspace返回的 workspace。第 3 步等待双方响应不做任何轮询或催促见硬性规则二等待两位成员各自返回分析结论。第 4 步让分歧互相质证这是委员会机制的核心价值所在。当两位成员的结论不一致时把双方的论证原样传递给对方把成员 A 的论点与论据发给成员 B 请其回应反之亦然。目的是让分歧在论证层面被消解或缩小而不是由主 Agent 单方面和稀泥。第 5 步持续迭代直至收敛重复第 4 步直到双方收敛converge为一份共识响应。如果始终无法收敛保留双方观点中最有力的部分在最终交付中如实呈现分歧。结果汇报共识 分歧过程工作流结束后主 Agent 需要向用户交付两部分内容共识方案委员会收敛后的结论作为后续行动的输入分歧摘要两位成员在哪里、为何产生分歧以及分歧是如何被解决或保留的——这份分歧记录本身就是根因分析质量的重要证据它说明结论经过了真正独立的双视角检验而非单一 Agent 的自说自话。技能的分发与更新机制paseo-committee属于仓库skills/目录下的内置编排技能包与其他技能paseo、paseo-advisor、paseo-handoff、paseo-help、paseo-plugin并列。服务端通过 orchestration-skills 的同步机制将其安装到各 Agent 的技能目录中packages/server/src/server/orchestration-skills/internal/sync.test.ts 验证了内置技能含references/子目录在磁盘不存在时会被安装到 agents / Claude / Codex 各自的技能目录且后续更新会以新内容覆盖旧版本。这意味着委员会技能作为 Agent 可加载的 Skill 工具随 Paseo 版本分发主 Agent 在执行时通过 Skill 工具加载即可。小结paseo-committee把多智能体辩论这一高价值协作模式压缩成一个可重复、有纪律的操作规程先读 profiles 选对人 → 用同一份问题级 prompt 并行启动两名高推理成员 → 只分析不改代码 → 静默等待完成通知 → 互传分歧直到收敛 → 汇报共识与分歧过程。它最适合主 Agent 自身陷入僵局、需要真正独立的外部视角做根因分析与规划的场景是paseo-advisor单 Agent 第二意见的加强形态。使用时请始终遵守两条硬性规则每个 prompt 都带 no-edits 后缀以及绝不轮询、信任完成通知。【免费下载链接】paseoOrchestrate multiple coding agents from desktop and mobile项目地址: https://gitcode.com/gh_mirrors/pa/paseo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考