Agent 架构双轴框架：七脉六式

很多团队设计 Agent 时是「堆能力」式的：看到别人用了 RAG 就加 RAG，看到别人多 Agent 就拆多 Agent，最后系统跑起来一长串、线上一出错就找不到是哪一环。这篇提出一套双轴框架——用「七脉」描述 Agent 把资源花在哪、用「六式」描述错误怎么传播——给技术决策和团队评审提供一套通用的 Agent 架构语言，把模糊的「感觉这个 Agent 不够稳」变成可定位的「推理 × 循环没有停止条件、治理 × 路由没有审批门」。

核心目的只有一个：避免「堆能力式」设计，降低复合错误带来的线上事故风险。

一、为什么需要这套框架

业界主流的 Agent 分类方式（Lilian Weng 的《LLM Powered Autonomous Agents》、Anthropic 的《Building Effective Agents》、Chip Huyen 的 Agent 章节、吴恩达的 Agentic Design Patterns 等）各有侧重，但都是从某个侧面对同一系统画「三视图」——单独用任何一种都有盲区。把它们叠起来看，会发现一个共同的结构性缺口。

举个「感知盲区」的具体例子：一个代码审查 Agent，你把整个仓库塞进上下文，以为模型「看到了全部」。但 200K token 装不下中型项目；就算装得下，模型的注意力也会被无关文件稀释——结果它对真正有 bug 的那 30 行视而不见。信息进入了上下文 ≠ 信息进入了模型的有效注意力。

核心判断可以浓缩成一句：

Model spends, harness budgets —— 模型负责「花」（花 token、花工具调用、花时间、花用户信任），harness（宿主框架）负责「预算」（决定怎么花、花多少、留下什么账）。

基于这个思路，下面整理出一个双轴框架，专门用来给团队做选型和评审。

二、双轴框架总览

• 纵轴（认知功能） —— 资源花在哪
• 横轴（执行拓扑） —— 错误怎么传
• 两轴交叉 —— 每个设计模式都有唯一坐标

一句话骨架：

纵七脉定资源得失，横六式断错误路径。

任何一个 Agent 设计模式，都能用「哪一脉 × 哪一式」精确定位。只说「我们用了 Orchestrator-Workers」是没有信息量的——它落在哪一脉、错误怎么传，才是关键。

三、纵轴 · 七脉（认知功能）

七脉不是 7 个模块名，而是 7 种不同的资源预算问题。按建设顺序分三圈：内圈让 Agent 能用，中圈让 Agent 可靠，外圈让 Agent 能上线。

每一脉对应一种资源预算、回答一个问题、有一个特定的失败信号：

下面逐脉说明，每脉配一个具体例子。

感知 Perception —— 预算的是「注意力」

回答的是「什么信息进入模型」。注意力是稀缺资源：上下文窗口再大，模型的有效注意力也有限。

例：客服 Agent 要同时读工单、聊天历史、CRM 记录。如果一股脑全塞进去，模型会被无关字段干扰；正确做法是做「上下文分诊」（Context Triage）——先判断这个工单需要哪几类信息，只把相关的那部分喂给模型。

失败信号：看到太多 = 什么都没看见。

记忆 Memory —— 预算的是「连续性」

回答的是「跨时间保留什么」。记忆决定 Agent 在多次会话、多次任务之间能否积累。

例：一个编程助手如果每次会话都「失忆」，你上周教它的项目约定（命名规范、目录结构）这周又得重教——这就是「reset 后技能退化」。解决办法是把长期偏好写入持久记忆（如向量库或结构化档案），短期对话状态另存。

失败信号：每次 reset 后技能退化。

推理 Reasoning —— 预算的是「不确定性」

回答的是「从前提怎么走到结论」。推理深度要匹配问题难度。

例：用户问「今天几号」，却触发了一整套多步思维链——慢、贵、还可能想多了出错。正确做法是「复杂度分流」（Complexity Routing）：简单意图直接答，复杂问题才启用深度推理。

