5 篇博文 含有标签「function-calling」

工具描述不是文档。它是模型在每一轮对话中都会读取的 prompt，用于决定该工具是否触发以及如何触发。你不是在为对接该工具的开发者编写内容——开发者已经在 PR 中看到了 schema、类型和示例。你是在为一个从未见过这个代码库的随机读者编写内容，它在同一个上下文窗口中还拿着另外二十个工具描述，并且必须在下一次前向传播中选出一个。

大多数团队并没有意识到这一点。他们把 OpenAPI 摘要粘贴到 description 字段中，把 JSON Schema 贴在下面，然后就发布了。结果，agent 调用工具的次数过少，或者自信地调用了错误的邻近工具，又或者用了任何读过 schema 的人类都会觉得“显而易见”是错误的参数来调用正确的工具。团队责备模型，但模型读取的正是一字不差的你写的内容。

生产环境 Agent 中最危险的 Bug 不是那些会抛错的 Bug。而是这种：工具描述写着 returns user_id，但后端在两个 Sprint 前悄悄开始返回 account_id，而模型在后续推理中仍在愉快地凭空捏造 user_id —— 因为清单（manifest）是这么写的，Few-shot 历史加强了这一点，而且循环中没有任何环节去获取真实情况（ground truth）。

这就是清单漂移（manifest drift）：工具描述所声称的内容与端点实际行为之间缓慢且无声的分歧。它很少产生堆栈跟踪（stack traces）。它产生的是带有干净审计线索的错误决策 —— 这是 Agent 系统中最糟糕的一类 Bug。

你的智能体中杠杆率最高的 prompt 并不在你的系统 prompt（system prompt）中。它是你六个月前在某个工具定义下写的那句描述，它随实现代码一起提交，之后就再也没动过。模型在每一轮对话中都会读取它，以此决定是否调用该工具、绑定哪些参数，以及当响应不符合预期时如何恢复。工程师将其视为面向人类的 API 文档，而模型则将其视为一个 prompt。

这两种视角之间的鸿沟，正是最糟糕的工具使用（tool-use）类 bug 的温床：模型调用了正确的函数名，传入了正确的参数，发出了正确的 API 调用 —— 但原因却是错的，场景是错的，或者它放着旁边更合适的工具不用。没有任何异常抛出。你的评估套件依然通过。这种退化（regression）只会表现为衡量智能体是否真正起到帮助的指标在缓慢下降。

大多数工程师对待智能体工具的方式与编写 REST 接口或库函数如出一辙：清晰地暴露功能、记录参数、处理错误。这对人类来说是正确的直觉。但对于 AI 智能体（AI Agents）来说，这完全是错误的。

智能体使用的工具是以非确定性的方式被消耗的，它被逐个 Token 解析，并由一个对上周二使用过什么工具没有持久记忆的模型来选择。你编写的工具 Schema 并不是文档——它是运行时提示词（runtime prompt），在推理时被注入到模型的上下文中，塑造着智能体做出的每一个决策。每一个字段名称、每一段描述、每一个返回值的结构都是一个设计决策，具有可衡量的性能影响。这就是智能体-计算机接口（ACI，Agent-Computer Interface），它值得你像对待任何关键的面向用户的界面一样投入工程精力。

LLM 在生产环境中函数调用失败最令人惊讶的地方在于它们的来源。不是幻觉推理。也不是模型选错了工具。代理不稳定的首要原因在于参数构造：错误的类型、缺少必填字段、格式错误的 JSON、幻觉出的额外字段。模型本身没问题。你的 schema 才是问题所在。

这是个好消息，因为 schema 修复成本很低。