KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
Tool Calling — keel 龙骨
在 Harness 的一次运行里，模型只能提出“下一步可能需要这个工具”。真正困难的部分发生在之后：程序怎样描述工具、校验参数、判断权限、执行动作、返回结果，并在失败或副作用出现时保持可控。
在 Harness 的一次运行里，模型只能提出“下一步可能需要这个工具”。真正困难的部分发生在之后：程序怎样描述工具、校验参数、判断权限、执行动作、返回结果，并在失败或副作用出现时保持可控。
章节目录
- 01. 函数为什么不能直接交给模型？ — 先看一条请求。
- 02. 先让模型真正提出一次工具请求 — 上一章的请求是我们手写的。现在换成真实模型：给它一段自然语言和一组工具描述，让它自己决定要不要请求工具、请求哪一个、参数填什么。
- 03. 一个工具契约究竟包含什么？ — 上一章末尾留下了一个问题：模型确实能提出工具请求，但「一个函数」和「一个能交给模型的工具」之间，到底差了哪些字段？
- 04. Registry 和 Executor 怎样形成白名单？ — 模型返回的工具名是不可信输入。程序不能按字符串寻找任意函数，只能从已经注册的能力中选择。
- 04. 数据库里的一行静态记录，怎样变成可调用的 function？ — 前面几章里，工具的 handler 一直是一个已经存在的 Python 函数：tools.py 里写好，build_registry() 直接把它塞进注册表。这条路径很自然，但它有一个前提——写代码的人事先知道有哪些工具。
- 05. Registry 和 Executor 怎样形成白名单？ — 第 01 章说过：模型返回的工具名是不可信输入。这一章把那句话落成两件事——工具只能从一个显式表里取出来，以及每次调用都走同一条固定检查顺序。
- 05. 工具结果为什么要回到下一轮？ — 工具返回事实，不会自动生成用户能读懂的诊断。模型必须在下一轮看到工具结果，才能继续决定或组织最终回答。
- 06. 工具失败时为什么不能急着重试？ — 最危险的失败是结果未知：请求已经发出，但客户端没有收到响应。创建工单可能已经成功，立刻重试会产生第二张工单。
- 06. 工具结果为什么要回到下一轮？ — 执行器已经给出了结构化结果，事情到这里结束了吗？没有。工具返回的是事实，不是用户要的答案——把 severity: high 和三条证据翻译成一句「先去看数据库连接池」，还得模型再参与一次。
- 07. 工具失败时为什么不能急着重试？ — 上一章展示了「把错误放回上下文，模型自己会改」。这句话有个前提容易被忘：改对的是参数，重试不一定是安全的。这一章处理重试前的三个问题。
- 07. 多工具和流式调用怎样不乱？ — 掌握单次循环后，才进入两个更复杂的传输问题：一个响应里可能有多个工具请求，流式响应中的工具字段可能分批到达。
- 08. 多个工具和流式调用怎样不乱？ — 到目前为止，一轮模型响应里只提过一个工具请求。真实场景里经常一次提两三个——而这两个之外的问题，教科书上很少写：「并发」和「流式」都改变了结果的到达方式，顺序不再可信。
- 08. 副作用工具怎样进入审批边界？ — 查询事件和发送通知不能使用同一套自动执行策略。工具是否会影响外部世界，必须成为契约和策略的一部分。
- 09. 把工具子系统放回 Harness — 到这里，你已经完成了工具内部的完整链路：
- 09. 副作用工具怎样进入审批边界？ — 前面八章保证的是「调用被正确地执行」。这一章要保证另一件事：有些调用根本不该自动执行，即使参数完全合法。
- 10. 把工具子系统放回 Harness — 九章跑下来，工具链路已经被拆成了九个可以单独检查的部分。这一章做三件事：把它们压回一次运行、放回它所属的更大系统、然后给你一个需要自己补两次能力的结业练习。