智慧體和工作流：先想清楚要不要用智慧體
智慧體是讓模型自己決定下一步做什麼。同樣三個問題，固定流程 1 次呼叫就答對了，智慧體要 3 到 4 次。講清楚兩者的區別、智慧體的代價，以及一份判斷要不要用智慧體的清單。
- 約 30 分鐘
- 難度：進階
- 實測：2026-09-14 deepseek-flash
程式碼和執行結果保留原樣（簡體中文），與實際執行時完全一致。
"智慧體"是這兩年最熱的詞之一。好像什麼東西都要做成智慧體才夠先進。
在動手之前，先想清楚一個問題：你的任務真的需要智慧體嗎？這一課先把智慧體和工作流區分清楚，再用一個實驗看看它們的代價差多少，最後給出一份判斷清單。
兩者的區別
回顧一下 RepoBot v2 回答問題的過程：改寫問題、檢索文件、把文件和問題交給模型回答。這三步是你寫死在程式碼裡的，順序固定，每次都一樣。模型只負責其中兩步裡的具體內容：改寫成什麼詞、回答什麼。這叫工作流（workflow）。
智慧體（agent）不一樣：你只給它目標和一組工具，下一步做什麼由模型決定。它可能先搜尋，發現結果不對就換個詞再搜；可能讀一個檔案，覺得不夠，再讀另一個；也可能覺得資訊夠了，直接回答。步驟的數量和順序，事先都不知道。
工作流： 智能体：
改写问题（固定） ┌─▶ 模型决定：下一步做什么？
▼ │ │
检索文档（固定） │ ┌───┴───┬────────┬────────┐
▼ │ 搜索 读文件 列目录 回答 ──▶ 结束
回答（固定） │ │ │ │
└───┴───────┴────────┘兩者之間沒有明確的界線。一個工作流裡，某一步讓模型決定"要不要檢索"，就已經有一點智慧體的意思了。更實用的問法是：控制權在誰手裡。控制權越多地交給模型，系統越靈活，也越難預測。
實驗：同樣的問題，兩種做法
用第 04 模組的 RAG 流程（改寫、混合檢索、帶引用回答）和上一課將要寫的智慧體（自己決定用 grep_docs、read_doc、list_docs 查文件），回答同樣三個問題。程式碼見 code/05-agents/workflow_vs_agent.py，我執行的結果（中間是智慧體每一步的軌跡）：
问：httpx 默认会自动跟随重定向吗？
固定流程：1 次回答调用，2.2 秒，输入 831 词元，输出 109 词元
不会。与 `requests` 不同，HTTPX 默认不跟随重定向 [1]。默认情况下，HTTPX 对所有 HTTP 方法都不会跟随重定向 [2]。
[第 1 步] grep_docs({"keyword": "follow_redirects"}) → compatibility.md:19: response = client.get(url, follow_redirects=True) | compatibility.md:
[第 1 步] grep_docs({"keyword": "redirect"}) → advanced/transports.md:178: Or this example, which uses a custom transport and `httpx.Moun
[第 2 步] read_doc({"path": "compatibility.md", "start": 8, "end": 30}) → 8: ## Redirects | 9: | 10: Unlike `requests`, HTTPX does **not follow redirects by defaul
[第 2 步] read_doc({"path": "quickstart.md", "start": 430, "end": 445}) → 430: [] | 431: >>> r.next_request | 432: <Request('GET', 'https://github.com/')> | 433: ``
智能体： 3 次调用，3.8 秒，输入 3261 词元，输出 457 词元
**不会。httpx 默认不自动跟随重定向。**
问：怎么给 httpx 设置代理？
固定流程：1 次回答调用，3.7 秒，输入 1550 词元，输出 518 词元
可以，以下是文档中提到的几种设置代理的方式。
（智能体的轨迹省略）
智能体： 4 次调用，5.8 秒，输入 6756 词元，输出 732 词元
httpx 设置代理主要有三种方式：
问：httpx 的超时分成哪几种？每种管什么？
固定流程：1 次回答调用，2.6 秒，输入 991 词元，输出 208 词元
httpx 的超时分为四种：**connect**、**read**、**write** 和 **pool** [1]。
（智能体的轨迹省略）
智能体： 3 次调用，4.1 秒，输入 3731 词元，输出 546 词元
httpx 的超时一共分成 **四种**（依据 `advanced/timeouts.md:45-61`）：（固定流程只統計了回答那一次呼叫，改寫問題的呼叫結果已經快取了。）
兩種做法都答對了三道題。但智慧體每道題要 3 到 4 次模型呼叫，輸入詞元是固定流程的 4 倍左右，耗時多一到兩秒。
原因很好理解：智慧體的每一步都要把之前所有的步驟重新發一遍。第 1 步讀了一段 grep 結果，第 2 步的輸入就包含它；第 2 步讀了兩個檔案，第 3 步的輸入就包含這兩個檔案的內容。步數越多，輸入越長。
對這類"查一個事實"的問題，一次檢索就能找到答案，智慧體的靈活性沒有用武之地，只剩下多花的錢和時間。
智慧體的代價
- 更貴、更慢。多步呼叫，上下文一步步變長。
- 不可預測。同一個問題，這次查 3 步，下次可能查 6 步；這次查對了檔案，下次可能在錯誤的方向上越走越遠。
- 難以測試和除錯。工作流每一步的輸入輸出都是確定的，可以單獨測試；智慧體的問題要翻執行軌跡才能找到。
- 風險更大。模型能自己決定呼叫工具，如果工具能修改資料、發訊息、花錢，一個錯誤的決定或者一次成功的攻擊（第 8 課）就會造成實際的後果。
智慧體的價值
智慧體值得用的地方，是那些步驟沒法事先確定的任務：
- 要查什麼，取決於前一步查到了什麼。比如排查一個報錯：先看報錯資訊，再根據報錯去找對應的原始碼，再根據原始碼去找相關的配置。
- 可能要試好幾種辦法。第一次搜尋沒找到，換個關鍵詞、換個地方再找。
- 任務的形式千變萬化，沒法為每一種寫一個固定流程。比如程式設計助手，使用者可能讓它修 bug、加功能、寫測試、改文件。
RepoBot v2 回答不了"預設最多跟隨幾次重定向"，因為答案不在文件裡，只在原始碼裡。一個固定的"檢索文件再回答"的流程，天生做不到"文件裡沒有，就去原始碼裡找"。這才是需要智慧體的地方，第 9 課會做出來。
判斷清單
在做一個新功能之前，按順序問自己：
- 一次模型呼叫能做好嗎？ 很多工，一個寫得好的提示詞加上合適的資料就夠了。能，就別往下想了。
- 步驟能事先寫死嗎？ 如果能畫出一張固定的流程圖（先 A 再 B，如果 X 就 C），就用程式碼寫成工作流。每一步可以呼叫模型，但控制流程的是你的程式碼。
- 是否必須根據中間結果決定下一步？ 如果是，而且情況多到沒法一一寫成分支，才考慮智慧體。
- 出錯的代價能不能承受？ 智慧體會犯錯。它的工具能造成什麼後果？有沒有辦法讓危險操作先經過人確認？
- 成本和延遲能不能接受？ 智慧體的一次任務可能是工作流的幾倍花費、幾倍時間。
一個實用的策略：先做成工作流，遇到它處理不了的情況，再把那一部分交給智慧體。比如 RepoBot 可以先走固定的 RAG 流程，只有檢索結果顯示"文件裡沒有"時，才啟動一個能翻原始碼的智慧體。
常見的誤區
"用了工具呼叫，就是智慧體"。第 03 模組第 3 課的程式也用了工具呼叫，但它只是"模型要查版本就查一次"，流程非常固定。有沒有工具不是關鍵，關鍵是步驟是不是由模型動態決定的。
"智慧體更高階，所以效果更好"。本課的實驗裡，三道題固定流程和智慧體都答對了，但智慧體花了四倍的錢。在步驟固定的任務上，智慧體不會更準，只會更貴、更慢、更難預測。
"先做一個通用智慧體，什麼都能幹"。工具越多、任務越寬泛，模型越容易選錯工具、走錯方向。實際專案裡更靠譜的做法是：一個智慧體只負責一類任務，給它的工具只和這類任務相關。
練習
- 在
workflow_vs_agent.py里加一個問題"httpx 預設最多跟隨幾次重定向？"（答案在原始碼裡，文件沒寫）。兩種做法分別怎麼回答？ - 回想你工作中的一項任務（比如處理客戶工單、整理週報），按本課的判斷清單走一遍，寫下你的結論：用一次呼叫、工作流還是智慧體？為什麼？這道題沒有標準答案。
自測
1. 工作流和智慧體的根本區別是什麼？
控制權在誰手裡。工作流的步驟和順序由程式碼寫死，模型只負責每一步的具體內容；智慧體只給定目標和工具，下一步做什麼由模型自己決定，步數和順序事先不知道。
2. 為什麼智慧體回答同樣的問題，輸入詞元比工作流多好幾倍？
智慧體要呼叫多次模型，每一次都要帶上之前所有的步驟：工具呼叫的請求和返回的結果。步數越多，每一步的輸入就越長，加起來比一次呼叫多得多。
3. 什麼樣的任務才值得用智慧體？
步驟沒法事先確定的任務：下一步做什麼取決於上一步的結果，可能需要多次嘗試，情況多到沒法一一寫成固定的分支。能用一次呼叫或固定流程做好的任務，不要用智慧體。