边界扩张比功能追加更危险
用户会不断提出「能不能顺手也做这个」，每接一个都在扩大失败面与责任范围。边界文档应写明不处理哪些请求与理由，新增用途必须走变更流程，否则智能体会在半年内变成一个谁都说不清用途的系统，维护成本也随之失控。
权限升级要单独审批
从只读升到建议、从建议升到可执行，每一次都应视为独立变更，附评测结果与审批记录。权限一旦放开就很难收回，业务方会形成依赖并以此为由反对收紧，因此每次升级前都要想清楚回退路径与责任人。
动作清单要冻结
上线前把动作清单与对应的权限档位冻结，冻结后新增动作需重新走评测与审批。没有冻结动作的智能体会在迭代中悄悄多出几个写接口，等到出事才发现没人记得是谁加的，日志里也找不到变更记录。
灰度看异常而非只看成功率
灰度期要重点观察越权拦截次数、工具失败率与人工接管原因，而不只是任务成功率。成功率好看但越权拦截频繁，说明边界正在被试探，此时放量等于把风险复制到更大范围，后续处理成本会成倍上升。
变更记录要能回答三个问题
谁提出的、影响哪些动作、谁批准的，这三项应能在一次查询里看到。记录不全时，事故复盘会变成互相推诿；记录完整时，同样的问题第二次出现就能快速定位到具体环节与责任人，整改也更有针对性。
适用与不适用
适合谁
- 需求方多、容易扩展用途的智能体项目
- 涉及写操作、需要风控评审的场景，需要提前设防
- 已上线并准备逐步放量的智能体，需要明确责任
不适合谁
- 仅做内部演示、不接入真实系统的试验
- 不接受权限分级与变更审批的团队
典型场景
某运营商的智能体上线两个月后，业务方提出让它直接修改套餐状态。项目组按变更流程评估，发现该动作属于写操作且无回滚接口，暂缓实施。同期灰度数据显示越权拦截次数上升，团队据此补充了边界文档与拒答话术，放量计划推迟两周，但避免了后续更大范围的误操作。
可执行步骤
- 写出边界文档，列明不处理的请求类型与拒绝理由，并由业务确认，作为后续变更的基准
- 把动作清单与权限档位在上线前冻结，形成可查询的版本记录，便于审计与复盘
- 任何权限升级都要求附评测结果、回滚方案与审批人签字，由安全团队确认
- 灰度期重点看越权拦截、工具失败率与接管原因，而非只看成功率，作为放量依据
常见坑
- 边界只写在需求文档里、没有对外说明，用户不断试探，智能体被推着做越来越多的事，最终无人能说清它的用途。
- 权限升级走口头同意，事后没有任何记录，出问题时无法证明谁批准过，整改也只能靠猜；整改也缺乏依据。
- 动作清单不冻结，迭代中悄悄多出写接口，日志里找不到变更记录，复盘时各执一词，责任也难以厘清。
- 灰度只看成功率，忽略越权拦截次数，放量后风险被成倍复制，处理成本远高于当初省下的时间，影响面也更广。
自检与验收清单
- 边界文档是否写明不处理的请求与理由，是否有人签字
- 动作清单与权限档位是否已冻结，是否可查询，是否可随时查询
- 权限升级是否有评测、回滚与审批记录，是否留有记录
- 灰度是否统计越权拦截与接管原因，是否每周统计
常见问题
边界能不能先宽后窄？
不建议。先宽后窄意味着上线初期就承担了不必要的风险，收紧时还会遇到业务方阻力。更稳妥的做法是从窄边界起步，用运行数据证明稳定后再逐项扩展，每次扩展都留观察期与回退方案。
业务方绕过流程直接找开发怎么办？
把流程写进项目管理规则，由产品负责人统一受理，开发侧不接受口头需求。同时保留一个快速通道处理真正紧急的变更，但要求书面说明与事后补评审，避免流程被完全架空。
越权拦截次数多少算异常？
没有统一阈值，应以上线首月的数据为基线观察趋势。持续上升通常说明用户在与边界博弈，或提示话术不够清楚；此时应优先改提示与拒答话术，而不是简单加拦截规则，否则体验会明显变差。