大家好，我是十三～
我长期做服务端设计和架构，对设计模式、系统分层、工程治理这些问题并不陌生。GoF 设计模式也好，面向对象的分工也好，复杂系统里的解耦、扩展和演进也好，这些年也一直在实践。我越来越强烈地感受到：当软件系统开始真正引入大模型和 Agent 之后，过去那套我熟悉的设计语言，依然重要，但已经不足以覆盖 Agent 带来的新问题。
最近朋友推荐了黄佳老师的《Agent 设计模式之美》。看完开篇词，我几乎立刻就决定把这门课写成一个学习笔记系列。
原因很简单：它击中的，刚好就是我这段时间最想补上的那块空白——如果说传统架构设计是我长期熟悉的旧知识区，那么 Agent 工程就是我正在系统学习的新问题域。这门课给我的第一感觉，不是“又一门 AI 热课”，而是它确实很适合像我这样，正从传统研发视角走向 Agent 工程实践的人。
我的当前判断是：Agent 真正带来的变化，不是系统里多接了一个模型，而是软件设计问题的重心正在发生迁移。 过去我们更关心对象如何协作、模块如何分层、接口如何解耦；现在我们不得不开始处理另一组问题：系统该感知什么、该记住什么、该如何推理、怎样行动才不失控、多个角色如何协作、能力变强之后又该如何治理。
如果把话说得再直接一点，Agent 难的从来不是把模型调起来，而是把一套不确定的智能能力，组织成一个可以长期运行、可以持续演进、也可以被治理的系统。
这也是为什么，看完这篇开篇词之后，我会有一种很强的确认感：这件事值得认真学，而且必须系统学。
为什么这门课一下就击中了我
过去一年，关于 Agent 的讨论非常热闹。
有的内容在讲 Prompt，有的在讲工具调用，有的在讲工作流编排，还有很多产品在讲多 Agent 协作。它们当然都重要，但如果只停留在这些表层现象，很容易形成一种误解：好像只要把模型、工具和流程拼起来，一个 Agent 系统就自然成立了。
但从架构和工程的视角看，事情远没有这么简单。
一个 Demo 能跑通，并不意味着系统能成立；一个流程能自动往下走，也不意味着它在真实环境里就稳定、可靠、可控。真正往前走两步，你就会遇到一连串传统服务端系统里不那么典型、但在 Agent 场景里绕不过去的问题：
- 上下文该怎么组织，信息该保留到什么粒度
- 记忆到底是在增强系统，还是在污染系统
- 推理质量、执行延迟和 Token 成本怎么平衡
- 工具调用一旦带来副作用，边界由谁来守
- 一个 Agent 不够时，多个角色之间该如何分工
- 系统越来越强之后，权限、审批、观测、回放这些治理能力要不要一起补上
这些问题之所以重要，不是因为它们“听起来很 AI”，而是因为它们本质上已经是系统设计问题。
也就是说，Agent 的出现，并没有取消软件工程，反而逼着软件工程进入了一个新的问题域。
过去我熟悉的是 GoF，今天我要补的是 Agent 双轴
如果让我用一句最朴素的话来概括这篇开篇词给我的冲击，那就是：我第一次明确意识到，Agent 的设计问题，已经不能只用我过去熟悉的那套语言来覆盖了。
GoF 23 设计模式我很熟。创建型、结构型、行为型，这套语言解决的是经典对象世界里的组织问题：对象怎么创建、模块怎么组合、行为怎么解耦。直到今天，我依然认为这套语言有长期价值，它不会因为 Agent 出现就突然失效。
但 Agent 要处理的东西，显然已经不只是对象之间的关系。
它开始要求我们面对另一种复杂性：系统需要具备哪些认知能力，这些能力之间怎么配合，它们又应该通过什么执行结构被组织起来。换句话说，过去我们更多是在设计“对象如何协作”；而进入 Agent 语境之后，我们还要进一步设计“能力如何协作”。
这也是“Agent 双轴”最打动我的地方。
至少在我当前的理解里，这套框架最有价值的地方，不是提出了几个新术语，而是给了一个新的观察坐标：
- 一条轴，是系统到底需要哪些核心能力
- 另一条轴，是这些能力应该如何被组织、如何被执行
这和我过去熟悉的设计经验之间，其实既有连续性，也有明显的新意。
连续性在于，它依然是在做分解、做抽象、做边界划分。
新的地方在于，过去我们拆的是对象、模块、职责；现在我们开始拆的是感知、记忆、推理、行动、反思、协作、治理这些能力，以及它们背后的执行方式、风险结构和成本结构。
所以，从 GoF 23 到 Agent 双轴，我感受到的不是“旧设计模式没用了”，而是设计问题本身变了。
这篇开篇词给我的第一个新坐标：别再把 Agent 当成一个大词
我很喜欢这篇开篇词的一点，是它没有把 Agent 写成一个含混的大词，而是试图把它拆开来看。
在我当前的理解里，这门课最先给出的一个重要坐标，就是把 Agent 拆成几类可以分别讨论的能力：感知、记忆、推理、行动、反思、协作、治理。
这个拆法为什么对我有价值？
因为它一下子把“Agent 很复杂”这句空话，变成了可以继续往下追问的问题。
以后我们再判断一个 Agent 系统到底强不强，不能只笼统地问它“聪不聪明”，而应该进一步追问：
- 它的问题出在感知，还是出在记忆
- 它是推理不稳，还是行动边界没收住
- 它是单体能力不够，还是协作结构有问题
- 它是生成效果不行，还是治理机制缺位
这背后其实是一种我很熟悉的架构思维：先把问题拆成几个受力面，再分别看约束、边界和代价。
所以这篇内容对我最大的帮助，不是让我立刻“学会了 Agent”，而是让我第一次看到了一个值得继续学下去的分析框架。它把一个原本很容易被写成热词的概念，重新压回到了可以讨论、可以判断、也可以逐步建模的工程语境里。
这篇开篇词给我的第二个新坐标：能力之外，还要看执行结构
如果说前一个坐标是“别把 Agent 当成一个大词”，那么后一个坐标就是：别只盯着能力，还要盯着能力如何被执行。
这是我觉得这篇开篇词非常有价值的地方。
很多时候，我们谈一个智能系统，容易先被“它会什么”吸引：它会不会检索、会不会规划、会不会调用工具、会不会反思。但真正进入工程落地之后，你会慢慢发现，系统最后好不好用，不只取决于它会什么，也取决于这些能力是怎么跑起来的。
是一步一步串行推进，还是多路并行探索？
是由一个中心统一编排，还是由多个角色分工协作？
是一次生成后直接执行，还是要经过反思和迭代？
这些问题，看上去像流程问题，但本质上已经会反过来影响系统的成本、延迟、稳定性、可观测性，以及最终效果。
这也是为什么，我会把这篇开篇词看成一个“换坐标”的开始。它提醒我：Agent 设计不是多学几个 Prompt 技巧，也不是多记几个工作流名词，而是要同时理解能力维度和执行维度。
这也是我为什么愿意把它写成一个系列
如果只是自己读课、自己记笔记，当然也可以。但我还是决定把它写出来，原因很简单：我希望把这个学习过程沉淀成一组逐步成形的判断记录。
这里也想把话说清楚：这个系列不是“我已经把 Agent 全讲透了”，而是“我作为一个长期做架构和服务端的人，正在认真学习一个新的设计问题域”。
所以后面的文章，我会尽量保留两样东西。
第一，是十三原来的写法：问题驱动、判断前置、边界清晰、尽量把复杂问题拆开说清楚。
第二，是学习中的真实姿态：我会明确交代某一讲新在哪里，它击中了我原来知识体系里的哪个空白，它和我过去熟悉的系统设计方法是什么关系，以及基于当前理解，我得出了什么阶段性判断。
这意味着这个系列不会写成两种样子。
一种，是普通课堂笔记：老师讲什么，我就摘什么；概念列出来了，但文章没有自己的重心。
另一种，是假装已经完全吃透 Agent 的布道文：结论说得很满，但少了学习过程，也少了边界感。
我更希望它像一组持续展开的学习文章：既保留一个老架构师的判断力，也保留一个进入新领域的人应有的诚实。
读完这一讲之后，我的阶段性判断是什么
如果现在就让我把这篇开篇词压缩成一句话，那我的判断是：
Agent 值得被认真学习，不是因为它热，而是因为它正在把软件设计从“模块如何组织”进一步推向“认知能力如何组织、执行过程如何组织，以及治理与信任边界如何组织”。
这件事对很多做服务端和架构的人来说，都不会只是一个新工具话题，而更像一次新的设计语言进入视野。
我现在当然还谈不上已经吃透这套语言。很多具体模式、很多双轴上的细节、很多工程实现上的边界，我也还在继续学。
但至少从这篇开篇词开始，我已经可以确认一件事：这门课值得学，这个问题值得认真拆，这个系列也值得慢慢写下去。
如果你和我一样，本来熟悉的是传统架构、服务端系统、GoF 设计模式这些经典语境，但也开始意识到 Agent 正在把设计问题带到新的维度，那么欢迎一起把这套新语言慢慢学透。
关于十三Tech
长期从事服务端架构与系统设计，持续关注工程治理、架构演进与 AI Agent 实践。