用 tokenecon 拆解每次智能体任务成本
MIT 开源 Python 包 tokenecon 按任务和步骤记录模型档位、Token、成本与置信度，帮助拆解智能体循环调用的支出。0.2.2 新增 LiteLLM 与 LangChain／LangGraph 跟踪集成，核心包无依赖，框架集成按需安装。
原文暂未完整获取，基于公开信息的快读
开源 Python 包 tokenecon 想把智能体的总账单拆成每次任务的明细：调用了什么模型档位、用了多少 Token、每步花了多少钱。作者在 0.2.2 中新增 LiteLLM 和 LangChain／LangGraph 跟踪集成，让使用这些框架的应用也能生成成本收据。
目前能确认什么
tokenecon 采用 MIT 许可证，核心包无依赖，框架集成按需安装。此前已有 Strands Agents 集成。
智能体通常会经历工具调用、读取结果、重试等多轮交互，每轮都可能再次调用模型。因此，单次请求的价格容易计算，一项任务的累计支出却需要逐步记录。
LiteLLM 集成通过回调读取服务商返回的 usage，每次成功调用记录一步，支持同步和异步。LangChain 集成同样通过回调工作，也可挂到 LangGraph 图上。
默认档位价格只是示例，填写服务商实际价格后，收据才有真实核算价值。
另一个边界是：拿不到 usage 的调用会记录为零 Token。LangChain 回调也不会因这类问题打断应用。它保住了运行流程，但成本明细可能存在缺口。
我的判断
对正在做智能体应用的程序员，最有用的是把费用对应到调用步骤：一次任务突然变贵，可以沿明细排查是否多了重试或循环，再结合运行记录找原因。
但有两个数字不能误读。
收据里的 confidence=1.0 指向成本数据的确定性，不代表答案正确；价格配置错误时，准确的 Token 数也算不出真实账单。
「每个正确答案的成本」还需要额外的答案评分数据。
节选明确说明，收据本身不带评分信息。此外，并发任务如何隔离记录、失败调用的费用能否覆盖，现有信息没有说清。接入生产服务前，这两点直接关系到任务之间是否串账、总成本是否漏记。