Sandbox-Native智能体的分支策略优化:让AI在模拟世界中学会“动手”
2026/8/21 10:03:18
设计模式中的结构型模式,共7种,按“类/对象组合”维度分类,具体包括:
这七种模式均聚焦于如何组织类与对象之间的关系,以提升系统的灵活性、可扩展性与复用性。
# 示例:简单装饰器模式(Python风格,体现对象组合思想)classComponent:defoperation(self):return"basic operation"classDecorator(Component):def__init__(self,component:Component):self._component=componentdefoperation(self):returnf"decorated({self._component.operation()})"# 使用base=Component()decorated=Decorator(base)print(decorated.operation())# 输出:decorated(basic operation)适配器模式(Adapter)与代理模式(Proxy)在结构上相似(都通过包装目标对象、实现相同接口、委托调用),但意图和应用场景存在本质区别:
| 维度 | 适配器模式(Adapter) | 代理模式(Proxy) |
|---|---|---|
| 核心意图 | 解决接口不兼容问题:让原本因接口不匹配而无法协作的类能一起工作 | 控制对目标对象的访问:为对象提供一个替身或占位符,以附加逻辑(如权限、延迟、日志等) |
| 动机来源 | 外部已有类(第三方库、遗留系统)接口不符合当前需求,需“转换”而非修改 | 目标对象本身可用,但需在访问前后/过程中增强行为或施加约束 |
| 客户端视角 | 客户端不知道也不关心被适配的对象,只面向统一适配后的新接口 | 客户端通常明确知道正在使用代理(或至少感知到间接访问),代理与真实对象接口一致,但语义不同(如“远程代理”暗示网络调用) |
| 生命周期关系 | 适配器通常不控制目标对象的创建与销毁,仅封装已有实例 | 代理常负责目标对象的创建、初始化、缓存或销毁(如虚拟代理延迟加载,智能引用代理管理生命周期) |
| 典型场景 | 将旧版Logger API适配为新ILogger接口;将第三方支付SDK接口转为内部PayService接口 | 访问远程服务(远程代理)、大图加载(虚拟代理)、权限校验(保护代理)、方法调用日志(智能代理) |
✅ 简记口诀:
🔹适配器 = “翻译官”(语言不通,帮你转译);
🔹代理 = “经纪人”(你有权找本人,但我替你安排、把关、增值)。
# 对比示例(Python)fromabcimportABC,abstractmethodclassTarget(ABC):@abstractmethoddefrequest(self)->str:...# —— 适配器:转换Adaptee的incompatible接口classAdaptee:defspecific_request(self)->str:return"Adaptee's specific result"classAdapter(Target):def__init__(self,adaptee:Adaptee):self._adaptee=adaptee# 组合已有对象defrequest(self)->str:returnf"Adapter:{self._adaptee.specific_request()}"# 接口转换# —— 代理:控制对RealSubject的访问classRealSubject(Target):defrequest(self)->str:return"RealSubject's result"classProxy(Target):def__init__(self):self._real_subject=None# 延迟创建defrequest(self)->str:ifself._real_subjectisNone:self._real_subject=RealSubject()print("Proxy: checking access before forwarding...")returnself._real_subject.request()# 使用差异:adapter=Adapter(Adaptee())# 客户端只知Target,不知Adapteeproxy=Proxy()# 客户端用Proxy,隐含“受控访问”语义