> ## Documentation Index
> Fetch the complete documentation index at: https://aisa.one/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 设计自主 API 采购工作流

> 规划 AI agent 如何在没有无上限支出和重复扣费的前提下，选择、授权、购买、校验和审计受支持的付费 API 能力。

自主 API 采购工作流让 agent 可以在明确的预算和授权规则下，于运行时申请受支持的付费能力。agent 可以选择某个资源，但仅仅"选中"并不等于获得支出许可。

AIsa 对模型和 API 消耗采用按量计费。有些工作流会使用预先充值的 AIsa 余额，也有些已文档化的能力可能支持另一种程序化支付流程。不要假设所有 API 都使用相同的支付协议或结算方式。

## 把决策拆开

把这个工作流视为几个独立阶段：

1. **选择：** 找出可以完成任务的能力。
2. **估算：** 确认已公布的计价单位和整个工作流的预期成本。
3. **授权：** 把成本和能力类型与策略比对。
4. **执行：** 通过文档化的接口提交经批准的请求。
5. **校验支付：** 确认用量或结算记录。
6. **校验交付：** 确认 API 响应完整且可用。
7. **审计：** 记录决策、金额、资源和结果，且不含敏感信息。

支付成功并不能证明所请求的资源已成功交付。两者必须分别校验。

## 执行前先定义策略

| 控制项    | 策略问题示例                  |
| ------ | ----------------------- |
| 允许的能力  | agent 可以购买哪些模型或 API 家族？ |
| 单次请求上限 | 一次操作的最高成本是多少？           |
| 单任务上限  | 整个工作流所有步骤的总成本上限是多少？     |
| 时间维度上限 | 每日或每月的上限是多少？            |
| 确认阈值   | 哪些金额或能力类型需要人工批准？        |
| 重试策略   | 在哪些状态下可以安全重试请求？         |
| 降级策略   | agent 是否可以选择更便宜或替代的能力？  |
| 审计策略   | 保留哪些请求、决策、成本和结果字段？      |

尽量把授权策略放在模型提示词之外，在应用代码或其他可信控制层中强制执行。

## 推荐工作流

### 1. 定义任务和成功条件

明确所需输出、可接受的质量、截止时间和最大支出。成功条件模糊会导致不必要的调用或重复采购。

### 2. 选择足够用的最小能力

用[按目标查找能力](/docs/zh/by-goal)和[按接口查找能力](/docs/zh/by-interface)判断任务需要的是模型、直接 API、Skill 还是其他资源。

当某个更小的已文档化入口就能满足需求时，不要购买范围更广或更贵的能力。

### 3. 查阅最新的计费和可用性信息

批准之前，确认：

* 精确的模型、API 或能力标识。
* 当前的计价单位和认证要求。
* 可用性、速率限制和已知约束。
* 该流程使用的是常规 AIsa 余额扣减，还是另一种已文档化的支付机制。

请使用最新文档和实时响应，不要依赖缓存的固定价格。

### 4. 授权请求

把估算结果与策略比对。如需确认，应展示：

* 该能力及其对应任务。
* 预期价格或最高授权金额。
* 资金来源或计费边界。
* 结果失败或不完整时的处理方式。
* 重试是否会再次产生费用。

### 5. 只执行一次并保留标识

通过文档中给出的确切 API 提交请求，保留系统返回的任何请求、用量、交易或关联标识。

只有当该能力明确支持幂等控制时才使用它。不要为没有文档说明的 endpoint 自行发明幂等键约定。

### 6. 处理状态不明的结果

| 观察到的状态          | 稳妥的处理方式            |
| --------------- | ------------------ |
| 请求在被接受前就被拒绝     | 修正请求或选择其他能力        |
| 既无确认扣费也无结果      | 先查询状态，再考虑是否重试      |
| 存在扣费或用量记录，但没有结果 | 进行对账或联系支持；不要盲目重新购买 |
| 有结果，但结算状态不确定    | 保留结果，另行核对财务记录      |
| 支付和结果都已校验       | 标记采购完成并记录结果        |

网络超时并不能证明请求在计费之前就已失败。

### 7. 审计但不暴露敏感信息

只记录审查所需的字段，例如：

* 任务和策略决策。
* 能力标识。
* 授权金额，以及可获得时的实际金额。
* 请求或交易引用号。
* 结果状态和校验结论。
* 重试或降级决策。

绝不要在审计记录中存储 API 密钥、钱包密钥、签名或 bearer token。

## 什么时候适合自主采购

以下情况可以考虑：

* 资源需求随任务变化。
* 偶尔使用，不值得为某个提供商单独开订阅。
* 工作流可以给出明确的支出上限。
* 应用能够同时校验计费和交付。
* 预算、确认、重试和审计控制可以被强制执行。

## 什么时候更简单的计费方式更合适

如果用量可预测、采购决策不需要在运行时做出，或者应用无法安全处理状态不明的支付情形，那么使用常规账户充值加由应用控制的 API 调用会更好。

## 相关内容

* [面向 AI Agent 的机器支付](/docs/zh/concepts/machine-payments-for-agents)
* [AIsa 钱包与支付](/docs/zh/guides/pricing/wallet)
* [价格评估指南](/docs/zh/evaluate/pricing)
* [安全评估指南](/docs/zh/evaluate/security)
* [认证](/docs/zh/guides/authentication)