【人机协作】为什么大佬可以做到一个人盯10-20个Agent，但是你不行

TLDR：你多开窗口耍 cx/cx 效率极限在 10 个左右，而减少人类介入时间之后，可以达到 20 个

我们假设：

• 人类的注意力是串行的——你同一时刻只能专注一件事。


• AI Agent 是并行的——100 个 Agent 数量没有上限，跑起来互不干扰。

所以我们可以建模一下，人类与AI协作的效率模型

你的注意力有限

想象你是一个餐厅经理，手下的厨师想要多少有多少。

如果你站在一个厨师背后盯着他切菜、炒菜、装盘，全程指挥。虽然你确实让这个厨师做得更好了，但你只有一双眼睛。

那开 20 个厨师呢？理论上你 2 分钟指导一个，刚好轮一圈。但问题来了：你从粤菜厨师走到日料厨师，脑子要从"镬气"切换到"刀工"，这个切换不是免费的。而且厨师越多，你记住每个人做到哪一步就越难。

到了第 25 个厨师，你光"想起来他在做什么"就要花 1 分钟，指导的 2 分钟反而没发挥作用。

这就是为什么优化任务效率的问题中，最优解不是"无限多 Agent"，而是存在一个极值。

公式来了

别被吓到，就三个东西：

• 
  

  N = 你同时跑的 Agent 数量，没有上限

  
  


• 
  

  α(N) = 脑子切换的成本，随 N 增大而增大。管 3 个 Agent 切换成本很低，管 20 个你光回忆上下文就耗尽了

  
  


• 
  

  η(N) = 调度效率，范围是0-1，随 N 增大而降低。Agent 越多，"3 个同时找你"和"全在跑没人需要你"的概率都在涨

  
  

注意到：N 往上走，α 在吃你，η 在拖你。存在一个最优并行数 N^*， 超过它，再加 Agent 反而降低总产出。

不同的工作模式，N* 不同。你的基础设施越好，N^* 越高。

五种工作方式，效率差多少？

Level 0：纯人类编码

baseline：你自己写，40 分钟一个任务。一天 8 小时，完成 12 个。

Level 1：盯屏 Agent（绝大多数人的现状）

Agent 写 5 分钟，你放下刷视频的手机，花 2 分钟看一眼、敲个反馈，再等它写下一段。来回几轮，25 分钟一个任务。一天 19 个。

快了？快了。但只有 1.6 倍。因为你全程在盯着——Agent 写那 5 分钟你也占着，刷刷手机等它跑完。N = 1，没有并行。

Level 2：多窗口并行

你这次没玩手机，你给 Agent 更完整的上下文，让它能独立跑更久。每个任务你通常介入三次：

• 1 分钟 vibe 信息输入，Agent 启动工作一段时间。


• 2 分钟中间纠偏，因为你发现你的设想可能有偏差或者你表达有偏差，让他重新干


• 1 分钟收尾验收，共 4 分钟。

Agent 独立工作 30 分钟，周期 34 分钟。

理论上 N 可以开到很高，但随着窗口增多，你在"这个 Agent 改的是哪个模块来着？"上花的时间越来越多。

最优 N^* ≈ 12，有效并行 4.7 倍。一天 66 个，5.5 倍

理论值，这里没有给 \alpha，实际上你可能早上刚喝完咖啡能够达到这个强度，下午就累完了。而且实际的并行会给你带来：不同端口的冲突，数据库冲突（Worktree 的并行实际还没法隔离完整的开发环境），你需要一个工具能够立马知道哪个Agent跑完了，

Level 3：自动化部署（省人类一分钟，多做 15 个任务）

用脚本自动化或者提示词或者 Harness Engineering 或者 CI，达到自动切分支/Worktree、跑测试、部署预览环境，达到点开预览链接就能看到效果。

中间那次纠偏从 2 分钟省到 1 分钟（你不再需要手动跑命令确认状态，Agent 自己搞定了）。人类介入变成 1+1+1 = 3 分钟

Agent 多自主跑 3 分钟，周期 36 分钟。

自动化只往前走了很小的两步：

• 让每次介入更短、更标准化，所以 α 增长更慢；


