我想念的并不是效率，而是那种不为任何系统打工的下午。
一、一片没有被认真看过的叶子
我大概是在给一盆琴叶榕擦叶子的时候，意识到自己已经很久没有认真看过一片叶子了。
抹布裹着清水，顺着叶脉往下走，灰尘结成细软的颗粒。客厅里只有冰箱的低鸣，和窗帘被风顶起来又落下的声音。手机在沙发另一头，屏幕朝下，像一块被翻过来的黑色方碑。
那天我没有打开任何 AI 对话框。
不是刻意修行，只是突然不想了。不想再把「帮我润色这段」复制进去，不想再等几秒，然后挑选一个看起来最像人话的版本，不想再把生活拆成 prompt 和 response。
这些年，我越来越习惯让 AI 先做一遍。写邮件先让它起稿，做计划先让它拆解，连给朋友发生日祝福，都要先问一句「怎样显得真诚但不油腻」。效率确实提升了。但体感上，时间并没有因此变得耐嚼，反而像被压缩过的视频文件，码率很高，细节很少。
效率提高了，我却仍然感到疲惫。
二、系统为什么还需要我守着
从 Notion 到 Obsidian，从卡片笔记到第二大脑，再到 Agent 集群，工具换了一轮又一轮。我们搭建系统，优化流程，把「效率」刷成日常的主线任务，却在某个深夜发现：自己只是在为系统打工。
这件事在搭建 Agent 时尤其明显。
最开始，我的关注点全在「让模型更聪明」上：更好的 prompt 模板、更复杂的推理策略、更多的上下文。在相关讨论里，也常有人纠结 system prompt 应该写三段还是五段，或者是不是该换一个更强的模型。
但真正让我停下来的，往往是一些不那么体面的细节：上下文塞不下了，输出格式变了，两个 Agent 之间传错了信息，一个任务不知道该在什么时候结束。
这些连接工作仍然需要人补上：补充说明、传递结果、处理失败的调用。一个流程即使每一步都有 AI，也可能仍然靠人把它串起来。系统替人写了一段文字，又把检查、搬运和善后的工作交了回来。
如果一个流程需要我不断提醒它下一步做什么，那么省下来的打字时间，很可能已经花在照料它上了。
擦叶子的那个下午，和这些工程上的麻烦，其实指向同一个问题：我到底希望工具替我承担什么，又准备为它付出多少注意力？
三、Token 是最底层的砖
回到系统里，我想先把顺序理清：先管好资源和边界，再把流程接稳，最后讨论怎样让模型表现得更好。
我把这个顺序记成三层：Token、自动化、智能。
说「Token 是最底层的砖」，是一个工程上的比喻。在文本模型里，token 是处理文本的基本单位，可能是一个词、一个词的一部分，也可能是标点。它与上下文长度和调用成本有关，却不自带权限，更不会自动隔离两个 Agent 的信息。
这里真正需要管理的，是模型每次能看到什么、最多消耗多少资源，以及信息通过什么接口流动。权限和隔离要由应用本身实现，不能靠在 prompt 里写一句「不要越界」。
第一层，是有限的预算和清楚的上下文。 一个任务要读哪些材料，哪些历史记录不该带进去，最多运行多少轮，到了上限怎么办，这些都应该先有答案。不同 Agent 之间传递的是完成任务所需的信息，而不是把彼此整段对话不加选择地塞过去。这样做不能消除错误，但能减少无关信息，也让错误更容易追查。
第二层，是可以检查的自动化。 谁触发任务，每一步接收什么、交付什么，失败后重试还是停下，什么时候需要人介入，都应该落在程序和流程里。让模型「记得继续」和由程序推进下一步，是两回事。一次调用花了多少 token，也不能证明任务做对了；还需要看实际输出、工具执行结果和记录。
第三层，才是具体任务里的模型能力。 当输入、输出和失败处理清楚了，再比较不同模型，才更容易分清：这次究竟是模型能力不足，还是流程本身出了问题。选择也不必只围绕「最强」展开，还要看它在这个任务里的准确性、稳定性、速度和成本。
这不是所有 AI 项目都必须遵守的唯一顺序。有时一个小实验，确实只需要一段 prompt。但当我开始搭建要反复运行的系统时，这个顺序能提醒我：别把本来可以写清楚的规则，变成一次又一次对模型的临场劝说。
四、把边界写清楚，是为了少盯一会儿
我曾经把 Agent 之间的上下文隔离，类比成操作系统里的进程隔离。这个类比有用的地方，是提醒我明确每个任务可以接触的信息，以及任务之间的通信方式。它并不意味着 token 就是地址空间，也不意味着分配了配额，错误便不会传播。
如果 Agent A 给了一个错误结论，Agent B 仍然可能照单全收。边界让我们更容易找到错误经过了哪里，验证和纠错仍然要另外做。
同样，接口统一之后，更换模型可能方便一些，却不会因此变成无成本的事。不同模型对同一份材料的理解、工具调用的表现，都需要重新检查。
我愿意花时间把这些事情做清楚，因为它们有机会减少后面的反复干预。但如果为了少点一次按钮，我维护了一套每周都要修的流程，这笔账就需要重算。
我开始觉得，评价自动化时，应该把人的时间也算进去。除了调用用了多少 token，还要问：我解释了多久，检查了多久，出了错又收拾了多久？
一个系统是否值得保留，不只看它能做多少事，也看它需要我陪着做多少事。
至于 Agent 应该有多少自由，我还没有一个通用答案。约束太细，可能处理不了意外；权限和预算放得太宽，又可能把问题拖得更大。至少可以先说明白：哪些事允许它自己尝试，哪些事必须停下来找人。
这种有限、明确的介入，比让我一直坐在旁边猜它下一步会做什么，要轻松得多。
五、生活不必照着同一套规则运行
有一次，我让 AI 整理一份会议纪要。它把「预算削减」听成了「预算血减」，还自作聪明地加了一段「关于如何止血」的建议。
我盯着那段文字看了很久，突然笑出声。不是因为错误好笑，而是因为我意识到，自己已经疲倦到连校对都觉得麻烦。
那天下午我关掉电脑，走路去三公里外的市场买豆腐。没有耳机，没有播客，也没有让 AI 给我规划最优路线。我在豆制品柜台前站了十分钟，看师傅用铜勺把豆花舀进塑料盒，动作慢得像在修补一件瓷器。
回来的路上下了一点雨。我没有打车，也没有看导航，就沿着骑楼一直走。雨水把柏油路面洗得发亮。
在系统里，我希望减少不必要的等待和返工。走在街上，我却不急着把每一分钟都用到极致。这两件事可以同时成立。
旅行也是一样。规划能解决不少麻烦，但让我记住一座城市的，常常是路线之外的东西：问路时聊了几句的人，排队时听到的对话，转错弯以后经过的一家小店。这些细节很难提前列进计划，却会在很久以后留下来。
我不怀念低效。我怀念的是亲手把事情做完的实感：自己磨一把刀，自己冲一杯咖啡，自己写一段虽然笨拙、但确实从脑子里长出来的句子。
有些工作适合交给工具，有些过程我仍然想留给自己。判断的依据，不能只有速度。
六、把屏幕留在玄关
我依然认为 AI 是很有用的工具，也仍然愿意研究怎样把它用好。只是现在，我更在意一项改进完成之后，自己能不能安心离开屏幕。
把 Token 的预算理清，把上下文的边界划好，把自动化的失败处理写明白，是希望系统少向我索取一些注意力。至于拿回来的注意力怎样花，不需要再交给另一个系统安排。
我开始练习把屏幕留在玄关。回家后先把手机放在鞋柜上，像放下一袋还需要整理的东西。然后去做饭，去擦叶子，去看一部不需要做笔记的电影，去读一本不需要写读后感的书。
这些时刻没有 KPI，也不必写进日志。我不需要证明这段时间产出了什么，才能允许自己这样度过。
Token 可以是系统的砖。把砖砌稳，是为了住进去以后，不必每天都扶着墙。
屏幕暗下去之后，房间里的光反而更亮了。
