AI 智创简报：《工具调用专利三千六，空结果语义无人 claim》
内容提要
文章指出，大厂专利集中在工具结果进入模型前的输入过滤、调用拦截和输出验真，却无人处理工具返回空值或失败后的语义分流。空值可能意味着数据本为空、工具故障或参数错误，误判会导致错误推理或无效重试。现有工具和社区讨论也偏重调用前防护。作者因此提出一个个人开发者可做的只读审计器，将失败结果分为三类记账并核算重试成本，不拦截、不改调用。
延伸解读
专利检索的“零命中”说明了什么
文章用同一检索接口对比“tool execution”的3638件与“empty tool result”的0件，指出执行侧专利密集而结果语义侧空白。这一对比的价值在于揭示权利要求布局的偏向：大厂专利集中在结果进模型前的输入过滤、调用拦截和输出验真，而非工具返回空值或报错后的语义分流。读者需注意，零命中只反映精确短语检索结果，不能等同于该领域完全无人研究，但足以说明公开专利文本中缺少对应claim。
空结果误判的实际代价
文章将工具返回失败或空值拆为三种语义：数据本为空、工具服务故障、参数错误。三者正确动作不同，但当前分流依赖开发者手写临时判断。误判后果具体：把库存查询为空当成商品下架，会让agent基于假空值继续推理；对临时故障无限重试，则消耗大量token预算。这一拆解提醒读者，工具调用链路的薄弱点不只在调用前防护，也在结果返回后的语义归类。
社区热度与供给错位
文章列举Hacker News近一年五个相关帖，以及npm上@stackone/defender、promptfoo和PyPI上guardrails-ai、llm-guard等工具，说明工具调用生态活跃，但供给集中在调用发生前的注入防御与护栏。作者据此判断需求已出现而供给堵在上游。读者可从中看到，现有工具和讨论偏重写入侧防护，失败结果进门后的分流仍是较少被产品化的环节。
只读审计器的定位与边界
作者提出个人开发者可做的只读tool-result语义审计器：挂在工具调用日志之后，将失败与空返回值分为三类记账并核算重试成本，不拦截、不改调用、不碰模型。文章称从公开专利文本看，四件专利的claim停在输入过滤、异常调用检测与输出验真，这种事后只读审计暂不落入其文字范围。读者应注意，这是基于公开文本的判断，并非法律结论，实际实施仍需自行评估。
Q&A
大厂在工具调用相关的专利主要覆盖哪些环节？
大厂专利集中在工具结果进入模型之前的输入过滤、调用拦截和输出验真，例如美国运通的LLM交互安全沙箱、微软的幻觉检测、提示词注入判定和异常工具调用判定，均未涉及工具返回空值或报错后的语义分流。
工具调用返回空值或失败时，可能包含哪几种不同的语义？
至少混有三种语义：数据库里本来为空、工具服务坏了、参数用错了。这三种情况的正确后续动作完全不同，但当前缺乏自动分流机制。
如果错误处理工具返回的空值或失败，会带来什么后果？
误判会导致错误推理或无效重试。例如agent把库存查询为空当成商品下架，或者对着临时故障无限重试，烧掉大量token预算。
目前社区和工具生态对工具调用失败结果的处理现状如何？
社区讨论和现有工具（如@stackone/defender、promptfoo、guardrails-ai、llm-guard）都偏重调用前的防护（如提示词注入防御），没有一个做失败结果进门后的语义分流。
作者提出的只读审计器具体做什么？
只读的tool-result语义审计器挂在工具调用日志之后，将失败与空返回值分箱为「本来为空、工具故障、参数错误」三类分开记账并出报告，帮开发者算清每类错误烧掉的重试成本；不拦截、不改调用、不碰模型。
为什么说这个只读审计器可能不落入大厂专利的保护范围？
从公开文本看，四件专利的claim停在输入过滤、异常调用检测与输出验真，这种事后、只读、不执行动作的审计暂不落在其文字范围内。
