范式觉醒：从 GoF 失效到双轴框架

这门课要解决一个具体的认知问题：上千个 agent 工程问题，看上去千奇百怪，背后是不是有有限的结构？答案是有。所有这些问题都落在同一个原子循环上——一次 LLM 调用接收一段 context、产出 token，这些 token 被解析成动作并执行，结果作为新的 observation 回填进下一轮 context。28 个设计模式，全部是对这个循环施加约束的不同方式。

1.1范式之变：GoF 失效与分布式系统补位

GoF 设计模式假设 actor 是确定的、控制流编译期已知；LLM agent 两条假设都不成立——它是概率节点，控制流在运行时由模型自己决定。

GoF 那 23 个模式，全部建立在两条前提上：actor 是确定的（同样的输入给出同样的输出），控制流编译期已知（哪个分支走哪里，写代码时就定死了）。LLM agent 把这两条都打破。第一，执行是概率性的——模型做的是 token 概率的模式匹配，不是逻辑推断。第二，控制流在运行时由模型自己决定——Anthropic 对 agent 的定义就是"LLM 动态地指挥自己的流程和工具使用"。

底层机制（比"非确定"深一层）：很多人以为非确定性是采样噪声，把 temperature 设成 0 就能消掉。这是错的。Thinking Machines 在 2025-09 实测：Qwen3-235B 在 temperature=0 下，同一个 prompt 跑 1000 次产生了 80 个不同的补全，而且分叉发生在第 102 个 token。根因不是浮点不结合律本身，而是服务器负载让 batch size 浮动，导致 RMSNorm／矩阵乘／注意力的归约（reduction）顺序变化，浮点结果随之变化（batch 不变性缺失）。含义很重：你连"同输入同输出"这条最底层的契约都拿不到，GoF 那套基于确定性的设计失去基础。

那该用什么范式补位？答案是分布式系统。一旦 actor 不可靠、步骤之间有网络／工具副作用、又没有跨步骤的事务，你面对的失效集合——部分失败、超时、重复投递、最终一致——正好就是分布式系统十五年前解决过的那一套。这套机制是直接可映射的：消息队列对应 agent 步骤间的任务缓冲；幂等键防止重复的 LLM 调用产生重复副作用；熔断器对应主模型限流时切备用模型；Saga + 补偿处理多步工作流中途失败的回滚；两阶段提交对应不可逆动作前的人工审批门；背压对应并行 LLM 调用的并发上限。下图是这套机制里最常用的一种：Saga 补偿。

下面这段伪码把这套机制收成一个可复用的步骤骨架：幂等键挂在"逻辑操作"上而不是每次推理调用上，外部 oracle 验证而非自检，副作用登记补偿、持久化以便崩溃重放。

# 分布式系统的机制用于 agent：每个有副作用的步骤 = 幂等键 + 外部验证 + 补偿 + 重放
def run_step(saga, step, inputs):
    # 1) 幂等键挂在"逻辑操作"上，不是每次 LLM 调用
    key = sha256(f"{step.name}:{stable_json(inputs)}")
    if cached := store.get(key):          # 重试策略：命中即 no-op，绝不重算
        return cached                     # （这是 retry，不是 sampling）

    # 2) LLM 这步非确定 → 拿环境 ground truth 校验，失败再"采样"换答案
    for attempt in range(MAX_SAMPLES):    # 采样策略：换答案，独立于上面的重试
        out = llm_call(step.prompt, inputs)
        if validate(out, against=env):    # 独立验证：不靠模型自检
            break
    else:
        saga.compensate_all()             # 都不过 → 逆序补偿已完成步骤
        raise StepFailed(step)

    # 3) 副作用必须可补偿、可重放（否则崩溃重放会重复执行）
    effect = step.apply(out)
    saga.register_compensation(step.undo, effect)   # 登记逆操作
    store.put(key, out)                   # 持久化：崩溃后重放跳过本步
    return out

1.2双轴框架（上）：两根正交的轴

两根轴回答两个不同的问题——纵轴（认知功能）问"一步循环内部在做什么"，横轴（执行拓扑）问"循环之间如何连、谁决定下一步"。

§1.1 立住了地基：agent 是概率分布式节点。这一节在地基上立起坐标系。把 1000 个工程问题压缩成有限模式，靠的就是发现：任何一个具体的 agent 设计问题，本质都在回答两件正交的事。

纵轴 = 认知功能，由 CoALA（Cognitive Architectures for Language Agents，TMLR 2024）给出权威划分，回答"这一步循环内部在做什么"。它把动作切成两类："不碰世界"的内部动作（推理 reasoning、检索 retrieval、学习 learning，只更新工作记忆）和"碰世界"的外部动作（grounding，接到对话／物理／数字环境，有不可逆副作用）。感知、记忆、推理、行动、反思这五个认知功能，本质是这个内部决策周期里被调用的不同动作类型。下图是这个周期的机制。

