踐（36）：不要再寫 Agent 教程——先定義一個(gè)真實(shí)問題)
發(fā)布時(shí)間2026-08-29標(biāo)簽AI Agent工程實(shí)踐Use Case SelectionAgent Architecture上一篇AI Agent 工程實(shí)踐35我的 AI Engineering OS 最終架構(gòu)下一篇AI Agent 工程實(shí)踐37需求分析——一個(gè) Agent 項(xiàng)目到底應(yīng)該怎么拆上個(gè)月我朋友面試了一個(gè)崗位他簡歷上寫著精通 Agent 開發(fā)。面試官問他你最近做的那個(gè) Agent解決的是什么問題他說我搭了一個(gè)客服 Agent能查訂單、能退換貨、能回答物流。面試官又問那為什么不用三個(gè) API 一個(gè) if-else他愣住了。這就是我想先聊的事在寫任何 Agent 之前你真正需要回答的不是怎么做而是到底該不該做。問題背景這是「AI Agent 工程實(shí)踐」系列的第五階段也是最后一段長路。前面三十五篇我們默認(rèn)了一個(gè)前提——我們已經(jīng)決定要做一個(gè) Agent 了。然后去討論 Rules 怎么分層、Memory 怎么設(shè)計(jì)、Planner 怎么跑、Observability 怎么看。這些都對(duì)但它們都跳過了一個(gè)更早、也更致命的問題這個(gè)問題真的值得用一個(gè) Agent 來解決嗎我見過太多這樣的項(xiàng)目花了三周搭出一個(gè) Agent能調(diào)十個(gè)工具、有完整的 Memory、還上了 LangGraph最后發(fā)現(xiàn)它 90% 的工作一個(gè) 200 行的 Flask 接口就能干完而且更快、更穩(wěn)、更便宜。更糟的是這種用 Agent 解決不需要 Agent 的問題的項(xiàng)目往往不是效率問題而是可靠性災(zāi)難因?yàn)?Agent 會(huì)自由發(fā)揮把本來確定的事情做成不確定的——該返回訂單未找到的時(shí)候它可能編一個(gè)訂單已發(fā)貨。Agent 不是目的它是手段。而在你把它當(dāng)手段之前你得先證明這個(gè)手段是必要的。這一篇就是整個(gè)第五階段的地基先定義一個(gè)真實(shí)問題并證明它值得用 Agent。地基打歪了后面十五篇全是白搭。錯(cuò)誤嘗試第一次嘗試我的個(gè)人知識(shí)庫問答助手我的第一個(gè) Agent 項(xiàng)目就是典型的反面教材。我想做一個(gè)個(gè)人知識(shí)庫問答助手——喂給它一堆筆記然后問什么答什么。聽起來很 Agent 對(duì)吧它要理解我的問題、去檢索、去組織答案多有自主性。于是我上了全套向量庫、RAG、多輪對(duì)話、工具調(diào)用。結(jié)果呢絕大多數(shù)問題其實(shí)就是這篇筆記里寫了什么——一個(gè)關(guān)鍵詞搜索 原文摘錄就夠了。我精心設(shè)計(jì)的自主決策能力在 80% 的場景里完全用不上反而因?yàn)樗鼤?huì)自由發(fā)揮時(shí)不時(shí)給我編造筆記里根本不存在的結(jié)論。我當(dāng)時(shí)的判斷是技術(shù)不夠好于是繼續(xù)加 Prompt、換模型、調(diào)檢索。繞了一大圈才意識(shí)到問題根本不在技術(shù)在于——我從一開始就選錯(cuò)了問題一個(gè)確定性極高、幾乎不需要自主決策的任務(wù)硬被我套上了 Agent。第二次嘗試以為加上推理就能救活它吸取第一次教訓(xùn)后我并沒有立刻想通而是走上了一條更隱蔽的彎路給這個(gè)確定性的任務(wù)強(qiáng)行加推理環(huán)節(jié)。我想既然它是個(gè)問答任務(wù)那讓它先分析用戶意圖、再?zèng)Q定檢索策略、最后組織答案——這不就有自主性了嗎于是我加了一個(gè)意圖理解節(jié)點(diǎn)、一個(gè)檢索策略節(jié)點(diǎn)、一個(gè)答案組織節(jié)點(diǎn)。結(jié)果呢多花了 3 倍的 Token延遲從 0.8s 漲到 4s準(zhǔn)確率沒有提升因?yàn)樵瓉砟?80% 的問題根本不需要這些推理反而因?yàn)橹虚g環(huán)節(jié)變多出錯(cuò)的概率變大了這第二次失敗教會(huì)我的東西比第一次更值錢問題本身的確定性不會(huì)因?yàn)槟阍谕饷嫣赘?Agent 環(huán)節(jié)而改變。一個(gè)不需要 Agent 的任務(wù)你把它包裝得再像 Agent它依然不需要——你只是在用復(fù)雜度掩蓋判斷錯(cuò)誤。第三個(gè)觀察什么才是選對(duì)問題真正讓我開竅的是一個(gè)完全反面的對(duì)比。同樣是客服場景問訂單狀態(tài)——確定一步查庫問幫我分析為什么昨天支付失敗率暴漲——不確定要先看日志、再看監(jiān)控、再關(guān)聯(lián)部署記錄、可能還要追到具體訂單前者是 API 的活后者才是 Agent 的活。區(qū)別不在問題是不是客服相關(guān)的而在問題的結(jié)構(gòu)步驟能不能提前寫死、分支能不能提前枚舉。于是我得到了那一句貫穿全文的判斷標(biāo)準(zhǔn)。關(guān)鍵觀察痛定思痛我把該不該用 Agent這個(gè)判斷收斂成了兩個(gè)維度不確定性這個(gè)任務(wù)的每一步是不是固定的、可預(yù)測(cè)的可枚舉性這個(gè)任務(wù)的所有步驟和分支能不能提前寫清楚把這兩個(gè)維度一交叉任務(wù)就分成了四個(gè)象限quadrantChart title 任務(wù)類型四象限該用什么技術(shù) x-axis 低不確定性 -- 高不確定性 y-axis 步驟不可枚舉 -- 步驟可枚舉 quadrant-1 需要 Agent quadrant-2 需要 Workflow quadrant-3 普通 CRUD / API quadrant-4 需要 RAG 查訂單狀態(tài): [0.15, 0.85] 生成處理建議: [0.45, 0.65] 倉庫故障診斷: [0.8, 0.35] 知識(shí)庫問答: [0.55, 0.4]核心洞察一句話當(dāng)一個(gè)任務(wù)能寫清楚 SOP它就不需要 Agent。SOP標(biāo)準(zhǔn)作業(yè)流程能寫出來意味著步驟是確定的、分支是可枚舉的那它就是 Workflow 甚至 CRUD 的活。只有當(dāng)你發(fā)現(xiàn)我沒法提前把步驟寫死只能讓它在執(zhí)行中自己判斷下一步Agent 才真正登場。注意能寫清楚 SOP和看起來復(fù)雜不是一回事。一個(gè) 50 步的固定流程哪怕很長只要每步都確定它就是 Workflow一個(gè) 3 步的調(diào)查任務(wù)哪怕很短只要第 2 步該查什么要視第 1 步結(jié)果而定它就是 Agent 的活。復(fù)雜度不決定要不要 Agent確定性才決定。最終方案四象限判斷法落地成一個(gè)可操作的判斷流程。拿到一個(gè)需求先別急著開寫按順序問自己四句def choose_tech(task): if task.steps_are_fixed and task.no_external_knowledge: return CRUD / API # 場景A查訂單狀態(tài) if task.steps_are_fixed and task.need_retrieval: return RAG # 場景D知識(shí)庫問答 if task.steps_enumerable and task.low_uncertainty: return Workflow # 場景B生成處理建議 if task.high_uncertainty and task.steps_not_enumerable: return Agent # 場景C自己判斷查什么、調(diào)什么 return Agent Workflow 混合 # 大多數(shù)真實(shí)項(xiàng)目的答案用四個(gè)真實(shí)場景把這個(gè)判斷說透每個(gè)象限一個(gè)代表性案例場景用戶需求步驟能寫死嗎結(jié)論技術(shù)A查詢訂單狀態(tài)能就一步查庫返回確定性極高CRUD/APIB根據(jù)訂單、庫存、物流生成處理建議能三步查→算→出報(bào)告流程可枚舉WorkflowC分析一次支付服務(wù)異常自己判斷查什么、發(fā)現(xiàn)異常繼續(xù)查、最后給方案不能查日志還是監(jiān)控、查到哪一步算完事前不知道需要?jiǎng)討B(tài)決策AgentD在知識(shí)庫里找某篇筆記能檢索→摘錄但需要外部知識(shí)檢索型RAG場景 C 為什么是 Agent因?yàn)樗年P(guān)鍵特征是過程不確定用戶只說幫我分析昨天支付服務(wù)異常沒說查哪些系統(tǒng)、按什么順序、查到什么算結(jié)束。這些得讓 Agent 在執(zhí)行中自己判斷。這才是自主性的真正用武之地。為了強(qiáng)化這個(gè)判斷我把四種真實(shí)項(xiàng)目里常見的錯(cuò)誤選型也列出來——它們都是看起來該用 Agent實(shí)際不用的陷阱常見陷阱你以為實(shí)際正確做法報(bào)表生成要理解需求用 Agent流程固定純模板Workflow表單自動(dòng)填寫要識(shí)別字段用 Agent字段映射可枚舉Workflow 規(guī)則文檔問答要理解語義用 Agent檢索即答案不需要推理RAG定時(shí)抓取要處理異常用 Agent固定 URL 固定解析普通腳本架構(gòu)圖 / 流程圖整個(gè)判斷的決策樹畫出來是這樣注意最后兩個(gè)菱形真實(shí)項(xiàng)目很少是純 Agent或純 Workflow絕大多數(shù)是混合體——確定的步驟用代碼固定不確定的節(jié)點(diǎn)才交給 Agent。這個(gè)認(rèn)知后面第 47、48 篇會(huì)專門展開。第二張圖用 ASCII 畫同一個(gè)判斷的落地視角發(fā)布提示可用 draw.io 重畫成正式圖與 Mermaid 圖形成雙圖組合需求進(jìn)來 │ ├─ 步驟能寫死 │ ├─ 就一步 ──────────────→ [CRUD/API] 例查訂單狀態(tài) │ ├─ 需要外部知識(shí) ─────────→ [RAG] 例知識(shí)庫問答 │ └─ 多步可枚舉 ───────────→ [Workflow] 例生成處理建議 │ └─ 步驟不能寫死 └─ 需要?jiǎng)討B(tài)決策 ────────→ [Agent] 例支付異常診斷 │ └─ 發(fā)現(xiàn)部分步驟其實(shí)確定 └─→ [WorkflowAgent 混合]代碼或配置示例為了讓四象限不是空話我拿一個(gè)真實(shí)需求來做示范判斷——這也將是我整個(gè)第五階段貫穿始終的項(xiàng)目。需求做一個(gè)針對(duì)本地 Git 倉庫的診斷助手用戶問這個(gè)項(xiàng)目里支付相關(guān)邏輯在哪 / 幫我定位這個(gè) bug / 這次改動(dòng)有什么風(fēng)險(xiǎn)。# 需求 → 技術(shù)選型的判斷記錄這就是選對(duì)問題的產(chǎn)出物 requirement { name: Repo Doctor倉庫診斷 Agent, q1_steps_fixed: False, # 定位 bug 時(shí)先 grep 還是先看 git log不確定 q2_branches_enumerable: False, # 查到哪算找到無法事前寫死 q3_need_external_knowledge: True, # 需要讀代碼 git 元數(shù)據(jù) q4_uncertainty: high, # 用戶問句本身含糊需 Agent 追問/猜測(cè) } verdict choose_tech(requirement) # 輸出Agent —— 因?yàn)樵摬槭裁?、按什么順序、查到哪一步都不確定這個(gè)判斷為什么成立因?yàn)槎ㄎ?bug這件事本質(zhì)上是一個(gè)調(diào)查過程你可能先 grep 關(guān)鍵字發(fā)現(xiàn)不對(duì)再去看 git blame 找是誰改的又順藤摸瓜去看關(guān)聯(lián)文件……每一步都依賴上一步的結(jié)果沒法提前寫成固定腳本。這正是 Agent 該上場的地方。為了讓判斷記錄更可復(fù)現(xiàn)我給每個(gè)候選需求都留了一張選型卡第五階段每做一個(gè)任務(wù)都填一張# 選型卡repo_doctor/use_case.md case: name: 倉庫診斷 ask: 幫我定位這個(gè) bug / 解釋這段代碼 / 審查這次改動(dòng) steps_fixed: false # 調(diào)查路徑不可枚舉 branches_enumerable: false need_external_knowledge: true uncertainty: high verdict: agent reason: 定位 bug 是動(dòng)態(tài)調(diào)查過程路徑依賴中間結(jié)果 review_date: 2026-08-15 # 注意這個(gè) verdict 不是永久的。第 47 篇會(huì)發(fā)現(xiàn) # PR review子任務(wù)其實(shí)很確定會(huì)把它單獨(dú)退成 Workflow。設(shè)計(jì)權(quán)衡候選方案優(yōu)點(diǎn)缺點(diǎn)為什么不選硬編碼腳本CRUD快、穩(wěn)、零幻覺只能答固定問題遇到新 bug 就廢診斷的路徑無法枚舉固定 Workflow可控、可測(cè)調(diào)查型任務(wù)步驟不可枚舉查到哪算完寫不死RAG檢索代碼片段快只檢索不推理定位不了 bug 的因果鏈診斷需要推理不是找片段Agent能動(dòng)態(tài)決策調(diào)查路徑有幻覺風(fēng)險(xiǎn)、調(diào)試難、成本高調(diào)查的本質(zhì)是動(dòng)態(tài)決策只能它關(guān)鍵結(jié)論選 Agent 不是因?yàn)樗呒?jí)而是因?yàn)檫@個(gè)任務(wù)的結(jié)構(gòu)本身要求動(dòng)態(tài)決策。反過來如果哪天 Repo Doctor 里某個(gè)任務(wù)比如 PR review被證明步驟是固定的我會(huì)毫不猶豫把它退成 Workflow——這是第 47 篇的事。這里有一條誠實(shí)的邊界值得說四象限不是精確科學(xué)是判斷框架。有些任務(wù)會(huì)落在象限邊緣需要你結(jié)合錯(cuò)誤容忍度和團(tuán)隊(duì)能力來定。判斷的準(zhǔn)則只有一條選錯(cuò)了的代價(jià)是你能承受的嗎如果你不確定優(yōu)先選更簡單的方案CRUD Workflow Agent因?yàn)?Agent 的調(diào)試成本最高。常見誤區(qū)FAQQ1我的任務(wù)看起來需要理解自然語言是不是就該用 Agent不是。理解語言 ≠ 需要自主決策。知識(shí)庫問答需要理解自然語言但它是 RAG 的活。判斷標(biāo)準(zhǔn)是步驟能不能寫死不是要不要理解語言。Q2Agent 用起來更酷用它有什么壞處三個(gè)實(shí)打?qū)嵉拇鷥r(jià)① 幻覺風(fēng)險(xiǎn)編造不存在的東西② 調(diào)試?yán)щy輸出不確定難以復(fù)現(xiàn)③ 成本高每步多次 LLM 調(diào)用。這些代價(jià)只有在任務(wù)真的需要自主決策時(shí)才值得付。Q3一個(gè)任務(wù)現(xiàn)在不需要 Agent以后呢會(huì)變。任務(wù)是會(huì)演化的今天生成處理建議是固定三步 Workflow明天可能要根據(jù)庫存異常自己決定查哪些 SKU那它就滑進(jìn) Agent 區(qū)。所以選型不是一次性的要定期復(fù)審后面第 47 篇會(huì)講從 Agent 退成 Workflow的反向演化。Q4團(tuán)隊(duì)已經(jīng)搭好 Agent 了但需求其實(shí)很確定怎么辦這是最常見的現(xiàn)實(shí)架構(gòu)已經(jīng)上了發(fā)現(xiàn)選錯(cuò)了。建議不要立刻推翻而是先量一下Agent 自由發(fā)揮導(dǎo)致的錯(cuò)誤率如果錯(cuò)誤率可控、成本可接受可以繼續(xù)用如果不行把那部分確定的任務(wù)剝出來退成 Workflow——具體方法見第 47 篇?？偨Y(jié)? 寫 Agent 之前先回答到底該不該用 Agent這比怎么用更致命。? 判斷靠兩個(gè)維度不確定性 × 步驟可枚舉性交叉成四象限。? 一句話鐵律能寫清楚 SOP 的任務(wù)就不需要 Agent。? 真實(shí)項(xiàng)目大多是 Workflow Agent 混合不是純 Agent。? 我選倉庫診斷作為第五階段貫穿項(xiàng)目因?yàn)樗恼{(diào)查本質(zhì)要求動(dòng)態(tài)決策。? 選型要定期復(fù)審任務(wù)會(huì)演化Agent 和 Workflow 之間可以雙向流動(dòng)。參考資料Anthropic《Building Effective Agents》→ 為什么引用它最早把 Workflow 和 Agent 分開提出簡單優(yōu)先原則是四象限判斷的源頭。LangGraph 官方文檔 → 為什么引用確認(rèn)了 Workflow 與 Agent 在工程實(shí)現(xiàn)上的邊界支撐混合體的結(jié)論。系列導(dǎo)航上一篇AI Agent 工程實(shí)踐35我的 AI Engineering OS 最終架構(gòu)下一篇AI Agent 工程實(shí)踐37需求分析——一個(gè) Agent 項(xiàng)目到底應(yīng)該怎么拆本文是 [AI Agent 工程實(shí)踐] 系列的第 36 篇也是第五階段「從 Demo 到 Production」的第一篇。 AI Agent 工程實(shí)踐（36）：不要再寫 Agent 教程——先定義一個(gè)真實(shí)問題
發(fā)布時(shí)間2026-08-29標(biāo)簽AI Agent工程實(shí)踐Use Case SelectionAgent Architecture上一篇AI Agent 工程實(shí)踐35我的 AI Engineering OS 最終架構(gòu)下一篇AI Agent 工程實(shí)踐37需求分析——一個(gè) Agent 項(xiàng)目到底應(yīng)該怎么拆上個(gè)月我朋友面試了一個(gè)崗位他簡歷上寫著精通 Agent 開發(fā)。面試官問他你最近做的那個(gè) Agent解決的是什么問題他說我搭了一個(gè)客服 Agent能查訂單、能退換貨、能回答物流。面試官又問那為什么不用三個(gè) API 一個(gè) if-else他愣住了。這就是我想先聊的事在寫任何 Agent 之前你真正需要回答的不是怎么做而是到底該不該做。問題背景這是「AI Agent 工程實(shí)踐」系列的第五階段也是最后一段長路。前面三十五篇我們默認(rèn)了一個(gè)前提——我們已經(jīng)決定要做一個(gè) Agent 了。然后去討論 Rules 怎么分層、Memory 怎么設(shè)計(jì)、Planner 怎么跑、Observability 怎么看。這些都對(duì)但它們都跳過了一個(gè)更早、也更致命的問題這個(gè)問題真的值得用一個(gè) Agent 來解決嗎我見過太多這樣的項(xiàng)目花了三周搭出一個(gè) Agent能調(diào)十個(gè)工具、有完整的 Memory、還上了 LangGraph最后發(fā)現(xiàn)它 90% 的工作一個(gè) 200 行的 Flask 接口就能干完而且更快、更穩(wěn)、更便宜。更糟的是這種用 Agent 解決不需要 Agent 的問題的項(xiàng)目往往不是效率問題而是可靠性災(zāi)難因?yàn)?Agent 會(huì)自由發(fā)揮把本來確定的事情做成不確定的——該返回訂單未找到的時(shí)候它可能編一個(gè)訂單已發(fā)貨。Agent 不是目的它是手段。而在你把它當(dāng)手段之前你得先證明這個(gè)手段是必要的。這一篇就是整個(gè)第五階段的地基先定義一個(gè)真實(shí)問題并證明它值得用 Agent。地基打歪了后面十五篇全是白搭。錯(cuò)誤嘗試第一次嘗試我的個(gè)人知識(shí)庫問答助手我的第一個(gè) Agent 項(xiàng)目就是典型的反面教材。我想做一個(gè)個(gè)人知識(shí)庫問答助手——喂給它一堆筆記然后問什么答什么。聽起來很 Agent 對(duì)吧它要理解我的問題、去檢索、去組織答案多有自主性。于是我上了全套向量庫、RAG、多輪對(duì)話、工具調(diào)用。結(jié)果呢絕大多數(shù)問題其實(shí)就是這篇筆記里寫了什么——一個(gè)關(guān)鍵詞搜索 原文摘錄就夠了。我精心設(shè)計(jì)的自主決策能力在 80% 的場景里完全用不上反而因?yàn)樗鼤?huì)自由發(fā)揮時(shí)不時(shí)給我編造筆記里根本不存在的結(jié)論。我當(dāng)時(shí)的判斷是技術(shù)不夠好于是繼續(xù)加 Prompt、換模型、調(diào)檢索。繞了一大圈才意識(shí)到問題根本不在技術(shù)在于——我從一開始就選錯(cuò)了問題一個(gè)確定性極高、幾乎不需要自主決策的任務(wù)硬被我套上了 Agent。第二次嘗試以為加上推理就能救活它吸取第一次教訓(xùn)后我并沒有立刻想通而是走上了一條更隱蔽的彎路給這個(gè)確定性的任務(wù)強(qiáng)行加推理環(huán)節(jié)。我想既然它是個(gè)問答任務(wù)那讓它先分析用戶意圖、再?zèng)Q定檢索策略、最后組織答案——這不就有自主性了嗎于是我加了一個(gè)意圖理解節(jié)點(diǎn)、一個(gè)檢索策略節(jié)點(diǎn)、一個(gè)答案組織節(jié)點(diǎn)。結(jié)果呢多花了 3 倍的 Token延遲從 0.8s 漲到 4s準(zhǔn)確率沒有提升因?yàn)樵瓉砟?80% 的問題根本不需要這些推理反而因?yàn)橹虚g環(huán)節(jié)變多出錯(cuò)的概率變大了這第二次失敗教會(huì)我的東西比第一次更值錢問題本身的確定性不會(huì)因?yàn)槟阍谕饷嫣赘?Agent 環(huán)節(jié)而改變。一個(gè)不需要 Agent 的任務(wù)你把它包裝得再像 Agent它依然不需要——你只是在用復(fù)雜度掩蓋判斷錯(cuò)誤。第三個(gè)觀察什么才是選對(duì)問題真正讓我開竅的是一個(gè)完全反面的對(duì)比。同樣是客服場景問訂單狀態(tài)——確定一步查庫問幫我分析為什么昨天支付失敗率暴漲——不確定要先看日志、再看監(jiān)控、再關(guān)聯(lián)部署記錄、可能還要追到具體訂單前者是 API 的活后者才是 Agent 的活。區(qū)別不在問題是不是客服相關(guān)的而在問題的結(jié)構(gòu)步驟能不能提前寫死、分支能不能提前枚舉。于是我得到了那一句貫穿全文的判斷標(biāo)準(zhǔn)。關(guān)鍵觀察痛定思痛我把該不該用 Agent這個(gè)判斷收斂成了兩個(gè)維度不確定性這個(gè)任務(wù)的每一步是不是固定的、可預(yù)測(cè)的可枚舉性這個(gè)任務(wù)的所有步驟和分支能不能提前寫清楚把這兩個(gè)維度一交叉任務(wù)就分成了四個(gè)象限quadrantChart title 任務(wù)類型四象限該用什么技術(shù) x-axis 低不確定性 -- 高不確定性 y-axis 步驟不可枚舉 -- 步驟可枚舉 quadrant-1 需要 Agent quadrant-2 需要 Workflow quadrant-3 普通 CRUD / API quadrant-4 需要 RAG 查訂單狀態(tài): [0.15, 0.85] 生成處理建議: [0.45, 0.65] 倉庫故障診斷: [0.8, 0.35] 知識(shí)庫問答: [0.55, 0.4]核心洞察一句話當(dāng)一個(gè)任務(wù)能寫清楚 SOP它就不需要 Agent。SOP標(biāo)準(zhǔn)作業(yè)流程能寫出來意味著步驟是確定的、分支是可枚舉的那它就是 Workflow 甚至 CRUD 的活。只有當(dāng)你發(fā)現(xiàn)我沒法提前把步驟寫死只能讓它在執(zhí)行中自己判斷下一步Agent 才真正登場。注意能寫清楚 SOP和看起來復(fù)雜不是一回事。一個(gè) 50 步的固定流程哪怕很長只要每步都確定它就是 Workflow一個(gè) 3 步的調(diào)查任務(wù)哪怕很短只要第 2 步該查什么要視第 1 步結(jié)果而定它就是 Agent 的活。復(fù)雜度不決定要不要 Agent確定性才決定。最終方案四象限判斷法落地成一個(gè)可操作的判斷流程。拿到一個(gè)需求先別急著開寫按順序問自己四句def choose_tech(task): if task.steps_are_fixed and task.no_external_knowledge: return CRUD / API # 場景A查訂單狀態(tài) if task.steps_are_fixed and task.need_retrieval: return RAG # 場景D知識(shí)庫問答 if task.steps_enumerable and task.low_uncertainty: return Workflow # 場景B生成處理建議 if task.high_uncertainty and task.steps_not_enumerable: return Agent # 場景C自己判斷查什么、調(diào)什么 return Agent Workflow 混合 # 大多數(shù)真實(shí)項(xiàng)目的答案用四個(gè)真實(shí)場景把這個(gè)判斷說透每個(gè)象限一個(gè)代表性案例場景用戶需求步驟能寫死嗎結(jié)論技術(shù)A查詢訂單狀態(tài)能就一步查庫返回確定性極高CRUD/APIB根據(jù)訂單、庫存、物流生成處理建議能三步查→算→出報(bào)告流程可枚舉WorkflowC分析一次支付服務(wù)異常自己判斷查什么、發(fā)現(xiàn)異常繼續(xù)查、最后給方案不能查日志還是監(jiān)控、查到哪一步算完事前不知道需要?jiǎng)討B(tài)決策AgentD在知識(shí)庫里找某篇筆記能檢索→摘錄但需要外部知識(shí)檢索型RAG場景 C 為什么是 Agent因?yàn)樗年P(guān)鍵特征是過程不確定用戶只說幫我分析昨天支付服務(wù)異常沒說查哪些系統(tǒng)、按什么順序、查到什么算結(jié)束。這些得讓 Agent 在執(zhí)行中自己判斷。這才是自主性的真正用武之地。為了強(qiáng)化這個(gè)判斷我把四種真實(shí)項(xiàng)目里常見的錯(cuò)誤選型也列出來——它們都是看起來該用 Agent實(shí)際不用的陷阱常見陷阱你以為實(shí)際正確做法報(bào)表生成要理解需求用 Agent流程固定純模板Workflow表單自動(dòng)填寫要識(shí)別字段用 Agent字段映射可枚舉Workflow 規(guī)則文檔問答要理解語義用 Agent檢索即答案不需要推理RAG定時(shí)抓取要處理異常用 Agent固定 URL 固定解析普通腳本架構(gòu)圖 / 流程圖整個(gè)判斷的決策樹畫出來是這樣注意最后兩個(gè)菱形真實(shí)項(xiàng)目很少是純 Agent或純 Workflow絕大多數(shù)是混合體——確定的步驟用代碼固定不確定的節(jié)點(diǎn)才交給 Agent。這個(gè)認(rèn)知后面第 47、48 篇會(huì)專門展開。第二張圖用 ASCII 畫同一個(gè)判斷的落地視角發(fā)布提示可用 draw.io 重畫成正式圖與 Mermaid 圖形成雙圖組合需求進(jìn)來 │ ├─ 步驟能寫死 │ ├─ 就一步 ──────────────→ [CRUD/API] 例查訂單狀態(tài) │ ├─ 需要外部知識(shí) ─────────→ [RAG] 例知識(shí)庫問答 │ └─ 多步可枚舉 ───────────→ [Workflow] 例生成處理建議 │ └─ 步驟不能寫死 └─ 需要?jiǎng)討B(tài)決策 ────────→ [Agent] 例支付異常診斷 │ └─ 發(fā)現(xiàn)部分步驟其實(shí)確定 └─→ [WorkflowAgent 混合]代碼或配置示例為了讓四象限不是空話我拿一個(gè)真實(shí)需求來做示范判斷——這也將是我整個(gè)第五階段貫穿始終的項(xiàng)目。需求做一個(gè)針對(duì)本地 Git 倉庫的診斷助手用戶問這個(gè)項(xiàng)目里支付相關(guān)邏輯在哪 / 幫我定位這個(gè) bug / 這次改動(dòng)有什么風(fēng)險(xiǎn)。# 需求 → 技術(shù)選型的判斷記錄這就是選對(duì)問題的產(chǎn)出物 requirement { name: Repo Doctor倉庫診斷 Agent, q1_steps_fixed: False, # 定位 bug 時(shí)先 grep 還是先看 git log不確定 q2_branches_enumerable: False, # 查到哪算找到無法事前寫死 q3_need_external_knowledge: True, # 需要讀代碼 git 元數(shù)據(jù) q4_uncertainty: high, # 用戶問句本身含糊需 Agent 追問/猜測(cè) } verdict choose_tech(requirement) # 輸出Agent —— 因?yàn)樵摬槭裁?、按什么順序、查到哪一步都不確定這個(gè)判斷為什么成立因?yàn)槎ㄎ?bug這件事本質(zhì)上是一個(gè)調(diào)查過程你可能先 grep 關(guān)鍵字發(fā)現(xiàn)不對(duì)再去看 git blame 找是誰改的又順藤摸瓜去看關(guān)聯(lián)文件……每一步都依賴上一步的結(jié)果沒法提前寫成固定腳本。這正是 Agent 該上場的地方。為了讓判斷記錄更可復(fù)現(xiàn)我給每個(gè)候選需求都留了一張選型卡第五階段每做一個(gè)任務(wù)都填一張# 選型卡repo_doctor/use_case.md case: name: 倉庫診斷 ask: 幫我定位這個(gè) bug / 解釋這段代碼 / 審查這次改動(dòng) steps_fixed: false # 調(diào)查路徑不可枚舉 branches_enumerable: false need_external_knowledge: true uncertainty: high verdict: agent reason: 定位 bug 是動(dòng)態(tài)調(diào)查過程路徑依賴中間結(jié)果 review_date: 2026-08-15 # 注意這個(gè) verdict 不是永久的。第 47 篇會(huì)發(fā)現(xiàn) # PR review子任務(wù)其實(shí)很確定會(huì)把它單獨(dú)退成 Workflow。設(shè)計(jì)權(quán)衡候選方案優(yōu)點(diǎn)缺點(diǎn)為什么不選硬編碼腳本CRUD快、穩(wěn)、零幻覺只能答固定問題遇到新 bug 就廢診斷的路徑無法枚舉固定 Workflow可控、可測(cè)調(diào)查型任務(wù)步驟不可枚舉查到哪算完寫不死RAG檢索代碼片段快只檢索不推理定位不了 bug 的因果鏈診斷需要推理不是找片段Agent能動(dòng)態(tài)決策調(diào)查路徑有幻覺風(fēng)險(xiǎn)、調(diào)試難、成本高調(diào)查的本質(zhì)是動(dòng)態(tài)決策只能它關(guān)鍵結(jié)論選 Agent 不是因?yàn)樗呒?jí)而是因?yàn)檫@個(gè)任務(wù)的結(jié)構(gòu)本身要求動(dòng)態(tài)決策。反過來如果哪天 Repo Doctor 里某個(gè)任務(wù)比如 PR review被證明步驟是固定的我會(huì)毫不猶豫把它退成 Workflow——這是第 47 篇的事。這里有一條誠實(shí)的邊界值得說四象限不是精確科學(xué)是判斷框架。有些任務(wù)會(huì)落在象限邊緣需要你結(jié)合錯(cuò)誤容忍度和團(tuán)隊(duì)能力來定。判斷的準(zhǔn)則只有一條選錯(cuò)了的代價(jià)是你能承受的嗎如果你不確定優(yōu)先選更簡單的方案CRUD Workflow Agent因?yàn)?Agent 的調(diào)試成本最高。常見誤區(qū)FAQQ1我的任務(wù)看起來需要理解自然語言是不是就該用 Agent不是。理解語言 ≠ 需要自主決策。知識(shí)庫問答需要理解自然語言但它是 RAG 的活。判斷標(biāo)準(zhǔn)是步驟能不能寫死不是要不要理解語言。Q2Agent 用起來更酷用它有什么壞處三個(gè)實(shí)打?qū)嵉拇鷥r(jià)① 幻覺風(fēng)險(xiǎn)編造不存在的東西② 調(diào)試?yán)щy輸出不確定難以復(fù)現(xiàn)③ 成本高每步多次 LLM 調(diào)用。這些代價(jià)只有在任務(wù)真的需要自主決策時(shí)才值得付。Q3一個(gè)任務(wù)現(xiàn)在不需要 Agent以后呢會(huì)變。任務(wù)是會(huì)演化的今天生成處理建議是固定三步 Workflow明天可能要根據(jù)庫存異常自己決定查哪些 SKU那它就滑進(jìn) Agent 區(qū)。所以選型不是一次性的要定期復(fù)審后面第 47 篇會(huì)講從 Agent 退成 Workflow的反向演化。Q4團(tuán)隊(duì)已經(jīng)搭好 Agent 了但需求其實(shí)很確定怎么辦這是最常見的現(xiàn)實(shí)架構(gòu)已經(jīng)上了發(fā)現(xiàn)選錯(cuò)了。建議不要立刻推翻而是先量一下Agent 自由發(fā)揮導(dǎo)致的錯(cuò)誤率如果錯(cuò)誤率可控、成本可接受可以繼續(xù)用如果不行把那部分確定的任務(wù)剝出來退成 Workflow——具體方法見第 47 篇?？偨Y(jié)? 寫 Agent 之前先回答到底該不該用 Agent這比怎么用更致命。? 判斷靠兩個(gè)維度不確定性 × 步驟可枚舉性交叉成四象限。? 一句話鐵律能寫清楚 SOP 的任務(wù)就不需要 Agent。? 真實(shí)項(xiàng)目大多是 Workflow Agent 混合不是純 Agent。? 我選倉庫診斷作為第五階段貫穿項(xiàng)目因?yàn)樗恼{(diào)查本質(zhì)要求動(dòng)態(tài)決策。? 選型要定期復(fù)審任務(wù)會(huì)演化Agent 和 Workflow 之間可以雙向流動(dòng)。參考資料Anthropic《Building Effective Agents》→ 為什么引用它最早把 Workflow 和 Agent 分開提出簡單優(yōu)先原則是四象限判斷的源頭。LangGraph 官方文檔 → 為什么引用確認(rèn)了 Workflow 與 Agent 在工程實(shí)現(xiàn)上的邊界支撐混合體的結(jié)論。系列導(dǎo)航上一篇AI Agent 工程實(shí)踐35我的 AI Engineering OS 最終架構(gòu)下一篇AI Agent 工程實(shí)踐37需求分析——一個(gè) Agent 項(xiàng)目到底應(yīng)該怎么拆本文是 [AI Agent 工程實(shí)踐] 系列的第 36 篇也是第五階段「從 Demo 到 Production」的第一篇。