一、只知道模式名，离会设计还差很远
以前学设计模式时，有过这样一个阶段：看到一个新模式，就想找地方用。
这很好理解。刚学到一个新工具，总想在真实项目里验证它的价值。可工程里的很多问题，不是“能不能用”，而是“值不值得用”。
Agent 模式也是一样。
比如一个需求来了：做一个能帮用户分析需求并生成方案的 Agent。听起来什么都能往里塞：加记忆、加反思、加并行、加协作，再加治理。
听起来很完整，对吧？
但真这么做，首版大概率会变成一个难以调试的系统。
因为每加一个模式，都不是白送的。记忆会带来污染，反思会增加延迟，并行会放大调用量，协作也会让责任归属更难。
所以，模式不是装饰品。
模式更像系统里的结构性承诺。你用了它，就要承担它带来的复杂度。
这也是现在看第四讲最认同的一点：学习 Agent 模式，不能停在“认识模式”，必须进入“选择模式”。
二、坐标系先把问题放对位置
第三讲里聊过，Agent 设计至少要分清两个维度：能力维度和执行维度。
第四讲往前推进了一步：当这些维度都出现后，怎么真正用起来？
设计坐标系就像一张工程选型地图。
能力维度回答的是“系统要会什么”。比如是否需要感知复杂输入、长期记忆、推理规划、工具行动、反思修正、角色协作和治理边界。
执行维度回答的是“系统怎么跑”。是链式推进，还是路由分流；是并行探索，还是循环修正；是中心编排，还是层级委派。
两个维度合在一起，才开始接近真正的设计问题。
这张图最有价值的地方，不是某个术语，而是它给出了一个顺序：
先评估能力需求，再判断主运行形态，最后为关键能力选择模式。
这个顺序很克制。它没有鼓励把所有模式都堆上去，而是先问：这个任务里，哪几类能力是 heavy 的？也就是强需求能力。
这其实很像做服务端架构选型。
不是一上来就问“要不要微服务”，而是先问业务复杂度、团队规模、数据一致性、稳定性要求。微服务只是一个可能解法。
Agent 模式也一样。
三、首版 Agent 先别急着上“全家桶”
这一讲里有个建议特别朴素，也特别重要：第一版不要堆太多模式。
这句话听起来没那么酷，但很工程。
见过不少系统复杂度失控，都是从“顺手再加一个能力”开始的。最开始只是想记住用户偏好，后来又想自我检查、多角色讨论，最后还要审批。
每一步单看都合理，合在一起就不一定了。
| 首版常见想法 | 更稳的做法 |
|---|---|
| 把七类能力都安排上 | 先找2到3个关键能力 |
| 一上来多Agent协作 | 先验证单体链路是否稳定 |
| 先追求自我反思 | 先定义质量标准和退出条件 |
| 工具能接就都接 | 先明确权限、回滚和审计边界 |
首版克制，是为了更好地接住新能力。
克制是为了让问题可以被观察、被定位、被修正。一个只有三四个关键设计点的 Agent，也更容易知道下一步该把新能力加在哪里。
反过来，如果首版就是全家桶，出问题时很难判断：是模型不行、Prompt 不行、记忆不行，还是拓扑不行。
工程里最可怕的不是系统简单，而是系统复杂到你不知道该改哪里。
所以现在会倾向于把“先少用几个模式”看作一种设计能力，而不是能力不足。
四、GoF 到 Agent，变的不是数量，是问题空间
第四讲里还有一张 GoF 23 和 Agent 28 的对比图。
如果只看数字，很容易误解成：以前23个模式，现在28个模式，所以只是模式库扩容。
但真正的变化不在数量。
GoF 主要处理的是对象世界里的创建、结构和行为。它关心代码对象怎么协作，变化怎么隔离，职责怎么分配。
Agent 模式处理的是智能能力世界里的感知、记忆、推理、行动、反思、协作和治理。它关心能力怎么组合，上下文怎么组织，不确定性怎么被约束。
两个世界有关联，但问题空间不一样。
这也是为什么不会简单地把 Agent 模式理解成“新时代 GoF”。这个说法容易让人以为只是换了一批模式名。
更准确地讲，Agent 模式是在传统软件工程之上，多了一层智能能力设计。
过去我们说“这里用策略模式”，团队大概知道你想隔离一组可替换算法。以后我们说“这里需要反思模式”，也应该能让团队迅速对齐：这个环节质量不稳定，需要生成、评审、修正的反馈闭环。
模式最终要变成团队共同语言，而不是个人知识储备。
五、我会怎么用这张坐标系
如果以后真要从零设计一个 Agent，会把第四讲这套坐标系压成四个问题。
第一个问题：任务里最关键的能力是什么？
不要把“智能体”当成一个整体词。拆开看，是感知复杂，还是记忆关键？是推理路径长，还是行动副作用大？是需要协作，还是更需要治理？
第二个问题：主运行形态是什么？
能链式就别编排，能路由就别层级，能单体跑通就别急着多 Agent。不是因为复杂结构不好，而是复杂结构要有足够理由。
第三个问题：哪些能力值得上 heavy 模式？
不是所有能力都需要重设计。一个首版 Agent 里，真正值得认真打磨的，往往只有少数几个关键点。
第四个问题：每新增一个模式，代价是什么？
成本、延迟、调试难度、可观测性、失败恢复、权限治理，这些都要算进去。模式带来能力，也带来债务。
这四个问题问完，方案可能没那么花哨，但会更接近真实工程。
六、学模式，是为了让选型更可复盘
回到开头那个画面。
当年学 GoF，花了很久才明白：设计模式不是为了把代码弄得看起来更复杂，而是在合适的地方，用一套大家都懂的语言，解决反复出现的问题。
今天学 Agent 设计模式，也是同一个道理。
如果没有坐标系，模式越多，选择越容易靠感觉；如果有坐标系，模式就会从名词表变成选型工具。
现在还在学习阶段，很多模式怎么落到真实项目里，还要继续拆。但第四讲至少让方向想清楚了：先充分理解新模式，再判断“这个问题到底落在哪个坐标上”。
一个靠谱的 Agent 系统，不是把所有聪明能力都塞进去。
真正的设计能力，是知道该让系统聪明在哪里，也知道该让它克制在哪里。