我是一名大模型应用开发工程师，日常就是跟各种 Agent 打交道，搭 harness、接模型、写 tool、调 memory。

我说了好几遍：

“工程层正在凋亡。”

第一代 Agent 工程已经在凋亡了。

第二代看着热闹，骨子里也开始松动了。

Claude Code 和 Codex 大概率能活下来。

但是很多跟着这波 Agent 热长出来的 SDK、wrapper、各种 agent engineering platform，说实话，正走向一种慢性的死。

不是说 Agent 没价值。

问题是出在另一边：

我们一直把 Agent 塞进了错的工程形状里。

---

第一代：把 Agent 当成了 Workflow

第一代 Agent 工程不垃圾，它很纯粹，也有探索的意义。

但它犯了一个特别大的错误——

它太高估你能事先编排 Agent 的行为了。

这一代的东西，核心基本就是 graph、workflow、chain、role、SOP 这些概念。

LangChain、AutoGPT、AutoGen、MetaGPT、Dify workflow，都在探很重要的东西。它们让开发者头一回意识到：哦，大模型不只是个聊天框，它可以变成系统里的一个零件。

但骨架没变。这代工程用的还是传统软件自动化那套语言。

Graph 就是编排层。

Workflow 就是 SOP。

Chain 就是一串被人手设计好的步骤。

先调工具。再传结果。再校验。再分支。再重试。最后吐出来。

这个思路太自然了，任何一个写过后端的人都会这么想。

几十年了，软件工程本质上就干一件事：把能重复的人的想法，翻译成机器能跑的固定结构。

Vim、Excel、VS Code、Photoshop、Chrome、无数的 SaaS——软件一直在做人手里重复部分的固化。

创造了巨大价值，没毛病。

但有一个关键区别，好多人没注意到：

传统软件从来没打算坐人的位置。
它自动化的是一件事，不是一个人。

LLM 不一样。

它打一开始学的就是自然语言。

而语言不只是个交互壳子——语言是压缩过的人类意图。

一个系统要是能听懂话、能写代码、能调工具、能读文件、能查 API、能操作终端，还能根据反馈来回改——那它就不再是一个功能块了。

它开始往人的生态位上靠。

它不是又一个编译器，也不是又一个状态机。

它是一个把人类意图翻译成可执行动作的东西。

所以到今天，如果你还在写软件，但死活不肯用 Codex、Claude Code、Cursor 这些东西，说真的，你就是在主动扔掉一堆已经被验证过的杠杆。

这些工具当然不完美。屎山代码照样写。照样得盯着。

但方向很明确了：

它们早就不只是辅助了。它们在变成意图的执行器。

第一代 Agent 工程真正出问题的地方就在这——

它非要把一个通用 Agent，塞进一个 SOP 形状的笼子里。

---

SOP 真不是终局

SOP，标准作业流程。把活拆成角色、步骤、岗位。

现代工业就是长在这套逻辑上的。流水线轰隆隆，每个人都卡在系统里一个很窄的位置。

产量上去了，整个自动化世界都出来了。

这个逻辑极其强大：让工具专精，让位置固定，让流程标准，然后拼命提吞吐。

但 Agent，它不是一个专精工具。

Agent 更像一个通用的语义工作者。

不是说它是人。不是说它有意识。更不是说你可以闭眼信它。

而是说，它主要的价値不来自被钉死在一个窄位置上。

它的价値来自灵活。来自翻译意图。来自处理模糊。来自该用哪个工具自己挑。来自看懂上下文再动手。

来自把一个讲不清楚的目标，变成一件件能做的具体事。

律师不只是走流程。做研究的也不只是走流程。高级工程师也不只是走流程。

他们会解释意图、掂量约束、处置异常、自己选工具。

所以模型越强，你把 workflow 卡得越死，限制可能就越大。

一个 Agent 已经能开终端、读文档、写代码、搜文件、调 API、自己定计划了——你这时候给它套一个定死的流程，可能不是在帮它。

你给它的不是结构，是镣铐。

