让 Agent 干活之后，人开始忙着管理 Agent

一个 Coding Agent 连续运行了十一小时，执行了 16,892 项单元测试，拿出了六项优化建议。最后真正合入的只有两项。

这是 Google 本周公开的一次实际工程实验。我第一眼注意到的是 Agent 已经能在一个大仓库里持续推进这么久，随后才意识到另一个细节：它生成候选改动的速度，和团队决定哪些改动可以交付的速度，是两回事。

同一周，Anthropic 公布了一份内部组织研究。读完之后，我更关心的问题变成了：当越来越多任务交给 Agent，人的注意力究竟花在什么地方？

10 月 16 日，Anthropic 发布 How employment is changing at Anthropic。这份报告结合了内部工具使用、工作产出、招聘和员工访谈，研究 AI 深度使用以后，工作到底发生了什么变化。

报告提到，到 2026 年 8 月，员工使用的交互式 AI Agent 工作时长总量已经达到人类员工工作时长的约六倍。注意，这是一种使用遥测的工作时长统计，不能直接换算成“六倍的人类生产力”，更不能理解为每一小时 Agent 工作都创造了同等价值。

更值得关注的是“元工作”（meta-work）的增加。Anthropic 抽样分析了约 2,000 条简短的 Claude 会话摘要，判断这些交互是否在为其他 Agent 编写 Skill、制定计划、构建监控或组织评审。报告中，平均每位员工的交互式 Claude 会话里，被归为元工作的比例从 2025 年秋季约 10% 上升至 2026 年春季约 22%。

10%→22% 是会话占比的变化，不是员工工时占比，更不能说明工作总负担增加了 12 个百分点。 它真正表明的是：在这家公司的工具使用记录中，“管理和改善 Agent”的交互变得更加常见。

报告还观察到，员工越来越多地编写 Agent 指令、搭建监控面板、检查执行结果。人和人之间的沟通没有因为 Agent 出现就消失：中位数员工的会议时间同比增长约 20%，技术个人贡献者的会议时间也增长了约 16%。

这些变化不能简单归因给 AI。Anthropic 同期高速扩张，部门组成、岗位结构和业务复杂度都在变化。报告本身也讨论了这些混杂因素。因此，这些数据更适合作为一个高强度使用 Agent 组织的观察窗口：注意力、评审能力和跨人协作可能成为新瓶颈，而目前还无法量化其中有多少由 AI 单独造成。

这也解释了为什么“同时跑五个 Agent”并不天然等于“交付速度变成五倍”。产物会更快堆积，判断与验收却仍然占用人的认知资源。

同一周，Google 分享了一次用 Gemini 4 Argon 优化约二十万行 Python 代码库的实践。Agent 在 ADK 项目上连续工作十一小时，跑完 16,892 项开源单元测试，最终给出六项性能优化方案。

维护者审查后，只上线其中两项。其余四项为什么没有被采纳？有的依赖脆弱的运行时状态，有的触碰私有库内部实现，有的只在合成基准上有效，还有的让代码变复杂却没有改善独立评测的端到端性能。

还有一个很有意思的细节：Agent 的一项改动让所有公开单元测试通过，却触发了 25 个 Google 内部测试目标失败。维护者最终选择了兼顾兼容性的实现。

如果只看“跑了多久、调用了多少工具、通过多少测试”，这次执行很容易被认定为成功。真正的工程收益，却是经过评审、权衡、验证以后留下的那两项优化。

在这次实验里，Agent 负责扩大探索范围、生成候选实现，并完成大量测试；维护者负责结合仓库规范、兼容性和真实收益做最终取舍。

图：Anthropic 的 10%→22% 是元工作会话占比变化，不是员工工时；Google 的六选二是特定工程案例。两组证据不能直接换算成 AI 对生产力的净影响。

更进一步的问题是：其中有多少审查可以提前变成约束和独立验证，减少人反复筛选明显不合格方案的时间？

过去我们常按专业角色交接：产品写需求，研发做设计和实现，测试负责质量，运维保障上线。Agent 进入以后，同一个人可能同时发起任务、推进编码、检查结果，还要在必要时联系其他领域的同事。

这不等于“所有人都变成管理者”。更贴近实际的变化，是任务负责人可能同时承担更多的任务定义、过程判断与结果验收。如果工具和协作机制跟不上，人就会成为多个 Agent 争抢的稀缺资源。

在我看来，有三类负担值得优先通过系统消化。

首先，减少重复交代背景。已经确认的需求条件、工程约束和历史决策，应该能随任务流转，而不是每换一个 Agent 或跨一次会话就重新解释。

其次，让执行情况可读。需要汇报的是“目标还差什么、有哪些风险、证据在哪里、下一步谁决策”，而不仅是一条持续滚动的调用日志。

最后，把独立验证前移。对容易自动核验的部分，让系统持续检查，尽量不要把所有候选方案都直接推到人面前。人的评审时间应该更多留给技术取舍、业务影响和无法被既有规则覆盖的情况。

本周阿里云 AgentCore 的一篇端到端研发实践，也提到基于工序契约、风险门禁和独立质检安排 Agent 交付。它与 Anthropic 的研究、Google 的实验出发点不同，但都说明了一件事：把任务交给 Agent 后，明确交接条件和验证责任仍然很重要。

Anthropic 报告称，其技术部门初级岗位员工占比从 2025 年初约 21% 降至 14%，初级技术招聘占比从 27% 降至 9%。这些数字来自一家公司，不能直接推成整个行业的变化，也不能认定变化全部由 AI 导致。

但问题本身值得讨论。过去，很多工程师是在修 Bug、读代码、写测试和跟着评审的过程中逐步形成判断力。如果初级执行任务被大量交给 Agent，团队是否还在为新人提供理解系统和承担责任的成长路径？

未来对判断力的要求提高，与新人获得训练机会减少，可能同时发生。组织如果只考核短期交付效率，容易忽略这笔更长期的账。

Anthropic 的样本有高速增长公司的特殊性，Google 的实验也只是一次性能优化任务。两者还不足以支持“AI 必然让研发人员更忙”这样的结论。但它们共同指向一个可观察的问题：Agent 能连续执行多久，和一个需求最终要耗费多少人力，仍然是两套指标。

图：本文提出的衡量框架。评价 Agent 收益时，既记录交付周期与缺陷，也记录人在任务准备、审查、修复和验收中的投入。

接下来我更想在真实需求里统计：工程师花了多少时间解释背景、查看运行、做方案取舍、修复回归和最终验收；这些投入能否随着经验积累与工具改进而下降。只有把人的这部分工作也放进交付账本，才能判断 Agent 的规模扩张究竟带来了多少净收益。