6.3 Agent调优与失控防护

6.3 Agent 调优与失控防护

失控的四种形态：循环不止（一个工具调八遍）、越权调用（用户没问订单它去查）、成本飞车（长历史滚雪球）、幻觉动作（编造工具参数）。防护是四道闸门的组合：迭代上限兜底、工具授权收窄、提示词约束引导、观测与熔断兜后。没有单点银弹，只有组合拳。

第 6 章收官。6.2 首跑成功的第二天，我遇到了本节所有翻车样本的原型——小艺在一条会话里连续调了八次 query_order，因为后端偶发返回空列表，它以为"再试一次也许就有了"。自主性放出去的账，这一节还。

一次真实的失控复盘

翻车会话的运行记录（节选）：

输入：帮我看看我的订单
轮次 1：query_order(keyword=我的订单) → 返回空列表（该用户近期无订单）
轮次 2：query_order(keyword=订单)     → 空
轮次 3：query_order(keyword=我的)     → 空
轮次 4-7：同上，参数在"我的订单/订单/买的东西"之间打转
轮次 8：撞上迭代上限，输出："抱歉，查询遇到问题。"
消耗：8 轮模型调用，token 是正常问答的十倍。用户体验：等了 40 秒，得到一句道歉。
​

根因链很清晰：工具返回没有告诉模型"为什么空"（空列表可以被理解为"没查到，换个词再试"，也可以是"该用户确实没有订单"——模型选了前者）。三层修复：其一，工具返回加字段 has_order: false 与 message: "该用户近三个月无订单记录"，把"空的原因"说清楚，模型就不会重试；其二，系统提示词加约束"同一工具参数几乎相同时不得连续调用超过两次"；其三，迭代上限从默认压到 5。三层分别对应工具层、提示词层、平台层——防护栏从来不是一根，是一排。

四道闸门逐个配

**闸门一，迭代上限。**Agent 设置里的最大迭代次数，循环的硬天花板。只读查询类 3 到 5 次绰绰有余（正常链路两三次收口）；上限给到两位数等于没有上限——每多一次可能，账单就多一分方差。把它当数据库连接超时一样配置：按最坏情况可以忍多少定。

**闸门二，工具授权。**每个工具有两种授权模式：自动（模型决定即执行）与需确认（平台暂停等人点头）。授权矩阵按"动作的可逆性"画：只读查询自动，写操作（退款、改址、发券）需确认或干脆不挂——5.3 的工作流加条件分支处理写操作，比 Agent 自主写安全一个量级。

**闸门三，提示词约束。**3.2 的说明书在 Agent 场景加一段"工具纪律"：

【工具纪律】
- 调用工具前先判断是否已有答案，避免重复调用。
- 同一工具参数基本相同时，最多调用两次。
- 工具返回为空或明确说明无记录时，如实告知用户，不得换词重试。
- 查询结果只报告给当前用户本人相关的信息。
​

四条对应四种失控形态的前三种。注意这些约束不是 100% 生效的——提示词是引导不是强制，所以它排在闸门一、二后面当第三层。

**闸门四，观测与熔断。**日志面板里按会话看工具调用轮次与 token 消耗，把"平均轮次"和"P95 轮次"拉成日常指标。熔断的含义：发现某个工具的失败率或重试率异常，先在工具页停用它（下架即时生效，Agent 自动降级为没有这个工具），修好再上。让"下架工具"成为五分钟内可执行的操作预案，这是运营 Agent 的底气。

图 6-3：失控形态与四道闸门的对应关系

调优后的验收数据

四道闸门配齐后跑两百条历史问题回放：平均工具调用轮次 1.8（此前 2.9），P95 轮次 4（此前 8 以上），越权调用 0（授权矩阵生效），因上限截断的会话占 1.5%（全是"查无记录"类，触发兜底话术转人工——行为符合设计）。成本侧，单次咨询平均 token 降了约四成。这份验收与 4.3 的召回验收同一方法论：先定义指标，再改，用数字证明改对了。

问题：迭代上限设多少合适？5 次会不会太少？

按"正常链路最长几步"加一两次余量来定，不按直觉。小艺的正常链路：查订单、查物流、收口，最多三轮，上限 5 已含两次容错。你的 Agent 若有四工具串行的链路，正常就要四轮，上限得给 6 到 7。判断上限是否合理有个观测法：看截断会话的占比——长期低于 2% 说明余量健康；若 5% 以上的会话撞上限，要么上限太紧，要么链路设计本身该收敛（比如把固定两步合并进一个工具）。上限是安全网，不是惩罚机制。

问题：防护栏会拖慢 Agent 吗？

几乎不会。四道闸门里，迭代上限与工具授权是零成本的控制逻辑，由平台执行器在循环间判断，不增加模型调用；提示词纪律只多了几十个 token 的系统提示词，相对整轮历史可以忽略。真正可能拖慢的是"需确认"模式——它等人点击，时间不可控。所以生产环境的时间敏感链路里，需确认要么不开，要么配上超时自动降级（超时走无工具的纯文本回答并提示转人工）。防护与性能并不冲突，冲突的只有"等人类点头"这一种。

变式：两种稳健形态

**变式一，工作流包 Agent。**把 Agent 作为工作流里的一个节点：外层流程做确定性预处理（分类、鉴权、参数提取），只把"确实需要自主判断"的子问题交给 Agent 节点，结果回到流程里校验后再输出。控制权光谱（图 6-1）上这是从右往左收回半步，生产系统里我最推荐这个形态。**变式二，多 Agent 协作。**复杂任务拆成多个单职责 Agent（一个只查、一个只写文案），由一个协调者串起。能力更强，复杂度与调试成本也翻倍——没有 6.1 的读轨迹基本功，别急着上。

⚠️ 常见坑：把防护全押在提示词上。四道闸门里提示词是唯一"软"的——模型大概率遵守、偶尔失忆。迭代上限与授权矩阵是硬的，必须先配硬的再用软的补细节。顺序反了，等于用劝说代替门锁。

本节要点回顾

• 失控四形态：循环、越权、成本、幻觉，各有专属闸门，组合防护；
• 工具返回说清"为什么空"：模型不猜，重试自然消失——工具层是最高性价比的防护层；
• 硬闸先于软闸：迭代上限与授权矩阵是门锁，提示词纪律是门牌；
• 观测日常化：平均与 P95 轮次、失败率、单会话 token，异常即下架工具；
• 回放验收：拿历史问题做回归，指标定义先于调优；
• 三个不该用 Agent 的信号：流程可枚举、错误不可逆、纯问答——分别推回工作流、流程加人工、检索链路。

小艺至此三件能力齐备且全部带防护。最后一章收口整条流水线：把它正式交付进业务系统，并让它长期健康地跑下去。