干这行两年多，我真实的感受就是：早期很多 Agent 系统，demo 让人觉得要变天了，一上真实工作就拉胯，原因就在这。

它们被设计成了一种新型 SaaS 零件。

但 Agent 根本不想当 SaaS。

Agent 想生产 SaaS。

一个 SaaS 产品，通常就是个固定的业务壳子，把 workflow 写死，控制一个领域。

Agent 不一样。Agent 是语义执行器。它可以用 SaaS。可以造 SaaS。可以横跨好几个 SaaS 的边界干活。甚至能自动化掉那些曾经靠 SaaS 去自动化别人的人。

第一代把 Agent 当成自适应 SaaS 组件了。

但它不是自适应 SaaS。

它更像一个通过软件来干活的人形东西。

---

第二代：让 Agent 扮演人类

然后第二代就来了。

Manus、Claude Code、Codex、OpenClaw、Hermes，一大堆 Agent Application 冒出来。

它不再把 Agent 主要当 workflow 节点用了。

它开始把 Agent 当成被人指挥的 coworker。

你不用事先把 workflow 的每一步设计好。你说你要什么，Agent 自己想办法把结果给你。

这一步真的是概念上的跳。

Manus 重要的地方就在这。不管它后来产品走成什么样，我一直觉得 Manus 标记了一个节点：

它证明了自然语言可以当工单界面。

你说你要啥，Agent 自己试着把你的意思翻译成最终的产出。

这已经不是编排层那个世界了。

后边 Claude Code 和 Codex 在写代码这个领域把事推得更狠。Agent 进 codebase，读文件，改代码，跑命令，看报错，定计划，重试。

它开始在一个跟真实开发者几乎一样的环境里干活。

这一步非常关键。

但第二代也搞出了新麻烦：

它一边让 Agent 看起来像人，一边底下的 harness 根本撑不住。

Agent 看起来像员工了。但底下的执行环境，说真的，还很脆。

太多上下文。太多工具。太多自定义调用。太多插件和用不上的 MCP。太多没结构的内存。

缓存纪律几乎没有。可观测性几乎没有。恢复机制几乎没有。经济控制几乎没有。

而且太信"自己能进化"这种说法了。

所以很多 Agent Application 热得飞快，忘得更快。

它们制造了狂热，也制造了焦虑，但没留下能用的范式。

一个 demo 能让 Agent 看着像真干活的。但严肃系统得让这个干活的变得可靠、能查、能恢复、有经济账。

demo 只要漂亮一次。系统要每次都扛得住。这是两个世界。

---

为什么是程序员先吃到肉

那问题来了——既然系统这么脆，为啥程序员还是能从 Claude Code 和 Codex 里拿到实实在在的价値？

为什么写代码会变成第一个严肃的 Agent 应用领域？

答案不只是模型代码写得好。

更底层的答案是：

程序员天然就知道怎么盯着 Agent。

程序员懂文件系统、懂报错、懂 diff、懂测试、懂架构取舍、懂终端命令。程序员看一眼 patch，就大概知道能不能合。

也就是说，harness 不需要把所有问题都解决掉。人类开发者自己填了很多坑。

Agent 可以不完美但依然有用——用的人自己能修它。

这就是 coding agent 跑在通用 agent 前面的原因。

不是因为写代码简单。写代码一点都不简单。

而是因为写代码有一个极其硬核的监督循环。

跑测试。看报错。查 diff。搜文件。上 bash。让它 patch 和 edit。重新 debug。再来。再来。再来。成了。

这条循环对人和对模型，都足够清楚。

但换成法律、医学、会计、学术研究、金融分析、企业内部运营——情况就不一样了。

法律 Agent 生出错的条文，一次错信任就碎了。医学 Agent 给错解释，一次错治疗窗口就没了。

非程序员大概率根本不知道怎么查 Agent 哪出了错。不知道它做了什么。不知道哪次调工具参数写错了。不知道记忆是不是过期了。不知道吐出来的是不是编的。

