小贴士：明确你在并行运行多个智能体时的个人能力上限。
运行更多智能体并不意味着你自身能投入更多精力。目前关于智能体工程（agentic engineering）的讨论大多聚焦于吞吐量和并行处理能力，却几乎无人关注这对实际参与其中的“人”造成了多大负担。你同时要在脑海中维持多个问题上下文，不断做出判断决策，还要承受对某个智能体可能正在悄然出错的不安情绪。
这是一种我们尚未找到合适语言描述的新型认知劳动。
这源于西蒙·威利斯（Simon Willison）在与莱尼·拉奇特斯基（Lenny Rachitsky）最近的一次对话中提到的观点：同时启动四个智能体，工作到上午11点，人就已经精疲力竭了。他说的没错。我们对计算资源的扩展已有近一个世纪的直觉认知，但对“在持续进行跨任务判断的同时，脑海中同时处理五个并发问题上下文”是什么感觉，几乎毫无概念。这种消耗是潜移默化的——直到你意识到中午时分已疲惫不堪，甚至分不清哪个线程已经失控。
我一直在撰写关于协调智能体的管理模型——将并行会话类比异步工程团队运作，包含任务简报、授权模式和验证循环。但这种框架主要解决的是组织层面的开销。而我想深入探讨的是个人层面的开销，即完全存在于你内心深处的部分。
并行智能体真正对你提出的要求
当你与单个智能体协作时，认知模型相对清晰：一个活跃上下文、一条决策线索、一条待评估的输出流。你可以深入其中，察觉偏差。
但一旦同时运行四个，你所做的事情在性质上就会发生根本变化。你并非在做四遍相同的事，而是同时管理四种不同的心智模型：四种不同的代码库、四种不同的问题框架、四种不同的信任校准机制，以及四种对“它可能在多大程度上悄悄出错？”的不同估算。
最后这一点最容易被低估。并行智能体工作之所以令人疲惫，很大原因并非主动的认知负荷，而是持续的警觉性负担。你的大脑无法完全放松，因为它知道某个线程可能在二十分钟未被检查后正悄然偏离正轨。我把这称为“环境焦虑税”——它不会出现在你的任务清单上，却从同样的心理资源池中不断消耗能量。
这与我在理解债务（comprehension debt）一文中所写的观点相关：当我们让智能体生成速度超过我们的理解速度时，债务就开始累积。在单一线程中，这种债务是有界的；但在并行线程中，它会同时在多个方向叠加增长，而你往往难以判断哪个线程正在累积最大的“账单”。
真正的负载究竟存在于何处
首先是上下文切换的成本，其代价常被低估。在不同智能体间切换意味着要重新加载心智模型：这个任务从何开始、智能体采用了什么方法、三十分钟前做出的决策现在又对当前可接受范围产生何种约束。关于任务切换的研究一致表明，成本并不在于切换本身，而在于恢复时间。当有四个并行线程时，你几乎每时每刻都在支付这笔费用，而每次恢复都尚未完成，下一个切换就已到来。
其次是那些无法批量处理或延后的判断决策。这一点在我刚开始尝试更高数量级智能体时让我颇为意外。原本预期并行智能体能通过后台工作释放我的带宽，它们确实做到了——但它们也持续不断地生成需要我即时判断的时刻，这些时刻会打断我的思路：这个方案是否符合我们的架构原则？是否该停止当前线程并重新定向？这个错误是可恢复的，还是根本性漂移的信号？这些判断无法像邮件一样排队等待。
第三是信任校准的开销，它在出问题前完全隐形。每个智能体会话都伴随着动态且隐性的信任校准过程。初期我会密切观察；当某个会话进展顺利到中期时，我会给予更多自主权。但这种校准必须为每个线程单独维护——一旦你不再密切观察，校准就会退化。当你发现自己已经忘记某个线程的信任水平处于什么位置时，往往就要重新阅读它产生的所有内容。而这常常正是让一个高效的上午变成疲惫不堪的分水岭。
为何增加智能体数量不能线性提升效率
并行运行智能体有种诱人的数学逻辑：如果一个智能体能在四十分钟内完成一个功能，那么运行四个就应在同一窗口内完成四个功能。这种数学在吞吐量层面成立，但在人类层面不成立。
你的认知带宽无法并行化。智能体负责生成内容，而你仍需完成所有评估、决策、信任建立和整合工作——这些在你这边都是单线程处理的。
真正可扩展的是你的监督吞吐量，而非你的理解吞吐量。你可以监督比你能深入理解的更多智能体。但缺乏理解的监督恰恰是理解债务滋生的温床。代码虽然能发布，但你对自己所构建内容的心理模型却随着每个新增线程而越来越滞后。
这也解释了为什么Code Agent Orchestra（代码智能体乐团）中的指挥家隐喻依然成立。指挥家不必演奏每件乐器，而是把握整体乐章。但正因为要把握整体，这种全系统意识才格外耗费心力。试图通过更努力来扩展这种能力是行不通的。
找到自己的上限本身就是一种技能
我们大多数人都会通过“撞墙”的方式发现这一点：从一个表现良好的两个智能体会话开始，觉得还可以再加一个，再加一个，到中午时已无心仔细审阅任何内容，只是被动接受输出。这感觉不到失败，只觉得是高效。
你的上限不是一个固定数值。它会随每个线程的复杂度而变化。两个智能体处理真正新颖的架构问题，会比四个处理边界清晰的迁移任务更快耗尽你的精力。每个线程的作用域范围比线程数量本身影响更大。
它也会随前期任务规划的清晰度而变化。模糊的简报会在执行过程中制造歧义，迫使你反复回到该线程。而清晰的简报配合明确的验收标准，能让线程更具自包含性。在启动前撰写一份规范的简报不是额外开销，而是让你真正能够抽离的前提。
它还随会话时长而变化。有明确时间限制的小会话与开放式的长会话感觉完全不同。没有定义终点状态时，你会 indefinitely 地维持开放循环。周一精力充沛、会议较少的一天，其上限与周四下午连续六场背靠背会议后的上限，显然存在实质性差异。在这两种情况下使用相同的智能体数量，是一种大多数人都未察觉的误判，直到你已精疲力尽。
我实际做出的改变
我现在把长时间的智能体会话当作深度专注工作来对待：设定时间盒，并为每个线程明确作用域。
具体做法是：在启动任何智能体前先定义会话总时长，并根据此时间框来设计任务范围。如果我要进行两小时的三线程会话，我会确保每个线程的任务都能在该窗口内完成，且我能用三十分钟审阅其输出。如果任务不符合这个形态，我就要么拆分任务，要么减少线程数。
时间盒创造了自然的检查点，防止悄无声息的漂移——你不是因为焦虑而检查，而是因为时间到了。这也改变了环境焦虑的负担。开放式线程带来的是无期限的警惕，而时间盒线程带来的是有边界的警惕，这种差异会在一周内不断累积。
第二个改变：我已接受三个专注且经过充分审阅的线程，比六个我只能半监督的线程产出更有用的结果。六个线程看起来吞吐量更高，但只有三个线程的代码，我才愿意在没有第二遍审查的情况下真正合并。对于典型会话，我的上限大约在三个到四个线程之间，具体取决于复杂度。知道这个数字后，我就不再把少于这个数量的线程视为失败。
如何校准——如果你希望有意识地控制
从比你感觉“刚好合适”的数量少一个线程开始。诱惑在于不断推高智能体数量直到系统崩溃。反过来操作则能让你保持校准状态而非被动反应。
关注你的审阅质量，而非智能体数量。当你在会话结束前对将要接受的内容信心开始下降时，你就找到了该会话的上限。这个信号比任何经验法则都更诚实。
留意焦虑信号的早期迹象。对一个线程“不太清楚它到底在做什么”的感觉本身就是信息。当这种感受同时出现在两个以上线程时，你就已达到容量极限。
尝试先缩小作用域，再减少数量。很多时候杠杆不是“运行更少智能体”，而是“给每个智能体分配更紧凑的任务”。更小的线程作用域降低了每个线程的心理开销，从而让你在仍能真正掌控工作的前提下，有效运行更多线程。
我们讨论得还不够多的部分
关于AI编程智能体的讨论几乎全部集中在智能体能做什么。它还需要包括人类能持续承受什么。
上限不是个人能力的失败。我们拥有有限的工作记忆、真实的上下文切换成本，以及有限的警觉性。长期来看，能从并行智能体中获得最大价值的工程师，不会是那些同时运行最多数量的人，而是那些能区分吞吐量与理解力，并学会将这种区别作为设计约束而非弱点来对待的人。
在使用这些工具时找到你的个人上限是一种技能。我们大多数人都会在无意中经历这个过程，而不是有意识地学习它。目标就是缩短这个差距。
