成本管理

面向 AI Agent：本页的 Markdown 版本位于 https://ankole.agentbull.com/zh-Hans-CN/docs/cost-management/index.md，文档索引位于 https://ankole.agentbull.com/zh-Hans-CN/llms.txt。

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

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

杠杆 1：model profile 档位

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

Brain 只保留 embedding 和 rerank 两项实例级模型设置。在 AppConfigure 中选择负责维护 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。

两招最省：

• 把 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 键限制每回合花费：

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

杠杆 5：Workflow fanout 与任务尝试

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

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

Workflow 没有覆盖整批任务的 token 或金额预算。每个任务仍受普通回合的迭代次数、输出 token 和无活动超时限制。应让每个任务使用窄提示和精简的结构化结果，显式处理 null 失败；单次汇总过大时，把集合拆成多个运行。任务与结果边界见 Workflow。

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

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

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

杠杆 7：按 Agent 的 token 额度

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

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

把额度当作止损，而不是预算规划器。它不会在接近上限时让 Agent 放慢，一次调用也可能因自身用量而超出上限。按下面观察到的花费来定大小，并给最重的正常一周留出余量。字段说明见 Agent。

花费到底在哪

调整模型或并发之前，先找到产生调用的 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。
• agent 循环旋钮及其键，读 环境变量。
• 相关会话与后台任务接口，读 Console API 参考。
• 有界子 Agent fanout 及其限制，读 Workflow。
• 任务上限，读 后台 Agent 任务。