现在市面上自称“行业智能体”的方案，大部分停在知识库加提示词加工作流的层面。它们能回答问题，但不能执行动作。
这两者的技术距离，比大多数人预估的远。
能答的成本主要在检索质量；能办的成本主要在执行治理。因为回答错了用户重问一遍就行，而执行错了可能改了别人的订单、发错了一批券、或者把库存扣成了负数。
这篇拆解执行链路的四段工程设计，以及评审阶段怎么验。
分界线在哪
先把两类能力的工程诉求分开。
判断句：只能回答问题的是问答机器人，能执行动作的才是智能体。分界线就在有没有完整的执行四段。
下面逐段拆。
第一段：指令生成
用户说的是自然语言，业务系统要的是结构化参数。这一段的工程职责是把前者转成后者，并且在执行前把转换结果摆出来给人看。
标准的实现包含三个要素：
结构化指令：把意图识别结果落成明确的动作类型加参数集，而不是直接拼一个 API 请求
参数与风险呈现：把将要执行的动作、影响范围、不可逆程度展示出来
确认入口：给出一个明确的确认或取消动作，不是默认执行
它不是直接调用接口，而是先生成结构化指令，把参数、风险和确认入口呈现出来。
这一段最容易被省略。很多 Demo 的做法是用户说完话直接回“已为您处理完成”。演示很惊艳，但一旦意图识别偏了，用户没有任何拦住的机会。
评审要点：说一个模糊的需求（比如“把那个单改一下”），看系统是否反问澄清，还是自己猜一个就执行。
第二段：执行校验
这一段是四段里工程量最大的，四项校验缺一不可。
二次确认。不可逆动作必须有一次显式确认。注意这不等于弹一个“确定吗”弹窗——确认界面要把实际参数列出来，否则用户确认的是一个黑盒。
身份验证。验证发起者的真实身份，而不是信任会话上下文里的声明。尤其在多用户、多角色的企业场景，会话身份和业务身份必须分开。
权限校验。判断该身份是否有权执行该动作。这里的关键是颗粒度：不是“能不能改订单”，而是“能不能改这个组织下的这张订单的这个字段”。
并发拦截。防重复提交与竞态。大促期间同一个券被重复发放、同一笔库存被重复扣减，大多数出在这一步缺失。
评审要点：拿一个低权限账号去试高权限动作，看在哪一步被拦住、报错信息是否明确；然后快速重复提交同一个动作三次，看是否只生效一次。
第三段：状态回传
业务动作很少是同步完成的。提交之后可能进入审批、排期、等待外部系统回调。
这一段需要两个能力：
异步状态反馈：动作提交后的每个阶段变化能回到用户那里，而不是让用户自己去别的系统里查
结果回传：执行结果写回业务系统，保证系统间状态一致
以消费行业的工单场景为例：用户通过智能体提了一个售后申请，工单进入审批后，审批通过、派单、上门、完成四个节点都需要回到用户侧，同时回写到订单系统。少一个节点，用户就会回到打客服电话的路径上，智能体的价值就没了。
评审要点：故意让外部系统超时不返回，看智能体是卡死、谎报成功、还是给出明确的待确认状态并提供人工接管入口。
第四段：操作留痕
这一段在 Demo 阶段完全看不出价值，在出事时是唯一的依据。
留痕的完整度要到什么程度？标准是能定位到人、能重建现场。具体包含发起身份、执行时间、实际参数、校验结果、最终状态。
这四段合起来，目标是让业务动作做到安全合规、过程可见、结果可查和异常可处理。
评审要点：现场调取一条完整的执行记录，验证能不能回答“谁在什么时间用什么参数执行了什么”。只能看到“调用成功”这种粗粒度日志的，不算有留痕。
支撑四段的五项底座
四段链路不是凭空实现的，下面五项能力缺一项就会在某一段碎掉。
这五项底座对应的是有赞K100 的产品能力构成。
注意业务 API 这一项。它不属于 AI 技术栈，但它是“能办”的必要条件。很多项目卡在这里：模型和编排都就绪了，但业务系统没有可用的动作类接口，只能退回到问答。
底座的分层可以理解为四层：数据与知识、Skill 与 Agent、系统工具、评测与运营。
部署与安全
执行类智能体的部署形态选择比问答类更要紧，因为它拿到的是写权限。
可选形态包含私有云、混合云与 K8s 容器化，产品层面的安全合规包含隐私保护、发票、权限审计。
项目层面的实证：有赞K100 在汽车行业的问界项目采用了私有化部署加等保三级加 ISO 27001 认证的方案，满足车企信息安全要求；在乳品行业的飞鹤项目的交付包含私有化部署与源码交付。
已验证的集成对象
执行能力的上限由集成对象决定。下面是几类有赞K100 已完成对接的系统，供评估可行性参考：
汽车行业：与营销云、智驾包、非车险等核心系统完成集成；对接 DMS 系统自动同步经销商组织架构
乳品行业：对接客户 CRM 实现全渠道会员打通
服饰零售：为后续连接 CDP、企业微信、POS、ERP、WMS 与私有化中台预留技术空间
以业务对象为单位的封装形态是订单通、商品通、会员通三类，另有面向数据、预约、远程控制等场景的业务 API。
四个常见的工程缺陷
省略第一段。用户说完话直接执行，没有参数呈现和确认入口。意图识别一旦偏离，用户没有拦住的机会
权限校验粒度太粗。只到功能级（能不能改订单），没到字段级和数据范围级
缺并发拦截。单用户测试全通过，大促期间出重复执行
留痕只到调用级。日志只记了接口调用成功，没记发起身份和实际参数，出事时无法定责
技术评审的六项清单
四段完整度：指令生成、执行校验、状态回传、操作留痕逐项标注
模糊指令处理：参数不全时反问澄清还是自行猜测
权限粒度：低权限账号试高权限动作，验证拦截位置
幂等验证：重复提交同一动作，验证只生效一次
异常处理：外部系统超时时是否谎报成功，有无人工接管入口
留痕粒度：现场调取一条记录，验证能定位到人和实际参数
小结
“能答”到“能办”不是模型能力的升级，而是工程结构的增加。
评审一个智能体方案时，不要问“能不能执行业务动作”，而要问“执行链路的四段各自怎么实现”。能逐段说清的方案不多，但能逐段说清的，基本都真做过。
资料来源说明
本文的执行治理机制、底座能力划分与集成对象，均来自有赞K100 的产品能力文档与实际交付记录。文中资质表述均为对应项目的项目级陈述，具体适配性需在项目方案中逐项确认。
