FDE岗位实务指南 · 第17篇上一篇讲的是做错了怎么定位。这一篇往前退一步能不能让错误根本发不出手Agent 时代的典型场景是这样的演示里Agent 听懂指令、调起工具、动作执行一气呵成掌声响起。掌声落下之后懂行的人会问一个问题它刚才做的那个动作是被允许的吗这个问题不是挑剔是 Agent 从演示走向生产之前必须跨过的门槛——演示考验的是能不能做生产考验的是只做该做的。不是问技术上能不能调通——接口能调通恰恰是最简单的部分——而是问以这个身份、对这个对象、在对象当前的状态下这个动作在业务上成立吗太多团队把这个问题交给了提示词。你是一个谨慎的助手不要越权操作——这句话写进系统提示里演示时确实有效因为演示不会遇到真正的越界请求。可提示词是建议不是闸门。模型可以误解、可以被诱导、可以在多轮对话里忘记最初的约束。把失效方式说具体误解是模型把不要越权理解成了不要频繁操作诱导是用户在对话里一步步把 Agent 引向它本不该做的动作每一小步看起来都人畜无害忘记是上下文一长最早的约束被挤出了模型的注意力窗口。三种方式没有一种是恶意结果都一样——约束在执行的那一刻不在场。授权和业务约束必须在执行路径上成立写在提示词或界面说明里的都不算数。一、工具可调用为什么业务动作仍不能执行先把两个概念分开。工具可调用是技术事实接口存在、参数合法、网络通畅。业务动作可执行是业务判断发起者有授权、对象是范围内对象、对象当前状态允许这个动作、动作引用的依据仍然有效。前者是后者的必要非充分条件。把业务上成立再拆细一点是四个必须同时回答是的问题发起人是谁——以真实身份计他有没有这个动作的授权对象是谁——在不在他被允许的范围内对象现在什么状态——这个状态允不允许这个动作发生动作依据的是什么——依据的版本、数据、确认此刻还有没有效四个问题里任何一个答不上是动作就该被拦下。技术接口只能替你回答调不调得通这四个问题一个都替不了。澄川制造的两起教学事件合成设定把这个差别演得很清楚。第一起申请 A-017 的提案原本是 v1核验员甲打开过 v1 并准备确认。申请人这期间把提案改成了 v2——用途描述改了金额也动了。核验员的界面上还停着 v1 的内容。如果确认动作只检查甲是核验员、A-017 存在甲的确认就会落在 v2 的单据上依据却是 v1 的内容。权限是对的动作是错的——因为确认的对象版本和确认者看到的版本不一致。第二起一位测试者教学设定在研究表格配置时把自己的角色列从申请人改成了核验员然后尝试确认一张申请。如果系统只读表格上的角色字段这次冒充就成立了。真实身份——账号在权限系统里登记的角色——从未获准确认权限。两起事件一个是合法身份做了过期动作一个是伪造身份做了越权动作。它们的共同点在于单看调用都没问题问题都出在执行路径上缺少校验。二、将身份、对象范围与动作对应防线的第一层是授权矩阵谁对哪些对象可以做什么动作。三个维度缺一个都不完整。澄川的授权与状态条目教学设定是这样写的核验员甲仅可确认其负责范围内的申请申请人可修改自己名下处于待补充状态的申请单系统负责人可配置工作流但不可确认业务单据。注意每一条都是身份 对象范围 动作三元组——核验员可以确认这种两元写法是不合格的因为它没回答对谁的申请、什么状态的申请。这里的关键纪律是身份以权限系统的真实登记为准不以请求自带的声明为准。第二起事件的根因就是系统信了请求里的角色字段。请求里的一切声明——我是核验员我有权这是管理员操作——都只是待验证的输入验证的依据是服务端独立掌握的身份记录。这条纪律在普通系统里是老生常谈在 Agent 场景里要再拧紧半圈Agent 替人发起动作时请求链路上多了一层转述每一层转述都是身份被粉饰的机会。执行端必须穿透到最终真实身份来校验不能采信中间环节的转述。回到第二起事件它的工程含义值得多说一句。表格上的角色列是业务数据不是安全边界——任何用户可写或可被配置流程改写的字段都不能作为授权依据。这道线画错了后面所有的检查都是在沙地上盖楼。正确的做法是授权决策只读取权限系统的登记数据表格里的角色列顶多用于界面展示展示错了顶多是误导不至于放行。一张能用的授权矩阵每一行都要能直接翻译成执行层的检查代码。核验员甲—负责范围内申请单—确认这一行翻译出来是三个校验身份校验请求的真实身份是甲且角色为核验员、范围校验目标申请单属于甲的负责范围、动作校验该角色对该范围内对象开放确认动作。翻译成不了检查的矩阵行都是还没有想清楚的矩阵行。矩阵的粒度是个权衡。太粗——采购组都能确认——执行时人人有权等于人人无责太细——每张单子单独授权——维护成本会吞掉收益。实务上的起点是按角色和对象类别划跑起来之后再对出过事的格子加密。A-017 这类单据就是因为金额阈值的存在天然比低值单据多一道负责人复核的格子。矩阵写出来只是第一步它还要回答一个更细的问题范围怎么界定。甲负责一车间——一车间的申请单怎么标识按部门字段、按物料类别、还是按审批流的节点归属范围的判定规则要写进矩阵否则范围内三个字在执行时就是一笔糊涂账。三、检查当前版本和业务状态防线的第二层是状态动作落下去的那一刻对象处于什么状态、依据是否仍然有效。为什么状态检查非做不可因为授权矩阵回答的是你是谁、能对谁做什么回答不了现在能不能做。同一个人、同一个对象、同一个动作昨天合法、今天可能就不合法——区别全在对象走过的状态路径上。把状态检查省掉的系统等于默认业务是静止的而业务恰恰从不静止。A-017 的案例说明了一切。确认动作的正确前提不是A-017 存在而是一组状态条件的合取提案处于待确认状态确认引用的提案版本与当前版本一致申请所附资料处于已核验完整状态。甲对着 v1 的内容确认 v2 的单据违反的是第二条——版本一致性。这条规则落实在执行路径上就是确认动作提交时服务端比对请求携带的版本号与对象当前版本号不一致就拒绝并说明拒绝原因。状态检查的前提是对象有一张画出来的状态转换图。A-017 这类申请单的状态机教学设定草稿 → 已提交 → 资料待补充 → 资料已核验 → 待确认 → 已确认外加终态已退回和已作废。每个动作挂在允许的源状态上——确认只允许从待确认发起修改只允许在草稿和资料待补充发起。图一画出来很多口头争议自动消失为什么改不了因为它已经过了已确认修改这个动作在这个状态上不存在。不是系统刁难是业务上这个动作此刻就不该存在。状态检查远不止版本。第 11 篇讲动作约定时列过一组提交前规则数量必须大于零、对象必须处于启用状态、不能存在未关闭的重复单据、预算不得超过可用额度。这些规则的共性是——它们都只能在执行的那一刻检查不能提前检查一次就永久有效。因为状态是流动的v1 在你阅读期间变成了 v2预算在你填写期间被另一张单子占用对象在你决定执行前被冻结。权限是相对稳定的名录状态是时刻变动的现实有权限从来不等于此刻允许。还有一条容易被遗忘确认过的内容被修改后原确认自动失效。甲确认过 v1这个确认不能遗传给 v2——哪怕改动只有一个标点。失效不是惩罚是语义确认这个行为绑定的本来就是那一刻的内容内容变了确认的对象就不存在了。曾确认不表示修改后仍有效这条要写进动作规则里而不是靠业务人员自觉。实现上这条规则通常体现为两个机制的配合。其一是版本比对任何基于内容的动作——确认、批准、签署——提交时必须携带发起人所见内容的版本标识服务端与当前版本比对不一致即拒绝。其二是失效传播内容一旦被修改指向旧版本的所有确认、签署、核验记录状态置为已失效并通知原确认人。两个机制一个管别用旧依据做新动作一个管新内容来了旧结论作废。缺了第二个系统里会漂着一堆看似有效、实则悬空的确认记录比没有确认记录更危险——它给所有人一种这事已经有人看过了的假象。四、实现允许与拒绝两类路径规则写好了落在系统里是两条路径允许路径和拒绝路径。多数团队只认真设计前者。允许路径要完成的事按顺序是校验身份真实登记→ 校验对象范围 → 校验状态前提含版本→ 执行动作 → 记录证据谁、何时、对哪个版本、做了什么、结果如何。证据记录不是锦上添花是动作的一部分——没有证据的动作等于没做过的动作因为没人能复核。证据要落到什么粒度至少能回答五个问题谁真实身份不是显示名、何时服务端时间、对哪个对象的哪个版本、做了什么动作类型和关键参数、结果如何成功、拒绝、还是结果未知。这五个字段恰好也是第 16 篇排障时需要的第一手材料——执行端的证据设计和排障端的材料清单本来就是一枚硬币的两面。拒绝路径要完成的事更多。第一返回清楚的拒绝原因是无权限、跨范围、版本不一致还是状态不允许——四种原因对应四种后续动作笼统的操作失败等于把排障成本转嫁给用户。第二验证没有副作用拒绝之后目标记录必须和请求发生之前一模一样。这一条要专门测因为拒绝实现里最常见的 bug 就是先改了什么、再发现不该改、然后没擦干净。第三拒绝也要留证据谁在什么时候尝试了什么、被哪条规则拦下——越界尝试的记录是权限审计的富矿也是区分用户困惑和蓄意试探的依据。拒绝原因的表述也有讲究要对用户有用但不向越界者泄露防线细节。真实身份无确认权限是合格的表述——用户知道了为什么、知道了找谁解决试探者却没有得到防线在哪里的额外信息。不合格的表述在两个极端一端是系统错误把业务拒绝伪装成技术故障用户会去重试而不是去补权限另一端是事无巨细的校验报告等于给试探者递上防线的地图。澄川的三个拒绝样本教学合成其一测试者以伪造角色请求确认 A-017——拒绝原因真实身份无确认权限目标记录未变尝试留痕。其二甲基于 v1 请求确认已是 v2 的 A-017——拒绝原因引用版本与当前版本不一致请刷新后重新确认目标记录未变。其三申请人修改他人名下的申请单——拒绝原因超出对象范围。三个样本覆盖了身份、版本、范围三类边界全部进了回归集。到这里可以回答开头那个演示问题了Agent 会调用工具之后正确的架构是让它建议动作而不是直接执行——建议走到受控的执行层由执行层完成身份、范围、状态、版本的校验通过了才落动作不通过走拒绝路径。自然语言入口可以灵活执行层必须确定。提示词管的是建议的质量规则管的是执行的合法性各归各位。五、用越界请求检验边界防线建成了怎么知道它真的拦得住答案是主动攻击它用一组越界请求去撞看它拦不拦、拦得对不对、拦完擦没擦干净。越界测试的样本设计正好是授权矩阵的反面矩阵里每一个不可都构造一个请求去试。无权限的身份、跨范围的对象、过期的版本、不允许的状态、伪造的角色声明——每一类至少一个样本每个样本检查三件事请求被拒绝拒绝原因指明是哪条边界目标对象状态与请求前完全一致无副作用。前两件事大多数团队会查第三类检查最容易被跳过也最重要——边界防线的及格线不是拦住了是拦住了且没留下半拉子改动。验证无副作用的具体做法是前后快照对比请求前记录目标对象的关键字段请求被拒后逐一比对任何字段的意外变化都是防线上的洞——哪怕那个变化看起来无害。这组测试和第 15 篇的评测体系共用样本管理纪律越界样本同样分开发、独立测试与回归每次权限模型或状态机调整后全部重跑。边界不是一次建成的是每次改动后重新确认的。还有一类最容易漏的越界时间维度上的越界。甲调岗了、离职了、负责范围从一车间换成二车间了——他的授权矩阵行更新了吗权限的删除和修改永远比新增危险因为新增是有人申请的删除常常没人记得。把人员变动触发的权限复核写进流程比任何技术检查都更能堵住这类口子。迁移练习留给你这次换个行业客服主管可以确认质检发现成立——那么他能不能读取全部组的通话录音他对发现的确认会不会自动写进客服的绩效三个问题分别对应身份范围、对象范围、动作外溢练习的产出要同时证明两件事允许的动作确实能成功越界的动作确实无副作用。只会证明前者的还不算懂执行边界。把这一篇的边界也划清它管的是动作发出之前——身份、范围、状态、版本四道检查都在执行路径的起点。动作通过检查、发出去了结果却没回来那是另一种局面检查的对象从该不该做变成到底做没做成。下一篇处理最后这种硬情况动作发出去了结果没回来——接口超时之后为什么不能直接再试一次