失败信号：简单意图也走深度思考，慢且贵。

行动 Action —— 预算的是「不可逆性」

回答的是「能对世界做什么」。这是七脉里最危险的一脉，因为行动会改变外部世界。

例：推理算错了可以重新回答一遍，代价是几个 token；但「行动」算错了——比如真的发了一封退款、删了一个云资源——就要补偿或回滚，代价可能是真金白银。所以写操作必须配审批、配回滚路径。

失败信号：推理错可重答，行动错要补偿/回滚。

反思 Reflection —— 预算的是「校正」

回答的是「刚才做得对不对」。它是一个独立维度，不是推理的附属技巧。

例：代码审查 Agent 最怕「假阳性」（false positive，把没问题的代码报成 bug）。加一个 Critic（批评者）角色，对每条 finding 反问「这真的是 bug 吗？复现路径是什么」，能大幅降低误报。但 Critic 的标准必须清晰——标准模糊的 Critic 会无中生有，制造伪问题。

失败信号：Critic 标准不清，制造伪问题。

协作 Collaboration —— 预算的是「分工」

回答的是「多 Agent 怎么拆」。核心不是「拆成几个」，而是「每个 Agent 该看到什么」。

例：把研究任务拆给「搜索 Agent + 分析 Agent + 写作 Agent」，如果三个 Agent 都拿到全量上下文，等于没拆——每个都被无关信息淹没。正确做法是上下文隔离：搜索 Agent 只看查询词，写作 Agent 只看分析结论。

失败信号：大家都拿全量上下文 = 噪声淹没。

治理 Governance —— 预算的是「信任」

回答的是「能力如何被限制、记录、审计」。能力越强，事故越强，治理就越不可省。

例：一个能改云资源的运维 Agent，没有审批门（Approval Gate）就敢执行 terraform destroy，没有审计日志就查不出是谁触发的——这在生产环境是事故候选。治理脉要回答：哪些动作需要人确认、单次操作的爆炸半径多大、出事后能否追溯。

失败信号：能力越强，事故越强。

四、横轴 · 六式（执行拓扑）

六式 = 六个动词：传、选、撒、协、转、分。它描述的是多个步骤/Agent 之间怎么连接。

关键洞察：六式本质是「错误传播路径轴」

选了拓扑，就是在选错误怎么移动。

Route vs Orchestrate（最常被混为一谈）

这两个最容易混淆，区别在于「中心是否全程在场」：

用代码对比最直观：

# Route：分类器选一个处理器，然后自己退场，不再参与
def route(query):
    kind = classify(query)          # 把输入归到固定的 N 类之一
    return HANDLERS[kind](query)    # 交给对应处理器，路由器使命结束

# Orchestrate：中心反复收回控制权，运行时动态决定下一步
def orchestrate(task):
    state = init(task)
    while not state.done:
        step   = planner.next(state)   # 运行时根据当前状态决定下一步
        result = execute(step)
        state  = update(state, result) # 中心始终持有全局状态
    return synthesize(state)            # 最后综合所有结果

一个生活化的类比：Route 像医院分诊台——护士看一眼症状把你分到内科还是外科，分完就不管了；Orchestrate 像项目经理——全程盯着项目，根据进展不断调整下一步派谁做什么。

五、双轴正交的工程意义

同一个功能换拓扑，工程后果完全不同；同一个拓扑换功能，含义也完全不同。功能 × 拓扑合起来才是唯一地址。

5.1 设计模式矩阵（7 脉 × 6 式）

7 × 6 = 42 格，业界常见的 Agent 设计模式几乎都能落进去。下表整理了当前在生产或准生产系统里被广泛使用的典型模式：

读法说明：

