Tool Calling 让大模型可以调用后端函数，比如查订单、查报表、创建任务、发送通知。它看起来很像“自然语言调用接口”，但工程上必须更谨慎。
我的判断： Tool Calling 不是把 Java 方法暴露给模型这么简单，它本质上是新增了一类调用入口。入口越智能，后端边界越要硬。
工具要小而明确
一个工具最好只做一件事。比如 queryCampaignCost 比 operateAdPlatform 安全得多。工具粒度越大，模型误用的风险越高。
参数要有 Schema
工具入参不能只靠自然语言描述。要明确字段类型、必填项、枚举值、范围和默认值。后端仍然要做二次校验，不能因为调用方是模型就放松。
权限不能交给模型判断
模型可以选择工具，但不能决定用户有没有权限。权限校验必须在服务端执行，和普通接口一样走登录态、角色、数据范围。
失败要可解释
工具调用失败时，要返回模型能理解、用户也能理解的错误。比如“时间范围不能超过 31 天”，比“SQL Error”更适合进入对话。
实际场景：让模型查 BI 状态或广告任务结果
Tool Calling 最适合的第一个落地场景，不是让模型直接“操作系统”，而是让它查询已有后端能力。比如用户问“昨天那个标签历史版本算完了吗”“这个批创任务失败在哪里”“某个项目今天花费有没有同步”，这些问题本质上已经有接口，只是入口分散、参数多、用户不一定知道去哪里查。
工具设计时，我会先选只读能力。比如 queryBatchCreateStatus 查询批创任务状态，入参是 batchId；queryUserGroupCalcStatus 查询分群计算状态，入参是 groupId；queryMediaSyncSummary 查询媒体同步摘要，入参是 projectId 和 dateRange。只读工具的风险低，适合验证权限、参数校验、日志审计和回答格式。
参数 schema 要尽量窄。日期范围最多 31 天，项目 ID 必须属于当前用户，任务 ID 必须和用户所在租户匹配，枚举值必须在服务端定义。模型可以帮助用户补全参数，但不能绕过后端规则。比如用户说“查所有项目”，后端应该根据用户权限展开，而不是真的允许传空项目范围。
工具返回值要面向对话，而不是直接返回数据库实体。批创状态可以返回总数、成功数、失败数、主要失败原因和重提建议；BI 分群状态可以返回当前阶段、进度、最近一次日志和是否可重试；媒体同步摘要可以返回处理账号数、失败账号数、限流次数和最后同步时间。这样模型能给出有用解释，而不是把 JSON 原样丢给用户。
下一步才是写操作，比如“重跑失败项”“刷新分群”“触发看板预计算”。写操作一定要更谨慎：需要二次确认、权限校验、幂等键、审计日志和操作结果回传。尤其是会影响业务数据或调用第三方媒体接口的工具，不能因为用户一句自然语言就执行。
Spring AI 的 Tool Calling 能把 Java 方法暴露给模型，但生产落地的核心仍然是后端工程能力：工具粒度、参数约束、权限边界、错误语义、审计和回滚。模型只是新的调用入口，不是系统边界的替代品。
我会把工具调用当成一次普通后端请求来治理。每个工具都要有 owner、风险等级、调用上限、超时时间和降级策略。查询类工具可以返回缓存结果，写操作工具必须走数据库事务或任务表，不能让模型直接跨服务串联多个不可回滚动作。工具执行前后也要记录输入摘要和输出摘要，方便复盘。
还有一个容易忽略的点是“模型解释”和“真实执行”要分离。模型可以解释它准备做什么，但真正执行必须以服务端校验后的参数为准。比如模型说“查询最近一个月”，服务端仍要把时间范围转换成明确的起止日期，并校验不超过限制。这样回答和执行才不会出现偏差。