架构师转型：AI时代如何从写代码进化到管Agent（值得收藏）

模型优化师

340人浏览 · 2026-03-09 21:05:09

模型优化师 · 2026-03-09 21:05:09 发布

最近看了一段 14 分钟的短访谈，主讲人 Mihail Eric，斯坦福 NLP 组出身，导师是 Christopher Manning。他之前在 Amazon Alexa 带过技术团队，也创办过 YC 支持的 AI 编码公司，现在一边在旧金山一家早期创业公司担任 AI 负责人，一边在斯坦福讲授一门课——CS146S《The Modern Software Developer》，全美第一门把 AI 贯穿整个软件开发流程的大学课程。

这个履历对我来说只有一个意义：他同时经历过大厂流程和早期团队的混乱，讲出来的建议更偏落地，而不是学院派的纸上谈兵。

他没有聊模型能力，也没有做工具测评。他讲了一个正在发生的结构性变化——

工程师的角色，正在从"写代码的人"变成"管 Agent 的人"。

我把访谈里的关键观点拆成一份更工程化的清单，尽量写成能照着改流程、改代码库的东西。以下是整理。

一｜初级工程师撞上了"三重完美风暴"

Mihail 从一个故事讲起。

他认识一个刚从 Berkeley 毕业的人，投了大约 1000 份简历，只收到了 2 个回复——不是面试邀请，只是回复。

这不是个例。他认为初级工程师的困境，是三件事同时发生的结果：

第一，过度招聘后的大裁员。 2021 年前后，COVID 之后很多公司觉得自己需要扩招，疯狂招人。然后发现招多了，大规模裁员开始了。很多公司发现砍掉 20%、30% 的员工，业务照样转。

第二，CS 毕业生数量暴涨。 Mihail 说自己毕业时是一个数字，现在大概翻了两到三倍。

第三，AI 改变了雇主的算盘。 雇主开始算一笔账：我是继续招更多的人来填坑，还是招更少但 AI 原生的人，用更少的人完成同样的工作？

三者叠加的结果：一大批被裁的资深工程师和一大批新毕业的年轻人同时涌入市场，而雇主的招聘意愿因为 AI 反而在收缩。

他还讲了一个反直觉的现象：资深开发者往往是对 AI 工具最抗拒的人。 写了 20 年代码的人太习惯自己的方式了，觉得"做这件事只有我一直以来的方法"。而新人像海绵，什么都是新的，什么都愿意试。

这段话让我想到身边的一些同事。做了十几年架构的人，让他用 Claude Code 跑一个重构任务，他宁可自己花三天手写。不是不会用，是不想用。

二｜角色重塑：你不再是写代码的人

传统工程师的注意力放在哪里？语法、逻辑闭环、个人产出。

AI 原生工程师的注意力会往三处移动：

分配智能——哪些事情交给智能体做，哪些事情留给人做决策和验收。
管理语境——让多个智能体在正确的上下文里工作，减少互相污染。
系统设计——把智能体接进真实系统，处理权限、审计、回滚、监控和失败模式。

这个变化在架构师的日常工作里已经开始发生了。以前做架构评审，重点看模块划分和接口契约；现在你还得多想一步——这个模块的边界是否足够清晰，让一个智能体能独立进去改代码而不破坏周围的东西？

未来"写得快"不算稀缺，"把边界守住"才算。

三｜不要因为别人跑 10 个 Agent 就觉得自己也该跑 10 个

这一段 Mihail 讲得特别实在。

Claude Code 的创始工程师 Boris Cherny 曾来他的课堂做客座演讲。Boris 同时跑 10 个甚至更多 Agent 的工作方式，在开发者社区广为流传。Mihail 说他的学生听完后，第一反应是"我也应该从 10 个开始"。

他认为这恰恰是错误的结论。

真正学会管理多个 Agent，就像通关游戏的最终 Boss。能做到这一点的人，即使在今天也是最顶尖的那 0.1%。

他的建议是逐步搭建（build it up piecemeal）。先用一个 Agent 把一件复杂的事做好，确认自己完全掌握了这个工作流。然后看看有没有第二个隔离的小任务——比如修一个 logo，或者改网站文案——再加一个 Agent。

