委託模式（Delegation）

OCR 負責確定性工程，宿主 Agent 用自己的 LLM 做評審——不用設 API key

是什麼

委託模式把工作切開：OCR 負責確定性工程（檔案篩選、規則解析、排除邏輯），宿主 Agent 使用自身的 LLM 能力執行實際評審。OCR 端不需要配置 LLM。

何時使用

專為訂閱制 AI 編碼代理設計——Claude Code、Codex、Cursor、OpenCode、Qoder 等：

你的 AI 編碼代理用訂閱制，想複用已有額度做評審——不需額外 API key 或模型端點。
你只需要 OCR 的工程腳手架（檔案過濾、規則解析、排除邏輯），由宿主 Agent 負責所有 LLM 推理。
你在建自訂 Agent 管線，需要結構化輸入（檔案清單 + 規則）作為自身評審步驟的輸入。

前置條件

which ocr || npm install -g @alibaba-group/open-code-review

不需配置 LLM——委託模式在 OCR 端不呼叫任何 LLM。

安裝 Skill / Command

# Claude Code — Command
mkdir -p .claude/commands
curl -o .claude/commands/delegate-review.md \
  https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/claude-code/commands/delegate-review.md

# 任意 Agent — Skill
npx skills add alibaba/open-code-review --skill open-code-review-delegate

工作流程

Step 1 — Preview：確定評審範圍

ocr delegate preview                # 工作區
ocr delegate preview --from main --to feature
ocr delegate preview -c abc123      # 單次提交

輸出 mode（workspace/range/commit）、ref 元資料、可評審檔案清單（路徑、狀態、插入/刪除行數）、已排除檔案與原因。

Step 2 — 取得檔案規則

ocr delegate rule <path1> <path2> ...

依規則內容分組輸出——共享相同規則的檔案歸為一組，避免重複。

Step 3 — 取得 diff

# Range 模式
git diff <merge_base>..<to> -- <path>
# Commit 模式
git show <commit> -- <path>
# Workspace 模式
git diff HEAD -- <path>        # 已追蹤檔案
cat <path>                      # 新的未追蹤檔案

Step 4-5 — 評審與報告

對每個可評審檔案：取 diff → 參照規則組 → 深入評審。
Critical/High——bug、安全問題、資料遺失風險。永遠回報。
Medium——效能、錯誤處理缺失。附脈絡回報。
Low——風格建議。靜默丟棄，除非確有價值。

子命令與旗標

命令	用途
`ocr delegate preview`	列出可評審檔案 + mode/ref 元資料
`ocr delegate rule <path...>`	依內容分組解析評審規則

通用旗標：--from / --to / -c --commit / --repo / --rule / --exclude / -b --background / -B --background-file。

與其他整合方式對比

模式	誰呼叫 LLM？	適用場景
Agent Skill	OCR	OCR 驅動完整評審
Command（Claude Code）	OCR	斜線命令，OCR 驅動，自動修復
委託模式	宿主 Agent	OCR 提供腳手架，Agent 驅動評審

📖 教學解說：委託模式深入

「誰負責什麼」的精確分工

委託模式的核心是職責分離：

OCR 負責：檔案篩選（五重門）、規則解析（四層鏈）、排除邏輯、結構化輸出——這些是確定性的，不需要 LLM。
宿主 Agent 負責：所有 LLM 推理——讀 diff、依規則評審、產生評論。

OCR 端完全不呼叫 LLM，所以不需要 API key。這是與 Agent Skill / Command 的本質差異。

五步工作流的實務技巧

Step 1 ocr delegate preview 的輸出不只是清單——它包含 mode（workspace/range/commit）、merge_base、以及每個檔案的排除原因。先看排除原因再決定是否調整 --exclude。Step 2 ocr delegate rule 會自動按規則內容分組——共享相同規則的檔案只出現一次規則文本，避免重複。

與 Agent Skill 的選擇矩陣

選哪個？看兩個問題：① OCR 的 LLM 要用誰的？② 要自動修復嗎？

用自己的 API key、不自動修復 → Agent Skill
用自己的 API key、要自動修復 → Command（Claude Code）
不想付 API key、宿主有訂閱 → 委託模式

練習 / 驗收清單

能解釋委託模式「誰負責什麼」
能描述五步工作流
能區分委託模式與 Agent Skill / Command
能設定 Claude Code 的 delegate-review 命令

看完這頁你應該能說出：委託模式「誰負責什麼」（OCR 工程 / Agent 推理）、為什麼訂閱制代理最適合、五步工作流、以及它與 Agent Skill / Command 的本質差異。

延伸閱讀：整合 · 快速開始 · 評審規則

① 進階真實情境 Worked Example：在 OpenCode / Claude Code 裡跑一次完整委託評審

情境

你用的是訂閱制 Claude Code，不想付額外 API key。現在要審一批變更（跨 3 個檔、含 auth.go 的安全修改），你要宿主 Agent「拿到檔案清單 + 規則 + diff 後，自己決定該查什麼、該批什麼」，OCR 全程不碰 LLM。

Step 1 — 確定評審範圍（OCR 確定性工程，不花你額度）

