人机协作效率模型：为何有人能同时盯20个Agent

背景

随着 AI 编码 Agent 的能力快速提升，如何高效地与多个 Agent 协同工作成为开发者关注的核心问题。许多人在实际使用中发现自己只能同时盯住 1–2 个 Agent，而一些“大佬”却能同时管理 10–20 个甚至更多。本文来自 LINUX DO · AI 社区的一篇帖子，作者通过建模分析人类注意力与 AI 并行性的矛盾，提出了不同工作模式下的最优并行数量（N*），并分享了个人实践中的自动化工具与流程设计，旨在帮助开发者最大化人机协作效率。

核心内容

人类注意力是串行的，AI Agent 是并行的

人类的注意力本质上是串行的——同一时刻只能专注一件事。而 AI Agent 可以无限并行，互不干扰。因此，人机协作的效率受到人类认知切换成本的限制。

效率模型：T_eff(N) = N × (1 − α(N)) × η(N)

• N：同时运行的 Agent 数量，理论上无上限。
• α(N)：认知切换成本，随 N 增大而增大。管理 3 个 Agent 时切换成本很低，管理 20 个时仅回忆上下文就消耗大量精力。
• η(N)：调度效率，范围 0–1，随 N 增大而降低。Agent 越多，同时找你的概率和无人需要你的概率都在上升。

存在一个最优并行数 N*，超过该值后增加 Agent 反而降低总产出。基础设施越好，N* 越高。

五种工作模式及效率对比

Level 0：纯人类编码

• 自己写，40 分钟一个任务。8 小时完成 12 个任务。

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

• Agent 写 5 分钟，人类花 2 分钟查看并反馈，来回几轮，25 分钟一个任务。一天完成 19 个，仅为 1.6 倍。因为 N=1，没有并行。

Level 2：多窗口并行

• 人类给 Agent 更完整的上下文，每个任务介入 3 次：1 分钟输入，2 分钟中间纠偏，1 分钟收尾验收，共 4 分钟。Agent 独立工作 30 分钟，周期 34 分钟。
• 最优 N* ≈ 12，有效并行 4.7 倍，一天完成 66 个（5.5 倍理论值）。但认知负荷高，下午容易疲劳，且存在端口冲突、数据库冲突等实际问题。

Level 3：自动化部署

• 利用脚本、提示词、Harness Engineering 或 CI 自动完成切分支、跑测试、部署预览环境。中间纠偏从 2 分钟减到 1 分钟（不再手动跑命令确认状态）。人类介入减少为 1+1+1=3 分钟，Agent 自主运行时间增加 3 分钟，周期 36 分钟。
• 自动化使每次介入更短、更标准化，α 增长更慢；Agent 自主运行时间更长，η 衰减更慢。最优 N* ≈ 15，有效并行 6.1 倍，一天完成 81 个（6.8 倍）。

Level 4：Plan → Execute → Deploy 流水线

• 人类角色从“过程中反复纠错”变为“开头花 5 分钟做好规划”。Agent 拿到清晰 plan 后自主执行 45 分钟，全流程自动编码、测试、部署，零打断。周期 50 分钟。
• 5 分钟规划让 α 增长最慢（认知模式统一），η 衰减最慢（45 分钟独立运行，调度几乎无冲突），N* 被推到最高约 25，有效并行 10 倍，一天完成 96 个任务（每个任务比 Level 2 大 50%）。换算成 Agent 总工时约 72 小时，撬动 9 倍 AI 劳动力。
• 代价：测试时间变长，Agent 等待时间增加，并行高带来的合并冲突概率上升。

个人实践建议

• 回顾项目：是否有重复的代码规范落地需要手动介入？是否有审核 PR 时切分支、开服务打断当前工作？是否经常轮询终端窗口看 Agent 跑完没？是否有 Agent 说做完但启动失败，需要手动找日志再让 Agent 修改？
• 正确配置 Skills 和 Harness Engineering，最大化 Agent 连续工作时间，最小化人类介入时间。
• 先 Plan 再 Execute，能提高效率，且避免写完再修改消耗 2 倍 token。后端项目更容易一次命中，前端因文本难以描述图像仍存在挑战。
• 给 Agent 配置 Skill，实现“完成即部署”，节省 1 分钟打断时间。
• 将需求转化为测试，避免回归和不准确描述。测试对 Agent 来说是绝对的第二信源（第一信源是 prompt）。
• 使用 tmux 或 zellij 多开窗口，而不是 VS Code 的 terminal，实时查看进展，避免轮询。

工具实践：OpenASE 与 Omx

作者使用 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 → 并行团队执行

关键要点

• 人类注意力是串行的，AI Agent 是并行的，人机协作效率受认知切换成本（α）和调度效率（η）共同制约，存在最优并行数 N*。
• 五种工作模式效率逐级提升：Level 0（纯人类，12个任务/天）→ Level 1（盯屏，19个，1.6倍）→ Level 2（多窗口，66个，5.5倍）→ Level 3（自动化部署，81个，6.8倍）→ Level 4（Plan→Execute→Deploy，96个，10倍）。
• 自动化部署和流水线设计的关键在于：减少人类介入时间、标准化每次介入、延长 Agent 自主运行时间，从而降低 α 增长和 η 衰减。
• 个人效率提升要点：
  • 识别并消除重复手动介入（如代码规范、环境切换、轮询）。
  • 先 Plan 再 Execute，避免 token 浪费和认知碎片化。
  • 配置 Skill 实现“完成即部署”，减少打断。
  • 将需求转化为测试，作为 Agent 的第二信源。
  • 使用 tmux/zellij 等终端多窗口工具，而不是 VS Code 的 terminal。
• 工具如 OpenASE 和 Omx 可以通过状态设计和工作流编排，实现多 Agent 的自动流转与人类审批，提升并行效率。

意义与影响

该帖子从认知科学和工程效率的角度，系统性地揭示了人机协作中“瓶颈在人类”这一核心矛盾，并给出了可量化的模型和阶梯式改进路径。对于正在使用