核心概念

Anthropic Applied AI 工程師 Margot Vanlar 以零售店排班系統為案例，展示從單一 prompt 到代理式架構的完整迭代過程。任務是為八名員工排一週班表，需滿足每日班次人數需求以及各種硬性約束（連續工作天數上限、休息日等）。由於有明確的硬性規則，使用 Python 函式程式化計算違規次數，而非 LLM judge。

五輪迭代的結果：

方案 配置 結果
第一輪 Sonnet 4.6 + 基礎提示詞 五案例全部失敗，模型在推理但未檢查自己的工作
第二輪 Opus 4.7 + 相同提示詞 全部失敗，違規次數大幅減少，更強推理在幫忙但不夠
第三輪 Opus 4.7 + adaptive thinking 排班開始可靠合規，但 token 用量與延遲增加約三倍
第四輪 Sonnet 4.6 + 優化提示詞 五案例兩個通過，三個因輸出限制未完成（可加大 max tokens 解決，但 token 用量比第三輪更高）
第五輪 Generate-Evaluate-Repair 代理架構 所有案例通過，token 用量與延遲低於第四輪

代理式架構的核心思路：把一個龐大提示詞拆成三個各司其職的簡單 prompt：

  • Generator：生成排班初稿
  • Evaluator：逐條規則檢查違反情況，提供具體違規證據
  • Repair：接收違規報告，做針對性修復

這三個 prompt 各自非常簡單，但它們獨立運作，而不是試圖在一個大提示詞裡完成所有事。

關鍵要點

強模型不是萬能藥

換成更強的模型（Opus 4.7）確實能減少違規，但不能保證合規。靠 adaptive thinking 讓模型自己決定推理量，可以達到可靠合規，但代價是延遲和成本大幅上升。這說明「把更大的模型砸進去」是有效果的，但不一定是最佳路徑。

提示詞優化有成本天花板

加入推理步驟指引和「輸出前檢查自己的工作」，可以讓部分案例通過——但失敗的原因不是推理錯，而是 context 用完了，來不及輸出完整排班。Prompt 優化的極限是 context 長度，而不只是模型的推理能力。

代理式架構在 token 和延遲上同時勝出

最終代理架構比單一優化 prompt 的 token 用量更低、延遲更低，卻有更高的正確率。這不是因為代理架構更「笨」，而是因為職責分離讓每個 prompt 的任務更清晰，不需要過度推理。

軟性約束可以動態加入

代理式架構的額外好處：可以在執行時動態修改 Evaluator prompt 加入軟性約束（例如「Harry 不喜歡跟 Sally 一起工作」、「週三需要第三班」），而不需要每次去改後端的 Python 評估函式。硬性約束用程式化函式計算，軟性約束留給 LLM evaluator——這兩者分開處理，互不干擾。

實務應用

判斷何時用代理式架構而非優化單一 prompt 的啟發式準則：

  1. 任務有明確的可驗證約束（硬性規則可量化）：評估器可以程式化，不依賴 LLM judge，結果更可靠
  2. 單一 prompt 的失敗模式是「來不及完成」而非「推理錯誤」：是 context 瓶頸，不是能力問題，拆分可以解決
  3. 需要彈性的軟性約束：代理架構讓 evaluator 的自然語言規則和 generator 解耦，更容易修改
  4. 三個簡單 prompt 優於一個複雜 prompt：職責愈清晰，每個步驟的輸入和輸出愈可預測

從五輪迭代的模式可以歸納：初始失敗 → 換強模型（快但貴）→ 加思考（更貴）→ 優化 prompt（有上限）→ 架構重設計（往往是最終解）。在初期就考慮架構拆分，比一輪輪調整 prompt 更有效率。

相關頁面：AI Agent 設計模式 | Prompt 遷移除錯：評估套件、結構清理與三大陷阱 | Prompt Engineering 進階技術：CoT、Few-shot 與提示鏈

反向連結

以下頁面引用了本頁：