type
Post
status
Published
date
Mar 15, 2026
slug
summary
tags
category
效率工具
icon
password
platform
去年十月份，我在即刻发了个帖子说：
但没想到模型发展得这么快，
现在，每天让一堆 Agent 在替我干活，已经成为了工作的日常：
- 浏览器：指挥 Tabbit 的 Agent 帮我操控浏览器，定向获取数据，配置后台。
- 写文档：在 Tabbit 中写文档，用 Chat 辅助我写文档，画流程图；
- 调研：指挥 Gemini / Manus 帮我做调研，查询某个概念/某个产品/某个技术等等；
- 编程：指挥 ClaudeCode/Cursor：帮我设计开发方案，开发软件，完成产品交互展示和功能验证；
- 设计：指挥 Codex + Figma MCP：按照需求描述画原型稿画成原型稿。
让 Agent 替我干货的好处就是，效率高了很多。
以前 3 天才能做完的事情，现在可能 1 天就干完了。
而且可以完成超出自己的能力边界以外的事。
Agent 时代的工作范式
有了 Agent 参与后，我们的工作模式发生了变化
我们将工作的内容进行简化，进行演示：
以前的工作可能是一天专注地做一件事情，三天做三件事
- 事项 A：调研 - 想方案 - 写 PRD - 开发
- 事项 B：调研 - 想方案 - 写 PRD - 开发
- 事项 C：调研 - 想方案 - 写 PRD - 开发
在 Agent 时代新的工作方式下：
以前 3 天做完的事情，现在可能 1 天就做完了
- 事项 A：Agent 调研-人类 Review
- 写事项 B：人类写文档-寻求 AI 建议-修改文档
- 事项 C：Agent 制定开发任务-人类 Review - Agent 进行开发 - 人类测试和 Review
这其实是一个工作方式的改变：从单线程到多线程
多线程工作确实让我们的工作效率变高了，但却让我们却感到更累了。
单线程 vs 多线程
以前是单线程的模式
单线程工作的优势：
- 更容易进入心流状态，产生最优体验
- 注意力不被打断，产出质量更高
- 任务的上下文完整保留在脑海中，不需要反复"加载"
- 完成后的成就感更强，形成正向激励循环
心流（Flow）是一种全神贯注、投入忘我的状态——在这种状态下，你感觉不到时间的流逝，完成任务后会产生一种充满能量且非常满足的感受。
米哈里·契克森米哈赖在《心流：最优体验心理学》中提出，心流出现时具有以下特征：
- 全神贯注：注意力完全集中在当前任务上，没有失序现象需要整顿
- 忘我状态：自我意识暂时消失，人与行动完全合一
- 时间感改变：几小时犹如几分钟，或几分钟变得像几小时
- 明确的目标与即时反馈：知道自己在做什么，并能立即看到进展
- 掌控感：充满乐趣的体验使人觉得能自由控制自己的行动
心流和 kv cache
说起来很有意思的是，心流的特点，其实和 LLM 的 kv cache 机制非常相似：
KV Cache 是大模型（如 Transformer 模型）在生成文本时用于存储键（Key）和值（Value）的缓存机制，主要用于提升推理效率。在自注意力机制中，每次生成新词时，模型需要计算当前词与之前所有词的相关性，KV Cache 保存了之前步骤的 Key 和 Value，避免重复计算，从而加快生成速度。
大模型在同一个 Session 下推理，基于 KV cache 缓存，可以节省很多算力和时间。
人的大脑也是一样，当我们专注地处理一件事情时，大脑也会有 KV cache 的机制，在思考和处理事情时，更节省脑力。
而现在是多线程的模式
有了 Agent 以后，工作模式变成了：
事项 A 发起调研 →
事项 B 写文档 →
事项 C 等待开发结果 →
事项 A 的 Agent 返回结果需要 Review →
事项 B 的 AI 建议返回 → ...
表面上，以前 3 天做完的事情，现在 1 天就能完成。
但实际上，你的大脑正在承受多线程工作的隐性成本：
1. 注意力残留（Attention Residue）
心理学家发现，当你从任务 A 切换到任务 B 时，大脑的一部分注意力仍会"残留"在任务 A 上，无法完全聚焦到当前任务。这种残留会影响你在任务 B 上的表现。
2. 蔡加尼克效应（Zeigarnik Effect）
相比已完成的任务，人们更容易记住未完成或被打断的任务。未完成的任务会占据你的短期记忆，产生侵入性想法，造成心理负担。
蔡加尼克效应（Zeigarnik effect），也称为蔡氏效应，是心理学名词，得名于苏联心理学家布卢玛·蔡加尼克。相较于已经完成的工作，人们比较容易记得未完成的，或是被打断的工作。在格式塔学派中，也用蔡氏效应来陈述格式塔现象，而且不只是一种概念上的效应，在认知上也有类似的情形。
大脑的这两个特点，
让我们在进行多线程工作时，大脑承担着很多上下文（Context）切换的成本。
每个事项都有自己的 背景信息(Context)，每当从事项 A 切换到事项 B，大脑中的注意力就要重新刷新一遍。把 Context 从 A 的切换 B 的。
但人脑不像 Agent 一样，只需要在输入框里输入 /clear，Conetxt 就会清除得一干二净。人脑也没有办法开启多个 session 来处理不同的事情。
人的大脑并没有这样的机制，
人脑的注意力机制是为了专注做一件事设计的。
当在很多事项之间频繁切换时，人脑会有大量的注意力残留，
就好像当大模型的上下文被污染混乱的时候推理的效果比较差一样。频繁切换事项也会让大脑的表现变差。
所以我们在工作中，经常会有这样的场景：
- 刚开始 Review Agent 的任务产出的时候，已经忘了最开始为什么要做这件事，只能去返回上文，重新寻找 Context；
- 因为对自己的背景信息和目标变得模糊，虽然效率很高，但有时候做着做着就发现偏离了方向，本来的目标是从 A 点走到 B 点。但现在直接走出了 B1,B2,B3 不一样的三条路。
- 在发起一个任务后，因为又切换上下文去做了另外的事情。过了好一阵子，才回想起来“噢！还有这么个事儿忘了，快点来看看 Agent 做的怎么样”
人们经常听到这样的说法：千禧一代由于成长于充满科技产品的环境，因此具有同时处理多个任务的能力。这一世俗信念是错误的。千禧一代并不比其他人更擅长同时处理多个任务，因为研究表明，几乎所有人在多任务处理时表现都不佳。” 基思·斯坦诺维奇 《这才是心理学》
维度 | 单线程工作 | 多线程工作（有 Agent） |
效率感知 | 慢但扎实 | 快但疲惫 |
认知负担 | 低 | 高 |
心流体验 | 容易进入 | 难以维持 |
完成质量 | 高 | 取决于 Review 质量 |
心理感受 | 专注、满足 | 焦虑、被追赶 |
时间感 | 沉浸、不知时间流逝 | 碎片化、时刻被打断 |
这就是现在感觉"更累了"的深层原因——人脑的设计根本不适合多线程工作。
人脑已经跟不上这个 Agent 的速度了，或者说，人类已经极大地妨碍了 Agent 的工作效率。
Agent 帮你并行处理了任务，但你仍然需要串行地 Review、决策、切换上下文。这种"异步并行 + 同步串行"的错位，正是疲惫感的来源。
人类和 Agent 协作的工作范式，让工作效率提升了很多，但却也变得更加混乱。
我们需要适应新的工作方法
在人类和 Agent 这种异步并行协作的范式下，需要探索一种像 Getting Thins Done 一样的方法，一种保持效率高的同事也更加人类友好的工作模式。
Getting Thins Done 是一种时间管理和工作效率提升的方法，由戴维·艾伦（David Allen）提出。其核心是通过清晰的清单和分类，将任务分解并按优先级处理，帮助人们更有效地管理工作和生活
因为有痛点，所以才有新的机会。
如果能够解决好这个问题，或许你可以做一个 Agent 时代的精力管理工具。
博主目前也在摸索中，只能提供一些思路：
思路一：建立"收件箱"机制，把 Push 变成 Pull
现在的痛苦很大程度上来自于——Agent 们总在Push你。
- Manus 做完调研了，弹窗提醒你查看
- ClaudeCode 遇到报错了，立刻 @你帮忙
- Cursor 写完代码了，等你 Review
也许我们应该反过来：让所有的 Agent 输出先进入一个"收件箱"（Inbox），而不是直接打断我。
就像 GTD 的方法论 [[GTD时间管理方法]] 说的，先把所有的事情丢进收件箱，然后再统一处理。并且优先处理重要紧急的事情，按照优先级来处理工作。
Conducter 有点类似这样的思路：
让用户可以在一个窗口里打开多种 Coding Agent，并通过项目和对话的维度去管理 Agent 的工作，不过可惜现在只支持了 Coding 的场景。
思路二：给人脑加上 Kv cache
人脑不像 Agent 有
/clear 命令，也没有多 Session 机制。所以每次切换任务，我都要重新回忆：
- 这个任务是干嘛的来着？
- 之前的 Context 是什么？
- 我要 Review 什么？
也许我们应该为每个 Agent 任务强制要求一个"任务卡片"，包含：
这样当我打开任务时，不用回忆，30 秒就能恢复上下文。
这也正是 Entire 团队在编程领域正在做的事情，他们在做一个更好的 Git
GitHub 前 CEO Thomas Dohmke 创立的新初创公司 Entire ，融资6000 万美金，计划为 AI Coding 设计一个更好的的 Git。
目前 Entire 的第一版本的方案，解决了 Git 在 AI Coding 时代的一个痛点
原来的 git 记录了
- What：哪些文件变了，每一行的 diff
- Who：谁提交的
- When：什么时候提交的
- Where：在哪个分支上
但 Git 没有记录为什么要这么修改（Why）
Entire 的 Check point 补齐了这一点，将对话和推理链自动跟随的 commit 记录；
让 Git 变得更适合 Agent 来阅读和使用。
- Git 是为了人类协作设计的
- Entire 是为了人类和 Agent 异步并行的 Coding 模式设计的
同样的，或许在其他领域，也需要这样的产品。
Entier官网：https://entire.io/
思路三：明确人类的角色——只做方向层和验收层
也许我们累的原因，是管得太细了。
参考 VM0 团队的工作方式，他们把人类介入简化为三个检查点：
层级 | 人类做什么 | Agent 做什么 |
方向层 | 明确需求、设定目标、定义验收标准 | 接收任务，开始执行 |
过程层 | （尽量不干预） | 自主执行，遇到问题先自己尝试解决 |
验收层 | Review 输出、验收或打回修改 | 根据反馈迭代 |
现在的我常常陷入"过程层"——Agent 一报错我就去 Debug，Agent 一卡住我就去救场。这其实是在做 Agent 应该做的事情。
更好的方式可能是：
- 给 Agent 足够清晰的任务描述和验收标准
- 让它自己去折腾，除非它明确求助，否则我不介入
- 我只在"任务开始前"和"任务完成后"出现
关联阅读：VM0 dev workflow Managing AI agents like a team https://blog.vm0.ai/en/posts/manage-agents-team
思路四：限制并行数量，接受人脑的局限性
VM0 团队的经验是：超过 10 个并发 Agent 不推荐，因为"限制因素不是工作流程，而是人的注意力和决策质量"。
我们可能也要承认：人脑就是不适合同时管理太多并行任务。
也许应该给自己设定一个上限——同时进行的 Agent 任务不超过 5 个（符合"7±2"的工作记忆容量）。
新的 Agent 任务来了？可以，先排队，等前面的完成了再启动。
理想状态
想象一下这样的工作流：
早上 9:00
- 我花 30 分钟，给 3-5 个 Agent 分别下达清晰的任务卡片
- 告诉它们：我会在 10:30 和 15:30 统一 Review
9:30 - 10:30
- 我专注做自己的深度工作（写文档、思考方案）
- Agent 们各自工作，产出进入我的收件箱
10:30 - 11:00
- 我打开收件箱，批量 Review Agent 产出
- 通过的，给新任务；需要修改的，写清楚反馈
剩下的时间
- 我继续深度工作
- Agent 继续执行
- 除非是极其紧急的事，否则不打破这个时间节奏
下班前
- 所有任务进入确定状态
- 收件箱清零
- 第二天重新开始
这样，Agent 像不知疲倦的员工一样并行工作，而我像从容的 CEO 一样批量决策。
既享受了效率提升，又不会被多线程工作拖垮。
写在最后
Agent 时代的疲惫感，本质上是来自于 人类和 Agent 异步并行协作工作过程中的无序。
我们需要重新设计一个人机界面界面，设计一个更好的工作方法来解决这个问题。
问题不在于 Agent 太多，
而在于我们还在用"单线程大脑"去应对"多线程 Agent"，并且任由 Agent 打断我们的节奏。
- Agent 不再随时打断人类
- 人类不再实时追踪 Agent 的过程
- 双方都尊重彼此的"工作节奏"
这可能就是 Agent 时代的 GTD 方法论——不是管理时间，而是管理注意力；不是追求更快，而是追求更从容。
我还在实践中，如果你有更好的方法，欢迎交流。
最后的最后，说几点洞察
- Attention is actually all you need：人类和 Agent 都需要注意力；
- 人类的存在成为限制 Agent 的发挥，这句话已经不是危言耸听；
- 工作模式的变化刚刚开始，编程领域已经先用上了 Agent，接下来会扩散到白领办公领域，再慢慢拓展到各种硬件中，到整个世界。
- 就好像 18 世纪蒸汽机被发明以后，首先用于抽水。直到瓦特改进了蒸汽机以后，慢慢才扩散到交通和工业上。
希望这篇文章，能对你有帮助，如果有的话，请给我的文章点赞，在看，或是转发给你觉得需要的朋友。现在微信中的公众号，上新了内容推荐算法，对创作者的文章阅读和转发比例有了更大的要求，希望可以多帮点点转发，感谢。