我第一次把运维 Agent 接进测试环境时只给了它一个看起来很小的任务发现接口错误率升高后定位配置问题并修正灰度开关。Agent 找到了错误的配置项也生成了语法正确的修改但它把“恢复 10% 灰度”理解成“将目标版本权重设置为 10”没有同步降低旧版本权重。配置中心接受了请求两个版本的权重之和变成 110网关按照归一化结果继续分流。监控显示错误率下降任务因此被判定为成功直到第二天对账时才发现流量比例与变更单不一致。这次问题没有造成生产事故却暴露出一个容易被忽略的边界模型能生成正确命令不等于系统理解了命令的业务后果接口返回成功也不等于变更满足预期。继续增加 Prompt、换用 DeepSeek-R1 或 Claude 3.5 Sonnet都无法单独解决这个问题因为真正缺失的是生产写入之前的预演、约束与结果证明。后来我把流程改成三段。Agent 先提交一份不可执行的变更意图预演控制器在影子环境中重放读取、计算差异并估计副作用只有预演结果通过策略和人工门槛后写入代理才签发一次性能力租约。模型不再直接持有数据库、配置中心或云控制台凭据它能做的是提出带证据的修改。这个变化降低了“自动化程度”的表面观感却让每次写操作都可以解释、拒绝和撤销。本文选择自主 Agent 安全边界作为主线重点不在介绍 Docker 沙箱或 RBAC 的基础概念而在回答一个更具体的问题拥有写能力的 Agent怎样在真实企业 IT 环境中完成生产变更同时不把推理结果直接等同于执行授权。Agentic Workflow、AST 语法树审计、影子数据面、能力租约和可撤销提交会组成一套完整的变更预演协议创源AIGC只作为可替换的模型接入节点参与其中不承担最终授权责任。一、先区分三种“成功”命令执行、状态变化与业务结果传统自动化脚本通常有确定的输入和动作退出码为零可以作为重要证据。自主 Agent 不同它会根据自然语言目标选择工具、拼接参数和调整步骤。一个命令执行成功只能说明目标接口接受了请求资源状态发生变化只能说明写入生效只有业务指标满足约束、没有越过风险边界才能说任务完成。在灰度权重案例中配置接口返回 200 属于命令成功目标版本权重从 0 变成 10 属于状态变化但“总权重保持 100、错误率下降且高价值租户不受影响”才是业务结果。如果任务记录只保存最后一次工具调用前两个条件会掩盖第三个条件的失败。因此我把每个写任务拆成五类声明声明回答的问题例子目标最终希望改变什么将新版本灰度恢复到 10%前置条件什么状态下允许执行当前总权重为 100版本均健康允许动作Agent 可以调用哪些工具读取配置、提交权重变更提案禁止副作用无论如何不能发生什么不创建新版本、不改高价值租户规则完成证明怎样判断业务任务结束权重和为 100五分钟错误率低于阈值这五类声明必须在模型规划之前确定。模型可以补充候选步骤但不能自行删除禁止项或降低完成门槛。对于定义不清的任务系统应该停在 need_clarification而不是让 Agent 猜测“用户大概想要什么”。自主性越强输入契约越要明确。任务还需要区分确定状态和未知状态。超时后如果不知道上游是否已经执行不能立即重试同一写操作必须先查询资源版本、幂等记录或审计日志。把 unknown 当作 failed会导致重复扣款、重复发版或重复删除把 unknown 当作 succeeded又可能掩盖未完成任务。未知状态进入独立队列由恢复器查询事实后再决定继续、撤销或人工处理。业务不变量最好由资源负责人维护成目录而不是每次都让 Agent 临时生成。配置中心可以定义权重总和、版本数量和租户覆盖范围数据库可以定义余额守恒、状态转换顺序和最大影响行数发布系统可以定义可用副本、错误预算和变更窗口。目录中的规则包含 owner、severity、query、threshold 和 evidence_ttl预演控制器根据任务资源自动加载。模型可以建议新规则但新增或修改不变量本身属于独立变更不能和本次生产任务一起批准。证据还需要新鲜度。十分钟前读取的健康状态在高峰期可能已经失效昨天生成的数据库执行计划也不能证明今天仍然安全。每类证据设置有效期并在 Commit 前重新读取关键字段。如果新事实只发生无关变化可以继续如果资源版本、目标行数或风险指标变化旧 Effect 立即失效。这样能避免系统拿一份曾经正确的报告为当前写入背书。完成证明应由独立验证器采集不能让执行 Agent 自己总结“任务已完成”。验证器使用只读身份从监控、资源 API 和审计账本获取事实并把原始查询时间、数据源版本和结果哈希写入证明。Agent 可以解释结果或提出下一步但 succeeded 状态只能由确定性条件产生。对于无法机器验证的语义结果例如公告措辞是否合适状态保持 waiting_for_review。二、变更意图不是命令建立 Plan、Effect、Commit 三阶段协议Agent 直接输出 Shell、SQL 或云 API 参数时推理与执行被压缩在同一个步骤里。更稳妥的协议把一次生产变更拆成 Plan、Effect 和 Commit。Plan 描述想做什么Effect 是预演控制器计算出的资源差异和风险Commit 是经过签名、只能执行一次的具体操作。三个阶段使用不同的数据结构和权限主体。Plan 阶段只接受结构化意图。它可以包含自然语言理由但授权判断只读取类型化字段。下面是一份配置调整意图Agent 可以生成候选值却不能给自己添加审批人或扩大资源范围。{intent_id:chg-8f12,task_type:adjust_rollout_weight,resource:{environment:production,service:checkout-api,region:cn-east},desired_state:{stable_weight:90,candidate_weight:10},preconditions:[current_total_weight 100,candidate_health healthy,active_incident false],forbidden_effects:[change_tenant_override,create_route,modify_secret],evidence_required:[config_diff,five_minute_error_rate,rollback_snapshot]}Effect 阶段不执行生产写入而是读取当前快照把 desired_state 应用到影子副本再输出差异。差异不能只显示文本行还要包含语义变化路由总权重是否守恒、哪些租户会受影响、预计重载多少实例、是否触发缓存失效、是否修改敏感字段。对于数据库变更Effect 应包含执行计划、预估锁范围、受影响行数上限和回滚可行性。Commit 阶段只接受已经冻结的 Effect 哈希。若预演后生产状态发生变化前置条件版本不再匹配提交必须失败并重新预演。这类似乐观并发控制系统拒绝在未知的新状态上执行旧计划。Agent 不能通过重新发送同一命令绕过版本冲突因为写入代理同时校验 intent_id、effect_hash、resource_version 和租约有效期。三阶段协议也让人工审批变得具体。审批者看到的不是一段长对话而是目标、前置条件、差异、副作用和回滚点。低风险变更可以由策略自动批准中风险变更要求一个服务负责人确认高风险变更要求双人复核。审批人不能修改 Effect如果需要改参数必须回到 Plan 生成新的版本。为了让 Effect 哈希稳定Plan 需要规范化序列化。字段按照 Schema 排序时间统一为 UTC数字使用明确精度资源名先解析为内部唯一标识空字段与缺失字段不能混为一谈。自然语言理由不进入执行哈希否则模型措辞的细小变化会让同一变更产生不同票据但理由仍保存在审计记录中供审批者理解上下文。Plan 的 Schema 也要有版本。新增字段时先保持向后兼容旧执行器遇到未知的安全关键字段必须拒绝而不是忽略。客户端提交 schema_version、生成器版本和任务模板版本预演结果再记录解释器版本。某次事故发生后团队才有可能回答当时到底是哪一版规则把哪一字段解释成了什么动作。模型引用的证据不能直接相信。它可能把一段旧日志当成当前状态也可能受到工单正文中的提示注入影响。证据引用只能指向平台签发的 evidence_id预演控制器再从受信数据源读取内容。用户文本、OCR 结果和工单附件全部标记为 untrusted_context允许用于理解问题但不能单独满足生产前置条件。三、从长期 RBAC 到能力租约权限必须绑定对象、动作和时间RBAC 适合管理“谁通常可以做什么”但不足以约束一次自主任务。给 Agent 一个长期的 config:write 角色即使资源路径受限它仍可能在错误时间重复写入。生产写权限隔离应从静态角色继续收窄为能力租约只允许某个主体在短时间内对一个具体资源执行一次确定动作。一张能力租约至少包含 subject、resource、action、constraints、not_before、expires_at、max_uses、effect_hash 和 approvers。它由策略服务签发写入代理验证模型本身只拿到不含底层凭据的票据。租约使用后立即作废任务重试需要查询原提交结果不能重新消费。下面是一个简化的验证器。生产实现还应校验签名、时钟偏差、撤销列表和审计序列号。fromdataclassesimportdataclassfromdatetimeimportdatetime,timezonefromtypingimportFrozenSetdataclass(frozenTrue)classCapabilityLease:subject:strresource:stractions:FrozenSet[str]effect_hash:strexpires_at:datetime max_uses:intdefauthorize(lease:CapabilityLease,subject:str,resource:str,action:str,effect_hash:str,used_count:int,)-bool:nowdatetime.now(timezone.utc)returnall([lease.subjectsubject,lease.resourceresource,actioninlease.actions,lease.effect_hasheffect_hash,nowlease.expires_at,used_countlease.max_uses,])资源匹配不能只做字符串前缀。文件路径需要解析真实路径和符号链接Kubernetes 资源要同时匹配集群、命名空间、类型和名称数据库要匹配实例、库、表和允许的语句类别云资源还要匹配账号与区域。类似 production-app 和 production-app-backup 的名称如果使用 startsWith 判断很容易越权。租约服务与模型网关必须分离。模型接入层负责协议转换、调用记录和用量策略服务负责身份、审批和租约写入代理负责最后一次验证。即使某个模型通道或聚合中继发生配置错误也不能因此获得生产凭据。把三者放进同一个进程会让一个普通的模型调用漏洞扩大为写权限漏洞。紧急场景也不应回到永久管理员密钥。可以预先定义 break_glass 流程由值班负责人申请更高权限租约要求更短有效期、更完整录屏和事后复核。紧急并不意味着无约束只是审批时延和风险接受者发生变化。租约签发依赖清晰的身份链。用户发起任务时使用个人身份编排器运行时使用工作负载身份写入代理执行时再交换为目标系统接受的短期身份。审计记录同时保存 initiator、planner、executor 和 approver不能把所有动作都记在一个共享机器人账号下。共享账号看似方便发生问题时却无法判断是谁提出、谁批准、哪个实例真正执行。签名密钥应放在硬件或托管密钥服务中租约服务只请求签名不导出私钥。验证端缓存公钥和密钥版本支持轮换但不能无限信任旧版本。撤销列表用于处理审批取消、账户离职、事故冻结和策略误签关键写入在使用租约前查询最新撤销状态查询失败时保守拒绝。对低风险测试任务可以短时缓存撤销结果但缓存时长必须小于租约有效期。权限收窄还包括参数边界。允许 update_config 并不意味着任意值都可写租约可以限定 stable_weight 在 80 到 95 之间、candidate_weight 在 5 到 20 之间并要求两者之和为 100。对于 SQL限制语句模板、目标表、主键集合和 row_budget对于 Kubernetes限制镜像摘要、副本变化范围和禁止修改的安全上下文。把约束写进票据写入代理就不必依赖模型再次正确复述审批内容。四、影子数据面不是复制一套环境而是复制变更所需的事实很多团队听到预演会想到完整的生产克隆但完整复制成本高也可能复制敏感数据。影子数据面的目标不是运行一个一模一样的世界而是为当前变更提供足够事实。配置变更需要资源拓扑、当前版本和约束SQL 变更需要脱敏样本、索引统计和锁模型文件修改需要只读仓库快照与构建依赖外部 API 写入则需要一个能记录请求而不产生真实副作用的代理。影子环境可以分成四层。第一层是只读快照保存资源版本和校验哈希第二层是仿真适配器把写请求转成差异事件第三层是隔离执行器运行脚本、测试和静态检查第四层是断言引擎对结果检查业务不变量。只有四层都通过Effect 才能进入审批。Docker 安全沙箱适合承载第三层但默认容器配置并不安全。执行容器应使用非 root 用户、只读根文件系统、临时工作目录、CPU 与内存限制、PID 上限、禁用特权模式并拒绝挂载宿主机 Docker Socket。网络默认关闭需要访问依赖仓库时只开放固定代理。工作目录只挂载任务需要的文件凭据由短期工作负载身份提供而不是写进环境文件。services:rehearsal:image:agent-rehearsalsha256:replace-with-approved-digestread_only:trueuser:10001:10001network_mode:nonecap_drop:-ALLsecurity_opt:-no-new-privileges:truepids_limit:128mem_limit:768mcpus:1.0tmpfs:-/tmp:size128m,noexec,nosuidvolumes:-./task:/workspace:ro数据库预演尤其需要克制。不要把生产全量数据复制进普通沙箱可以使用模式副本、统计信息和经过脱敏的代表性行。涉及唯一约束、外键和触发器时脱敏过程必须保留关系结构否则“预演成功”没有意义。对于无法安全复制的数据使用写入代理计算 WHERE 命中数量和执行计划并把真正执行保留给数据库变更系统。外部系统无法提供沙箱时可以使用效果捕获代理。代理接受与真实 API 相同的请求验证 Schema 和权限但把副作用写进事件日志。例如发送通知时只记录目标人数、模板和变量不实际发送创建云资源时只计算资源图和预算变化不调用控制面。这个代理不能伪造所有上游行为因此 Effect 必须标记 fidelity告诉审批者预演覆盖了什么、没有覆盖什么。保真度可以按资源类型分级避免一份笼统的“沙箱通过”制造错误信心等级预演能力不能证明的内容适用动作F0 Schema只校验字段、类型和权限运行时结果与业务副作用低风险参数草稿F1 Snapshot在资源快照上计算语义差异并发变化与真实性能配置、路由和权限提案F2 Emulation使用脱敏数据和仿真依赖执行外部系统完整行为SQL 修复、脚本和构建F3 Shadow复制真实流量但屏蔽写入最终生产写入效果高风险灰度与接口变更策略可以规定不同风险需要的最低保真度。修改文档元数据可能只需 F0调整生产流量至少需要 F1 和实时健康证据数据库批量修复通常需要 F2核心交易链路变更则需要 F3 加人工审批。若环境只能提供较低等级系统不是简单显示一个警告而应自动降低允许的动作范围。影子环境自身也会漂移。镜像摘要、数据库模式、功能开关和依赖服务版本都要写进 rehearsal_manifest。每天用只读任务比较影子与生产的关键结构超过阈值就暂停相关预演。否则团队可能在一个数月未更新的沙箱里反复得到成功结果却在生产面对完全不同的索引、限额和安全策略。五、写入代理与可撤销窗口把副作用关进一条窄通道即使预演通过也不应让 Agent 直接连接生产系统。所有写操作进入独立写入代理代理只接受类型化动作并再次读取前置条件。它不支持任意 Shell也不接受模型生成的原始 URL。每种动作都由人工实现适配器例如 update_config、restart_workload、apply_sql_patch 和 rotate_feature_flag。写入代理为每次变更创建 before_snapshot、commit_record 和 verification_deadline。before_snapshot 是可回滚所需的最小状态commit_record 保存真实请求和上游响应verification_deadline 定义观察窗口。在观察窗口结束前任务状态是 committed_unverified而不是 succeeded。验证器持续检查业务指标和禁止副作用一旦触发阈值便进入撤销流程。可撤销并不等于所有动作都有反向命令。配置和流量权重可以恢复快照数据库 UPDATE 需要记录受影响主键和旧值发送消息、删除外部资源或触发第三方付款可能不可逆。任务目录应明确标记 reversibilityreversible、compensatable 或 irreversible。不可逆动作默认只生成提案必须人工确认并且不能依赖自动回滚作为安全理由。数据库写入可以采用“额度托管”。Agent 的意图声明最大影响 200 行预演发现预计影响 143 行租约便把 row_budget 固定为 200。执行时写入代理先在同一事务中重新计算命中数超过预算立即中止低于预算才继续更新。完成后保存实际行数和主键摘要验证器再检查业务不变量。这样WHERE 条件因为数据变化扩大时旧计划不会静默作用于更多记录。生产写入还需要幂等语义。配置动作可以使用 intent_id 作为幂等键数据库动作可以在审计表中锁定 effect_hash外部系统若没有幂等接口写入代理必须先查业务结果再决定是否执行。超时后禁止盲目跨渠道重试因为第二个通道可能无法看到第一个通道已经产生的副作用。写入代理的状态机可以定义为 accepted、precondition_checked、committing、committed_unverified、verified、reverting、reverted 和 manual_required。状态只能单向前进任何跳转都写入追加式事件账本。进程重启后恢复器根据最后事件继续查询事实而不是从头执行。这样既能处理网络超时也能避免因数据库故障把已经完成的提交重新消费。并发变更是另一类风险。两个 Agent 可能分别提出“把候选权重调到 10”和“临时关闭稳定版本”单独预演都合理合并后却不可用。写入代理应对资源建立短期变更锁或使用版本比较并把正在等待的 Effect 重新评估。锁的范围不能过大否则一个低风险字段会阻塞整个集群也不能只锁单字段因为跨字段不变量需要共同保护。观察窗口内的指标必须绑定变更而不是只看全局大盘。验证器记录变更前基线、目标服务、受影响租户和时间范围使用相同统计口径比较错误率、延迟和业务完成率。全局指标正常可能掩盖一个小租户故障短时尖峰也不一定意味着需要回滚。回滚阈值、最小样本量和观察时长应在 Plan 模板中预先定义。撤销动作同样经过写入代理但不需要重新请求原审批人的在线确认因为批准 Effect 时已经批准了对应回滚快照。若回滚本身会扩大影响例如数据库结构已经被后续变更依赖则进入 manual_required 并冻结冲突写入。自动回滚不是无限承诺它只在预先验证的可逆窗口内成立。六、AST 审计只能发现语法风险运行时预演负责验证真实副作用AST 语法树审计适合在执行前发现危险结构例如 Python 中的 eval、exec、动态导入、shellTrueJavaScript 中的动态代码执行SQL 中无 WHERE 的 UPDATE 或 DROP。它比正则可靠因为能够理解调用结构和语句类型。但 AST 不能证明代码安全危险命令可以通过库封装、字符串构造、依赖安装或运行时下载间接触发。因此审计链应包含源码检查、依赖检查、系统调用限制和副作用对比。源码检查输出结构化 findings依赖检查锁定包名、版本和哈希系统调用限制由沙箱与运行时策略执行副作用对比则比较执行前后的文件、网络、进程和资源事件。任何未知出站连接、工作区外写入或未声明子进程都提高风险等级。一个有效的审计结果不只是 pass 或 fail而应告诉策略服务发现类型、代码位置、可到达性、是否在本次路径执行、可能影响的资源和建议处理。低风险的临时文件写入可以允许高风险的凭据读取应直接阻断无法判断的动态行为则要求人工复核。模型可以解释 findings但无权覆盖阻断级规则。规则也要防止过度拦截。如果所有 subprocess 调用都被禁止很多构建任务无法运行如果允许任意编译器脚本又可能借构建过程访问网络。更实际的做法是按任务模板提供工具白名单例如测试任务允许 pytest、npm test 和只读 Git 命令数据库任务只允许查询计划和预定义迁移器。白名单由平台维护Agent 只能从中选择。审计器自身需要版本化。规则升级后历史任务仍应能还原当时的判断新规则先在历史事件上回放观察误报和漏报再进入灰度。若规则变化导致大量任务从允许变为阻断应暂停自动提交而不是让 Agent 反复改写代码迎合一个未经验证的检查器。运行时事件需要与声明的 Effect 对齐。计划只允许读取工作区、运行测试并写入临时目录实际却出现 DNS 查询或访问凭据路径即使进程退出码为零也应判定失败。事件采集可来自容器运行时、系统调用过滤器和网络代理审计服务把行为归一化为 file_read、file_write、process_start、network_connect 和 secret_request。未声明事件默认拒绝高频重复的只读事件可以聚合避免日志量掩盖关键变化。审计报告不应保存完整源码和敏感参数。对文件记录规范化路径与内容哈希对网络记录目标类别和策略决策对命令参数进行字段级脱敏。需要调查时由有权限的人员回到受限证据仓读取原文。否则本来用于提升安全性的日志平台反而会成为代码、密钥和客户数据的集中泄露点。静态与动态结果发生冲突时采用更保守的结论。AST 没发现风险但运行时出现未知写入应阻断AST 标记动态执行但沙箱证明路径不可达可以交由人工决定是否接受而不是自动消除 finding。安全结论要能表达不确定性不能为了生成一个简单总分而把证据压平。七、多模型协作与统一接入推理通道不能成为授权通道复杂变更可以采用“规划模型加审查模型”的双通道一个模型生成候选 Plan另一个模型从前置条件、遗漏副作用和回滚可行性角度提出质疑。DeepSeek-R1、Claude 3.5 Sonnet 或本地代码模型都可以承担其中一种角色但双模型一致不等于安全证明。它只减少单一推理偏差最终约束仍来自策略、预演和写入代理。模型接入配置应使用能力别名而不是把供应商名称写进 Agent 逻辑。规划任务声明 long_context 和 structured_output代码审计解释声明 code_reasoning敏感数据任务声明 local_only。路由层依据数据等级、延迟预算和渠道健康度选择实际模型。创源AIGC可以作为研发联调中的一个统一中继节点与自建 One-API、LiteLLM 或本地服务并列验证。model_relay:base_url:https://178.nz/yinc/v1api_key_env:AGENT_RELAY_TOKENroutes:planner:reasoning-routereviewer:code-review-routedata_policy:production_secret:denymasked_config:allowtimeout_seconds:45发送到模型的数据应该是最小证据包脱敏后的资源摘要、允许动作、前置条件、错误信息和必要代码片段。生产凭据、完整客户数据、长期日志和租约签名不进入 Prompt。模型返回的工具参数继续被当作不可信输入必须通过 Schema、资源匹配和策略验证。双模型还要避免伪共识。如果两个通道使用相同系统提示、相同上下文和相近模型家族它们可能重复同一种错误。审查模型应收到候选 Plan、任务契约和独立的反例清单但不应先看到规划模型的自我辩护。对高风险任务确定性规则和历史失败样本比再增加一个“投票模型”更有价值。路由失败不能扩大权限。规划通道不可用时可以切换模型租约服务不可用时则应保守拒绝生产提交审计日志不可用时关键写操作也不能静默放行。可用性降级必须沿着风险方向设计宁可让自动化暂时停止也不能因为一个外围服务故障而绕过授权。八、用故障注入验证边界测试“系统如何拒绝”而不只是如何成功生产前测试不能只准备正常任务。至少应覆盖过期租约、资源版本冲突、遮罩后的敏感字段、预演与生产状态漂移、上游超时、重复提交、审计服务不可用和人工撤销。每个场景都要定义预期状态、允许重试次数和最终责任人。我使用一组 120 个脱敏任务做受控演练其中包括 50 个配置变更、30 个数据库修复、20 个仓库补丁和 20 个外部 API 操作。数字用于展示评测方法不代表任何平台的通用性能。比较了直接工具调用、只加 RBAC、容器沙箱加 RBAC以及完整预演协议四种流程流程非预期副作用拦截率重复写入率中位交付时间人工复核分钟/任务未知状态可恢复率直接工具调用31%4.2%3.8 分钟2.138%只加 RBAC48%3.5%4.4 分钟2.842%沙箱加 RBAC72%1.9%6.7 分钟4.661%预演、租约与写入代理94%0.2%9.8 分钟5.391%完整协议明显增加了交付时间和平台复杂度这也是必须承认的成本。它适合数据库修复、灰度调整、基础设施和外部业务写入不适合每一个低风险动作。格式化代码、生成测试草稿和修改临时分支可以停在工作区隔离与 CI把同样重的审批链套在所有任务上会让团队绕开平台。拦截率也不能作为唯一质量指标。系统如果拒绝所有任务拦截率看起来很高却没有业务价值。还要同时观察合法任务通过率、误阻断率、人工等待时间、回滚成功率和每个完成任务的总成本。安全门槛应按动作风险分层而不是用一个全局分数决定。故障演练的重点是检查证据是否完整。租约过期后日志能否说明拒绝原因提交超时后恢复器能否查到实际状态回滚失败后是否能升级到明确责任人模型通道切换后Plan 是否仍绑定原 Effect。只有拒绝、未知和撤销路径都能闭环系统才具备生产写入的基本条件。建议把故障库分成身份、状态、依赖和业务四组。身份组包含伪造主体、过期票据和审批撤销状态组包含资源版本冲突、重复请求和提交结果未知依赖组包含模型超时、策略服务中断、日志延迟和对象存储不可用业务组包含指标恶化、影响行数超额和不可逆动作。每次发布预演控制器或写入代理时至少回放一组高风险用例。测试还要检查失败是否“关在原地”。模型通道故障不应影响已经签发租约的验证日志积压不应拖垮只读查询单个租户的错误任务不能占满恢复队列。对每条依赖定义失败模式保守拒绝、有限降级或异步补记。关键授权服务只能保守拒绝非关键展示指标可以延迟审计事实不能丢失只能进入本地追加队列等待恢复。演练结果应进入发布门禁。严重用例未通过时禁止扩大资源范围恢复时间超过值班承诺时降低自动化级别误阻断率过高时保留只提案模式。门禁的目标不是追求一次测试全绿而是保证失败不会悄悄把系统推回“模型拿着长期凭据直接写生产”的旧路径。九、落地顺序与停止条件不是所有团队都需要生产写权限 Agent落地可以从“只提案”开始。第一阶段让 Agent 读取监控、配置和代码输出结构化 Plan由人手工执行第二阶段建立影子数据面和 Effect 报告但仍不签发生产租约第三阶段只开放可逆、低风险动作例如测试环境配置和灰度权重第四阶段在故障演练通过后才考虑受限的生产写入。每个阶段都要有退出标准。只提案阶段关注 Plan 可解析率和遗漏前置条件数量预演阶段关注副作用发现率和误阻断受限执行阶段关注重复写入、未知状态恢复和回滚时间生产阶段再增加业务 SLO、审计覆盖与人工负担。指标没有达到门槛就停在当前阶段修正不因演示效果继续扩大权限。团队还应明确停止自动化的条件资源版本持续漂移、审计链中断、租约撤销列表不可用、异常率超过预算、模型输出结构连续失败或者值班人员无法在规定时间接管。停止不是系统失败而是安全设计的一部分。生产写入 Agent 必须拥有明确的关闭开关并且关闭动作不依赖同一套模型服务。有三类场景不值得引入完整协议。第一任务低频且每次结构差异很大维护适配器比人工处理更贵第二动作不可逆且缺少可靠的完成查询例如某些外部通知和资金操作第三组织没有资源负责人、变更审批和事故响应制度。技术沙箱不能替代组织责任没人接管的自动化只会把故障发现时间推迟。平台成本也应按成功变更计算。总成本不仅包括模型调用还包括影子环境、证据存储、策略维护、人工审批、故障演练和适配器升级。一个每月只执行两次的高风险动作即使技术上可以自动化也可能由标准化人工运行手册完成得更便宜。相反每天重复数百次、输入边界稳定且可验证的修复任务更容易摊薄控制面的固定成本。组织分工至少包括任务模板负责人、资源负责人、策略负责人、平台值班人和审计查看者。一个人可以承担多个角色但每项职责必须有明确接管路径。模型路由升级由平台负责不应悄悄改变业务批准的 Effect资源负责人修改不变量时也要通知任务模板维护者更新回归样本。生产安全来自这些接口而不是某个单独团队“对 AI 负责”。运行看板应优先展示拒绝原因、未知状态年龄、租约使用次数、预演与生产漂移、回滚耗时和人工等待而不是只展示 Agent 完成任务数量。完成数量很容易激励团队扩大权限边界指标才能说明系统是否仍在可控范围。月度复盘选择被阻断、被撤销和人工接管的真实案例检查规则是避免了事故还是制造了无效等待。真正值得保留的系统应在 30 天观察期内证明三件事高风险副作用能在生产前被发现未知状态能够恢复为确定事实人工复核时间随着模板成熟而下降。如果只能证明“Agent 执行了更多命令”就还没有建立生产能力。自主 Agent 的安全边界最终不是一道 Prompt也不是一组 Docker 参数而是一条从意图、预演、授权、写入到验证的责任链。模型负责提出候选方案策略服务负责约束影子数据面负责暴露副作用能力租约负责收窄权限写入代理负责执行确定动作人类仍然负责接受风险。把第一次写操作放在可观察、可撤销的预演世界里生产环境才不必承担模型试错的成本。