custom-agent-router

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Custom Agent Router

把已獲授權的工作映射成最小可行執行形狀。只選擇執行方式，不建立權限、任務追蹤器、規格或新的工作流程。

Map authorized tasks into the minimal viable execution shape. Only select execution methods; do not create permissions, task trackers, specifications, or new workflows.

綁定執行環境

Bind Execution Environment

先完成通用路由，再讀取當前 runtime profile：

Codex：讀取 Codex runtime profile。
沒有已驗證 profile：保留抽象 tier，由主 Agent 使用現場可證明的能力，並記錄 binding 偏差；不要猜測模型、effort、唯讀或 fresh-context 能力。

runtime profile 只能選擇實際模型與角色，不能改變 mode、risk、shape、批准或專案規則。

Complete the general routing first, then read the current runtime profile:

Codex: Read Codex runtime profile.
No validated profile: Retain the abstract tier, use field-verifiable capabilities by the main Agent, and record binding deviations; do not guess model, effort, read-only, or fresh-context capabilities.

The runtime profile can only select actual models and roles, and cannot modify mode, risk, shape, approval, or project rules.

Codex 專案設定閘門

Codex Project Configuration Gate

在 Codex runtime 套用本 Skill 時，先確認目前專案的

.codex/config.toml

、

.codex/agents/*.toml

與 runtime metadata。若專案設定不存在、不完整或無法證明符合 profile，讀取 Codex 專案設定引導，說明目前能安全使用的降級能力，再詢問使用者要「建立建議設定」、「只顯示建議」或「暫不設定」。

未取得使用者選擇前，不得建立或修改設定。若使用者略過，仍可完成通用路由，但要保留抽象 tier，只使用現場能證明的能力並記錄 binding 偏差，不得把未驗證的 named role、模型、effort、唯讀或 fresh-context 能力寫成已可用。

When applying this Skill in Codex runtime, first check the current project's

.codex/config.toml

.codex/agents/*.toml

, and runtime metadata. If the project configuration does not exist, is incomplete, or cannot be proven to comply with the profile, read Codex Project Onboarding Guide, explain the currently available downgraded capabilities that can be used safely, then ask the user to choose "Create recommended configuration", "Show only recommendations", or "Skip configuration for now".

Do not create or modify configurations without obtaining the user's selection. If the user skips, the general routing can still be completed, but the abstract tier must be retained, only field-verifiable capabilities can be used, binding deviations must be recorded, and unvalidated named roles, models, effort, read-only, or fresh-context capabilities cannot be written as available.

先確認邊界

Confirm Boundaries First

先讀取系統、使用者與專案規則。上層規則永遠優先。
確認目標、允許範圍、驗收方式與停止條件足以執行。
若缺少的資訊會改變結果、權限或風險，先詢問或做有限唯讀調查。
沿用專案既有的任務追蹤器、Git、安全與批准規則，不建立第二套系統。
只使用執行環境能證明存在的 Agent、sandbox、審查與並行能力，不依名稱猜測。

派工、重試或升級只能改變執行者，不能擴大檔案、工具、外部 mutation 或批准範圍。

First read system, user, and project rules. Upper-level rules always take precedence.
Confirm that objectives, allowed scopes, acceptance methods, and stop conditions are sufficient for execution.
If missing information will change the result, permission, or risk, first ask questions or conduct limited read-only investigations.
Follow the project's existing task trackers, Git, security, and approval rules; do not establish a second system.
Only use Agents, sandboxes, review, and parallel processing capabilities that can be proven to exist in the execution environment; do not guess based on names.

Dispatch, retry, or upgrade can only change the executor, and cannot expand the scope of files, tools, external mutations, or approvals.

路由順序

Routing Sequence

依序決定

mode → tier → risk → shape → review → fallback

。風險控制批准與審查，不直接決定 Agent 數量。

Determine

mode → tier → risk → shape → review → fallback

in order. Risk controls approval and review, and does not directly determine the number of Agents.

1. 選擇 mode

1. Select Mode

Mode	條件	下一步
`execute`	結果、範圍與驗收清楚	直接執行，或交給最低可勝任的能力層級
`explore_then_plan`	方向清楚，但證據不足、跨元件或回復昂貴	做有限唯讀調查，形成一個可驗證工作切片
`co_discover`	問題、產品選擇或驗收仍不清楚	只釐清會改變方向的問題，搭配低成本探查

Mode	Conditions	Next Step
`execute`	Clear results, scope, and acceptance criteria	Execute directly, or assign to the minimally competent capability tier
`explore_then_plan`	Clear direction, but insufficient evidence, cross-component, or high recovery cost	Conduct limited read-only investigation to form a verifiable task slice
`co_discover`	Unclear problem, product selection, or acceptance criteria	Only clarify issues that will change the direction, paired with low-cost exploration

2. 選擇 tier

2. Select Tier

Tier	工作特徵
`light`	搜尋、列舉、重現、測試、格式與規則固定的機械工作
`standard`	邊界清楚，但需要工程判斷的實作、除錯、整合與審查
`frontier`	歧義、架構、跨元件根因、安全、不可逆決策與最終仲裁

選擇最低可勝任的 tier。高 tier 可以暫代低 tier，但要在路由紀錄旁註明模型綁定偏差；低 tier 不得替代必要的安全、架構或高風險判斷。實際模型與 effort 由執行環境設定綁定，本 Skill 不指定產品模型名稱。

Tier	Task Characteristics
`light`	Search, enumeration, reproduction, testing, formatting, and mechanical tasks with fixed rules
`standard`	Implementation, debugging, integration, and review tasks with clear boundaries that require engineering judgment
`frontier`	Ambiguity, architecture, cross-component root cause analysis, security, irreversible decisions, and final arbitration

Select the minimally competent tier. Higher tiers can temporarily replace lower tiers, but model binding deviations must be noted next to the routing record; lower tiers cannot replace necessary security, architecture, or high-risk judgment. The actual model and effort are bound by the execution environment settings; this Skill does not specify product model names.

3. 套用 risk gate

3. Apply Risk Gate

Risk	典型條件	最低驗證
`low`	局部、可回復、驗收直接	執行者自測，主 Agent 回查
`material`	跨檔案或元件，或改變使用者可見行為	主 Agent 整合驗證；有明顯不確定性時使用全新上下文審查
`high`	資安、發布、外部狀態或回復昂貴	明確計畫與批准閘門；完成後使用全新上下文審查
`critical`	資料遺失、正式流量、不可逆或重大權限影響	停止自動執行，取得明確批准與獨立驗證

若工作包含資料庫或正式環境 mutation，先使用

explore_then_plan / frontier / critical

。批准只授權指定操作，不等於完成驗證。

Risk	Typical Conditions	Minimum Verification
`low`	Local, recoverable, direct acceptance	Self-test by executor, review by main Agent
`material`	Cross-file or cross-component, or changes user-visible behavior	Integrated verification by main Agent; use fresh-context review when there is obvious uncertainty
`high`	Security, release, external state, or high recovery cost	Clear plan and approval gate; use fresh-context review after completion
`critical`	Data loss, production traffic, irreversible, or major permission impact	Stop automatic execution, obtain explicit approval and independent verification

If the task involves database or production environment mutation, first use

explore_then_plan / frontier / critical

. Approval only authorizes specified operations, and does not equal completion of verification.

4. 通過 dispatch brake

4. Pass Dispatch Brake

派工前逐項確認：

每個工作代理的完成結果能用一句話說清楚。
主 Agent 直接做不會更便宜可靠。
工作不需要等待另一個工作代理才能前進。
每個可寫工件只有一個負責者。
已指定整合與最後驗證的負責者。

任一項不成立就維持

direct

，或先調查到邊界清楚。通過後只使用三種形狀：

Shape	條件
`direct`	小工作、緊密耦合問題，或方向仍需主 Agent 判斷
`single_worker`	一個邊界與驗收都清楚的獨立工作流
`bounded_parallel`	至少兩個已就緒工作彼此獨立，且寫入責任不重疊

使用

single_worker

或

bounded_parallel

時，派工說明至少包含：目標、允許寫入範圍、不可觸碰範圍、輸入證據、驗收命令、停止條件與回傳格式。主 Agent 保留整合責任。

Confirm the following items one by one before dispatch:

The completion result of each task agent can be clearly described in one sentence.
Direct execution by the main Agent is not cheaper or more reliable.
The task does not need to wait for another task agent to proceed.
Each writable artifact has only one responsible party.
The responsible party for integration and final verification has been designated.

If any item is not satisfied, maintain

direct

, or first investigate until the boundaries are clear. After passing, only use three shapes:

Shape	Conditions
`direct`	Small tasks, tightly coupled problems, or direction still requires judgment by the main Agent
`single_worker`	An independent workflow with clear boundaries and acceptance criteria
`bounded_parallel`	At least two ready tasks that are independent of each other and have non-overlapping writing responsibilities

When using

single_worker

bounded_parallel

, the dispatch description must include at least: objective, allowed writing scope, forbidden scope, input evidence, acceptance command, stop condition, and return format. The main Agent retains integration responsibility.

5. 選擇 review 與 fallback

5. Select Review and Fallback

```
low
```
：使用
```
review=lead
```
，不為形式建立審查者。
```
material
```
：預設由主 Agent 整合驗證；跨模組、不確定性高或作者偏誤明顯時，使用
```
review=fresh
```
。
```
high / critical
```
：完成聲明使用
```
review=approval+fresh
```
。若執行環境無法證明全新上下文或唯讀能力，就停止完成聲明，不以自審冒充。
第一次失敗先修正派工說明、證據或環境問題；需要時同一 tier 最多重試一次。
同原因再次失敗時最多升一個 tier。升級後仍失敗，或必要能力不可用，就交回主 Agent 或使用者，不再自動重跑。

```
low
```
: Use
```
review=lead
```
, do not establish reviewers for formality.
```
material
```
: Default to integrated verification by the main Agent; use
```
review=fresh
```
when cross-module, high uncertainty, or obvious author bias exists.
```
high / critical
```
: Use
```
review=approval+fresh
```
for completion declaration. If the execution environment cannot prove fresh-context or read-only capabilities, stop the completion declaration and do not pretend to be self-review.
For the first failure, first correct the dispatch description, evidence, or environment issues; retry at most once in the same tier if needed.
If it fails again for the same reason, upgrade at most one tier. If it still fails after upgrading, or necessary capabilities are unavailable, hand it back to the main Agent or user, and do not automatically rerun.

輸出路由紀錄

Output Routing Record

非簡單派工、能力升級或高風險直接執行都輸出一行：

text

mode=execute risk=material tier=standard shape=single_worker owner=builder review=fresh fallback=one-tier-max

欄位只使用以下值：

欄位	值
`mode`	`execute` 、 `explore_then_plan` 、 `co_discover`
`risk`	`low` 、 `material` 、 `high` 、 `critical`
`tier`	`light` 、 `standard` 、 `frontier`
`shape`	`direct` 、 `single_worker` 、 `bounded_parallel`
`owner`	負責交付的角色或 Agent 名稱
`review`	`lead` 、 `fresh` 、 `approval+fresh`
`fallback`	`none` 、 `same-tier-once` 、 `one-tier-max`

路由紀錄只保存決策，不取代派工說明、測試證據、批准紀錄或任務狀態。簡單且直接完成的工作不必為了格式輸出路由紀錄。

runtime profile 若要求 binding receipt，就放在 route receipt 下一行。binding receipt 只能補充實際角色、模型、effort 與偏差，不得覆寫通用路由結果。

Output one line for non-trivial dispatch, capability upgrade, or high-risk direct execution:

text

mode=execute risk=material tier=standard shape=single_worker owner=builder review=fresh fallback=one-tier-max

Only use the following values for fields:

Field	Values
`mode`	`execute` , `explore_then_plan` , `co_discover`
`risk`	`low` , `material` , `high` , `critical`
`tier`	`light` , `standard` , `frontier`
`shape`	`direct` , `single_worker` , `bounded_parallel`
`owner`	Role or Agent name responsible for delivery
`review`	`lead` , `fresh` , `approval+fresh`
`fallback`	`none` , `same-tier-once` , `one-tier-max`

The routing record only saves decisions, and does not replace dispatch descriptions, test evidence, approval records, or task status. Simple and directly completed tasks do not need to output routing records for formatting purposes.

If the runtime profile requires a binding receipt, place it on the line below the route receipt. The binding receipt can only supplement actual roles, models, effort, and deviations, and cannot overwrite the general routing result.

固定回歸案例

Fixed Regression Cases

案例	預期路由
回答單一事實或唯讀確認	`execute / light / low / direct / lead`
邊界清楚的單一工程修改	`execute / standard / material / single_worker / lead`
兩個獨立且不寫同檔的盤點	`execute / light / low / bounded_parallel / lead`
需求與驗收仍有產品歧義	`co_discover / frontier / direct`
跨元件、證據不足但方向清楚	`explore_then_plan / frontier / material / direct`
資料庫或正式環境 mutation	`explore_then_plan / frontier / critical / approval+fresh`
低能力層級不可用	記錄綁定偏差後升一層，或由主 Agent 直接處理
必要的全新上下文審查者不可用	停止高風險完成聲明，不以自審冒充

更換執行環境設定只能改變實際模型，不得改變 mode、risk、shape 或安全邊界。

Case	Expected Routing
Answer a single fact or read-only confirmation	`execute / light / low / direct / lead`
Single engineering modification with clear boundaries	`execute / standard / material / single_worker / lead`
Two independent inventories that do not write to the same file	`execute / light / low / bounded_parallel / lead`
Product ambiguity in requirements and acceptance	`co_discover / frontier / direct`
Cross-component, insufficient evidence but clear direction	`explore_then_plan / frontier / material / direct`
Database or production environment mutation	`explore_then_plan / frontier / critical / approval+fresh`
Low-capability tier unavailable	Record binding deviation then upgrade one tier, or handle directly by main Agent
Necessary fresh-context reviewer unavailable	Stop high-risk completion declaration, do not pretend to be self-review

Changing execution environment settings can only modify the actual model, and cannot change mode, risk, shape, or security boundaries.

停止條件

Stop Conditions

遇到以下任一情況就停止自動推進：

授權、範圍或驗收仍會改變路由結果。
需要的批准尚未取得。
執行環境無法證明必要能力。
派工後出現未預期的重疊寫入或外部狀態變更。
同一原因已用完一次同 tier 重試與一次 tier 升級。

不要建立排程器、佇列、Agent 登錄表、Hook、路由資料庫或通用任務追蹤器。只有真實失敗證據顯示 Prompt 與執行環境原生能力不足時，才另案評估程式或 Hook。

Stop automatic advancement when any of the following situations occur:

Authorization, scope, or acceptance criteria will still change the routing result.
Required approval has not been obtained.
The execution environment cannot prove necessary capabilities.
Unexpected overlapping writes or external state changes occur after dispatch.
One same-tier retry and one tier upgrade have been used up for the same reason.

Do not create schedulers, queues, Agent registries, Hooks, routing databases, or general task trackers. Only evaluate programs or Hooks separately when real failure evidence shows that Prompt and native execution environment capabilities are insufficient.