Copilot v1.0 发布 + 每案件单位成本 — $/案件如何成为定价基础而非事后核算

日期: 2026-09-11 阶段: Phase 3 - AML 调查 Copilot 标签: #unit-economics #cost-per-case #budget-instrumentation

核心问题

P3 把作品②从「参考架构骨架」推到「v1.0 可演示 Copilot」。但 Demo 能跑只是入场券——作为对标 FIS-Anthropic「Financial Crimes AI Agent」的求职作品，真正的杀手数字不是「准确率」也不是「降本 40%」（那是别人的 benchmark），而是一个自己实测、能拆解、能解释的数字：每调查一笔 AML 告警，我的 Copilot 花多少钱？

FIS press release（2026-05）把价值主张钉死在「Reducing cost per case, by eliminating the manual evidence gathering」——cost per case 是这条产品线的北极星。所以今天回答三件事：

1. $/案件怎么拆？ 一次调查的钱花在哪——检索（RAG）、生成（lead+sub LLM）、judge（评测）三段各占多少？
2. 怎么把成本归因到「案件」这个单位？ 而不是只有一张月底的 provider 账单。复用 P2 gateway 的计量能力，怎么落到 budget.ts？
3. 为什么这个数字是 AISA（AI Solutions Architect）作品的核心？ 而不是一个事后核算的财务指标？

这不是抽象算账。Day 32 已经推过 token economics 的盈亏门槛公式，budget.ts 留了 costCapUsd 字段。今天把「事前门槛」收口成「事后实测单位成本」，闭合成本闭环。

关键内容

A. $/案件的三段分解：检索 / 生成 / judge

一次 AML 告警调查（Copilot v1.0 的最小工作单元）的成本，不是「一次 LLM call」，而是一条流水线。按 Braintrust 的「per-agent-run 归因」口径（2026-08），一次 run 要拆到能看出钱花在哪一段。本项目的三段：

一笔告警调查 (1 case)
├─ [检索段] RAG: embedding 查询 + 混合检索 (BM25+向量, RRF 融合)
│     成本 = embedding_tokens × $emb  +  rerank LLM call (若启用)
├─ [生成段] LLM 推理 (成本大头, ~70%)
│     ├─ Lead 规划       Opus 4.8   (输入证据包 + 输出调查计划)
│     ├─ Sub 检索/比对    Sonnet 4.6 (典型学 typology 比对)
│     └─ Lead 综合 SAR   Opus 4.8   (5W1H 叙述生成)
└─ [judge 段] 评测: faithfulness/coverage/submittable 三维 LLM-judge
      成本 = judge_input × $judge_in + judge_output × $judge_out

把它写成单位成本分解公式。设一笔案件 $i$ 的总成本：

$$C_{\text{case}}^{(i)} = \underbrace{C_{\text{ret}}^{(i)}}{\text{检索}} + \underbrace{\sum{r \in \text{roles}} \left( t_{\text{in}}^{r}\cdot p_{\text{in}}^{r} + t_{\text{out}}^{r}\cdot p_{\text{out}}^{r} \right)}{\text{生成 (按角色×模型分级)}} + \underbrace{C{\text{judge}}^{(i)}}_{\text{评测}}$$

其中 $p_{\text{in}}^{r}, p_{\text{out}}^{r}$ 是角色 $r$ 所用模型的输入/输出单价（cost.ts 的 MODEL_PRICES），$t$ 是 token 数。关键的工程点：生成段必须按角色拆，因为 lead（Opus，$5/$25 per MTok）和 sub（Sonnet，$3/$15）单价差一档——混成一个 input/output 桶会掩盖钱花在哪（digitalapplied 2026：「aggregating into a single input/output bucket hides where spend actually goes」）。

但「单笔实测」还不够，因为 AML 调查会重试（检索不到证据→换查询、SAR 不过 judge→重生成）。所以真正的单位成本要按成功率摊销——这是 cost-per-token 与 cost-per-task 的根本区别：

