AI Agent 场景选型：四道门与 YAML 边界配置

根据阿里巴巴官方文档，2026 年 8 月 3 日，阿里巴巴宣布推出一站式办公 AI 智能体平台“千问办公”。

我们据此做一个判断：企业接下来关注的不只会是“能不能回答”，还会是“能不能交付一个可检查的结果”。这不是阿里巴巴的原话。

这个变化很容易让企业产生一种冲动：第一个场景是不是也该选一个“大任务”，一次证明 Agent 真能干活？

我的判断恰好相反。

越是进入“交付结果”的阶段，第一个场景越不能只看演示效果。因为它不再只是回答一句话，而是开始读取真实数据、调用真实工具、改变真实流程。场景一旦选大了，团队很可能同时撞上数据、权限、验收和接管四堵墙，最后连问题出在哪一堵都说不清。

第一个场景，先排除三类“错不起”

第一类，结果很难独立验收。

比如“帮管理层做经营判断”听起来价值很大，但判断好不好往往要过很久才知道。第一轮就选这种任务，模型说得再完整，团队也缺少一把当场能用的尺子。

第二类，一上来就要高权限。

自动改价、付款、删除、对外承诺，都可能只需要一次工具调用，却会立刻产生业务后果。第一个项目如果必须先拿到这些权限才能证明价值，试错空间会非常小。

第三类，出错后很难收回。

超时后重复建单、发错消息后无法撤回、状态写错却没有审计记录，这些问题不是“准确率再高一点”就能解决的。它们说明恢复路径根本没被设计。

先排除这三类，不是保守，而是让团队第一次就能知道：什么算对，什么算错，错了由谁接。

场景名字不重要，动作边界才重要

一些选型会列一张表：客服分流、知识问答、工单摘要、报表分析，然后争论哪个优先级最高。

这张表的问题是，同一个名字下面可能藏着完全不同的动作。

“客服分流”如果只是给坐席建议队列，低置信度自动转人工，错分后还能退回，它可以是一个很好的起点。可如果它会直接回复客户、修改工单状态、触发退款，那就已经是另一个风险等级。

“内部问答”也不天然安全。只显示答案和引用，通常容易核对；如果答案会直接触发采购、审批或对外承诺，错误照样会离开内部系统。

所以，不要问“客服场景适不适合先做”。要问的是：这个场景的第一版，究竟被允许做到哪一步？

把评审问题落成可检查材料时，可以先对照生产就绪检查项逐项写清数据、工具、验收和人工接管，再决定是否扩大动作范围。

用四道门给候选场景改判

把每个候选场景都过一遍四道门：

• 结果能不能独立验收：负责人能拿真实样本判断对错，不靠“看起来不错”。
• 输入是不是相对稳定：关键字段、知识和规则有明确来源，缺失时会停，而不是自行补齐。
• 错误能不能隔离和撤回：一次错误不会扩散，已经发生的动作有补偿或撤回路径。
• 权限和接管是不是有人负责：谁批准数据和工具，谁接低置信度与异常结果，都写得出名字。

四道门里有一项说不清，也不必马上换场景。本文建议先缩小动作范围，再重新评审：

• 从自动执行退到生成建议；
• 从写操作退到只读查询；
• 从直接回复退到人工确认；
• 从全部用户退到一类请求或一个队列。

这比重新挑一个“听起来更简单”的场景更有效。因为真正需要被控制的不是场景名称，而是动作半径。

第一个项目，要买到“可继续”

很多团队希望第一期立刻证明节省了多少时间。这当然重要，但更重要的是，项目结束后有没有留下下一期还能用的东西。

按本文的评审方法，首个场景应该沉淀四样可复用材料：

1. 一批业务认可的验收样本；
2. 一张写到具体动作的权限表；
3. 一条真实跑过的人工接管路径；
4. 一份可以回放输入、工具调用和结果的运行记录。

有了这些，第二个场景才不是重新开盲盒。团队可以复用验收口径、权限模式和失败处理，再逐步扩大动作范围。

高价值场景也不必往后排。如果它本来就有稳定样本、窄权限、成熟接管和可回放记录，先做同样合理。四道门不是固定排行榜，而是一套改判工具。

千问办公的推出让“交付结果”成为一个更具体的话题。对企业而言，下一步不是再找一个更大的演示，而是把第一个真实动作关进可验收、可接管、可撤回的边界里。

可直接带进评审的材料

下面是一份示例配置，作用不是给所有场景套同一答案，而是把评审结论变成能被版本控制和测试读取的边界：

scenario:ticket_summarymode:suggestallowed_actions:-read_ticket-draft_summarydenied_actions:-update_priority-notify_customeron_missing_input:stopon_low_confidence:handoffevidence:-input_ref-rule_version-tool_resulttests:-case:missing_descriptionexpect:stop-case:notify_without_approvalexpect:deny

配置落库后，至少自动跑两个反向用例：缺少必要字段必须停止；没有批准时请求通知客户必须拒绝。评审通过也不是把mode直接改成auto，而是先给新增动作补验收样本、批准人和恢复路径，再单独升级。这样配置 diff 和测试结果能一起回答“这次到底多放了什么权”。

场景表不能只留“客服分流、知识问答、报表分析”这类业务名称。工程评审至少还要补上允许动作、输入来源、验收人、失败信号和恢复方式。这样同一个业务名称才能被拆成风险完全不同的版本：只读查询是一版，生成建议是一版，自动写入又是另一版。

落库时，可以把“允许动作”做成枚举，而不是一段自然语言备注；把“缺字段时怎么处理”和“低置信度交给谁”写成可测试规则；把每次放权使用的验收样本、规则版本和批准人写进变更记录。后续换模型时，先重跑同一批边界样本，不需要重新争论场景名称。

评审结果也不应该只有通过和否决。更实用的状态是：只读验证、建议模式、人工确认执行、可逆自动执行，以及明确禁止。每次状态变化都要同时给出证据和退回条件。

场景评审的结论不必是做或不做。更有用的结论是：第一版允许做到哪一步，缺哪份证据就不继续扩权。

官方文档核对：阿里巴巴 2026-08-03 千问办公公告。