公司沒有 ML 工程師，PM 可以自己主導設計 agent spec 嗎？

可以。Agent Spec 的核心是定義決策邊界和成功標準，不需要懂模型訓練或框架代碼。PM 需要掌握的是「在什麼情況下 agent 應該停下來請求人工確認」和「如何量化 task completion rate」，這些都是產品決策，不是技術決策。有了三層決策框架和十個必問問題，沒有 ML 背景的 PM 一樣可以主導高品質的 agent spec。

Agent Spec 和傳統 PRD 最大的差異是什麼？

PRD 描述使用者流程（確定性系統），Agent Spec 定義決策邊界（非確定性系統）。最關鍵的差異在三個部分：escalation 條件（agent 何時請求人工介入）、tool 邊界（agent 被授權使用什麼、不能碰什麼）、context 策略（agent 在每一步能看到什麼）。這三件事 PRD 不會要求你回答，但 agent 設計必須在上線前全部說清楚。

第一個 agent 專案應該從哪裡開始？

從「suggestion only」模式開始，第一版 agent 只提建議、不執行操作。先確認 task completion rate 達到目標，再按 Autonomy Ladder 升級自主度。同時確保在上線前回答八維度部署清單的所有問題，特別是 escalation 條件和錯誤恢復機制。跳過這個階段直接讓 agent 自主執行是主要失敗原因之一。

一份好的 Agent Spec 是什麼樣子？PM 設計 AI Agent 的三層決策框架

你的工程師說「agent 設計好了」，但你不知道該問什麼問題來驗證。這不是你的問題，現有的 AI agent 教學幾乎全是給工程師看的 LangGraph 代碼教學，沒有一份是給 PM 看的設計規範指南。結果是：PM 用 PRD 邏輯寫需求、工程師用技術直覺做決策、上線後才發現 escalation 條件根本沒人討論過。

這篇文章要填補這個缺口：三層決策框架讓 PM 知道自己的決策邊界在哪；八維度部署清單讓你在 sprint planning 前就能確認 spec 完整度；10 個 PM 必問問題讓你在下次 sprint review 就能用。

TL;DR

Agent 設計有三層決策：戰略層（為什麼建、誰負責）、架構層（工具/記憶/escalation）、實現層（prompt/測試/監控）。PM 主導戰略層，共同決策架構層。
好的 Agent Spec 必須在上線前回答八個維度的問題：可靠性、guardrails、成功標準、工具整合、成本/延遲、人工介入、錯誤恢復、可觀測性。
Princeton 研究顯示（via MorphLLM，原始論文尚無公開直連），有 AGENTS.md 的 agent 系統比沒有的快 28.6%、省 16.6% token，且人工撰寫比自動生成更有效。
第一版 agent 只建議不執行（suggestion only），等 task completion rate 達標再升級自主度。

PM 和工程師為什麼在 Agent 設計上雞同鴨講

傳統 PRD 框架在 agent 設計上失效，原因是根本性的：PRD 描述確定性系統，使用者做 A，系統回應 B，路徑是可窮舉的。但 agent 有自主判斷能力，等於你給了系統一個「在不確定情況下自己做決定」的授權。

這個授權的範圍如果沒有明確定義，問題不是系統會壞掉，而是系統會做出你沒預料到的決策。Mind the Product 的分析指出，agent 設計最核心的挑戰不是選哪個模型，而是定義「goals & guardrails」，這兩件事 PRD 通常不要求回答。

一個在台灣 B2B SaaS 公司做後端的工程師說得最直接：「我最怕的是 spec 上只寫『讓 agent 自動回覆客服信件』，然後沒有下文。沒有說遇到什麼情況要找人、失敗了要怎麼 fallback、可以用哪些工具、不能動哪些系統。結果我只能猜，猜錯了要改，改了 PM 說跟他想的不一樣。」猜測的成本最終由整個團隊承擔。

PM spec 最常漏掉的四個生產環境缺口：

Context engineering：agent 在每一步能看到什麼資訊、精度和格式為何
Observability：agent 的行為是否可追蹤、可調試
Guardrails：哪些操作被允許、哪些需要人工確認
Cost architecture：每次任務的 token 預算和 cost ceiling 是多少

這四個缺口都不會出現在傳統 PRD 模板裡，但 agent 上線後如果沒有答案，運維成本會遠超預期。

