人类在 Agent Swarm 时代的工作范式迁移

随着现在 Agent Swarm 的兴起，人类的身份逐渐变化。旧的定义是人写代码，AI 辅助（AI 当助理）现在变成了人设计系统，AI 执行。 即从执行者+监督者，变成了设计师+委托人+决策者

观察到的一些现象

比如现在的 gpt-5.2 / gpt codex 5.2 这一些模型，让他做个简单的“助手型任务”，比如翻译一些注释、改一些变量名使其满足可读性规范、又或是其他简单任务（模仿一个文件的风格写另一个文件等），它会思考20秒才给出结果，反应迟钝，看起来很懒惰，作为助手，它很糟糕。

但转折来了，如果你给他一个比较模糊/复杂的任务，比如“研究一下这个依赖库在 Linux ARM 架构上构建失败的原因，并帮我写一个补丁”，它会像一个真正的人类一样连续工作个十几、几十分钟不等。它会自己去查文档、读源码、尝试复现并分析原因，最后给出方案。

所以刚开始用 gpt-5.2 / codex 给我的第一感觉就是“慢”，实际上我不需要盯着他工作十几分钟。但随着使用次数的增加，我发现 gpt 5.2 在处理一些复杂问题时，它的推理会很细致，发现了很多我没发现的细节，于是开始转变看法。或许我的工作范式才是导致工作流变慢的原因。

注意单点瓶颈！

过去两年，像 Cursor、Copilot 等编辑器在侧边栏与 AI 聊天，被视为标准范式，但只要侧边栏还在，人类的注意力就总会下意识退回到人类问一些问题，AI 就补全一些代码。或者是把代码从右边复制到左边的一个过程。这种模式让人产生一种“在用 AI”的幻觉。可实际上人是这个链路中最慢的组件，把自己锁死在“人在回路中”的瓶颈位置。

这种模式不仅慢，而且有毒，它会让你沉迷即时反馈的快感，让你忽略了真正的效率提升。

我没有在说侧边栏不好，我是在思考，是不是真的要把注意力从代码层面开始转移。codex app 的无代码界面我也十分不习惯，但随后我了解到他们这些工具的设计理念之后，我反过来思考我都工作模式，或许这些工具一开始不完美，或许以后也是要支持代码/文件浏览功能，但无论如何，旧的编码方式让人处在木桶短板地位这个说法我认为是没错的。

人类的大脑是单线程的，一次几乎只能处理一个文件（或一个 feature），侧边栏模式是为了人类单线程工作而设计的。

但 AI 是可以并发的，如果卡在人类的瓶颈，那这完全浪费了 AI 的并发能力。

范式的转变

答案是什么？我认为是要像“工厂模式”那样，才是未来。

以前的助手模式下，我是钢铁侠，AI 是贾维斯。虽然贾维斯很强，但还是会围着我转，我停下来，他也停下来。即上述说的“单点瓶颈”。

而工厂模式下，我是工厂主，我负责设计好流水线，按下按钮，多个 AI Agent 并发工作（或 sub Agent

打个比方：

• Agent 1 负责拆需求
• Agent 2 负责写实现
• Agent 3 负责写测试
• Agent 4 负责 code review
• Agent 0 甚至可以调度这另外几个 Agent

你不需要盯着他们，可以去做别的事

关于“开发体验”

在以前，报错信息、日志是给人看的，会拿来排查故障，确定问题；用红色高亮标识爆错，用英文/中文写“=== failed to get xxx ===”，讲究可读性。

现在“开发体验”的语义也开始转变。以前 DX(Development Experience)指的是开发者体验，现在分化为 HDX(Human DX) 和 ADX(Agent DX)。

有些观点是：可以为了 ADX 牺牲一些 HDX。怎么做呢？比如日志采用结构化的 JSON 或者某种冗长但包含详细堆栈细节的格式。这种信息人类读起来体验可能会很差，但对 AI 十分友好。

这是对的，因为现在绝大部分报错都可以通过 Agent 自动捕获并且修复，而人类会更少的（逐行）阅读日志。如果为了人类感官上的可读性好，而牺牲 Agent 的效率，那是本末倒置。

HDX 不再等于“可读性”，而等于“可干预性”。也就是说，日志不需要人能顺眼读，报错不需要人第一眼看懂，代码甚至不需要人能轻松 follow。但必须满足一件事：人类能在 5 分钟内接管系统，并施加“高层干预”。

如果 ADX 走到，只有 AI 看得懂，人类失去全局理解能力，那不是进化，是技术性失明。

最健康的形态是：

• 底层：为 Agent 优化
• 顶层：为 Human 决策优化

其他

AI 发展太快，一周、一月一个样，从 GPT-4 到 GPT-5.2 只用了两年，但模型效果天翻地覆。

任何试图“维护旧功能”的行为，在这个高速发展的时代，都是在自杀。

人也一样，如果不自己颠覆自己，别人就会来颠覆你。