过去讨论AI Agent，大家最关心的通常是：

模型还能不能更强？

Codex一次能跑多久？

能不能同时开更多Agent？

一个工程师能不能同时让5个、10个甚至更多Agent工作？

从表面看，多Agent时代最重要的资源似乎应该是：

模型能力、Token、算力和并发。

但当Agent真正进入工程工作流以后，一个非常反直觉的问题开始出现：

Agent越多，人反而越忙。

Agent A正在修Bug。

Agent B等待Approval。

Agent C测试失败。

Agent D已经完成，需要Review。

Agent E发现新的问题，希望扩大修改范围。

如果每一个Agent都需要人不断查看：

现在做到哪里？
为什么失败？
要不要继续？
这个Diff能不能接受？
要不要批准这个动作？

那么即使Agent执行速度提高10倍，人类最终仍然可能成为整个系统最慢的一层。

OpenAI在2026年公开Symphony时，就披露了一个非常有代表性的观察：工程师通常可以比较舒服地同时管理3—5个Codex Session，再往上，频繁的上下文切换就开始明显影响效率。团队最终发现，真正的系统瓶颈已经变成了 human attention——人类注意力。

这可能是多Agent时代比“模型又提升多少”更值得关注的变化。

---

一、单Agent时代，人类注意力几乎不是问题

只有一个Agent时，工作模型非常简单：

Human
↓
Agent
↓
Result

人可以一直跟着它。

Agent运行命令。

你看一眼。

测试失败。

你继续指导。

修改完成。

你检查Diff。

这种模式虽然需要人工参与，但注意力只有一个方向。

可以理解为：

Human Attention
=
1 Task

所以Agent再复杂，人仍然容易保持上下文。

但多Agent以后完全不同。

假设同时运行5个任务：

Agent A
Auth Refactor

Agent B
Payment Bug

Agent C
Test Expansion

Agent D
Dependency Upgrade

Agent E
PR Review

每个Agent都有独立的：

目标；

执行状态；

历史决策；

代码变化；

失败原因。

此时人类需要维护的不再是一个Context。

而是：

5个不断变化的Context。

真正昂贵的动作开始从：

写代码

变成：

重新进入某个任务的状态。

---

二、多Agent最昂贵的操作，可能是“重新理解发生了什么”

假设Agent A运行了30分钟。

你去处理Agent B。

十分钟以后回来。

Agent A告诉你：

已修改认证逻辑，但Refresh Token测试仍然失败，我认为可能需要调整Cookie策略。

这句话看起来很简单。

但为了做出正确判断，你必须重新恢复很多信息：

最初目标是什么？

Agent已经改过哪些地方？

为什么选择这个方案？

之前排除了什么？

当前测试失败是不是原有问题？

修改Cookie会不会超出任务范围？

这就是：

Context Reconstruction Cost。

Agent处理任务时，它一直在任务上下文里。

人却不断在多个任务之间切换。

于是出现一个有意思的反转：

Agent拥有连续上下文，人类反而拥有碎片化上下文。

当Agent数量增加以后，这种重建成本会越来越明显。

OpenAI在Symphony实践中描述的正是这种现象：工程师需要不断在多个Session之间切换、查看输出、重新引导卡住的Agent，最终生产率反而开始下降。

---

三、所以“同时运行更多Agent”不是一个完整的效率指标

很多Agent产品喜欢展示：

1 Agent
↓
5 Agents
↓
10 Agents

看起来并发越高越好。

但真正的生产率应该更接近：

Agent Throughput
-
Human Coordination Cost

假设一个工程师：

以前一天完成5个任务。

现在10个Agent理论上能够完成50个任务。

但如果这50个任务产生：

20次Approval；

15个失败；

30个Diff等待Review；

8个任务需要方向判断；

那么人类未必有能力真正消费这些结果。

这时候系统会出现一种新的排队：

过去是：

Tasks
↓
等待开发者实现

未来可能变成：

Agent Results
↓
等待人类Review

瓶颈只是从：

Implementation Queue

移动到了：

Attention Queue。

OpenAI在Harness Engineering的实践中也明确把“human time and attention”称为真正稀缺的资源；随着Agent代码吞吐量增加，他们随后遇到的瓶颈之一就是人类QA能力。

---

四、这意味着未来不能让人“监督每一个Agent”

如果多Agent系统的设计逻辑仍然是：

Agent执行一步
↓
人检查一步
↓
Agent继续
↓
人再次检查

那么Agent数量永远无法真正扩张。

因为：

10 Agents
=
10份监督工作

最终人只是从：

写代码的人

变成：

盯AI写代码的人。

这其实没有真正解决规模问题。

所以真正可扩展的Agent系统必须发生一个变化：

从：

Continuous Supervision

转向：

Exception-Based Supervision。

正常任务：

Agent
↓
Execute
↓
Verify
↓
Complete