Agent 設計的三層決策框架

解決 PM 和工程師溝通斷點的起點，是釐清誰在哪個層次做決策。

層次	核心問題	負責人
戰略層	為什麼建這個 agent？成功標準是什麼？build vs. buy vs. configure？誰是 owner？	PM 主導
架構層	工具邊界是什麼？記憶策略（context / retrieval / external memory）？escalation 條件？autonomy level？	PM + 工程師共同決策
實現層	system prompt 設計原則？測試框架（多情境 accuracy validation）？監控指標？	工程師主導

戰略層是 PM 最關鍵的貢獻。在開始設計之前，PM 必須能清楚回答：這個 agent 解決什麼問題、不解決什麼問題、成功看起來像什麼。一位帶過多個 agent 專案的技術主管說出了缺少戰略層設計的代價：「上個月有個 PM 提案要做一個『自動分析客戶行為的 agent』，說很簡單，結果工程師估了三個月。三個月的估算裡有兩個月是在補設計決策。」

架構層是溝通最容易斷點的地方。特別是三個決策：

工具邊界：agent 被授權使用什麼工具、每個工具的限制是什麼（不能做什麼）。Anthropic 的工具設計原則指出，工具應該是「task-shaped」，不是「API-shaped」，工具邊界應該反映業務決策，不是技術實現。

記憶策略：什麼資訊應該放進當前 context（現在需要）、什麼用 retrieval 取回（偶爾需要）、什麼存在 external memory（長期保留）。Anthropic 的 context engineering 研究指出，「smallest set of high-signal tokens」原則，把所有資訊都塞進 context 是反模式，context rot 會讓 agent 性能在某個閾值後急速惡化。

Autonomy Ladder：agent 的自主程度應該從低到高漸進升級，先建議（suggest only），再部分審批（partial approval），最後才完全自主（independent）。Mind the Product 將這個路徑稱為 Autonomy Ladder，升級時機取決於 task completion rate 是否達到目標，不是時間。

好的 Agent Spec 長什麼樣：八維度部署清單

這是文章的核心 deliverable。Product School 提出的八維度部署框架，結合 Anthropic 的最佳實踐，每個維度附上 PM 可立即使用的驗證問題。

1. 可靠性測試 在 production-like 環境測試過嗎？有具體的延遲和吞吐量目標嗎（例如「250 個並發請求，P95 延遲 300ms 以內」——白話版：100 個請求裡最慢的那 5 個，要控制在 0.3 秒以內）？

2. Guardrails 哪些操作是不可逆的？這些操作有沒有 approval gate？agent 的最小權限是什麼（能做什麼、不能做什麼）？

3. 成功標準 task completion rate 的目標是多少？tool correctness 怎麼量？cost per successful task 目標是多少？Product School 強調：如果你無法清楚定義「好」是什麼，就沒辦法安全地上線。

4. 工具整合 每個工具的邊界是什麼？有 timeout、retry、backoff 策略嗎？Anthropic 指出工具設計應確保冪等性（idempotency，白話版：同一個操作執行兩次，結果要一樣——不能重複扣款或重複發信），避免重試導致重複操作。

5. 成本/延遲預算 每次任務的 token 預算是多少？cost ceiling 設在哪？超過預算的 fallback 是什麼？這個問題工程師通常不會主動問，但沒有答案就沒辦法設計 cost-aware 的 context 策略。

6. Human-in-the-loop 哪些情況觸發人工介入？交接給人時 agent 會傳遞完整 context 嗎？人工介入的 SLA 是什麼（預計多久有人回應）？

7. 錯誤恢復 失敗了怎麼 fallback？有沒有做過 tabletop drill（模擬 agent 失敗的情境演練）？rollback 機制存在嗎？

8. 監控/可觀測性 有 end-to-end trace 嗎？engineer dashboard（debugging 用）和 product dashboard（業務指標用）分開嗎？上線後第一個看什麼指標？

我們在自己的 agent fleet 裡學到的教訓：上線前沒有清楚定義「可觀測性」的後果不是系統壞掉，而是出問題時花很長時間才知道哪裡壞了。現在我們的每個 agent 都有 structured logs + trace ID，問題定位時間從「不知道多久」縮短到幾分鐘。

