上一篇讲的是做错了怎么定位。这一篇往前退一步：能不能让错误根本发不出手？

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 篇的评测体系共用样本管理纪律：越界样本同样分开发、独立测试与回归，每次权限模型或状态机调整后全部重跑。边界不是一次建成的，是每次改动后重新确认的。

还有一类最容易漏的越界：时间维度上的越界。甲调岗了、离职了、负责范围从一车间换成二车间了——他的授权矩阵行更新了吗？权限的"删除"和"修改"永远比"新增"危险，因为新增是有人申请的，删除常常没人记得。把"人员变动触发的权限复核"写进流程，比任何技术检查都更能堵住这类口子。

迁移练习留给你，这次换个行业：客服主管可以确认质检发现成立——那么，他能不能读取全部组的通话录音？他对发现的确认，会不会自动写进客服的绩效？三个问题分别对应身份范围、对象范围、动作外溢，练习的产出要同时证明两件事：允许的动作确实能成功，越界的动作确实无副作用。只会证明前者的，还不算懂执行边界。

把这一篇的边界也划清：它管的是

"动作发出之前"——身份、范围、状态、版本，四道检查都在执行路径的起点。动作通过检查、发出去了，结果却没回来，那是另一种局面，检查的对象从"该不该做"变成"到底做没做成"。

下一篇处理最后这种硬情况：动作发出去了，结果没回来——接口超时之后，为什么不能直接再试一次。

会调用工具，还要懂权限、状态和执行边界

副总裁

人工智能

授权矩阵、状态校验、版本比对四道防线缺一不可。拒绝路径需验证无副作用并留痕。Agent执行前必须通过身份、范围、状态、版本检查，越界样本测试验证拦截有效性。权限动态管理防时间越界，自然语言入口灵活但执行层必须严格。

Agent

2026上云采购 | AI焕新·智启新局

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

会调用工具，还要懂权限、状态和执行边界

会调用工具，还要懂权限、状态和执行边界

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