---
title: "成本管理"
description: "控制 Ankole 花费的杠杆——模型档案、reasoning effort、Web 工具、回合预算、Workflow fanout 和后台任务上限。"
url: "https://ankole.agentbull.com/zh-Hans-CN/docs/cost-management/"
lang: "zh-Hans-CN"
---

> 面向 AI Agent 的文档索引：https://ankole.agentbull.com/zh-Hans-CN/llms.txt

# 成本管理

Ankole 花的大部分是模型 token，而其中大部分由一小撮配置杠杆决定，不是你无法塑造的用量。本页命名这些杠杆，说明各自的花费与节省，并给出账单太高时拉它们的顺序。这里的每一样都是控制面里真实的旋钮；没有一条是"少用 agent"。

先说明最关键的一点：成本取决于*哪个模型运行、运行多少次、每次运行多久*。模型档案决定使用哪个模型，Agent 循环预算限制迭代次数，Workflow 和后台任务上限则约束 fanout 与重试。应调整与实际花费来源对应的那一项。

## 杠杆 1：model profile 档位

八个内置 Agent profile 分别控制不同的付费路径。五个选择语言模型，三个绑定网页搜索、网页抓取和图像生成能力。

| 槽 | 何时跑 | 成本杠杆 |
|---|---|---|
| `primary` | 主推理模型——大多数回合 | 最大的一项成本 |
| `light` | 高频低风险路径 | 应当真正廉价 |
| `heavy` | 硬综合 | 昂贵；`primary` 调好时很少用到 |
| 后台 Agent 任务（内部键为 `coding`） | 每个后台 Agent 任务 | 决定持久后台任务使用哪个 Provider 和模型 |
| `vision_fallback` | `primary` 处理不了图像时 | 仅在 agent 看图像时绑定 |
| `web_search`、`web_fetch` | web 工具 | 见杠杆 3 |
| `image_generate` | 图像生成 | 按次昂贵；仅在用时绑定 |

