Agent 项目面试里，很多人会讲规划、反思、多轮对话和工具调用。但真正上生产后，最难的往往不是让模型“会调用工具”，而是让它在合适的时候、用正确参数、以可追踪的方式调用工具，并且出错后能收场。
一旦 Agent 可以查数据库、发消息、改配置、创建工单、执行代码，它就不再只是生成文本的模型，而是在触发真实系统副作用。后端设计必须从“模型会不会用工具”升级到“工具执行能不能被控制”。
工具 schema 不是注释，而是合同
工具参数要有明确 schema，字段类型、枚举值、必填项、范围、默认值都要写清楚。模型输出的参数不能直接信任，必须经过服务端校验。比如金额、日期、用户 ID、资源范围、操作类型，都不能只靠提示词约束。
更稳的做法是把工具分成只读工具和有副作用工具。只读工具可以相对宽松，但仍要做权限过滤；有副作用工具必须经过更严格的参数验证、幂等键、审批或确认。这个分类比“我给模型写了工具说明”重要得多。
权限不能交给模型判断
Agent 经常需要根据用户身份访问不同数据。这里最危险的做法是把权限规则写进 prompt，让模型自己决定能不能查。权限必须在后端系统里执行，模型最多提出意图，最终由服务端根据用户、角色、资源和操作判断是否允许。
企业场景尤其如此。一个销售只能看自己的客户，一个部门经理只能看本部门数据，一个知识库问题只能检索用户有权访问的文档。权限过滤应该发生在工具执行前，而不是生成答案后再试图删除敏感内容。
幂等和审计是上线门槛
Agent 可能因为网络超时、模型重试、用户重复点击、任务恢复而多次调用同一个工具。如果工具会创建订单、发送通知、修改状态，就必须有幂等设计。请求 ID、业务唯一键、状态机流转、重复提交识别，都要提前准备。
审计同样重要。每次工具调用至少要记录用户、会话、模型输出、最终参数、权限判断、执行结果和耗时。出了问题时，不能只在日志里看到“模型调用失败”，而要能复盘到底是哪一步错了：意图理解错、参数校验漏了、权限判断错了，还是下游系统失败。
人工确认不是产品妥协
对高风险操作，人工确认是工程设计的一部分。比如删除数据、发送外部邮件、提交付款、修改生产配置，Agent 可以生成操作草案，但执行前应让用户确认关键字段。确认页不能只显示“是否继续”，要把影响范围、目标对象和不可逆后果展示清楚。
这不是让 Agent 变笨，而是把责任边界做清楚。低风险动作自动化，高风险动作半自动化，才是企业系统更容易接受的落地方式。
失败路径要先设计
工具调用会失败：参数不合法、权限不足、下游超时、网络断开、执行一半失败。Agent 不能只把错误包装成一句抱歉。系统要知道哪些失败可以重试，哪些必须停止，哪些需要补偿，哪些要通知人工介入。
面试里可以这样总结：Agent 工具调用的生产化，不是把函数列表塞进上下文，而是把工具当成后端接口治理。schema 校验、权限控制、幂等、审计、确认和补偿都到位，Agent 才能从演示走向可运营系统。