执行型 Agent 与业务闭环

1. 执行型 Agent v2 的新增责任

本周将两个外部动作接入项目：为合格会员发券，以及写入允许的活动标签。目标不是证明“AI 会点按钮”，而是让模型根据业务目标提出动作，由确定性服务校验资格、权限和预算，再通过受控连接器完成并回查结果。

先保持清楚的分工：模型可以选择工具、解释方案或提出澄清，不能给自己授权；用户确认的是具体动作参数，不是一句笼统的“以后你看着办”；连接器必须区分未执行、已成功、已失败和结果未知。教学使用本地模拟服务，不接触真实会员或营销渠道。

2. 从建议到动作的完整状态机

一个可靠动作至少经过草案、预检、确认、提交和回查。失败时还可能进入明确失败、结果未知或补偿流程。不要只用一个 success: true/false 覆盖所有状态，否则网络超时时无法判断是否应该重试。

draft → validated → awaiting_confirmation → submitted
                                      ├→ committed → reconciled
                                      ├→ failed
                                      └→ unknown → query_status → reconciled / manual_review

confirmation expired / payload changed → return to preview
irreversible downstream effect → compensation plan, not "undo everything"

只有当服务端能够确认实际状态时，才可以向用户报告完成。“请求已发出”不等于“券已发到”；超时不等于没有执行；代码回滚也不等于撤销外部动作。

3. 工具契约：发券与打标签分别设计

标签也不是天然无风险。标签可能触发其他自动化流程、影响营销资格或暴露敏感判断。应使用明确白名单，避免让模型任意写入“高风险”“易投诉”等未经验证或不适当的人群标签。

4. 确认必须绑定具体参数

用户看到的预览应包含门店、人群数量、金额或动作内容、活动规则、预计最大成本和未覆盖条件。确认记录应绑定规范化参数摘要、身份、租户、有效期和版本。确认后改变金额、增加人群或替换活动，必须重新确认。

# 教学设计片段；生产环境还需真实身份、持久化及并发控制。
payload = {
    "tenant": trusted_context.tenant_id,
    "store": "A",
    "segment_ref": validated_segment_ref,
    "action": "issue_coupon",
    "amount_cents": 500,
    "policy_version": "campaign-1"
}
# 规范化序列化后计算摘要，将其绑定至服务端确认记录。
# 执行端读取确认记录，并重新检查权限、资格与预算。

摘要只证明参数是否变化，不负责身份验证，也不是保密手段。不能将模型输出的 confirmed=true 当成用户确认；下载包中的布尔参数仅模拟可信边界，不是可直接上线的鉴权实现。

5. 幂等、重试与结果未知

同一个逻辑动作因网络重试到达两次时，应返回同一结果而不是重复发券。幂等键要绑定租户和动作内容；同键不同内容应拒绝，而不是复用旧结果。多个不同动作还需要预算的原子检查，避免两个预览分别通过、同时执行后超预算。

请求超时后先查动作状态，再决定重试。若下游不支持幂等或状态查询，应限制动作规模，并设计人工对账。不要向用户承诺“恰好一次”，除非端到端链路确实具备相应保障；本地字典保存结果只在当前进程有效，服务重启后并不可靠。

补偿也需要业务定义。标签可能可以移除，但若它已触发另一活动，就不是简单删标签；券已核销通常不能通过数据库回滚收回。运行手册要写明可撤销、可补偿和不可逆三类结果，以及谁批准和执行补偿。

6. 用户反馈与授权升级

记录建议是否被采用，还要记录拒绝原因。可能是依据不足、预算不合适、时间不对、门店无执行资源，或建议本身已经在进行。单纯采集“满意/不满意”不足以改进系统。

建议同时观察四组指标：质量——建议是否满足业务规则；采用——合格建议中多少被接受；执行——确认动作中多少完成并核对；结果——在适当实验下是否影响业务目标。每组都要写分母，不能把“点了确认”的比例当作业务提升。

授权升级依据质量、风险和实际运行证据。先只读，再建议，再限定动作与人群，最后才考虑更多自动化范围。不是使用次数多了就自然获得更高权限。业务人员的拒绝和覆盖操作应保留理由，成为下一轮规则与评估样本。

7. 嵌入工作方式与案例分析

Agent 不一定需要一个独立聊天窗口。若运营已经在活动工作台中完成分群和执行，可以把带证据建议、参数预览和异常队列嵌入那里，减少复制粘贴。界面选择应基于用户任务，而不是技术演示偏好。

阅读 Klarna 客服案例。AI 支持常见服务问题并保留人工渠道，给 FDE 的启发是把意图识别、事实查询、受控动作和解决确认连成完整路径。对话结束只是界面事件，退款到账、问题解决或人工接手才是相应的业务状态。

演练一个退款请求超时：先按原操作键查询；已成功则返回原凭证，处理中则等待，无法确认则保留 unknown 并交接人工。禁止用新请求编号盲目重试。提交状态机、幂等测试和带上下文的交接单，并把重复咨询与返工计入成本。

8. 必做作业、思考与验收

必做：实现发券与标签两个连接器的本地模拟；完成预览、参数绑定、确认、幂等、预算重检、动作回查和审计；将其接入真实模型运行时并提交“执行、澄清、拒绝”不同任务轨迹；收集建议反馈并更新第 7 周评估集。

思考：用户说“这些人都发一下”，但当前会话里出现过两个不同的人群，你如何确定指代？如果确认后人群资格变化，执行时应使用快照、重检还是重新预览？说明你的选择与风险。

进阶：模拟一次“下游已执行但客户端超时”，实现状态查询与对账；模拟服务重启，说明内存幂等为什么不足，并提出持久化事务方案。

验收要求：动作前后状态可查；模型不能伪造确认；同键重复不增加副作用，同键不同内容被拒绝；跨店、过期、超预算测试通过；未知状态不被报告为成功；演示明确标注模拟边界。只有固定脚本调用接口的版本，不满足模型自主选择工具这一项要求。