$$\bar{C}{\text{success}} = \frac{\sum_i C{\text{case}}^{(i)}}{N_{\text{success}}} = \frac{\mathbb{E}[C_{\text{case}}]}{1 - r_{\text{retry}}}$$

digitalapplied（2026）口径：「the cheapest model per token is not the cheapest model per task—retry rates, output quality, and context overhead determine true cost per unit of work」，并给出工程经验值「budget 5-15% traffic uplift on any production deployment」作重试缓冲。

反直觉洞察①（最便宜的 token 不等于最便宜的案件）：直觉是「换个更便宜的模型，$/案件就降」。但 digitalapplied 的数值反例戳穿它——「一个便宜模型若有 15% 输出需人工复核，其 cost-per-completed-task 高于一个 3% 复核率的贵模型」。在 AML 里这条更狠：一份 judge 判「不可提交」的劣质 SAR 触发重生成，整笔案件的检索段+生成段成本全部重算一遍。所以省钱不是去抠 token 单价，而是去降重试率——而降重试率靠的是 P1 的 judge gate 和 P2 的 guardrail，不是换模型。单位成本的分母（成功率）比分子（token 单价）更值得优化。

B. 成本归因方法：复用 P2 gateway 的计量

P2 已经把 AI gateway（语义缓存）的骨架搭好（semanticCache.ts），它天然是一个计量点——每次 LLM 调用都过 gateway，命中缓存则成本归零、未命中则计费。归因方法是把 Braintrust 的「六字段标签 + 五种 rollup」（2026-08）落到本项目：

每个 LLM call 在 gateway 处打标签 { caseId, role, layer, model, inputTokens, outputTokens, cacheHit }，按 caseId 聚合即得 $/案件。Braintrust 的五种 rollup 里，本项目取两种作核心指标：

成本归因的伪代码闭环（接 budget.ts 的 addCost）：

on each LLM call via gateway:
    if semanticCache.lookup(prompt).hit:        # L1/L2 命中
        cost = 0                                 # 缓存命中零成本
        record(caseId, layer, cost, cacheHit=true)
    else:
        cost = estimateCost(model, inTok, outTok)   # cost.ts 单价表
        budget.addCost(cost)                         # 累计进运行时硬闸
        record(caseId, layer, cost, cacheHit=false)
        budget.assertCostOk()                        # cost > costCapUsd → 中断

on case end:
    caseCost = Σ record where record.caseId == thisCase
    emit { caseId, caseCost, byLayer: {ret, gen, judge}, cacheHitRate }

为什么必须经 gateway 计量、而非在每个 agent 里各自记账：(1) 单一计量点保证不漏不重（DRY）；(2) 缓存命中的「省下来的钱」只有在 gateway 这层才看得见（命中率 × 平均 call 成本 = 节省额）；(3) 与 Day 32 的运行时硬闸 assertCostOk() 同源——计量和熔断共用一个 addCost 累加器。

context overhead 是 AML 场景的隐形成本大头：digitalapplied（2026）「user query 50 tokens 但 full input payload 4,000 tokens」——AML 的「证据包」（多账户交易记录 + KYC + 历史 SAR）作为每次调用的 context，远比用户那句「调查这笔告警」长。这让 prompt caching 成为财务刚需（lead 系统提示 + 固定 typology 知识库走 0.1× 命中价），而非可选优化。

C. 单位经济作 AISA 作品核心数字：定价基础而非事后核算

这是今天最重要的认知翻转。先看一组量化对比表——把本项目 v1.0 的实测 $/案件估算（保守 token，Claude 2026-06 计价）和行业基线对照：

（生成段 $0.35 沿用 Day 32 单 agent 估算；检索/judge 段按 embedding 与 judge 三维各一趟 LLM 保守估。这些是设计估算非生产实测，W13 用真实跑批回填。）

