敢让 AI 碰真实系统是体系给的底气

这是「AI 落地四形态」系列的第四讲。上一讲的结尾钩是：当客户说「审批过了直接帮我做」，知识问答链就走到头了——这一讲讲接下去那一格。

真实卡住的场景：做一个 AI 应用交付，客户要求「让 AI 直接去把事办了」。搜出来的方案出奇一致——插件、OpenAPI、MCP，半小时接好。但教程集体跳过一个问题：接上之后，你敢让它碰生产系统吗？实际交付里，负责审批的人问了三句话：「它要是乱来怎么办？有没有人能拦住它？出了事怎么查？」三个问题教程一个都没答，方案当场卡住。「接上」和「敢用」之间隔着一整个执行体系——不是模型能力问题，是体系问题。

分界：调一个能力（工具级集成，一次调用同步返回、结果即所得）vs 托付一件任务（任务级交付，自己拆步骤、跑命令、看中间结果、汇总）。任务级要求三样工具级没有的东西：流程不能死等、中途要能插人、出了事要能说清。

三条路实测：市场插件能接能调（短问答 8 秒级），但同步对话式——无法断点插入审批、无任务状态；自定义工具/OpenAPI 本质同插件，无状态无闸门；MCP 也没有「任务挂起等审批再继续」的语义。工具级缺的恰好是任务级要的三样——状态、断点、闸门。不是方案不好，是工具级这个层级本身不提供，必须自己建一层。

柱子一 断点式执行编排：为什么不直连、中间非要有一层——三个结构性原因：同步与异步的断层（平台 HTTP 节点是同步世界，Agent 真执行是分钟级世界，简单任务 8–15 秒、深度任务一分钟起）、任务状态需要一个「活着的地方」、闸门需要一个咽喉位置（否则 Agent 就是「裸奔的执行体」）。执行服务很小——约 160 行、零第三方依赖、五个职责：投递接收（秒回受理加任务 ID，实测 0.6 秒）、任务状态机（已受理/执行中/已完成或已失败）、转交执行（异步派活、失败自动重试）、双态回写（无论成功失败都回调收口流程，是交付可信度的底线）、兜底与闸门（执行超时先停掉孤儿执行，不允许任务悬空）。容易误会的点：发起流程投递完就结束了，结果由独立的收口流程承接。这一层刻意做小——只做断点承接、不做业务不掺编排、坏了能十分钟看穿，职责收敛本身就是可靠性设计。

柱子二 安全闸门：一个反直觉的实测——Agent 自己的原生审批在无人值守链路上并不拦高危动作。所以拦不拦得住破坏性任务，不取决于 Agent 自觉，取决于链路里有没有强制闸门。第一层机器粗筛：高危模式库（递归删除/根路径强删/关机重启/格式化/清表），命中默认拒绝、执行体零接触，不是先跑了再拦；第二层人工终审：关键词会误伤正常业务描述，改成任务包显式声明加审批授权置位，「声明含高危 + 授权位置位」双条件才放行，授权位单次有效、不跨任务复用。边界层：执行体以最小权限账号运行、命令白名单——审批授权管「能不能做」，执行身份管「能做到哪」。三环控制按时间分工：意图边界（事前声明动作清单）、执行边界（事中，越界命令在系统层直接被拒）、越界判定（事后审计逐条比对）——越界拦截发生在事中，唯独不靠「告诉 AI 自觉」。最后一道保险：失败不许静默——三类故障注入（停服务/强制中断/超时）暴露失败信号根本回不到流程，兜底方案是双态回写加人工兜底指引。

柱子三 对照验证：怎么证明「敢用」不是自我感动？同一个模型、同一个任务描述（发布前服务器巡检）两条路各跑一遍——路 A 纯平台内无执行通道，它诚实拒答「我无法执行，所有数值都将是凭空编造的」；路 B 走「平台发起 + 执行服务 + Agent 真执行」，约 10 秒回来全字段 JSON。然后拿报告回服务器手动重跑巡检脚本对账：进程号、版本号、主机名逐项一致，内存小数浮动反而证明它是真读的不是背的。差异不在模型智商，在执行通道。把对照验证列为柱子之一是有意的：前两根解决「能不能」，这一根解决「凭什么信」——客户不是不信 AI，是不信「不可验证的 AI」。

判据三问（命中任何一问就走任务级）：AI 要碰真实系统吗／执行需要人把关吗／结果要回到流程继续用吗。工具级轻快零部署，任务级才需要整套体系——三根柱子缺一根，敢用就缺一块地基。

四条实测边界：执行服务当前是实验验证形态（生产化四件事：任务台账落盘、授权升级为显式声明、鉴权与多租户隔离、最小权限专用户部署）；意图声明机制适用于结构化任务投递，纯自然语言对话要先加「意图转声明」的强制确认；变更类写任务要另配幂等键与回滚步骤，生产化方向可引入执行预览；执行完成不等于任务成功——Agent 常以「如实汇报错误」完成执行，收口侧要做结果语义体检，把「完成了但没干成」如实报告为异常。

金句：敢让 AI 碰真实系统，不是模型给的底气，是体系给的。下一讲进入最后一格——流程卡在等人审批。

完整文字版见下方文章。