models-consensus

模型共识

直接调用时，请根据选定的议事范围使用 shared/references/model-preview.md。明确指定三席时，选择三个盲评开场角色。预览还会显示所有已批准的组织者、评审者和综合分析角色及其注册席位。精简投票会显示两条条件评审路径。不要将其扩展为与无关任务类型对应的路由表。嵌套调用会沿用父调用选定的快照，不会再次提示，也不会调用未列出的工作者。

模型 ID、推理力度支持情况和任务默认值仅以 shared/model-routing.json 为准。在预览或审批前，先解析相关路由；在分派、重试和恢复期间，保留完全一致的已保存路由。

为想听取多个模型意见的用户生成决策报告。报告的下一位使用者是用户。完成标准是：报告列出建议、异议、证据局限、一个后续步骤、已配置和已观察到的席位，以及回执的局限。

这是一个由用户控制的只读工作流。只有当用户认为独立意见值得投入相应的时间和成本时，召开议事会才有必要。

启动与审批

仅在用户明确调用 models-consensus 或明确要求获取更多模型意见后运行。其他技能可以将此工作流建议为手动后续步骤，但不得调用它。

分派任何模型前：

1. 默认选择 poll；方向存在争议时选择 debate；用户希望从一个选定模型获取五种角度时选择 personas。未设置 poll_profile 的投票采用旧版 standard 配置。只有在问题风险较低时，才显式选择 lean。
2. 阅读 references/role-routing.md、shared/references/model-roster.md、shared/references/task-shaped-model-routing.md 和 shared/references/host-model-execution.md。先检查原生宿主路由，再检查外部运行器。如果存在 .rar-skills/config.local.yaml，仅在形成此预览时，按 shared/references/local-config.md 的定义读取其中具有参考性质的 profile 和 seats。根据名册和选定的执行路径验证每个值，优先遵循用户的直接指示，并在审批后绝不重新读取该文件。
3. 显示下方的审批预览，并询问：“批准此议事计划，还是要指定更改？”
4. 等待明确批准。沉默、超时、先前的一般性批准、auto 请求或其他技能的指示均不构成批准。

预览必须显示所有计划调用和条件调用：

字段	必需内容
问题和模式	中立的问题，以及 poll、debate 或 personas
Poll 配置	对于新的 poll，填写 standard 或 lean、risk_flags 和不可变的 poll_policy 快照。旧版 standard 计划可以省略这些字段。
席位	每个获批角色的注册信息：席位 ID、请求的模型标签、提供方、回执和执行路径。除三个开场席位外，还可以有一个仅供评审的席位。
角色	组织者、每位评审和综合者或主席，以及各自的席位、请求的模型标签、连续性密钥、依赖项和条件状态
条件评审	对于 lean poll，填写两条确切的评审路由、工作量、工具策略、回执要求、预算，以及可能要求启用它们的组织者证据条件
工作量	每次模型调用的确切配置工作量或由运行时控制的工作量
主机和会话	已检查的主机或运行器、每个角色的会话策略，以及角色能否通过其记录的 ID 恢复
服务回执	对每个席位标明 required 或 explicitly allowed unverified，并注明状态、来源和观测到的模型
预算	poll_budget 和相匹配的审批预算：基础调用次数、条件调用次数、验证重试上限、最大调用次数、建议回复上限，以及任何已报告的用量或耗时限制。Lean 必须包含 poll_budget。
工具	共享的只读工具配置。Codex 运行器席位需要在执行条目中设置 repo_read_only、tool_evidence: configured 和 allowed_tools: []，并注明为“Codex：已配置只读隔离，启动工具不可观测”；参见 references/runner-invocations.md
证据	哪些原生或运行器检查已通过，以及服务模型回执仍待确认

采用席位保真原则：获批席位必须完全符合所请求的模型标签、回执要求、执行路径、工作量和角色连续性策略。每次运行器调用都使用 --disable-fallback；原生路由没有运行器回退。如果预览后所选席位、模型标签、回执要求、主机、执行路径、工作量、角色或会话策略发生变化，请停止并展示修订后的预览。待确认回执变为所批准模型的已验证回执，属于新证据，无需重新审批。观测到的模型不匹配或未满足必需回执时，必须阻止该路由；绝不能为了继续而降低回执要求。未经新审批，不得替换、降级、增加席位、切换模式或降为 personas。

明确的 council 审批涵盖所有列出的角色，包括之后可能变为 conditional-not-needed 的 lean 评审。条件状态控制后续调度，但不代表批准未列出的路由或替代方案。

解析席位配置后，使用以下预览格式：

Council plan: awaiting approval
Mode: <mode>
Poll profile: <standard | lean>; risk flags: <none | configured flags>
Poll policy: <low confidence threshold and full required flags from the central snapshot>
Opening: <seat> / <requested model> / <receipt status and source> / <host and execution path> / <effort or runtime-controlled> / <continuity key>
Organizer: <seat> / <requested model> / <host and execution path> / <effort or runtime-controlled> / <continuity key>
Judges: <seat> / <requested model> / <host and execution path> / <effort or runtime-controlled> / <continuity key> / <required or material conflict or gap, low confidence, or high risk>; <seat> / <requested model> / <host and execution path> / <effort or runtime-controlled> / <continuity key> / <required or material conflict or gap, low confidence, or high risk>
Synthesis or chairman: <seat> / <requested model> / <host and execution path> / <effort or runtime-controlled> / <continuity key>
Budget: <base> base, <conditional> conditional, <retry ceiling> retries, <hard maximum> maximum calls
Tools: <read-only profile>
Evidence: <native or runner checks>; serving-model receipts pending
Sessions: <persistent per-role policy and resume limit>
Serving receipt: required | explicitly allowed unverified

Approve this council plan, or specify changes.

Council 模式

模式	适用场景	协议
poll	用户需要独立回答和综合后的建议	references/poll-protocol.md
debate	用户希望对相互竞争的方向进行压力测试	references/stance-rotation-schedule.md
personas	用户希望通过一个选定模型获得五种思考视角	references/personas.md

所有模式对目标项目均为只读。它们只能在 .ai-workflow/consensus/ 下写入本地状态、响应产物和最终报告。它们不会编辑产品文件、运行可写入的工具或启动实现工作。

预检

使用 references/operations.md 查看审批记录、制品状态、响应验证和恢复规则。仅在获批后使用 references/runner-invocations.md。仅当获批的预览选择 cmux 时，才使用 references/cmux-transport.md。

在预览前探测所选执行路径。成功的原生能力检查或运行器探测只能证明某条路径可能启动。原生或由提供商观察到的服务模型回执才能证明服务模型。由包装器回显的 effective_model 标签不能证明。没有经过验证的回执的响应可以为报告提供参考，但不能提高多样性置信度。

对于 poll 和 debate，要求有三个经批准的盲测开场角色，且其请求的模型标签各不相同。席位注册表可以包含仅负责组织或评审的席位。无需三个不同的提供商。只有在三个盲测开场回执验证了不同的观察到的模型时，才能计入开场多样性。已注册的条件评审员不会增加开场多样性。经验证的提供商多样性是辅助证据，而不是席位数量规则。如果预检无法支持某条路径，请报告阻碍因素并提供修订后的三席位方案。personas 是单模型的独立模式；其预览必须注明顾问、审查员和主席调用所使用的模型。

对于投票，请在审批前确定核心策略。security、money、migrations、public_contracts、data_loss、deep_review 和 high_risk 均选择 standard。如果明确请求精简模式，同时带有上述任一风险标记，则必须在审批前拒绝。请改为展示修订后的标准预览。精简模式仅使用原生或运行器的 per_call 传输。cmux 无法承载组织者证据门控，因此会在指纹生成、采纳或中继前拒绝精简模式。

即使两条精简模式评审路径的调用是有条件的，也要对其进行预检。路径不可用时会阻止预览，因为用户必须在组织者门控条件明确之前批准确切路径。如果获批的评审路径变得不可用，而组织者要求使用该路径，则保留该失败，不要在综合时绕过评审员。

执行

获得批准后，按照 references/operations.md 的定义，从精确预览初始化通用 council CLI，并在分派前预留每次尝试。为每项任务和角色创建一个独立、持久的上下文。向每个开场角色提供相同的中立简报、只读来源、工具配置和输出预算。开场角色只能恢复自己的上下文，以重试架构校验或修复经批准的缺漏。组织者、每位评委、综合者、顾问、审阅者和主席各自拥有单独的上下文。评委开始时不带有开场角色或组织者的历史记录，彼此也不共享上下文。

在标准 poll 中，依次运行盲审开场、组织者分析、至多一轮缺漏修复、两位评委，然后进行综合。这样可保留现有的七次基础调用、三次有条件的缺漏修复、每个计划步骤一次校验重试，以及最多二十次调用。

在精简 poll 中，运行三次盲审开场和组织者，然后运行计划中的三次可选缺漏修复。组织者的响应除常规分析外，还包含 confidence 和 high_risk 字段。如果经过校验的组织者响应满足以下任一条件，则在综合前运行两位评委：material_gaps: true、存在任何实质性矛盾、置信度低于经批准的策略阈值，或 high_risk: true。两位评委仍相互隔离，并使用各自精确获批的路由。即使已运行缺漏修复，综合也必须等待两位评委的结果。

如果这些评委触发条件均不适用，则将每位精简 poll 评委记录为 conditional-not-needed。此记录是证据，并非执行结果或缺失的覆盖。它必须引用经过校验的组织者响应工件及其原始回执摘要。运行时会在综合前验证该证据。调用方给出的理由不能跳过评委。标准精简计划包含五次基础调用、五次有条件调用、每个计划步骤一次校验重试，以及最多二十次调用。显式批准可以设定更低的重试上限和相应的最大调用次数。

在 debate 中，按获批的轮数运行，并使用匿名化摘要和固定上限。在 personas 中，运行五种视角；如果预览中包含匿名化同行评审，则运行该评审；随后由主席处理。

如果获批的调用或会话恢复失败，请在状态中保留该失败及其记录的上下文 ID，并报告出来。再次发送前，先核对待处理调用。不要改用其他模型，也不要以未经批准的新上下文替代。如果达到法定人数所需的参与者出现重大损失，则使用已收集的证据结束运行，并明确提供修订计划选项。

输出

返回或写入 .ai-workflow/consensus/{session_id}.md，内容包括：

1. 问题、模式、获批预览和实际运行记录。
2. 建议和一个后续步骤。
3. 共识、异议、盲点和证据缺口。
4. 答案置信度和多样性置信度，分别列出。
5. 席位回执：请求、配置、有效和观察到的模型字段；回执状态和来源；提供方、主机、执行路径、工作量控制、角色上下文状态以及任何失败。
6. 对于精简 poll，列出配置文件、策略快照、风险标记、触发判定，以及每项 conditional-not-needed 证据引用。

对于采纳决策，请使用一种通俗易懂的等级：采纳、试行、暂缓、拒绝，或与我们无关。如果证据不足，请返回“暂缓：证据不足”，并列出需要检查的内容。

委员会绝不实施其建议。用户之后可以选择单独的实施工作流。