工具推薦｜cedr — 依剩餘額度自動分案給 AI coding agent，順手鎖住 MCP server 清單防被偷換

🌏 English version

工具資訊

解決什麼問題

你如果同時開著 Claude Code、Codex、Cursor 幾個 AI coding agent 的訂閱，每次指派任務前都得自己想一次「哪個額度還夠用、哪個適合這種工作」，想錯了就是某個 plan 提前用完，剩下的時間只能乾等重置。review 階段也類似——同時跑兩三家廠商的 code review bot，每次都要自己看完幾份報告、判斷哪些是真問題、該不該放行，其實每次都在重做一樣的合併工作。更隱蔽的是第三個問題：你核准 agent 使用的 skill 跟 MCP server，通常只在第一次裝的時候被看過一次，之後它的工具清單、描述、連去的網域有沒有被偷偷換掉，沒有人會再檢查——這正是 Invariant Labs 在 2025 年描述過的 MCP「tool poisoning」風險的日常版本。

cedr 用一個 CLI 把這三件事收進同一套工具。Route 讀你寫在 routes.toml 的規則，配合各 agent 自己回報的額度（例如把 cedr route statusline 設成 Claude Code 的狀態列，就能讀到即時用量），同等適合的工作會分給剩餘額度最多的那個 plan，快用完的 plan 會被自動跳過。Council 幫每個廠商各開一個 reviewer，把回來的報告合併、把指向同一處的發現歸成一組，再決定整批放行還是擋下——任何 P0 或 P1 都會擋，報告數量不夠也絕不會悄悄放行。Guard（目前還是 preview）替你的 agent 設定做檢查，把每個 skill 跟 MCP server 的工具、描述、連去的網域鎖進 cedr.lock，之後只要有任何一項跟鎖定時不一樣，cedr verify 就會在 CI 裡失敗。三者共用同一個二進位檔，cedr mcp 可以把 Route 和 Council 開成 MCP server，讓任何支援 MCP 的 agent 直接呼叫。

適合本來就同時訂多個 AI coding agent、常常要人工猜「這個任務該給誰做」的人，或是已經在跑多廠商 review bot、想把判斷流程收斂成一個 gate 決策的團隊。如果你只用一個 agent、一個 plan，Route 跟 Council 幫不上忙；但單獨跑 Guard 的 cedr lock 把現有的 skill／MCP 清單鎖起來，對任何人都是幾分鐘就能做的事。

快速上手

安裝

# Linux x86_64，其他平台把檔名換成對應的 archive
curl -fsSL https://github.com/Sheernox/cedr/releases/latest/download/cedr-x86_64-unknown-linux-gnu.tar.gz | tar -xz
install -m 755 cedr-x86_64-unknown-linux-gnu/cedr ~/.local/bin/cedr
cedr --version

# 或從原始碼編譯（需要現版 Rust toolchain）
cargo install --locked --git https://github.com/Sheernox/cedr cedr

基本用法

# ~/.config/cedr/routes.toml
version = 1

[orchestrator]       # 你實際工作的 agent，保留不該分給別人的工作
harness = "claude"
model = "opus"

[harnesses.claude]
expect = ["five_hour", "seven_day"]
effort_option = "effort"

[[readings]]          # plan 用量從哪裡讀
kind = "claude-statusline"
harness = "claude"

[routes."review.code"]
work = "Independent review"
role = "review"
candidates = [
  { target = "codex/sol", effort = "high", tier = 1 },
  { target = "claude/sonnet", effort = "high", tier = 1 },
]

cedr route pick review.code        # 依目前各 plan 剩餘額度選一個候選
cedr route pools                   # 看每個 plan 還剩多少額度
cedr route verdict <id> accepted   # 記錄這次挑選的結果，累積統計用

進階用法（選填）

cedr lock    # 把目前核准的 skill 和 MCP server 鎖進 cedr.lock（要連進 MCP server 讀工具清單，得加 --introspect，執行前會先警告）
cedr verify  # 離線比對目前設定跟 cedr.lock，有漂移就以非零結束
cedr mcp     # 把 Route／Council 的工具開成 MCP server，給任何支援 MCP 的 agent 呼叫

在 CI 裡跑 cedr verify，一旦某個 MCP server 改了工具清單或換了連去的網域，流程就會在合併前失敗，而不是等 agent 真的呼叫到被動過手腳的工具才發現。

與現有工具的比較

cedr 的 Route 跟 Council 目前沒有直接對應的對照組——多代理人調度多半還是人工判斷，多廠商 review 合併也很少有工具專門做。比較明確的對照組是 Guard 這塊「MCP 工具清單鎖定」，同一個生態圈裡專門做這件事的工具是 mcp-warden（2026-06 建立）：

mcp-warden 自己的文件寫得很清楚：它驗證的是 tools/list／resources/list／prompts/list 回報的「宣告」有沒有變，不是完整的 agent 防火牆，也不防行為層的攻擊——這句警語同樣適用於 cedr 的 Guard。兩者都只能告訴你「清單跟你上次核准的不一樣了」，不能告訴你新清單是不是真的危險，要不要重新核准還是得由人判斷。只在意 MCP 供應鏈這一件事，mcp-warden 的 guard proxy 多做了執行期攔截；還想把多代理人路由跟多廠商 review 收進同一個 CLI，cedr 多做了這兩塊。

注意事項

• 還在 preview：README 自己寫明指令跟檔案格式在 1.0 之前都可能改，routes.toml 這種設定檔之後升版有可能要跟著調整。
• 只鎖「宣告」，不防行為攻擊：跟 mcp-warden 一樣，cedr lock／cedr verify 比對的是 MCP server 回報的工具清單跟描述，工具清單沒變但回傳內容被動過手腳的攻擊不在它的偵測範圍。
• cedr lock 預設不會連進 MCP server：要讀即時工具清單得加 --introspect，執行前會先警告，避免在不知情的狀況下觸發一次 MCP 連線。
• 多機器／團隊共用路由紀錄才需要帳號：Route／Council／Guard 全部在本機跑、不需要帳號；只有 cedr route sync 要把挑選紀錄和路由設定同步到 cedr.dev 團隊，才需要在 [sync] 區塊填 API key。
• 剛建立，還沒有外部使用回饋：2026-10-30 才建立的 repo，目前 30 stars、0 個 open issue，README 和文件完整，但還沒有大規模使用後才會浮現的問題可以參考。

今日收穫

多代理人、多廠商 review 變成日常用法之後，「這個任務該給誰做」「這三份 review 報告到底要不要放行」本來都是人工判斷，cedr 把它們收進同一個設定檔和 CLI，走的是跟上游 CI 工具一樣的路——先用規則取代直覺判斷，有爭議再回頭調規則。MCP 的 tool poisoning 風險，之前大多是研究者在文章裡描述，現在開始有獨立團隊各自用「lockfile」這個熟悉的比喻做出對應的檢查工具，說明這已經從「理論風險」變成有人覺得值得花時間寫 CLI 解決的日常問題。

參考資料

• Sheernox/cedr — GitHub
• cedr README（raw）
• cedr.dev 官方文件
• DataScience-EngineeringExperts/mcp-warden — GitHub（比較對象）
• mcp-warden README（raw，比較對象）
• Model Context Protocol — Wikipedia（MCP 背景與 tool poisoning 脈絡）