作者 | 云昭
一款 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/
