ARTICLE · 1101441
重新理解 AI 系列43:工具接上了,为什么还不能放心让 AI 去做?
副标题：真正困难的不是让模型调用工具，而是让每一次调用都经过选择、校验、授权、执行与验收
引言
在上一篇《重新理解 AI 系列42：模型每一轮到底应该看见什么？》里，我们讨论了 Context Engineering 如何在 Harness 中落地，为模型准备当前这一步需要的工作集。
材料准备好了，模型也判断出了下一步。接下来似乎只要选工具、填参数、执行就行了。
但我们来看一个很普通的请求：
“帮我约明天下午和财务、法务开一个预算会。”
模型能听懂用户想约会，也知道该调用日历工具。可真要执行，问题马上就来了：“明天下午”是几点？会议多久？“财务、法务”分别指谁？如果时间冲突，系统该自动调整，还是先问用户？
即使参数都明确了，调用也可能出错。假如创建会议的请求超时，第一次也许已经成功，只是结果没有及时返回。盲目重试，可能创建两个会议、发送两遍邀请。
所以，工具接上了，不等于 AI 已经能可靠地做事。
这一篇，我们继续往 Harness 里面走，讨论它的另一项关键职责：模型提出行动以后，系统怎样治理工具调用，让这一步正确、可控地发生。
一、工具调用治理，不是一张工具清单
我们先给 Harness 中的工具调用治理一个不太教科书、但足够实用的定义：
工具调用治理是 Harness 围绕调用生命周期建立的一组运行时机制。它决定当前可以暴露哪些工具，校验参数、检查权限、管理执行，并验证结果是否真正生效。
工具清单回答“系统有哪些能力”，Harness 的工具调用治理关心的则是：这一轮该提供哪些工具？参数是否合理？操作有没有被授权？失败后该重试、查询状态，还是停下来？接口成功，任务就真的完成了吗？
连接工具只是提供了行动入口，Harness 还要负责管理行动边界。
图注：工具接入只是入口；可靠调用还要贯穿选择、校验、授权、执行恢复、结果验证和状态回填。
二、第一道关：让模型选对工具
模型要选对工具，首先得看懂每个工具是做什么的。
一个工具通常需要名称、用途描述、输入输出结构、适用场景和限制条件。如果描述只是“处理日程”，模型很难判断它究竟是查询、创建还是修改会议。工具越相似，模糊描述越容易造成误选。
这不只是措辞是否漂亮的问题。OpenAI 的 Function Calling 指南明确建议使用清晰、具体的函数名和参数说明；Anthropic 在工具设计实践中也指出，功能重叠、用途模糊的工具会让 Agent 更难选对行动。
安排预算会时，系统可能同时拥有查询日程、寻找多人空闲时间、预订会议室、创建会议和发送通知等能力。它们都和“开会”有关，却对应不同阶段和影响范围。
澄清时间时，模型只需要读取类工具；用户确认方案后，才需要创建会议、发送邀请。如果一开始就暴露全部工具，不仅增加选择难度，也会让高影响操作过早进入可选范围。
因此，工具注册不是维护一张固定清单。系统要根据任务阶段、用户身份、授权范围和当前状态，动态决定这一轮暴露哪些工具。
OpenAI 的官方指南也建议控制一轮开始时可用工具的数量，并在工具面很大时采用延迟加载。重点不是追求一个适用于所有系统的固定数字，而是避免把整套能力无差别地塞进模型上下文。
这和上一篇的上下文管理正好接上了：工具描述本身也是上下文的一部分。工具多，不等于更会做事。
三、第二道关：让模型填对参数
选对工具以后，还要填对参数。
Schema 可以规定字段类型、必填项、枚举值和基本格式，例如开始时间格式、会议时长和参会人 ID 列表。
在支持严格模式的 Function Calling 中，系统还可以要求模型生成的参数遵守给定的 JSON Schema。但这解决的主要是参数“长什么样”，不是参数“在业务上是否正确”。格式合法，仍然不等于业务正确。
模型完全可以生成一份通过 Schema 校验的参数，却把会议定在下午一点、持续四小时，把“财务”理解成负责人、把“法务”理解成整个部门。字段都合法，组合起来却未必符合用户意图。
所以，参数治理至少有三层：结构校验检查字段和类型；业务校验检查时间、人员、资源及字段间的矛盾；意图确认判断关键参数来自用户明确表达，还是模型推测。
低风险、容易撤销的默认项可以由系统建议。但会议时间、参会人和是否发送邀请会直接影响他人，不能因为模型“猜得挺合理”就自动执行。
好的参数校验，不是把所有模糊表达都猜成一个答案，而是知道什么时候该停下来问一句。
四、第三道关：让模型有权做，而且只做被允许的事
同样是日历工具，不同操作的风险并不一样。
读取自己的空闲时间通常只影响信息展示；查询他人日程可能涉及隐私；创建、修改或取消会议则会直接影响参会人。
“帮我看看大家什么时候有空”，不等于授权系统直接创建会议；允许创建一次预算会，也不等于允许它以后自由修改所有人的日程。
权限不能只写进 Prompt，期待模型自觉遵守。真正的授权判断必须由外部系统执行：当前用户是谁？可以访问哪些数据？操作是否超出范围？是否需要再次确认？
最重要的原则，是让一次调用只获得完成当前动作所需的最小权限。查询空闲时间，不应顺便拿到删除会议的能力。
这就是安全工程里常说的最小权限原则：用户或代表用户运行的进程，只获得完成当前任务所必需的访问能力。权限校验应由确定性的系统机制落实，而不是交给模型临场判断。
模型可以提出动作，但系统必须握住最终的执行开关。
五、第四道关：调用失败以后，不能只会再试一次
工具调用失败时，最自然的反应往往是“再试一次”。可在真实系统里，这可能恰恰是危险的开始。
失败可能是请求被拒绝、参数不合法、服务限流、网络超时、部分完成，以及最麻烦的“结果未知”。
还是回到创建会议。系统发出了请求，却在等待结果时超时。我们只知道没有收到响应，却不知道会议是否已经创建成功。
直接重试可能产生两个会议；直接告诉用户失败，又可能让已经创建的会议无人处理。更稳妥的做法，是先查询外部状态，或者为同一次业务操作设置幂等标识，让系统识别重复请求。
AWS 的可靠性指南也把幂等视为安全重试的重要前提：同一个业务请求使用相同的幂等标识，重复发送时不应重复产生副作用。
对于确实可以重试的错误，也要控制次数和间隔，识别限流，必要时暂停任务、切换方案或交给人工。
有些操作还需要补偿。例如会议已经创建，邀请却只发送了一部分。系统要知道哪些步骤完成了，再决定补发、撤销还是请用户处理。
可靠的失败处理，不是“失败就重试”，而是先判断：发生了什么，当前状态是什么，重复执行会不会造成新的影响，然后再决定下一步。
图注：响应超时只说明结果未知。先查询外部状态或复用幂等标识，可以避免盲目重试造成重复副作用。
六、工具返回“成功”，任务也不一定真的完成
工具返回成功，只能说明一次接口调用得到了成功响应，不一定意味着用户目标已经完整达成。
创建会议后，系统还要核对会议 ID、时间、参会人、会议室和邀请状态。会议可能创建成功，但法务同事没有加入；线上链接生成了，会议室却预订失败；接口返回成功，时间却因时区转换出现偏差。
这些结果要被整理成结构化状态，再放回任务流程：哪些已完成、哪些待处理、下一轮模型需要看见什么、用户该得到怎样的说明。
Anthropic 对 Agent 工具的实践建议同样强调，工具返回应该优先保留与后续行动有关的高信号信息，而不是把所有底层字段和冗长结果一股脑交还给模型。
这也把工具调用治理与上下文管理连接起来：工具结果不应原封不动地塞回对话，而要保留关键字段、来源和执行状态，再参与下一轮工作集的组装。
我们要区分三个层次：模型说“已经完成”，接口返回“调用成功”，现实任务确实完成。只有最后一层经过核对，结果才值得交付。
七、Function Call、MCP、CLI、Skills 与 Harness 是什么关系？
讲到这里，我们可以把此前介绍过的几个概念放回同一张地图里。
Function Call 让模型用结构化方式表达“希望调用哪个工具、传入什么参数”。它产生的是调用请求，真正执行函数的仍然是模型外部的应用程序或运行环境。
API 和 CLI 是能力的具体操作接口：一个面向程序调用，一个面向命令行交互。
MCP 是连接 AI 应用与外部数据、工具的开放协议。MCP Server 可以暴露工具，但调用是否被允许、由谁执行、结果如何进入后续流程，仍取决于宿主应用和 Harness。
Skills 则把说明、流程、经验以及必要的脚本或参考资料组织起来，帮助模型判断在什么场景下如何选择、组合和使用这些能力。
Harness Engineering 中的工具调用治理，则围绕调用前、中、后处理运行边界：暴露哪些工具，参数是否可信，动作是否被允许，失败如何处理，结果怎样验证并写回状态。
它们不是互相替代。我们可以先用一张简化的工程地图来理解：Function Call 表达动作意图，API 或 CLI 提供操作入口，MCP 规范连接和能力暴露，Skills 沉淀使用方法，Harness 则让整个过程可以被控制和检查。这是帮助理解的分层，不是唯一的行业标准架构。
图注：Function Call、API/CLI、MCP、Skills 与 Harness 承担不同职责；这是一张帮助理解的工程地图，不是唯一标准架构。
结语：工具多，不等于行动能力强
在本文中，我们从一句“帮我约个会”出发，看了一次工具调用真正需要经历什么。
系统要让模型选对工具、填对参数，检查权限，管理超时和失败，核对动作是否生效，并把结果写回任务状态。少了其中任何一环，都可能产生看似合理、实际无法交付的行动。
工具越多，系统拥有的可能性越多，选择错误、权限越界和失败扩散的空间也会随之变大。
工具调用治理的价值，不是让模型随意使用更多工具，而是让它在正确的时机，以正确的方式，执行被允许而且能够被验证的动作。
模型负责提出动作，工具负责执行动作，Harness 负责让动作值得被执行。
参考资料
• OpenAI, Function calling. • Anthropic, Writing effective tools for AI agents—using AI agents, 2025. • Model Context Protocol, MCP TypeScript SDK Overview. • NIST, Least Privilege. • AWS Well-Architected Framework, Make mutating operations idempotent.