ocr delegate preview

mode: workspace
merge_base: -
files:
  internal/auth/login.go     modified  (+38 -12)
  internal/upload/store.go   modified  (+5 -3)
  web/src/api.ts             added     (+120)
excluded: 4 files (generated, vendor)

Step 2 — 取得每檔的評審規則（依內容分組，避免重複）

ocr delegate rule internal/auth/login.go internal/upload/store.go

group 1 (auth rules): login.go
  → Check for missing error handling after db.Begin()...
group 2 (upload rules): store.go
  → Check for path traversal and unbound writes...

Step 3 — 讓宿主 Agent 自己拿 diff 並評審

# 在 Claude Code 裡，讓它執行：
git diff HEAD -- internal/auth/login.go internal/upload/store.go
# 並對照 Step 2 的規則做推理
# 對新檔 web/src/api.ts：cat 讀整檔

宿主 Agent 用自己的 LLM 額度完成推理——這就是委託模式的精髓：OCR 給「審什麼 + 用什麼標準」，Agent 給「動腦」。

Step 4 — 依分級回報

Critical/High：永遠回報（auth.go 的登入驗證順序問題）。
Medium：附脈絡回報（store.go 的未驗證路徑）。
Low：靜默丟棄（api.ts 的命名風格）。

為什麼選這條審查路徑

訂閱制場景下，「讓 OCR 呼叫 LLM」就是雙重付費。委託模式把「確定性工程」留在 OCR（免費、可測試），把「推理」留在宿主（你已付費的額度）。你得到的好處：檔案過濾與規則解析確定且一致，而評審深度由你信的 agent 決定——省下「多養一套 LLM 端點」的成本與管理。

預期產出

review decision (host agent):
  [HIGH] auth/login.go: 驗證順序錯誤，token 檢查在 rate-limit 之後 → 可被繞過
  [MED]  upload/store.go: 未驗證 user-supplied path
  (web/src/api.ts 僅 Low 風格，靜默)

② 深入原理擴充：委託模式與內建評審的邊界在哪

同一套五重門、不同輸出端

ocr delegate preview 與 ocr review --preview 共用同一套檔案過濾與規則解析——五重門、四層規則鏈都一樣。差別只在「後續誰來推理」：內建模式由 OCR 啟動子 agent 迴圈；委託模式把結構化輸入吐給宿主。這表示你對內建模式學到的過濾知識，在委託模式全部適用——--exclude、--rule、--background 的語意都一致。

「看起來完成評審但其實有隱患」的案例

# 宿主 Agent 拿到 preview 後，直接對所有檔案「草草審完」：
# 它只看了 preview 的檔案清單，沒讀 rule 輸出，也沒取 diff
for f in $(ocr delegate preview | jq -r '.files[].path'); do
  echo "reviewing $f ... done (no issues)"   # ← 假評審
done

委託模式把「評審品質」完全押在宿主 Agent 的自律上——OCR 端沒有 LLM、沒有 REVIEW_FILTER_TASK、沒有定位模組，因為這些都由宿主執行。隱患：宿主 Agent 為了省事可能「假裝審完」。防禦：在 Step 4 要求宿主「每條 HIGH/MED 都附上引用的程式碼片段」——引不出程式碼片段的「評論」就不算數；比對 Step 3 的 diff 與規則，要求引用對得上。

③ 診斷式疑難排解

症狀	可能原因	解決方案
`ocr delegate preview` 輸出空清單	工作區無變更，或全部被過濾	確認有 staged/unstaged 變更；用 `--exclude` 檢視排除規則
宿主 Agent 的評論行號對不上	Agent 從 merge_base 或工作區取 diff，錨定基準不一致	Step 3 明確定義取 diff 的命令（`git diff HEAD` 或 `git diff merge_base..HEAD`）
宿主 Agent 審到被排除的檔	Agent 沒用 preview 清單，自己掃了整個 repo	Step 1 把 preview 清單寫進 prompt，要求「只審此清單」
規則沒被宿主讀到	Agent 跳過 `ocr delegate rule` 輸出	把規則文本直接內嵌進宿主 prompt，而非只給命令
群組內多檔共享規則被漏審	Agent 以為「一組一條規則」等於「只審一個檔」	Step 2 明確列出每組內的檔案，要求逐檔套用規則

④ 進階挑戰題

挑戰一：寫一段給宿主 Agent 的 prompt 模板，包含「preview 清單 + 規則分組 + 強制引用程式碼片段」三要素，讓它無法「假評審」。
挑戰二：委託模式適合「訂閱制 agent」，那「自架模型 + 有預算」的團隊該不該用？畫出決策條件。
挑戰三：委託模式下，--background 還有效嗎？它在委託流程中扮演什麼角色？

① 專案級端到端 Worked Example：建構「內部 code review 代理」知識庫

情境

你們買了 30 席訂閱制 AI 編碼代理（Claude Code / Codex），不想再為 OCR 付一套 API key。你要把「所有 agent 的評審都統一走委託模式」，並把每次評審的結論累積成公司內部「code review 知識庫」，讓新同事的 agent 開箱就有前人的判斷。

