把决策拆开
把这个工作流视为几个独立阶段：- 选择： 找出可以完成任务的能力。
- 估算： 确认已公布的计价单位和整个工作流的预期成本。
- 授权： 把成本和能力类型与策略比对。
- 执行： 通过文档化的接口提交经批准的请求。
- 校验支付： 确认用量或结算记录。
- 校验交付： 确认 API 响应完整且可用。
- 审计： 记录决策、金额、资源和结果，且不含敏感信息。
执行前先定义策略
尽量把授权策略放在模型提示词之外，在应用代码或其他可信控制层中强制执行。
推荐工作流
1. 定义任务和成功条件
明确所需输出、可接受的质量、截止时间和最大支出。成功条件模糊会导致不必要的调用或重复采购。2. 选择足够用的最小能力
用按目标查找能力和按接口查找能力判断任务需要的是模型、直接 API、Skill 还是其他资源。 当某个更小的已文档化入口就能满足需求时，不要购买范围更广或更贵的能力。3. 查阅最新的计费和可用性信息
批准之前，确认：- 精确的模型、API 或能力标识。
- 当前的计价单位和认证要求。
- 可用性、速率限制和已知约束。
- 该流程使用的是常规 AIsa 余额扣减，还是另一种已文档化的支付机制。
4. 授权请求
把估算结果与策略比对。如需确认，应展示：- 该能力及其对应任务。
- 预期价格或最高授权金额。
- 资金来源或计费边界。
- 结果失败或不完整时的处理方式。
- 重试是否会再次产生费用。
5. 只执行一次并保留标识
通过文档中给出的确切 API 提交请求，保留系统返回的任何请求、用量、交易或关联标识。 只有当该能力明确支持幂等控制时才使用它。不要为没有文档说明的 endpoint 自行发明幂等键约定。6. 处理状态不明的结果
网络超时并不能证明请求在计费之前就已失败。
7. 审计但不暴露敏感信息
只记录审查所需的字段，例如：- 任务和策略决策。
- 能力标识。
- 授权金额，以及可获得时的实际金额。
- 请求或交易引用号。
- 结果状态和校验结论。
- 重试或降级决策。
什么时候适合自主采购
以下情况可以考虑：- 资源需求随任务变化。
- 偶尔使用，不值得为某个提供商单独开订阅。
- 工作流可以给出明确的支出上限。
- 应用能够同时校验计费和交付。
- 预算、确认、重试和审计控制可以被强制执行。