工具设定决定Agent上限

工具设定决定Agent上限很多Agent不是模型不行而是工具设计太差工具设计直接决定Agent的能力上限你给它一个含糊的工具它就只能猜你给它一堆粒度混乱的工具它就会乱选你给它一个返回值全是自然语言的工具它下一步就没法稳定判断工具不是API列表而是Agent的行动边界很多人一开始做工具调用思路是这样的“后端已经有一堆接口了我把这些接口都注册给大模型不就完事了吗”这也是很多Agent项目失控的开始后端API是给程序员用的Agent工具是给模型决策用的程序员调用API时脑子里面知道业务含义、调用时机、参数来源、异常处理模型不知道模型看到的只是工具名、工具描述、参数Schema和历史上下文如果你把一堆内部接口原样丢给模型比如queryDatagetInfosubmit那他只能猜所以工具设计的第一条原则就是工具不是把API暴露给模型而是把可控动作封装成模型能理解、能选择、能恢复的能力一个好的工具至少要回答四个问题这个工具能做什么什么时候应该使用它什么时候不应该使用它调用完之后Agent能不能根据结果继续判断如果这四个问题没回答清楚Agent就会开始自由发挥自由发挥听起来很智能但是放在生产里面就是不稳定工具描述不要只写“查询订单信息”很多工具描述写的特别随意比如{ name:get_order, description:查询订单信息 }这样的描述太浅了模型看完只能知道这个工具能查订单但是它不知道查的是订单基础信息还是支付、物理、退款状态用户只提供手机号时能不能用订单不存在时会返回什么这个工具适合排查什么问题他能不能替代退款工具对人来说“查询订单信息”也许够了对于Agent来说不够因为Agent要靠描述判断“下一步该不该用它”更好的描述应该这样写{ name:get_order_detail, description:根据订单ID查询订单的基础状态、支付状态和退款状态适用于用户询问订单进度、支付是否成功 }好的工具描述不只是说“能做什么”还要说清楚“适用边界”尤其是三类信息第一工具能解决什么问题比如“查询订单状态”“查询接口延迟”“检索知识库文档”不要写“处理用户请求”第二工具不能做什么比如查询工具不能修改数据草稿工具不能直接发送消息库存查询工具不能代表最终可购买数量这个“不做什么” 很重要因为Agent最怕把相似工具混在一起第三什么时候优先使用它工具描述不是注释工具描述就是Agent的使用说明书参数设计别把脏活都丢给模型工具描述决定模型会不会选对工具参数设计决定模型能不能把工具用对很多Agent工具的参数设计很重要{ name:search_logs, parameters:{ query:string } }看起来很灵活实际上很危险因为你把所有的脏活都丢给模型模型要自己决定查哪个服务查哪个时间段查什么日志级别查哪些关键词返回多少条这就很容易出问题他可能把时间写成“昨天晚上”它可能查了太宽的范围导致工具超时可能查了太窄的范围什么都查不到更好的方式是把参数拆清楚{ name: search_service_logs, description: 查询指定服务在固定时间范围内的日志用于排查接口错误、超时和异常调用链。, parameters: { type: object, properties: { service_name: { type: string, description: 服务名称例如 payment-service }, start_time: { type: string, description: 查询开始时间格式为 YYYY-MM-DD HH:mm:ss }, end_time: { type: string, description: 查询结束时间格式为 YYYY-MM-DD HH:mm:ss }, level: { type: string, enum: [ERROR, WARN, INFO], description: 日志级别排查故障时优先使用 ERROR 或 WARN }, keyword: { type: string, description: 可选关键词例如接口路径、错误码或 traceId } }, required: [service_name, start_time, end_time, level] } }这样Agent就不会随便编一个大字符串必须按照结构填参数这就是参数Schema的价值它不是为了让接口看起来高级他是为了模型的自由度约束在合理范围内参数设计有几个很实用的原则能枚举就枚举比如日志级别、订单状态、排序方式、操作类型能用enum就不要让模型自由填字符串自由字符串看似灵活但很容易出现errerrorERROR_LOG后端还要做一堆兼容枚举能减少很多不必要的不稳定时间、数量、范围要明确Agent很喜欢写模糊表达最近做完前几天这些对人能理解对工具不稳定工具参数里最好要求明确格式start_timeend_timelimitsort_by同时加上默认上限这些限制不是小题大做而是防止Agent一次调用把系统拖垮不要让一个参数承担多个含义比如{ user_input:帮我查一下张三昨天的订单 }这个参数就太混乱里面混了用户、时间、对象和意图工具端还要再做一次理解如果工具本身还要靠大模型再解析那你就把不确定性叠了两层更好的方式是拆开user_namedataquery_type参数越清楚Agent越稳定缺关键参数时不要让模型硬编缺少必要参数时先向用户询问返回值设计别只返回一段自然语言很多人只重视工具入参不重视工具返回值这也很容易出现问题比如一个订单查询工具返回{ result:订单已经支付目前正在仓库处理中预计明天发货 }人看当然没问题但是Agent下一步要怎么判断工具返回值的设计至少要包含三类信息第一状态字段比如successstatuserror_codeorder_statusrisk_level状态字段让Agent能做分支判断第二证据字段比如数据来源命中文档查询时间范围监控指标日志片段ID证据字段让Agent的最终回答不只是猜他能说“我根据什么得出这个结论”第三下一步提示比如{ suggested_next_actions: [ 如果用户询问物流单号可以调用 get_shipping_detail, 如果用户要求取消订单可以先调用 check_cancel_policy ] }这个字段不是必须的但是在复杂的Agent里面很有用他不是替代Agent做决定而是给Agent一个可靠的行动提示尤其是业务系统里面不同状态对应不同后续动作把这些动作提示词写在工具返回里面比让模型凭空猜稳定很多工具粒度太细会跑断太粗会失控工具粒度是Agent设计里面最容易纠结的问题工具应该设计的细一点还是粗一点答案是都不能太极端工具太细Agent会被迫做大量低级决策比如你给Agent这些工具get_user_id_by_phoneget_order_ids_by_user_idget_order_base_info这些工具单看都没问题但是如果用户只是问“我买的东西为啥还没发货”Agent可能需要连续调用五六次中间任何一步参数错了、结果空了、状态没记录好后面就断了工具太细会让Agent变成一个脆弱的流程编排器模型需要做太多机械步骤这不是它擅长的工具太粗Agent又看不见过程另一种极端是:handle_order_problemsolve_user_issueprocess_after_sales这种工具太粗Agent调用之后里面到底在做什么他不知道返回一个“处理成功”它也不知道成功在哪里出错了也不知道是订单不存在、支付失败、库存不足工具太细Agent表面上很省事但是系统会变成黑盒不可解释也不好调试合理粒度围绕一个业务动作封装一个工具完成一个清晰的业务动作并返回可判断的结构化结果工具粒度是要介于底层API和完整业务流程之间的太细会增加多步调用失败库太粗会降低可控性和可解释性。有副作用的工具必须单独设计边界Agent工具大致可以分为两类查询类工具和动作类工具查询类工具只读数据比如查订单、查日志、查监控、查知识库动作类工具会改变外部世界比如发邮件、提交退款、修改配置这两类工具绝对不能混在一起设计因为风险完全不一样查询错了最多答案不准动作错了就可能直接造成业务事故所以有副作用的工具至少要加三层保护读写工具分开不要设计这种工具{ name:handle_refuse, description:“处理退款问题” }它太模糊了处理退款到底是查规则还是直接提交退款更好的设计是拆开get_order_detailcheck_refund_policycreate_refund_draftsubmit_refund_after_user_confirm读是读写是写草稿是草稿边界越清楚越不容易出事故高风险动作必须二次确认凡是会影响钱、权限、数据、通知、生产环境的操作都不要让Agent单独决定比如退款扣费删除数据发送正式邮件改生产配置这些操作之前应该让Agent生成草稿或者执行计划然后让用户确认再调用真正的执行工具这不是智不智能这是工程安全一个成熟的Agent系统必须知道什么时候停下来让人确认工具返回要记录审计信息动作类工具返回值里面最好包含操作人操作对象操作时间操作前的状态操作后的状态审计ID是否需要人工复核这样的Agent后续回答就不会说我已经退款而应该说我已经创建退款申请草稿需要你确认后才会正式提交这就是工具边界带来的稳定性错误信息要能让Agent恢复很多工具失败时返回值只有一句{ success: false, message: 系统异常 }这对Agent没什么帮助他不知道接下来该重试、换参数、换工具还是告诉用户稍后重试好的错误返回应该能帮助Agent恢复Agent可以根据错误类型决定下一步缺参数就追问用户时间范围太大就缩小范围权限不足就说明无法执行工具超时可以有限重试错误信息不要只给人看也要给Agent看如果工具失败后Agent无法恢复它就很容易乱编一个答案很多幻觉不是从模型生成开始的而是从工具返回值太差开始的不要一次性把所有工具都塞给Agent工具越多Agent越强不一定工具越多选择空间越大选错概率也就越高如果你把订单、物流、退款、财务、监控等等全部塞给Agent它每一步都要在几十个工具里面选择这对模型不是增强这是干扰更好的方式是按照任务动态收敛工具集比如客服Agent处理订单问题时只给它订单查询物流查询退款规则查询退款草稿创建用户追问工具排查故障时只给它监控查询日志查询发布记录查询链路追踪查询写代码可以告诉它文件读取代码搜索测试执行补丁编辑工具集不是越大越好工具集要和当前任务相关这点和Agent vs Workflow是连接的Workflow 可以先判断任务类型再给Agent分配对应工具箱外层流程负责收口内部Agent负责开放搜索工具设计不好Agent会出现哪些症状判断工具设计有没有问题不用玄学看Agent的行为就知道如果经常出现下面这些情况大概率是工具设计有问题经常选错工具比如用户问退款规则agent却直接查物流这通常是工具描述太像边界不清晰解决方式是把每一个工具的使用场景和不适用场景写清楚参数经常填错比如时间格式错误、枚举填错、ID类型错误这些通常是参数Schema太松解决办法是收紧类型、枚举、必填项和格式说明调用后不知道下一步工具返回一大段自然语言Agent看完继续猜这通常是返回值没有状态字段和证据字段解决方式是返回结构化结果一直重复调用同一个工具比如知识库没搜到还连续搜索好几次这通常是缺少失败语义和停止条件解决方式是在返回值里面标记无结果原因并提示下一步应该追问用户或换策略做了不该做的动作比如用户只是咨询退款agent却直接提交退款这通常是读写边界不清没有二次确认解决方式是拆分查询、草稿和正式执行工具这些问题表面是Agent不稳定底层经常是工具契约没设计好