这个数字的份量，对照「chatbot → agent」的单位成本跃迁就懂了：cloudzero（2026）「单次请求从 chatbot 的 $0.02 涨到 agent 的 $0.40」——agent 化让单位成本涨了一个数量级。这意味着 $/案件不是一个事后才去看的财务指标，而是产品能不能成立的前置约束：

反直觉洞察②（agent 产品的单位成本是定价基础，不是事后核算）：传统 SaaS 的成本是「先定价（$X/座席/月），后核算毛利」——成本是结果。但 agent 产品的边际成本（每多调查一笔就多烧一次 LLM）高到无法忽略，定价必须从单位成本反推。digitalapplied（2026）给的定价法则直接说明这点：「price the outcome at 2.5-3.5x the blended per-unit model cost at your expected success rate」——先有 $/案件，才能定 per-resolution 价格。这正是 2026 的定价范式转向：Zendesk $1.50/automated resolution、Fin $0.99/outcome（fin.ai 2026）都是 outcome-based，而 outcome 价 = $/案件 × margin。所以本项目把 $/案件 实测出来，等于交付了一个「能定价、能算毛利」的产品，而不只是一个能跑的 Demo——这是 AISA 与「调通了 API 的工程师」的分水岭。 一个 PM/架构师候选人能说出「我的 AML Copilot $0.51/可提交 SAR，按 2.5× 定价 $1.3/case，对标人工 20-60 分钟有 X 倍 ROI」，比说「我接了 Claude API」强一个量级。

设计要点/决策表

对本项目的落地

• 给 src/agent/orchestrator/budget.ts 扩计量维度：当前 addCost(usd) 只累计总额，无法拆段。计划新增 addCost(usd, { caseId, layer })（layer ∈ ret/gen/judge），内部维护 Map<caseId, {ret, gen, judge}>，导出 caseCost(caseId) 与 byLayer(caseId)。costCapUsd 硬闸不变（Day 32 已设计），仅在累加时打标签——计量与熔断同源。
• gateway 作单一计量点：src/agent/gateway/semanticCache.ts 的 lookup() 返回已含 layer（exact/semantic）命中信息；计划在 gateway 包一层 meteredCall(prompt, model, role, caseId)，命中则 cost=0 并记 cacheHit，未命中则 estimateCost（cost.ts）后 budget.addCost。命中率 × 平均成本即「缓存节省额」，进 $/案件报表。
• 复用 cost.ts 单价表：MODEL_PRICES 已含 Opus 4.8 / Sonnet 4.6 / Haiku 4.5；A 节公式的 $p_{\text{in}}^r, p_{\text{out}}^r$ 直接取此表。注意 cost.ts 头注「Snapshot 2026-05」——W13 实测前须按 scripts/refresh-model-prices 核对当月官方 pricing（Day 32 SOTA 检查标记 Opus 新 tokenizer 可能多用 ≤35% token，token 估算须上修）。
• $/案件作 v1.0 发布的核心交付数字：写进作品②的 README 与长文#4（Day 90）——以「检索/生成/judge 三段分解表 + $/可提交 SAR + 对标人工 ROI」呈现，而非裸报一个总数。这是 C 节反直觉②的落地：把成本做成「可定价、可算毛利」的产品能力。
• 诚实标注：本日 $/案件（$0.43、$0.51）为设计估算（保守 token × 2026-06 计价），非生产实测；addCost 的 caseId/layer 维度、gateway meteredCall、重试率 $r$ 实测均为 P3 落地项，v1.0 发布时须标「估算口径，W13 实测回填」。严禁把估算 $/案件 报成「已实现的生产单位成本」——延续 P1 Day 27/28、P2 Day 63 钉死的降本数字诚信纪律。

参考资料

