Agent 做完任务就交卷我加了个哨兵工具它自己揪出 3 个错给 Agent 增加一个哨兵工具强制模型在交卷前自我验证漏检率从 31% 降到 4%额外延迟仅 0.4 秒。Agent 默认完成工具调用后直接返回结果缺乏自我验证。通过定义哨兵工具并修改执行循环强制模型在结束前调用一次验证漏检率从 31% 降至 4%额外 token 成本约 120 个。Agent 完成工具调用后通常直接返回结果但生产环境中经常发现模型自以为完成实则遗漏关键步骤或错误理解数据。通过定义一个 verify_result 哨兵工具修改执行循环使其在检测到任务完成迹象时强制触发一次自我验证实测漏检率从 31% 降到 4%额外延迟约 0.4 秒token 成本增加约 120 个。本文提供完整可运行的 TypeScript 实现。先上代码后面解释我为什么这么写。// 哨兵工具让 Agent 在交卷前自检constverifyResultTool{type:functionasconst,function:{name:verify_result,description:任务完成前必须调用对照预期目标检查实际结果列出遗漏项和错误项,parameters:{type:object,properties:{task_goal:{type:string,description:原始任务目标},actual_result:{type:string,description:当前实际结果摘要},missing_items:{type:array,items:{type:string},description:遗漏或未完成的子项},errors_found:{type:array,items:{type:string},description:发现的错误或不一致},is_ready:{type:boolean,description:确认结果完整且正确可以提交}},required:[task_goal,actual_result,missing_items,errors_found,is_ready]}}};这就是哨兵工具的全部定义。它看起来像个普通工具但有个关键细节description里用了必须调用和完成前这种强制时态词。我实测过把必须换成可以或者建议调用率从 87% 跌到 34%。模型对时态词和语气词很敏感这算是个小窍门。完整的执行循环长这样interfaceToolCall{id:string;type:function;function:{name:string;arguments:string};}asyncfunctionrunAgentWithSentinel(userQuery:string){constmessages[{role:systemasconst,content:你是任务执行助手。完成所有工具调用后、给出最终答案前必须调用 verify_result 检查一遍。 规则 - 不要连续调用同一个工具超过 2 次 - 如果 verify_result 返回 is_readyfalse继续修正然后再次调用 verify_result - 最多进行 3 轮验证},{role:userasconst,content:userQuery}];constallTools[searchTool,calculateTool,formatTool,verifyResultTool];letstepCount0;constmaxSteps20;while(stepCountmaxSteps){stepCount;constresponseawaitcallLLM(messages,allTools);constchoiceresponse.choices[0];// 普通文本回复直接返回if(!choice.message.tool_calls){returnchoice.message.content;}consttoolCallschoice.message.tool_calls;// 执行所有工具调用for(constcalloftoolCalls){constargsJSON.parse(call.function.arguments);constresultawaitexecuteTool(call.function.name,args);messages.push({role:toolasconst,tool_call_id:call.id,content:JSON.stringify(result)});}// 检测到哨兵工具被调用constsentinelCalltoolCalls.find(cc.function.nameverify_result);if(sentinelCall){constargsJSON.parse(sentinelCall.function.arguments);if(args.is_readytrueargs.missing_items.length0args.errors_found.length0){// 自检通过再给它一次机会表达最终结果messages.push({role:userasconst,content:验证已通过请给出最终答案。});continue;}if(stepCountmaxSteps-2){return[验证未通过但已耗尽步数] 遗漏${args.missing_items.join(, )}错误${args.errors_found.join(, )};}// 验证失败自动注入修正指令messages.push({role:userasconst,content:验证发现问题请修正遗漏${args.missing_items.join(、)}错误${args.errors_found.join(、)}。修正后再次调用 verify_result。});}}return步数耗尽任务未完成;}这个循环的核心就一点不拦截模型的正常思考流程只在它以为自己完成了的时候插一道验证关卡。你可能会问模型真的会认真检查吗还是随便填个is_readytrue敷衍了事我一开始也这么想。毕竟这跟让学生自己批改试卷有什么区别但实测数据让我改了主意。在 200 组任务里模型调用verify_result时有 63 组主动报告了missing_items或errors_found非空。其中 47 组在后续修正轮中确实补上了遗漏。16 组报了问题但修正时还是没修对——这属于模型对任务理解本身就有偏差哨兵也救不了。但 47 组实打实的补漏说明模型不是敷衍它是真的没注意到。我给你说一个具体的例子。用户问的是查一下北京和上海今天的天气顺便告诉我紫外线指数。Agent 调了天气 API拿到了北京温度 32°C 和上海的 28°C然后觉得自己做完了准备直接回答。哨兵工具这时候被触发模型一检查等等紫外线指数还没查。于是调了紫外线 API把 UV 指数补上。这整个修正过程是完全自动的不需要人工干预。这种场景在生产环境里太常见了。模型在处理多步骤任务时很容易做了前半段忘了后半段或者把顺便这种次要请求当成装饰性语句给忽略掉。你当人类没干过这种事吗我上周让同事帮忙打印文件顺便装订结果只打印了装订根本没管。人都会漏模型凭什么不漏哨兵工具在什么场景下最值我的经验是查询聚合类任务最划算。比如查近三天销量 Top 5 的商品和对应库存模型可能查了销量就忘了库存或者把 Top 5 理解成了 Top 3。哨兵工具能 catch 这种做了一半以为全做完了的错觉。我手头的数据是这类任务不加哨兵漏检率 31%加了之后降到 4%。单步查询任务也有收益但没那么夸张。漏检率从 8% 降到 2%属于锦上添花。不过考虑到额外延迟才 0.3 秒顺手加一道也不亏。纯计算类任务反而收益低。112 这种模型几乎不会错加了哨兵就是浪费 0.4 秒。你要是用 Agent 做大量纯数学运算哨兵可以省掉。但有个坑我得提醒你。哨兵工具不能放在tools数组的最后一位。我测过放在末尾时模型调用率 71%放在前四位的任意位置时调用率 87% 到 91%。我怀疑这跟注意力机制有关——模型对列表开头和中间的关注度高于末尾。这道理其实跟写简历一样放太后面的技能HR 可能根本看不见。system prompt 里的验证规则也别写太长。我原来写了 8 条验证细则调用率反而降到 52%。后来砍到 3 条调用率回涨到 89%。这跟 system prompt 精简的逻辑是一样的规则越多模型越装看不见。这玩意不是写得多就管用精炼到没法再省略的那几条才是真的有约束力。场景无哨兵漏检率有哨兵漏检率额外延迟额外 token查询聚合31%4%0.4s~120单步查询8%2%0.3s~90纯计算2%1%0.4s~110说实话我最初对这个技巧没抱多大希望。毕竟让模型自己检查自己听起来像个悖论。但数据摆在这儿31% 到 4% 的落差我没什么好辩解的。而且那 120 个额外 token 的成本换算成调用费用大概是 0.0003 美元——花不到一厘钱换 27% 的漏检减少这买卖怎么算都值。当然哨兵不是银弹。如果模型对任务本身的理解就是错的那它检查的结论也是错的。这种根本性的理解偏差哨兵拦不住。比如用户问2023 年 Q3 的数据模型理解成了2024 年 Q3那它检查一百遍也查不出这个错——因为从一开始的任务目标就是歪的。还有一种情况是模型过度谨慎哨兵阶段报告了一堆不存在的遗漏。我在测试里遇到过几次模型查完了所有数据调用verify_result时突然说我可能漏了历史趋势分析然后强行再去查一轮结果用户根本没问这个。这种情况在 system prompt 里加一句只验证用户明确要求的内容不要自行扩展范围就能缓解大半。部署这套机制我大概花了两个小时。第一版其实更复杂我想给每个工具都配一个专门的验证工具结果工具列表膨胀到原来的三倍模型调用率直接崩盘。后来收敛成这一个通用哨兵反而效果最好。有时候做减法比做加法难你得忍住那种把所有可能性都覆盖到的冲动。顺便一提我在做的那个收录一人公司案例的 App 雷达鸭客服 Agent 也跑着这套哨兵机制华为应用市场能搜到。你有没有在生产环境里试过让 Agent 自我验证效果怎么样关于作者老三10 年以上软件开发经验软件设计师人工智能应用工程师。专注鸿蒙应用开发ArkTS北向开发 Web 前端探索 AI 自动化。不定期在 CSDN 分享鸿蒙 / AI 方向技术文章。本文遵循 MIT 协议转载请注明出处。
Agent 做完任务就交卷我加了个哨兵工具它自己揪出 3 个错给 Agent 增加一个哨兵工具强制模型在交卷前自我验证漏检率从 31% 降到 4%额外延迟仅 0.4 秒。Agent 默认完成工具调用后直接返回结果缺乏自我验证。通过定义哨兵工具并修改执行循环强制模型在结束前调用一次验证漏检率从 31% 降至 4%额外 token 成本约 120 个。Agent 完成工具调用后通常直接返回结果但生产环境中经常发现模型自以为完成实则遗漏关键步骤或错误理解数据。通过定义一个 verify_result 哨兵工具修改执行循环使其在检测到任务完成迹象时强制触发一次自我验证实测漏检率从 31% 降到 4%额外延迟约 0.4 秒token 成本增加约 120 个。本文提供完整可运行的 TypeScript 实现。先上代码后面解释我为什么这么写。// 哨兵工具让 Agent 在交卷前自检constverifyResultTool{type:functionasconst,function:{name:verify_result,description:任务完成前必须调用对照预期目标检查实际结果列出遗漏项和错误项,parameters:{type:object,properties:{task_goal:{type:string,description:原始任务目标},actual_result:{type:string,description:当前实际结果摘要},missing_items:{type:array,items:{type:string},description:遗漏或未完成的子项},errors_found:{type:array,items:{type:string},description:发现的错误或不一致},is_ready:{type:boolean,description:确认结果完整且正确可以提交}},required:[task_goal,actual_result,missing_items,errors_found,is_ready]}}};这就是哨兵工具的全部定义。它看起来像个普通工具但有个关键细节description里用了必须调用和完成前这种强制时态词。我实测过把必须换成可以或者建议调用率从 87% 跌到 34%。模型对时态词和语气词很敏感这算是个小窍门。完整的执行循环长这样interfaceToolCall{id:string;type:function;function:{name:string;arguments:string};}asyncfunctionrunAgentWithSentinel(userQuery:string){constmessages[{role:systemasconst,content:你是任务执行助手。完成所有工具调用后、给出最终答案前必须调用 verify_result 检查一遍。 规则 - 不要连续调用同一个工具超过 2 次 - 如果 verify_result 返回 is_readyfalse继续修正然后再次调用 verify_result - 最多进行 3 轮验证},{role:userasconst,content:userQuery}];constallTools[searchTool,calculateTool,formatTool,verifyResultTool];letstepCount0;constmaxSteps20;while(stepCountmaxSteps){stepCount;constresponseawaitcallLLM(messages,allTools);constchoiceresponse.choices[0];// 普通文本回复直接返回if(!choice.message.tool_calls){returnchoice.message.content;}consttoolCallschoice.message.tool_calls;// 执行所有工具调用for(constcalloftoolCalls){constargsJSON.parse(call.function.arguments);constresultawaitexecuteTool(call.function.name,args);messages.push({role:toolasconst,tool_call_id:call.id,content:JSON.stringify(result)});}// 检测到哨兵工具被调用constsentinelCalltoolCalls.find(cc.function.nameverify_result);if(sentinelCall){constargsJSON.parse(sentinelCall.function.arguments);if(args.is_readytrueargs.missing_items.length0args.errors_found.length0){// 自检通过再给它一次机会表达最终结果messages.push({role:userasconst,content:验证已通过请给出最终答案。});continue;}if(stepCountmaxSteps-2){return[验证未通过但已耗尽步数] 遗漏${args.missing_items.join(, )}错误${args.errors_found.join(, )};}// 验证失败自动注入修正指令messages.push({role:userasconst,content:验证发现问题请修正遗漏${args.missing_items.join(、)}错误${args.errors_found.join(、)}。修正后再次调用 verify_result。});}}return步数耗尽任务未完成;}这个循环的核心就一点不拦截模型的正常思考流程只在它以为自己完成了的时候插一道验证关卡。你可能会问模型真的会认真检查吗还是随便填个is_readytrue敷衍了事我一开始也这么想。毕竟这跟让学生自己批改试卷有什么区别但实测数据让我改了主意。在 200 组任务里模型调用verify_result时有 63 组主动报告了missing_items或errors_found非空。其中 47 组在后续修正轮中确实补上了遗漏。16 组报了问题但修正时还是没修对——这属于模型对任务理解本身就有偏差哨兵也救不了。但 47 组实打实的补漏说明模型不是敷衍它是真的没注意到。我给你说一个具体的例子。用户问的是查一下北京和上海今天的天气顺便告诉我紫外线指数。Agent 调了天气 API拿到了北京温度 32°C 和上海的 28°C然后觉得自己做完了准备直接回答。哨兵工具这时候被触发模型一检查等等紫外线指数还没查。于是调了紫外线 API把 UV 指数补上。这整个修正过程是完全自动的不需要人工干预。这种场景在生产环境里太常见了。模型在处理多步骤任务时很容易做了前半段忘了后半段或者把顺便这种次要请求当成装饰性语句给忽略掉。你当人类没干过这种事吗我上周让同事帮忙打印文件顺便装订结果只打印了装订根本没管。人都会漏模型凭什么不漏哨兵工具在什么场景下最值我的经验是查询聚合类任务最划算。比如查近三天销量 Top 5 的商品和对应库存模型可能查了销量就忘了库存或者把 Top 5 理解成了 Top 3。哨兵工具能 catch 这种做了一半以为全做完了的错觉。我手头的数据是这类任务不加哨兵漏检率 31%加了之后降到 4%。单步查询任务也有收益但没那么夸张。漏检率从 8% 降到 2%属于锦上添花。不过考虑到额外延迟才 0.3 秒顺手加一道也不亏。纯计算类任务反而收益低。112 这种模型几乎不会错加了哨兵就是浪费 0.4 秒。你要是用 Agent 做大量纯数学运算哨兵可以省掉。但有个坑我得提醒你。哨兵工具不能放在tools数组的最后一位。我测过放在末尾时模型调用率 71%放在前四位的任意位置时调用率 87% 到 91%。我怀疑这跟注意力机制有关——模型对列表开头和中间的关注度高于末尾。这道理其实跟写简历一样放太后面的技能HR 可能根本看不见。system prompt 里的验证规则也别写太长。我原来写了 8 条验证细则调用率反而降到 52%。后来砍到 3 条调用率回涨到 89%。这跟 system prompt 精简的逻辑是一样的规则越多模型越装看不见。这玩意不是写得多就管用精炼到没法再省略的那几条才是真的有约束力。场景无哨兵漏检率有哨兵漏检率额外延迟额外 token查询聚合31%4%0.4s~120单步查询8%2%0.3s~90纯计算2%1%0.4s~110说实话我最初对这个技巧没抱多大希望。毕竟让模型自己检查自己听起来像个悖论。但数据摆在这儿31% 到 4% 的落差我没什么好辩解的。而且那 120 个额外 token 的成本换算成调用费用大概是 0.0003 美元——花不到一厘钱换 27% 的漏检减少这买卖怎么算都值。当然哨兵不是银弹。如果模型对任务本身的理解就是错的那它检查的结论也是错的。这种根本性的理解偏差哨兵拦不住。比如用户问2023 年 Q3 的数据模型理解成了2024 年 Q3那它检查一百遍也查不出这个错——因为从一开始的任务目标就是歪的。还有一种情况是模型过度谨慎哨兵阶段报告了一堆不存在的遗漏。我在测试里遇到过几次模型查完了所有数据调用verify_result时突然说我可能漏了历史趋势分析然后强行再去查一轮结果用户根本没问这个。这种情况在 system prompt 里加一句只验证用户明确要求的内容不要自行扩展范围就能缓解大半。部署这套机制我大概花了两个小时。第一版其实更复杂我想给每个工具都配一个专门的验证工具结果工具列表膨胀到原来的三倍模型调用率直接崩盘。后来收敛成这一个通用哨兵反而效果最好。有时候做减法比做加法难你得忍住那种把所有可能性都覆盖到的冲动。顺便一提我在做的那个收录一人公司案例的 App 雷达鸭客服 Agent 也跑着这套哨兵机制华为应用市场能搜到。你有没有在生产环境里试过让 Agent 自我验证效果怎么样关于作者老三10 年以上软件开发经验软件设计师人工智能应用工程师。专注鸿蒙应用开发ArkTS北向开发 Web 前端探索 AI 自动化。不定期在 CSDN 分享鸿蒙 / AI 方向技术文章。本文遵循 MIT 协议转载请注明出处。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
