ReentrantReadWriteLock的Strategy模式

主表+扩展表设计模式

建造者模式解决的是：当一个对象有很多参数，其中一些必填、一些选填、一些之间还有约束关系时，直接用构造器或一堆 setter 会让调用方很痛苦。来看问题是怎么出现的。

并行化，就是让 Agent 同时干多件互不依赖的事。不是所有步骤都排队。能同时查新闻、查公告、查知识库，就不要一个一个查。最后再把多个分支的结果合并，生成一个统一答案。并行化不是为了炫技。它解决的是一个很现实的问题：复杂任务太慢。提示链让 Agent 会按步骤做事。路由让 Agent 会选择不同路径。并行化让 Agent 在合适的时候同时推进多个分支。真正的工程重点是：独立分支、统一输出、超时兜底、冲突合并、成本控制。一句话总结：能独立跑的任务，就并行；需要依赖的任务，就串行；

故事联想记忆法速记，总结常用和不常用的设计模式

学习与适应，是 Agent 从“工具调用器”升级成“长期系统”的关键一步。它的核心不是让模型自由发挥，而是建立反馈闭环。能记录。能评估。能诊断。能更新。能验证。能回滚。做到这些，Agent 才能越用越稳，越跑越准。智能体设计模式：学习与适应 Learning & Adaptation：功能变化与行业影响解析_热闻岛。

命令模式是一种行为型设计模式，其核心思想是将请求封装为独立对象，实现调用者和执行者的解耦。该模式包含5个关键角色：Command接口定义执行操作，ConcreteCommand绑定接收者和动作，Receiver执行业务逻辑，Invoker触发命令，Client组装命令对象。 典型应用场景包括：GUI事件处理、撤销/重做功能、任务队列、日志记录和宏命令组合。文中通过智能家居遥控器示例展示C++实现，包括灯光控制、音响调节和组合命令，演示了命令执行和撤销机制。

前面所有章节构建的 Agent 都有一个共同的隐含前提：它们在使用过程中不会成长。你用了一年的 Agent，和你用了一天的 Agent，能力边界完全相同。上周它帮你解决了一个 Python 依赖冲突，下周同样的问题再出现，它依然从零开始思考。这在人类同事的视角里不可想象——一个工作了一年的工程师，绝对不可能和入职第一天一样。自主进化 Agent 要解决的就是这个问题：让 Agent 从"工具"变成"同事"，越用越强。本章讲清楚六件事：你的团队每天都会做"代码提交前检查"这件事：跑 linter、跑测试、写提

资源感知优化，是 Agent 从 Demo 走向生产的关键能力。Demo 可以只追求效果。生产系统必须同时看质量、成本、延迟和稳定性。一句话：小问题别烧大模型，大问题别省关键资源，高风险问题别让 Agent 独自决定。智能体设计模式：资源感知优化 Resource-Aware Optimization_热闻岛。

原型模式把“创建一个新对象”变成“复制一个已经配置好的样板”。它像关卡编辑器里的复制粘贴：设计师先做出一只带属性、掉落、AI 参数的怪物样本，生成器以后只负责克隆。C# 里的浅拷贝很诱人，但游戏对象往往包含列表、引用、资源句柄。原型适合“从样板派生实例”，但不适合隐藏复杂生命周期。对象需要注册系统、申请资源、绑定事件时，克隆后仍要有清晰的初始化阶段。原型模式让对象自己知道如何复制自己，生成器只依赖“可克隆”的抽象。当对象构造过程很复杂，或者类型组合来自数据配置时，继续写一堆。血量/速度/掉落/AI。

这个认知没错，但只覆盖了模板方法 20% 的用法——剩下的 80% 藏在各种 Spring 组件里，你天天在用却从来没把它跟设计模式挂钩。剩下的 6 个步骤是 JdbcTemplate 帮你写好的——这就是模板方法模式的本质：**固定流程 + 可变步骤**。# 你写 JdbcTemplate 的 callback 写了三年——这就是模板方法，但你从没把它当设计模式。ps -> ps.setString(1, "PAID"), // 步骤1：设置参数。8. 归还连接到连接池。

