寫於 2026 年 8 月 20 至 21 日（補 8 月 20 日的排程），9 月才上線（部落格的發佈額度在 8 月中用完了，稿子積壓了三週）。文中對 Amp 的描述以 8 月 20 日的官方 manual 為準，你讀到時文件可能已經改版。

先問你自己一個問題：你上次卡在同一個 bug 上超過兩輪的時候，做了什麼？

我猜大部分人的答案是「再叫它試一次」。這個答案很自然，也是最貴的那個：同一個模型、同一份被污染的 context，第三次給出的答案跟前兩次同源。

Amp（Sourcegraph 做的 coding agent）把這件事做成了產品裡的一個工具。它叫 oracle。

它是什麼

manual 的原文：

Amp has access to a powerful “second opinion” model that’s better suited for complex reasoning or analysis tasks, at the cost of being slightly slower, slightly more expensive, and less suited to day-to-day code editing tasks than the main agent’s model.

一個更會推理、但更慢更貴、而且不適合日常改碼的模型，透過名為 oracle 的工具給主 agent 用。

有意思的是路由規則。同樣一份 manual 寫著，oracle 用哪個模型取決於你的 agent 模式、你連了哪些模型供應商的訂閱、workspace 限制與模型可用性。具體來說：

In high mode without a connected ChatGPT subscription, Oracle currently uses Claude Fable 5 with high reasoning. With a connected ChatGPT subscription, it uses GPT-5.6 Sol with high reasoning to maximize use of that subscription. The main High agent currently uses GPT-5.6 Sol with x-high reasoning in both cases.

同一個 oracle 工具，你連了 ChatGPT 訂閱它就走 GPT-5.6 Sol，沒連就走 Claude Fable 5。主 agent 兩種情況都是 GPT-5.6 Sol，只差 reasoning 檔位。

這個設計的動機寫得很白：maximize use of that subscription。它在幫你把已經付掉的錢用完。

模式那邊也不是給你選模型，是給你轉一個刻度。原文四個模式：low（快、便宜，處理小而明確的任務）、medium（預設，平衡品質速度成本）、high（難的任務，能忍受更多時間與成本）、ultra（最難的開放式任務，能力比速度與成本重要）。

你決定這件事值多少資源。它決定用誰。

最誠實的一句在後面

The main agent can autonomously decide to ask the oracle for help when debugging or reviewing a complex piece of code. We intentionally do not force the main agent to always use the oracle, due to higher costs and slower inference speed.

刻意不強制。理由是成本與延遲。

這句話值得停一下。一個把 oracle 當賣點的產品，在自己的手冊裡告訴你「我們故意不讓它每次都用」，這比「我們的第二意見隨時保護你」誠實得多，也比較符合實際：每次都叫第二意見，等於把每個決策的成本乘以二點多倍，而大部分決策根本不需要。

實務上（這段是第三方使用心得，不是官方文件）多數人是直接跟 agent 說「去問 oracle」來手動觸發。另外有人做過 system prompt 的考古，指出 oracle 歷史上拿到的工具比主 agent 少，大致是讀取、搜尋、抓網頁那一組，沒有寫入。這點我沒在官方 manual 裡看到對應句子，所以當成傳聞看，不要當設計保證。

Claude Code 這邊沒有對等物

Claude Code 沒有內建的「第二意見」工具。你想要同一個效果，有三條路。

第一條是派 subagent，在 Agent tool 呼叫時指定 model。缺點是每次都要自己想該用哪個，而且 subagent 是通用的，不是為「挑戰現有結論」設計的。

第二條是自己寫 agent 定義檔，把 model 與唯讀工具集綁在一個具名角色上。這其實就是我昨天寫的那個專案在做的事（pilotfish 把模型綁死在八個角色上，然後花最多篇幅叫你不要派工），它的 verifier 與 plan-verifier 兩個角色本質上就是手工打造的 oracle，而且用 frontmatter 的 tools 白名單強制唯讀。

第三條是裝外掛，讓另一家的模型來審。我四月寫過 OpenAI 官方的那個（Codex Plugin for Claude Code），跨供應商的第二意見，/codex:review 一行帶走。

三條路都通。差別在誰維護那份「什麼時候該叫」的判斷。

兩邊的差異其實在一句話

Amp 把判斷收進產品：你轉刻度，它決定模型，主 agent 自己決定要不要問 oracle。

Claude Code 把判斷留給你：模型參數、agent 定義檔、外掛，全部是你的組合題。

哪個好，取決於一件事——你到底有沒有那套判斷。

如果你已經知道自己的工作裡什麼算高風險、什麼算機械勞動，那 Claude Code 的做法是純粹的好處：你可以把「schema 遷移一定要唯讀角色先審」這種規則寫死，不必祈禱產品猜對。

如果你沒有那套判斷，Claude Code 給你的自由度會變成負債。你會每次都用最強的模型「保險一下」，最後付了 ultra 的錢做 low 的事。這種時候 Amp 幫你決定反而划算。

什麼情況下第二意見反而是壞選擇

這是我覺得比「怎麼用」更值得想的一面。

你還沒定位根因的時候。 換一個更聰明的模型看同一份沒有證據的問題，得到的是更有說服力的猜測，不是答案。第二意見要在有證據之後才值錢，它的價值是挑戰你的推論，不是替你找線索。

你只是想有人同意你的時候。 這個最難自己察覺。你去問第二意見，心裡已經有答案，然後把它的回覆讀成背書。要避開這個，問法要改成「找出這個方案會失敗的理由」，而不是「你覺得這樣可以嗎」。

每一次都問的時候。 Amp 自己講了成本與延遲。同樣的話換個講法：如果第二意見從不推翻你，它就沒有在工作，你付的是心安的錢；如果它常常推翻你，那你該回頭修的是第一意見的產生方式，不是加一層審查。

改一個 typo 的時候。 這聽起來像廢話，但實際上很多人的自動化流程就是所有變更走同一條 pipeline。風險決定要不要獨立審查，檔案數量不決定。

所以我會怎麼選

不騎牆講清楚：如果你像我一樣已經有一套派工與審查的紀律，Claude Code 的機制路線更值得投資，因為那套紀律是你的資產，寫成 agent 檔跟政策文字之後每個 session 自動生效，而且不會因為某家產品改了路由規則而失效。

反過來，如果你現在的狀態是「每次都開最強的模型然後祈禱」，那 Amp 這種把判斷收進產品的做法，會比你自己亂調划算。至少它的取捨是被人想過一遍的。

有一個東西兩邊都值得抄：oracle 這個名字取得很好。它不叫 reviewer，不叫 validator，叫 oracle——你去問，它回答，它不替你做決定，也不替你負責。你手上那個結論的責任還在你身上，這件事沒有任何一個模型接得走。

我沒驗證的部分

我沒有用過 Amp。這篇的官方描述全部來自 8 月 20 日 ampcode.com/manual 的原文，模式與 oracle 路由那幾段是逐字引的；oracle 工具權限受限那段是第三方的 system prompt 考古，我沒有在官方文件裡找到對應句子。Amp 的模型路由跟訂閱綁定，所以你實際看到的模型很可能跟我引的不一樣。

Claude Code 那三條路我自己都跑過，subagent 綁 model 與 codex 外掛是日常在用的，agent 定義檔綁唯讀工具集則是站上另外那篇文章的專案在做的事，我讀過原始碼但沒安裝過它。

來源