别把“会画图”和“做架构”混在一起

过去一年有一种很流行的说法：AI 已经越来越会写系统，架构师是不是会变得没那么重要。这个判断有一半是真的。确实有一类架构师会被削弱，那就是长期只停留在概念层、流程图层、汇报层，不深入运行细节的人。因为当代码生成和系统组装越来越便宜时，抽象但不落地的“高位设计”会更容易失去说服力。

但另一半恰好相反。只要你去看 LangGraph、微软 Agent Framework、OpenAI Agents SDK 和 MCP 这些系统，就会发现一件事：Agent 不是把架构问题消掉了，而是把它们从“服务怎么连”进一步推进成“运行时怎么稳”。这层问题不但没有变少，反而更多。

新问题，越来越像运行时问题

传统软件架构更偏静态：模块怎么拆、数据库怎么分、接口怎么定、消息怎么流。Agent 系统则明显更偏动态：状态在哪里存，任务断了怎么接，工具调用怎么审计，人工批准怎么回到流程里，多个子代理如何移交上下文，异常和越权怎么及时拦下。

LangGraph 把 durable execution 放在中心，微软把 workflow 与 checkpoint 做成显式能力，OpenAI 的 Agents SDK 反复强调 human in the loop，MCP 又把工具、资源和提示词的边界协议化。这些东西放在一起，几乎是在提醒架构师：以后真正稀缺的，不只是“搭一个系统”，而是“搭一个能带着状态、带着权限、带着恢复能力跑下去的系统”。

这轮变化会把架构师往哪里推

所以我更愿意把 Agent 时代的架构师理解成一种新的运行时设计者。这个角色需要管的事情，至少会比过去多出几层。

  • 状态边界：哪些记忆应该短存，哪些应该长期保存，哪些不该让 Agent 自己写回。
  • 工具边界：工具的 schema、权限、失败返回和审计字段如何统一。
  • 执行边界：任务跑多久、何时 checkpoint、何时 timeout、何时重试、何时转人工。
  • 协议边界：模型、工具、知识源、外部系统之间如何通过稳定协议连接。
  • 治理边界：谁可以批准、谁可以回滚、谁能查看 trace、谁对结果负责。

换句话说，架构师的主场正在从“画静态组件图”，进一步转向“设计动态运行规则”。

哪类架构工作会先显得吃力

被冲击最大的，不是懂得很多底层约束的人，而是把架构工作长期做成 PPT 工业的人。

如果一个架构师只会讲抽象层次、技术路线和理想分层，却不理解实际工具如何被模型调用、状态如何被污染、审批怎样真正嵌进 workflow、失败如何被恢复，那么 Agent 时代会迅速暴露这种工作方式的空心化。因为系统一旦开始自主执行，所有没落到运行时的“原则”都会在第一轮事故里失效。

反过来，那些本来就重视运行细节、协议边界、审计链路和恢复策略的架构师，会越来越值钱。AI 会让他们少花很多时间在样板实现上，却会让他们花更多时间在真正关键的设计决策上。

结尾：Agent 时代真正稀缺的，不是图纸，而是默认稳定的运行规则

我的倾向判断是：架构师不会被削弱为可有可无的角色，但架构师这个岗位会被强行洗牌。旧式的“图纸型架构师”会更危险，新的“runtime 型架构师”会更稀缺。

所以这轮变化里最值得问的问题不是“还需不需要架构师”，而是“架构师有没有能力把 Agent 系统最容易失控的那几层设计成默认稳定”。如果答案是有，那么这个岗位不但不会被替代，反而会比过去更靠近组织核心。

更新附注

  • 版本：v1.1

更新日期：2026-04-01 更新原因：重写标题、首屏判断与结尾收束，把文章焦点进一步收拢到“运行时设计者”这一岗位迁移方向。