高效边界路由 是做什么的？
在 Claude Code、Codex 或其他支持按模型启动子代理的智能体（例如 Gemini CLI 或 Antigravity CLI）中，为任务匹配最合适的模型，无论主会话使用的是什么模型。一个更便宜的主会话可以协调常规工作，并在需要时咨询一个更强的智能体；一个更强的主会话可以将常规工作委派给更便宜的智能体。 当交接成本高于直接执行时，将小任务保留在本地完成。
帮助与配置
当使用 help 或 --help 调用时，读取配置帮助，解释控制项和示例，然后停止。对于帮助请求，不要启动委派工作或更改设置。对于配置问题，阅读同一份参考文档；对于普通任务，则跳过它。
应用来自用户请求和适用指令文件的路由偏好。对于此技能的偏好，首先使用显式任务指令，然后是项目偏好，全局偏好，最后是下面的默认值。主机权限、模型可用性和强制限制仍然适用。 用户可以选择发现、实现和审查模型；每个智能体的努力程度；升级触发器和重试次数；最大并发子代理数；以及升级是否需要批准。尊重配置的模型上限或无委派偏好。如果所需的审查无法在这些限制内运行，报告未满足的审查，而不是默默地替换它。这些是由助手解释的指令，不是 JSON 设置或硬性支出上限。除非被要求，否则不要编辑持久偏好。
工作流程
- 识别需要更强判断力的决策：架构、歧义、风险、冲突的证据以及最终的技术审查。在主会话适合该任务时，由主会话处理；否则向上委派。
- 识别可委派的工作：研究扫描、仓库清单、搜索、文档提取、浏览器/测试运行、日志缩减、测试失败聚类、范围明确的编码以及机械性编辑。
- 为合理的交接生成子代理，并行化独立的切片，明确所有权、限定范围、验证门控和证据。
- 要求紧凑的返回内容：发现、更改的文件、执行的命令、剩余风险、触发的停止条件以及需要综合或升级的决策。
- 在呈现结果之前，集中进行整合和审查。
交接包
将委派的提示编写为自包含的包。假设接收智能体没有看到对话。包括仓库路径、目标、范围、范围外区域、相关文件或搜索目标、预期的返回格式、验证命令和停止条件。
有用的停止条件：
- 实时代码与交接中的假设不匹配。
- 验证命令达到配置的重试限制（默认：两次合理修复尝试后失败）。
- 工作似乎需要超出分配范围的文件。
- 智能体无法为其声明提供具体证据。
审查循环
将委派的输出视为需要检查的证据，而不是需要转发的结论。重新打开重要引用的文件，浏览高风险差异，并在声称完成之前重新运行或抽查重要的验证。如果委派的智能体在一个困难的技术问题上存在分歧，使用一个更强的审查者并附上证据。将产品决策和范围变更留给用户。
常见场景
将这些作为软性建议：
- 研究：委派广泛的仓库扫描、文档提取和源代码比较；主会话对结果进行优先级排序，并将困难判断升级。
- 编码：在文件所有权明确时，委派边界明确的补丁、重构或机械性编辑；集中整合和审查。
- 测试：在适当的推理层级选择验证策略，然后使用更便宜的智能体运行单元检查、浏览器流程、屏幕截图和日志缩减。要求它们返回精确的命令、失败信息、可能的原因，以及信号是脆弱的、环境相关的还是产品相关的。
- 调试：将独立的智能体派往不同的理论、日志或复现路径；当证据仍然冲突时，升级诊断。
工作示例
一个使用 Sonnet 的主会话收到指令“修复失败的结账测试，并顺便收紧退款规则”，项目偏好设置为：发现使用 Haiku，实现使用 Sonnet，高风险审查使用 Opus 且努力程度为高，最多两个并发子代理。
- 发现工作由一个 Haiku 子代理执行：运行测试套件，聚类失败项，并返回失败的测试、它们触及的文件以及确切的命令。第二个 Haiku 子代理负责绘制退款逻辑的位置。
- 失败项聚集在一个过时的测试夹具上。这是一个边界明确、机械性的修复，所以主会话在本地进行修复，而不是为交接付出成本。
- 退款规则涉及计费模块，这是高风险的。在编辑之前，主会话向 Opus（明确请求，
effort: high）发送一个包含退款文件、提议的变更、当前测试以及一个问题的包：此变更是否会破坏任何现有的退款路径？ - 主会话应用变更，自行重新运行测试，重新打开 Opus 标记的两个文件，并报告每个步骤由哪个模型执行，以便用户可以看到更强的审查确实发生了。
层级匹配
使用主机可用的模型和用户的映射，选择最便宜且合适的层级，可以高于或低于主会话的模型：
| 工作 | 所需能力 | Claude 示例 | Codex 及其他主机 |
|---|---|---|---|
| 发现、摘要、事实核查 | 快速、准确的提取 | Haiku | 适合事实核查工作的快速可用模型 |
| 范围明确的实现和测试 | 在既定模式内可靠编码 | Sonnet | 适合该范围的可用编码模型 |
| 架构、深度调试、高风险审查 | 跨系统的强推理能力 | Opus，或 Fable（如可用） | 更强的可用推理模型 |
Claude 名称是针对 Claude 会话的示例，而不是传递给 Codex 的别名。不要发明 Codex 模型 ID，或假设供应商之间存在永久的——对应关系。检查主机的可用模型选择，并使用明确的有效名称。除非用户另有要求，否则对于普通路由保持当前提供商；在需要时应用单独的不同供应商审查规则。独立于模型选择努力程度，并尊重用户的努力程度限制。不要将所有智能体默认设置为最高努力程度。
较强的主会话可以直接做出困难决策。从较便宜的会话中，使用紧凑的证据包委派困难决策或审查，然后整合结果并运行所需的检查。如果主机只暴露一个模型，则在该模型上执行所有工作，并报告任何未满足的更强审查要求。不要仅仅因为努力程度增加就声称使用了更高的模型层级。
从较便宜主会话进行升级
在实施不熟悉的架构变更或对高风险不变量的变更之前，根据用户的升级策略进行升级。当证据冲突或达到重试限制（默认：对同一技术问题进行两次合理尝试）时，也要升级。重用已收集的证据；不要为对相同文件进行另一轮广泛探索而付费。
将身份验证、计费、权限、安全、迁移、数据丢失、共享状态、缓存、并发、跨模块行为、公共 API 和用户可见的工作流程视为高风险。使用最适合该决策或技术审查的层级。当用户要求高风险工作由不同供应商的模型进行审查时，保留该审查；它提供了来自不同模型的观点。
在 Claude Code 中，在 Agent 调用中显式请求子代理的 model，或使用具有 model: opus 的自定义代理（并在适当时使用 effort: high）。未指定的模型可能会继承较便宜的主模型。使用具有聚焦交接的普通子代理；对话分叉将使用主模型。检查报告的模型，在可用时使用 /tasks。在 Codex 或其他主机中，通过主机支持的每个代理选择器显式设置模型和推理努力程度。如果继承完整对话会阻止模型覆盖，则使用聚焦的任务交接。检查报告的选项；如果主机无法为每个代理选择模型，则报告该限制，而不是模拟路由。
将主会话保持在其选择的模型上。这是一个路由指令，不是自动的运行时路由器，也不能保证较便宜的模型会检测到每个困难案例。如果所需的模型不可用或受限制，报告该限制，而不是默默地声称发生了更强的审查。
护栏
- 对于即时阻塞点，在本地工作，除非更强的专业知识或上下文隔离证明顺序交接是合理的。在等待时做独立的工作（如果可用）。
- 不要要求多个智能体同时编辑相同的文件。
- 当风险很高时，不要盲目信任子代理的结论；亲自检查重要的证据。
- 不要声称普遍节省成本。这种模式在探索与实现、测试或研究可以并行化时效果最佳。
默认框架
“我将把常规工作保留在当前模型或更便宜的模型上，并在需要时将困难决策或高风险审查委派给更强的智能体。”