不需要人持续介入。

只有异常情况才进入：

Agent
↓
Cannot Resolve
↓
Escalation
↓
Human

人类注意力就从：

监控全部工作

转变成：

处理系统自己无法决定的少数问题。

这也是为什么上一层的Control Plane会越来越重要。

Control Plane真正节省的不是Agent时间。

而是：

Human Attention。

---

五、未来好的Agent系统，应该主动“压缩”给人的信息

今天很多Agent完成任务后，会输出非常长的过程记录：

读取了什么文件；

运行了什么命令；

失败过几次；

修改了什么代码；

为什么做这些事情。

这些信息对于Audit非常重要。

但如果每个Agent都把完整过程直接交给人，

10个Agent一天可能产生几万行日志。

人根本无法消费。

所以未来系统需要同时存在两层信息。

第一层：

Machine Evidence。

保存完整：

Logs
Terminal
Diff
Test
Decision History

用于：

追踪；

审计；

回滚。

第二层：

Human Summary。

只告诉人：

Goal
Status
Risk
Evidence
Decision Needed

例如：

Task：
修复支付接口超时。

Status：
已完成。

Evidence：
12项相关测试通过。
Build成功。

Risk：
未验证生产环境第三方支付服务。

Human Action：
Review 3个核心Diff。

这比让人阅读一整段Agent聊天记录有效得多。

真正好的Agent系统应该做的是：

把大量机器行为压缩成少量高价值的人类决策点。

---

六、Review本身也必须从“看所有代码”转向“看高风险变化”

Agent吞吐量越来越高以后，另一个问题会出现：

人还能不能Review所有代码？

OpenAI的Agent-first工程实践已经遇到类似情况。随着Codex生成代码的速度提高，团队逐渐把大量Review工作转向Agent-to-Agent Review，人类并不一定需要查看每一个Pull Request；他们的目标就是把有限的人类判断力投入到更高价值的位置。

这意味着未来Review也可能分层。

Low Risk

例如：

文档；

小范围测试；

机械性重构。

可以：

Agent Review
+
Automated Test

直接完成。

Medium Risk

例如：

业务逻辑修改。

可能：

Agent Review
+
Test
+
Human Spot Check

High Risk

例如：

认证；

支付；

权限；

数据库；

生产基础设施。

必须：

Human Review

这里真正发生的是：

Review Attention Allocation。

不是所有代码都值得获得同等的人类注意力。

---

七、未来高级工程师的核心能力，可能变成“注意力分配”

过去高级工程师最大的价值之一是：

知道应该怎么写。

Agent越来越强以后，这种价值不会消失。

但会增加一个新的能力：

知道什么值得自己亲自看。

例如同时有20个Agent结果。

工程师需要判断：

哪个只是普通测试补充？

哪个修改了认证边界？

哪个涉及架构变化？

哪个失败3次以后仍然没有收敛？

哪个Agent虽然测试通过，但Diff范围异常？

人类真正的工作开始像一个：

Attention Scheduler。

把有限时间分配到：

High Risk
High Ambiguity
High Impact
Irreversible Action
Architecture Decision

而不是平均分配给所有任务。

这也是为什么Agent时代的人类价值可能越来越集中在：

判断力。

---

八、人类注意力为什么比算力更难扩展？

算力有一个非常好的特点：

可以横向扩展。

任务多了：

增加机器。

Agent多了：

增加并发。

但人类注意力不一样。

一个工程师无法：

CPU × 10

也无法真正同时深入思考十个复杂工程问题。

所以Agent系统存在一个天然的不对称：

Agent Capacity
可以快速扩张

Human Attention
扩张非常慢

当模型能力持续提高以后，这个差距只会越来越大。

OpenAI的Codex产品也已经明显按照这种变化设计：官方把Codex in ChatGPT描述为Agentic Coding的“command center”，支持多个Agent跨项目并行执行，而Codex App从一开始就是为了让开发者能够同时管理多个Agent、独立线程和Worktree。

也就是说：

Agent已经开始规模化。

现在的问题变成：

人的注意力怎么不被规模化Agent拖垮？

---

九、所以未来Agent系统需要一个“Attention Architecture”

过去软件系统设计常讨论：

Compute Architecture。

Data Architecture。

Network Architecture。

多Agent时代可能还需要一个新的概念：

Attention Architecture。

它解决：

什么情况下需要人？

可以简单拆成四层。

第一层：Auto Execute

低风险、高确定性。

Agent直接执行

第二层：Auto Verify

执行完成后：

Agent
↓
Tests
↓
Policy
↓
完成

不需要人。

第三层：Human Review

存在较高风险：

Agent
↓
Evidence
↓
Human Review

第四层：Human Decision

涉及：

架构；

安全；

不可逆行为；

需求歧义。

Stop
↓
Human Decision
↓
Resume

