并非所有交互都要消耗Token：确定性AI的案例

背景

大语言模型（LLM）正被越来越多地嵌入日常业务流程中，团队倾向于把任何能用语言描述的任务都直接丢给模型处理。这种“万物皆可 prompt”的做法看似高效，实则暗藏巨大的成本陷阱和质量隐患。最近一个团队仅仅为了每天从 API 拉取 JSON 数据并重新格式化、存入表格，就运行了一个 agent——结果第一天工作正常，但账单却因为每次加载数千 token 的原始 JSON 而迅速膨胀，而且格式化偶尔还会出错，因为概率模型在执行一个五行的确定性脚本就能完美完成的任务。这个案例揭示了一个普遍问题：团队把语言模型当成了通用运行时，但模型不是 cron 作业，也不是数据库，而是按 token 计费的推理引擎。让模型做本不需要“大脑”的工作，是最快烧钱、降质的方式。

核心内容

“一切皆 prompt”的诱惑与代价

prompt 的吸引力很明显：快速，无需设计 schema、构建 endpoint、部署。对于一次性任务，这确实是合理的选择。但问题在于，当一次性任务变成周期性任务时，每一条确定性任务路由到模型都会继承三个不该有的属性：非确定性、慢、按量计费。你为每个运行周期支付费用，而一个定时函数本可以免费且永不犯错地完成。

两个症状相互叠加：

1. 成本随错误的东西增长。Token 开销应该与所请求判断的价值成正比，但现在却与塞进模型的机械工作量成正比。每天拉取十个 API 而不是一个，账单就涨十倍，尽管这些拉取都不需要智能。
2. 上下文膨胀。为了“处理”数据，团队把数据读入上下文窗口。但上下文窗口有限且是推理发生的地方。塞满原始记录会挤占模型真正擅长的部分。质量下降，同时因为大多数提供商按输入 token 计费，长上下文的成本也在攀升。你付更多钱却得到更差的答案。

区分概率性工作与确定性工作

核心的心智模型：在决定任务在哪里运行之前，把每个任务归入两个桶之一。界限很简单：需要判断的任务归 agent，需要精确且可重复的任务归应用。确定性是一种特性，不是限制。一个每天早上相同方式运行的定时任务，应该是无聊且可预测的。

关键锚定线：你只用 token 构建一次应用，然后每次运行时就不再支付 token。智能投入到创建机器的过程中，机器本身免费运行。

一个常见的错误：把记忆笔记当数据库

很多人用 agent 的记忆或笔记来存储结构化数据：记录、指标、流水线阶段、客户列表、库存数量。这感觉自然，因为笔记就在那里，agent 已经会读它。但笔记不适合结构化数据：

• 无 schema，无法保证一致性
• 无查询能力，agent 每次需要某个字段时都得把整个笔记读入上下文，既慢又计费
• 笔记越长越退化，半结构化文本正是一张真正的表格要取代的东西

但笔记本身并非问题，用错地方才是问题。笔记真正适合的是那些没有清晰 schema 且永远不会有的上下文：偏好、语气和风格、agent 学到的模式、决策及其背后的推理。“我们做事的方式”这类知识塑造 agent 的思考方式，而不是你会用 SELECT 去查询的东西。这种上下文天生非结构化，用于影响判断，强行塞进刚性表格会剥离其有用性。

因此规则是双向的：

• 结构化、可查询、高容量的数据 → 真实数据库
• 非结构化、解释性、影响推理的上下文 → 保留在笔记中

把客户列表放在笔记里会痛苦，把品牌语气指南放在数据库里则过度工程化。工具匹配数据形状，两个问题都消失。

Vybe 模型：AI 和应用各司其职

在 Vybe 平台上，agent 不只是聊天，它们构建并运行真正的应用。这一事实使得“学会不 token 化”从好建议变成可实现的目标，因为 agent 有地方放置确定性工作。

模式如下：

• 周期性工作安排在应用内部，而不是靠模型记住去运行
• 数据拉取和转换放在应用 endpoint 后面，agent 需要时调用，机械步骤作为代码运行而非 prompt
• 状态存储在真实数据库中，agent 确定性查询
• agent 编排和推理，应用执行和记忆

两个具体例子：

1. Competitor Radar：内部构建的竞争追踪 agent。它不会把竞争对手数据囤积在上下文或笔记中，而是构建了一个带定时刷新的实时数据库应用。调度、拉取、存储都在应用层作为确定性工作完成。agent 只把 token 花在需要大脑的部分：判断什么真正值得标记。该系统已部署运行，token 成本比让 agent 做管道工作要低得多。

2. Falcon：竞争情报分析 agent，每天监控竞争对手的 changelog、博客和社交媒体活动，并通过邮件发送定时情报简报。同样的架构，面向客户。监控节奏和邮件发送是确定性应用级管道，每天以相同方式运行。Falcon 只把 token 花在判断这个改变是信号还是噪音上。架构正是按预期工作的。

注意两者的共同点：昂贵的智能资源只指向工作真正需要智能的部分，其余部分作为廉价、可靠、确定性的代码运行。

为什么这难以复制

大多数现有工具无法做到这一点，原因在于结构性问题而非打磨。纯聊天 agent 助手（单模型 copilot、Slack bot）没有应用层可以卸载工作，无处可推确定性任务，因此一切都在模型内部运行。每个定时任务、每个数据拉取、每个查询都消耗 token，因为 token 是这些工具唯一拥有的东西。它们的架构强制了文章开头提到的成本问题。

纯无代码和应用构建器则有相反的问题——它们缺乏 agent 的推理能力，无法实现智能判断与确定性执行的分离。

关键要点

• 不要把所有任务都 token 化：语言模型是推理引擎，不是通用运行时。需要判断的任务用 agent，需要精确可重复的任务用常规代码。
• 成本陷阱：token 花费应跟踪判断的价值，而非机械工作量。把确定性任务塞进模型会导致成本随错误的东西（数据量）线性增长，而智能价值并未增加。
• 上下文膨胀损害质量：用上下文窗口处理原始数据会挤占推理空间，同时增加输入 token 成本，导致“付更多钱得更差答案”的恶性循环。
• 记忆笔记不是数据库：结构化、可查询、高容量的数据应放入真实数据库；非结构化、影响推理的上下文（如偏好、风格、决策逻辑）才适合放在笔记中。
• 架构决定成本：好的架构让 agent 仅负责推理，应用层负责执行和记忆。定时任务、数据拉取、格式转换等确定性工作应作为代码运行，而非 prompt。
• 工具的结构性限制：纯聊天 agent 没有应用层，无法卸载确定性工作，会陷入成本陷阱；纯无代码工具缺乏智能判断能力。两者都无法做到 agent 与应用的有机分离。
• 成功案例：Vybe 的 Competitor Radar 和 Falcon 证明了该模式的有效性——智能资源只用于判断，其余工作由确定性应用层免费运行。

意义与影响

这篇文章提出了一个在 AI 工程化实践中至关重要的原则：学会区分什么时候用模型，什么时候用传统代码。在 LLM 热潮中，许多团队不假思索地把所有任务都 prompt 化，导致成本失控、输出质量下降。文章通过清晰的二元分类（概率性 vs 确定性）和具体架构模式（agent + 应用层分离），为构建可持续、低成本的 AI 系统提供了可操作的指导。

这一原则的影响是深远的。首先，它推动了 AI 架构从“全模型”向“混合架构”的转变，让 token 资源仅用于真正需要推理的地方，大幅降低运营成本。其次，