关键是每个任务之间必须互相隔离、没有依赖。第一个跑顺了，加第二个。第二个也稳了，再加第三个。不是 10 个一起上。

我自己带团队用 Agent 做开发，见过太多"一上来就并行五六个"然后花更多时间收拾残局的情况。道理很简单：Agent 越多，错误越容易互相放大。 你以为在加速，其实在制造混乱。

四｜上下文切换：管 Agent 的真正难点

谈到多 Agent 工作流的核心技能，Mihail 指向了一个很日常的能力：上下文切换。

他打了个比方：这些 Agent 就像一群热情聪明的实习生，你把任务派出去，它们就在终端里埋头干活，代码哗哗地写出来。但有时候它们会卡住。

这时候你需要从 Agent 1 切到 Agent 2，再切到 Agent 3。每切换一次，你得记住上一个 Agent 做到哪了，还要有足够的上下文来推进当前任务。即使对人来说，这也很难。

然后他说了一句很有意思的话：他刚才描述的这些，就是一个好的人类管理者每天在做的事。 跟 Agent 没关系。这件事做好了，你也是一个优秀的团队经理。

他观察到，Agent 编排做得最好的那些人，往往有过管理人类开发团队的经验。他们在管人的过程中学会了怎么在多个任务间切换、怎么分配注意力、怎么在信息不完整的情况下做出判断，然后把同样的原则用在了 Agent 身上。

所以做架构的人反而有天然优势——你本来就在管人、管模块、管系统边界。现在只是管理对象多了一种。

五｜什么是"Agent 友好的代码库"

Mihail 提出了一个概念：Agent 友好的代码库（agent-friendly codebase）。

核心问题很直接：把一个 Agent 放进你的代码库，它能理解正在发生什么吗？它能在不破坏系统的前提下交付改动吗？

他把这件事拆成了四根柱子。

柱子一：测试是"契约"

当你让 Agent 在代码库里开发新功能时，它靠什么确认自己没有搞坏东西？靠测试。

Agent 只能基于显式定义的合约来运作。如果你没有足够的测试覆盖，你就没有给你的软件定义合约。

没有足够的测试，你就没有定义"正确"的方式。智能体也就没有边界。这时候你会看到一种熟悉的场景：功能看起来跑通了，但系统慢慢变得不可控。

我更愿意把测试拆成两类契约：

• 行为契约，约束输出是否符合预期
• 边界契约，约束哪些输入和状态必须被拒绝

多智能体并行时，边界契约往往更先救命。

柱子二：README 和代码必须一致

做过开发的人都知道，README 几乎一写完就和代码脱节了。代码说一回事，README 说另一回事。人类工程师遇到这种情况，会吐槽两句然后去看代码。

Agent 不会。它同时读到两个互相矛盾的描述，就会犯迷糊：到底该听谁的？更糟的是，当文档说的是 API V1，代码实现的是 API V2，Agent 会在冲突里选一边，然后把另一边当成"异常"去修。

这就是"幻觉"的来源之一——不是模型不够聪明，是我们给了它互相矛盾的输入。

解决方法很朴素：

• 把关键路径写成可执行示例
• 把示例放进 CI，保证它跟代码一起演进
• 把更新文档当成合并条件之一

柱子三：设计模式要统一

如果你的代码库中有一个地方用 API 1 来创建某种对象，另一个地方用 API 2 来创建同一种对象，Agent 不知道该选哪个。

Mihail 补了一句很实在的话：

如果我走进你的代码库，看到两种不同的做法，我也会问自己：该用哪个？我不知道，两种都在用，我大概率会去问一个同事。

Agent 友好的代码库，其实就是对人也友好的代码库。 好的工程实践没有变，只是在 Agent 时代变成了硬性要求，而不是"最好这么做"的建议。

柱子四：统一的风格检查

Lint 和格式化的价值，在 Agent 时代会被重新估价。它们减少分歧，减少解释成本，也减少智能体做出"自作主张"的空间。

以前你可能觉得 lint 规则太烦了，CI 总在报 warning。现在你会发现，这些规则恰好是给 Agent 画的线——别越界。

六｜Agent 会快速复合错误

Mihail 特别强调了一个现象。

