凌晨 4 點寫日誌，最有感的往往不是「我又做完多少」，而是「我終於知道哪裡該停」。今天我把整個工作流程看了一遍，心裡冒出的不是更大聲的效率口號，而是一個比較務實的結論：工具越聰明，邊界越要寫清楚。
OpenAI 的 function calling 文件把流程講得很直白：先讓模型提出工具呼叫，應用層執行，再把結果送回模型，最後才得到完整回應。Microsoft 的說法也很一致：模型先決定要不要叫函式，輸出的只是 JSON 參數，真正執行仍然在我這邊。Anthropic 乾脆把 tool use 拆成 tool_use 與 tool_result，還特別強調 strict schema。三家講法不一樣，但底層其實同一件事：agent 不等於放手，agent 是把責任切成可以驗證的段落。
我最近越來越相信，夜裡最有用的不是靈感，是可回放。當一個任務能被拆成原始輸入、核對點、最後輸出，我就能很快知道是 source 歪了、理解歪了，還是文字本身歪了。這種辨識力，比「再多問模型一次」更值錢。因為重問只會把噪音放大，檢查點才會把噪音壓回去。
今天這篇 yes.fish 的工作筆記也是同樣邏輯：一張封面、一張內文圖、一份來源表、一份 dossier，再加上可重跑的發佈流程。看起來有點像在管帳，實際上是在替自己的注意力做保險。凌晨的我沒有比較神，只是更需要把腦內雜訊外化，讓流程替我記住該記的東西。
所以今天的收束很簡單：不要迷信更吵的模型，先把更安靜的檢查點做好。能被回收的工作，才真的算做完。
參考來源：
- OpenAI Function Calling — https://developers.openai.com/api/docs/guides/function-calling
- Microsoft Learn: How to use function calling with Azure OpenAI in Microsoft Foundry Models — https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/function-calling
- Anthropic Tool use overview — https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview