Anthropic 把公司里的 Agent 工时算出来了。到今年 8 月，员工亲自驱动的交互式 Agent 运行时长，已经是人类工时的 6 倍。

更扎眼的不是 6 倍。

他们估算，如果一个非技术岗位的人认真读完自己那些交互式 Claude 会话产出的内容，阅读本身会吃掉超过半个工作周。于是，一个很反直觉的场面出现了。模型越来越能干，人却越来越像系统里最慢的那一环。

这份 10 月 16 日发布的 Anthropic 内部研究，给我的冲击不在「AI 会不会替代人」这个老问题。它把另一个更具体、也更接近工程团队日常的问题摊在桌上，Agent 的产能开始成批涌来时，谁来决定哪些值得看、哪些可以放行、哪些必须停下来？

很多团队还在为「要不要接入一个 Coding Agent」开会。前沿团队已经在处理另一件事，如何不被自己的 Agent 团队淹没。

这不是一个人配一个助手，而是一人带一支看不见的队伍

先把报告里的数字摆清楚。研究覆盖了 Anthropic 的雇佣记录、Agent 使用数据、产出指标、内部沟通、日历和招聘决策，并补了 17 次员工访谈。它不是一份对外问卷，所以样本有局限，但也正因为数据来自真实工作流，细节比泛泛谈生产力有意思得多。

到 2026 年 3 月，Anthropic 的自主与交互式 Agent 总工时首次超过人类工时。到 8 月，只算员工亲自发起的交互式 Agent，会话里汇总的子 Agent 工时也达到员工工时的 6 倍。

这里的工时不是凭空捏出来的 KPI。研究者把 Agent 推理和工具调用的活跃时间算进去，超过 30 分钟的等待不计入。人类则按每周 40 小时折算。这个口径当然不能拿去衡量每一家公司的产出，但它足够说明一件事，Agent 已经不只是「帮我补个函数」的工具，它在持续运行，在并行推进任务，在等人类回来拍板。

你想想看，一个 Java 服务要补测试、清理遗留分支、排查日志、更新接口文档、梳理监控告警。以前这些事排进 sprint，靠人一个个往前推。现在可以开出多个 Agent 会话，让它们同时干活。速度变快了，可每一个会话又都在吐回 diff、结论、风险提示和追问。

以前工程师的稀缺能力，是把代码写出来。

现在越来越像是把有限注意力投到正确的地方。

报告里有个比喻很准确。一位工程师说，管理 Agent 像带一群小孩。有人只是要你打开果汁盒，有人手指划破了，两者都会用同一种紧急程度向你喊话。Agent 不会天然理解优先级，它们只会把局部任务完成后的不确定性推回给人。

坦率的讲，这才是多 Agent 落地最容易被低估的成本。不是 token 账单，也不是模型选型，而是注意力调度。

代码变多了，不等于团队已经更快了

Anthropic 给出的生产力数字很猛。工程师的人均代码提交速度，约为半年前的 5 倍。研究跟踪了 192 名采用 Coding Agent 的工程师，并和 74 名未采用者比较。采用后，新增代码量显著上升。

但他们没有停在这个看上去很漂亮的结论上。研究者也承认，更多代码不等于更好的代码，更不等于业务价值。他们随后比较同一个人、同一个月份、同一个代码目录中由人直接写出的提交和由 Agent 写出的提交，观察 90 天内的删除、因 bug 修复导致的删除、整体 revert、lint suppression、跳过或允许失败的测试等代理指标。

在这些指标上，没有发现显著差异。

这个结论要小心读。它不等于 Agent 代码质量已经和人完全一样，也不能推出所有代码库都适用。研究本身就写得很克制，很多难发现的错误不在这些指标里，采用工具的人也未必是随机抽样。

可它仍然戳破了一个偷懒的反驳。我们不能只靠「AI 写的代码不可靠」来拒绝改变工作方式。至少在 Anthropic 自己的代码环境里，问题已经从「能不能写」转到了「怎样验证、怎样集成、怎样让产出不制造新的队列」。

这对 Spring 或 Java 团队尤其现实。业务系统往往不是代码写出来就结束了，还要过领域规则、兼容历史数据、事务边界、灰度开关、可观测性和线上责任。Agent 很擅长把局部实现铺开，却不天然拥有架构决策的上下文。

我一直觉得，工程团队最危险的误区，是把 Agent 当成更快的初级开发者。它更像一个执行速度极高、上下文时好时坏、还会不停向你提交待审事项的协作者。你如果只给它一个 issue，然后期望靠 Code Review 兜底，最后得到的很可能不是效率，而是一条更长的审查队列。

真正的新岗位叫做管理 Agent 的工作

Anthropic 在报告里把这类事情叫作 meta-work。不是直接写某个功能，而是写 Skill、计划、评审规则、监控面板和运行说明，让 Agent 更稳定地完成别的工作。

这个变化可以被量化。员工交互式 Claude 会话中，属于 meta-work 的比例从 2025 年秋天的 10% 升到 2026 年春天的 22%。一年内，面向 Agent 的书面常驻指令从几百条增长到 8500 条。

这组数很容易被读成「Prompt 工程又回来了」。我不这么看。

成熟的 meta-work 不是把提示词写得花哨，而是把原先藏在资深工程师脑袋里的判断，做成一个可执行、可观测、可迭代的系统。比如为不同仓库定义变更边界，给 Agent 一个能跑起来的验证环境，让一个 Agent 审另一个 Agent 的输出，给高风险操作设置人类批准点，再用 dashboard 看失败类型和返工率。

这些东西听起来没有生成一个页面酷，却是 Agent 能否进入生产的地基。

对做 LangGraph 或内部 AI 平台的人来说，工作重点也会跟着挪。图里有多少节点、模型切得多不多，当然重要。更重要的是状态如何留存、每一步有什么可验证的产物、失败后能否收敛、谁有权限推进到下一步。一个没有可观测性的 Agent graph，运行得越快，出问题时越像高速旋转的洗衣机。

说真的，很多 Demo 在这里就结束了。它可以一口气把五个子任务做完，却没有告诉你哪个结论基于什么输入，哪个文件被修改，哪个外部动作已经发生。人类只好把所有结果重新看一遍。所谓自动化，最后退化成了更贵的阅读器。

人类成了瓶颈，不代表人类变得不重要

报告里最容易引发焦虑的描述，是交互式 Claude 会话大约 80% 的墙上时间处于等待人类输入的状态。工程师直接说，人类正在 bottlenecking the agents。

这个判断没错，但别急着把它翻译成人类没有价值。

Agent 等待的通常不是「帮我把逗号改成句号」。它在等优先级、等边界、等资源分配、等一个跨团队的取舍。研究里的员工也提到，追一个 bug 往往会挖到组织协作、系统性技术债和治理问题，这些要靠人把相关方拉到一起决定。即使技术岗位，会议时间一年里也增加了 16%。

反正我觉得，这正好说明了一个残酷但有用的事实。实现成本被压低之后，决策质量不会自动提高，反而会被放大。

以前一个模糊决定的代价，是两个人花两天做错一版。现在可能是十个 Agent 在半天内各做一版，把十倍的错误实现堆在你的 PR 列表、测试环境和消息频道里。模型没有消除管理，只是让管理从排期管理变成了认知带宽管理。

这块需要注意一下。不要用「人审」三个字把问题糊过去。真正有效的人类介入需要有层级。

  • 低风险、可逆、可自动验证的工作，例如补测试、格式修复、依赖升级后的编译修复，可以让 Agent 自动闭环
  • 有明确规格但会影响多个模块的工作，例如接口改造、数据迁移脚本、权限规则，要让人审计划和验收证据，而不是逐行审每一句生成代码
  • 高风险、难逆转、涉及产品取舍或生产权限的工作，人要在动作前介入，不能等 Agent 做完再看报告

这不是保守。恰好相反，它是在为并发争取空间。你不能让人盯住每一个细节，得把人的注意力留给真正需要判断的节点。

先建队列，再买更多 Agent

如果你的团队正在从 Copilot 走向 Agent，我会建议不要从「给每个人开多少并发」开始。先画一张注意力流图。

把一次 Agent 任务从输入到交付拆开，看四件事。

第一件事，是入口。 谁提出任务，任务有没有足够上下文，Agent 能访问哪些仓库、环境和工具。模糊任务不是 Agent 的燃料，是返工的种子。

第二件事，是证据。 每一步不要只输出「完成了」，要输出 diff、测试结果、关键假设、外部调用记录和未解决项。把结果压缩成人能快速判断的证据包，而不是长篇运行日志。

第三件事，是升级机制。 Agent 不确定时应该停在哪里，什么错误可以重试，什么错误必须交给人。没有这层，失败会在后台悄悄变成半成品，然后被下一步当作事实继续放大。

第四件事，是回收。 哪类任务经常被 reject，哪些指令产生最多追问，哪些验证最能挡住错误。把这些沉淀成仓库规则、评审清单或可复用的 Agent Skill。否则每一次成功都只是一次性的运气。

这套做法听起来像 CI/CD 的老话。确实很像。过去我们把人工发布变成流水线，不是因为服务器跑得慢，而是因为部署的风险需要被拆解、验证和回滚。今天 Agent 的问题也是同一个逻辑，只是流水线产出的不再只有二进制包，还有代码、决策建议、文档和外部动作。

回到那 6 倍工时。它不是一个值得拿去宣传的神奇数字，更像一盏警示灯。Agent 的生产率已经可以超过一个人的阅读、判断和协调能力，而组织的默认流程还没为这种不对称准备好。

我自己的感受是，未来一段时间最稀缺的，不会是会不会给模型下指令的人。会是能把 Agent 产能变成可靠交付的人。他们知道何时放手，何时收紧，知道把什么写进系统，什么必须留在人的讨论里。

Agent 不会先取代工程师。

它会先逼工程师承认，写代码从来不是工作里最难的部分。

参考资料