尧图网页设计 
撤销重做怎么实现用命令模式把请求对象化关键词命令模式、Command Pattern、设计模式、撤销重做、Agent 工具调用目录一、为什么撤回消息撤销编辑总写得很别扭二、五个角色一段可运行的代码走查三、跑通整条调用链四、三个变体撤销、宏、跨进程4.1 可撤销命令存一份反操作4.2 宏命令命令里套命令4.3 纯数据命令跨进程也扛得住五、它和谁长得像又哪里不同5.1 和策略模式的边界5.2 和备忘录、责任链怎么分工六、这几个坑先替你踩了6.1 业务逻辑写在 Invoker 还是 Receiver6.2 撤销没存前置状态重做会错乱6.3 命令越积越多内存撑爆6.4 异步命令不收尾回调堆成山七、在大模型工程里它出现在哪7.1 把 LLM tool calling 建模成 Command7.2 幂等工具调用把调用当命令而非 RPC7.3 Agent 工具链的统一封装记住这三条就够了你有没有遇到过这种需求一个后台要支持撤回上一步操作“批量执行一组动作”“把用户操作记录下来以后复盘”。如果直接调函数撤回几乎没法做——函数跑完就跑完了你手里什么都没留下批量动作要自己写个 for 把函数挨个再调一遍还得分清顺序想记录操作日志又得在每个函数里都塞一段写库代码。问题不在你代码写得差而是一次操作这个东西在你的代码里是瞬时的、不可捉摸的——它发生了然后就消失了。命令模式Command PatternGoF 1994 收录的行为型模式的解法是别把操作写成一个函数调用而把它做成一个对象。一个命令对象里既装着要干什么也装着干这件事需要的一切上下文于是它可以先被创建、再被传递、再被某个按钮触发、甚至被排进队列延后执行。发送操作的人Invoker完全不知道背后是哪个业务对象在干活他只管触发这个命令。一旦操作变成了对象撤销、重做、批量、日志、队列、跨进程全都从几乎做不到变成了顺手就能加。一、为什么撤回消息撤销编辑总写得很别扭先把痛点说清楚比直接背定义有用。设想一个会话后台运营在后台给一条对话打标签、导出对话、撤回某条消息。打标签这个动作过程式写法就是store.add_tag(conv_id, 已解决)一行调用。它的问题是操作不可回放。用户点完打标签函数返回后你手里什么都不剩。要想撤回只能再写一段几乎一模一样的反向逻辑而且你还得自己记住刚才打的是哪个标签。批量动作要重写一遍流程。产品说一键关闭会话 打’已解决’标签 打’待复盘’标签 导出你只能再写一个close_conversation()把那几个函数又调一遍顺序、异常、部分失败全得重考虑。横切逻辑日志、权限、审计没处挂。你想给每个操作记一条审计日志只能在每个函数里复制一段audit.log(...)改一处要改好几处。一个很经典的对照来自 GUI菜单里的保存和快捷键 CtrlS 触发的是同一件事但如果代码里各写一遍save()改保存逻辑就得改两处漏一处就行为不一致。命令模式把保存做成一个SaveCommand对象菜单项和快捷键都只持有同一个命令引用点哪个都调它的execute()。这个例子之所以经典是因为它把触发动作的多种入口和动作本身彻底分开了——入口可以有无数个动作只有一个。你今天遇到的会话后台撤回、批量、审计难题本质上和菜单与快捷键要调同一个保存是同一类问题入口多、动作要统一管理。这些痛点的共同根源是操作是函数调用调用完就蒸发了。命令模式把操作升级成对象让它能在内存里停留、能被拿着到处走——这一节的所有问题本质都是对象化之后自然解决的。先记住这个结论下面看代码时你会处处看到它的影子。图一命令模式的五个角色各管一段调用方因此和具体业务解耦二、五个角色一段可运行的代码走查命令模式的核心是把请求封装成对象围绕这个对象长出了五个角色。与其背定义不如直接走查一段能跑的代码——我们以会话后台打标签为例把五个角色一个个对上。【命令模式骨架把「会话后台的一个操作」做成对象】fromabcimportABC,abstractmethod# ① Command所有命令的统一接口classCommand(ABC):abstractmethoddefexecute(self)-None:...abstractmethoddefundo(self)-None:...# 可撤销命令的标配先占个位# ② Receiver真正干活的对象会话仓库classConversationStore:def__init__(self):self.tagsset()defadd_tag(self,tag:str)-None:self.tags.add(tag);print(f[store] 已打标签{tag})defremove_tag(self,tag:str)-None:self.tags.discard(tag);print(f[store] 已撤标签{tag})# ③ ConcreteCommand把「打标签」这个请求绑到 ReceiverclassTagConversation(Command):def__init__(self,store:ConversationStore,tag:str):self._storestore;self._tagtagdefexecute(self)-None:self._store.add_tag(self._tag)# 调 Receiver 的业务方法defundo(self)-None:self._store.remove_tag(self._tag)# 反向操作恢复前置状态# ④ Invoker只认 Command 接口不认识 ConversationStoreclassActionBar:def__init__(self):self._history[]defsubmit(self,cmd:Command)-None:cmd.execute();self._history.append(cmd)defundo_last(self)-None:ifself._history:self._history.pop().undo()# ⑤ Client把一切装配起来storeConversationStore()barActionBar()bar.submit(TagConversation(store,已解决))# 打标签bar.undo_last()# 撤回打标签边读边看这五个角色各自负责什么Command抽象命令只声明execute()以及可选的undo()这么一个统一接口。它是 Invoker 和 Receiver 之间的契约——Invoker 永远只认这个接口不认具体业务。Receiver接收者真正执行业务逻辑的对象这里就是ConversationStore。它完全不知道命令的存在只管add_tag/remove_tag这种本职方法。ConcreteCommand具体命令TagConversation把打哪个标签、打在谁的会话上绑死在自己身上并在execute()里转调 Receiver 的方法。它把一个请求固化为一个对象。Invoker触发者ActionBar只持有Command接口调cmd.execute()但全程不知道背后是打标签还是导出还是撤回。它甚至能顺手维护一个_history列表为撤销/重做埋下伏笔。Client装配者最后才是把ConversationStore包进TagConversation、再交给ActionBar的那段代码。只有 Client 知道哪个请求对应哪个 ReceiverInvoker 和 Receiver 彼此绝缘。这套分工里最值钱的一点是Invoker 拿到的永远是一个 Command 对象而不是一个函数调用结果。操作在被触发之前就已经作为一个实体存在了所以你可以把它先存进队列、先记进历史、甚至先序列化发到另一台机器——ActionBar完全不关心这些它只管触发。这就是命令模式所有高级玩法撤销、宏、队列、跨进程的共同起点。如果你写过前端会发现它和 Redux 的 action 思路异曲同工action 也是一个描述了要做什么的纯对象dispatch 它而不是直接改状态命令模式的 Command 只是把这个思路用面向对象的方式显式化了——多了 Receiver 这一层专职干活的实体。理解了这层对应关系命令模式就不再是又一个要背的 GoF 模式而是一种你已经用过的思想只是这次它有了更明确的角色分工和生命周期。三、跑通整条调用链把上面的角色连起来一条命令从出生到能被撤销经历的是这样一个生命周期Client 先创建 Receiver把请求包进 ConcreteCommand再把命令交给 InvokerInvoker 在合适的时机调execute()ConcreteCommand 转头去调 Receiver 的业务方法业务才真正发生如果命令支持撤销Invoker 还能从历史里把它捞出来调undo()。注意全程被传递、被存储、被触发的是同一个命令对象而不是一段函数。图二一条命令的生命周期——装配、入队、触发、执行、撤销全程是对象在流转这个对象化带来的直接好处用一段对照就能看清过程式写法下撤回一个操作意味着再调一次反向函数而且你得自己记得反转参数命令模式下撤回就是history.pop().undo()——命令对象自己知道怎么把自己撤销掉调用方零成本。这也是为什么 GUI 的撤销/重做、游戏的回放、终端的操作日志几乎清一色选命令模式它们要的不是再算一遍而是把刚才那件事原样退回去。把命令对象存进队列这件事打开了过程式写法完全没有的可能性你可以把用户连续做的十个操作先收进队列等网络空闲时再批量 drain也可以在执行前统一插一道权限检查只有can_execute(cmd)返回 True 才真正execute()甚至可以把整个队列序列化到磁盘进程重启后接着跑。这些能力的共同前提是操作是一个能停留的对象——而传统函数调用在这一步就断了函数返回后栈帧一收你什么都抓不住。所以命令模式的本质是用对象的生命周期换来了对操作的掌控权。四、三个变体撤销、宏、跨进程基础骨架不变按需求能长出三种最常见的变体。理解它们基本就覆盖了命令模式 80% 的使用场景。值得一提的是这三种变体并不互斥——一个 ConcreteCommand 完全可以同时支持undo()变体一又作为宏命令的子项变体二而宏命令整体又能序列化成纯数据变体三跨进程传输。理解变体不是为了背分类而是为了在需求变化时知道该在骨架的哪一处加能力要可撤销就补undo()要组合就包一层宏要跨进程就把逻辑抽成 Handler。骨架始终不变长出来的只是能力。4.1 可撤销命令存一份反操作最经典的变体。让Command多一个undo()执行前先把撤销需要的前置状态记下来。我们前面的TagConversation就是这个思路execute调add_tagundo调remove_tag两个操作天然互逆所以不需要额外存状态。但有些操作撤销不是简单反函数——比如把会话标题从 A 改成 B撤销时你得知道原来的标题是 A。这种就得在执行前把 A 存进命令对象里【可撤销命令执行前先把前置状态存进命令自身】classRenameConversation(Command):def__init__(self,store,conv_id,new_title):self._store,self._conv_id,self._newstore,conv_id,new_title self._oldNone# 撤销时要用的前置状态defexecute(self):self._oldself._store.get_title(self._conv_id)# 先记下来self._store.set_title(self._conv_id,self._new)defundo(self):ifself._oldisnotNone:self._store.set_title(self._conv_id,self._old)# 改回去关键点前置状态由命令自己保管Receiver 不用为怎么回滚操心。撤销时即使过了很久、中间夹着别的操作只要这个命令对象还在历史栈里就能精准退回当时的状态。4.2 宏命令命令里套命令宏命令MacroCommand内部持有一组子命令execute()依次调每一个undo()通常逆序回退。它把一组动作也变成一个命令对象于是一键批量操作和单个操作在 Invoker 眼里没有任何区别——都是submit(cmd)。【宏命令命令里再装一组命令】classMacroCommand(Command):def__init__(self,cmds):self._cmdslist(cmds)defexecute(self):forcinself._cmds:c.execute()defundo(self):forcinreversed(self._cmds):c.undo()# 逆序撤销保证语义正确closingMacroCommand([TagConversation(store,已解决),TagConversation(store,待复盘),])bar.submit(closing)# 一键打两组标签撤销也一次性回退宏命令的实用价值在组合即新命令你不用为关闭会话这种复合动作新写一个大类把已有命令拼起来就是新命令而且它天然支持整体撤销——这对事务性操作要么全成、要么全退特别友好。4.3 纯数据命令跨进程也扛得住前两种命令都把逻辑 数据打包在一个 Python 对象里没法跨进程。第三种做法是把命令拆成纯数据和执行器命令对象只带tool、args、call_id这些参数可 JSON 序列化真正执行的逻辑放在另一端的 Handler 里。这正是 MediatR、Wolverine 这类 mediator 框架的思路——命令在网络上飞的是数据落地后才由本地 Handler 执行。【纯数据命令命令只带参数执行逻辑另放 Handler】importjsonfromdataclassesimportdataclassdataclassclassToolCallCommand:tool:strargs:dictcall_id:str# 幂等键重试时复用同一个defto_wire(self)-str:returnjson.dumps({tool:self.tool,args:self.args,call_id:self.call_id})classToolHandler:# 在远端 / 另进程执行defhandle(self,cmd:ToolCallCommand):print(f[handler] 执行{cmd.tool}({cmd.args}) id{cmd.call_id})这种命令即数据的变体是后面讲 Agent 工具调用时的主角——因为大模型要调的工具本质上就是一串要发给远端执行的参数。图三同一套骨架按需求长出三种变体——可撤销、宏命令、纯数据跨进程五、它和谁长得像又哪里不同命令模式常被和另外几个模式搞混因为它们名字里都带解耦。但解耦的对象完全不同一句话就能分清。下面两个是最常见的误用现场把本该用策略的换算法写成了命令结果命令类里塞满算法分支撤销、队列这些能力从没用过或者反过来把本该记录的操作写成了一次性函数结果产品一要撤销就抓瞎。先把边界划清能省掉大把返工。另外还有一个容易和命令混的是观察者模式它解决状态变了通知谁和命令解决把请求做成对象不在一个维度一般不会撞车只是初学者常把按钮点了通知监听者和按钮点了执行一个命令搞混——前者是广播通知后者是定向触发一个动作。5.1 和策略模式的边界策略模式Strategy封装的是怎么做——一个算法族运行时挑一个换上调用方和具体算法解耦。命令模式封装的是做什么——一个请求对象它不止能换实现还能被排队、被记录、被撤销。区别的关键在生命周期策略对象通常是被调一下就完命令对象在被触发前可以长期存活、反复流转。如果你要的是同一个接口换不同算法用策略如果你要的是把一次操作存起来以后再说用命令。一个很实在的判断需要 undo / 队列 / 日志里任意一个命令模式就比策略更合适因为策略接口里根本没有撤销或记录的位置。5.2 和备忘录、责任链怎么分工备忘录Memento封装某一刻的状态快照。它常和命令搭档命令负责触发动作undo()负责把对象恢复到备忘录存的那一刻。两者一个管动作、一个管状态配合起来才是完整的撤销机制。**责任链Chain of Responsibility**解决的是一串请求谁来处理的接力和命令解决把请求做成对象是两个维度——前面讲责任链时说过网关里常同时出现两者外层用代理包壳、内层用责任链把鉴权→限流→日志→路由一排节点串起来而其中每一节点的执行某个具体动作又可以用命令对象来表达。一句话区分三兄弟命令管请求、策略管算法、备忘录管状态。把它们摆在一起看会更清楚图四命令、策略、备忘录各封装了不同的东西——请求、算法、状态六、这几个坑先替你踩了理论讲完落地时真正会让你返工的是下面这几个。每个都用问句点出来方便对号入座——它们不是边角案例而是几乎每个第一次用命令模式的人都会在某处栽一下。尤其要提醒的是命令模式带来的可撤销、可记录是能力也是负担——一旦你存了历史就要为历史负责内存、一致性、并发。所以下面四个坑核心都围绕你存下的那个命令对象到底该活多久、该记什么活太久占内存记太少撤销会错乱异步收不了尾就变成黑盒。先把这几个边界想清楚命令模式才是帮你省事的工具而不是反过来。6.1 业务逻辑写在 Invoker 还是 Receiver这是最容易分不清的归属问题。记住一条Receiver 持有业务逻辑Invoker 只负责触发和调度ConcreteCommand 只负责把请求转交给正确的 Receiver 方法。Invoker 里切忌出现if cmd.type tag: store.add_tag(...)这种业务分支——一旦 Invoker 开始懂业务它就和具体命令耦合了命令模式的解耦收益立刻归零。Invoker 该关心的只有把这个命令 execute 掉、记进历史、可能撤销至于执行什么它一概不知。一个信号能帮你自查如果你的 Invoker 里出现了针对某类命令的特殊判断说明那段逻辑放错地方了应该下沉到对应的 ConcreteCommand 或 Receiver。6.2 撤销没存前置状态重做会错乱这是撤销功能最隐蔽的 bug。很多操作不是简单反函数前面举的改标题就是如果你只在undo()里写死一个反向动作、却没在执行前保存前置状态那么改标题 A→B→再撤回会变成改成某个写死的旧值而不是真正的 A。正确做法是命令对象在执行前把撤销所需的前置状态存进自己身上见 4.1 的self._oldundo()只依赖这份存下来的状态。再往前一步如果同一个 Receiver 上多个命令交错执行打标签、改名、导出撤销一定要按历史栈逆序回放否则会覆盖掉别人刚做的操作——宏命令的reversed撤销就是这个意思。6.3 命令越积越多内存撑爆一旦你用命令模式做无限撤销或全量操作日志历史栈会一直涨。长时间运行的后台几万次操作后历史列表可能占掉可观内存甚至引发泄漏。解法分两档一是给历史栈设上限只保留最近 N 步更早的丢弃代价是不能无限撤销但多数业务够用二是把命令序列化落库而不是全留内存需要复盘时再从库里读。关键是在设计之初就决定历史是有限窗口还是持久化别等内存报警才想起来——到了那时候已经在内存里丢掉的命令是找不回来的。6.4 异步命令不收尾回调堆成山命令模式本身是同步语义execute()直接跑完但现代后台大量操作是异步的发消息、调外部 API、导出一个大文件。如果直接在execute()里await一个长任务Invoker 会被卡住如果甩一个回调进去又不跟踪命令对象执行到哪一步、成没成功就全成了黑盒。处理异步命令要给它一个明确的终态概念要么execute()只负责提交任务并拿到一个 future/任务句柄就返回终态由回调或轮询更新到命令对象上要么用纯数据命令4.3 那种把任务丢给远端 Handler本地只管发和收。无论哪种都要保证命令对象能回答我现在是成功、失败还是进行中否则历史栈里的命令状态永远对不上真实世界。七、在大模型工程里它出现在哪命令模式在 LLM 工程里出现得比想象中频繁因为模型要做的动作天然适合被建模成命令对象一个 tool call 就是一次请求它要被调度、要能撤销、要能排队、还要能在多轮对话间被记录和复盘。下面给三个贴着可运行骨架的场景。为什么偏偏是大模型工程把命令模式用得顺因为 Agent 的每一次动手都是一个需要被监管的副作用——发邮件、改数据库、调 API这些动作一旦发出去就难以收回。把它们做成命令对象意味着要不要执行、执行前记一笔、出错了怎么退都能统一处理而不是散落在模型调用前后的各处 if 里。这种建模方式在真实框架里并不少见LangChain 的 Tool 调用、OpenAI 的 function calling 返回结构本质上都是模型给出一组待执行的参数。把它们包成命令对象等于在模型与副作用之间加了一道你完全可控的闸门——模型只负责我决定现在发一封邮件剩下的执行、限流、回滚全交给 Invoker。顺着这条线再往前想一步当 Agent 能调用的工具越来越多模型产出命令、统一管道执行的分工会越来越值钱它把一个大模型 Agent 的动手能力用命令模式收口成了可治理的资源。7.1 把 LLM tool calling 建模成 Command大模型返回的 tool_call本质上就是我要执行什么、参数是什么。把它包成一个ToolCallCommand配上支持撤销和调度的InvokerAgent 的工具调用就从裸调函数升级成受管控的操作流【LLM tool calling 建模为命令可撤销、可调度】fromabcimportABC,abstractmethodclassToolCallCommand(ABC):abstractmethoddefexecute(self):...abstractmethoddefundo(self):...classSendEmailCommand(ToolCallCommand):def__init__(self,mailer,to,body):self._mailer,self._to,self._bodymailer,to,body self._sent_idNonedefexecute(self):self._sent_idself._mailer.send(self._to,self._body)# 真正发信defundo(self):ifself._sent_id:self._mailer.recall(self._sent_id)# 撤回已发邮件classAgentInvoker:def__init__(self):self._log[]defrun(self,cmd:ToolCallCommand):cmd.execute();self._log.append(cmd)# 执行并记入日志defrollback_last(self):ifself._log:self._log.pop().undo()注意UndoableCommand的思路直接复用发邮件前记下sent_id撤销时调recall。Agent 在真正动手前多一层命令封装等于给所有工具调用套上了统一的执行 记录 回滚管道。7.2 幂等工具调用把调用当命令而非 RPCAgent 调工具时最怕重试导致重复副作用网络抖动框架自动重试了一次send_email结果同一封邮件发了两遍。把 tool call 当成 RPC 来调重试就是再发一次请求把它当成带幂等键的事务性命令重试时复用同一个call_idReceiver 端发现这个 call_id 已经执行过就直接返回上次结果不再产生新副作用【幂等命令同一 call_id 重试不产生重复副作用】 SEEN{}# 真实系统里换成 Redis / 数据库defhandle_tool_call(cmd:ToolCallCommand):ifcmd.call_idinSEEN:# 已经处理过直接返回returnSEEN[cmd.call_id]resultcmd.execute_once()# 真正执行一次SEEN[cmd.call_id]result# 记下后续重试复用returnresult这里call_id就是命令对象身上的幂等键呼应 4.3 的纯数据命令。把工具调用当成带身份的命令而非无状态的远程过程是 Agent 生产化的一个关键细节——否则任何一次重试都可能变成一次事故。7.3 Agent 工具链的统一封装当 Agent 能用的工具变多搜索、计算、查库、发消息、写文件用一个ToolInvoker统一收口所有调用天然就能获得队列、日志、权限、限流的能力而每个工具只需实现自己的Command【Agent 工具链统一 Invoker 收口所有工具调用】classToolInvoker:def__init__(self):self._queue[];self._done[]defenqueue(self,cmd:ToolCallCommand):self._queue.append(cmd)defdrain(self):# 批量顺序执行whileself._queue:cmdself._queue.pop(0)cmd.execute();self._done.append(cmd)defundo_all(self):# 整条链回退whileself._done:self._done.pop().undo()invokerToolInvoker()invoker.enqueue(SearchCommand(订单状态))invoker.enqueue(SendEmailCommand(mailer,ax.com,已处理))invoker.drain()# 先搜后发整体有序、可回退enqueuedrain把一次 Agent 动作变成了可编排的命令队列你可以先做权限校验再执行、可以整体撤销、可以把队列序列化后异步跑。这正是命令模式在 Agent 工程里的价值落点——模型只负责产出命令执行、调度、回滚全部交给统一的 Invoker。当你把工具调用、消息发送、数据写入都收口成命令Agent 的行为能力就从一堆散落的 API 调用变成了一条可观测、可重放、可治理的操作流。出问题时不只是看日志猜发生了什么而是能直接拿着历史命令对象逐步回放、定点回滚——这对线上 Agent 的可靠性提升是结构性的而不是修修补补。记住这三条就够了命令模式落到工程里真正要刻进肌肉记忆的只有三条把操作做成对象而不是一次函数调用——对象能传递、排队、记录、撤销函数调用完就蒸发了。这是所有高级玩法的根。Receiver 持业务逻辑Invoker 只管调度ConcreteCommand 只做转交。Invoker 一旦开始懂业务解耦收益立刻归零。要撤销就自己存前置状态历史栈要设上限或落库——这两点决定你的撤销是稳的还是上线三天后内存报警、且回滚错乱。顺带划一道边界不是所有调一下函数都该上命令模式。如果你的操作永远只执行一次、不需要撤销/队列/日志/跨进程那直接调函数反而更直白命令模式真正的收益在操作需要被管理的时候——可撤销、可批量、可记录、可跨进程。一个很实用的进场信号当你发现自己开始给每个函数复制粘贴写日志 记历史 错误处理这段代码或者产品第一次提能不能加个撤销那就是命令模式该进场的时候了。反过来如果操作永远只有调一下就完硬上命令模式只会多绕一层弯。#命令模式 #CommandPattern #设计模式 #撤销重做 #Agent工具调用 一文带你吃透命令模式
撤销重做怎么实现用命令模式把请求对象化关键词命令模式、Command Pattern、设计模式、撤销重做、Agent 工具调用目录一、为什么撤回消息撤销编辑总写得很别扭二、五个角色一段可运行的代码走查三、跑通整条调用链四、三个变体撤销、宏、跨进程4.1 可撤销命令存一份反操作4.2 宏命令命令里套命令4.3 纯数据命令跨进程也扛得住五、它和谁长得像又哪里不同5.1 和策略模式的边界5.2 和备忘录、责任链怎么分工六、这几个坑先替你踩了6.1 业务逻辑写在 Invoker 还是 Receiver6.2 撤销没存前置状态重做会错乱6.3 命令越积越多内存撑爆6.4 异步命令不收尾回调堆成山七、在大模型工程里它出现在哪7.1 把 LLM tool calling 建模成 Command7.2 幂等工具调用把调用当命令而非 RPC7.3 Agent 工具链的统一封装记住这三条就够了你有没有遇到过这种需求一个后台要支持撤回上一步操作“批量执行一组动作”“把用户操作记录下来以后复盘”。如果直接调函数撤回几乎没法做——函数跑完就跑完了你手里什么都没留下批量动作要自己写个 for 把函数挨个再调一遍还得分清顺序想记录操作日志又得在每个函数里都塞一段写库代码。问题不在你代码写得差而是一次操作这个东西在你的代码里是瞬时的、不可捉摸的——它发生了然后就消失了。命令模式Command PatternGoF 1994 收录的行为型模式的解法是别把操作写成一个函数调用而把它做成一个对象。一个命令对象里既装着要干什么也装着干这件事需要的一切上下文于是它可以先被创建、再被传递、再被某个按钮触发、甚至被排进队列延后执行。发送操作的人Invoker完全不知道背后是哪个业务对象在干活他只管触发这个命令。一旦操作变成了对象撤销、重做、批量、日志、队列、跨进程全都从几乎做不到变成了顺手就能加。一、为什么撤回消息撤销编辑总写得很别扭先把痛点说清楚比直接背定义有用。设想一个会话后台运营在后台给一条对话打标签、导出对话、撤回某条消息。打标签这个动作过程式写法就是store.add_tag(conv_id, 已解决)一行调用。它的问题是操作不可回放。用户点完打标签函数返回后你手里什么都不剩。要想撤回只能再写一段几乎一模一样的反向逻辑而且你还得自己记住刚才打的是哪个标签。批量动作要重写一遍流程。产品说一键关闭会话 打’已解决’标签 打’待复盘’标签 导出你只能再写一个close_conversation()把那几个函数又调一遍顺序、异常、部分失败全得重考虑。横切逻辑日志、权限、审计没处挂。你想给每个操作记一条审计日志只能在每个函数里复制一段audit.log(...)改一处要改好几处。一个很经典的对照来自 GUI菜单里的保存和快捷键 CtrlS 触发的是同一件事但如果代码里各写一遍save()改保存逻辑就得改两处漏一处就行为不一致。命令模式把保存做成一个SaveCommand对象菜单项和快捷键都只持有同一个命令引用点哪个都调它的execute()。这个例子之所以经典是因为它把触发动作的多种入口和动作本身彻底分开了——入口可以有无数个动作只有一个。你今天遇到的会话后台撤回、批量、审计难题本质上和菜单与快捷键要调同一个保存是同一类问题入口多、动作要统一管理。这些痛点的共同根源是操作是函数调用调用完就蒸发了。命令模式把操作升级成对象让它能在内存里停留、能被拿着到处走——这一节的所有问题本质都是对象化之后自然解决的。先记住这个结论下面看代码时你会处处看到它的影子。图一命令模式的五个角色各管一段调用方因此和具体业务解耦二、五个角色一段可运行的代码走查命令模式的核心是把请求封装成对象围绕这个对象长出了五个角色。与其背定义不如直接走查一段能跑的代码——我们以会话后台打标签为例把五个角色一个个对上。【命令模式骨架把「会话后台的一个操作」做成对象】fromabcimportABC,abstractmethod# ① Command所有命令的统一接口classCommand(ABC):abstractmethoddefexecute(self)-None:...abstractmethoddefundo(self)-None:...# 可撤销命令的标配先占个位# ② Receiver真正干活的对象会话仓库classConversationStore:def__init__(self):self.tagsset()defadd_tag(self,tag:str)-None:self.tags.add(tag);print(f[store] 已打标签{tag})defremove_tag(self,tag:str)-None:self.tags.discard(tag);print(f[store] 已撤标签{tag})# ③ ConcreteCommand把「打标签」这个请求绑到 ReceiverclassTagConversation(Command):def__init__(self,store:ConversationStore,tag:str):self._storestore;self._tagtagdefexecute(self)-None:self._store.add_tag(self._tag)# 调 Receiver 的业务方法defundo(self)-None:self._store.remove_tag(self._tag)# 反向操作恢复前置状态# ④ Invoker只认 Command 接口不认识 ConversationStoreclassActionBar:def__init__(self):self._history[]defsubmit(self,cmd:Command)-None:cmd.execute();self._history.append(cmd)defundo_last(self)-None:ifself._history:self._history.pop().undo()# ⑤ Client把一切装配起来storeConversationStore()barActionBar()bar.submit(TagConversation(store,已解决))# 打标签bar.undo_last()# 撤回打标签边读边看这五个角色各自负责什么Command抽象命令只声明execute()以及可选的undo()这么一个统一接口。它是 Invoker 和 Receiver 之间的契约——Invoker 永远只认这个接口不认具体业务。Receiver接收者真正执行业务逻辑的对象这里就是ConversationStore。它完全不知道命令的存在只管add_tag/remove_tag这种本职方法。ConcreteCommand具体命令TagConversation把打哪个标签、打在谁的会话上绑死在自己身上并在execute()里转调 Receiver 的方法。它把一个请求固化为一个对象。Invoker触发者ActionBar只持有Command接口调cmd.execute()但全程不知道背后是打标签还是导出还是撤回。它甚至能顺手维护一个_history列表为撤销/重做埋下伏笔。Client装配者最后才是把ConversationStore包进TagConversation、再交给ActionBar的那段代码。只有 Client 知道哪个请求对应哪个 ReceiverInvoker 和 Receiver 彼此绝缘。这套分工里最值钱的一点是Invoker 拿到的永远是一个 Command 对象而不是一个函数调用结果。操作在被触发之前就已经作为一个实体存在了所以你可以把它先存进队列、先记进历史、甚至先序列化发到另一台机器——ActionBar完全不关心这些它只管触发。这就是命令模式所有高级玩法撤销、宏、队列、跨进程的共同起点。如果你写过前端会发现它和 Redux 的 action 思路异曲同工action 也是一个描述了要做什么的纯对象dispatch 它而不是直接改状态命令模式的 Command 只是把这个思路用面向对象的方式显式化了——多了 Receiver 这一层专职干活的实体。理解了这层对应关系命令模式就不再是又一个要背的 GoF 模式而是一种你已经用过的思想只是这次它有了更明确的角色分工和生命周期。三、跑通整条调用链把上面的角色连起来一条命令从出生到能被撤销经历的是这样一个生命周期Client 先创建 Receiver把请求包进 ConcreteCommand再把命令交给 InvokerInvoker 在合适的时机调execute()ConcreteCommand 转头去调 Receiver 的业务方法业务才真正发生如果命令支持撤销Invoker 还能从历史里把它捞出来调undo()。注意全程被传递、被存储、被触发的是同一个命令对象而不是一段函数。图二一条命令的生命周期——装配、入队、触发、执行、撤销全程是对象在流转这个对象化带来的直接好处用一段对照就能看清过程式写法下撤回一个操作意味着再调一次反向函数而且你得自己记得反转参数命令模式下撤回就是history.pop().undo()——命令对象自己知道怎么把自己撤销掉调用方零成本。这也是为什么 GUI 的撤销/重做、游戏的回放、终端的操作日志几乎清一色选命令模式它们要的不是再算一遍而是把刚才那件事原样退回去。把命令对象存进队列这件事打开了过程式写法完全没有的可能性你可以把用户连续做的十个操作先收进队列等网络空闲时再批量 drain也可以在执行前统一插一道权限检查只有can_execute(cmd)返回 True 才真正execute()甚至可以把整个队列序列化到磁盘进程重启后接着跑。这些能力的共同前提是操作是一个能停留的对象——而传统函数调用在这一步就断了函数返回后栈帧一收你什么都抓不住。所以命令模式的本质是用对象的生命周期换来了对操作的掌控权。四、三个变体撤销、宏、跨进程基础骨架不变按需求能长出三种最常见的变体。理解它们基本就覆盖了命令模式 80% 的使用场景。值得一提的是这三种变体并不互斥——一个 ConcreteCommand 完全可以同时支持undo()变体一又作为宏命令的子项变体二而宏命令整体又能序列化成纯数据变体三跨进程传输。理解变体不是为了背分类而是为了在需求变化时知道该在骨架的哪一处加能力要可撤销就补undo()要组合就包一层宏要跨进程就把逻辑抽成 Handler。骨架始终不变长出来的只是能力。4.1 可撤销命令存一份反操作最经典的变体。让Command多一个undo()执行前先把撤销需要的前置状态记下来。我们前面的TagConversation就是这个思路execute调add_tagundo调remove_tag两个操作天然互逆所以不需要额外存状态。但有些操作撤销不是简单反函数——比如把会话标题从 A 改成 B撤销时你得知道原来的标题是 A。这种就得在执行前把 A 存进命令对象里【可撤销命令执行前先把前置状态存进命令自身】classRenameConversation(Command):def__init__(self,store,conv_id,new_title):self._store,self._conv_id,self._newstore,conv_id,new_title self._oldNone# 撤销时要用的前置状态defexecute(self):self._oldself._store.get_title(self._conv_id)# 先记下来self._store.set_title(self._conv_id,self._new)defundo(self):ifself._oldisnotNone:self._store.set_title(self._conv_id,self._old)# 改回去关键点前置状态由命令自己保管Receiver 不用为怎么回滚操心。撤销时即使过了很久、中间夹着别的操作只要这个命令对象还在历史栈里就能精准退回当时的状态。4.2 宏命令命令里套命令宏命令MacroCommand内部持有一组子命令execute()依次调每一个undo()通常逆序回退。它把一组动作也变成一个命令对象于是一键批量操作和单个操作在 Invoker 眼里没有任何区别——都是submit(cmd)。【宏命令命令里再装一组命令】classMacroCommand(Command):def__init__(self,cmds):self._cmdslist(cmds)defexecute(self):forcinself._cmds:c.execute()defundo(self):forcinreversed(self._cmds):c.undo()# 逆序撤销保证语义正确closingMacroCommand([TagConversation(store,已解决),TagConversation(store,待复盘),])bar.submit(closing)# 一键打两组标签撤销也一次性回退宏命令的实用价值在组合即新命令你不用为关闭会话这种复合动作新写一个大类把已有命令拼起来就是新命令而且它天然支持整体撤销——这对事务性操作要么全成、要么全退特别友好。4.3 纯数据命令跨进程也扛得住前两种命令都把逻辑 数据打包在一个 Python 对象里没法跨进程。第三种做法是把命令拆成纯数据和执行器命令对象只带tool、args、call_id这些参数可 JSON 序列化真正执行的逻辑放在另一端的 Handler 里。这正是 MediatR、Wolverine 这类 mediator 框架的思路——命令在网络上飞的是数据落地后才由本地 Handler 执行。【纯数据命令命令只带参数执行逻辑另放 Handler】importjsonfromdataclassesimportdataclassdataclassclassToolCallCommand:tool:strargs:dictcall_id:str# 幂等键重试时复用同一个defto_wire(self)-str:returnjson.dumps({tool:self.tool,args:self.args,call_id:self.call_id})classToolHandler:# 在远端 / 另进程执行defhandle(self,cmd:ToolCallCommand):print(f[handler] 执行{cmd.tool}({cmd.args}) id{cmd.call_id})这种命令即数据的变体是后面讲 Agent 工具调用时的主角——因为大模型要调的工具本质上就是一串要发给远端执行的参数。图三同一套骨架按需求长出三种变体——可撤销、宏命令、纯数据跨进程五、它和谁长得像又哪里不同命令模式常被和另外几个模式搞混因为它们名字里都带解耦。但解耦的对象完全不同一句话就能分清。下面两个是最常见的误用现场把本该用策略的换算法写成了命令结果命令类里塞满算法分支撤销、队列这些能力从没用过或者反过来把本该记录的操作写成了一次性函数结果产品一要撤销就抓瞎。先把边界划清能省掉大把返工。另外还有一个容易和命令混的是观察者模式它解决状态变了通知谁和命令解决把请求做成对象不在一个维度一般不会撞车只是初学者常把按钮点了通知监听者和按钮点了执行一个命令搞混——前者是广播通知后者是定向触发一个动作。5.1 和策略模式的边界策略模式Strategy封装的是怎么做——一个算法族运行时挑一个换上调用方和具体算法解耦。命令模式封装的是做什么——一个请求对象它不止能换实现还能被排队、被记录、被撤销。区别的关键在生命周期策略对象通常是被调一下就完命令对象在被触发前可以长期存活、反复流转。如果你要的是同一个接口换不同算法用策略如果你要的是把一次操作存起来以后再说用命令。一个很实在的判断需要 undo / 队列 / 日志里任意一个命令模式就比策略更合适因为策略接口里根本没有撤销或记录的位置。5.2 和备忘录、责任链怎么分工备忘录Memento封装某一刻的状态快照。它常和命令搭档命令负责触发动作undo()负责把对象恢复到备忘录存的那一刻。两者一个管动作、一个管状态配合起来才是完整的撤销机制。**责任链Chain of Responsibility**解决的是一串请求谁来处理的接力和命令解决把请求做成对象是两个维度——前面讲责任链时说过网关里常同时出现两者外层用代理包壳、内层用责任链把鉴权→限流→日志→路由一排节点串起来而其中每一节点的执行某个具体动作又可以用命令对象来表达。一句话区分三兄弟命令管请求、策略管算法、备忘录管状态。把它们摆在一起看会更清楚图四命令、策略、备忘录各封装了不同的东西——请求、算法、状态六、这几个坑先替你踩了理论讲完落地时真正会让你返工的是下面这几个。每个都用问句点出来方便对号入座——它们不是边角案例而是几乎每个第一次用命令模式的人都会在某处栽一下。尤其要提醒的是命令模式带来的可撤销、可记录是能力也是负担——一旦你存了历史就要为历史负责内存、一致性、并发。所以下面四个坑核心都围绕你存下的那个命令对象到底该活多久、该记什么活太久占内存记太少撤销会错乱异步收不了尾就变成黑盒。先把这几个边界想清楚命令模式才是帮你省事的工具而不是反过来。6.1 业务逻辑写在 Invoker 还是 Receiver这是最容易分不清的归属问题。记住一条Receiver 持有业务逻辑Invoker 只负责触发和调度ConcreteCommand 只负责把请求转交给正确的 Receiver 方法。Invoker 里切忌出现if cmd.type tag: store.add_tag(...)这种业务分支——一旦 Invoker 开始懂业务它就和具体命令耦合了命令模式的解耦收益立刻归零。Invoker 该关心的只有把这个命令 execute 掉、记进历史、可能撤销至于执行什么它一概不知。一个信号能帮你自查如果你的 Invoker 里出现了针对某类命令的特殊判断说明那段逻辑放错地方了应该下沉到对应的 ConcreteCommand 或 Receiver。6.2 撤销没存前置状态重做会错乱这是撤销功能最隐蔽的 bug。很多操作不是简单反函数前面举的改标题就是如果你只在undo()里写死一个反向动作、却没在执行前保存前置状态那么改标题 A→B→再撤回会变成改成某个写死的旧值而不是真正的 A。正确做法是命令对象在执行前把撤销所需的前置状态存进自己身上见 4.1 的self._oldundo()只依赖这份存下来的状态。再往前一步如果同一个 Receiver 上多个命令交错执行打标签、改名、导出撤销一定要按历史栈逆序回放否则会覆盖掉别人刚做的操作——宏命令的reversed撤销就是这个意思。6.3 命令越积越多内存撑爆一旦你用命令模式做无限撤销或全量操作日志历史栈会一直涨。长时间运行的后台几万次操作后历史列表可能占掉可观内存甚至引发泄漏。解法分两档一是给历史栈设上限只保留最近 N 步更早的丢弃代价是不能无限撤销但多数业务够用二是把命令序列化落库而不是全留内存需要复盘时再从库里读。关键是在设计之初就决定历史是有限窗口还是持久化别等内存报警才想起来——到了那时候已经在内存里丢掉的命令是找不回来的。6.4 异步命令不收尾回调堆成山命令模式本身是同步语义execute()直接跑完但现代后台大量操作是异步的发消息、调外部 API、导出一个大文件。如果直接在execute()里await一个长任务Invoker 会被卡住如果甩一个回调进去又不跟踪命令对象执行到哪一步、成没成功就全成了黑盒。处理异步命令要给它一个明确的终态概念要么execute()只负责提交任务并拿到一个 future/任务句柄就返回终态由回调或轮询更新到命令对象上要么用纯数据命令4.3 那种把任务丢给远端 Handler本地只管发和收。无论哪种都要保证命令对象能回答我现在是成功、失败还是进行中否则历史栈里的命令状态永远对不上真实世界。七、在大模型工程里它出现在哪命令模式在 LLM 工程里出现得比想象中频繁因为模型要做的动作天然适合被建模成命令对象一个 tool call 就是一次请求它要被调度、要能撤销、要能排队、还要能在多轮对话间被记录和复盘。下面给三个贴着可运行骨架的场景。为什么偏偏是大模型工程把命令模式用得顺因为 Agent 的每一次动手都是一个需要被监管的副作用——发邮件、改数据库、调 API这些动作一旦发出去就难以收回。把它们做成命令对象意味着要不要执行、执行前记一笔、出错了怎么退都能统一处理而不是散落在模型调用前后的各处 if 里。这种建模方式在真实框架里并不少见LangChain 的 Tool 调用、OpenAI 的 function calling 返回结构本质上都是模型给出一组待执行的参数。把它们包成命令对象等于在模型与副作用之间加了一道你完全可控的闸门——模型只负责我决定现在发一封邮件剩下的执行、限流、回滚全交给 Invoker。顺着这条线再往前想一步当 Agent 能调用的工具越来越多模型产出命令、统一管道执行的分工会越来越值钱它把一个大模型 Agent 的动手能力用命令模式收口成了可治理的资源。7.1 把 LLM tool calling 建模成 Command大模型返回的 tool_call本质上就是我要执行什么、参数是什么。把它包成一个ToolCallCommand配上支持撤销和调度的InvokerAgent 的工具调用就从裸调函数升级成受管控的操作流【LLM tool calling 建模为命令可撤销、可调度】fromabcimportABC,abstractmethodclassToolCallCommand(ABC):abstractmethoddefexecute(self):...abstractmethoddefundo(self):...classSendEmailCommand(ToolCallCommand):def__init__(self,mailer,to,body):self._mailer,self._to,self._bodymailer,to,body self._sent_idNonedefexecute(self):self._sent_idself._mailer.send(self._to,self._body)# 真正发信defundo(self):ifself._sent_id:self._mailer.recall(self._sent_id)# 撤回已发邮件classAgentInvoker:def__init__(self):self._log[]defrun(self,cmd:ToolCallCommand):cmd.execute();self._log.append(cmd)# 执行并记入日志defrollback_last(self):ifself._log:self._log.pop().undo()注意UndoableCommand的思路直接复用发邮件前记下sent_id撤销时调recall。Agent 在真正动手前多一层命令封装等于给所有工具调用套上了统一的执行 记录 回滚管道。7.2 幂等工具调用把调用当命令而非 RPCAgent 调工具时最怕重试导致重复副作用网络抖动框架自动重试了一次send_email结果同一封邮件发了两遍。把 tool call 当成 RPC 来调重试就是再发一次请求把它当成带幂等键的事务性命令重试时复用同一个call_idReceiver 端发现这个 call_id 已经执行过就直接返回上次结果不再产生新副作用【幂等命令同一 call_id 重试不产生重复副作用】 SEEN{}# 真实系统里换成 Redis / 数据库defhandle_tool_call(cmd:ToolCallCommand):ifcmd.call_idinSEEN:# 已经处理过直接返回returnSEEN[cmd.call_id]resultcmd.execute_once()# 真正执行一次SEEN[cmd.call_id]result# 记下后续重试复用returnresult这里call_id就是命令对象身上的幂等键呼应 4.3 的纯数据命令。把工具调用当成带身份的命令而非无状态的远程过程是 Agent 生产化的一个关键细节——否则任何一次重试都可能变成一次事故。7.3 Agent 工具链的统一封装当 Agent 能用的工具变多搜索、计算、查库、发消息、写文件用一个ToolInvoker统一收口所有调用天然就能获得队列、日志、权限、限流的能力而每个工具只需实现自己的Command【Agent 工具链统一 Invoker 收口所有工具调用】classToolInvoker:def__init__(self):self._queue[];self._done[]defenqueue(self,cmd:ToolCallCommand):self._queue.append(cmd)defdrain(self):# 批量顺序执行whileself._queue:cmdself._queue.pop(0)cmd.execute();self._done.append(cmd)defundo_all(self):# 整条链回退whileself._done:self._done.pop().undo()invokerToolInvoker()invoker.enqueue(SearchCommand(订单状态))invoker.enqueue(SendEmailCommand(mailer,ax.com,已处理))invoker.drain()# 先搜后发整体有序、可回退enqueuedrain把一次 Agent 动作变成了可编排的命令队列你可以先做权限校验再执行、可以整体撤销、可以把队列序列化后异步跑。这正是命令模式在 Agent 工程里的价值落点——模型只负责产出命令执行、调度、回滚全部交给统一的 Invoker。当你把工具调用、消息发送、数据写入都收口成命令Agent 的行为能力就从一堆散落的 API 调用变成了一条可观测、可重放、可治理的操作流。出问题时不只是看日志猜发生了什么而是能直接拿着历史命令对象逐步回放、定点回滚——这对线上 Agent 的可靠性提升是结构性的而不是修修补补。记住这三条就够了命令模式落到工程里真正要刻进肌肉记忆的只有三条把操作做成对象而不是一次函数调用——对象能传递、排队、记录、撤销函数调用完就蒸发了。这是所有高级玩法的根。Receiver 持业务逻辑Invoker 只管调度ConcreteCommand 只做转交。Invoker 一旦开始懂业务解耦收益立刻归零。要撤销就自己存前置状态历史栈要设上限或落库——这两点决定你的撤销是稳的还是上线三天后内存报警、且回滚错乱。顺带划一道边界不是所有调一下函数都该上命令模式。如果你的操作永远只执行一次、不需要撤销/队列/日志/跨进程那直接调函数反而更直白命令模式真正的收益在操作需要被管理的时候——可撤销、可批量、可记录、可跨进程。一个很实用的进场信号当你发现自己开始给每个函数复制粘贴写日志 记历史 错误处理这段代码或者产品第一次提能不能加个撤销那就是命令模式该进场的时候了。反过来如果操作永远只有调一下就完硬上命令模式只会多绕一层弯。#命令模式 #CommandPattern #设计模式 #撤销重做 #Agent工具调用