Learning Objectives
- 用 while 迴圈和步數上限寫出 Agent：呼叫模型、執行工具、放回結果、直到模型不再要工具
- 說明 Agent 需要哪些停止條件：模型講完、步數上限、token 預算、重複呼叫
- 累計每一輪的 usage，說明對話變長時費用怎麼增加
- 判斷什麼時候用固定流程比 Agent 可靠
查一次不夠的任務
第 15 課的工具呼叫只來回一次。但很多問題要查好幾次才答得出來，而且下一步要查什麼，要看上一步的結果。例如：
我的學號是 B1123456。這週四想請假一天，週四有哪些課？那些課我已經缺多少？請假後會不會達到扣考標準？
要先查課表才知道有哪些課，知道課程代碼才能查缺課紀錄，還要查手冊的扣考規定。
Agent 的核心就是一個迴圈： 呼叫模型，有工具呼叫就執行並把結果放回，沒有就結束。下一步要做什麼由模型決定，能不能做、什麼時候該停由你的程式決定。這一課不用任何框架，全部用二十幾行 Python 自己寫。
校園資料都是虛構的（學號、課表、缺課紀錄；手冊是虛構的《優學大學學生手冊》）。三個工具的資料和定義放在一個 JSON 檔裡，範例用 campus() 讀出來：
| 工具 | 參數 | 回傳 |
|---|---|---|
search_handbook |
topic（固定幾個主題，用 enum） |
手冊條文 |
get_schedule |
student_id |
課程代碼、名稱、星期、每次時數 |
get_absences |
course_id |
已缺課時數、總時數 |
逐步看：一個完整的 Agent
看 messages 每一輪怎麼變長、total_tokens 怎麼累加，以及迴圈在哪裡結束。跑完之後，試試把第 5 行的 MAX_STEPS 改成 2 再執行一次。
這次執行做了什麼
錄到的這次執行共 3 輪，累計 2020 tokens：
| 輪 | 模型的決定 | 累計 tokens |
|---|---|---|
| 1 | 查課表，同時查手冊的「請假方式」與「缺課與扣考」 | 388 |
| 2 | 看到課表裡週四有 MATH101、CS102，查這兩門的缺課；週二的英文沒有查 | 1058 |
| 3 | 寫出回答：微積分請假後 19 小時，達到 18 小時的標準；程式設計 6 小時，沒有達到 | 2020 |
這些步驟沒有寫死在程式裡，是模型看到結果後決定的。同樣的問題再跑一次，順序和工具可能不同，後面小工具的錄音就是另一次執行。
把累計拆開來看，三輪分別用了 388、670、962 tokens：後面的輪次要重送前面所有內容，第 3 輪還加上比較長的回答。Agent 的費用不是「每次呼叫一樣貴」，對話越長，每一輪越貴。
逐步看：token 預算也是停止條件
和上一個範例同樣的問題，包成 run_agent(max_steps, max_tokens)。這次步數上限設得很寬，但 token 預算只有 1000。
停止條件要寫在程式裡
模型說「我講完了」只是其中一種結束方式。實際的 Agent 至少要有這幾個條件：
| 條件 | 為什麼需要 | 停下來之後 |
|---|---|---|
| 模型不再要工具 | 正常結束 | 把回答交給使用者，但不代表回答正確 |
| 步數上限 | 模型可能一直查下去 | 告訴使用者沒有完成，以及已經查到什麼 |
| token 或費用預算 | 每一輪都比上一輪貴 | 同上 |
| 重複呼叫 | 同一個呼叫重複執行不會得到新資訊 | 把狀況告訴模型，或直接停 |
| 時間上限 | 工具可能很慢，使用者還在等 | 同上 |
步數上限的值怎麼定？看任務通常要幾步，留一點餘裕。設太小，任務來不及完成；設太大，出錯時要花更多錢才停。下面的小工具可以直接試。
逐步看：偵測重複呼叫
先讓真實模型面對一個一直回「連線逾時，請重試」的工具，看它會不會一直重試。後半段的呼叫順序是手寫的，用來測試偵測器。
這次模型沒有重試，偵測器還是要寫
錄到的真實回應是：工具說「請重試」，模型只試一次就回覆使用者「連線逾時，請稍後再試」。第 1 次錄製時工具回「系統維護中」，結果也一樣。
這不表示可以省略偵測。這次只測了一種情況、一個模型；換了模型、任務或工具回傳的內容，行為可能不同。步數上限和重複偵測的目的是即使模型判斷錯了，程式也停得下來，這和模型平常表現好不好無關。
逐步看：同一個問題不用 Agent
問題和開頭相同，但學號和星期已經確定。這支程式完全不呼叫模型，也算得出答案。
Agent 什麼時候不值得用
上面這支程式 0 次模型呼叫、0 token，結果和 Agent 相同：微積分會達到，程式設計不會達到。Agent 那次用了 2020 tokens。
| 情況 | 比較適合 |
|---|---|
| 步驟固定、規則明確（查課表→算缺課） | 一般程式 |
| 判斷要每次一致、可以稽核（會不會扣考） | 一般程式，規則寫在程式裡 |
| 使用者說法多變，但要做的事只有幾種 | 模型只負責判斷意圖與取出參數（第 9 課），後面走固定流程 |
| 下一步要看上一步的結果，而且路徑事先列不完 | Agent |
Agent 的代價是：費用比較高、每次路徑可能不同、比較難測試，也多了出錯和被誤導的機會。能用一般程式解決的部分就用一般程式，把模型留給真正需要它的地方。
下一課會談另一面：Agent 能動用工具之後，出錯的代價也變大了。
實作：補完 Agent 迴圈
完成 run_agent(model, max_steps)，加上兩個停止條件。這題不呼叫真正的模型，model 是一個假函數，回應是寫好的字典（欄位和真實回應的意思相同，只是用字典表示，比較好讀）。
- 回應的
finish_reason不是tool_calls→ 回傳("完成", 回答文字, 第幾輪, 累計 tokens) - 達到
max_steps還沒結束 → 回傳("達到步數上限", None, max_steps, 累計 tokens)
第一個測試的模型第 3 輪會講完；第二個測試的模型永遠要工具，上限是 4，所以一定要靠步數上限才停得下來。
小測驗：Agent 迴圈
Agent 迴圈裡，下一步要用哪個工具由誰決定？能不能執行由誰決定？
為什麼需要步數上限？
下面這段程式會印出什麼？
「週四請假會不會達到扣考標準」這個判斷，為什麼適合用程式計算而不是交給模型？
對話進行到第 5 輪時，輸入 token 通常比第 1 輪多。下列哪個說明正確？
重點整理
- Agent 就是迴圈：呼叫模型 → 有工具呼叫就執行、放回 → 沒有就結束。
- 模型決定下一步，程式決定能不能做、什麼時候停。
- 停止條件要寫在程式裡：模型講完、步數上限、token 預算、重複呼叫、時間。模型講完不代表回答正確。
- 每一輪都重送全部內容，費用要累計
usage才看得到，而且越後面越貴。 - 步驟固定、規則明確的部分用一般程式；Agent 留給路徑事先列不完的任務。
下一課： 工具要怎麼接上去、該給 Agent 多少權限。