AI接手关键操作前，先把“决定”和“执行”拆开

一句“把生产环境的 payments-gateway 切到备用区域”，背后可能牵动算力、数据库、缓存和流量。Intuit 最新披露的灾备智能体 EWOK Agent，让值班工程师用自然语言发起这类切换；但它最值得企业借鉴的，并不是“AI 会执行故障恢复”，而是一个克制的分工：模型决定该做什么，确定性系统决定怎样执行。

Intuit 原有的灾备编排系统已把受支持工作负载的恢复时间从数小时缩短至约20分钟，但选择恢复流程、确认资产是否就绪、处理变更冻结期的例外，仍依赖资深值班人员经验。EWOK Agent 补的是“理解与协调”：它识别资产、列出可用流程、做就绪与策略检查、创建变更记录、发起执行，并持续回报各阶段状态；真正改变生产环境的动作仍由既有 API 和工作流完成。

把经验写成技能，但别把控制权交给提示词

该案例把灾备知识改写为带输入输出约束的技能：既有机器可读的字段定义，也有逐步操作、停止条件和策略分支。变更冻结期并不被当成可由模型绕过的报错；系统只会要求工程师提供事故编号或紧急理由，用户拒绝则停止。失败步骤也必须立即结束，不能让模型自由尝试替代路径。

这是生产级智能体与聊天助手的分界。模型适合解释模糊请求、在已批准选项中选择、串联结果并和人沟通；权限校验、状态改变、重试策略和审计记录，应留在传统、可测试的执行器中。模型不持有云端凭证，也不直接连接灾备系统；执行器在请求范围内取得身份，返回结构化成功或失败状态。每个关键动作因而沿用与人工操作相同的审批和审计链。

每向前放开一步，都应把可变的判断留给模型，把不可逆的执行锁进可验证的系统。

STARBOX视角：给智能体一张“动作双账本”

STARBOX 的组织层应先定义谁能请求、谁能批准、什么情形必须停止；BOX 层保存经确认的技能版本、允许动作、例外分支和结果证据；智能体层只负责把请求映射到已授权能力。这里需要两本账：一笔记录模型为什么提出动作，另一笔记录执行器是否按规则完成、由谁批准。两者不能混成一段自然语言总结。

DDABC 也因此多了一条生产线：Define 划清判断与执行接口；Deploy 让智能体接入受限工具；Analyze 看哪些请求频繁被拒绝或转人工；Benchmark 比较成功率、等待时间与误触发；Calibrate 再更新技能和策略。企业真正要规模化的，不是“让 AI 有更大权限”，而是让它在更清楚接口内承担更多协调工作。

当智能体开始触及订单、付款、发布或设备，最重要的问题不再是“它聪不聪明”，而是：它提出行动后，谁用什么规则把行动变成事实？把这道边界设计好，AI 才能从演示进入关键工作，而不会把风险一起放大。

这套边界对营销、客服和运营同样适用。比如内容智能体可以根据品牌知识提出发布计划，却不应自行越过审批把内容推送到外部渠道；销售智能体可以整理客户信号、建议下一步，却不应直接改写合同条款或授予折扣。企业需要预先写清哪些工具只是读取，哪些可以创建草稿，哪些动作必须附带审批号、工单号或负责人确认。这样，人的判断不是在每一步重复点击，而是集中在真正改变业务承诺和风险敞口的节点。

来源：AWS《How Intuit built an agentic disaster recovery assistant with Amazon Bedrock》（2026-09-04）。文中恢复时间与运行时长均按 Intuit/AWS 案例表述，不外推为行业平均。