我们在为「重读」付钱,
不是在为「思考」付钱。

每来一条达人消息,系统就把整条聊天记录重新推导一遍业务状态。真正的 agent 只花掉 coordinator 预算的 2.7%,其余 95% 花在它周围的重复推导上。 这份文档基于线上实测,不是基于代码阅读的推测。

数据来源:otter-lens 线上 LLM 调用日志 + 生产库直查,7 天窗口。 每一条论断在文档里都带一个证据编号 E4, 可以回到 Research/coordinator-vnext/evidence/ 复查。

案例 A · 一条 635 KB 的 prompt,98.6% 是噪音

我们抓到线上一次真实调用:任务是「找出达人此前报过的价格」。输入 635 KB / 296,224 token, 输出 89 token。把这条 prompt 按块拆开,比例是这样的 E4:

把那 98.6% 再拆开,里面装的是:

案例 B · 模型答对了,系统重跑 60 次去推翻它

上面那条 prompt 里的 29 条消息,全部来自同一个营销邮件列表 (emil@iphonephotographyschool.com,标题「Thank You For Contacting Us」×17)。 没有达人,没有价格。模型的完整回答是:

{"priceUpdates": [],
 "summary": "No inbound creator-owned price quote for the current
            YouTube long-form video package is present in the scoped history."}

它是对的。 然后系统在同一份 296k token 输入上重跑了 60 次,花掉 $26.46 E3。 原因在代码里:校验器把「这个事实本来就不存在」和「抽取失败」当成同一种状态, 于是触发了三级修复阶梯 activities.ts:2240-2400—— 整历史重抽 → 再抽 → 内部再循环 5 次。

案例 C · 答案早算好了,却花 2 万 token 请模型复述一遍

后端有一段 9,290 字符的确定性 TypeScript,已经把该做什么、出多少钱都算出来了 prompts.ts:2197-2392。它长这样:

required_next_action:
  type: send_channel_message
  requirement:
    recommended_offer_usd: 1000
    comparison_basis: total_package
    deliverable_count: 3
    guardrail: "Use recommended_offer_usd as the exact JO total package offer…"

然后它被塞进一个 19,395 token 的 prompt——其中静态指令占 54.3%,这个决策只占 2.6% E11。模型的全部产出是:把这句话用英文重说一遍,交给下一个 LLM 去写句子。

抽样 40 次真实调用 E12:

案例 D · 叫「campaign_scoped_history」,里面装了 8 个 campaign

系统提示词里白纸黑字写着 “Every engagement is scoped to exactly one creator and one campaign; never mix facts from other campaigns” prompts.ts:71。 而线上那一个「已限定范围」的历史块里,实际含有 E5:

这不是偶然的 WHERE 写错。历史是按联系渠道聚拢的, 却按活动贴标签——而 19% 的达人(38,299 中的 7,295)同时在 ≥2 个活动上, 最多的一个在 20 个上 E6。这两个集合本来就不相等,没有任何 WHERE 子句能修好。

之前的设计稿主张把里程碑整体改造成「证据推导的投影」。数据不支持这个方案 E10:

值基本是对的,而且主要是运营在用,不是 agent 在用。整体重写是一笔糟糕的交易。 真正的缺陷只有两条:粒度错了,以及没有出处。

我们把这份材料交给了三个独立评审(只给测量数据,不给结论)。其中一个被明确要求不许读代码库, 它的开场是整轮评审最有价值的一句话:

线 A 先做,做完重新测量。 线 B 里真正紧急的只有两件——沙箱出站隔离、提醒基数 bug——其余等线 A 的数据再定。

原则一 · 一条消息,一生只被 LLM 读一次

消息到达时,一次有界的抽取调用(新消息 + 当前事实卡 → 类型化 delta), 不给历史。此后这条消息的正文不再进入任何 prompt,除非人或 agent 显式引用它。

这不是压缩或检索策略,是结构上让单轮成本与对话长度无关。 「上下文不随聊天记录线性增长」这个要求,由此在构造上成立,而不是靠预算钳制。

原则二 · 判定用代码,表达用模型

decide(state, trigger) → NoAction | Send(requirement) | Undetermined(q) | NeedsHuman(r)

decide 是纯函数,就是今天的 buildRequiredNextAction——它已经写好了。 改的是它的地位:从 prompt 里的一段建议,变成控制流本身。

数据说清楚了:这是 40% 的优化,不是 100%。 谁说能把 agent 删光,谁就是在吹。

原则三 · 没有出处就不是事实

每一条会话性事实必须能定位到 (message_id, segment, char_start, char_end, span_sha256)。 非会话性事实(打款回调、目录数据)带它自己的来源事件——否则就是在伪造出处。

摘要永远不能成为事实,靠权限边界保证,不靠在 prompt 里写「不要编造」:

• 摘要不能提供证据引用
• 摘要不能更新投影、不能授权业务命令
• 任何基于摘要的检索,必须先把被引用的原文取回来再用

三个模型角色,取代今天的十类调用

删除:批评者(金额/语言/披露校验本来就是确定性的)· 语言检测 + 语言选择 + 翻译(3 次调用折进 Writer 契约)· 轮次分类 · 品牌意图分类 · 以及全部「重新推导」调用。

预期效果

我不打算把这写成「降本 15 倍」。诚实的说法是:正常路径大约一个数量级,病态路径接近全部消除, 而且 O(n²) 变成 O(n) 是结构性的,不会随时间劣化。

上下文预算 · 每一块都有主人

今天全包没有任何一处设 maxOutputTokens 代码审计 §A4。

今天状态分散在五种并存的持久化范式里:打分笔记表、价格/条款行表、 jsonb 数组、「时间线最新节点胜出」、以及重建式投影。事实账本一次性取代它们—— 这是简化,不是新增。

create table fact (
  id            uuid primary key,
  workspace_id  uuid not null,          -- 沙箱隔离靠这个,不靠 flag
  subject_type  text not null,          -- 'creator' | 'engagement' | 'deliverable'
  subject_id    uuid not null,
  predicate     text not null,          -- 来自版本化注册表,不是模型自由生成
  value         jsonb not null,
  qualifiers    jsonb not null,         -- currency / channel / usage_rights / market
  status        text not null,          -- asserted | superseded | disputed | retracted
  source_kind   text not null,          -- message | system_event | operator
  source_ref    uuid not null,          -- ← 出处是必填,不是可选
  supersedes    uuid references fact(id)
);
create unique index fact_current on fact (subject_type, subject_id, predicate)
  where status = 'asserted';

• 当前值 = status='asserted' 的那行。 更正 = 插新行 + 回指,旧行转 superseded。历史与审计免费。
• 冲突不靠置信度裁决。 两条互斥断言且无显式更正关系 → disputed,进人工队列。按置信度选一个是在制造静默错误。
• subject_type='creator' 的行跨活动可见;engagement / deliverable 的行结构上不可能污染兄弟活动。

「campaign 是唯一容器」这件事怎么破

今天沙箱、fork、临时对话、实验全靠伪造身份挤进 campaign 命名空间 (custom:<uuid>、fork:<origin>[n])。 正确做法是把挤在「哪个 campaign」里的三个正交维度拆开:

球权看板

关键差别不是好看,是「缺的到底是什么」被写成了一个字段,而不是要人去猜。 催办因此可以指名道姓,而不是「有进展吗?」

agent 提议,人确认 —— 但只在该确认的地方

decide() 返回 Send 的 40% 直接走,不打扰人。 只有 Undetermined 和 NeedsHuman 才会出现在运营面前, 并且带着它的依据:

线上有 8,586 个进行中的交付合作。签约到成片的链路是一串交接: 选品 → 寄样 → 脚本 → 改稿 → 拍摄 → 改片 → 发布 → 打款。 每一环的延迟都来自「不知道在等谁、等什么」。

把「等待」变成一个有主人、有缺口、有时限的对象

create table obligation (
  deliverable_id       uuid,          -- ← 按交付物,所以 3 条视频并行
  kind                 text,          -- await_script_draft | await_our_review | await_publish …
  owner                text,          -- creator | us | brand   ← 球权,最关键的字段
  blocked_on           text,          -- 能让它完成的那一条 fact 谓词
  due_at, sla_hours, cadence
);

四个加速器

一 · 球权永远唯一且可见

任何时刻,每个交付物有恰好一个 owner 和一个具名的缺口。 今天「在等谁」是从位掩码推断的,推断不出来就只能发一封「有进展吗」。 有了 owner 字段,球在我们这边的时候会自动升级到内部,而不是去催达人—— 上面的看板里视频 2 就是这种情况,而这在今天是完全隐形的。

二 · 按交付物并行,不再互相掐断

这是前面那条线上正在发生的 bug 的正解:提醒挂在 (engagement_id, deliverable_id, kind) 上, 第 1 条视频发布不会再让第 2、3 条的催稿静默消失。

三 · 催办指名道姓,而不是按节奏骚扰

因为 blocked_on 知道缺的是哪一条事实,催办可以写成:

四 · 素材是有版本的对象,不是聊天里的一条链接

这是那份「充足沙箱与对象存储」预算真正该花的地方—— 按交付物建存储前缀,而不是按达人:

artifact(deliverable_id, kind, version, uri, review_state, source_message_id)
        kind ∈ { brief, script, cut, final, publish_proof }

最大的一类返工是「我们说的是哪一版」。脚本 v1/v2/v3 各自带审阅状态之后, 「已改的地方不会被重复要求,没改的地方不会被漏掉」。 再配合事实账本的引用能力,系统不会再去要一个达人已经给过的东西—— 而今天它会,因为它每轮都在重新推导,推导失败就再问一遍。

如果只做一件事,做 0a。 如果只做一周,做完 0a/0b/0c 然后重新测量,再回来看后面。

这一节是被独立评审逼出来的,我认为它比设计本身更重要。

• 「prompt 越大错误率越高」我说得太满。 38k 那一档的错误率反而低于 26k 档。上线前需按 model / purpose / 错误码 / 首次-重试 拆开重测。
• 一个病态合作证明了「可能发生」,没证明「普遍发生」。 必须测:多大比例的上下文里含有外来活动、自动化流量、零条真实达人消息。
• 过滤器的召回率是真风险。 traffic_class 会不会误杀转发、经纪人代收、带真实排期的自动回复、用群发平台发信的达人?必须有隔离区 + 召回率指标,不能直接丢。
• 编译式上下文会漏细节。 一句很久以前的让步可能进不了本轮上下文,导致「自信地答错」。缓解靠引用可追溯 + 运营可查看「本轮省略了什么」,而不是退回全量倾倒。
• 类型化状态机会拒绝合法但新颖的商业安排,运营可能为了推进流程而乱填状态。必须留显式的人工裁决出口。
• 33,169 个「进行中的谈判」里有多少是僵尸? 状态模型过载可能在虚报在办量。

完整设计:Research/coordinator-vnext/04-vnext-architecture.md
线上实测 E1–E12:evidence/prod-token-economics.md · 源码审计 A–D:evidence/code-audit-facts.md
三份独立评审(只给数据、不给结论)+ 各自提问:evidence/consultations/
我读评审前写下的独立判断(留档对撞用):evidence/my-position-before-consultation.md