如何计量每一个 Token：Multi-Agent-CAD token_tracker 监控系统的实现原理

如何计量每一个 TokenMulti-Agent-CAD token_tracker 监控系统的实现原理【免费下载链接】Multi-Agent-CADMAC (Multi-Agent CAD): A decoupled multi-agent framework for text-to-CAD generation via constrained test-time compute项目地址: https://gitcode.com/gh_mirrors/mu/Multi-Agent-CADMulti-Agent-CADMAC是一个通过多个 AI 智能体协作、把自然语言直接变成可打印 3D 模型的 CAD 生成框架。由于 Token 消耗是 LLM 项目的核心成本MAC 内置了一个轻量级的Token 监控系统——multi_agent_cad/token_tracker.py它能逐次捕获每一次 LLM API 调用、精确归属到具体工作流节点并区分输入、输出、缓存命中与推理 Token最终输出一份按模块分账的用量报表。为什么多智能体 CAD 项目需要 Token 计量CAD 生成是一个生成代码 → 执行 → 报错 → 修复 → 重新生成的多轮循环过程。传统单智能体方案会把完整对话历史每轮都塞回上下文Token 消耗随迭代次数指数级膨胀。MAC 的做法是让 4 个智能体之间只传递紧凑的结构化状态CADBrief、ArchitectPlan、QA 报告而不是原始对话。在 10 条提示词的基准测试中总 Token 从1.04 亿降到 89.6 万116 倍缩减成本从 ¥125.69 降到 ¥9.67。但省了 116 倍这个结论本身就来自token_tracker的精确计量——没有可靠的 Token 监控系统这类效率声明根本无法量化。可以说它既是成本监控器也是项目效率叙事的数据来源。双通道捕获不漏掉任何一次 LLM 调用MAC 的 LLM 调用来自两条不同的路径token_tracker在安装补丁时patch()方法见 multi_agent_cad/token_tracker.py 第 169 行起同时钩住它们通道 1补丁 OpenAI SDK 的Completions.createnodes.py 中有 4 处直接的 LLM 调用点。监控系统用猴子补丁monkey patch替换了openai.resources.chat.completions.Completions.create在原始调用返回后从响应中提取usage字段并记录。通道 2注册 litellm 的success_callback编码修复阶段使用的 Aider 框架走的是litellm.completion()其内部调用的是with_raw_response.create()——另一个SDK 方法通道 1 的补丁抓不到它。因此监控系统向litellm.success_callback追加了一个回调函数。该回调在响应完全组装后触发覆盖同步/异步/流式三种模式usage字段均已填充。 两条通道互为补充漏掉任何一条报表都会出现凭空消失的 Token。模块归属如何知道 Token 花在了哪个节点上这是整套系统最精巧的部分。捕获到一次调用后监控系统需要回答是哪个节点花的钱它的策略是就近原则——向上查找调用栈找到最近的node_*函数名作为归属模块_detect_module见 multi_agent_cad/token_tracker.py 第 274 行起。但这里有个大坑litellm 的成功回调是在asyncio 事件循环中触发的回调发生时同步调用方的栈帧已经消失了直接遍历调用栈只能得到unknown。MAC 的解法是 Python 的contextvars补丁会包装nodes模块中的每个node_*函数_wrap_node第 295 行起进入节点时把当前模块名写入一个 ContextVarContextVar 天然穿透 asyncio回调触发时直接读取即可知道我现在在哪个节点里另外还有一层细节litellm 的日志走全局线程池工作线程不继承调用方的上下文因此监控系统把那个线程池替换为 ContextVar 感知的子类让上下文能跨线程传播。最终每次调用都会被记录为一条包含时间戳、模块名、模型名、输入/输出/缓存/推理 Token 的结构化数据_record方法第 60 行起并以锁保护保证线程安全。计费细节正确处理思考型推理 Token不同厂商的 Token 统计口径并不一致监控系统对此做了专门处理见 multi_agent_cad/token_tracker.py 第 86-98 行标准 OpenAI 口径如 o1 系列reasoning_tokens是completion_tokens的子集直接取 completion 即可避免重复计数百炼 GLM 口径completion_tokens只计可见回答思考 Token 单独报告、不属于completion 的一部分因此实际计费输出 completion reasoning。系统用一个启发式规则自动区分两种口径reasoning completion 时按后者相加并把缓存命中的cached_tokens也纳入统计。这一步保证了报表数字与真实账单一致而不是一个看起来差不多的估计值。查看统计报表一行 reset 一行 print_summarytoken_tracker的使用方式极其简单整个工作流的生命周期由两个调用点闭环开始运行前清零graph.py 第 399 行调用_token_tracker.reset()确保每次运行独立计量graph_aider.py 第 282 行做了同样的事。运行结束后出报表graph.py 第 447 行调用_token_tracker.print_summary()。值得注意这一调用位于异常处理之外——即使工作流中途崩溃或被中断你也能看到已经消耗了多少 Token这对成本止损非常实用。报表输出大致如下终端表格形式TOKEN USAGE SUMMARY (multi-agent CAD workflow) Total API calls : 24 Total tokens : 184,320 input : 152,410 output : 28,750 cache_read : 3,160 module calls input output cache_r total --------------------------------------------------------------------------- node_spec_planner 3 48,210 3,120 0 51,330 node_geometric_architect 4 62,040 8,910 3,160 74,110 node_python_coder 8 42,160 16,720 0 58,880 --------------------------------------------------------------------------- TOTAL 24 152,410 28,750 3,160 184,320每个智能体节点花了多少钱、调了几次、输入输出各占多少一目了然。你还能据此发现哪个阶段是 Token 大户有针对性地优化 Prompt 或精简状态。Web 端同样接入了这套系统web_runner.py 在运行前调用reset()结束后把summary()[total_tokens]和 API 调用次数一并推送给前端展示第 125-137 行。相关文件速查文件作用multi_agent_cad/token_tracker.pyToken 监控系统核心双通道捕获、模块归属、汇总报表multi_agent_cad/graph.py主工作流入口调用reset()/print_summary()multi_agent_cad/graph_aider.pyAider 工作流入口同样接入计量multi_agent_cad/nodes.py4 个node_*智能体节点被自动包装以支持归属multi_agent_cad/web_runner.pyWeb 服务端把 Token 统计推送到前端小结token_tracker用不到 300 行代码解决了一个真实工程难题在 SDK 直连与第三方框架混用的多智能体流水线里精确计量每一次 LLM 调用的 Token 并归属到正确节点。它的三个设计点值得借鉴——双通道补丁确保捕获完整、ContextVar 穿透异步栈实现模块归属、厂商计费口径差异的启发式修正保证数字可信。对于任何认真跑 LLM 成本的项目这套import 即生效、零侵入业务代码的计量思路都可以直接拿来参考。【免费下载链接】Multi-Agent-CADMAC (Multi-Agent CAD): A decoupled multi-agent framework for text-to-CAD generation via constrained test-time compute项目地址: https://gitcode.com/gh_mirrors/mu/Multi-Agent-CAD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考