Enter your search text in the box above

Select a result to preview

Agent 时代团队不需要更多执行者

#type/article #area/management #area/ai

核心观点

一个技术管理者的日常困境

你给团队布置了一个明确的技术方案，不存在模糊地带。得到的反馈是："这样可能有问题，你确认一下所有细节。"

你的第一反应是：这些细节不正是你应该自己验证、然后给我结论的吗？第二反应是：算了，我用 agent 做可能更快。

如果你带过团队，这个场景大概率不陌生。执行力很强、能吃苦、遇到技术难点能一个个啃下来——但工作模式是：你告诉我每个细节，我来实现。遇到不确定性，默认上抛而不是自己闭环。

这类工程师不是能力差，而是把自己定位成了"指令的接收端"。在 AI agent 已经能可靠执行明确指令的今天，这种定位还有多少价值？

执行层的价值正在被压缩

这不是一个关于个人能力的判断，而是一个关于成本结构的事实。

以前，一个明确的技术方案从设计到实现，需要一个工程师花三天写代码、调试、部署。现在，同样的方案交给 AI agent，三小时可以完成初版，人只需要 review 和调整。

当执行的边际成本从"一个人三天"降到"几美元 token 费用"时，"能执行"就不再是稀缺能力。Matt Webb 说他现在"看代码的时间比以往任何时候都少，思考架构的时间比以往任何时候都多"。这不是 agent 让架构变重要了，而是 agent 把写代码的噪音过滤掉之后，架构的重要性终于被看见了。

Sia Partners 2026 年的研究发现，大多数组织使用 AI 只获得了 5-10% 的生产力提升，而顶尖组织达到了 20-60%。差距不在于谁用了更好的模型，而在于谁重新设计了工作流和治理结构。换句话说，瓶颈已经从"写代码"转移到了"做决策"。

这意味着团队中"你告诉我细节我再动手"的工作模式，恰好落在了 agent 最擅长的区间里。不是这些人变差了，是他们提供的价值被更便宜的替代方案覆盖了。

团队的最小单元正在重新定义

传统的技术团队结构是金字塔形的：一个技术负责人定方向，几个主管分模块，每个主管带几个执行者。信息从上往下流，代码从下往上交。

在 agentic engineering 的语境下，这个结构正在被压扁。LeadDev 2026 年 4 月的文章直接问了一个问题：AI 时代，团队规模还重要吗？

我的观察是，团队的最小交付单元正在从"1 个 lead + N 个执行者"演变为"1 个高 ownership 的人 + agent 集群"。这个"人"不是传统意义上的 leader——他不需要带人、不需要做绩效、不需要开周会。他需要的是：能定义问题、能在模糊地带做判断、能对结果负责。

而那些把自己定位成"指令接收端"的工程师，问题不是技术能力不够，而是没有把"在不确定性中做判断并承担结果"当成自己的职责。每次遇到模糊地带，默认行为是上抛——让上级来确认、来拍板、来承担判断错误的风险。

在没有 agent 的时代，这种模式是可以接受的，因为执行力本身就是价值。但当 agent 能替代执行时，剩下的只有判断力——而这恰恰是这类工程师缺失的。

"不如我自己做"是一个危险的陷阱

意识到这一点之后，很多管理者的第一反应是：既然 agent 能执行，我又能做判断，那我一个人 + agent 不就够了？

这个想法很自然，但很危险。

管理者觉得 agent 比团队成员快，有一个隐藏的原因：agent 直接读你的文档、你的 spec、你的代码库——它跳过了"口述背景"这个低带宽环节。而团队成员慢，不是因为他们笨，是因为他们要先听你讲半天才能获得 agent 天然拥有的上下文。

你在比较的不是人和 AI 的能力差距，而是文档驱动和口述驱动的效率差距。这是一个被上下文优势扭曲的效率幻觉。