更新顺序会影响结果。对象 A 先更新还是对象 B 先更新，可能改变碰撞、AI 感知或触发事件的结果。需要确定性时，要明确排序规则。游戏里大量对象都有跨帧行为：移动、冷却、动画、生命周期、AI。更新方法让对象把自己的时间推进逻辑封装起来，主循环只负责统一调度。更新方法把“每帧要做的事情”分散到每个对象自己身上。游戏世界像一支队伍，主循环每帧点名，每个对象向前走一步。更新列表遍历时不要直接增删当前集合。使用延迟添加、死亡标记或命令队列，可以避免迭代器失效和跳过对象。

本文系统介绍了软件设计模式的三大类型（创建型、结构型、行为型）及其核心模式。重点讲解了创建型模式中的五种常用模式：简单工厂模式（封装对象创建逻辑）、工厂模式（支持多维度扩展）、抽象工厂模式（解决产品族兼容问题）、单例模式（全局唯一实例）和建造者模式（复杂对象构造）。每种模式都通过代码示例说明其核心思想、适用场景和优缺点，并强调设计原则（如开闭原则、单一职责原则）在模式设计中的重要性。

中介者模式是一种行为设计模式，通过引入中介对象来封装对象间的交互，降低耦合度。核心包括中介者接口、具体中介者和同事类三部分，适用于聊天室、智能家居等需要协调多个组件的场景。文中以C++实现的智能家居系统为例，展示了控制中心（中介者）如何协调灯光、空调等设备（同事类）的交互，实现"早安模式"、"晚安模式"等场景。该模式有效减少了对象间的直接依赖，使系统更易于维护和扩展。

你有没有想过，为什么有些APP用起来就是"顺手"，而有些APP怎么用都"别扭"？答案往往不在于功能多少，而在于交互设计。好的交互设计让用户几乎不需要思考就能完成操作，而差的交互设计让用户每一步都在犹豫——“这个按钮是干什么的？”“我刚才点了什么？”“怎么返回？”智能交互设计更进一步——它不仅让操作"顺手"，还让操作"智能"。系统能根据用户的上下文、习惯、甚至情绪状态，主动预测用户意图，提供最合适的操作路径。比如你每天早上8点都会打开新闻APP，系统在第7天就会在7:58自动把新闻推到你的锁屏上。但智能交互有

工具使用，也叫函数调用。它的核心很简单：把一个外部能力描述给模型，让模型在需要时生成结构化调用请求。真正执行工具的，不是模型。而是你的业务系统。模型只负责三件事：• 判断是否需要工具。• 选择应该调用哪个工具。• 生成这个工具需要的参数。编排层负责后面的事：参数校验、权限判断、调用接口、处理异常、记录日志，再把结果回填给模型。这就是工具型 Agent 的底层逻辑。工具使用，是 Agent 从“聊天”走向“执行”的关键一步。没有工具，大模型只是一个聪明的文本生成器。

这套笔记参考《游戏编程模式》的中文站点目录与章节内容，但不是逐段翻译。这里会把每个模式重新整理成游戏工程里更容易形成“画面”的结构：先看它像什么，再看它解决什么，最后看 C# 代码如何落地。该系列博客仅仅用于个人学习理解和记录，如果想看书籍正版内容，请访问下方的链接，如要转载请表明转载来源！

护栏不是把 Agent 变成“傻瓜模式”。恰恰相反，护栏是让强 Agent 能进入真实业务系统的前提。没有护栏，Agent 只能做 Demo。有了护栏，Agent 才可能接订单、查数据、调接口、改流程、进生产。本章一句话越有执行能力的 Agent，越要有边界、有权限、有审批、有审计。智能体设计模式：护栏与安全 Guardrails_热闻岛。

策略模式（`Strategy Pattern`）是一种**行为型设计模式**，核心思想是**定义一系列算法，将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户端**。

记忆模式组包含四种模式：分层保留（Hierarchical Retention）、检索增强（RAG）、进度追踪（Progress Tracking）、失败日记（Failure Journals）。如果用四个字概括，就是：架、取、录、省。分层保留，解决的是“架”。做记忆系统，最先要定下来的就是层级。先想清楚分几层、每层放什么，再去写代码。