门槛在这。不是"Agent 不能干活"。

而是：harness 还没把 Agent 做成让普通人能安全用的系统。

开发者能从不完美的 Agent 里捞价値，因为开发者自己就是 harness 的零件。

对其他人来说，harness 自己得先变强。

Agent 不会自己纠错。纠错要么靠人，要么靠足够硬的 infra。

---

为什么 Bash 这种东西反而赢了

写代码的 Agent 变强，还有个原因，很多人没注意：

它们踩在通用工具上。

Bash 就是最好的例子。

回到 2023 年，那会儿大家都很上头 RAG——你可以理解为"让模型能在回答你之前先翻资料"的技术。大家研究怎么把文字切成块、怎么建向量索引、怎么排召回结果、怎么自己写检索工具。

这些工作当然有价值。

但后来发生了一件事特别有意思：

最强的写代码 Agent，最后回退到了最简单、最通用的交互上。

搜文件。跑命令。读输出。改代码。跑测试。重复。重复。重复。

好了，出活了。

为什么？

因为 Bash 是通用的。它是整个操作系统的通用控制面。它老、它无聊，但在训练数据里到处都是。

理论上，光靠 Bash 就能完整操控 Linux。为什么只是理论上？因为你背不全命令。

但大模型最擅长什么？

答案呼之欲出。

这对模型训练非常关键。AI 实验室可以训练模型去处理像 Bash 这样的交互，看常见模式，改进工具使用，围绕通用操作把模型越对越齐。

但你那个带了 100 个自定义工具调用、40 个私有 MCP 的工作流呢？

模型大概率没见过。实验室也没法围着它训练。

训练很难干净地穿透各种自造的 wrapper 去做泛化。

你的交互方式越怪，就越吃不到主能力前端的红利。

第一代 Agent 工程挣扎，这也是一个原因——搞了太多自定义的编排壳。

另一边，真跑出来的产品，拥抱的都是通用基面：文件、shell、代码、测试、API、浏览器、标准协议，还有越来越靠近 MCP 这种通用工具接口的东西。

真正要学的事不是 RAG 死了。

真正要学的：通用工具面，模型更好学，人更好监督，infra 更好优化。

这就是 Bash 赢的原因。

不是因为它优雅。是因为它通用。

老掉牙的通用技术，反而成了新时代的硬通货。

---

第二代 Agent Application 差在哪

第二代办了一件重要的事：从 workflow 走到了拟人。

但拟人不够。

用户不光是想要一个"看着像同事"的 Agent。用户要的是回报。

很多 Agent Application 就死在这。

它们承诺能自我进化。

但到底什么叫自我进化？多写几个 skill？多挂几个工具？多存几条记忆？把历史和分支越攒越大？

这些东西可能有一点用。但它们不会自动带来质变。

实际用起来，用户期待的是：Agent 会越来越懂我，越来越聪明，犯错越来越少，能搞定的领域越来越多，最终成一个靠谱的搭子。

但真实情况往往是：Agent 记住了我的名字，记住了我在什么行业，记住了一些偏好，存了一些 workflow——然后接着犯新错。

成本还在往上涨。上下文越撑越大。系统越来越看不懂。

用户开始觉得，Agent 没帮我省事，反而多了一种运维债。

程序员可能愿意咬牙扛，因为收益是直接的。非程序员，理解门槛就挡掉一大半，更别提忍受了。

所以 GitHub Star 真可能骗人。

一个项目可能因为大家怕错过风口才火。可能因为 demo 太炫才火。也可能因为它让非技术用户觉得：我终于也能有一个 Agent 了。

但火不等于能留。

能留的，只有可重复的经济产出。能不能每天省时间？能不能降成本？能不能提吞吐？能不能跑长程任务？能不能从错误里恢复？能不能被检查？能不能在一个领域里被信任？

Star 数量的是期待。经济产出量的是真相。

这才是真测试。

也是第三代 Agent 工程一定会出来的理由。

---

工程层没死