更危险的是，这个陷阱是自我强化的：你觉得"不如自己做"→ 减少委派 → 团队成员得不到锻炼 → 能力差距进一步拉大 → 更加"不如自己做"。Russinovich 和 Hanselman 在 CACM 2026 的论文中把这叫做"senior boost / junior drag"——senior 用 AI 效率飙升，组织觉得 junior 没用，停止招聘和培养，5 年后发现没有 senior 可用。

还有一个容易忽略的点：agent 不会挑战你的假设。它执行得快，但它不会说"这个方案有问题"。团队成员的"笨问题"有时候恰恰是在帮你约束解空间。如果你把所有人都替换成 agent，你就失去了这个纠错机制——你会更快地走向错误的方向。

所以真正的杠杆不是"我一个人 + agent"，而是找到 2-3 个同样能驱动 agent 的人。每个人都是"判断者 + agent 集群"的节点，而不是你一个人变成单点故障。

判断力不是抽象的——它有具体的形态

说"团队需要有判断力的人"太笼统了。判断力在 agent 协作中至少有三种具体形态：

导航者：决定探索方向。当 agent 可以暴力搜索解空间时，人的价值不在于亲自搜索，而在于约束搜索范围。"不要往这个方向走了，换一条路"——这个决策 agent 做不了，因为它没有全局视角，也没有业务直觉。导航者的核心工作是约束解空间，而好的架构设计本质上就是一种约束。

裁判：判断结果是否正确、是否有意义。Agent 能生成方案，但它无法判断这个方案在当前业务上下文中是否合理。Agent 可以写出一个技术上能跑的微服务拆分方案，但它不知道你的团队只有三个人、下个季度要砍预算、这个服务的流量根本不需要拆分。发现和理解之间存在结构性鸿沟——在数学领域，Knuth 让 Claude 探索组合问题，Claude 找到了构造但无法证明它为什么成立；在工程领域，agent 能生成代码但无法判断这段代码是否该存在。裁判负责弥合这个鸿沟。

断路器：识别 agent 陷入死胡同并主动中断。LLM 在长上下文中会被自己之前的输出锚定，产生叙事惯性，越来越难跳出局部最优。人类可以"睡一觉"来打破思维定式，LLM 在同一个 session 里做不到。断路器不是被动等 agent 失败，而是主动判断"它已经进入死循环了"。

回到开头的场景：那类工程师缺的不是执行力（探索者角色），而是导航和断路的能力。不敢自己判断方向，不敢在不确定性中做决策，不敢说"我验证了，这条路走不通，建议换方案"。

怎么办：训练窗口、招聘标准、组织演进

对于现有团队中的执行型成员，核心是重新定义交互契约：

把"上抛问题"的通道关掉，打开"上报结论"的通道。 当成员带着不确定性来找你时，不替他做判断，而是要求他先验证、先给结论和建议方案，你只做最终拍板。判断错了复盘就好，不追责——但不做判断不行。给一个明确的时间窗口，2-3 个月。如果经过训练仍然无法独立闭环，那就不是沟通问题，而是人和岗位不匹配。

对于招聘，筛选标准需要从"能不能干活"转向"能不能在模糊地带做判断并承担结果"。一个有效的评估方式是：给候选人一个真实项目场景和一个相对较弱的模型，观察他如何弥补模型的不足——任务分解、质量判断、方向决策，这些才是 agentic engineering 时代的核心能力。

对于组织演进，方向是：

不是淘汰人，是淘汰一种工作模式

写到这里，我想澄清一点：这篇文章不是在说"能力一般的人应该被淘汰"。

被淘汰的不是人，而是"你告诉我做什么我就做什么"这种工作模式。一个愿意转变的人，完全可以从执行者成长为判断者——前提是他意识到这个转变的必要性，并且愿意承受转变过程中的不适。

真正的风险不在于团队里有执行型的人，而在于整个团队都是执行型的人，只有你一个人在做判断。那样的话，你不是在管理一个团队，你是在操作一群人形 agent——成本更高，速度更慢，还不能 7×24 运行。

Agent 时代对团队的要求很简单：每个人都应该是一个能独立做判断的节点，而不是一个等待指令的终端。

参考