• 空白（—）：该组合在生产中罕见，或容易退化成相邻格的变体。
• 结构性不成立：该功能本质上不适用该拓扑。例如「感知 × 层级」——感知是「什么信息进入模型」的问题，本身不是层级委派问题，硬套没有意义。
• 研究方向：学术界活跃但尚未稳定 production 化（如多智能体辩论），谨慎选用。

举几个格子的具体含义：

• 感知 × Route = 上下文分诊：进来一个请求，先分类「这需要读哪几类资料」，只检索相关的。
• 记忆 × Route = 分层记忆：把记忆分成 hot（当前会话）/ warm（近期）/ cold（归档），按需检索，类比 CPU 的多级缓存。
• 行动 × Loop = 退避重试（Retry-with-Backoff）：工具调用失败后等待递增的时间再重试（1s、2s、4s……），避免把下游打挂。
• 治理 × Loop = 人机闭环（Human-in-the-Loop）：高风险动作执行前暂停，等人确认后再继续。

5.2 同功能不同拓扑（以 Reasoning 为例）

同样是「推理」，放进 Chain 和放进 Loop，token 预算、等待时间、停止条件、错误恢复路径完全不一样。

def reasoning_chain(question):
    decomposition = llm("拆成三个子问题：" + question)
    answers = llm("依次回答：" + decomposition)
    final = llm("基于回答给最终答案：" + answers)
    return final

def reasoning_loop(question, max_iter=5):
    answer = llm("先给出一个答案：" + question)
    for _ in range(max_iter):
        critique = llm("检查问题，没问题输出 DONE：" + answer)
        if "DONE" in critique:
            break
        answer = llm("修订答案：\n" + answer + "\n批评：" + critique)
    return answer

两者都属于 Reasoning，但工程画像完全不同——这正是「功能 × 拓扑才是唯一地址」的意思。

5.3 同拓扑不同功能（以 Orchestrate 为例）

反过来，同样是 Orchestrate，落在不同脉上叫法和典型错误都不一样：

所以只说「我们用了 Orchestrator-Workers」是没有信息量的——它到底在协调推理步骤、协调多个 Agent，还是在做可观测性兜底？必须配上「哪一脉」才说得清。

六、选型三步：ASSESS → ROUTE → SELECT

示例：代码评审 Agent 选型

v1 最小组合：Context Triage + 结构化推理 + Generator-Critic。三个模式，覆盖三个 Heavy，其余降级到 v2。

七、双轴评审法（五问）

评审会上直接套用这五问。每问都给「答不出 = 什么问题」和「✅ 清楚回答示例」的对照。

价值：评审从「感觉这个 Agent 不够稳」升级为「推理 × 循环没停止条件，治理 × 路由没审批门，协作 × 层级没子代理隔离」——主观感受变成可定位、可整改的具体缺口。

八、Compound Error 公理（最容易被低估的风险）

Agent 系统的错误会复合。单步 95% 正确率听起来很高，但乘起来就崩：

这是所有长链 Agent 的现实，也是 Anthropic 等反复强调 「simple, composable patterns」（简单、可组合的模式） 的根本原因——链越长，复合错误越吃掉成功率。

四条应对策略

拓扑 × 错误对策速查

九、给团队的落地建议

1. 评审会强制走「评审五问」，取代「感觉不稳」的主观讨论。
2. 新项目立项先交 ASSESS → ROUTE → SELECT 三步结论，而不是直接报技术栈。
3. 高风险动作（能改云资源、能退款、能发外部消息）必须落 Governance，无论 v1 多紧。
4. 长链 Agent 先跑复合错误估算——20 步链即便单步 95%，整体也只有 36% 成功率。
5. 第一版架构目标是「最小可行稳定组合」，不是炫技。

一句话小结

纵七脉定资源得失（资源花在哪），横六式断错误路径（错误怎么传）。 给每个 Agent 模式一个「功能 × 拓扑」的唯一坐标，团队就能把「堆能力」的随性设计，换成可评审、可演进、可控制爆炸半径的工程决策。