基于火山引擎方舟的多智能体调用归集与费用归因实践 - 文章 - 开发者社区

说明：本文以火山引擎方舟大模型（ARK）为底座，给出一套「调用打标 → 落库归集 → 多视角归因」的落地方法。示例代码为演示性质，接入时请替换为你的 ARK 推理接入点与密钥；文中口径说明仅用于解释逻辑，不涉及任何真实客户数据。

当团队把多个 Agent 陆续接入业务后，费用视角会从「这个月总共花了多少」变成「这些 Token 到底花在哪了」。尤其当同时跑着多个项目、养着好几个数字员工、又有不少同事在调用模型时，单看一张汇总账单已经不够用了。你可能会冒出这样的问题：

哪些项目产生了消耗？哪几个项目「用得多、产出少」？

某个数字员工一共用了多少 Token？有没有配好了却长期闲置计费的？

具体某个同事、某把 API Key 的调用情况如何？是不是有人在批量跑任务？

本文以火山引擎方舟为例，拆解如何把每一笔模型调用归属到具体的项目、智能体和用户，再围绕同一张归集表做下钻分析。核心思路不依赖特定平台：只要在调用侧把归属维度记下来，后面怎么看都行。

picture.image

一、先给每次调用打上归属标签

看费用的第一步不是盯数字，而是先把范围定清楚——而范围要能定清楚，前提是每次调用在数据层就带上了归属维度。

做法是在业务侧封装一层统一网关，所有 Agent 的调用都先经过它，由网关在请求方舟的同时，把 project / department / agent / user 这几个维度写进归集表。这样调用从一开始就不会混在一起。

import sqlite3
import requests
from datetime import datetime

ARK_ENDPOINT = "https://ark.cn-beijing.volces.com/api/v3/chat/completions"
ARK_API_KEY = os.getenv("ARK_API_KEY")
MODEL_ID = "doubao-seed-1.6-250615"  # 示例模型 ID，请替换为你的方舟推理接入点

def _record(project, department, agent, user, prompt_tokens, completion_tokens, model):
    """把一次调用的归属维度与用量落库，供后续多视角分析。"""
    conn = sqlite3.connect("cost_ledger.db")
    conn.execute(
        """INSERT INTO cost_ledger
           (project, department, agent, user, prompt_tokens, completion_tokens, model, created_at)
           VALUES (?,?,?,?,?,?,?,?)""",
        (project, department, agent, user, prompt_tokens, completion_tokens, model,
         datetime.now().isoformat()),
    )
    conn.commit()
    conn.close()

def call_ark(messages, *, project, department, agent, user):
    """统一网关：调用方舟并记录归属与用量。"""
    resp = requests.post(
        ARK_ENDPOINT,
        headers={"Authorization": f"Bearer {ARK_API_KEY}", "Content-Type": "application/json"},
        json={"model": MODEL_ID, "messages": messages},
        timeout=30,
    )
    resp.raise_for_status()
    data = resp.json()
    usage = data["usage"]
    _record(
        project=project, department=department, agent=agent, user=user,
        prompt_tokens=usage["prompt_tokens"],
        completion_tokens=usage["completion_tokens"],
        model=MODEL_ID,
    )
    return data["choices"][0]["message"]["content"]

范围怎么定，全靠这张表里记录的维度。后续无论是「研发部这周」还是「某把 Key 今天」，都是对它的筛选，而不是重新改造调用链。

二、从总量看整体：金额、Token 与请求次数

方舟的计费按 input / output token 分别计价（豆包系列不同模型单价不同），所以核对时要同时看「金额」和「Token 用量」，二者不能只看其一。

归集表里先把原始 Token 记下来，金额按各模型单价在查询时折算即可：

  COUNT(*)                                   AS request_count,   -- 计费请求次数
  SUM(prompt_tokens)                         AS total_input,     -- 输入 Token
  SUM(completion_tokens)                     AS total_output,    -- 输出 Token
  COUNT(DISTINCT project)                    AS active_projects, -- 活跃项目数
  COUNT(DISTINCT agent)                      AS active_agents    -- 活跃智能体数
FROM cost_ledger
WHERE department = 'customer-success'
  AND created_at >= '2026-09-01'
  AND created_at <  '2026-10-01';