Phase 1 — 部署委託 skill/command 到所有人

# 各開發者的 agent 安裝同一個委託 command
mkdir -p .claude/commands
curl -o .claude/commands/delegate-review.md \
  https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/claude-code/commands/delegate-review.md
# 或: npx skills add alibaba/open-code-review --skill open-code-review-delegate

Phase 2 — 規範「評審輸出的最小格式」（可被知識庫吸收）

# 要求每個委託評審輸出固定格式的結論檔:
# docs/reviews/<PR號>.md
# ## HIGH
# - [檔案] 驗證順序錯誤（引用片段…）
# ## MED
# - [檔案] 未驗證 user-supplied path
# ## 總結
# 一句話結論 + 是否建議合併

Phase 3 — 用 repository 當知識庫 + 定期 review 知識庫本身

# 結論檔 commit 進 docs/reviews/ → 全公司可搜尋
# 用 ocr scan --path docs/reviews --preview 確認範圍
# 每季用 ocr scan 掃「已合併但後來出事」的結論 → 校正錯誤判斷
git log --oneline --grep="revert\|hotfix" docs/reviews/ | head

Phase 4 — 把知識庫變成年資訓練素材

# 新同事 onboarding: 先讀 20 份 docs/reviews/ 再讓 agent 跑第一次委託評審
# → 新 agent 不再是「憑空猜」，而是「站在前人結論上」

為什麼選這條路徑

委託模式的「宿主 Agent 自己推理」是優點也是風險——推理品質不可控。用「固定輸出格式」把每次評審變成可累積的資產（知識庫），用「定期回掃」校正錯誤判斷，用「onboarding 讀歷史結論」讓新 agent 有脈絡。這把「省 API key」的委託模式升級成「組織記憶」——評審不再是一次性消費，而是滾動累積的判斷。

預期產出

Month 1: 30 位開發者的 agent 統一走委託模式，0 套額外 API key
Month 3: docs/reviews/ 累積 400+ 份結論，跨團隊可搜尋
Quarterly: 回掃發現 6 份「被錯誤放行」的結論 → 更新規則與知識庫標記
→ 新同事 agent 的首次評審，命中前人發現的機率明顯提升

② 效能 / 品質 / 安全深度：委託模式三面向

效能：省下的是「LLM 費用」，付的是「agent 額度」

委託模式不省總算力——它把 LLM 呼叫轉移到宿主 agent 的訂閱額度。效能考量：① ocr delegate preview 不花 agent 額度（OCR 端零 LLM），先用它確定範圍；② 委託模式的 token 效率取決於宿主 agent 的自律（它可能重複讀檔、無窮探索）——在 command 的 prompt 裡規範「只審 preview 清單」能大幅省額度；③ 固定輸出格式避免「總結報告」吃掉大量 output token。

品質：品質責任完全在宿主

委託模式沒有 REVIEW_FILTER_TASK、沒有定位模組——品質完全靠宿主 agent 自律。品質措施：① 要求「每條 HIGH/MED 附程式碼引用片段」（引不出片段＝不算數）；② 用固定輸出格式強制分級；③ 把「審完的檔案清單」列進輸出，防止「草草審完」；④ 用知識庫回掃做品質校正。

安全：宿主 agent 的權限即風險

委託評審發生在宿主 agent 的工作環境——它有檔寫權限（可能會「順手修」）。安全措施：① 委託評審預設「只讀、不回寫」（除非明確要求修復）；② 不要對 untrusted 的 repo 跑委託評審（惡意 diff 可能誘導 agent 執行）；③ 輸出結論檔含 diff 內容——docs/reviews/ 若公開，等同公開程式碼。

③ 文件間比較對照表

面向	本文（委託模式）	相關文	差異說明
誰呼叫 LLM	宿主 Agent	integrations.html	skill/command/OpenCode 工具都由 OCR 呼叫 LLM；委託是唯一「OCR 端零 LLM」的模式
評審深度	靠宿主推理，無 filter/定位模組	architecture.html	架構頁講的「評論流水線」（過濾/定位）是內建模式才有——委託模式沒有，這是取捨
品質保證	輸出格式 + 引用片段規範	benchmarks.html	benchmark 證明「內建管線」的品質；委託模式的品質是「宿主能力 + 規範」——要另做驗證
入門成本	不需 API key（省錢）	quickstart.html	quickstart 教你配 LLM 跑內建模式；委託模式跳過這步，但要求有訂閱制 agent

④ 互動式檢核清單

進階驗收：你能把委託模式變成組織級評審機制嗎？

- [ ] 能解釋委託模式「省下」與「付出」的資源分別是什麼
- [ ] 能設計一份「防假評審」的委託 prompt（含檔案清單 + 引用片段要求）
- [ ] 能定義固定輸出格式讓評審結論可被知識庫吸收
- [ ] 能防範宿主 agent「順手修復」造成的非預期寫入
- [ ] 能在 untrusted repo 上正確拒絕跑委託評審
- [ ] 能設計「結論回掃」流程校正被錯誤放行的歷史判斷