你在智能层争辩 prompt 的好坏，有人在 token 层已经完成了自动化。
一
我不记得这是第几次看到类似的场景了。
有人在讨论 RAG 的 chunk 大小要不要动态调整，有人在纠结 Agent 的 system prompt 应该写三段还是五段，有人在反复测试不同的 reasoning 策略。每个人都相信，智能的问题需要在智能层解决。但我的直觉正好相反：在智能层遇到的大部分问题，根因都在更底下那一层。
过去两年，我在自己的 Agent 系统上反复踩过这个坑。最开始我的关注点全在「让模型更聪明」上——更好的 prompt 模板、更复杂的 chain-of-thought、更多的上下文。但每一次，最终卡住我的都不是模型不够聪明，而是 token 不够用、格式不稳定、调用的边界失控了。
二
“正确的路径"其实只有三步，但大部分人从第三步开始走：
- 先解决 token 的问题
- 然后用 token 解决自动化问题
- 最后再解决智能问题
Token 是所有 AI 系统的最底层砖块。不是抽象意义上的砖块，是字面意义的。你让模型思考需要 token，让它记忆需要 token，让它调用工具需要 token，让它与其他 Agent 协作——每一次消息传递、每一次状态同步、每一次记忆检索——全部需要 token。如果你的 token 机制是混乱的，那么上层的一切都是沙上之塔。
我犯过的错误很典型：先找了一个顶级模型，花了大量时间设计复杂的 Agent 通信协议，结果发现模型之间的上下文边界不清晰——Agent A 的思考被错误地传给了 Agent B，Agent B 据此做了决策，决策错了，根因追溯回去，发现是底层 token 的归属和隔离没有做好。
这个阶段的痛苦不是「模型不够聪明」，而是「聪明被浪费在混乱里」。
三
正确的顺序是倒过来的：从最底层开始盖。
Token 是第一层。 在我当前的实践中，token 被当作「有主权标签的资源」来管理。每个 Agent 有自己的 token 预算，有自己的上下文边界，有明确的读/写权限。Agent A 无法看到 Agent B 的内部思考，除非通过明确定义的接口去请求。这不是功能上的限制，而是架构上的纪律——我把 token 当作系统的「砖块」而非「空气」，每块砖都有归属，不能被随意借用。
自动化是第二层。 当 token 的归属和流动被管好后，自动化才有了可预测的基础。我开始把「给 Agent A 发一个消息」自动化成一个 pipeline——不是靠 prompt 告诉 Agent 去"记得"做什么，而是靠外部的 scheduling 和 trigger 机制。Token 不只是消耗品，它同时是「消息的载体」和「过程的证明」。一个自动化流程之所以可靠，不是因为它在智能层做对了什么，而是因为它在 token 层的边界是清晰的。
智能是第三层，也是最后才需要关心的那一层。 当 token 有秩序、自动化可预测之后，模型的选择反而变得简单了——你不需要最强的模型，你需要的是在预算内、在上下文边界内、在自动化流程里表现最稳定的模型。
四
我在自己的系统里验证了这个路径。
第一阶段，我花了很长时间重构 token 的分配机制。每个 Agent 启动时获得一个明确的 token 配额，当它需要调用其他 Agent 时，调用者和被调用者各自从自己的配额中支付。这个机制的灵感来自操作系统里的进程隔离——每个进程有自己的地址空间，通过明确定义的系统调用去通信。Token 就是 Agent 世界里的地址空间。
结果很直接：Agent 之间的"幻觉碰撞"大幅减少。因为一个 Agent 不再能"借用"另一个 Agent 的上下文，错误不再跨 Agent 传播。
第二阶段，自动化变得可写、可测、可读。因为 token 的边界是清晰的，我可以精确地描述一个自动化流程消耗多少 token、涉及哪些 Agent、每个步骤的输入输出是什么。
第三阶段，模型的选择权终于回到了我手上。我不再被某个特定模型的 prompt 风格或 reasoning 策略绑定——只要它遵守 token 层的契约，它就能被替换。
五
这个三层模型的背后，是一个更本质的观察：智能不是越往上层越难的线性问题，而是越往下层越关键的基础设施问题。
“未来是无序的，智能是预测。“我越来越理解 Victor 这句话。无序指的是 token 层的熵——如果没有对 token 的有效管理、分配和隔离，上层的一切努力都是在与熵对抗。智能之所以能成为预测，前提是 token 层的规则是确定的。
类似的信号在系统设计中反复出现：文件系统的块管理先于操作系统的进程调度，网络的包路由先于应用层的协议握手，数据库的事务日志先于查询优化——每一层都是下一层的砖块。你无法在混乱的地基上建起精确的上层建筑。
六
一个我还无法回答的问题：当 token 的边界已经清晰、自动化已经可靠，我们还需要给 Agent 多少"自由”？
如果 token 被管得太死，Agent 会不会失去处理意外情况的能力？如果管得太松，会不会又回到混乱的起点？Token 层的纪律和智能层的弹性之间，是否存在一个动态平衡点——就像操作系统里 user space 和 kernel space 的切换是有成本的，但也是必要的？
我想这个问题的答案，只有在第三步走到足够深的时候才会浮现。
