作者 | 云昭
一款 Agent 究竟是怎樣讓大模型具備“Tool Use”，即工具調用的能力？
今天，有一位正在創建編碼 Agent 的狠人出來曝光了這個算法邏輯。
這位狠人，名為 Philip Zeyliger，過去幾個月，他和他的團隊一直在開發一款名為“Sketch”的 AI 編程助手。然后，他寫了幾篇博客，總結了開發過程中的經驗。
其中最讓 Zeyliger 震驚的是：其實大模型在搭配“Tool Use”使用時，根本沒我們想象的復雜！
它的主循環邏輯，竟然超級簡單直白，其實就 9 行代碼！
def loop(llm):
msg = user_input()
whileTrue:
output, tool_calls = llm(msg)
print("Agent: ", output)
if tool_calls:
msg = [ handle_tool_call(tc) for tc in tool_calls ]
else:
msg = user_input()這 9 行代碼，理解起來也非常簡單。可以說是讓大模型具備工具調用能力，核心思想就濃縮在這 9 行里面。
ps：當然，為了讓上述代碼真正跑通，還有不少「儀式感」需要補齊。
完整腳本見這里：https://philz.dev/blog/agent-loop/。
1.9 行代碼搞懂大模型的 Tool Use，這其實也是個 Agent 循環
其中，函數 `llm()` 負責把系統提示詞、歷史對話和用戶輸入一起發送給 LLM API。
而所謂的“工具使用（Tool Use）”，聽起來高大上，其實就是：LLM 輸出一些結構化格式，符合預定義的 schema。
這方面，在完整腳本里有寫具體的邏輯，通過系統提示詞和工具說明，告訴 LLM 它可以訪問 bash。
不要小看這樣一個簡單的函數，Zeyliger 很興奮地發現，僅僅是這樣一個看似沒什么特別的“常規操作”，當前的模型（Zeyliger 自己在用 Claude 3.7 Sonnet）就能解決許多問題，有些用例甚至可以一發入魂，精準命中。
舉個實際例子，Zeyliger 表示，“過去，我需要查找某個冷門的 git 命令，然后復制粘貼；現在，我直接問 Sketch。”再比如，之前改個類型之后，都得一個一個手動修正類型檢查錯誤（或者老實說，用 `perl -pie` 這種“魔法”），但現在他讓自己參與研發的 Sketch 來搞定。
有經驗的朋友可能會問，LLM + Tool Use，這不就是 Agent 嗎？
沒錯，其實這 9 行代碼就可以理解成是個 agent 循環。
而且，只要提示詞寫得合適，這個 agent 循環還能保持持續對話狀態。你機器上缺少某個工具？它就會試著安裝。你本地 `grep` 的命令參數跟預期不一樣？它會適配。
當然，它也可能令人抓狂！比如它會說：“哦，這個測試過不了……那我們就跳過好了。”
這時候，你聽了肯定想拍桌子。
2.只需要幾個小工具，這段腳本性能飛速提升
Agent 是未來，正在成為業界共識。同時，在很多工作流中，Agent 工具還會呈現「專精化」的趨勢。
Zeyliger 及其團隊后來發現，只要多加幾種小工具，他們開發的能顯著提升效果、加快迭代，也更符合開發者的真實使用習慣。
這是因為本身大模型也存在自身的能力邊界，比如 Zeyliger 就對“ LLM 正確修改代碼文本”的能力存疑，并沒有他想象中那么好。
“看到它在處理 `sed` 的一行命令時頻頻出錯，反而讓我重新感嘆：可視化編輯器（而非命令行）真的是奇跡般的存在。”
所以，這時候，就應該乖乖地讓大模型調用更擅長的工具。基于此，Agent 工具專精化將是一個越來越明顯的趨勢。
3.大量的輕量型、臨時的 Agent 腳本即將涌現
此外，作為親身體驗了 Agent 開發和使用的老炮兒，Zeyliger 已經完全確信這一點： 這段 9 行核心邏輯的 agent 循環將越來越多地被用于日常的自動化任務，尤其是那些過去既不適合通用工具，又過于復雜難以傳統自動化的部分。
對于開發者而言，進而就意味著——未來我們會在項目的 `bin/` 目錄中，看到越來越多定制、臨時、即棄（throw-away）型的 LLM Agent 腳本。
4.Agent 本身沒什么秘密武器
不要把 Agent 想得多么高大上。
就拿各種Coding Agents 為例。表面看起來百家爭鳴，國外的 Claude Code、Windsurf、Cursor、Cline、Copilot、Aider、Codex，國內的通義靈碼、Codemate、小浣熊、CodeBuddy……大家都在做 coding agent，但其實背后，更主要還是 LLM 自身的驅動能力集中爆發的結果。
本質上，沒有“秘密武器”，主要是 LLM 本身的能力、加上 loop 與 tool-use 框架的廣泛適配。
正如 Zeyliger 所說，未來將涌現出更多“輕量級、即拋式、項目內的臨時 Agent”。
5.網友：確實，但關鍵是Agent究竟應該循環幾次
這個 9 行代碼說清楚 Agent 循環構建的文章，快速引起了HackerNews網友的關注和討論。
其中一位網友對于 Zeyliger 的“大模型不合理的”Tool Use能力的解釋大為贊同，更是直接甩出了一篇“如何從零構建一個 coding agent”的文章，感興趣的朋友不妨去讀一讀：https://ampcode.com/how-to-build-an-agent
這篇文章實證了 LLM+工具調用循環的強大能力。
圖片
甚至網友更進一步討論起來了，這 9 行代碼中最難把握的問題，即：我們并不能精準清楚大模型能做什么，究竟讓他們自己做幾次循環，然后才由人來重新控制它？
圖片
另一位網友則表示認同。他認為，代理的主要問題在于它們沒有反思自身的表現，也沒有主動暫停執行并向人類尋求幫助。代理在很多情況下可以成功運行 20 多次迭代，但在某些情況下，每次迭代后都需要人工指導。
“這就像一個初級人員沒有意識到自己已經超出了自己的能力范圍，應該尋求幫助。”
直白點理解，就是LLM有點缺乏“自知之明”。對于這個問題，其實還沒有達成共識解：
有位網友提出，用另一個 “監督 LLM” 來判斷 agent 是否卡殼，并在人類介入前終止循環。
不過很快就有網友提出了不同的意見：一位名為suninsight的網友表示他們的公司（NonBioS.ai）已經在實踐中實現了這種機制。
而另一位則認為甚至不需要單獨監督者，agent 自身每一步都可以嘗試進行「進展判斷 + 請求幫助」的邏輯判斷。
看來這個問題，只能具體問題具體分析了。
6.寫在最后：Agent沒有那么神秘，可以手搓起來了
不過目前可以確認兩點：
- 大模型自身就可以很容易實現調用工具，實現并不難；
- 但是，LLM agent 循環存在“跑偏”的可能，可靠性仍是問題，尤其在多輪執行中。即便可以實現 90% 的成功率，但最后 10% 的精度上依舊沒有很好的解法。
正如網友所說，目前還做不到完全無人監督地持續運行超過幾次循環。
其實這也反過來說明，LLM agent 循環機制本身也是一個非常有誘惑力的研究領域，潛力和局限性都有待AI開發者們親自研究一番。
那么問題來了，大家準備手搓一個“Agent”火蓮了嗎？再把這 9 行代碼的完整腳本的鏈接貼給大家，請諸位自行把玩——https://sketch.dev/blog/agent_loop.py
參考鏈接：https://philz.dev/blog/agent-loop/
