ask 是做什么的？
先停一下
如果用户提到了 $ask、/ask、一个 ask 模式、预言机、深度审查、并行审查、圆桌讨论、争论、CAE 差距审查或 ask DAG，请在执行任何操作前完整阅读本文件。然后使用真实的运行时入口点，除非用户明确要求使用回退方案，或者运行时不可用并且该回退方案已被报告。
不要用 spawn_agent、普通模型调用、普通网络搜索、手动摘要或虚构的审查来替代 $ask。
运行时入口点
在此目录下运行命令。Pi 技能命令语法（例如 /skill:ask webgpt 2+2等于几?）是一等快捷键：前导浏览器处理器（webgpt、webclaude、webkimi、webgemini 或 webgrok）会路由到 Tau 的 single-call 浏览器处理器 DAG，并带有 --execute --json 参数。内联的 Pi 技能引用（例如 $ask webgpt 2+2等于几?）以及带空格的自然语言拼写 $ask web gpt 2+2等于几? 必须同样处理（web gpt 标准化为 webgpt）。这只是 Pi 用户的兼容性快捷方式；绝不能使用已移除的直接 WebGPT 预言机路径。
./run.sh tau-dag "<请求>" 在内部映射到 Typer tau-dag run 子命令。./run.sh team-plan "<请求>" --team <预设> 会生成一个基于角色的多代理计划和一个冻结的 Tau DAG 预览；执行需要显式的 --execute --live 参数（参见 README 中的“团队编排”）。
cd skills/ask
./run.sh --help
./run.sh webgpt 2+2等于几?
./run.sh webgpt --compile-only 2+2等于几?
./run.sh ask --help
./run.sh tau-dag run --help
每个重要的运行都必须保留运行时产物。标准产物集包括：
<ask_id>.request.json<ask_id>.status.json<ask_id>.events.jsonl- 模式特定输出，例如
review.md、review.json、DAG 清单或浏览器证据
运行时产物默认存储在 .ask_artifacts/runs/<ask_id> 或提供的 --run-output-root 目录下。对于长时间运行、实时运行或生成式运行，建议使用存储支持的根目录，例如 /mnt/storage12tb/skills/ask/outputs/...。不要提交生成的 ask 产物。
每次执行的处理器调用（成功或失败）都会在执行 choke 点记录到 memory 中的 ask_call_log 集合，记录内容包括处理器、状态、failure_code、以及 controlled_tab_id/对话 URL（如果存在），还包括上一次成功调用的已证明方法（推理选择、标签绑定、生命周期模式、包含密码信息的调度命令）。模型 ID 会对照实时 SciLLM 目录在编译时进行验证（invalid_scillm_model_id BLOCKED，并提供最接近的有效替代方案）；一个连续 3 次或以上记录失败的浏览器座位会在调度前被标记为已知故障，并附带其失败代码。在依赖一个座位前先检查它：python3 skills/ask/scripts/ask_call_history.py --handler webgemini 会打印最近一次成功调用和近期失败；添加 --recommend 参数可获取要重用的确切证明方法。没有记录成功调用的处理器是盲目猜测——先编译或不执行地廉价探测。历史运行是可回溯填充的：python3 skills/ask/scripts/backfill_call_log.py [outputs-root] 会幂等地摄取磁盘上的每个节点收据（每个运行+节点具有确定性的 _key）。
每个已执行运行的 JSON 结果（以及 execution-status.json）也包含 handler_last_success：每个座位的最近一次成功方法来自记忆（对话 URL、标签、生命周期/布局）、当前连续失败次数以及要避免的失败代码——这些信息在上下文中返回，以便项目代理在使用一个运行后无需单独进行历史查询。
深度参考（按需阅读）
| 执行此操作前 | 请阅读 |
|---|---|
使用计划文件的 team-plan；status --run --projection | references/plans-and-status.md |
| 显式的 Pi 原生子代理目标 | references/pi-subagents.md |
| 将 ask 输出（一次性/圆桌/竞争/隔离）转化为子代理通道 | references/lane-handoff.md |
herdr list/who/send 到另一个代理的面板 | references/herdr.md |
| 选择一次性 vs 圆桌 vs 竞争；模型/精力选择器 | references/modes.md |
| 面板审计、座位名册、速率受限座位、webclaude 策略 | references/seats-and-audits.md |
| 执行/监督任何实时运行（监控、窗口、负载矩阵、解除阻塞、漂移） | references/operations.md |
| 任何运行失败 | references/diagnosis.md |
| 编译/执行任何多座位 DAG（圆桌/竞争/创作者-审阅者） | references/workflows.md |
| 任何浏览器处理器执行 | references/browser.md |
四种目标类型
/ask 处理四种对等的目标类型。它们在传输方式上有所不同，但在地位上是平等的：
| 目标 | 示例 | 传输所有者 |
|---|---|---|
| Herdr 会话 — 面板中的实时代理 | memory, w11:p13 | $monitor-herdr 通过 herdr pane run |
| 模型调用 — API/模型处理器 | gpt-5.5-high, Codex-opus-5-high, deepseek-ai/DeepSeek-V3.2-TEE | $tau（SciLLM 是 Tau 的内部组件） |
网页模型 — 浏览器支持的审查者（聊天标签，非代理模型；请参见下面的 webclaude 警告） | webgpt, webclaude, webkimi | $surf + $browser-oracle |
| Pi 原生子代理 — 本地 Pi 子顾问/工作者 | pi reviewer, subagent general-purpose, local coder | pi-subagents 原生 subagent 工具 |
项目代理不应关心哪一方是浏览器、模型、Herdr 会话或 Pi 原生子代理，只需指定目标名称即可。
项目代理快速入门
当用户请求单个模型调用、圆桌讨论、竞争或创作者-审阅者循环时，从这里开始。使用以下的一种形式，不要发明自定义编排路径。
| 用户意图 | 命令形式 |
|---|---|
| 一个处理器回答 | ./run.sh tau-dag "<任务>" --repo <仓库> --target <目标> --immutable-goal "<不可变目标>" --handler <处理器或模型> --execute --json |
| 圆桌讨论 | ./run.sh tau-dag "<共享任务>" --repo <仓库> --target <目标> --immutable-goal "<不可变目标>" --dag-template roundtable --handler <a> --handler <b> --topology concurrent --execute --json |
| 竞争 | ./run.sh compete "<隔离任务>" --repo <仓库> --target <目标> --immutable-goal "<不可变目标>" --handler <a> --handler <b> --criterion <标准> --execute --json |
| 一次性查询（每个座位独立回答，无共识） | ./run.sh one-shot "<问题>" --handler <a> --handler <b> --handler <c> — N 个独立的单次调用通道并发运行；每个通道返回其自己的 nonce 绑定答案或命名阻塞器。部分答案为 DEGRADED-but-usable（达到或超过 --min-answered 时退出码为 0）；圆桌讨论的法定人数拒绝在此处不适用。 |
| 从 Pi 内部调用 Pi 原生子代理 | subagent({ action: "list" }), 然后 subagent({ agent: "<代理>", task: "<任务>" }) 或一个 workflowScript 扇出。这仅适用于显式 pi/subagent/local reviewer 目标；它不是 Tau/浏览器处理器的替代品。 |
| 创作者然后审阅者 | ./run.sh tau-dag "<创作者任务然后是审阅者裁决>" --repo <仓库> --target <目标> --immutable-goal "<不可变目标>" --dag-template creator-reviewer --handler <创作者> --handler <审阅者> --topology sequential --execute --json |
| 诊断/修复/关闭 GitHub 问题 | ./run.sh fix-issues --repo <所有者/名称> --issue <N> [--issue <M>] [--handler gpt-5.5] [--execute] — 通过 gh 收集每个问题，通过实时一次性处理器诊断成结构化的原因/修复 JSON，并带有 调试器阶梯门控（needs_debugger 仅当失败转换是进程内运行时状态且无工件可解释时才推荐使用 $debugger），且默认为故障关闭：默认情况下为 dry-run；--execute 仅在其命名的验证命令（通常是 $agentic-evals 夹具）实际通过后才关闭问题。无验证 → blocked；验证失败 → verify-failed，问题保持打开状态。每个问题的收据在 outputs/fix-issues/ 下。门控：fixtures/fix_issues.json。 |
处理器即使传输方式不同，也是对等的。浏览器处理器（webgpt、webclaude、webkimi、webgemini、webgrok）通过 $surf 和 $browser-oracle 运行。API/模型处理器（如 gpt-5.5-high、gpt-5.5-xhigh、Codex-opus-5-high 或 chutes deepseek-ai/DeepSeek-V3.2-TEE）由 Tau 路由。项目代理不应关心哪一方是浏览器还是 API，只需指定处理器名称即可。
处理器无论是由浏览器支持（webgpt、webclaude、webkimi、webgemini、webgrok 通过 $surf/$browser-oracle）还是由 API 支持（gpt-5.5-high、claude-opus-5-high、chutes <提供者/模型> 通过 Tau）都是对等的。在执行任何多座位 DAG 之前：先编译（省略 --execute），向用户展示打印的 ASCII 图表，并且仅在确认后运行。完整模式示例和选择器规则：references/modes.md。完整协议和故障关闭表格：references/workflows.md。
每次运行的不容商议事项
- 对于圆桌讨论、创作者-审阅者和竞争，必须有一个明确且不可变的目标（
--immutable-goal或标记为Immutable goal:的行）；缺少目标时，会在联系任何处理器之前使预检失败并显示NEEDS_INTERVIEW。 - 圆桌讨论总是采用
--topology concurrent，并为每个座位发送相同的数据包。竞争候选者是隔离的，彼此永远不可见。 - 已执行的 DAG 必须通过运行的 JSON 流产物（
events.jsonl、dag-progress.json、节点收据、execution-status.json）监控到最终裁决；不要启动后就离开。 PASS仅表示审查者/模型证据；本地关闭需要确定性的本地证明。DEGRADED/NEEDS_ATTENTION/速率限制是通道本地的：保留可用的座位，遵循失败通道的恢复数据包。- 非流式 API 补全必须通过带
finish_reason=stop的类型化准入检查，其文本才能算作证据。截断、过滤、缺少 finish_reason 或格式错误的补全会发出scillm_response_incomplete；保留原始字节和response.meta.json的验证错误。不要自动修复部分裁决文本或重试。保留的情况：completion-admission-rejects-truncation（捕获的重放）和completion-admission-live-positive（真实提供者回读）。 - 失败不能静默：每个失败的通道会暴露
failure_code、一个恢复数据包以及next_command/工单指令。发生任何失败时，请阅读references/diagnosis.md并在理论推断之前根据所属收据进行调度。 - 直接 WebGPT 预言机路由（
$ask chatgpt、--oracle-backend webgpt、--webgpt-*）故障关闭；Tau 浏览器处理器仍然受支持。 - 跟进连续性： 每个浏览器通道的节点收据 /
response.meta.json必须携带controlled_tab_id和对话 URL；空的标签 ID 表示交接失败。当用户可能会提出澄清性或跟进问题时，使用--browser-tab-lifecycle fresh-keep（或reuse-bound）运行——默认的auto/fresh-temporary 会在运行后关闭窗口，从而终止对话。运行后，报告标签 ID 和对话 URL，并绑定它们（skills/browser-oracle/run.sh bind <项目> --backend <b> --tab-id <id> --url <url> --manual），以便后续跟进针对同一会话。 - 标签可见性门控（2026-09-15 观察到，webgemini）： 某些提供者（已确认 Gemini）会在标签页为隐藏文档时延迟 composer 发送——在共享窗口中只有一个标签页可以前置，因此 N 个并发通道中的 N-1 个始终是隐藏的，并停滞为
prompt_too_large_or_stalled（“提示在发送后仍留在 composer 中”）。因此，并发浏览器通道默认使用隔离窗口（每个座位一个窗口，放置在审查者桌面上），以便每个通道标签页都是可见文档；--window-layout shared是选择加入的。一个已停滞但已输入内容的 composer 是可以挽救的：skills/surf/run.sh tab.switch <id>使标签页可见，并且排队等待的发送将被调度。在缩小提示以处理此类失败之前，请检查document.visibilityState。每个座位已验证的有效方法存储在$memory中（ask_call_log键ask:method:webgemini；参见ask_call_history.py --handler webgemini --recommend）。 webclaude是一个 claude.ai 聊天标签页，仅用于测试——不是代理型 Claude。优先使用claude-fable-low，然后使用claude-opus-4-8-high（参见references/seats-and-audits.md）。
模式路由器
使用与用户请求匹配的最窄模式。
| 请求 | 运行时模式 | 所需细节 |
|---|---|---|
| 基于记忆的问题 | ./run.sh ask "<问题>" --json | 相关时包含范围。 |
| 预言机答案 | ./run.sh ask "<问题>" --oracle ... --json | 根据请求明确选择后端/模型/角色。 |
| Pi 浏览器处理器快捷方式 | ./run.sh webgpt 2+2等于几? 来自 /skill:ask webgpt 2+2等于几? | 重写为 Tau 的 single-call，带有 --handler webgpt --execute --json 参数；使用 --compile-only 发出 DAG，而不使用实时浏览器传输。 |
| 单个命名处理器 | ./run.sh tau-dag "<请求>" --handler <处理器或模型> --json | 浏览器处理器使用 $surf；非浏览器处理器是由 Tau 路由的 $scillm 模型名称。添加 --execute 用于实时传输。 |
| Pi 原生子代理目标 | 原生 Pi subagent 工具，在 subagent({ action: "list" }) 之后 | 仅在 Pi 内部运行且用户显式指定 pi、subagent、pi-subagent、local reviewer 或 local coder 时使用。浏览器/模型/Tau Ask 请求不使用此路由。 |
| 多处理器圆桌讨论 | ./run.sh tau-dag "<请求>" --handler webclaude --handler gpt-5.5 ... --topology concurrent --execute --json | 圆桌讨论是从提示到 Tau DAG。默认情况下，浏览器处理器会获得一个 Ask 拥有的新窗口。保留 browser-tab-lifecycle.json、dag.json、命令规范、处理器收据和联合收据。 |
| 竞争 / 淘汰赛 | ./run.sh compete "<任务>" --handler webgpt --handler webclaude --handler gpt-5.5-high --criterion deterministic-proof --execute --json | 隔离的候选者加上竞争评分卡和获胜者延续请求。浏览器/API 处理器是对等的。项目代理在提升前必须在本地验证特性。 |
| 创作者-审阅者循环 | ./run.sh tau-dag "<创作者任务然后是审阅者裁决>" --repo <仓库> --target <目标> --immutable-goal "<不可变目标>" --dag-template creator-reviewer --handler <创作者> --handler <审阅者> --topology sequential --execute --json | 创作者和审阅者处理器使用不同的提示。审阅者裁决包含创作者输出。项目代理必须保证创作者输出格式。 |
| 诊断/修复 GitHub 问题 | ./run.sh fix-issues --repo <所有者/名称> --issue <N> [--issue <M>] [--handler gpt-5.5] [--execute] | 每个问题通过 gh 收集，诊断成 JSON，并通过验证命令检查。 |
AI 伦理门控
ask 运行时包含一个针对日志偏见审查的 AI 伦理门控。如果用户请求审查任何 ask 日志（例如审查请求日志、结果日志、对话日志）的“偏见”或“公平性”，系统将使用预定义的提示进行审查，这些提示可能代表不同的利益相关者。这是特别标记的，应在 AI 伦理上下文窗口中处理。