你好，我是黄佳。
上一讲我们把这门课的地基打下来了。GoF 解决代码怎么组织，分布式解决服务怎么存活，Agent 解决模型怎么被约束地行动。
这三句话看起来像历史分期，其实是三种工程权力的转移：第一代把权力交给对象结构，第二代把权力交给服务边界，第三代把一部分决策权交给模型，然后由 harness 把边界重新收回来。
在Harness的设计过程中，我们无疑观察到了很多可以复用的元素、组件以及思想，我们希望把这些东西尽快的抽象成模式，形成Agent时代工程师和架构师的集体通用语。
然而，如果佳哥只是列一个目录，只是把 28 个模式排成表格，你会看到很多名字，却抓不住它们之间的力学关系。真正重要的是：Agent 时代的设计模式，不再只是在回答最终的代码长什么样，而是在回答“一个不确定的模型，在有限资源里，应该把注意力、记忆、推理、工具、权限和责任分别放到哪里”。
这就是双轴正交框架要解决的问题。
-
纵轴叫认知功能，回答 Agent 在做什么：它是在看、记、想、做、反思、协作，还是治理自己。
-
横轴叫执行拓扑，回答数据和控制怎么流动：它是链式传下去、路由选出去、并行撒出去、集中编排、循环收敛，还是层级委派。
两轴合起来，才给每个模式一个唯一坐标。没有这个坐标，“我们用了一个 agent workflow”这句话几乎没有信息量；有了这个坐标，“我们用了推理 × 循环的迭代假设，加治理 × 路由的审批门控”这句话就能进入工程评审。
今天这一讲我们解决三件大事。
-
第一，为什么现有的Agent模式分类不够全面、解决不了具体问题，业界 5 类主流说法为什么都只摸到了局部。
-
第二，把两根轴要表达的内容讲透。纵轴不是随便列 7 个名词，它背后是 Agent 能力从个体认知到系统智能的层级；横轴也不是流程图集合，它背后是错误、成本、延迟和责任在系统里的传播路径。
-
第三，把这张图变成拿来即用的工程工具：拿到一个业务需求，怎么查表、选模式；看到一个开源框架，怎么判断它覆盖了哪些格；评审一个 Agent 架构，怎么问出真正的问题。
在此之后，后面所有模式就不再是散落的术语，而会变成一张可以导航、可以评审、可以扩展的地图。
我是怎么发现双轴框架的
有一次给 Cisco Agent团队做培训前的沟通时，一个女生问我：“黄佳老师，你是怎么想到、并设计出这个双轴框架的？我之前在奇点智能大会上听你讲这个框架的时候，觉得非常震撼，就很想问你是怎么一步一步把它落地、设计出来的。所以我希望你在给我们培训这些模式本身的时候，也能介绍一下这个思想形成的过程。”
当时我也愣了一下。我说，“哦，这个应该跟你们Cisco的产品一样，也是在不停地迭代过程中进化到这一步的。”
回到上一讲介绍过的那些“古早”分布式模式。Circuit Breaker，Saga，后来的 Sidecar、Bulkhead、Idempotency Key、Reconciliation Loop，这些都是“问题 → 模式”的组织方式。网络会挂，所以要熔断；跨服务事务会失败，所以要补偿；横切关注点散落，所以抽成 sidecar。这种“见招拆招”在分布式时代很有效，因为问题高度可命名：延迟、故障、重试、幂等、隔离、观测。
但 Agent 时代只靠问题清单不够。原因很简单：Agent 模式之间的组合密度更高。
一个生产级 Agent 很少只用一个模式。代码评审 Agent 可能同时有上下文分诊、分层记忆、复杂度路由、工具调度、生成批评、审批门控、可观测性。它们是互相影响的预算系统，不能当成并排摆着的零件来看：上下文分诊影响推理质量，推理路径影响工具调用，工具结果影响反思，反思又可能触发重新检索或重新计划。
如果没有坐标，架构评审会变成一堆松散术语。有人说我们要加 reflection，但他说不清是生成批评（Generator-Critic）、自愈循环（Self-Heal Loop），还是跨会话经验回放。有人说我们要上多模态智能体，但他说不清是扇出/汇聚（Parallel fan-out）、编排器-工作者（Orchestrator-Workers），还是真正的层级委派。词汇越热，歧义越大。
因此，在写完《Agent 设计模式》这本中文书之后，我其实一直在反复纠结：这些模式到底应该用什么样的形式来组织，才会更清晰、更有结构感？
如果只是列一个模式清单，它当然也能讲，但总觉得不够。因为清单只能告诉你有哪些模式，却很难解决后面这一系列问题：这些模式之间是什么关系、什么时候该选哪个模式、为什么这个模式适合这个场景。
后来有一天，我在和 AI 反复切磋这个问题的时候，突然意识到：做 Agent 模式选型时，我问的其实不只是一个问题。
我不只是要问：我想让 Agent 做什么？我还要问：我想怎样组织 Agent 的行为？
-
前一个问题是 What，也就是 Agent 要承担什么认知功能：感知、记忆、推理、行动、反思、协作、治理。
-
后一个问题是 How，也就是这些能力在系统中怎样被编排：是链式执行、条件路由、并行展开、集中编排，还是循环迭代。
当 What 和 How 这两个问题交叉在一起时，第三个问题才真正浮现出来—— Why：为什么我在这个场景下需要这个模式？
也就是在那一刻，终于灵光一闪。我突然发现，Agent 设计模式不能只靠线性的清单来组织，它需要一套二维坐标系。一个轴回答“Agent 在做什么”，另一个轴回答“Agent 如何被组织”。这两个轴交叉起来，才形成了我们现在看到的双轴框架。
所以，术语表不足以解决问题，Agent 时代真正需要的是一套能把术语定位的坐标系！
业界分类的三个盲区
但是业界，包括之前出现的一些所谓《Agentic设计模式》的书籍，甚至包括Antropic、Google、LangChain及OpenAI都没有真正给出任何清晰的Agent设计坐标系。
我们先看过去几年最有影响力的几套说法。
这些分类都对，但它们不是同一层的东西。Weng 在数模块，Anthropic 在数 Workflow，Andrew Ng 在数常见 Agentic Design Pattern，Chip Huyen 更像在数工程角色。
它们像从不同方向给同一个立体物绘制三视图，每个视图都是真的，但没有一个分类能单独还原整个结构。
把这些分类叠在一起，会发现三个共同盲区。
第一个盲区是感知。 很多分类默认 LLM 拿到的 input 已经是正确 input，但生产系统最先死的往往就是 input。200K context 装不下整个 codebase，检索回来的 100 个 chunk 有 70 个是噪声，日志流一秒几千行，多模态输入没有统一接收口。Agent 要做的是在有限窗口里决定“什么值得看”，“看见一切再思考”根本不可能。感知不是前处理的小步骤，它是注意力预算的第一道闸。
第二个盲区是反思。Reflection 经常被折进 Reasoning，好像只是推理的一种技巧。而Reflexion 论文里，语言反馈和经验记忆让 coding benchmark 的表现明显提升，这说明反思是把“一次性回答”推进到“可迭代改进”的关键机制，远不只是锦上添花。
因此工程上它应该独立成脉。Reasoning 产出候选答案，Reflection 判断候选答案是否站得住Reasoning 是生成方向，Reflection 是纠偏方向。
第三个盲区是治理。 Demo 可以没有治理，工程却不能没有治理。一个能读文件、改代码、发邮件、操作云资源的 Agent，如果没有审批门控（Approval Gate）、爆炸半径控制（Blast Radius Control）、审计追踪（Audit Trail）、trace 和权限边界，它就是一个事故候选——根本谈不上是工程系统。2025 年 Anthropic 披露的 agentic cyber misuse 案例之后，这件事不再是理论风险：当 Agent 能跨多步自主行动，治理就必须和行动能力一起设计，而不是上线前临时补丁。
这三个盲区指向同一个问题：行业早期太关注模型“里面”发生了什么，太少系统化讨论模型“周围”应该怎么布置。
这也回到上一讲的一个思想内核：Model spends, harness budgets。模型负责花 token、花工具调用、花时间、花信任；Harness 负责决定它怎么花、能花多少、花完留下什么账。
双轴框架就是把这件事系统化。
纵轴：感知七脉
纵轴叫认知功能。它问的问题很朴素：一个 Agent 到底在做什么？
Agent刚出现那时候对这个问题的答案通常是四件事：感知、记忆、推理、行动。CoALA 这类认知架构论文也会把语言智能体放在记忆、行动空间、决策过程这些模块里理解。这四件事构成 Agent 的内圈：它看见环境，把信息放进工作记忆，基于目标做推理，再通过工具或语言行动。
但生产系统里，四件事不够。
四件事只能解释 Agent 怎么完成一次任务，解释不了它做错后如何改进，解释不了多个 Agent 如何分工，解释不了拥有高风险工具之后如何被约束。所以我们要在四脉外加三脉：反思、协作、治理。
这就形成了七大认知功能：Perception / Memory / Reasoning / Action / Reflection / Collaboration / Governance。
我称它为“七脉“，有点像武侠式的漂亮比喻“七脉神剑”，我特别喜欢这个说法。它实际上是一套很值得推敲的工程分层。这7脉，分成了三个圈层。
内圈是核心认知：感知、记忆、推理、行动。没有这四件事，Agent 就会退化成聊天机器人或固定脚本。它不能主动选择信息，不能跨步骤保持状态，不能根据观察调整判断，也不能改变外部世界。
中圈是元认知：反思。反思的本质是把上一步的产物变成下一步的对象，它不只是多想一会儿。它让 Agent 从“生成答案”进入“审查答案”，从“执行计划”进入“检查计划是否仍然成立”。没有反思，Agent 的输出永远像初稿；有了反思，Agent 才开始像一个会返工的工程师。
外圈是系统智能：协作和治理。协作让 Agent 从单体扩展成组织，治理让 Agent 从能力展示变成可上线系统。单 Agent demo 可以暂时没有外圈；真正进入企业流程，外圈缺一不可。协作没有隔离，会制造上下文污染和责任混乱；治理没有跟上，能力越强风险越大。
这三圈给了一个很实际的智能体建设顺序：
内圈让 Agent 能用，中圈让 Agent 可靠，外圈让 Agent 能上线。
很多团队失败的原因是建设顺序反了，不是模型差。内圈感知-推理-行动（Perceive-Reason-Act）还没跑顺，就开始搞多智能体集群；上下文质量还没稳定，就开始堆反思；工具权限还没分级，就把 Agent 接进生产系统。结果是错误涌现，不是智能涌现。
正确路径通常更朴素一些：先跑通内圈，再加反思稳定质量，最后加协作和治理扩大规模。每个项目不需要在第一天就七脉全满，但架构师必须第一天就知道七脉在哪里。你可以暂时不实现某一脉，但不能假装它不存在。
这七脉，也就是七个认知层，不要把它们当模块名背下来，要把它们当成七种不同的资源预算问题。
感知（Perception）是注意力预算。它回答什么信息进入模型，什么信息留在外面。在传统软件里，输入一般是明确的函数参数；在 Agent 系统里，输入本身需要被构造。一个代码 Agent 面对的是一个 codebase、一个 git diff、一串测试日志、几轮对话、若干项目约束，不是一个字符串。上下文分诊（Context Triage）的本质就是急诊分诊：先看主诉，再看生命体征，再决定谁进抢救室、谁等一等。感知失败的典型表现是“看到了太多，等于什么都没看见”，不是“没看到信息”。
记忆（Memory）是连续性预算。它回答Agent 跨时间应该保留什么。LLM 的上下文窗口是工作台，不是仓库；把所有历史都塞进工作台，迟早会爆。分层记忆的意义就在于把当前轮、近期摘要、长期事实、程序性经验分开。记忆不是越多越好，记忆的价值在于可召回、可更新、可遗忘。一个 Agent 如果每次都像第一次见用户，它没有成长；但如果它把所有细节都当永久事实，它会被旧信息拖死。
推理（Reasoning）是不确定性预算。它回答了面对当前信息，Agent 怎么从前提走到结论。推理不是只有 Chain-of-Thought。简单任务可能只需要一步判断，复杂任务需要分解、假设、验证、回溯。工程上真正重要的是让不同复杂度的问题走不同推理路径，让所有问题都“深度思考”是浪费。复杂器路由（Complexity-Based Routing）的价值就在这里——把慢思考留给真正需要它的地方，不是为了炫耀大模型。
行动（Action）是不可逆预算。它回答Agent 能对世界做什么，以及怎么做。读文件、查数据库、发邮件、改代码、部署服务，这些动作的风险完全不同。工具调配（Tool Dispatch）的本质是在自然语言意图、工具描述、参数 schema、权限边界之间做匹配，这比从下拉框里选工具复杂得多。行动失败最危险的地方在于它会改变外部状态；推理错了可以重答，行动错了可能需要补偿，甚至不可补偿。
反思（Reflection）是校正预算。它回答刚才做得对不对，错在哪里，下一步怎么改。生成批评（Generator-Critic）、自愈循环（Self-Heal Loop）、经验回放Experience Replay 都属于这一脉。反思的工程价值在于把错误尽早暴露出来，不在于让模型显得更聪明。反思也有失败模式：Self-Critic 容易自我合理化，Loop 容易过度修补，Critic 标准不清会制造伪问题。所以反思必须有终止条件、评价标准和必要时的外部基准事实（Ground Truth）。
协作（Collaboration）是分工预算。它回一个 Agent 装不下时，任务怎么拆给多个 Agent。协作的本质是把上下文、工具、目标和责任切开，不是让一群 Agent 聊天。真正的 multi-agent 价值通常来自两件事：专业化和隔离。读代码的 Agent 不必拿写文档的全部上下文，跑测试的 Agent 不必拥有生产写权限。协作失败的典型形式是大家都知道一切，所以大家都被噪声淹没。
治理（Governance）是信任预算。它回答Agent 的能力如何被限制、记录、审计和追责。治理是和工具调用同一层的运行时机制，不是最后加的合规文档。审批门控（Approval Gate）、爆炸半径控制（Blast Radius Control）、可观测性（Observability Harness）、Hooks Pipeline 都在做同一件事：把 Agent 的能力放进可见、可停、可回放、可解释的轨道里。Agent 越强，治理越不能弱；因为强能力没有边界，就是强事故。
七脉合起来给我们一个新的判断标准：一个 Agent 架构缺哪一脉，它就会在哪一类资源上失控。缺感知，token 失控；缺记忆，连续性失控；缺推理，判断失控；缺行动约束，世界状态失控；缺反思，错误失控；缺协作，规模失控；缺治理，信任失控。
引入上述体系帮助我们思考与判断，要比只关注用了几个 Agent、接了几个工具更接近工程本质。
横轴：拓扑六式
纵轴回答做什么，横轴回答怎么流。
如果说认知功能决定 Agent 在花哪一种资源，那么执行拓扑决定这种资源如何在系统里传播。数据怎么从一个节点到另一个节点，控制权怎么交接，错误怎么扩散，延迟怎么叠加，责任怎么落地，这些都由拓扑决定。
Anthropic 在 Building Effective Agents 里列出的 Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer，本质是在讲 workflow 拓扑。Google ADK 的 SequentialAgent、ParallelAgent、LoopAgent 也是拓扑。OpenAI Agents SDK 的 Handoffs、Guardrails、Tracing，更偏协作和治理拓扑。LangGraph 用有向图、条件边和 state graph 把这些拓扑进一步泛化。
这些框架的共同点是它们都在回答“流怎么走”。我们把这条轴收敛成六式：
六式分别是 Chain、Route、Parallel、Orchestrate、Loop、Hierarchy。为了方便记忆，也可以提炼为六个动词：传、选、撒、协、转、分。我们依次来看。
-
链式（Chain），传。上一步输出就是下一步输入。它适合步骤稳定、依赖清晰、每一步都能定义输入输出的任务。翻译 → 校对 → 润色是 Chain，检索 → rerank → 生成也是 Chain。链式的优点是可预测，缺点是错误会顺流而下。链越长，中间格式越重要；一个节点输出走偏了，下游节点经常不会纠错，反而把错包装得更漂亮。
-
路由（Route），选。先判断输入属于哪一类，再交给对应处理器。简单问题给小模型，复杂问题给大模型；退款问题给退款 Agent，技术问题给技术 Agent；低风险动作自动执行，高风险动作进入审批。Route 的核心是分类器质量。路由错了，后面再强也很难救。路由的工程价值常常在于降低平均成本和平均风险，而不在于提高上限。
-
并行（Parallel），撒。同一个任务多路展开，再合并结果。它可以是多模态的融合，也可以是扇出/汇聚 （fan-out gather），还可以是把互不依赖的子任务同时交给多个 worker。并行的关键在 merge，不在 fan-out。数学题可以多数投票，创意题不能；代码评审可以合并 findings，但要去重和分级；调研任务可以多源检索，但要解决来源冲突。没有好的 merge，并行只是把噪声并行化。
-
编排（Orchestrate），协。一个中心节点负责任务拆解、分发和汇总。它适合复杂但仍然能由中心理解全局目标的任务。计划-执行（Plan-and-Execute）是典型 Orchestrate：Planner 拆任务，Executor 执行，Planner 或 Synthesizer 汇总。它的失败模式是拆错边界：该选链式的拆成并行，该共享状态的拆成独立，该委派给专家的留在中心硬做。
-
循环（Loop） ，转。生成、评估、修订，再生成，直到达到停止条件。Loop 是 Agent 最迷人的拓扑，也是最危险的拓扑。它让系统能从错误中恢复，但也让错误有机会复合。Loop 的核心是停止条件、评估信号和每轮改动幅度，而不是循环本身。没有这些，Loop 会变得“越改越忙，越忙越偏”。
-
层级（Hierarchy），分。多层委派，父节点管目标，子节点管局部，孙节点继续细分。Hierarchy 和 Orchestrate 容易混，但它们不是一回事。Orchestrate 是一层中心编排多个 worker；Hierarchy 是多层责任分解。Claude Code 的 Subagents、企业里的分层审批、多级 sandbox，都更像 Hierarchy。它的失败模式是隔离没做好：父级上下文泄漏给所有子级，权限继承太宽，低层失败向上雪崩。
这六式不是为了画图好看。它们分别对应六种错误传播方式：Chain 是错误级联，Route 是错误分派，Parallel 是错误聚合，Orchestrate 是错误分解，Loop 是错误复合，Hierarchy 是错误放大或错误隔离。
所以我们惊讶地发现，这个横轴竟然不是流程图轴，而是错误的传播路径轴（failure propagation axis）。你选择了拓扑，就是在选择错误如何移动。这真是大开脑洞！不是么？
总结
到这里，双轴框架的第一层已经立起来了。
-
纵轴七脉，回答的是 Agent 在消耗哪一种资源：感知消耗注意力，记忆消耗连续性，推理消耗不确定性，行动消耗外部世界的可逆性，反思消耗校正能力，协作消耗分工成本，治理消耗信任预算。
-
横轴六式，回答的是这些资源如何在系统里流动：链式让错误级联，路由让错误分派，并行让错误聚合，编排让错误进入任务分解，循环让错误复合，层级让错误被放大或隔离。
我真希望，双轴框架能帮助我们看清 Agent 系统背后的工程力学：纵七脉定资源得失，横六式断错误路径。双轴既立，Agent 工程评析才真正入微。
这个思想也已经被我整理成论文并在Manning的重点书籍 Designing AI Agents 中进一步深化。
全书的核心主张正是：单看功能或单看流程都不足以解释 Agent 架构，只有把“它在做什么”和“它如何流动”正交起来，才能区分那些表面相似、工程后果却完全不同的系统。
这也解释了为什么我们不能把这一讲只当成“模式目录导览”。目录只能告诉你有哪些模式，双轴坐标系才能告诉你：为什么这个模式在这里，为什么另一个模式不该放在这里，以及未来新模式应该如何进入同一套工程语言。
思考题
-
回想你正在做或见过的一个 Agent 系统，它最容易失控的是哪一类资源？是输入太多导致感知失控，历史太杂导致记忆失控，判断不稳定导致推理失控，工具权限太大导致行动失控，还是缺少审查导致反思失控？
-
找一个你熟悉的 Agent 工作流，判断它主要采用的是哪一种执行拓扑。它是一步步链式执行，先分类再路由，多路并行展开，中心节点编排，反复循环修正，还是多层级委派？这种拓扑最容易让错误沿着什么路径传播？
-
为什么说“用了几个 Agent”“接了几个工具”还不足以说明一个系统设计得好不好？试着用“七脉”和“六式”重新描述这个系统，看它到底在解决什么认知功能问题，以及它如何组织执行路径。
欢迎你把自己的答案写在留言区。下一篇我们继续追问一个更关键的问题：为什么这两条轴必须是“正交”的？为什么只说“我们用了 Loop”“我们用了 Orchestrator-Workers”“我们加了 Memory”都还不够？只有回答了这个问题，双轴框架才会从一张分类图，真正变成一套可以选型、评审和演进 Agent 架构的工程工具。