接上第一个真工具
工具调用闭环四段演示；三档任务：选定工具、写三行描述、跑通闭环并故意搞一次破坏
本页解决的问题
先给结论「接上第一个真工具」要解决的关键问题是什么？
工具调用闭环四段演示；三档任务：选定工具、写三行描述、跑通闭环并故意搞一次破坏
跟着交接处走，不要只看 Demo。 系统是否可靠，往往取决于模型、工具、状态、权限和人的交接处。把每次交接都当成可以观察、测试和恢复的地方。
为一个自动化步骤写清输入、负责人、审批和恢复动作。
一次运行成功了，却说不清发生了什么，也无法安全重放。
「接工具」听起来是技术活，其实链路只有四段，而且模型全程没有执行任何东西，它只是开口要，真正动手的是框架。看懂这四段，你就知道出问题该查哪一段。
从模型开口到结果回喂
模型开口要
输出一段 JSON：调哪个工具、参数是什么
框架校验参数
格式对不对、值合不合法，不合法就打回重来
真实执行
查数据库、发请求、写文件，这一步才碰真实世界
结果回喂
执行结果塞回对话，模型消化后才说人话
第一个工具怎么挑
三个标准，一个都别让：高频（你的场景里几乎每次都用得上）、低风险（只读优先，查天气、搜文档都比发邮件安全）、输入输出清楚（参数两三个，返回结构固定）。这一章讲过工具描述的学问：同样的功能，好描述和坏描述的调用成功率差三倍，所以挑好之后，先把描述写明白再谈接入。
这一章的动手清单
0 / 3 已完成
选定第一个工具
15 分钟 所有人照着上面三个标准（高频、低风险、输入输出清楚），从你的场景里挑出第一个工具，写下：工具名、一句话功能、两三个参数分别是什么。挑不出来就选「搜索我的某某资料」，它几乎适配所有场景。
什么算做完了
把工具描述写成三行
1 小时 想让它调得准第一行：什么时候该用这个工具（也写清什么时候不该用）；第二行：每个参数的含义、格式和示例值；第三行：返回什么、拿到之后该怎么用。写完拿「一次对话背后的 5 条消息」那节课的视角自查：模型只凭这三行字决定怎么调，它看不到你的代码。
什么算做完了
跑通一次完整闭环
半天 准备真做一个用你顺手的平台（Coze、Dify、Cursor，或直接写代码）把这个工具真接上，问一个必须用到它的问题，看四段链路走完。然后故意搞破坏：问一个参数含糊的问题，看它卡在哪一段、给用户什么反馈。这一章讲的 Agent 卡死五种模式，你至少要亲眼见到一种。
什么算做完了
「先看清楚 · 一次工具调用的完整闭环」里的风险边界在哪里
「「接工具」听起来是技术活，其实链路只有四段，而且 模型全程没有执行任何东西 ，它只是开口要，真正动手的是框架。看懂这四段，你就知道出问题该查哪一段」把安全问题从一句“请模型不要犯错”拉回到权限、数据和环境。真正需要保护的是：模型即使判断失误，系统也不能让错误变成不可逆的结果。
把模型建议和实际权限分开
在「三个标准，一个都别让： 高频 （你的场景里几乎每次都用得上）、 低风险 （只读优先，查天气、搜文档都比发邮件安全）、 输入输出清楚 （参数两三个，返回结构固定）。这一章讲过工具描述的学问：同样的功能，好描述和坏描述的调用成功率差三倍，所以挑好之后，先把描述写明白再谈接入」涉及的流程中，要分别检查用户能要求什么、模型能建议什么、工具实际允许什么，以及谁有权批准写入或发送。网页、文档和工具返回值都可能携带不可信指令，不能因为它们看起来像说明就自动提升权限。
安全设计必须包含失败和恢复
结合「M2 要记的是：工具叫什么、描述怎么写的、第一次跑通和第一次卡死分别长什么样。卡死那条尤其值钱，下一章的评测就从它开始」做一次反向演练：加入错误输入、缺失凭证或迟迟不到的审批，确认系统会拒绝、暂停并留下可追踪信息，而不是继续执行到底。
从「先看清楚 · 一次工具调用的完整闭环」走到「动手清单 · 挑一个开始，勾掉它」
「先看清楚 · 一次工具调用的完整闭环」先把问题落在「「接工具」听起来是技术活，其实链路只有四段，而且 模型全程没有执行任何东西 ，它只是开口要，真正动手的是框架。看懂这四段，你就知道出问题该查哪一段」上；到了「动手清单 · 挑一个开始，勾掉它」，讨论继续推进到「照着上面三个标准（高频、低风险、输入输出清楚），从你的场景里挑出第一个工具，写下：工具名、一句话功能、两三个参数分别是什么。 挑不出来就选「搜索我的某某资料」 ，它几乎适配所有场景」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
做安全判断时，把“模型想做什么”和“系统允许做什么”分开，逐个检查数据边界、工具权限、人工确认和失败后的恢复路径。
- 「先看清楚 · 一次工具调用的完整闭环」：「接工具」听起来是技术活，其实链路只有四段，而且 模型全程没有执行任何东西 ，它只是开口要，真正动手的是框架。看懂这四段，你就知道出问题该查哪一段
- 「动手清单 · 挑一个开始，勾掉它」：照着上面三个标准（高频、低风险、输入输出清楚），从你的场景里挑出第一个工具，写下：工具名、一句话功能、两三个参数分别是什么。 挑不出来就选「搜索我的某某资料」 ，它几乎适配所有场景
- 「最后的要点」：M2 要记的是：工具叫什么、描述怎么写的、第一次跑通和第一次卡死分别长什么样。卡死那条尤其值钱，下一章的评测就从它开始
最后的「最后的要点」把讨论落到「M2 要记的是：工具叫什么、描述怎么写的、第一次跑通和第一次卡死分别长什么样。卡死那条尤其值钱，下一章的评测就从它开始」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。