Agent 最危险的时刻，不是它没有答案，而是它把一句听起来合理的话直接变成了不可逆的动作。退款、发信、改价和删除数据都不该由一段自由文本决定。更稳妥的做法，是让模型只负责评估候选动作并返回概率，再由业务代码根据权限、金额、证据和阈值决定是否执行。
本文用 TypeDecide 当前的订单售后示例，完整拆解一次 Agent 动作决策：输入哪些 State，如何设计 Choice 与 Noul 问题，怎样读取概率，以及为什么“模型推荐”必须与“系统执行”保持分离。你可以先打开 Jev Playground，对照本文检查请求结构。
目录
为什么 Agent 动作不该直接交给自由文本
自由文本适合解释，不适合承担动作协议。假设你问模型“这个售后问题该怎么办”，它可能回答“建议先核验证据，必要时退款”。人能理解这句话，但程序仍然不知道应该调用哪个工具、参数是什么、能否自动执行，也无法稳定比较不同版本的输出。
动作决策需要的是一个封闭集合。例如：
inspect_evidence：检查客户上传的照片或视频；issue_refund：进入退款流程；ask_customer：向客户补充询问信息。
模型的职责是判断哪个候选项更符合当前 State，并保留其他选项的概率。业务系统的职责则是验证权限、金额上限、证据完整性和幂等性。两者之间不是一句自然语言，而是一份可以校验、记录和回放的结构化结果。
这层分离带来三个直接好处。第一，动作 ID 稳定，工具调用不依赖模型措辞。第二，概率分布保留了不确定性，系统可以在两个动作接近时转人工。第三，每次决定都能记录“输入、候选项、模型版本、概率和最终执行结果”，方便事后审计。
需要特别强调：概率不是事实，也不是合规结论。它只表达模型在当前候选集合中的偏好强度。即使某个动作概率很高，业务规则仍然可以拒绝执行。
三层配置：State、问题和执行策略
一个可维护的 Agent 动作决策至少分成三层。把这三层混在一个 Prompt 里，短期看起来省事，后续却很难定位问题究竟来自输入、问题设计还是执行规则。
第一层：State 只描述当前事实
State 应包含完成判断所需的最小事实集合。订单售后场景可以提供订单状态、问题类型和已有证据：
{
"order_status": "delivered",
"issue": "missing_item",
"evidence": ["unboxing_photo"]
}
不要在 State 里提前写入“应该退款”这类结论，也不要提交密码、密钥、完整银行卡号或未经授权的个人信息。如果一个字段不会改变候选动作的判断，就不应为了“上下文更丰富”而默认加入。
第二层：问题完整表达判断目标
问题 ID 只用于程序关联响应，真正的语义必须写在 instructions 中。next_action 可以使用 Choice，让模型从明确候选项中选择下一步；escalate 可以使用 Noul，返回是否需要专员介入的概率。
Choice 候选项的说明同样重要。issue_refund 不能只写“退款”，还应说明它代表“证据和业务规则允许立即进入退款流程”。当候选项定义彼此重叠时，模型即使理解业务，也无法给出稳定分布。
第三层：执行策略留在业务代码
执行阈值、权限检查、金额上限、重试和幂等键都属于业务系统。模型不应该自行决定“概率高于 0.8 就退款”，因为相同概率在不同风险、金额和客户等级下代表不同处置方式。
推荐的边界是：模型返回候选动作和概率；策略层读取结果并组合确定性规则；工具层只接受已通过校验的命令。这样即使更换模型，权限和资金安全边界也不会一起迁移。
一个可运行的订单售后示例
在 TypeDecide Playground 中载入“Agent 动作”模板，可以看到 State、两个问题和请求预览同时出现。你可以先用本地 Mock 检查字段形态、问题 ID 和候选项是否清晰；只有登录并主动选择“真实运行”时，才会把请求发送给后台和当前启用的第三方 Provider。
核心 Choice 问题可以写成下面这样：
{
"next_action": {
"type": "choice",
"instructions": "What should the support agent do next?",
"criteria": {
"inspect_evidence": "Review uploaded evidence",
"issue_refund": "Refund immediately",
"ask_customer": "Request more information"
}
}
}
这个请求做对了两件事：动作集合是封闭的，动作说明也能独立表达含义。不过生产配置还应进一步补充业务限制。例如“立即退款”是否只适用于低金额订单，上传照片是否必须通过文件安全扫描，以及订单已经退款时应该返回哪个动作。模型看不到的规则，必须由策略层兜底。
拿到结果后，不要只读取获选项。假设 inspect_evidence 为 0.52，ask_customer 为 0.43，虽然前者排名第一，但两个动作非常接近。直接执行会隐藏这种不确定性；更合理的策略可能是暂停自动化、补充一个证据完整性问题，或者交给人工选择。
这也是结构化决策与普通分类接口的重要区别：最终选项便于路由，完整分布则帮助系统判断这次路由是否值得信任。
从概率到动作：阈值与人工复核
阈值不应该是全局常量，而应与动作风险绑定。读取数据、创建草稿和真实退款的失败成本不同，所需的置信门槛也不应相同。
可以从下面的策略开始，再用真实业务数据校准：
- 低风险、可撤销动作：例如给工单添加内部标签，可以允许较低阈值，但仍记录原因与结果。
- 中风险外部动作：例如向客户发送消息，需要模板校验、频率限制和敏感内容检查。
- 高风险或不可逆动作：例如退款、删除和权限变更，默认要求更高阈值，并组合金额、角色和人工审批。
- 概率接近或信息不足：不要强行二选一。补充信息或转人工本身也应该是合法动作。
对于高风险动作，建议同时检查获选项概率、第一与第二候选项的差值，以及单独的 escalate 概率。单一阈值无法覆盖所有不确定性。如果输入缺字段，系统应先拒绝执行，而不是期待模型从上下文猜测。
还要把“模型版本”和“配置版本”写入审计记录。概率变化可能来自模型升级，也可能来自候选项说明调整。没有版本信息，就无法解释同一订单为什么在两次运行中得到不同结果。
上线前最常见的四个错误
错误一：把动作 ID 当成完整 Prompt
issue_refund 对程序足够，对模型不够。instructions 和 criteria 都应使用完整、无歧义的描述。ID 保持稳定，说明负责表达语义。
错误二：候选动作互相重叠
“检查证据”和“向客户询问”可能同时合理。需要明确什么情况下证据已存在、什么情况下必须补充材料，否则概率分布会反映定义冲突，而不是业务不确定性。
错误三：只存最终动作，不存完整结果
只记录 inspect_evidence 会丢失决策上下文。至少保存输入摘要、问题版本、候选概率、模型版本、耗时、策略判断和最终工具结果，并对敏感字段进行脱敏。
错误四：把 Mock 结果当成真实能力
TypeDecide Playground 会明确区分“本地 Mock”和“真实 Provider”结果。本地 Mock 验证交互和请求结构；真实运行用于受控联调，但同样不证明模型准确率已经满足业务要求。进入生产前仍需要在目标数据上建立离线评测集，并通过影子流量或人工复核观察真实错误。
如果你还没有确定问题类型，可以先阅读 Jev 与结构化决策介绍；需要核对请求字段时，再查看 接入文档 和 Agent 动作示例。
FAQ
Agent 动作决策和 Function Calling 有什么区别？
Function Calling 解决的是模型如何生成符合工具参数结构的调用；动作决策解决的是在多个候选动作之间如何评估、保留概率并应用业务阈值。两者可以组合：先完成结构化动作决策，再由确定性代码构造并验证工具调用。
概率最高的动作可以直接执行吗？
不能仅凭“最高”执行。还要检查绝对概率、候选差值、动作风险、输入完整性、权限和业务规则。高风险动作通常还需要人工审批或额外验证。
应该把多少业务信息放进 State？
只放会改变判断的必要事实，并为字段建立允许列表。过多上下文会增加成本、泄露风险和噪声；过少则会迫使模型猜测。可以从失败案例反推缺失字段，而不是一次提交整份客户档案。
模型返回了列表外的动作怎么办？
把它视为无效响应并拒绝执行。结构化校验必须发生在工具调用之前，同时记录错误以便检查模型版本、Schema 和候选项配置。
下一步
先在 在线 Playground 中载入 Agent 动作模板，尝试修改订单状态、证据和候选项说明，观察请求预览如何变化。真正接入时，从低风险、可撤销的动作开始，建立审计记录和人工复核路径，再逐步扩大自动化范围。
结构化决策的价值不是让 Agent 更大胆，而是让每一步更可见、更可控，也更容易在出错时停止。