几个数字合在一起能帮你建立整体印象：

请求次数——是调用频繁，还是少数几次大请求拉高了费用；

活跃项目 / 智能体数——有多少在真正用，是不是比预期多；

输入 / 输出 Token——同样是 1 万 Token，输入和输出的单价往往不同，不同模型计价口径也不一样。只比金额容易误判，要结合 Token 用量一起看。

三、按项目、智能体、用户下钻

同一笔总量，光看总数看不出问题，要换不同的「管理视角」拆开来看。归集表天然支持三种 GROUP BY，正好对应三种日常管理角色。

按项目（判断费用在项目间怎么分布）：

       COUNT(*)                AS requests,
       SUM(prompt_tokens)      AS input_tokens,
       SUM(completion_tokens)  AS output_tokens
FROM cost_ledger
GROUP BY project
ORDER BY (prompt_tokens + completion_tokens) DESC;

按智能体（哪些在真干活，哪些长期闲置）：

       COUNT(*)                AS requests,
       SUM(prompt_tokens + completion_tokens) AS total_tokens
FROM cost_ledger
GROUP BY agent
ORDER BY total_tokens DESC;

按用户（人员使用核对，某把 Key 是否被高频调用）：

       department,
       COUNT(DISTINCT agent)   AS agents_used,
       SUM(prompt_tokens + completion_tokens) AS total_tokens
FROM cost_ledger
GROUP BY user
ORDER BY total_tokens DESC;

picture.image

⚠️ 关键提醒：这三个视角是同一张表、同一笔总量的三个切片，分别理解即可，不能把三栏的汇总金额直接相加——相加会重复计算。要核对总额，始终以第二节的总量查询为准。

四、峰值分析：定位异常时段

当费用出现明显波动，与其从上百条明细里一条条翻，不如先看时间维度的峰值。

  strftime('%Y-%m-%d %H', created_at) AS hour_bucket,
  SUM(prompt_tokens + completion_tokens) AS total_tokens
FROM cost_ledger
GROUP BY hour_bucket
ORDER BY total_tokens DESC
LIMIT 5;

峰值的作用不是直接告诉你「哪里有问题」，而是帮你快速圈定重点排查的部门和时间段。比如你发现某周三下午某几个小时消耗特别高，就可以回到明细里专门核对那段时间发生了什么——是不是做了批量数据处理、是不是集中跑了一轮模型测试、是不是某个新接入的应用刚上线。峰值给的是排查「方向」，合不合理最终要结合实际业务判断。

五、一个完整的月度核对流程

把上面的能力串起来，一次典型的月度费用核对可以是这样：

定范围：筛 department + 本月，先看总请求数与总 Token，确认整体趋势；

看结构：拆输入 / 输出 Token，判断费用构成是否合理；

下钻项目：GROUP BY project，找出消耗最高的几个，标记待确认项；

查智能体：GROUP BY agent，看有没有闲置或异常高耗的个体；

核对人员：GROUP BY user，确认高用量 Key 与报备业务是否一致；

追峰值：结合小时级聚合，对异常时段做业务回溯。

走完这一圈，你对「钱花在哪」就不再是一笔糊涂账，而是能拿着具体数据，去和项目方、部门负责人做有针对性的沟通。

六、几个容易踩的坑

把三个视角的金额相加：项目、智能体、用户是同一总量不同切片，相加会重复计算，总额永远看总量查询。

只看金额不看 Token：金额受模型单价影响大，只看金额容易误判。结合 Token 用量，才能分清是「用得多」还是「单价贵」。

范围没选对就下结论：全公司和单部门的数字天差地别，排查前一定先定好部门和时间。

峰值高就认定有问题：峰值只是线索，要结合业务场景判断，避免误伤正常的大批量任务。

多智能体系统接入火山引擎方舟后，费用治理的本质不是「换一个看账单的地方」，而是在调用侧就把归属维度记下来，再用一张表做任意维度的下钻。企业可以先从一个边界清楚的项目开始：封装统一网关、观察用量和费用、再决定下一步怎么调。随着真实记录慢慢积累，再逐步扩大管理范围——这正是把 AI 使用纳入团队管理的务实起点。