AgenticOS 如何按任务追踪 Agent 运行成本

大多数团队要到月底收到供应商账单时，才知道 Agent 花了多少钱，而且无法把某个数字对应到产生它的任务上。AgenticOS 在 Activity 视图中把一次运行的模型、Token 用量、报告成本和工具事件放在一起，让成本数字和具体任务建立联系。本文基于一份已有的演示记录，说明如何读取这些字段，以及如何用它们测试 Agent、设定预算。

需要说明的是，文中金额来自既有的演示截图，不是供应商发票、当前价格建议，也不代表某种典型工作负载的基准。

打开一次运行记录

演示记录显示 Support Copilot 通过 Slack 回答"如何轮换供应商密钥？"。它标注了 OpenRouter 和 anthropic/claude-opus-4.5，输入 Token 5,397，输出 Token 170，报告成本 $0.0312，时间线中还有一次已完成的 search_documents 调用。

这几个字段要合在一起读。只有金额没有任务，无法判断这次运行是否有用；只有 Token 数没有解析后的模型，不足以解释定价；状态显示成功只说明运行完成，源段落和答案的质量仍需人工检查。

这张界面的作用是告诉你该看哪里，并不能推断换个文档问题要花多少钱，也不能说明换模型能省多少。要做这类比较，需要用固定的任务和输入自己跑一遍。

OpenRouter 是一个聚合多家模型供应商的 API 网关，用统一的接口暴露 Anthropic、OpenAI、Google 等厂商的模型，并按调用转发、计费。文中出现的 anthropic/claude-opus-4.5 就是 OpenRouter 的模型标识格式：斜杠前是供应商标识，斜杠后是具体模型名。这种命名意味着同一份记录里的模型字段可能由代理层解析而来，未必等同于你最初在配置中写的名字。

Token 是模型处理文本的最小计量单位，大致对应词或词的一部分。输入 Token 指送进模型的提示词（指令、工具定义、检索材料、对话历史等的合计），输出 Token 指模型生成的回复。供应商按这两类分别定价，通常输出单价高于输入。因此「输入 5,397、输出 170」这样的数字本身不决定金额，必须结合解析后的模型才知道适用哪套价目。

把成本对比绑定到具体任务

假设你想缩短某个客服 Agent 的提示词。做法是选一组小样本问题，保留期望的源材料，用同一批用例分别运行当前配置和修改后的版本。

记录配置的模型、答案、检索来源、状态和总用量。如果启用了 fallback，文档记录的行可能仍保留主 profile，即使实际回答的是另一个模型。要做受控的模型对比，应使用不带 fallback 的测试 profile，或单独取供应商侧的凭证。还要检查更短的提示词是否保留了任务所依赖的指令——如果答案漏掉了某个重要例外，用量更低并不代表结果等价。

评估完整任务时，要把重试和失败尝试也纳入。只挑最便宜的成功运行，会掩盖拿到那个答案所付出的代价。如果改提示词的同时也换了模型或供应商设置，就应记录这项变更，而不是把差异全归因于提示词。

Fallback（回退）指主模型调用失败或超时时，系统自动改用备用模型继续回答的机制。它在可用性上有价值，却会给成本归因带来麻烦：文档记录的行可能仍标注主 profile，而实际完成请求、产生费用的却是备用模型，于是金额与模型字段对不上。

做受控的模型对比时，应使用关闭 fallback 的测试 profile，或直接取供应商侧的凭证来核对真实调用。只有保证「一次运行对应一个已知模型」，模型之间的成本与质量差异才可解释；否则你比较的可能是两套完全不同的调用路径。

失败之前的工作同样计入成本

一次运行可能在发出计费的模型请求之后才失败。AgenticOS 会在历史中保留失败的运行及其记录的用量，这让失败记录在审查工作流成本时同样有意义，即使用户从未收到最终答案。

查看失败运行时，先定位在哪一步停止。模型工作之后的工具报错，与执行前就被拒绝的请求是两回事。记录能帮你把用量和失败前已完成的进度对应起来。