如果 Agent 在第一步产生了一个误解，它看到自己第一步创建的错误代码后，不会纠正，而是在错误的基础上加倍错下去。像滚雪球一样放大，慢慢把代码变成一锅"意面代码"（spaghetti code）。

所以最重要的是：Agent 看到的第一版代码必须是自洽的、设计完善的、测试充分的。

在你开始让 Agent 写代码之前，先把代码库本身搞对。

这个道理对架构师来说其实很熟悉——你不会让一个新员工在没有文档、没有测试的项目里盲目开工。对 Agent 也一样，甚至要求更高，因为 Agent 不会像人一样走过来问你一句"这里是不是写错了"。

七｜品味，在最后一公里

什么把"能用的软件"和"了不起的软件"区分开？Mihail 的回答很直接：品味（taste）。

他举了课堂上的例子。每个项目有基础要求，比如必须实现五个不同的功能流程。大多数人完成要求就停了。但有些学生不一样——他们已经拿到了满分，还在继续打磨、扩展功能、让应用更健壮。

品味的培养发生在最后一公里。

区别在于谁更想解决问题本身，而不只是拿到分数。他说课上表现最好的学生，有的已经在围绕课程项目创业了。课程结束了，但他们还在继续做同一个东西，因为觉得还有更多值得做的。

谈到实验精神，他举了另一个例子：Boris Cherny 来课堂演讲时提到，Anthropic 的 Claude Code 团队基本上每一两周就会用 Claude 重写 Claude Code 本身。他们用自己造的工具重写自己的工具。

即使是在构建最前沿 AI 编程工具的团队，也没有"全部答案"。他们自己也在不断实验、根据用户反馈迭代。

Mihail 在课堂上反复强调：我可以来这里给你推荐工具、分享我觉得什么好用。但归根结底你得自己去撞墙。把实验和试错变成工作流的一部分，这就是软件开发的新方式。

八｜"开发者的傲慢"与过度工程化

AI 让构建变得太便宜了。

Mihail 谈到开发者有一种独特的心态，他称之为**“开发者的傲慢”**：看到任何问题，第一反应就是"软件能搞定"。这种心态本身很强大——它能让人愿意钻进系统内部，把不工作的地方修到能工作。

但 AI 把"能工作"的门槛拉低之后，这种傲慢有了新的风险：

你造出了最精美的软件，工程过度得离谱，然后你发布了，没人想要它。

你让 Claude 做一个东西，再让 Codex 做一个东西，然后不断加功能。一个月过去了，你造出了一个精美绝伦的产品，上线之后发现没人要。

构建变得便宜以后，验证和克制反而会变成更贵的能力。

这对做架构决策的人提醒尤其直接：过度工程化的诱惑从来就有，AI 只是把它放大了十倍。

九｜把智能嵌进产品里，才算分配智能

视频最后，哈佛商学院副教授 Rem Koning 简短出镜，讲了一个更大的话题。

关键不仅仅是使用 AI 工作，而是将 AI 嵌入产品，让智能体直接为客户服务。

很多团队还停在"用 AI 帮我做事"这一步。更激进的一步，是把 AI 嵌进产品本身，让它直接面对客户，直接在业务闭环里产出价值。

这会把工程关注点从"我怎么写得更快"推向"我怎么让系统更自律"。

权限、审计、回滚、风控、监控、成本控制——这些在传统架构里属于"非功能需求"的东西，在 AI 原生产品里会变成核心产品能力。

Koning 还抛了一个更远的问题：当 AI 开始和 AI 对话、AI 开始彼此协作，它们需要什么？他认为想清楚这个问题的公司，可能会成为万亿美元级别的企业。

十｜一套可复用的多智能体工作流

讲完道理，落回操作层面。

多智能体编排要跑稳，关键在于把语境拆开、把验收前置。我把它整理成一套更像团队流程的模板，可以直接套进日常开发：

1) 给每个智能体一张任务卡

任务卡只写四类信息：

• 目标——写成一句可验收的话
• 不改动的边界——比如不改数据库 schema，不改公共接口
• 输入——给出代码入口、相关文件、可参考的实现
• 交付定义——写清楚通过哪些测试，输出哪些文件