• Agent 自主运行时间更长，调度更平滑，η 衰减更慢。

**最优 N^* ≈ 15，有效并行 6.1 倍。一天 81 个，6.8 倍

Level 4: Plan → Execute → Deploy 流水线

最终的理想：把人类的角色从"过程中反复纠错"变成"开头花 5 分钟做好规划"。Agent 拿到清晰的 plan 后自主执行 45 分钟。全流程端到端，AI自动编码、测试、部署，全自动零打断。周期 50 分钟。

虽然前面的计划时，5 分钟比 3 分钟长，但其实就类似于Planning Mode，需要你花一定时间设计，跟AI沟通好需求，计划好之后再让 AI 开始干，完全handoff。

这 5 分钟的贡献在于：

1. 
   

   α 增长最慢：每次你做的事都是"规划"，认知模式统一，切换成本比较低

   
   


2. 
   

   η 衰减最慢：45 分钟的独立运行时间，调度几乎不存在冲突

   
   


3. 
   

   N* 被推到最高：你可以同时管理远多于其他模式的 Agent

   
   

最优 N* ≈ 25，有效并行 10 倍。一天 96 个任务——但每个任务比 Level 2 大 50%。

自动测试的时候，Harness Engineering 可以完善测试和各种代码规范，尽可能将代码推向可维护性高的方向发展（也免去后期经常清理代码的烦恼）。但是会带来：运行测试时间更长，Agent等待时间更久，并行高带来的合并冲突概率上升。

换算成 Agent 总工时：72 小时。一个人的 8 小时，撬动了 9 倍的 AI 劳动力。

Claude 提供了下面的图表：

个人实践

假如说个人希望能够提高效率，减少切换上下文带来的大脑疲惫的感觉，可以尝试几个点。

回想你最近的做的项目：

• 是否有每次都提，但是代码规范没落地，需要你每次介入手动改的？


• 是否有审核 PR 的时候，切分支，开服务打断你当前工作的？


• 是否经常"轮询"各个终端窗口，看哪个Agent跑完没的？


• 是否有Agent说做完了，但是一启动炸了，你手动找报错日志给 Agent，Agent 问你要不要改，你回 OK 他才去改的？

上述各类情况都需要正确配置 Skills，Harness Engineering 来解决，最大化 Agent 连续工作时间，最小话人类介入时间，才能达到效率最优。

1. 规范你与Agent交互的方式，先 Plan再Execute能够提高很多效率。而且写完再修改消耗2倍token。尽可能让 Agent 在你的项目里面达到一击命中的感觉。（后端大概率可以，前端仍然缺少有完美品味以及测试方式让 Agent 100%达到你的需求，毕竟文本难以描述图像）


2. 给你的 Agent 配置 Skill，无论如何都要实现完成即部署，剩下你1分钟的打断时间。


3. 做好测试，将你的需求转化为测试，避免回归，避免描述不准确。测试对Agent来说是绝对的第二信源。（第一信源是你的prompt），如果让需要被修改的代码作为信源，会导致很多混乱！


4. tmux或者 zellij 多开窗口，而不是用vscode的terminal。实时查看进展，避免轮询。

我自己在使用 OpenASE 完成这个过程，自己也在摸索当中：

状态设计：Todo 放后端任务，Frontend 放前端任务。额外增多 Preview Deploy 在 Coolify 环境中部署独立的服务供我测试前端交互以及基本逻辑正确。

Workflow设计：后端使用 Codex，前端使用 Claude Code，一个 ticket 直接流转：

• 后端开发者（Codex+后端测试，Domain 100%覆盖率）：Todo->In Progress->Frontend


• 前端开发者（Claude code+DESIGN.md Skill）：Frontend->Frontend In Progress->Preview Deploy


• 部署运维员（Codex加Coolify Skill）：Preview Deploy->In Review


• 人类（大脑）：In Review->Merging，不通过放到 Rework


• 合并（Codex）：Merging->Done

Omx 也可以这么玩：

• $deep-interview → 需求澄清


• $ralplan → 方案审批


• $ralph → 单一负责人持续推进


• $team → 并行团队执行