大家好，我是十三！欢迎来到十三Tech。
前几天朋友推荐我看黄佳老师的《Agent 设计模式之美》。刚看到“设计模式”这几个字时，我并没有立刻被打动。
做了这么多年服务端和架构，GoF 23、DDD、分层架构、接口隔离、工程治理，这些东西都在我的旧知识区里。它们不是纸面概念，而是我在真实项目里反复用过、也反复踩过坑的一套工程语言。
但看完开篇词后，我开始意识到一个问题：过去这套语言依然重要，却已经不足以完整描述 Agent 带来的新复杂度。Agent 不是在传统系统里多塞一个大模型，它正在逼我们重新定义“设计”的对象。
这篇文章不做课程摘录，也不假装我已经吃透 Agent。它更像一篇开场白：为什么一个长期做服务端和架构的人，会决定系统学一遍、写一遍。
如果你也熟悉传统后端、工程架构、设计模式，但最近看 Agent 总觉得“好像懂一点，又好像少了一套语言”，那这篇应该能对上你的感觉。
一、我不是缺工具，我缺的是一套新语言
过去一年，Agent 这个词已经被讲得很热了。
有的人讲 Prompt，有的人讲工作流，有的人讲工具调用，也有人把多个 Agent 摆成一个小团队。这些东西我都感兴趣，都试过。
但越看越有一个问题：这些材料大多在讲“怎么把东西跑起来”，很少有人认真讲“跑起来之后，这个系统应该怎么设计”。
一个 Demo 能跑通，只能说明链路暂时没断；一个系统能长期运行，才说明边界、成本、失败恢复、观测和治理都有人管。传统服务端项目里我们很熟悉这套逻辑，到了 Agent 场景，反而容易被模型能力遮住判断。
我自己也会犯这个毛病。看到模型能规划、能调用工具、能自己修正，就很容易先被能力吸引。但继续往下想，真正难的地方很快就会浮出来：接口调错怎么办，记忆被污染怎么办，协作没有退出条件怎么办？
我把这种感觉画成了下面这张图。
这张图想表达的是：我不是要把过去那套工程经验丢掉。恰恰相反，GoF、DDD、分层、治理这些旧知识依然是地基。
只是 Agent 把问题往前推了一层。以前我主要处理“对象、模块、接口怎么协作”；现在还要处理“感知、记忆、推理、行动这些能力怎么协作”。旧语言还在，但它不够用了，需要补一套新坐标。
二、GoF 没过期，但它回答的是旧问题
我很反感那种“一切都被 AI 颠覆了，过去经验没用了”的说法。
这话听着刺激，真落到项目里，很容易害人。一个 Agent 系统最后还是要接数据库、外部接口、权限、日志和告警。只要进入真实业务，传统工程能力就跑不掉。
GoF 这套设计模式，今天依然有价值。工厂解决创建，策略隔离变化，观察者处理通知，装饰器扩展边界。这些思想不会因为模型出现就突然失效。
但它们主要回答的是对象世界里的问题。
Agent 带来的新麻烦，是能力世界里的问题。
| 我过去熟悉的问题 | Agent 之后多出来的问题 |
|---|---|
| 模块怎么解耦 | 上下文怎么组织，别越堆越脏 |
| 接口怎么稳定 | 工具调用有副作用，谁来兜底 |
| 流程怎么编排 | 推理、反思、执行怎么互相影响 |
| 权限怎么控制 | 自主行动和人工审批怎么平衡 |
你看，这些问题很像工程问题，但又不是传统工程问题的简单复制。
比如“记忆”。在普通业务系统里，存储是一件很确定的事：字段是什么，表结构是什么，数据怎么查，权限怎么控。到了 Agent 里，记忆更像一个会影响判断的长期上下文。存多了会污染，存少了又不聪明，存错了更麻烦。
再比如“行动”。普通服务调接口，输入输出基本可控；Agent 调工具，前面还有推理、规划、上下文压缩这些不确定环节。它不是不能做，而是不能假装这些不确定性不存在。
这也是我看开篇词时被点醒的地方：Agent 设计不是 GoF 设计模式的续集，而是软件设计对象的一次扩展。
从对象到能力，从确定性协作到不确定性治理，这个跨度，靠多背几个名词肯定不够。
三、最打动我的，是“双轴”这个视角
开篇词里最让我停下来的，是“双轴”这个说法。
我目前的理解很朴素：看一个 Agent 系统，不能只问“它会什么”，还要问“它怎么跑”。
“它会什么”，对应能力维度。比如感知、记忆、推理、行动、反思、协作、治理。
“它怎么跑”，对应执行维度。比如串行执行还是并行探索，一个中心统一规划还是多个角色协作，直接执行还是先反思再行动，自由调工具还是必须审批和回放。
这两个问题合在一起，才像一个真正能落地的设计问题。
这张图其实就是我给自己画的一张提醒卡。
以后再看一个 Agent 方案，我不想只问“它是不是用了 RAG，是不是接了工具，是不是多 Agent”。这些问法太容易停在名词层。
更有用的问法应该是：
- 能力缺口在哪里，是感知不完整，还是记忆不可靠？
- 执行结构怎么组织，是线性流程、反思循环，还是多角色协作？
- 治理边界谁来守，工具调用、审批、回滚、审计有没有位置？
这三个问题一问，很多看起来很酷的方案会立刻露出真实样子。
有的系统不是模型不够强，而是上下文一直在变脏；有的系统不是 Agent 不够多，而是协作结构没退出条件；有的系统不是工具接得少，而是副作用没人兜。
坦率地讲，这个视角对后端架构师很友好：熟悉的分解、边界、协作、治理仍然有用，只是要投射到新的能力对象上。
学习一个新东西，最怕的是完全没有抓手。双轴给我的感觉，就是终于有了一张可以继续往下学的地图。
四、我为什么要把它写成一个系列
如果只是自己看课，做点笔记，当然也行。
但我最后还是决定把它写成系列，原因很简单：我想把这个学习过程变成一组可复盘的判断，而不是一堆躺在本地文件夹里的摘录。
这里先把边界说清楚。
这个系列不会写成“课程逐字转述”。老师讲什么，我就抄什么，这种文章对读者没什么价值，对我自己也没什么沉淀。
它也不会写成“我已经彻底懂了 Agent，来给大家布道”。我现在还在学习阶段，很多工程边界和真实项目里的坑，也没资格说满。
我更想保留一种学习者姿态：一个长期做服务端和架构的人，正在把自己的旧知识区，慢慢迁移到 Agent 这个新问题域里。
所以后面的文章，我会尽量回答三个问题：这一讲解决什么问题；它和我过去熟悉的架构经验有什么关系；读完之后，我能得到什么阶段性判断。
这三个问题如果答不出来，文章就不发。否则很容易写成“概念都认识，读完没感觉”的笔记文，我自己都不爱看。
五、给同样从传统架构转过来的朋友
如果你和我一样，过去主要靠服务端、架构、设计模式、工程治理这套语言理解系统，那我觉得可以先别急着追每一个 Agent 新名词。
先把问题压小一点。
下一次你看到一个 Agent 方案，或者准备做一个 Agent 小项目时，可以先拿这三个问题过一遍：
- 它到底需要哪些能力，不要把所有东西都塞进一个“智能体”大词里。
- 这些能力怎么执行，不要只看功能清单，要看链路、反馈和退出条件。
- 能力变强之后怎么治理，不要等它能改数据、能发消息、能调接口了才想起来补边界。
也是我读完开篇词后最大的收获：Agent 不只是 AI 应用开发里的一个热词，它正在把软件设计从“代码结构设计”，推向“智能能力设计”。
而我们这些做工程的人，并不是要被迫丢掉过去的经验。
更准确地说，是要带着旧经验，进入一个新坐标。
我现在还不敢说自己已经掌握了这套坐标。但至少从这一讲开始，我知道接下来该往哪里看了。
真正值得学习的不是某个新名词，而是当系统开始具备智能之后，我们还能不能把它设计得可靠。
课程入口
关于十三Tech
All in AI Agent 方向的架构师，专注 AI 工程实践。
相信 AI 是程序员的最佳搭档，帮助每一位开发者驾驭 AI。
联系方式：569893882@qq.com
GitHub：@TriTechAI
