《AI 执行工程论纲》专论：何为「不完美主体」（Fallible Subject）？

人无完人这句话在日常生活里几乎不需要论证。人会疲劳、会误判、会受情绪影响、会遗忘上下文也可能在利益面前改变行为。正因为如此人类社会从未把重要秩序建立在某个人永远不会犯错之上财务需要复核司法允许上诉航空依赖检查单核工业要求双人确认公司治理强调权力制衡。这些制度并不假设参与者不可信它们只是假设参与者不可能始终正确。进入软件时代之后工程实践反而形成了另一种习惯。只要身份正确、Credential 合法、Permission 已经授予后续行为通常就被默认为可信。这套假设在过去几十年里支撑了大量计算机系统并且长期运转良好。AI Agent 的出现正在迫使我们重新面对一个人类其实早就知道的事实任何能够发起行动的主体都不应该被假设为永远正确。本文讨论的不完美主体Fallible Subject指的就是这个问题。它是《AI 执行工程论纲》中的一条基础假设也是后续全部执行控制Execution Control结构得以成立的前提。一、经典安全工程寻找的是可信主体经典软件系统里有一条非常自然的安全直觉先确认你是谁再决定你能做什么。用户登录系统完成身份认证身份对应角色角色对应权限权限最终决定某个 API、文件、数据库、设备或资金账户能否被访问。由此形成了一条熟悉的链条Identity → Authentication → Authorization → Action。只要前面的身份与授权关系成立后面发生的动作就被视为这一关系的自然延伸。这种设计在过去是合理的。传统软件大多是确定性的一个按钮对应一个功能一个接口对应一种行为一项权限通常对应相对稳定的能力边界人类是主要决策者软件更多只是执行已经明确下达的指令。在这样的环境中安全工程把绝大部分精力放在谁拥有权限上是一种性价比很高的选择。但这条链条中隐藏着一个很少被明确说出来的假设获得权限的主体大体知道自己正在做什么。过去这个假设在多数场景中成立所以它长期不需要被检验。Agent 的出现让它第一次变得危险。二、不完美是工程属性不是道德判断Fallible Subject 很容易被误读为不可信主体恶意主体或已被攻击者控制的主体。在本文的理论体系中它不指这些情况。不完美首先是一个工程属性用来描述主体在行动中的可靠性边界而不是对主体动机的评价。一个主体完全可以是善意的、专业的、经过充分训练的同时仍然是不完美的。现实中这类例子非常普通。一名认真负责的员工可能因为看错一位数字而把款项转往错误账户一名开发者可能拥有完全合法的生产权限却在错误的环境里执行了一条正确的命令一个 Agent 可能严格按照它当前的理解完成了任务却从一开始就误解了用户真正的 Intent。这些失败都不涉及恶意也未必涉及能力不足。因此一个主体被称为 Fallible并不是因为它一定会做坏事而是因为我们无法证明下面这句话它在未来的每一次行动中都能够获得完整信息、形成正确理解、保持原始目标并作出符合真实意图的选择。只要这一点无法被证明该主体就应被当作不完美主体处理。按照这个定义人类是不完美主体AI Agent 是自动化脚本是管理员是SaaS 平台同样是即使是一个经过大量安全测试的软件模块一旦运行在它被验证过的边界之外也会重新变成不完美主体。Fallibility 不是需要被特别标记的异常状态它是现实系统的默认状态。三、AI 改变的不是机器会不会犯错模型会犯错本身并不是最值得讨论的问题。传统软件一样有 Bug人类一样会误操作工程界对这两类失败已经积累了成熟的处理方式。发生变化的是另一件事不完美主体第一次同时获得了理解、规划、决策与执行的能力。传统程序通常只能在开发者预先定义好的路径中运行它的行为空间是被写死的。Agent 不同它可以读取环境、理解任务、拆解目标、选择 Tool、生成参数并根据中间结果调整计划后继续行动。一条动态生成的执行链条由此出现Intent → Interpretation → Planning → Tool Selection → Parameter Generation → Execution。其中任何一个环节发生偏差最终落到现实世界的结果都可能与预期不同而这种偏差往往不会表现为程序崩溃。一次语义上完全错误的执行在技术指标上可以是完美的API 返回 200Credential 有效权限检查通过数据库事务提交成功链上交易得到确认通知邮件也正常发出。从传统可观测性的角度看这次执行没有任何异常。系统忠实地完成了它被要求做的事只是它被要求做的事并不是原本应该发生的事。这正是不完美主体比 Hallucination 更值得单独讨论的原因。Hallucination 描述的是模型输出层面的错误处理它属于模型质量问题Fallible Subject 描述的则是一个可能形成错误认知的主体正在获得改变现实世界状态的能力。二者不在同一个层级上。四、危险的不是错误本身而是错误拥有执行权一个人算错一道数学题通常没有严重后果一个 Agent 总结错一篇文章也未必构成安全事故。风险真正开始积累是在错误可以穿过系统边界、直接转化为现实动作的时候。假设一个 Agent 错误理解了清理测试环境这一指令。如果它只能生成建议人类还有机会在执行前发现问题如果它同时持有云平台的操作权限同一个误解就可能变成被删除的实例。同样误判一项资金调度任务在只有分析能力时只是一份错误的报告在拥有钱包签名能力时则是一笔真实转账误读一封邮件中的指令在能够直接访问采购系统的前提下认知偏差会直接变成一张订单。执行工程关心的问题因此不止于主体会不会犯错而是当主体犯错时这个错误是否拥有让现实状态发生改变的权力。这是两个独立的问题解决其中一个并不等于解决另一个。我们没有办法保证主体永远正确但我们可以设计系统使单个主体的错误不足以独立成为现实。这是 Fallible Subject 这一概念最主要的工程价值。五、从相信主体转向约束结果传统安全体系带有强烈的主体中心倾向认证用户、认证设备、认证进程然后围绕身份分配权限。这种做法在过去非常有效但它存在一个结构性限制——身份能够证明是谁却无法证明这一次具体行动是否仍然合理。一个合法管理员可以执行一条错误命令一个合法 Agent 可以生成一组错误参数一枚从未泄露的 Credential也可以被一个已经偏离原始任务目标的程序合法调用。这些情况里没有任何一个环节违反了授权模型失败恰恰发生在授权模型的覆盖范围之外。执行工程由此发生一次视角转换。安全系统不再试图找到一个永远值得相信的主体而是假设所有主体都可能在某一时刻失败并围绕这种失败建立边界。系统的核心追问从谁是可信的转向即使这个主体此刻判断错误哪些事情仍然不能发生。前一种思路寻找 Trusted Subject后一种思路构建 Trustworthy Structure。一个成熟的结构不要求参与者永远正确它要求的是即使有人犯错、某个组件失效、部分环境被攻击者控制系统中依然存在若干条无法被跨越的边界。六、AUTHORITY 需要被重新分解接受了不完美主体这一前提很多今天看起来自然的软件设计就需要重新审视其中最重要的一条是能够提出 Action 的主体不应当被默认拥有完成该 Action 的全部 Authority。Agent 可以提出向这个地址转账但提出这一请求并不等于它应该持有最终签名权自动化系统可以判断服务器需要扩容但作出判断并不意味着它天然应当拥有无限制修改生产环境的能力模型可以生成一条 SQL而生成 SQL 与允许这条 SQL 在核心数据库上执行是两件需要分别成立的事。用一句更紧凑的表述概括这一原则Authorization ≠ Execution。Authority 因此需要被拆开。Intent 的产生者、Policy 的制定者、Authorization 的授予者、Runtime 的裁决者以及最终让现实状态发生改变的 Execution Authority可以分别由不同主体承担并且相互之间不必共享同一份信任假设。这种拆分的目的不是降低自动化程度效果往往相反。如果全部 Authority 集中在同一个 Agent 身上出于安全考虑人类就只能不断退回到逐项审批的模式自动化的实际收益会被审批成本吃掉。而当 Authority 被结构化地分解之后系统反而可以允许 Agent 在明确边界内更自主地运行因为越界的后果已经被结构本身限制住了。Fallible Subject 导出的结论并不是AI 不可靠所以所有事情都应该交给人确认而是不要要求主体完美而要让 Authority 的结构能够容忍主体的不完美。七、FAIL-SECURE 的本质是承认系统可能不知道不完美主体还有一个直接后果系统必须认真对待 Unknown。传统系统容易形成一种二元逻辑——权限存在则 Allow权限不存在则 Deny。但现实执行环境远比这复杂状态可能缺失Evidence 可能已经过期Intent 可能在执行过程中发生变化多个信息源可能彼此冲突上游系统可能根本无法给出确认。这些情况既不是 Allow也不是简单的 Deny而是当前无法判断。如果系统仍然假设主体能够自行处理这些空白不确定性最终会被转化为主体的自由裁量而当主体本身就是 Fallible 的时候这种自由裁量恰恰是执行风险的主要来源之一。执行系统因此需要一种朴素但严格的能力不知道就不能假装知道。Missing 不等于 FalseUnknown 不等于 TrueConflict 更不应该被自动解释为 Allow。这是 Fail-Secure 在执行工程中的含义。它不只是出故障就停机这种运维层面的策略而是一条更基本的约束当系统无法形成足够完整的执行证明时不允许不确定性自然坍缩成一个现实动作。从这个角度看一个成熟的执行系统之所以安全往往不是因为它判断得特别聪明而是因为它知道自己在什么时候没有资格判断。八、EVIDENCE 从审计材料变为结构的一部分如果主体是不完美的那么日志就不能只回答谁做了什么因为谁本身已经不足以解释一次行动的合理性。合法身份发起的错误执行在这种日志里看不出任何问题。需要被记录和回答的问题会因此扩展这个主体为什么发起该 Action它依据的 Intent 是什么当时它看到的 State 是什么哪些 Policy 生效哪些独立边界参与了裁决允许执行的条件是否完整成立以及最终的执行结果与原始 Intent 是否一致。当这些问题都需要被结构化地回答时Evidence 就不再只是事故之后的审计材料而成为执行结构本身的组成部分——它是执行得以发生的前置条件而不是执行发生后的副产品。系统需要记录的不止是 Action happened还包括 Why was this Action allowed to happen。这是从 Audit Log 到 Execution Proof 的变化其逻辑起点仍然是同一条假设既然不能假设某个主体永远正确系统结构就必须能够独立解释一次执行为什么成立。九、成熟的系统不需要完美的参与者回到人无完人。这句话之所以能够流传下来是因为人类很早就接受了一件事文明不能等待完美的人出现之后再建立制度。我们制定法律并非因为每个人都会犯罪要求财务复核并非因为会计不值得信任使用航空检查单更不是因为飞行员不专业。这些结构存在的理由恰恰是即使一个优秀、善意、训练有素的人也仍然可能在某一个具体时刻犯错。AI Agent 把这个古老的问题重新带回了计算机系统只是这一次的条件有所不同。不完美主体可以每秒完成成百上千次判断可以同时运行在大量系统之中可以自主选择工具可以连续执行数小时甚至数天并且正在越来越接近真实世界中的 Authority。错误的传播速度与作用范围都不再受人类操作节奏的限制。未来的执行安全工程需要追求的目标因此可能不是创造一个永远不会犯错的 Agent——这个目标本身就建立在一个无法被证明的假设上。更现实、也更有工程价值的问题是当一个不完美主体拥有越来越强的行动能力时我们能否建立一种结构使它即使犯错也无法轻易把错误变成不可逆的现实。《AI 执行工程论纲》的一条基本假设由此可以写得非常简单All acting subjects are fallible.任何能够行动的主体都应被视为可能犯错。安全系统需要证明的从来不是主体不会失败而是即使主体失败边界仍然成立。