PM 應該問工程師的 10 個問題

這些問題工程師通常不會主動提，但你必須問。PM 最大的痛點之一是「不知道問什麼問題」，這個清單是直接的解法。

在 sprint planning 或 spec review 時，把這些問題帶進會議：

這個 agent 什麼情況下應該停下來問人（而不是自己決定）？
如果 tool call 失敗，agent 的 fallback 是什麼？
Agent 需要記住什麼？記多久？誰能清除？
我們的成功指標是什麼？task completion rate 目標是多少？
Agent 有哪些工具？每個工具的邊界是什麼（不能做什麼）？
Context 用完了怎麼辦？有 compaction 策略嗎？
Agent 怎麼知道自己做錯了？有 evaluator 嗎？
第一版上線後我們怎麼監控？看什麼指標？
有哪些操作是不可逆的？這些操作有沒有 approval gate？
我們的 agent spec 在哪裡？是 AGENTS.md 還是另外一份文件？

第 10 個問題不只是問文件在哪，而是確認 spec 文件的存在和格式。如果工程師說「在 Confluence 的某個頁面上」或「在工程師的腦袋裡」，這是一個需要解決的問題，不是可以接受的狀態。

三層規格文件：AGENTS.md / SKILL.md / DESIGN.md 的角色

2025-2026 年出現了一個業界對「如何讓 agent 行為可規格化」問題的集體解答：三層規格文件慣例。

AGENTS.md = 行為層 定義 agent 的整體 context、角色、禁止事項、操作準則。MorphLLM 引用 Princeton 研究的數據顯示：有 AGENTS.md 的 agent 系統比沒有的運行時間縮短 28.6%、token 使用降低 16.6%。更重要的發現：人工撰寫的 AGENTS.md 比自動生成更有效，自動生成的版本反而讓 agent 成功率下降 2%、成本上升 23%。

這說明 AGENTS.md 不只是給人看的規範文件，它是 agent 的 context anchor，品質直接影響 agent 行為。PM 維護一份清晰的 AGENTS.md 是可量化的技術投資。

SKILL.md = 任務層 定義可重複使用的技能和流程知識。如果 AGENTS.md 是「誰」，SKILL.md 是「怎麼做」，每個具體任務的執行步驟、判斷規則、輸出格式。

DESIGN.md = 外觀層 Google Labs 的 DESIGN.md 規範提供了機器可讀（YAML design token）加人類可讀（Markdown 設計理念）的雙軌格式，讓 AI agent 對系統的視覺設計有持久的結構化理解。

DEV Community（AWS Builders）提出的三層分工原則很實用：formally verifiable content（可被自動驗證的）寫進 spec，judgment-based content（需要上下文判斷的）保持自然語言描述。混淆這兩種內容是讓 spec 文件失效的最常見原因。

我們自己的 Shareuhack agent fleet 也是這個三層架構的實踐：CLAUDE.md 作為全局行為規範、agents/AGENTS.md 定義各 agent 角色和操作準則、.claude/skills/ 作為技能層。根據實際運行經驗，三層分工讓 agent 的行為更可預測，也讓每個 agent 在接到新任務時能快速定位自己的決策邊界。如果你想深入了解這種記憶架構設計，我們另有文章詳細說明。

如果你已經有既有 PRD，不需要從頭換框架：做法是先用八維度清單對現有 spec 做缺口盤點，只補漏掉的維度（最常缺的是 escalation 條件和 cost/latency 預算）。新的 agent 專案才從三層框架起頭；現有進行中的 PRD 不必強制 migrate，等下一個版本迭代時再補齊。

常見設計錯誤：過度工程化與其他陷阱

Business case 不清楚和風險控制不足是 agentic AI 專案失敗的主因，不是技術能力問題。這兩個原因都指向設計階段的問題，不是實現問題。

四個最常見的陷阱：

陷阱一：一開始就做 multi-agent Multi-agent 架構解決的是單一 agent 能力邊界的問題，但如果單一 agent 的能力邊界還沒測試清楚就升級，你只是把問題乘以 N 倍。Anthropic 的建議：先確認 prompt-response 是否夠用，再考慮 agent，最後才考慮 multi-agent。

