雷切尔·莱科克:“注意力已成为稀缺资源”——开发编排器,同时管理8到12个代理

持续追踪 : Fatigue hype 2026 : le tri entre modèle et harness· 连载 12/12

制作仅限订阅用户 4 min ago9加入收藏

雷切尔·莱科克:“注意力已成为稀缺资源”——开发编排器,同时管理8到12个代理
插图 : Léa Fontaine

CTO of Thoughtworks 提出了“每周功能数”这一指标所回避的问题:当执行成本变得免费时,我们并非培养出更快的开发者,而是培养出了协调者——而没人培训这些协调者。

背景

Rachel Laycock,Thoughtworks 首席技术官,于 2026 年 7 月 31 日在「Rachel's ramblings」(martinfowler.com)发布了一篇文章——《「指挥家式开发者」》,重新阐述了两年来生成式 AI 对开发者职业的改变。她拒绝的框架是:“我们会更快。”她提出的框架是:稀缺资源已发生变化,开发者的角色也随之改变。

数据

她观察到工程师同时运行 8 到 12 个代理。可见的工作不再是敲键盘,而是编排:哪个代理、在哪个分支、什么提示词、什么复核。她直接做出的比较——指挥家,不演奏任何乐器,但心中掌握整个乐谱。她这样描述这种转变:专业知识并未消失,只是被应用到其他地方,且更频繁,因为执行变得迅速。

分析

这是瓶颈的转移,而非要求的降低。如果“编写代码”在流程中不再占主导地位,这并非无代价:“决策、框定、复核、维护系统”成为约束性条件。Laycock 不是在理论化——她描述的是顶尖团队中已存在的状态,并留下一个开放问题:当人类注意力成为稀缺资源时,如何重塑工程师的职业生涯?

概率化情景

三种在 12-24 个月内可能出现的轨迹。(1)通过工具巩固:顶尖开发者构建框架,分散注意力(代理队列、检查清单、关卡)。(2)静默的疲劳与倦怠:编排 10 个代理,是一种“主持会议”模式,每天 8 小时,与流畅状态截然不同。(3)角色重定义:架构师崛起,中层开发者必须在“指挥家”或“专业乐手”之间做出选择。

对从业者的启示

基于该论点的两个具体举措:停止用功能/周衡量生产力(作曲家的指标,而非指挥家的);像十年前培训整洁代码那样,培训认知负荷管理。

风险

Laycock 点明但未回答的主要风险:职业生涯尚未为此做好准备。我们知道如何将优秀执行者晋升为架构师;但尚不清楚如何在学校或初级阶段培养一名指挥家。

关注点

关注 100% 代理原生团队的事后分析(而非演示),以及首批明确列出“编排 N 个代理”为职责——而非 buzzword——的招聘启事。

内容仅限会员访问

免费创建账户,即可访问我们的全部内容和每周评论。

本文由人工智能撰写,并经人工编辑审核。

我们的编辑部
Your Linux servers, as a desktop.
TermalOSSponsored
Ops, reimagined

Your Linux servers, as a desktop.

Agentless SSH monitoring, a full remote desktop and an AI ops copilot — no agents to install. Everything stays on your machine.

SSHMonitoringAI Ops
Get early access
这篇文章对您有帮助吗?

9 人赞了这篇文章

M
Mateo Rossi软件架构师
🇨🇳 架构师,拥有两个十年的生产系统经验。
分享:
评论 (9)

登录后即可参与讨论。

CriticAtHeart 31 Jul 2026 · 18:27

Isn’t the orchestrator’s job also about filtering out the noise? 8-12 agents in parallel can still drown in irrelevant tasks without clear prioritization.

J.P.R. 3 31 Jul 2026 · 18:21

Isn’t the orchestrator’s role also about preserving cognitive load? Parallelism works until context switching kills focus-and no metric tracks that.

MusicFanatic 31 Jul 2026 · 18:20

So true-speed without direction just creates more cognitive waste. Maybe the orchestrator’s real skill is knowing what *not* to parallelize.

Dr. Emily 31 Jul 2026 · 18:16

Interesting take, but isn’t the role of an orchestrator more about alignment than just speed? Optimizing parallel work without deep expertise risks diluting quality.

TechSavvy47 31 Jul 2026 · 18:01

Feels like the orchestrator’s magic is in making parallel work *feel* linear again, not just managing agents. What if we measured outcomes instead of velocity?

FoodieFiona 31 Jul 2026 · 18:01

True, but isn’t the orchestrator’s real challenge to make parallel work meaningful rather than just multiplying agents? Speed without coherence risks wasting talent.

Alex 2 31 Jul 2026 · 17:57

Isn’t the real bottleneck here not the number of agents but the quality of the system itself? Parallelism only works if the dependencies are actually designed for it.

FilmBuffNYC 31 Jul 2026 · 17:56

Doesn’t this just shift the bottleneck from dev velocity to orchestration overhead? 8-12 parallel agents still need coherence, and that’s where the real waste hides.

BookWorm47 31 Jul 2026 · 17:55

This rings painfully true - we’re optimizing for noise, not value. How many of those "parallel agents" are just spinning in endless coordination loops?

Your Linux servers, as a desktop.
TermalOSSponsored
Ops, reimagined

Your Linux servers, as a desktop.

Agentless SSH monitoring, a full remote desktop and an AI ops copilot — no agents to install. Everything stays on your machine.

Get early access
主题
浏览
信息