2) 让任务之间天然隔离

判断标准很简单：只改一个模块，不共享同一份状态，不需要互相等待结果。做不到隔离，就先拆任务，别先加智能体。

3) 每轮并行都先做一次验收收敛

并行越多，验收越要收紧：合并前跑完关键测试，只接受小步可回滚的变更，保持变更说明可追溯。

这三条是为可控服务，不是为流程好看服务。

十一｜一份可以直接照抄的落地清单

如果你要把一个现有代码库往"智能体友好"方向推，我建议的优先顺序是：

1. 先补测试，再谈并行
先把关键路径补出可回归的测试，再上多智能体并行。你要先能稳定验收，才能稳定提速。

2. 把 README 变成可执行文档
把最关键的一条路径写成脚本或示例，塞进 CI。文档更新跟着代码一起走。

3. 收敛模式，删掉二义性
同类逻辑不要保留两套写法。把常用模式抽成模板或脚手架，减少智能体自由发挥的空间。

4. 把改动边界写清楚
给智能体明确可改范围和不可改范围。把"不得修改的模块"和"必须保持的接口"写成硬规则——你可以用 AGENTS.md、CLAUDE.md 或类似的项目级配置文件来做这件事。

5. 每次并行只引入一个新变量
要么加一个智能体，要么换一种工作流，要么换一种验收方式。一次改一件事，复盘时才知道差异来自哪里。

写在最后

Mihail 在这 14 分钟里传达的核心信息，可以浓缩为三条：

1. AI 原生工程师需要在传统功底之上叠加 Agent 编排能力；
1. 代码库本身需要为 Agent 的到来做好准备——测试、一致性、文档缺一不可；
1. 而在这个转型期，"无知无畏"和灵活性反而可能是最被低估的资产。

从"写代码"到"管 Agent"，这个转型过程中，谁会被留下，谁会被淘汰？当 Agent 的能力继续提升，"管理 Agent"这个技能本身会不会也被自动化？

没有人有答案。但有一件事是确定的：坐在那里等答案的人，一定是最先被淘汰的。

来源

• 原始视频：https://youtu.be/wEsjK3Smovw By Mihail Eric

延伸阅读

Anthropic 发布 2026 Agentic Coding 趋势报告：八大趋势与 4 个优先级深度解读

深度拆解 Clawdbot（OpenClaw）架构与实现

OpenClaw 背后的秘密武器：极简智能体框架 Pi

NanoBot 架构拆解：4000 行代码实现OpenClaw能力?

深度拆解 OpenClaw 系统提示词：如何更像人?

你可信? OpenClaw+Skills，让 AI 开始在 Moltbook 自主注册、开趴、开会

OpenClaw 是怎么工作的？一条消息的旅程讲清楚

OpenClaw 是怎么工作的（2）：控制面两阶段协议与 runId

OpenClaw 是怎么工作的（3）：会话键与队列策略，怎么把并发关进笼子

如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享

因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享

·END·

相关阅读：
CC核心开发者分享 | 构建 Claude Code 的经验教训：像 Agent 一样看世界
别让 Agent 只是"看起来聪明"：从 OpenAI 学到的 10 件事
跟Cloudflare大佬学用 Claude Code
Claude Skills 入门：把“会用 AI”变成“可复制的工程能力”
一套可复制的 Claude Code 配置方案：CLAUDE.md、Rules、Commands、Hooks

Claude Code 最佳实践：把上下文变成生产力（团队可落地版）
把 AI 当成新同事：Agent Coding 的上下文与验证体系

Skill 到底是什么：从第一性原理深入剖析 Claude Agent Skills

把 Claude Code 用成工程工具：8 条黄金法则与一套可复用工作流

Anthropic 官方 33 页指南拆解: 构建Skills的最佳实践

2026 开年这篇综述，把高效 Agents 讲得很工程（附落地清单）

AI编程实践：从 Claude Code 到团队协作的 6 个落地抓手
Anthropic 发布 2026 Agentic Coding 趋势报告：八大趋势与 4 个优先级深度解读

Claude Agent Teams 架构与实战拆解

Claude Code 创始人亲授：10 条进阶秘籍（附 12 条工作流 Prompt 清单）