当前位置：首页 > news >正文

Agent设计模式

news 2026/5/28 15:15:42

1、GoF 23 模式

GoF 的 23 种设计模式，本质上就是 23 种写程序时常见问题的经典解法。简单来说有三类。创建型：怎么把对象“造出来”更灵活。结构型：怎么把对象“拼起来”更合理。行为型：怎么让对象之间“配合工作”更顺畅。

但 GoF 23 模式有一个共同的底层假设：它假设单进程 / 共享内存 / 同步调用 / 确定性失败。所有对象在一个进程里跑，状态在共享内存里改，函数调用同步返回，失败就抛 Exception。

2、第二代设计模式——分布式系统模式

它们都把“不确定性”作为首要关注点来处理。GoF 假设失败是 Exception，分布式假设失败是 default，每一个模式都是在不确定性下保证系统行为可靠的工程纪律。

3、第三代 Agent 模式，解决“模型怎样被约束地行动”

第一条轴，叫认知功能。也就是 Agent 到底在做什么：感知、记忆、推理、行动、反思、协作、治理。
另一条轴，叫执行拓扑。也就是这些能力到底是怎样流动起来的：链式、路由、并行、编排、循环、层级。

对比

第一代把权力交给对象结构，第二代把权力交给服务边界，第三代把一部分决策权交给模型，然后由 harness 把边界重新收回来。

模式演进的根因：三种不确定性

第一种输出不确定 (Output uncertainty)

同一个 prompt，模型跑十次，可能给十种不同答案。你过去以为 retry 会得到同样结果，传统软件的 retry 假设幂等，失败重跑应该得同样结果。但在 LLM 上，LLM 调用的重试可能得到完全不一样的答案，引出新的行为分支。这就让熔断器（Circuit Breaker）、幂等键（Idempotency-Key）这些经典工程模式整套要重新装一遍。

第二种行为不确定

(Behavioral uncertainty)Agent 不只是给你一个答案，它还会自己决定要不要调用工具、先调用哪个工具、要不要问澄清问题、要不要继续展开思考。它的行为轨迹，不再是代码里写死的流程图。一个 ReAct Agent 在 Reasoning 和 Acting 之间循环切换，循环长度、循环内容、每一步具体做什么，都不是设计阶段就能预测的。

第三种环境不确定

(Environmental uncertainty)Agent 操作的世界本身在变。一个浏览网页的 Agent，今天看到的页面布局明天可能变了；一个写代码的 Agent，它上次读过的 Codebase 这次可能已经被同事改过。世界不会停下来等 Agent。传统软件工程把不确定性当边缘情况来处理，try-catch 一下、retry 几次、超时报错。大家会觉得我加个 retry、schema 校验，后者加个 timeout 就稳了。这思路是 try-catch 思路，它治不了 Agent 系统。

Agent 工程不是让模型自由发挥，而是让有限的注意力、记忆、工具、权限和信任资源，被花在最值得花的地方。这其实就是 Harness 的意义所在。