陷阱二：工具太多 工具數量超過 agent 的選擇能力，反而讓 agent 更容易選錯工具。Anthropic 的工具設計原則是「consolidation over proliferation」，能合併的工具就合併，讓每個工具的邊界清晰不重疊。

陷阱三：Context 塞太滿（context rot） Anthropic 的 context engineering 研究用「context rot」描述這個現象：當 context 隨任務累積而膨脹，agent 性能下降不是線性的，而是在某個閾值後急速惡化。最常見的錯誤是把所有可能相關的資訊都放進 context，正確做法是「smallest set of high-signal tokens」。

陷阱四：沒有 escalation path 這是工程師、PM、CTO 三方共同提到的問題。工程師猜不到、PM 沒想到、上線後才發現。Productside 的「Agent Journey Map」把 escalation 設計放在任務設計之前，不是之後，原因就是這個。

解法不複雜：第一版 agent 永遠只做「suggestion only」，等指標穩定再按 Autonomy Ladder 升級。這不是保守，這是避免讓失敗的成本在生產環境才被看見。

時間參考：一份初版 Agent Spec 填完三層框架和八維度清單，通常需要 2-4 小時（包含和工程師對齊一次）。從 suggestion only 升到 partial approval 的觀察期，根據任務複雜度通常是 2-4 個 sprint——看 task completion rate 是否在目標範圍內穩定，而不是靠感覺決定。

重要：「simplicity first」和「最終升級到 multi-agent」之間不是矛盾，而是時序問題。先建最簡單的有效版本，再用數據驅動複雜度升級，這才是可持續的 agent 設計路徑。

什麼時候不應該建 agent

在決定建 agent 之前，先回答三個問題。如果三個中有兩個是「否」，你可能不需要 agent：

任務是否多步驟或有分支決策？（固定流程用 workflow 就夠）
任務是否需要工具或跨任務記憶？（單次查詢用 RAG + prompt 就夠）
執行路徑是否會隨 context 高度變化？（若路徑固定，workflow 比 agent 更可靠）

如果三個都是「是」，才值得建 agent。

Build vs. buy vs. configure 的決策維度：

客製化需求程度：現成工具能滿足 80% 需求的，先 configure；核心差異化功能才 build。
維護成本：自建 agent 的維護成本在上線後才開始，模型版本更新、API 變更、edge case 累積。現成工具的維護外包給供應商。
合規要求：如果涉及敏感資料或特定監管要求，自建可以控制資料流；現成工具的資料處理需要審查 ToS。
現有工具覆蓋率：在決定自建之前，先評估 Zapier、Make、n8n 等 no-code/low-code 工具是否已能實現需求。
團隊規模：1-2 人身兼 PM 和工程師的小團隊，優先只維護 AGENTS.md（行為層），SKILL.md 和 DESIGN.md 按需要再加。三層完整文件適合有明確 PM / 工程師分工的團隊，對小團隊來說不是 P0 項目。

同一位技術主管後來加了一條規則：任何 agent 專案開始之前，PM 必須填完三層決策框架，確認戰略層、架構層、實現層的核心問題都有答案，沒填完不能排進 sprint。這樣做讓工程師估算從「三個月補設計決策」縮短到合理範圍。

如果你正在評估 agent 的安全設計，OWASP Agentic AI 成熟度評估框架是一個有用的補充參考，特別是在 guardrails 和監控設計上。

結論

PM 的工作不是學 LangGraph，而是把「決策邊界」轉化成工程師可執行的規格。三層決策框架讓你知道自己應該決定哪些事、八維度清單讓你知道 spec 完不完整、10 個問題讓你在 sprint planning 就能對齊關鍵決策。

拿到下一份 agent 需求時的兩個路徑：

如果你是 PM，從三層決策框架開始，先確認戰略層的三個問題有答案，再把 10 個問題帶進 sprint planning；如果你是 CTO / Tech Lead，先用三條件框架判斷是否需要建 agent，確認需要後，要求 PM 在 sprint 開始前填完八維度清單，沒填完就不進 sprint。

PM 的第一步（5 分鐘版）：打開一份空白文件，寫下這三行——「這個 agent 解決什麼問題？」「它不解決什麼？」「成功是什麼樣子？」這三個問題有具體答案了，你才算完成戰略層，可以帶進工程師對齊會議了。不需要先開 AGENTS.md，不需要先選框架，就從這三個問題開始。