不要假设每次失败的成本都一样，也不要认定失败一定比成功更贵。应针对实际任务查看记录的事件和用量。如果进行了重试，评估完成所需资源时，要把早先的尝试和成功那次放在一起看。

读懂 Spend 视图的覆盖范围

现有的 Spend 截图显示了关于未定价运行的警告。缺少价格不等于价格为零：显示的总计可能是该时间窗内用量的下限。

把仪表盘和供应商账户对比之前，先确认哪些模型标识已定价，供应商或代理是否在该查询之外附加了费用。还要比较同一个报告周期——自然月数字和滚动窗口即使在同一个页面上，也可能描述的是不同的运行集合。

模型用量只是 Agent 工作流成本的一部分。外部工具服务、沙箱计算和存储可能各有账单。估算整个任务的运营成本时，要让这些组成部分都可见，而不是把模型成本字段当成全部发票。

「未定价运行」指系统在记录中找不到某个模型标识对应的价目，因而无法为那部分用量计算金额。它和「价格为 0」是两件事：前者意味着金额未知，后者意味着已知且不收费。当时间窗内存在未定价运行时，视图显示的总计就是该窗口用量的下限而非全貌，真实金额可能更高。

常见的定价缺口包括：新上线或私有部署的模型尚未录入价目表；代理层在转发时附加了服务费或加价；供应商在报告周期之外结算。核对时还要确保比较的是同一报告周期——自然月与滚动窗口即使显示在同一页面，覆盖的运行集合也可能不同。

在目标配置上设定预算

AgenticOS 在发出模型请求之前检查已核算的支出。如果适用限额已经用尽，下一次请求可能被拒绝。检查某次运行该用哪个限额时，要看已发布的配置——修改草稿设置和发布它是两回事。

一个有用的试验是：用一次性的配置、故意设一个很小的限额，观察被拒绝的路径。检查运行状态和记录的用量，确认是哪个设置导致了停止。这建立的是那次试验的行为，而不是对所有可能工作流的普适上限。

预算不是未来账单的全额预留。请求通过检查之后仍可能产生费用，并发或已提交的工作也可能尚未反映在已核算总额中。定价缺口是显示金额可能无法描述全部用量的另一个原因。

决定放多少流量时，要把这些条件放在上限旁边一起看。支出限额和请求速率限额回答的是不同问题，外部服务费用也需要各自的管控。

看数字背后的输入

输入用量可能包含指令、工具定义、检索材料和对话历史。实际请求还取决于运行时的行为，比如选择、缓存和历史处理。数聊天窗口里可见的字数，无法复现那个请求。

如果输入在长任务中增长，要检查保留了什么。压缩（compaction）可以摘要历史，但摘要可能漏掉下一步需要的细节，而且生成摘要本身也需要工作。决定这个改动是否有帮助之前，要同时比较任务结果和总用量。

换更小的模型也适用同样的方法：固定源输入和成功标准，检查答案，记录整个任务的用量。单次请求更便宜，只有在它仍能完成你需要的工作、或以可接受的质量降低整个工作流成本时才有意义。

Compaction（压缩）是在长任务中把较早的对话历史摘要成更短文本、以控制输入 Token 增长的技术。它降低单次请求的输入成本，但引入两个代价：一是摘要由模型生成，本身也要消耗 Token；二是摘要是有损的，可能丢掉下一步真正需要的细节，导致任务失败或需要额外追问。

因此评估压缩是否有益，不能只看 Token 数下降，而要固定源输入和成功标准，同时比较最终任务结果与整个任务（含生成摘要）的总用量。这与换更小模型的判断逻辑一致：单次请求更便宜，只有在仍能完成任务、或以可接受质量降低整体工作流成本时才有意义。

保留一份有用的运行记录

第一次试验时，把任务输入、已发布配置、解析后的模型、输出和用量一起保留。加上失败的尝试，并标明平台未计入的外部成本。这样，之后改提示词或换模型时，才有具体的对象可以对比。

治理指南 解释了预算及其核算限制。上面的演示界面展示的是如何读一次运行；要估算工作负载，需要来自你实际打算支持的任务和流量的观察数据。

你最先想看到哪个 Agent 的成本，又会拿它和什么对比？