1. FIS — FIS Brings Agentic AI to Banking with Anthropic, Starting with Financial Crimes（press release，2026-05-04）：「Reducing cost per case, by eliminating the manual evidence gathering」「compress AML investigations from days/hours to minutes」「U.S. FIs spend $35–40 billion annually on AML」「BMO and Amalgamated Bank among first to deploy, broader availability H2 2026」
2. Braintrust — How to track LLM costs (2026): per-user, per-feature, and per-agent-run attribution（2026-08）：六字段标签 {user_id, feature, deployment, prompt_version, agent_run_id, customer_id}；五种 rollup（含 cost per agent run / cost per successful eval）；prompt_cached_tokens 单列
3. digitalapplied — LLM Agent Cost Attribution: Complete Production 2026 Guide / Agent Pricing Models 2026（2026）：「cheapest per token ≠ cheapest per task；retry/quality/context overhead determine true cost」；「budget 5-15% traffic uplift」；「four token layers: prompt/tool/memory/response」；「price outcome at 2.5-3.5x blended per-unit cost at expected success rate」
4. cloudzero — LLM API Pricing Comparison In 2026（2026）：单次请求从 chatbot $0.02 → agent $0.40（单位成本数量级跃迁）；output token 单价为 input 的 2-6×；prompt caching 为「highest-ROI lever」
5. fin.ai / Zendesk — AI Agent Pricing Comparison 2026（2026）：outcome-based 定价 Fin $0.99/outcome、Zendesk $1.50/automated resolution——outcome 价 = $/案件 × margin 的市场印证
6. Facctum — AML alert triage benchmarks（2026-03）：单告警 20-60 分钟、FP 率 85-95%、仅 1-5% 告警成 SAR
7. 本仓物证：src/agent/orchestrator/budget.ts（addCost/costCapUsd/assertCostOk）、src/agent/gateway/semanticCache.ts（L1/L2 计量点）、src/agent/shared/cost.ts（MODEL_PRICES/estimateCost）（2026-06）

SOTA 检查 (2026-09-11)

注：本笔记日历日为 2026-09-11；事实核查与一手原文检索（FIS press release、Braintrust、digitalapplied、cloudzero、fin.ai）在 2026-06-11 完成。$/案件实测须 W13 真实跑批后回填，发布当周按下方待跟踪项复核单价。

• 「per-agent-run 成本归因 + cost-per-task 而非 cost-per-token」是 2026-09 主流方法论：Braintrust、digitalapplied 口径一致——request-level 标签 + 按 run/successful-eval 聚合，已是生产 table-stakes。本项目「单一 gateway 计量点 + caseId/layer 标签」与此对齐，未见替代方法。
• outcome-based 定价在 2026 加速成为 agent 产品定价范式：Fin $0.99/outcome、Zendesk $1.50/resolution（2026）——这让「$/案件 实测」从财务核算升级为定价前置输入，强化 C 节反直觉②的 live 性。本项目 AML Copilot 若对外定价，应走 per-resolution（per submittable SAR），价 = 实测 $/案件 × 2.5-3.5×。
• Claude 计价的 2026 变量须发布当周复核：(1) Opus 4.8 新 tokenizer 同文本可能多用 ≤35% token，A 节 token 估算须上修；(2) Fast mode（Opus 4.8 $10/$50）改变成本结构；(3) prompt caching 命中 0.1×、Batch 5 折是把 $/案件 压下来的两个最大旋钮。cost.ts 的「Snapshot 2026-05」必须用 refresh-model-prices 在 W13 跑批前更新。
• 过时认知警示：(1) 不可把「换便宜模型」当降本主手段——重试率（分母）比 token 单价（分子）影响大（反直觉①）；(2) 不可把 $/案件 当事后核算——它是定价基础（反直觉②）；(3) 本日 $0.43/$0.51 为设计估算，非生产实测，发布材料须标限定语。
• 待跟踪（W13 跑批当周必做）：用真实 66 案金标跑 Copilot v1.0，实测三段 $/案件 与重试率 $r$，回填本日估算表；核对当周 Claude 官方单价；测 gateway 缓存命中率与「节省额」；将实测 $/可提交 SAR 写入长文#4（Day 90）作品②核心数字。