最终形成：

Automation
        ↓
Verification
        ↓
Exception Detection
        ↓
Attention Routing
        ↓
Human Decision

这里最重要的已经不是：

多少Agent在运行。

而是：

每天有多少事情真正需要打断人。

---

十、一个成熟Agent系统的指标，可能是“中断人类多少次”

过去评价开发工具：

响应速度；

准确率；

代码通过率。

未来企业可能还需要一个非常有意思的指标：

Human Interruptions per Task。

例如系统A：

完成100个任务。

需要人工介入80次。

系统B：

完成100个任务。

只需要介入12次。

即使两个系统最终成功率相同，

B的可扩展性也会完全不同。

类似的还有：

Human Review Minutes / Task

Escalation Rate

Auto-Recovery Rate

Evidence Quality

Decision Density

这些指标真正衡量的是：

Agent到底释放了多少人类注意力？

而不是：

Agent自己工作了多久。

---

十一、真正值得追求的不是“Human Out of the Loop”

这里还容易走向另一个极端。

既然人类注意力是瓶颈，

是不是应该彻底把人拿掉？

不一定。

真正合理的方向不是：

Human Out of the Loop。

而是：

Human at the Right Loop。

例如：

让Agent决定：

怎么修一个普通测试。

没有问题。

但让Agent自己决定：

是否改变公司核心权限架构，

就完全是另一回事。

所以目标不是：

所有事情都自动化。

而是：

把人放到最有价值的决策位置。

OpenAI在Harness Engineering总结中也明确表示，他们仍在探索“哪些地方最值得加入人类判断，以及怎样把这些判断编码进系统，让价值持续累积”。

这可能才是多Agent工程真正成熟的方向。

---

十二、Agent越强，人类工作的粒度反而会越来越高

过去工程师操作：

Line
Function
File

后来操作：

Feature
Bug
PR

Agent继续增强以后，人可能越来越多地操作：

Goal
Policy
Architecture
Priority
Exception

也就是说人的工作单位正在逐渐变大。

从：

How

转向：

What / Why / Whether。

Agent负责：

怎么完成。

人类负责：

做什么、为什么做、结果能不能接受。

这也是为什么OpenAI在Agent-first工程实践里把工作方式总结为：

Humans steer. Agents execute.

这句话真正重要的地方不在“Agent执行”。

而在：

Human Steer。

---

十三、从多Agent到“组织级Agent系统”

如果把前面两篇放在一起，会出现一个很清晰的演化过程：

第一阶段：

Human
↓
Single Agent

第二阶段：

Human
↓
Multiple Agents

很快出现：

Attention Bottleneck。

于是需要：

Human
↓
Control Plane
↓
Multiple Agents

再往后：

Control Plane负责普通调度和异常检测。

人只接受：

Decision Queue

最终变成：

Human Decision Layer
          ↓
Attention Router
          ↓
Control Plane
          ↓
Agent Runtime
          ↓
Agents

这时候才真正接近：

组织级Agent系统。

因为人不再直接管理每一个Worker。

系统开始替人管理Worker。

---

十四、未来团队真正稀缺的可能不是Agent，而是高质量判断

Agent可以复制。

Prompt可以复制。

模型调用可以扩容。

但真正难复制的是：

一个资深工程师看到一个Diff以后，能够判断：

这个架构会不会半年以后失控？

这个权限是不是开得过大？

这个测试虽然通过，但是否验证了真正需求？

这个Agent是不是解决了症状，却没有解决Root Cause？

这些判断，本质上都是：

Compressed Experience。

所以AI Agent越强，

人的价值可能越集中到：

Architecture
Judgment
Risk
Priority
Taste

这也是为什么Agent并不一定让资深工程能力变得不重要。

反而可能让：

高质量判断的杠杆变得更大。

---

最后

多Agent时代最容易产生的误解之一，就是：

Agent数量越多，生产率越高。

真正的关系更可能是：

Productivity
=
Agent Throughput
×
System Coordination
÷
Human Attention Cost

Agent Throughput持续上升以后，

真正决定系统能否继续扩张的，会越来越是：

人类注意力能不能被保护起来。

所以未来最成熟的Agent系统，不应该让人同时盯着20个Agent。

而应该让20个Agent自己：

运行；

验证；

恢复；

汇总；

筛选异常。

最后只把真正需要判断的：

3个问题

交给人。

从这个角度看，

Control Plane真正的价值并不是管理更多Agent。

而是：

让更多Agent运行时，不需要同比增加人类注意力。

这可能才是多Agent时代真正的规模效应。

未来高级工程师的工作，也可能越来越不像：

同时操控更多AI。

而更像：

设计一个系统，让AI自己工作，只在真正需要人类判断的时候打断我。

当这一点实现以后，

AI Agent才真正从：

个人效率工具

走向：

可扩展的组织执行系统。