所以听到有人说"工程层正在凋亡"，我作为天天写代码的人，完全能理解。

现在很多 Agent Engineering 看着确实很疲惫。

太多 wrapper。太多 SDK。太多一次性 harness。太多互相不兼容的 runtime。太多关于怎么起 agent、怎么管 session、怎么调工具、怎么管记忆、多个 agent 怎么协同的重复屎山。

乱的，真的乱。维护都头疼，更别说兼容。

像 1970 年代的操作系统，各搞各的。

但生态总有一天得收敛。

它需要无聊的地基、共享的抽象层、统一的 runtime 标准、能迁移、能跨架构。

工程层没死。它只是还没长成对的样子。

第一代想让 Agent 当 workflow。

第二代想让 Agent 占人的生态位。

第三代必须让 Agent 变成跑在实打实基础设施上的软件系统。

---

回到 Docker 这个比方

2013 年以前，容器这玩意早就有——LXC 2008 年就出来了。但没人用。

不是技术不行。是用起来太他妈碎了。

每个人都在自己搭环境、写脚本、处理依赖。能干，但换个机器就崩。

然后 Docker 来了。

Docker 没发明容器。Docker 做了一件事：把大家已经在干的事，标准化了。

一个 Dockerfile，一行 build，一行 run。镜像打包、分发、运行，从头到尾一套东西。开发环境、测试环境、生产环境，终于不用再互相甩锅说"我这能跑啊"。

后面 k8s、Docker Hub、整个云原生生态全是从这个标准化动作长出来的。

Docker 没创造需求。它把一群运维和开发已经在地上摸爬滚打的活，包成了一个能复用的标准。

Agent 现在就站在 2013 年容器圈的那个位置。

开发者天天在用 coding agent。模型已经能调工具了。MCP 已经成了事实上的通用工具接口。本地和远程沙箱正在变常态。上下文、记忆、缓存、权限、会话、工作区、可观测——全是真实工程问题了。

但每家公司都在自己搭。每个团队都在自己造 harness。互相不兼容，换一个模型供应商恨不得重写半套。

Agent Engineering 需要的 Docker 时刻，不是再来一个厂商 SDK，不是再来一个围着单一产品的 wrapper——是真 infra。

---

第三代会往哪走

下一代 Agent Framework，不会靠模拟一个公司赢。

也不会靠让 Agent 更像 PM、工程师、Reviewer、分析师或者 Manager 赢。

这种类比挺有启发性的，但不是终局。

Agent 的未来不是"AI 员工"。Agent 的未来是能落地算账的经济杠杆。

该问的不是：Agent 多像人？workflow 里排了多少角色？demo 多炫？能接多少工具？能记住几个 skill？

该问的是：

成功率、成本、延迟、恢复、观测、调试、迁移、自检、能不能跑长程、协调成本划不划算、能不能把模型能力稳定变成经济回报。

这些才是真 benchmark。

不是拟人度。不是 SOP 复杂度。不是 demo 障眼法。

量 Agent 不是量它多像人，是量它多出活。

这也会改变关于失业那套说法。

我不觉得最重要的 Agent 平台会靠"制造失业"拿分。这个说法太浅了。

更好的说法是：Agent 该把创造有用软件和有用运营系统的门槛打下来，让领域专家能自己做出以前非得养昂贵工程团队才能做的东西，让小团队拿到以前只有大组织才有的执行力，让那些 ROI 低但确实有意义的事变值得做。

真正的价値不是喊着替代人。真正的价値是扩开人在经济上值得去试的边界。

替代人是焦虑。扩展人是杠杆。这两条路去的不是同一个终点。

---

第三代，必须把 Agent 当跑在真实基础设施上的软件系统。地基不性感，但地基决定上面能盖多高。

最后问大家一句：

你平常干活的时候，有没有哪个环节是你特想让 Agent 帮你干了、但到现在还不敢交出去的？是因为它不够聪明，还是因为你没法确认它到底做对没有？

评论区说说你的岗位和你现在咋想的，一起聊聊。