横轴 = 执行拓扑，由 Anthropic 的工作流构建块和 LangGraph 的多智能体抽象锚定，回答"多个 LLM 调用在控制流上如何连线、谁决定下一步"。最根本的分界是 workflow（控制流写死在代码里）对 agent（LLM 在循环里自主决定）。在这条轴上，从简单到复杂依次是：单 agent 循环（ReAct）、规划-执行（强模型先出计划、弱模型执行）、编排者-工人（中心 LLM 运行时动态分解派发）、多 agent（network 对等 handoff／supervisor 中心调度）。拓扑的本质是 context 的拓扑——每个 box 是一个独立的上下文窗口，箭头是 token 的传递。

为什么两根轴正交：同一套认知功能可以塞进任意拓扑。一个 worker 内部仍然要跑完整的"提议-评估-选择-执行"周期；把 reflection 从单 loop 提到 evaluator-optimizer 拓扑，改的是"谁来反思"，不改"反思要产出什么"。所以"这一步做什么"和"循环怎么连"是两个能独立拨动的旋钮——这就是双轴框架的全部威力，也是它能装下所有模式的原因。

1.3双轴框架（下）：定位与反推选型

给业务问题问两个诊断问题——步数能否预先列举（定横轴）、是否需要反思／跨任务记忆（定纵轴）——两个坐标的交点就是模式族。

§1.2 立起了坐标系。这一节让它干活：把已知模式钉到坐标上，再反过来用坐标反推选型。关键是，两根轴各自绑定一个真实的成本机制，不是装饰性的分类标签。

横轴绑定"LLM 调用次数 × 串/并行"，直接决定延迟和 token 账单。ReAct 的铁律是"每个工具调用 = 一次大模型调用"，所以延迟线性累加、还容易近视（一次只为一个子问题规划）。Plan-Execute 把规划从执行剥离——规划器只在开头和重规划时调用，执行步可用廉价模型，成本约"1× 强模型 + N× 弱模型"，N>3 时常优于 ReAct。多 agent 把成本推到极限：Anthropic 的研究系统比单 agent 强 90.2%，但烧了约 15× 的 token，而且 token 用量本身解释了约 80% 的性能方差——多 agent 的本质是"用 token 买并行探索的广度"。

纵轴绑定"有限上下文窗口怎么花"。Anthropic 把它重述为注意力预算：transformer 的 n² 注意力让 context 越长召回越差（context rot）。纵轴往上爬的每一档，都是一种对抗 context rot 的记忆机制。下图把几个已知模式钉在了这个坐标系上。

反推选型只问两个诊断问题，各定一根轴的坐标。下面的伪码把这个判断显式化。

# 把一个业务问题投影到「认知功能 × 执行拓扑」坐标系
def locate_pattern(task):
    # —— 横轴：由"步数能否预先列举"决定 ——
    if steps_enumerable_upfront(task):
        topo = "plan_execute" if not subtasks_independent(task) else "parallel"
    else:                                   # 步数不可预测 → 反应式
        topo = "orchestrator" if dynamic_subtasks(task) else "react"

    # —— 纵轴：由"单遍能否做对 / 是否需记忆"决定 ——
    cog = "reactive"
    if needs_iteration_with_feedback(task): cog = "reflective"   # evaluator-optimizer / Reflexion
    if needs_cross_task_memory(task):       cog = "memory"       # 情景记忆 / 压缩 / 笔记

    return (cog, topo)                       # 坐标交点 = 推荐模式族

# 选错坐标 → 可预测的失败模式：
#   (reactive, plan_execute) 用在高动态环境 → 计划僵化、频繁 replan
#   (reactive, react)        用在可预列举任务 → 近视卡循环、延迟白付
#   过度上 (memory, orchestrator) → 上下文分散、决策冲突、token 爆炸

1.4逆向五步法：从产品反推架构

你只能看到 LLM API 边界上的字节流；逆向就是从这层字节流逐层向内反推：行为 → 工具 → 系统提示 → 控制流 → 架构。

前三节给了你一套坐标系和一套来自分布式系统的设计方法。这一节给你验证它们的工具：拿一个成熟 Agent 产品，把它的架构拆出来。这既能让你"带读他人代码"，也是检验你是否真懂双轴框架的试金石——能逆向，才算真懂。逆向的本质约束是：无论产品内部多复杂，它和模型之间只能通过 LLM API 边界上的字节流交互，所有"架构"都是从这层字节流向内反推。

第 2 步是杠杆点：把 base URL 指向本地 mitmproxy（ANTHROPIC_BASE_URL=http://localhost:8000），截获请求体里完整的 tools 数组（名字 + JSON schema + description）——这是最高保真的信号。第 3 步用频率分析：系统提示被 prompt caching 固定，每轮高频复现，可自动剥离出静态骨架 vs 动态注入（<system-reminder>、<env>、todo 重载）。第 4 步从 message role 序列重建状态机：assistant[tool_use] → user[tool_result] 反复出现即 ReAct 环；出现 Task 工具即 orchestrator-workers。

逆向最反直觉的一个发现：很多产品的多 agent 协调逻辑根本不在代码里，而是写在系统提示的自然语言指令里。工程师以为会看到调度器或消息总线，实际是 prompt。所以"控制流一半在代码、一半在 prompt"——盯着可执行逻辑找状态机会漏掉一半。