Deep Research 的成本不是一次模型调用的账单。
一个任务可能经过多轮模型推理、搜索 API、网页访问、计算、重试、摘要、状态存储和结果传输。某次成本异常，原因可能是上下文越来越长，也可能是工具超时触发重试，或者缓存没有命中。
如果监控只有“今天用了多少 token”，团队只能看到总额上涨，却不知道哪个租户、哪类问题、哪一步、哪个模型或哪个工具造成了变化。
相关工程材料提出全链路指标、结构化日志、成本趋势与异常告警。真正落地还需要把每项消耗关联到任务 Trace 和质量结果。
所以面试官真正想问的是：
Deep Research 成本应拆成哪些组成，Trace 怎样从 task 关联到模型和工具 span，估算成本与供应商账单如何对账，怎样定位重试、长上下文和缓存失效，又如何避免为了降本牺牲证据与答案质量？
为什么“总 Token”远远不够？
第一，它看不到输入和输出差异。
长上下文反复输入可能是主要消耗，输出却很短。只看合计无法判断应该压缩历史还是缩短报告。
第二，它看不到模型差异。
同样 token 数在不同模型、地区、批处理或缓存定价下成本不同。
第三，它看不到工具成本。
搜索、网页解析、学术数据库和第三方 API 可能按请求或结果计费，不体现在 LLM token 里。
第四，它看不到失败浪费。
超时重试、重复任务、无效循环和最终取消都可能已经消耗资源。
第五，它看不到成本与质量关系。
更便宜的任务如果漏答、无证据或需要用户重跑，未必更经济。
总 Token 适合看趋势，不适合做根因分析和单位经济判断。
成本需要落到任务、步骤、资源和结果，不能停在总量。
一次任务的成本应该拆成哪些部分？
模型推理成本包括输入 token、输出 token、可能的缓存读写、模型版本与调用次数。
自建推理还要考虑 GPU 时间、显存占用、空闲与批处理效率，但它与供应商按 token 计费不是同一口径。
工具成本包括搜索请求、网页抓取、解析、OCR、数据库查询、计算与外部服务调用。
基础设施成本包括任务队列、状态数据库、对象存储、日志、Trace 与网络传输。
失败成本包括重试、重复提交、取消前已执行步骤、失效缓存和无效循环。
人工成本可以单独记录，例如高风险任务复核，但不要与在线机器成本混成一个实时指标。
每项都需要单位、价格版本和归属规则。没有这些，汇总数字无法复算。
Trace 应该怎样分层？
根 span 表示一次 task，保存 task ID、租户、问题族、预算、版本和最终状态。
阶段 span 表示计划、检索、访问、计算、摘要和综合等阶段。
模型 span 记录模型、Prompt 版本、输入输出 token、缓存使用、采样、延迟与结果状态。
工具 span 记录工具名、参数摘要、供应商 request ID、计费单位、缓存命中、重试与错误类型。
状态 span 或事件记录 checkpoint、上下文长度、证据数量、剩余预算和停止原因。
父子关系让团队看到一次昂贵任务究竟在哪一步扩张。
异步任务跨进程、队列和服务时，需要传递 trace ID 与 task ID。不能依赖线程局部变量。
日志、指标和 Trace 使用同一关联键，但敏感问题与网页正文不进入高基数标签。
从 task 到模型、工具和状态 span，才能把异常成本定位到具体原因。
模型调用需要记录哪些字段？
模型提供方、模型 ID、部署版本和区域决定价格与性能口径。
记录 input token、output token、缓存命中 token、请求次数、开始与结束时间、排队和生成状态。
Prompt、工具 schema 和上下文策略版本也要保存。模型没变，Prompt 变长同样会推高输入成本。
若使用路由，记录路由原因与候选模型，不能只看最终模型名。
流式响应要在结束时补齐实际 usage。客户端断开不等于供应商停止生成，最终计量需要后端确认。
失败调用也要记录供应商是否计费，不能一律按零成本处理。
价格字段不直接硬编码进历史 span，可以记录 price version，再由可复算规则计算估算成本。
工具调用怎样计量？
不同工具计费单位不同。
Search 可能按请求，网页解析可能按页面、字符或计算时长，OCR 可能按页，数据库按资源消耗，自建工具则体现为基础设施成本。
工具 span 记录请求类型、结果数量、响应大小、延迟、状态、缓存命中和重试次数。
参数中可能含敏感 query，Trace 只保存脱敏摘要或哈希，不把原始私有内容写入标签。
若工具结果来自缓存，记录缓存层、数据新鲜度与原始供应商。命中不等于零成本，缓存存储和回源仍有成本。
工具失败后的换源要建立父子关系。否则看板只看到多个独立请求，不知道它们属于一次恢复路径。
估算成本与真实账单为什么会不一致？
在线系统需要立即显示预算消耗，只能根据当前价格表和 usage 做估算。
供应商账单可能晚到，并包含折扣、阶梯、缓存、失败计费、税费或区域差异。
因此要区分 estimated cost 与 billed cost。
估算用于运行中预算与异常发现，账单用于财务对账。二者不能互相覆盖而丢失历史。
通过供应商 request ID、账户、模型与时间窗口做对账，记录无法匹配和价格版本差异。
价格更新时，历史任务是按当时价格重算，还是按最新价格做情景分析，也要明确。
若供应商只给聚合账单，归因精度会受限，报告应展示未分摊部分，不强行伪精确。
怎样定位“上下文越来越贵”？
为每个模型 span 记录输入 token 和研究步骤序号。
若输入随步骤持续增长，说明系统可能每轮重放全部历史。
进一步区分工具 observation、状态摘要、系统 Prompt、证据和用户上下文分别占多少。
IterResearch 的演进报告与 ReSum 等方法，方向上用于控制长上下文；是否真实降本必须在同一任务、相同质量下测量。
压缩过度也可能丢失证据和约束，导致后续重搜或答案错误。
因此实验同时看累计输入 token、重搜次数、证据覆盖、答案质量和运行时长。
不能用教程中的复杂度直觉直接换算现有账单，也不能声称已经从某个量级降到另一个量级。
重试放大怎样被看见？
为每个逻辑 operation 分配稳定 ID，每次物理尝试记录 attempt number。
这样可以区分“用户确实发起多次不同搜索”和“同一个搜索请求被重试多次”。
看板展示成功前尝试次数、最终失败消耗、各错误类型和上层重试次数。
若工具适配层、Worker 和客户端都重试，Trace 能看到嵌套放大。
重试预算应跨层传递，避免每层都认为自己只试了少数几次。
网络超时后供应商可能已经执行成功，必须用幂等键或 request ID 查询，不能盲目再次计费。
降低重试次数不是最终目标。若成功率和质量下降，节省只是把失败交给用户。
缓存“节省了多少”怎样验证？
缓存命中时记录避免了哪个逻辑 operation、使用了哪一层缓存、数据年龄和是否满足新鲜度策略。
估算节省可以基于当时价格和原请求 usage，但要标为 counterfactual estimate，不是已发生账单退款。
还要计入缓存存储、序列化、失效和回源成本。
最重要的是质量。过期缓存可能让最新问题回答错误，不能把高命中率当纯收益。
对时效问题做绕过或短 TTL，对稳定结果才复用。比较时同时看命中、回源、旧数据错误和任务质量。
本文不声称现有系统已经通过缓存节省某个比例。
模型路由怎样做成本归因？
每一步先记录任务状态和路由决策：为什么使用小模型、为什么升级大模型、是否回退。
若小模型输出失败后再调用大模型，总成本是两次调用加恢复，而不是只看最终成功模型。
路由实验需要固定任务集，比较答案、证据、工具策略、延迟和成本。
简单任务可用较便宜模型是设计方向，但“简单”必须可验证。错误分诊会造成二次调用或低质量答案。
路由模型本身也有推理成本和延迟，应进入 task Trace。
不能只展示大模型调用比例下降，就宣布总成本优化。单位任务成本、失败重试和质量回归才是完整证据。
预算控制应该放在哪里？
提交时检查租户配额和任务级预算，防止明显超额任务进入队列。
调度时为模型、工具与总任务分配可用预算。
每个步骤前用估算成本做预检查，完成后用实际 usage 更新。
接近预算时，控制器可以缩小范围、切换模型、停止非必要分支或部分交付，但必须遵守任务质量硬门。
预算耗尽是明确终止原因，不等同策略错误。
如果价格更新，运行中任务使用哪个版本要固定，避免预算计算中途跳变。
对高风险任务，可以要求人工批准扩展预算，而不是自动继续。
成本告警怎样避免噪声？
全局总额告警只能发现大事故。
还应按任务类型、租户、模型、工具、版本和错误类型观察分布。
单任务成本异常适合捕获循环和超长上下文，日趋势适合发现价格或流量变化，失败成本比例适合发现环境问题。
告警使用基线分布和变更事件，不盲设一个适用于所有任务的固定金额。
每条告警附带 trace 链接、最近部署、价格版本和相似任务对比，减少值班人员重新拼信息。
高基数标签不能直接塞进指标系统。task ID 用于 Trace 查询，指标只保留受控维度。
没有现有生产数据时，可以先定义告警规则与演练，不声称已经验证了阈值。
成本看板为什么必须和质量看板放在一起？
只看成本，最容易得到错误优化。
减少工具调用可能降低证据质量；缩短输出可能漏答；路由小模型可能增加错误和重试；强缓存可能返回旧资料。
可以按质量硬门筛选后比较成本，或者画质量与成本的二维分布。
同一任务族中，找到质量达标的较低成本版本，比全站平均成本下降更有意义。
失败、取消和部分完成单独分组。低成本失败任务不应拉低平均值后看起来更好。
用户重跑也要关联原任务，否则一次失败拆成两次 task 后，真实完成成本被低估。
降本必须在任务质量、证据和完成边界不退化的条件下成立。
指标标签为什么不能塞 task ID 和原始 Query？
指标系统适合有限维度的聚合，例如模型、工具、状态、环境和问题类型。
task ID、用户 ID、URL 和原始 query 基数极高，会让时序数据库存储与查询成本迅速增加。
原始 query 还可能包含个人信息、商业资料或敏感关键词，不应作为普通标签传播。
更合理的做法是：指标保留受控维度，Trace 保留 task 级关联，日志保存经过脱敏的必要诊断字段。用户输入与工具原文进入权限更严格的存储，并按保留策略管理。
看板发现某个问题族成本异常后，再通过 trace ID 下钻具体任务，而不是把所有明细复制到指标。
标签字典需要版本化。问题分类规则变化时，历史与新数据不能静默使用同名不同义的标签。
可观测系统自身也有成本。无限增加标签和全量日志，可能为了监控成本又制造新的成本黑洞。
Trace 是否必须百分之百全量保存？
计费所需的聚合 usage 和任务成本应尽量完整，否则账单无法对齐。
详细 Prompt、observation 与逐步事件则可以根据风险、失败和抽样策略保存。
成功且低风险的常规任务可只保留结构化摘要；失败、异常高成本、安全事件和新版本灰度可以提高采样率。
但抽样决定要在知道基本成本和状态后进行。若先随机丢掉所有高成本细节，根因分析仍然失败。
采样规则、采样概率和保留期限写入 Trace 元数据。比较不同版本时，可以按概率校正聚合，避免某个版本只是采样更多而看起来异常更多。
账单对账记录、价格版本和供应商 request ID 不应随诊断 Trace 一起随意丢弃，它们承担不同用途。
Showback 和 Chargeback 应该怎样做？
Showback 是把消耗展示给租户或团队，帮助理解使用；Chargeback 则进一步把费用分摊或结算。
二者都依赖明确归属。共享缓存、自建 GPU、平台基础设施和公共评测任务不能随意全算给最后一个用户。
可以先定义直接成本与共享成本。直接模型、工具调用按 task 归属，共享资源按可解释规则分摊，无法归属的部分单独列出。
内部研究、失败重试和平台故障造成的浪费是否向用户计费，要有产品与财务规则，技术系统只提供证据。
Chargeback 前必须处理账单延迟与调整，不能用在线估算直接结算后不再校正。
成本展示还要附带任务状态和质量。用户看到一次任务便宜，却不知道它失败或只部分完成，信息是不完整的。
文章只解释归属方法，不代表现有系统已经上线计费或内部结算。
异步任务的成本为什么可能晚到？
模型流式 usage 可能在响应结束时返回，工具供应商账单可能更晚，后台重试也可能在用户关闭页面后继续。
因此 task 完成时可以先写 estimated cost，状态标记为待对账。
后续成本事件使用 task ID、operation ID 和供应商 request ID 追加，并通过版本或流水账方式更新汇总。
不能覆盖原始估算后只保留最终数字。估算误差本身可以帮助发现价格表、缓存计费或失败调用理解有误。
任务取消后仍要接收已发生调用的迟到 usage，避免把取消任务成本低估为零。
对账任务需要幂等。同一账单文件重复导入时，不应重复累计。
当 billed cost 稳定后，再把任务标为已对账；仍有未匹配项目则保留差额和原因。
怎样把成本异常关联到代码和配置变更？
每个 task Trace 记录应用版本、模型路由版本、Prompt、工具 schema、缓存策略和价格版本。
成本曲线发生变化时，先查看同一时间的发布、流量构成与供应商价格变化。
例如输入 token 增长可能来自 Prompt 新增说明，不一定是用户问题变长；工具调用增长可能来自重试配置修改，不一定是模型策略退化。
灰度发布应同时保留基线与候选版本，在相同问题族和质量条件下比较。
回滚后继续观察迟到任务和账单，避免认为曲线立即恢复就代表问题完全结束。
变更事件也是可观测数据。没有版本维度，团队只能看到“今天更贵”，却无法形成可复现归因。
怎样做一次可验证的降本实验？
先选定按问题族隔离的任务集和质量 rubric。
冻结模型以外的工具、环境、价格版本和预算，或者明确唯一变化项。
采集基线 task Trace，确认 token、工具、重试和状态字段完整。
只修改一个方案，例如上下文压缩、缓存或路由。
比较输入输出 token、工具调用、失败、重试、延迟与估算成本，同时运行答案、证据和过程评测。
人工抽查成本下降最大的样本，防止它们只是提前停止或丢失内容。
账单到达后做估算与实付对账，记录无法归因部分。
小批结果只说明当前任务与条件。没有生产流量和多周期数据，不能承诺长期成本收益。
面试官继续追问，怎么接？
追问一：统计每个请求 token 不就够了吗？
不够。还要关联任务步骤、工具、重试、模型价格、缓存、状态和最终质量，才能定位成本原因。
追问二：为什么估算成本和账单要分开？
在线估算用于预算，账单包含真实折扣与计费规则。混在一个字段里会让历史无法复算和对账。
追问三：缓存命中是不是等于省钱？
不是。要计算避免的调用、缓存本身成本与新鲜度风险，并将节省标为反事实估算。
追问四：如何发现重试成本黑洞？
用逻辑 operation ID 关联多个 attempt，并跨工具、任务和客户端统计嵌套重试。
追问五：你们现在单次任务成本是多少？
材料没有可核验生产账单或 Trace。可以讲清计量与验证方法，不能虚构金额。
怎样向面试官解释成本归因链路
Deep Research 的成本要以 task 为归属单元，不只看总 token。根 Trace 下记录模型、工具、缓存、状态、重试和存储 span，模型 span 保存模型与价格版本、输入输出和缓存 token，工具 span 保存计费单位、request ID、缓存命中和 attempt。
在线 estimated cost 用于预算，供应商 billed cost 到达后再对账，未匹配部分单独展示。通过步骤输入长度定位上下文膨胀，用 operation ID 看重试放大，用缓存年龄与质量判断假节省，用路由原因和回退记录计算真实总成本。
成本必须与任务完成、证据、答案和失败放在一起。降本实验固定任务族与环境，只改一个方案，比较资源、重试、延迟与质量，并人工回放下降最大的样本。相关材料只提供全链路监控、缓存、路由和告警方向，没有现有账单、生产 Trace 或收益数据，因此不能编造单次成本与节省比例。
成本数据能否回答这六个问题
成本看板只是入口；真正能支撑项目主张的，是从异常账单一路定位到任务、步骤、重试和质量变化的证据。
- 是否以 task 和 span 关联模型、工具、缓存、重试与状态？
- 是否区分 estimated cost、billed cost 和未分摊金额？
- 是否记录价格版本、供应商 request ID 和逻辑 operation ID？
- 是否把失败、取消、部分完成和用户重跑纳入真实完成成本？
- 是否让成本优化通过答案、证据和过程质量硬门？
- 是否明确没有虚构生产账单、Trace、单次成本或节省比例？