AI Agent 上生产前先加三道闸门审批、限权、可回放的工程实践关于模型说执行就执行的争论其实很少停留在模型层。真正把团队拦在生产环境门外的是这样一个问题当 Agent 的一次工具调用产生不可逆副作用时系统能不能在毫秒级拦住它、让人介入、并在三天后完整复现当时发生了什么。这不是提示词工程问题而是运行时的可控性工程问题。近期社区里先加三道闸门再碰真实业务的提法引起了不少讨论 [1]本文在此基础上向后端纵深推进把审批做成可持久化的状态机把限权落到工具治理的实处把第三道闸门升级为可重放的 Harness。一、Demo 能跑与能上生产之间的距离1.1 一次失控调用的典型链路先看一个合成的示意场景它不是真实事故但结构上接近团队最常见的失控路径业务人员输入“把 A 仓的超储部分调拨到 B 仓。”Agent 规划后选择工具create_stock_transfer构造参数时把数量字段理解为整仓全量同时漏掉了目标仓的容量校验参数直接提交了一张调拨单。把这条链路拆开失控通常发生在四段阶段发生了什么失控的表现缺失的约束意图理解自然语言转成任务目标目标被放大或曲解意图澄清、确认工具选择从工具集中挑一个选中语义相近但危险的工具工具风险分级参数构造填写调用参数字段含义错配、范围越界参数校验、权限收窄副作用执行调用下游系统不可逆写入已完成审批、可回滚、留痕注意四段里只有一段是模型能力问题另外三段都是工程问题。指望通过更强的模型、更精细的提示词消除后三段风险在工程上不成立模型输出本质上是概率性的而生产系统要求的是确定性边界。可控性工程的思路正是把确定性约束放在运行时而不是放在模型的自觉上。1.2 三道闸门分别解决什么本文所说的三道闸门是一个工程化提法不是行业标准术语但它们各自对应一类明确的失效模式审批决策授权解决该不该做。在有风险的动作执行前中断把决策权交给人或策略引擎而不是交给模型。限权能力边界解决能做什么。即使用错工具、参数错配也只能在被允许的范围内造成影响。可回放行为可追可复现解决事后怎么说清。让每一次运行都能被审计、被复现、被用于回归评估。三者缺一不可且互相不能替代。只有审批没有限权审批者面对的是海量高危请求最终变成无脑点同意有限权没有审批不可逆动作仍然会以合法权限被执行两者都有但无法回放出事之后既不能定位根因也不能证明系统当时的行为符合规则。1.3 适用边界与阅读路线本文聚焦运行时工程约束不覆盖提示注入的系统化治理、模型越狱防御、训练侧安全对齐等主题这些是另一条战线与本文措施互补。代码示例均为结构示意的伪代码具体 API 需以所用框架的官方文档为准。章节主要闸门可直接取用的产出第二章审批风险分级矩阵、审批状态机、持久化要点第三章限权权限收窄维度、MCP 坑位清单、运行时硬约束第四章可回放事件日志 schema、回放边界第五、六章三者串联端到端时序、Checklist、实施路径二、闸门一把审批做成状态机而不是弹窗2.1 哪些动作必须审批风险分级矩阵审批不是所有调用都要走否则系统会被拖死。判断依据主要是三个维度可逆性能否撤销、影响面影响单条记录还是全局、敏感度是否涉及资金、合规、对外触达。以开源项目double-ai-agent_1的业务域为参照该项目基于 Spring AI Alibaba Graph 构建涵盖自然语言驱动的 BI 查询与智能库存调拨并宣称支持 RAG、人工审批与图状态持久化 [3]。其中两类工具的风险等级显然不同工具动作类型可逆性影响面风险级策略query_bi_metrics只读查询完全可逆单一数据域低自动放行仅留痕create_stock_transfer业务单据写入流程内可撤销但已触发下游作业则代价高跨仓、跨部门中高强制人工审批send_notification_external对外触达不可逆外部客户高双人审批 限额一个可复用的空白模板如下建议在工具注册时就强制填写未填写的工具默认最高风险级# 配置示意字段为设计建议非任何框架的原生格式tool:create_stock_transferrisk_level:high# low / medium / high / criticalreversible:partialimpact_scope:cross_domain# single_record / single_domain / cross_domain / globalapproval_policy:required:trueapprovers:1# 或 2 表示双人复核sla_minutes:30on_timeout:reject# 超时默认拒绝优于默认放行param_constraints:max_quantity:5000allowed_warehouses:[A,B,C]rollback:method:compensating_order# 补偿式撤销而非假装删除这里有一个容易被忽略的取舍审批粒度。工具级审批实现简单但粗糙参数级审批精准但实现和体验成本高业务单据级审批最贴近组织流程但需要与单据系统集成。实践中常见做法是工具级定策略、参数级做校验、单据级做留痕三层叠加。double-ai-agent_1的实际审批粒度究竟落在哪一层需要读源码确认仓库描述本身不能作为实现细节的证据 [3]。2.2 中断-等待-恢复审批的运行时模型审批的本质是一次长事务Agent 执行到高危动作前挂起把执行上下文序列化等待外部决策再从断点恢复。它必须处理的状态迁移至少包括批准、驳回、超时、改参重试。运行中 ──触发高危工具── 待审批 ──批准── 运行中 │ ├──驳回────── 终止或回退到上一步重新规划 ├──超时────── 终止默认拒绝 └──改参重试── 运行中生成新 step_id保留原请求记录对应的骨架逻辑结构示意# 伪代码展示状态迁移骨架不对应任何具体 SDKasyncdefrun_step(ctx,action):policypolicy_engine.evaluate(action)ifpolicy.levelRISK_MEDIUM:checkpointpersist.save(run_idctx.run_id,step_idctx.step_id,snapshotctx.snapshot(),# 含计划、中间变量、工具候选pending_actionaction,)decisionapproval_bus.wait(checkpoint.id,timeoutpolicy.sla)ifdecision.kindrejected:returnterminate(ctx,reasondecision.reason)ifdecision.kindtimeout:returnterminate(ctx,reasonapproval_timeout)ifdecision.kindedited:actiondecision.action# 改参后重新校验而不是直接放行policypolicy_engine.evaluate(action)ctx.restore(checkpoint.id)returntool_executor.execute(action)# 仍需经过限权层见第三章四个容易踩空的点审批不是授权的终点。改参后的动作必须重新过策略引擎否则改参就成了绕过审批的后门。超时默认应为拒绝。默认放行会在审批人力不足时把风险全部释放到生产。并发互不阻塞。多次运行、同一运行的多个待审批点应各自独立不应互相排队。驳回要有语义。驳回并终止与驳回并重新规划是不同策略需按动作类型区分。关于 Spring AI Alibaba Graph 是否提供官方的中断、人工介入与恢复 API本次研究材料不足以给出确切结论double-ai-agent_1声称具备人工审批与图状态持久化能力 [3]但具体 API 形态需以框架官方文档和仓库源码为准。若框架不提供原生支持采用上述自研 checkpoint 模式是可行路径代价是要自己解决序列化、幂等与恢复语义。2.3 状态持久化进程重启后审批还有效如果审批状态只存在于内存里服务一次发布就会丢掉所有待办用户看到的是调用凭空消失。持久化设计至少要回答三件事存什么执行快照计划、上下文摘要、待执行动作 决策记录谁、何时、批准/驳回/改参、理由。幂等键怎么设计run_id step_id action_hash保证同一动作重复提交不会生成多张审批单。恢复语义重启后从最近快照恢复到断点已执行的副作用不得重放这要求工具调用本身也带幂等键。一个可行的事件与快照组合是审批单与决策记录用关系型数据库落表便于查询与权限控制执行过程用事件日志追加见第四章。double-ai-agent_1把图状态持久化列为其企业级能力之一 [3]可作为参照实现的方向但其是否只存快照、是否含事件流、崩溃恢复语义如何需要核对源码后才能判断。2.4 审批体验的工程细节审批系统最常见的失败不是技术失败而是审批疲劳。要让人真正判断审批单必须包含调用工具名、参数差异相对系统建议值或上一版本、预期副作用、影响对象数量、回滚方式与成本、该动作的历史批准/驳回统计。降低疲劳的手段包括低风险动作按策略自动放行并事后抽查、同类批量请求合并审批、设置 SLA 超时告警、对反复驳回的任务类型直接降低 Agent 的自主级别。审批率与驳回率应作为持续指标观察驳回率过低往往意味着审批者在无脑批准而不是 Agent 越来越准。三、闸门二最小权限与 MCP 的真实坑位3.1 工具即权限按数据域 × 动作 × 环境收窄给模型全部工具然后用提示词约束它不要乱用是可控性工程里的第一反模式。提示词是概率性的工具集是确定性的把安全边界放在概率性的一侧等于没有边界。正确的做法是在注册层就做裁剪模型看到的工具集本来就只是它被允许使用的那一部分。收窄的三个维度维度取值示例收窄方式数据域订单 / 库存 / 财务 / 用户按租户与角色绑定可见工具动作类型读 / 写 / 对外触达写与触达类单独注册、单独审批环境dev / staging / prod生产工具集最小化禁止跨环境混用# 工具集组装示意需替换为实际框架的注册写法contexts:-name:inventory_agent_prodtenant:tenant_aallowed_tools:-query_bi_metrics# 只读-create_stock_transfer# 写入强制审批denied_tools:-drop_table-send_notification_externalnetwork_egress:allow:[erp.internal.example]另外凭据不应随工具描述暴露给模型。正确形态是Agent 只拿到工具句柄真实凭据由执行侧在调用时注入且按会话隔离、可轮换、可吊销。3.2 MCP 接入的真实坑位清单MCP 解决的是模型如何发现和调用工具不解决工具该不该被调用。从能连上到生产可用社区实践反馈中反复出现的问题包括以下几类 [2][6]坑位表现应对工具描述歧义语义相近的工具被误选描述中写明边界与副作用风险级标注工具数量爆炸上下文被工具 schema 填满成本与误选率上升按场景动态裁剪工具集分层注册schema 与实际行为不一致声称只读实际触发写入契约测试执行侧二次校验鉴权凭据传递会话间串用、无法轮换执行侧注入、按会话隔离、短时效长会话与服务重启连接断开、工具结果丢失、无法恢复重连策略 事件落盘见第四章工具结果超长返回被截断后模型基于残缺信息继续决策摘要与原文分存关键字段强制校验多 Server 版本漂移同名工具在不同环境下行为不同版本锁定 环境隔离 变更审计需要说明的是上表是根据社区讨论与实践文章归纳的候选清单 [2][6]其中具体条目与归因仍建议对照 MCP 官方规范逐条核实本次研究材料未提供规范原文链接本文不对其版本号与条款细节作断言。社区文章的单点经验也不能当作普遍结论 [7]。3.3 运行时硬约束沙箱、出网与审计权限收窄之外还有一类约束必须在运行时硬性执行任何提示词都不应能绕过命令执行沙箱涉及 shell 或代码执行的工具运行在隔离容器中限制文件系统写入范围与 CPU/内存配额。出网白名单Agent 的网络出口默认拒绝仅放行业务必要域名防止数据外带。工具调用强制入审计无论成功、失败还是被拦截都留下记录。没有记录的拦截等于没有拦截。资源配额单次运行的工具调用次数、总 token 消耗、执行时长设上限超限即中断。多智能体编排中尤其需要轮次上限避免子任务互相驱动而无限扩张 [6][8]。有团队在数月落地实践中总结过类似经验权限与隔离问题往往比模型效果问题更早爆发 [7]。这也解释了为什么限权应当排在效果调优之前。四、闸门三可重放的 Harness4.1 为什么要回放三种诉求三种保真度“可回放经常被简化成有日志”但三类诉求对保真度的要求并不相同诉求需要什么保真度要求排障完整执行过程、每步输入输出高要能还原分支与中间状态回归评估可比对的输入输出对中重点是可重复执行同一用例合规审计不可篡改的决策留痕高且要求完整性与时间顺序可验证Harness 的概念正在从测试脚手架演变为运行时基础设施它负责驱动 Agent 循环、管理状态、记录事件并支持从任意断点恢复。SmartAI/ava将自己描述为面向 Python 的durable、replayable 的编码智能体 Harness [4]CSDN 上关于 hermes-agent 的文章也把 Harness 作为框架组件单独讨论 [5]。这两个来源印证了Harness 正在成为独立关注点这一趋势但其内部录制格式、恢复语义与成熟度需要阅读源码或文档后才能判断本文不依据标题推断实现细节。4.2 Harness 里到底录什么一次运行至少要记录以下事件才能支撑上述三类诉求{schema_version:1,run_id:run_20260318_ab12,step_id:step_007,event_type:tool_call,ts:2026-03-18T10:21:33.412Z,actor:agent:inventory_bot,payload:{tool:create_stock_transfer,params_digest:sha256:...,risk_level:high,policy_decision:require_approval,approval_id:apr_9f31},env:{app_version:1.8.2,model:recorded,mcp_server_versions:{erp:2.3.0}}}字段清单为设计建议不代表任何现有框架的格式。要点有三个run_id / step_id 串联全链路payload 存摘要原文进对象存储并以哈希关联避免日志库爆炸环境信息必须记录包括应用版本、模型标识、各 MCP Server 版本否则换一次依赖就无法复现。此外审批决策点必须作为事件记录而不是只留在审批系统的界面上。审计要回答的问题是当时系统为什么允许这个动作这需要决策依据与执行动作在同一时间线上。4.3 事件日志与状态快照的组合只存最终结果无法排障只存事件流在长链路里恢复成本高。实践中的取舍通常是事件日志追加写快照定期存。方案优点代价适用仅结果成本最低无法复盘不推荐用于生产仅事件流完整可追长链路恢复需重放全量短链路、低频任务事件流 快照恢复快、可追溯双写一致性要处理多数生产场景一致性上的稳妥做法是快照只记录已确认完成的 step 边界任何进行中的步骤都不进快照恢复时从最近快照加后续事件重建。4.4 确定性回放的边界必须明确一点回放验证的是编排、权限与工具链路不是模型能力。LLM 输出存在随机性同一输入两次调用可能得到不同计划。要做到可重放录制模式下需要把不确定性来源全部固定模型原始请求与响应全文录制重放时直接使用录制结果不再调用模型时间、随机数、外部服务响应在录制模式下一并捕获重放时替换真实调用工具执行分两类纯函数型可真正重跑有副作用型在重放中以录制结果代替并显式标注模拟执行。这里有一条红线回放时绝不能修改录制数据来让测试通过。一旦允许编辑录制内容回放就从验证手段退化成了自我安慰。录制数据应只读、可校验哈希、与原始执行环境的版本信息绑定。五、端到端走查一次库存调拨如何穿过三道闸门沿用前文的示例场景示例非真实实现把整条链路串起来用户输入把 A 仓超储部分调拨到 B 仓 │ ├─ 1. 意图澄清确认品种、数量口径、目标仓 ├─ 2. 规划生成计划选取工具 create_stock_transfer ├─ 3. 限权检查工具在该租户工具集内参数通过数量与仓别校验 │ └─ 不通过 → 拦截并记录事件结束 ├─ 4. 风险判定high → 触发审批 │ ├─ 保存 checkpoint快照 待执行动作 │ ├─ 挂起进入待审批 │ └─ 批准 → 恢复驳回 → 终止超时 → 拒绝 ├─ 5. 执行调用下游系统携带幂等键 ├─ 6. 落盘工具调用、结果、审批决策写入事件日志 └─ 7. 可回放任意时间可从事件与快照重建本次运行配置层面建议先严后松生产环境初期对中高风险动作全部强制审批灰度稳定后按动作类型逐步放开低风险自动放行权限白名单只增不减需要经过变更评审所有配置变更本身也要入审计。上线后重点观测的指标指标观察意义建议关注点非行业基准待审批平均时长审批是否成为瓶颈持续接近 SLA 需扩容审批人力或下调自主级别审批驳回率计划质量与风险识别长期接近零需警惕无脑批准工具调用拦截率权限与参数校验是否生效突然归零可能意味着校验被绕过回放成功率留痕完整性低于预期优先检查事件丢失异常恢复次数状态机健壮性频繁恢复需检查外部依赖稳定性阈值应由各团队按自身业务风险设定本文不提供通用基准值。六、上线清单与反模式6.1 上线前 Checklist审批所有工具已标注风险等级未标注者默认最高级中高风险动作的审批策略已配置超时默认拒绝审批单包含参数摘要、预期副作用与回滚方式改参后动作会重新过策略引擎限权工具集按租户、角色、环境裁剪生产工具集最小化凭据由执行侧注入按会话隔离支持轮换与吊销命令执行有沙箱网络出口默认拒绝并有白名单工具调用含被拦截的全部进入审计日志单次运行的调用次数、时长、消耗设上限可回放事件日志含 run_id / step_id / 环境版本信息审批决策作为事件记录与执行动作同时间线录制模式固定模型响应、时间、随机数与外部响应录制数据只读、可校验禁止为通过测试而修改观测待审批时长、驳回率、拦截率、回放成功率有看板与告警配置与权限变更本身有审计记录6.2 常见反模式审批疲劳所有调用都审批最终人人无脑批准。应按风险分级把人力留给高风险动作。权限一刀切后偷偷开白名单临时豁免没有记录、没有到期时间等于长期漏洞。只存结果不存过程出问题只能看到失败了看不到为什么失败。把审批做成前端弹窗进程重启即丢状态审批记录与执行动作对不上账。回放时修改录制数据验证机制失效且掩盖了真实缺陷。把提示词当权限任何请不要调用 X 工具都不构成安全边界。6.3 分阶段实施路径资源有限时建议顺序是审计留痕 → 权限收窄 → 审批状态机 → 可重放 Harness。理由是留痕成本最低、收益立刻可见且是后续所有工作的数据基础权限收窄直接削减爆炸半径审批状态机依赖前两者的策略与事件能力完整 Harness 的投入最大但能同时服务排障、回归与合规。每阶段的够了标准留痕阶段能回答过去 24 小时 Agent 调用了哪些工具限权阶段能在测试中证明越权调用被拦截审批阶段能演示进程重启后审批单仍可恢复并继续执行Harness 阶节能对任一历史运行重放并给出与录制一致的行为序列。七、结语三道闸门的共同本质是把模型的自由度关进运行时的确定性约束里。模型负责提出方案系统负责决定方案能不能执行、执行到什么范围、事后如何还原。这不是对模型能力的不信任而是工程系统的基本要求任何产生真实副作用的组件无论它内部是规则引擎还是神经网络都必须服从同样的授权、边界与审计规则。值得强调的是本文的技术判断基于公开的社区文章与仓库描述其中不少实现细节尚未逐条核对源码与官方规范 [2][3][4][5][6]。把这些当作方向性参考落到自己的系统前先做验证本身就是可控性工程的一部分。参考资料[1] 前端开发者做 Agent模型说执行就执行先加 3 道闸门再碰真实业务掘金。https://juejin.cn/post/7636280185700990986[2] 热榜都在吹 MCP Skills 万能我搭了个 AI Agent 才发现最大的坑不是 Skill掘金。https://juejin.cn/post/7605807405308051519[3] 豆芽/double-ai-agent_1企业级双引擎 AI 智能体Spring AI Alibaba GraphRAG、人工审批、图状态持久化Gitee。https://gitee.com/mitouhao/double-ai-agent_1[4] SmartAI/avaA durable, replayable coding-agent harness for PythonGitHub。https://github.com/SmartAI/ava[5] 【Agent】构建 Harness | hermes-agent 框架组件CSDN。https://blog.csdn.net/qq_35812205/article/details/160281584[6] 2026年AI Agent开发实战MCP协议深度解析与多智能体协作架构完全指南掘金。https://juejin.cn/post/7628131346834063410[7] 从 3 个月 AI Agent 落地实战聊透我踩过的坑和摸到的门道掘金。https://juejin.cn/post/7601034810313130038[8] AI Agent 工作流编排用 Subagent 实现复杂任务分解掘金。https://juejin.cn/post/7616650313060155443注本次研究资料未提供 MCP 官方规范原文链接文中涉及规范版本、能力协商与鉴权机制的内容未作具体断言建议实施时另行对照官方文档核实上述来源多为社区文章与仓库描述其中的实现细节需以源码与官方文档为准。