用途
dispatching-agent-work 用于解决「一项工作应该由谁来执行」的问题。它把分发决策与具体厂商的模型名称、智能体 API 解耦：在分发模式激活时，把当前会话保持为协调者，尽量让独立的执行单元承担实质性工作；否则优先选择最小的执行单元，以及能够可靠满足成功标准的最低模型角色。
激活条件
技能只在以下情形下生效：当前请求或权威的主机、仓库指令明确要求分发或选择执行边界；或此前已明确建立的 dispatch 模式在当前会话中仍然活动。仅提及、查看或编辑该技能不会激活它；复杂度、耗时、成本或可能的并行性本身也不构成激活理由。当没有激活条件时，按主机常规策略由当前智能体继续处理。
技能区分「单次请求激活」与「分发模式」：前者只适用于该特定目标；诸如「进入分发模式」「充当协调者」这类请求，或建立该角色的权威指令，会让分发模式对同一会话中后续目标持续生效，直到用户要求退出或有权威指令改变角色为止。
在分发模式下，当前智能体主要作为协调者，主动分发每一个具备自包含交接内容与成功标准的实质性目标，用户不必每轮重复要求分发。只有澄清、路由、协调、综合以及确实只需一步的琐碎操作保留在当前会话中。激活只允许进行路由分析，不会覆盖主机策略，也不会扩大权限。
工作流程
- 确认激活与作用范围，并区分单次激活和持续模式。
- 捕获分发契约：目标与成功证据；意图属于回答、诊断、变更、监控还是调度；范围内的文件、系统与人员；审批与破坏性操作边界；持久化、后续跟进、截止时间与隔离需求；任何被明确指定的模型、后端或技能。委派时不扩大权限。
- 探查主机能力：检查可用工具与策略，而非假定主机支持任务、子智能体、工作树、模型覆盖、等待或审批转发。当有多个执行后端或需要回退时，阅读 execution-backends.md；当目标为 Codex 应用且可能存在独立的用户可见任务时，阅读 codex-app.md。
- 选择执行边界：先对指令分类。只有当指令确实是对某个工作单元目标的延续，并且产物面、权限、生命周期、所需模型角色和推理强度都相同时，才复用该工作单元；任一维度不同、未知或未核实，就当作新目标。分发模式下优先选择主机期望的工作单元边界：Codex Desktop App 为每个新的实质性目标创建独立的用户可见任务；有子智能体但无持久任务的主机为每个有界目标创建子智能体并在父级综合结果；两者都没有的主机则在当前智能体中完成并报告能力限制；定时或重复性工作使用自动化或排队任务。非分发模式下按「已有工作单元 → 自动化/排队任务 → 持久任务 → 子智能体 → 当前智能体」的顺序取首个匹配项。子智能体不等同于用户可见任务；也不应仅因某个昂贵的工作单元已经打开就向其追加琐碎后续任务。
- 选择模型角色与推理强度：语义角色分为 efficient（低强度，适合规格明确、验证廉价的窄任务）、balanced（中强度，适合多条件审计、数据分析或中等跨文件综合）、frontier（高强度，适合模糊、跨领域、长周期、架构性、创造性或缺乏可靠判定标准的任务）。角色与强度是两条独立轴，起始强度只是默认值。高后果、广泛耦合、规格不清、证据量大或工具无法验证的判断，应提升角色或强度；当确定性工具、聚焦测试或精确规格承担了大部分工作时应降低。该规则同样适用于协调者自身：当所需角色或强度超过当前智能体时，应分发而不是本地执行。不得仅凭代码行数推断质量需求；命名具体模型前需确认其可用性，否则只报告语义角色。
- 保证并发安全：只读任务在观察仍有效时可并行；对同一工作区或产物面的写入需串行；独立写入仅在主机与仓库策略支持时使用隔离工作区；无法隔离时排队处理。避免对正在被其他工作单元改写的文件启动只读审计，除非该审计明确接受某一时点快照。
- 构建精简交接：包含目标；范围与需保留状态；所需技能（按名称引用，不复制其完整流程）；成功证据；权限与禁止操作；最终报告字段。说明工作单元应当实现还是仅诊断。
- 分发与协调：交接具备目标与成功证据后应立即分发，不让用户去选择已由主机策略和本流程确定的后端。Codex Desktop App 分发模式使用主机原生任务创建操作，其他主机使用暴露的子智能体操作。只有当主机原生操作确认创建并返回任务或会话句柄/链接时，才算创建了持久任务；准备好编辑器或深链接不算分发成功。仅在父级需要综合结果时等待或监控。
输出
以简洁形式报告决策：backend（current | existing | durable-task | subagent | automation）、model-role（efficient | balanced | frontier）、reasoning（low | medium | high | host-default）、isolation（shared-read | serialized-write | isolated-write）以及一句话 reason。对持久任务还需报告 dispatch-status（created | prepared | unavailable），其中 created 仅在主机原生创建成功后使用，prepared 表示仍需用户操作，unavailable 表示既无法创建也无法进行忠实的用户中介交接。除非用户要求，不暴露内部路由分析。
适用场景与限制
该技能适用于需要决定执行边界、在多个工作单元之间协调、或在分发模式下持续作为协调者的智能体工作流。限制在于：它不会覆盖主机策略，不会扩大权限；其可用性取决于主机是否提供相应能力（任务、子智能体、隔离工作区、模型覆盖等）；如何获取该技能、是否收费、支持哪些模型与平台等具体信息在资料中暂未提供。