大家好，我是十三！欢迎来到十三Tech。
在开篇词里，我聊了为什么要系统学 Agent 设计模式。这一讲往前走了一步，回到了一个更基本的问题：GoF 那套语言，到底哪里不够用了？
这个问题我其实想了很久。工厂、策略、观察者、装饰器，这些模式我用了十几年。对象怎么创建，模块怎么组合，行为怎么解耦，都在我的旧知识区里。GoF 的那套语言，我至今觉得有价值，它不会因为 Agent 出现就突然失效。
但看完第二讲，我意识到一件更重要的事：不是旧语言失效了，而是设计对象变了。
过去我主要是在设计代码结构------对象职责、模块边界、接口契约。现在一旦把大模型、上下文、工具调用、记忆、多 Agent 协作放进系统，问题就不只是"代码怎么组织得优雅"，而是"智能能力怎么组织得可靠"。
这篇文章不是课程摘录，是我读完第二讲之后的阶段性理解：Agent 真正带来的范式变化，不是模式数量从 23 变成 28，而是软件设计开始需要一套新的工程语言。
一、GoF 没失效，它只是回答不了全部问题
这种"旧东西没用了"的判断，听起来很爽，但通常经不起真实项目考验。直到今天，一个系统该怎么封装变化、怎么隔离依赖、怎么保持扩展性，GoF 里很多思想依然有用。
问题在于，Agent 系统多出来了一层过去不常见的复杂度。
以前我们更多关心对象之间的协作：谁创建谁，谁依赖谁，谁负责扩展点。到了 Agent 语境里，我们还要关心能力之间的协作：系统该感知什么，该记住什么，该如何推理，什么时候能行动，出了错怎么反思，多个角色怎么配合，能力变强之后谁来治理。
我把这层变化画成了下面这张图。
这张图想表达的不是"GoF 不重要了"，而是两个坐标解决的问题不一样。
GoF 更像是在回答：代码世界里，结构和行为怎么组织。
Agent 设计更像是在追问：智能系统里，认知能力和执行边界怎么组织。
一个偏对象，一个偏能力。一个偏确定性协作，一个开始进入不确定性治理。它们不是替代关系，更像是上下两层。
这也是我看第二讲时第一个被敲醒的地方：我不能只拿熟悉的服务端设计语言去理解 Agent。那会漏掉很多真正危险的地方。
二、真正麻烦的，不是模型会说话，而是它会行动
很多人第一次做 Agent，容易把注意力放在"模型聪不聪明"上。
我之前也会这样。Prompt 写得好不好，回答准不准，推理链顺不顺，看起来都是最直观的问题。但继续往下走一点，你会发现真正麻烦的地方不是模型会说话，而是它开始接入工具、调用系统、影响真实业务。
只聊天的时候，错了大不了重问。
一旦它能发邮件、改数据、创建任务、调用外部接口，性质就变了。它不再只是生成文本，而是在系统里制造副作用。
这时候问题会突然变多：
| 你以为的问题 | 实际更难的问题 |
|---|---|
| Prompt 怎么写得更好 | 上下文如何持续组织且不污染 |
| 工具怎么接得更多 | 权限、审批、回滚边界怎么守 |
| Agent 怎么更自主 | 自主性和可控性怎么平衡 |
| 多 Agent 怎么分工 | 协作链路如何避免循环和扯皮 |
我看到这里其实有点头大。
因为这些问题太像真实工程了。不是"调一个模型参数"就能解决，而是牵扯成本、延迟、权限、审计、观测、失败恢复。甚至很多时候，模型本身不是最大的问题，系统边界才是。
所以第二讲里提到的范式变化，我现在会理解成一句更工程化的话：
Agent 把软件设计从"模块如何稳定协作"，推向了"智能能力如何在约束中稳定协作"。
这里的关键词不是"智能"，而是"约束"。
没有约束的智能，落到真实系统里，很容易从助手变成风险源。
三、七类能力，是把黑箱拆成能排查的问题
这一讲里有一组很重要的能力划分：感知、记忆、推理、行动、反思、协作、治理。
刚看到这七个词时，我第一反应是：这不就是概念清单吗？
但多看几遍之后，我发现它的价值不在"背下来"，而在"拆开看"。它把一个大而模糊的 Agent 黑箱，拆成几个可以分别设计、分别评估、分别优化的受力面。
我把自己的理解重画成了这张图。
这张图对我最有帮助的地方，是它让我不再问一个特别空的问题："这个 Agent 好不好？"
这个问法太大了，大到没法下手。
更有用的问法应该是：它是感知不完整，还是记忆被污染？是推理链太长导致成本爆了，还是行动边界没有收住？是单体能力不够，还是多 Agent 协作结构本身就乱？
这其实很像我们排查服务端问题。
线上接口慢了，你不会只说"系统不行"。你会拆：是数据库慢，缓存没命中，线程池打满，网络抖动，还是下游服务挂了。
Agent 设计也需要这种拆法。
不是因为拆完就一定解决，而是因为不拆，连问题在哪都看不见。
四、模式不是名词表，而是团队共同语言
我以前学设计模式踩过一个坑：太容易把模式学成名词表。
工厂、策略、观察者、装饰器...背得挺熟，真到项目里还是乱用。后来做项目多了才慢慢明白，模式真正的价值，不是让你显得专业，而是让团队可以用更短的话讨论更复杂的问题。
比如一句"这里用策略模式"，背后其实压缩了很多信息：这里有可替换算法，这里要隔离变化，这里不要让调用方关心具体实现。
Agent 设计模式也应该这样学。
如果只是记住"感知模式、记忆模式、反思模式、多 Agent 协作模式"，意义不大。真正有价值的是，团队以后讨论 Agent 方案时，可以更快对齐问题所在：
"这个方案不是 Prompt 问题，是记忆设计问题。"
"这里不是多加一个 Agent 就行，协作拓扑本身要改。"
"这个工具调用不能直接放开，治理边界没设计。"
这种共同语言，才是模式的收益。
它让经验可以复盘，可以迁移，也可以被新人接住。没有模式，团队只能靠个人感觉一遍遍试；有了模式，试错才有机会沉淀成工程经验。
五、我现在怎么理解这次范式之变
回到开头那个问题：已经懂 GoF 了，为什么还要学 Agent 设计模式？
我现在的答案是：因为它们处理的不是同一层问题。
GoF 让我理解对象世界里的职责和边界。Agent 模式开始逼我理解智能系统里的能力、上下文、执行链路和治理边界。
一个帮我把程序写得更可维护，一个提醒我把智能能力组织得更可靠。
这就是我当前对第二讲的理解。
它不是让我离开软件工程，而是让我意识到：Agent 时代的软件工程，正在多出一层新的设计对象。
我当然还没有完全吃透这套语言。后面具体到感知、记忆、推理、行动这些模式时，肯定还会遇到很多细节和坑。但至少这一讲之后，我已经确认一件事：继续只用"对象和模块"的语言谈 Agent，迟早会不够用。
当系统开始具备智能，架构师要设计的就不只是代码结构，还有智能能力的边界。
关于十三Tech All in AI Agent方向的架构师，专注AI工程实践。 相信AI是程序员的最佳搭档，帮助每一位开发者驾驭AI。
联系方式：569893882@qq.com GitHub：@TriTechAI