Not Everything Should Cost a Token: The Case for Deterministic AI并非所有事务都应按 Token 付费：确定性 AI 的必要性
A team I talked to recently wired up an agent to do something simple: pull a metrics API every morning, reshape the JSON, and drop the result into a table. Clean idea. It worked on day one.最近我与一个团队交流，他们接入了一个智能体来完成一件简单的工作：每天早上调用一次指标 API，重塑 JSON 数据，并将结果存入表格。这个想法很简洁，第一天也运行得很好。
Then the invoice came in. Every morning, that "simple" job was loading a few thousand tokens of raw JSON into a context window, asking a language model to reformat data it did not need to reason about, and paying for the privilege. The reformatting was occasionally wrong, too, because a probabilistic model was doing a job that a five-line script does the same way every time. The context window was so stuffed with stale data that the actual reasoning the agent was supposed to do got worse.然而账单随后就来了。每天早上，那个“简单”的任务都要将几千个 Token 的原始 JSON 加载到上下文窗口中，要求语言模型对其实际无需推理的数据进行格式化，还要为此付费。由于概率模型在执行一项本应由五行脚本就能每次完美完成的任务，格式化结果偶尔还会出错。上下文窗口充斥着过时数据，导致智能体本该进行的实际推理能力反而下降了。
That trap catches almost everyone right now. Teams treat the language model as a universal runtime. If you can describe a task in a sentence, you prompt it. But a model is not a cron job and it is not a database. It is a reasoning engine you are renting by the token, and the fastest way to blow up your bill and degrade your output is to make it do work that never needed a brain in the first place.这是目前几乎每个人都会掉入的陷阱。团队将语言模型视为通用运行时。只要能用一句话描述任务，就去提示（Prompt）它。但模型既不是定时任务（cron job），也不是数据库。它是一个按 Token 计费的推理引擎，而导致账单飙升和输出质量下降的最快方式，就是让它去处理那些根本不需要“大脑”参与的工作。
The skill worth learning is knowing what not to tokenize.值得掌握的技能是：学会哪些东西不该被 Token 化。
Why "everything is a prompt" feels right and costs so much为什么“万物皆可 Prompt”听起来很有道理，代价却如此昂贵
The appeal is obvious. Prompting is fast. You skip the schema design, the endpoint, the deploy. You just ask. For a one-off, that is genuinely the right call.这种吸引力显而易见。提示词编写很快，省去了模式设计、接口开发和部署的麻烦。你只需要直接提问。对于一次性任务，这确实是正确的选择。
The problem shows up when the one-off becomes a recurring job. Every deterministic task you route through a model inherits three properties it should never have had: it becomes non-deterministic, it becomes slow, and it becomes metered. You now pay, per run, for work that a scheduled function would do for free and never get wrong.问题在于当一次性任务变成周期性任务时。你通过模型路由的每一个确定性任务，都会继承三个本不该有的特性：非确定性、低效和高额计费。你现在需要为每次运行付费，而原本通过定时函数就能免费且准确地完成这些工作。
Two symptoms follow, and they compound each other.随之而来的是两个相互叠加的症状。
The first is cost that scales with the wrong thing. Your token spend should track the value of the judgment you are asking for. Instead it tracks the volume of mechanical work you have shoved through the model. Pull ten APIs a day instead of one and your bill grows tenfold, even though none of that pulling required intelligence.首先是成本与任务性质不匹配。你的 Token 开销应该与你所寻求的判断价值相符，但实际上它却追踪了你塞给模型的机械工作量。每天调用十次 API 而非一次，你的账单就会翻十倍，尽管这些调用根本不需要任何智能。
The second is context bloat. To "process" data, teams read it into the context window. But the context window is finite and it is where reasoning happens. Fill it with raw records and you crowd out the thing the model is actually good at. Quality drops, and because most providers meter input tokens, the cost of a long context climbs at the same time. You pay more to get worse answers. That is the part that stings.其次是上下文臃肿。为了“处理”数据，团队将其读入上下文窗口。但上下文窗口是有限的，且是推理发生的地方。用原始记录填满它，就会挤占模型真正擅长的领域。质量下降了，而且由于大多数提供商会对输入 Token 计费，长上下文的成本也在同步上升。你支付了更多费用却得到了更差的答案，这才是最令人痛苦的部分。
The distinction that fixes it: probabilistic vs. deterministic work解决问题的关键区分：概率性工作 vs. 确定性工作
Here is the mental model I keep coming back to. Sort every task into one of two buckets before you decide where it runs.这是我不断重申的思维模型：在决定任务运行位置之前，将其归入以下两个桶之一。
| Belongs in the Agent (probabilistic) | Belongs in the App (deterministic) |
|---|---|
| Judgment and interpretation | Scheduled and recurring tasks |
| Drafting, summarizing, classifying | API calls and data transforms |
| Deciding what to do and whether something matters | Storing, retrieving, and querying data |
| Handling ambiguity and edge cases | Anything that must be exact and repeatable every single run |
The line is simple. If a task needs judgment, it belongs with the agent. If it needs to be exact and repeatable, it belongs in an app. Determinism is a feature, not a limitation. A scheduled job that runs identically every morning is something you want to be boring and predictable.界限很简单。如果任务需要判断，就交给智能体；如果任务需要精确且可重复，就交给应用程序。确定性是一种特性，而非局限。一个每天运行结果完全一致的定时任务，你应该希望它是枯燥且可预测的。
And here is the anchor line for the whole idea: you build the app with tokens once, then you stop paying tokens every time it runs. The intelligence goes into creating the machine. The machine itself runs for free.整个理念的核心在于：你只需通过 Token 构建一次应用，之后便无需在每次运行时都支付 Token。智能被用于创建这台机器，而机器本身运行是免费的。
"Learn what not to tokenize" is a discipline you practice on every task, not a setting you toggle once.“学会哪些不该 Token 化”是一种需要应用于每项任务的纪律，而不是一个只需切换一次的设置。
The one everyone gets wrong: memory notes as a database最常见的错误：将记忆笔记当作数据库
There is a specific version of this mistake that is worth calling out on its own, because I see smart people do it constantly.有一个具体的错误值得单独提出来，因为我经常看到聪明人犯这个错。
People use their agent's memory or notes as a database.人们将智能体的记忆或笔记当作数据库使用。
They start dropping structured data into notes: records, metrics, pipeline stages, customer lists, inventory counts. It feels natural because the note is right there and the agent already reads it. But notes are the wrong tool for structured data, and the reasons pile up fast. There is no schema, so nothing enforces consistency. There is no query, so the agent reads the entire note into context every time it needs one field, which is both slow and metered. And notes degrade as they grow, because a wall of semi-structured text is exactly what a real table exists to replace.他们开始把结构化数据塞进笔记里：记录、指标、流水线阶段、客户列表、库存统计。这感觉很自然，因为笔记就在那里，而且智能体已经能读取它了。但笔记不是处理结构化数据的正确工具，问题很快就会堆积：没有模式（Schema），也就没有一致性约束；没有查询功能，智能体每次需要一个字段时，都必须将整个笔记读入上下文，这既慢又昂贵。而且随着笔记增长，其质量会下降，因为半结构化文本的堆砌正是真实表格存在的意义。
Now here is the part that gets lost in the "just use a database" advice, and it matters: memory notes are not the problem. Using them for the wrong job is.现在，在“直接使用数据库”的建议中容易被忽略的一点是：记忆笔记本身不是问题，用错地方才是。
Notes are genuinely the right tool for a whole category of context that has no clean schema and never will. Preferences. Tone and voice. Patterns the agent has learned. Decisions and the reasoning behind them. The "here is how we do things" knowledge that shapes how an agent thinks rather than something you would ever run a SELECT against. That context is unstructured on purpose, it exists to inform judgment, and forcing it into a rigid table would strip out the nuance that made it useful.对于那些没有明确模式、且未来也不会有的那一类上下文，笔记确实是正确的工具。比如偏好、语气风格、智能体学到的模式、决策及其背后的推理过程。这些“我们是如何做事的”知识塑造了智能体的思维方式，而不是你需要执行 SELECT 查询的对象。这种上下文特意保持非结构化，其存在是为了辅助判断，强行将其塞入僵硬的表格只会抹杀其有价值的细微差别。
So the rule cuts both ways:因此，这条规则适用于两个方面：
- Structured, queryable, high-volume data goes in a real database.结构化、可查询、高容量的数据应存入真正的数据库。
- Unstructured, interpretive, reasoning-shaping context stays in notes.非结构化、解释性、塑造推理过程的上下文应留在笔记中。
Put a customer list in your notes and you will feel the pain. Put your brand voice guide in a database and you have over-engineered something that was fine as prose. Match the tool to the shape of the data and both problems disappear.把客户列表放进笔记里，你就会感受到痛苦；把品牌语调指南放进数据库里，则是过度设计，原本用文字描述就很好。工具与数据形态相匹配，两个问题都会消失。
The Vybe model: AI and apps, each in its own laneVybe 模型：AI 与应用，各司其职
This is where the architecture stops being a philosophy and starts being a product decision.这就是架构从哲学层面转向产品决策的地方。
On Vybe, agents do not just chat. They build and operate real applications. That single fact is what makes "learn what not to tokenize" actually achievable instead of just good advice, because the agent has somewhere to put the deterministic work.在 Vybe 上，智能体不仅仅是聊天，它们还能构建并运行真正的应用程序。这一事实使得“学会哪些不该 Token 化”变得切实可行，而不仅仅是好建议，因为智能体有了存放确定性工作的地方。
The pattern looks like this. Recurring work gets scheduled inside the app, not held together by asking the model to remember to run it. Data pulls and transforms live behind an app endpoint that the agent calls when it needs them, so the mechanical steps run as code instead of as prompts. State lives in a real database that the agent queries deterministically. The agent orchestrates and reasons. The app executes and remembers. Each layer does the job it was actually built for.这种模式是这样的：重复性工作在应用内部定时运行，而不是靠提醒模型去执行。数据拉取和转换位于应用接口后端，智能体在需要时调用它们，因此机械步骤以代码而非提示词的形式运行。状态存储在智能体可确定性查询的真实数据库中。智能体负责编排和推理，应用负责执行和记忆。每一层都做它本该做的工作。
Two examples make it concrete, and one of them is our own.两个例子可以让这一点更具体，其中一个是我们自己的。
Competitor Radar. We built a competitive-tracking agent internally, and it would have been easy to let it hoard competitor data in its context or its notes. It does not. It built a live database app with scheduled refreshes. The scheduling, the pulling, and the storing all happen at the app layer as deterministic work. The agent only spends tokens on the part that needs a brain: deciding what is actually worth flagging. That system is shipped and running, and its token cost is a fraction of what it would be if the agent were doing the plumbing itself.竞争对手雷达（Competitor Radar）。我们在内部构建了一个竞争对手追踪智能体，如果任由它将竞争对手数据囤积在上下文或笔记中会很容易，但我们没有这样做。它构建了一个带有定时刷新的实时数据库应用。调度、拉取和存储都在应用层作为确定性工作完成。智能体只在需要大脑的部分消耗 Token：判断什么才真正值得标记。该系统已上线运行，其 Token 成本仅为智能体亲自处理这些琐事时的一小部分。
Falcon. In our gallery, Falcon is a Competitive Intelligence Analyst that monitors competitor changelogs, blogs, and social activity every day and delivers scheduled intelligence briefs by email. Same architecture, customer-facing this time. The monitoring cadence and the email delivery are deterministic app-level plumbing. They run on a schedule, identically, every day. The only thing Falcon spends tokens on is the judgment call: is this change actually a signal, or is it noise? The architecture doing exactly what it is supposed to.Falcon。在我们的应用库中，Falcon 是一位竞争情报分析师，它每天监控竞争对手的更新日志、博客和社交动态，并通过电子邮件发送定时情报简报。架构相同，这次是面向客户的。监控频率和邮件发送是确定性的应用层琐事。它们每天按计划、完全一致地运行。Falcon 唯一消耗 Token 的地方在于判断：这次变化到底是真正的信号，还是噪音？架构发挥了它应有的作用。
Notice what both have in common. The expensive, intelligent resource is pointed at the one part of the job that needs intelligence. Everything else runs as cheap, reliable, deterministic code.注意两者的共同点。昂贵的智能资源被指向了唯一需要智能的部分。其余一切都作为廉价、可靠的确定性代码运行。
Why this is hard to copy为什么这很难复制
Most tools on the market cannot do this, and the reason is structural rather than a matter of polish.市场上大多数工具无法做到这一点，原因在于结构性问题，而非完善程度问题。
Pure chat-agent assistants, the single-model copilots and Slack bots, have no app layer to offload to. There is nowhere to push the deterministic work, so it all stays inside the model. Every scheduled task, every data pull, every lookup runs as tokens because tokens are the only thing those tools have. Their architecture forces the exact cost problem we started with.纯聊天智能体助手、单一模型 Copilot 和 Slack 机器人没有可卸载的应用层。没有地方可以推卸确定性工作，所以它们全部留在模型内部。每一个定时任务、每一次数据拉取、每一次查找都在消耗 Token，因为 Token 是这些工具唯一拥有的资源。它们的架构强制导致了我们最初提到的成本问题。
Pure no-code and app builders have the opposite gap. They can run deterministic apps all day, but there is no reasoning layer sitting on top deciding what matters.纯无代码（No-code）和应用构建器则存在相反的缺口。它们可以整天运行确定性应用，但上面没有推理层来决定什么才是重要的。
Vybe is the platform where the reasoning agent and the deterministic app are both first-class and built together, in the same place, by the same system. And because Vybe is model-agnostic, you are not locked into one vendor's token rates for whatever mechanical work does still run through a model. You get the best of both worlds instead of paying a premium to force one world to imitate the other.Vybe 是一个将推理智能体和确定性应用作为一等公民，并在同一地点、由同一系统共同构建的平台。而且由于 Vybe 是模型无关的，你不会被锁定在某个供应商的 Token 定价上。你获得了两全其美的结果，而不是支付高昂溢价去强迫一个世界模仿另一个。
A checklist for what not to tokenize关于哪些不该 Token 化的检查清单
Before you prompt, run the task through these questions.在编写提示词之前，请用这些问题过滤一下任务。
- Does this need judgment, or is it just mechanical? Judgment goes to the agent. Mechanical goes to an app.这需要判断力，还是仅仅是机械性的？判断力交给智能体，机械性工作交给应用。
- Does it repeat on a schedule? Move it into an app-level scheduled task and stop paying per run.它是否需要按计划重复？将其移入应用层的定时任务，停止为每次运行付费。
- Is the agent making an API call directly? Replace it with an app endpoint that makes the call, and have the agent invoke the endpoint.智能体是否在直接进行 API 调用？用一个执行调用的应用接口替换它，并让智能体调用该接口。
- Are you storing structured data in notes? Move it to a database and query it when you need it.你是否在笔记中存储结构化数据？将其移至数据库，并在需要时查询它。
- Is the data in your context there to be reasoned over, or just to be stored? If it is storage, get it out of the window and reserve that space for actual thinking.上下文中的数据是为了推理，还是仅仅为了存储？如果是存储，请将其移出窗口，为实际的思考预留空间。
Run through that list a few times and it becomes instinct. You start feeling which tasks deserve a token and which ones are quietly robbing you.多运行几次这个清单，它就会变成本能。你会开始感觉到哪些任务值得消耗 Token，而哪些任务正在悄悄地掏空你的钱包。
The point was never "more AI"重点从来不是“更多的 AI”
The goal of a good agent system is not to route everything through a model. It is to apply intelligence exactly where it earns its cost, and to let deterministic code handle everything else quietly and cheaply.优秀智能体系统的目标不是让一切都通过模型路由，而是将智能应用在真正产生价值的地方，并让确定性代码安静且廉价地处理其他所有事情。
That is the whole game. Work out what actually deserves a token, build the machine once, and let it run on its own. Your model should be spending its time on judgment, not plumbing.这就是全部的诀窍。搞清楚什么才真正值得 Token，构建一次机器，然后让它自动运行。你的模型应该将时间花在判断上，而不是处理管道琐事。
Vybe is built for precisely this: agents that reason and apps that execute, together, so you stop paying a premium to make one do the other's job. See what the AI plus apps model looks like in practice, or browse the agent gallery to see the pattern already running.Vybe 正是为此而生：智能体负责推理，应用负责执行，两者协同工作，让你不必再为强迫一方做另一方的工作而支付溢价。查看“AI+应用”模型在实践中是什么样子，或浏览智能体库以了解该模式的实际运行情况。