Brain 只保留 embedding 和 rerank 两项实例级模型设置。在 [AppConfigure](https://ankole.agentbull.com/zh-Hans-CN/docs/app-configuration/index.md) 中选择负责维护 Brain 的活跃 Agent：Brain 的所有模型调用都以该 Agent 的身份执行，并把用量归到该 Agent。该 Agent 的 `light` profile 用于从对话和 Source 中抽取知识，`heavy` profile 用于 Dreaming 和技能教训复审，`web_fetch` profile 用于读取 URL Source。未配置 `web_fetch` 或 Provider 请求失败时，系统改用本地 `ankole-browser`。停用维护 Agent 后，模型调用和本地网页抓取都会停止，直到重新启用或更换 Agent。**Brain → 健康**会显示所选 Agent 和各 profile 的状态。完整行为见 [Brain](https://ankole.agentbull.com/zh-Hans-CN/docs/brain/index.md)。

两招最省：

- **把 `light` 绑到真正廉价的东西。** 它为高频路径而存在；一个几乎和 `primary` 一样贵的 `light` 让这个槽失去意义。
- **默认把 `primary` 调低、不调高。** 一个“感觉贵”的 agent，往往是在 `primary` 上绑得比实际工作所需更重。质量需要时才上调。

Agent 用不到 `vision_fallback` 时，可以把它留空，避免产生相应调用。`image_generate` 留空时，若主 Provider 声明支持原生图像生成，请求仍可走原生路径。后台 Agent 任务不同：即使不单独配置，任务仍会回退到该 Agent 的 `heavy` 档案并通过 AIGateway 运行。只有后台任务需要不同 Provider 或模型时，才需要单独配置。

## 杠杆 2：reasoning effort

对支持 Codex reasoning effort 的 Provider，`model_reasoning_effort` 是七个档位的旋钮：`minimal | low | medium | high | xhigh | max | ultra`。更低 effort 更廉价更快；更高 effort 在难题上更好、花费更多。默认 `high`。

这是比换模型更细的杠杆。一个在 `medium` 就够、却配成 `high` 的 `primary` agent，多花钱却无可见收益。在 `primary` profile 上设它，匹配 agent 的实际工作；只给那个做硬综合的 agent 上调，不是给所有 agent。

## 杠杆 3：web 工具，按需

`web_search` 和 `web_fetch` 是独立的 profile，每次调用都花钱。两招：

- **agent 不需要联网时解绑它们。** 一个纯内部助手不该绑 `web_search`；这个槽存在就是一张调用的许可。
- **知道 URL 时优先 `web_fetch` 而非 `web_search`。** 抓已知来源是一次调用；搜索是一次调用加 agent 决定做的若干次抓取。

`worker.rendered_fetch_idle_ttl_ms` AppConfigure 键控制渲染后的抓取结果缓存多久——更高的 TTL 节省同一 URL 的重复抓取，代价是陈旧。

## 杠杆 4：agent 循环预算

三个 AppConfigure 键限制每回合花费：

| 键 | 限制什么 |
|---|---|
| `ai_agent.max_iterations` | agent 循环每回合的迭代预算 |
| `ai_agent.max_output_tokens` | 每回合输出 token 上限 |
| `ai_agent.inactivity_timeout_ms` | 回合多久无活动后会被回收 |

`max_iterations` 限制单个 Agent 回合的模型迭代次数，避免本可用两次工具调用完成的任务反复调用模型。`max_output_tokens` 限制单次响应大小。两项都是实例级默认值，应按常见回合设置；复杂回合达到上限时，Agent 会基于已有内容给出最终回答。

## 杠杆 5：Workflow fanout 与任务尝试

Workflow 中每次 `agent()` 尝试都是一个完整模型回合。一次调用最多进行三次尝试，因此即使主会话只发起一次 Workflow，大量子 Agent 调用仍会放大模型与 Web 工具用量。

| AppConfigure 键 | 默认值 | 最大值 | 控制内容 |
|---|---:|---:|---|
| `workflow.max_concurrency_per_run` | 8 | 32 | 单次运行可以同时执行的任务数 |
| `workflow.max_running_per_agent` | 8 | 64 | 单个 Agent 的所有 Workflow 中正在运行的任务总数 |
| `workflow.max_agent_calls_per_run` | 256 | 1,024 | 单次运行可以创建的子 Agent 调用总数 |

并发数只改变完成时间，不会减少模型调用总数。应根据有限输入设置调用上限，并且只申请实例确实需要的并发数。单次运行可以申请更低的 `concurrency` 和 `max_agent_calls`，但不能修改跨运行的 `max_running_per_agent`，也不能抬高任何 AppConfigure 上限。

Workflow 没有覆盖整批任务的 token 或金额预算。每个任务仍受普通回合的迭代次数、输出 token 和无活动超时限制。应让每个任务使用窄提示和精简的结构化结果，显式处理 `null` 失败；单次汇总过大时，把集合拆成多个运行。任务与结果边界见 [Workflow](https://ankole.agentbull.com/zh-Hans-CN/docs/workflows/index.md)。

## 杠杆 6：后台任务重试与槽位上限

后台任务能在重试上花 token，上限就是杠杆：

| 上限 | 值 | 效果 |
|---|---|---|
| `max_execution_attempts` | 5 | 任务在 `failed` 前最多重试五次 |
| `max_consecutive_turn_failures` | 5 | 连续回合失败后任务放弃 |
| `max_running_per_agent` | 3 | 每个 agent 最多三个运行中任务 |
| 重试延迟 | ~30 秒 | 重试之间的下限 |
| `agent_computer.background_agent_job.max_turns_per_worker` | 可配置 | 每个任务的 worker 回合上限 |

一个任务临时失败五次，就花五次运行的 token。多数时候上限保护你——配置错误快速失败并保持失败。要盯的是第三个：一个有三个并发任务的 agent 在同时跑三个模型循环。若不需要这种并行，用“一次只做一件事”这样的人设，花费会比上限允许的更低。

## 杠杆 7：按 Agent 的 token 额度

前六个杠杆决定一个回合花多少。token 额度封顶总量：它限制一个 Agent 在一个循环周期内可以消耗的 token，用量达到上限后，AIGateway 会拒绝该 Agent 的模型调用，直到周期结束。

在 Agent 页面设置：周期天数、周期起始时间和 token 上限。Agent 页面显示已用占比和当前周期的结束时间。在上限时到达的聊天消息会收到一条说明已用 token、上限和周期结束时间的回复。在上限时的后台 Agent 任务直接失败，不会等待。合理的用量高峰必须继续时，**重置周期**会立即开始一个新周期。

把额度当作止损，而不是预算规划器。它不会在接近上限时让 Agent 放慢，一次调用也可能因自身用量而超出上限。按下面观察到的花费来定大小，并给最重的正常一周留出余量。字段说明见 [Agent](https://ankole.agentbull.com/zh-Hans-CN/docs/agents/index.md)。

## 花费到底在哪

调整模型或并发之前，先找到产生调用的 Agent、会话、Workflow 或后台任务：

- `GET /ai-gateway/conversations` 显示近期回合做过的模型调用——哪些 profile 解析了、多少次调用、哪些 provider。这是看花费是在 `primary`（量）、`heavy`（少数昂贵调用）、还是 `web_search`（许多小调用）的最快途径。
- 让主 Agent 查看 Workflow。任务计数可以说明 fanout 和失败调用；当前版本没有 Workflow Console 页面，也不提供单次运行的费用汇总。
- `GET /background-agent-jobs` 显示任务 `attempts`——一个 `attempts: 5` 的任务花了五次运行。
- 结构化控制面日志带着 provider 调用的事件名和字段；你的日志摄入器可按 provider 和 agent 聚合。

修复从不是"少用 agent"，而是"这个具体杠杆对这个 agent 的工作设错了"。

## 一个完整示例

一个实例的账单在一周内翻倍。会话界面显示 `primary` 调用量正常，但 `web_search` 调用增长了十倍：一个使用 `may_intervene` 的团队助理开始为每条频道消息执行搜索。应当修改 Agent 的角色要求，例如“只在有人询问事实时搜索”，而不是调整全局成本限制。账单只反映问题，是否搜索仍由 Agent 的角色要求决定。

这是模式：成本问题常常是伪装的行为问题，行为杠杆是人设或 binding 策略，不是 token 上限。

## 成本管理不是什么

它不是实时花费仪表盘——Ankole 不提供。它不是把花费限制在某个美元金额的方式；杠杆限制*调用与迭代*，美元金额是 provider 费率乘以它们。它也不是读会话界面的替代；杠杆只有在你知道哪个设错之后才值得拉。

## 下一步

- Agent 的模型档案，读 [Agent](https://ankole.agentbull.com/zh-Hans-CN/docs/agents/index.md#配置模型)。
- agent 循环旋钮及其键，读 [环境变量](https://ankole.agentbull.com/zh-Hans-CN/docs/environment-variables/index.md)。
- 相关会话与后台任务接口，读 [Console API 参考](https://ankole.agentbull.com/zh-Hans-CN/docs/console-api/index.md)。
- 有界子 Agent fanout 及其限制，读 [Workflow](https://ankole.agentbull.com/zh-Hans-CN/docs/workflows/index.md)。
- 任务上限，读 [后台 Agent 任务](https://ankole.agentbull.com/zh-Hans-CN/docs/background-jobs/index.md)。