从GoF到Agent:软件架构的第三次跃迁

——用"认知功能×执行拓扑"双轴框架，拆解Agent架构的完整图景

引言：你可能一直在用错误的视角看Agent

2026年6月，Gartner将"AI Agent Harness Engineering"列为未来十年最重要的技术战略方向。几乎同一时间，Google Cloud AI总监Addy Osmani提出了"Loop Engineering"概念，宣称"别再写Prompt了，去设计循环"。OpenClaw创始人Peter Steinberger更直接："别再搞coding agent了，去设计能提示agent的loop。"

这些信号指向同一个事实：Agent不是一种新的框架，而是一种新的架构范式。

但如果你去搜"Agent架构"，大多数文章会给你列一堆框架——LangGraph、CrewAI、AutoGen、OpenClaw、Hermes——然后告诉你它们各有什么特点。这不是架构分析，这是产品目录。

真正的架构分析要回答的问题是：为什么需要这种架构？它解决了什么根本性的问题？它跟之前的架构有什么本质区别？

本文尝试回答这三个问题。核心论点是：

Agent时代的本质，不是"LLM+工具调用"——而是一种架构迁移。从GoF设计模式到分布式架构，再到Agent架构，每一次跃迁解决的都是上一代架构无法处理的约束类型。GoF解决确定性对象交互的约束，分布式解决网络不确定性带来的约束，而Agent架构解决的是语义不确定性——输入是模糊的自然语言，工具可能返回意料之外的结果，目标本身可能在执行过程中发生变化。

为了系统拆解这个论点，我提出一个双轴分析框架：

• 认知功能轴：Agent需要哪些"认知能力"？看（感知）、记（记忆）、想（推理）、做（行动）、反思、写作（表达）、治理自己（自我约束）
• 执行拓扑轴：这些认知能力按什么结构组织？链式、路由、并行、编排、循环收敛、层级委派

两个轴的交叉点，才是真正的架构决策空间。

一、三次架构跃迁：不是功能升级，是约束迁移

1.1 GoF时代：确定性约束

1994年，"四人帮"（Gamma, Helm, Johnson, Vlissides）出版了《设计模式》一书，提出了23种软件设计模式。工厂方法、观察者模式、策略模式、装饰器模式……这些模式的共同前提是：对象的行为是确定的。

一个Observer被notify()之后一定会调用update()，一个Strategy被调用后一定返回符合接口的结果。整个GoF体系建立在一个隐含假设上：如果你定义好了接口和契约，对象的执行结果就是可预测的。

这个时代的核心架构问题是：如何组织确定性组件之间的交互关系？

答案就是设计模式——用经过验证的组合方式，让确定性组件的协作更灵活、更可维护。单例确保全局唯一，工厂解耦创建逻辑，策略让算法可替换，观察者实现事件驱动的松耦合。

本质上，GoF解决的是"组件之间如何高效协作"的问题。约束是确定性的——你知道输入是什么，输出是什么，中间过程也是确定的。

1.2 分布式时代：概率性约束

当系统从单机走向分布式，一切开始变得不确定。

网络可能超时，节点可能宕机，消息可能丢失或重复。你定义了一个REST API，但对方服务可能在99.9%的情况下正常返回，在0.1%的情况下返回502。你设计了一个微服务架构，但分布式事务的CAP定理告诉你，一致性和可用性不可兼得。

这个时代催生了一系列新的架构模式：熔断器（Circuit Breaker）处理服务降级，重试策略处理瞬时故障，消息队列处理异步解耦，分布式锁处理并发冲突，Saga模式处理跨服务事务。

本质上，分布式架构解决的是"概率性失败下如何保证系统可用"的问题。约束是概率性的——你不知道这次调用会不会超时，不知道这条消息会不会丢失，但你知道大概率是正常的，小概率会出问题。

1.3 Agent时代：语义不确定性约束

现在，来看Agent架构要解决的问题。

当你让一个Agent"帮用户订一张从北京到上海的机票"，你面对的挑战跟分布式完全不同：

• 输入是模糊的：用户说"明天"，是今天24点之后？还是明天白天？"便宜的"是多少钱以内？
• 工具返回是不可预测的：航班查询API可能返回200条结果，也可能返回0条；价格可能在你查询的瞬间发生变化
• 目标是动态的：用户可能在执行过程中改主意——"算了，高铁也行"
• 执行路径是需要推理的：没有预定义的Workflow告诉你"先查机票→再查酒店→再查接机"，Agent需要自己判断应该先做什么

这就是语义不确定性——你无法用接口契约定义输入输出的关系，无法用概率模型描述失败分布，因为问题的定义本身就是模糊的、动态的、需要理解的。

这就是为什么GoF的设计模式帮不了你——模式解决的是确定性组件的协作问题，而Agent面对的不是确定性组件，是一个需要"理解"和"推理"的LLM。

这也是为什么分布式的模式不够用——熔断器可以处理服务不可用，但处理不了"服务返回了结果但结果不是用户想要的"这种情况。

Agent架构的本质，是为语义不确定性设计一套新的约束机制。 这套机制包括：如何让Agent感知环境（看）、积累经验（记）、做出判断（想）、执行操作（做）、从错误中学习（反思）、表达结果（写作）、约束自己的行为边界（治理自己）。

二、认知功能轴：Agent的七种能力

用一个类比来理解Agent架构：如果Agent是一个人，它需要什么能力？

认知科学中有个经典模型叫BDI（Belief-Desire-Intention），它描述了理性Agent的基本认知结构：信念（对世界的理解）、愿望（想要达到的目标）、意图（承诺去执行的目标）。但这个模型太粗了。2026年的Agent架构实践表明，一个完整的Agent至少需要七种认知功能。

2.1 看（Perception）：多模态感知

Agent的"看"不仅仅是接收输入，而是将多模态的环境信息转化为可理解的内部表示。

2026年的突破在于真正的多模态融合。Agent不再像早期那样"先识别图像再转成文本"，而是在统一的表示空间中同时处理文本、图像、语音、API返回数据等多种信息源。据业界分析，当前主流Agent架构的感知层已经支持通过MCP（Model Context Protocol）协议接入数据库、文件系统、API网关等外部工具，通过A2A（Agent-to-Agent）协议接收其他Agent的消息。

架构含义：感知层的设计决定了Agent的"信息边界"。一个只能处理文本的Agent和一个能同时处理代码仓库、数据库schema、实时日志的Agent，能力差距不在模型上，在感知层的宽度上。

2.2 记（Memory）：从金鱼记忆到终身学习

2026年之前，大多数Agent是"无状态"的——每次对话都是全新开始，上次犯过的错下次照犯不误。这是一个结构性缺陷。

2026年的记忆架构收敛为"三层模型"：

记忆类型	功能	存储方式	类比
短期记忆	当前会话上下文	LLM上下文窗口（128K~1M Token）	你脑子里正在想的事
长期记忆	持久化知识与经验	向量数据库 + 知识图谱	你记住的知识点和教训
工作记忆	当前任务所需的记忆子集	动态加载 + 缓存	你做题时翻的笔记

更关键的是记忆提炼——不是把所有对话记录都存下来，而是从交互中提取可复用的"事实""偏好""规则"，形成结构化记忆。Mem0框架的测试显示，经过10-20次相似任务后，Agent的执行速度可以提升2-3倍，因为它记住了"怎么做"。

Hermes Agent走得更远——它在完成复杂任务后会自动创建"Skill文档"，把成功的操作模式转化为可复用的程序性记忆。这些Skill在后续相似场景中会被自动调用和迭代优化。

架构含义：记忆不是存储问题，是认知问题。设计Agent的记忆系统，本质上是在设计"Agent应该记住什么、忘记什么、何时回忆"的认知策略。

2.3 想（Reasoning）：从思维链到树搜索

Agent的"想"就是推理与决策——根据感知到的信息和存储的经验，决定下一步做什么。

这个领域经历了三代演进：

第一代：思维链（Chain-of-Thought, 2023）——让模型"一步一步想"。有效但线性，遇到分叉路口只能猜。

第二代：ReAct（Reason+Act, 2024）——边想边做，每做一步观察结果再决定下一步。解决了"想"和"做"的耦合问题，但仍然是单路径推理。

第三代：树搜索+规划（Tree-of-Thought + Planning, 2026）——面对复杂任务，Agent会先生成一个任务分解计划（Plan），然后对每个子任务进行多路径搜索，评估每条路径的可行性，选择最优路径执行。Claude Code SDK和OpenAI Agents SDK都采用了这种"双层While循环"架构——外层控制任务级规划，内层控制步骤级执行。

架构含义：推理层的设计直接决定了Agent能处理多复杂的任务。单步推理只能做简单工具调用，多步推理能做Workflow，带规划的推理能做长程自主任务。

2.4 做（Action）：从Function Call到MCP协议

Agent的"做"是执行操作——调用工具、读写文件、发送请求、控制设备。

早期的Function Call只是让模型输出一个JSON格式的工具调用请求。2026年，MCP（Model Context Protocol）已经成为Agent工具调用的事实标准。MCP定义了模型与外部工具之间的标准化通信接口，一个MCP Server可以同时服务于Claude、GPT、DeepSeek等多个模型——"一次开发，多端复用"。

更重要的是工具编排的成熟。Google ADK（Agent Development Kit）提供了三种原生编排原语：

• SequentialAgent：流水线式顺序执行
• ParallelAgent：独立任务并行处理
• LoopAgent：迭代执行直到满足停止条件

架构含义：工具层的设计决定了Agent能触达多远的"手脚"。MCP协议让工具接入标准化，而编排模式让多工具协作从硬编码变成可配置。

2.5 反思（Reflection）：从"做完就完了"到"做完还要检查"

这是2026年Agent架构中最重要的新增能力。

传统Agent是单向的：输入→执行→输出。做完就完了，不管做得对不对。但2026年的主流架构引入了反思层——Agent在执行后会主动评估自己的输出质量，发现问题则自动修正。

反思分三个层级：

层级	含义	类比
行动级反思	单步操作校验	写完邮件检查有没有错别字
策略级反思	执行路径优化	做到一半发现方法效率太低，换个方法
目标级反思	目标对齐校验	做了一半发现方向错了，调整目标

Loop Engineering的核心理念就是建立在反思之上：你不再手动写Prompt，而是设计一个循环，让Agent自己执行、自己检查、自己改进，直到满足终止条件。OpenClaw和Claude Code都采用了"Maker/Checker"分离模式——一个Agent负责写代码，另一个独立Agent负责审查，两者使用不同的指令甚至不同的模型。

架构含义：反思层是Agent可靠性的核心。没有反思的Agent就像一个不检查作业的學生，做得快但错得多。有了反思，Agent的任务完成率可以从约50%提升到90%以上，幻觉率可以从30-40%降到10%以下。

2.6 写作（Expression）：结构化输出与多格式交付

Agent的"写作"不只是生成文本回复，而是将内部推理结果转化为符合外部期望的结构化输出。

这包括：强制JSON Schema输出（Constrained Decoding）、Markdown/HTML格式化报告、代码生成与格式化、自然语言摘要与汇报。

2026年的一个关键进展是约束解码（Constrained Decoding）的成熟——强制LLM的输出必须符合预定义的结构，从根本上解决输出格式不稳定的问题。这是Agent Harness（驾驭工程）内核约束层的核心能力。

架构含义：表达层是Agent与外部世界的"接口"。一个输出格式不稳定的Agent永远无法被集成到生产系统中。约束解码让Agent从"能聊天"变成"能干活"。

2.7 治理自己（Self-Governance）：Agent的"超我"

这是最前沿的能力，也是区分"Demo级Agent"和"生产级Agent"的分水岭。

2026年Gartner提出的Agent Harness Engineering，本质上就是一套治理框架。它包含四个层级：

1. 内核约束层：强制输出格式、上下文防火墙（自动打码敏感信息）
2. 安全护栏层：工具调用审查、沙箱执行环境、权限控制
3. 观测反馈层：全链路追踪（每次思考、每次工具调用都有Trace ID）、Token经济学监控
4. 策略控制层：成本预算上限（如每次运行最多$100）、操作审批流程（如git push需要人工确认）

Databricks在2026年6月开源的Omnigent更进一步，提出了"Meta-Harness"概念——一个管理Harness的Harness。它可以同时管理Claude Code、Codex、Pi等多个Agent，在它们之上施加统一的治理策略：预算策略（Agent花费达到阈值自动暂停）、上下文策略（npm install之后的git push需要人工审批）、安全策略（GitHub Token永远不暴露给Agent）。

架构含义：自我治理不是可选项，是生产部署的前提。没有治理的Agent就像没有刹车的汽车——跑得越快，事故越大。

三、执行拓扑轴：六种组织认知能力的方式

有了七种认知功能，下一个问题是：这些功能按照什么结构组织？

这就引出了执行拓扑轴。2026年的Agent架构实践中，我观察到六种主要的执行拓扑模式。它们不是互斥的，而是可以组合使用的"积木"。

3.1 链式（Chain）

Step 1 → Step 2 → Step 3 → 完成

最基础的拓扑。每个步骤的输出是下一步的输入，严格按顺序执行。

典型场景：数据采集→清洗→转换→加载→分析→报告。Google ADK的SequentialAgent就是这种模式。

优势与局限：简单、可预测、易调试。但一个环节卡住整条链停摆，且无法处理需要回退或分支的情况。

3.2 路由（Router）

            ┌→ Agent A（代码审查）
输入 → 路由 →├→ Agent B（数据分析）
            └→ Agent C（文档生成）

一个中央路由器根据输入内容判断应该交给哪个专业Agent处理。Microsoft ISE团队在2026年的实践中发现，Router模式适合意图明确、各分支互不重叠的场景——比如客服系统中，Bug报告转代码Agent、账单问题转财务Agent、功能建议转产品Agent。

优势与局限：快速、确定性强。但每个请求只能路由到一个Agent，无法处理需要多个Agent协作的复杂请求。

3.3 并行（Parallel）

         ┌→ Task A ─┐
Start → ├→ Task B ─├→ Merge → 继续
         └→ Task C ─┘

多个独立任务同时执行，等所有任务完成后合并结果。Google ADK的ParallelAgent实现了这种模式——对于互不依赖的子任务，并行执行的整体耗时取决于最慢的那一个，远快于串行。

优势与局限：大幅降低总耗时，适合数据采集、风险评估、多源搜索等场景。但Token消耗成倍增加，且需要处理合并冲突。

3.4 编排（Orchestration）

          ┌→ 价格查询 ──┐
请求 → 编排器 →├→ 库存检查 ──├→ 决策Agent → 输出
          └→ 合规审查 ──┘

编排器（Coordinator/Orchestrator）是路由模式的升级版——它不仅能分发任务到单个Agent，还能编排多个Agent协同工作。Microsoft ISE团队的实践表明，Coordinator模式是大规模企业部署的首选。

Salesforce在2026年Summer '26发布的Atlas 3.0引擎就是典型的编排模式：一个Planner Agent接收用户请求，决定需要哪些Specialist Agent，发送结构化任务，收集结果，最后由Reviewer Agent审查后输出给用户。

优势与局限：最灵活的模式，支持复杂的协作场景。但编排器本身成为瓶颈——它的推理质量决定了整个系统的上限。

3.5 循环收敛（Loop Convergence）

┌→ 执行 → 评估 → 满足条件？─是→ 输出
│                    └─否→ 修正 ─┘
└──────────────────────────────┘

Loop Engineering的核心拓扑。Agent执行一步，评估结果，不满足条件就修正后重试，直到满足终止条件。

这是2026年最重要的拓扑创新。Addy Osmani将其描述为"从'操作工'到'工厂主'"的转变——你不再一步步指导Agent，而是设计好循环的终止条件和评估标准，让Agent自己在循环中迭代。

循环收敛的关键设计要素：

• 终止条件：测试全部通过？相关性>0.9？用户满意度达标？
• 最大迭代次数：防止无限循环的安全阀
• 收敛策略：每次迭代如何改进？随机重试还是有方向地修正？

优势与局限：处理不确定性最强的拓扑——正因为输入和目标不确定，才需要反复迭代直到"足够好"。但成本高昂，每次迭代都消耗Token，且可能陷入局部最优。

3.6 层级委派（Hierarchical Delegation）

          Lead Agent（规划 + 分派）
         /        |         \
    Sub-Agent  Sub-Agent  Sub-Agent
    (执行)     (执行)     (执行)
         \        |         /
          Lead Agent（汇总 + 审查）

一个Lead Agent负责理解任务、分解子任务、分派给专业Sub-Agent执行，然后汇总结果。这是"Orchestrator-Worker"模式的高级形态。

Anthropic的研究表明，使用并行Sub-Agent协调的Lead Planner架构，在复杂任务上的表现远超单Agent。Hermes Agent的Sub-Agent架构更进一步——每个Sub-Agent拥有独立的上下文和工具集，Parent Agent通过结构化的Kanban系统进行任务调度和状态追踪。

优势与局限：最适合长程复杂任务——Lead Agent处理"全局观"，Sub-Agent处理"专业深度"。但Lead Agent的推理能力是单点瓶颈，且Sub-Agent之间的协调成本随数量增长。

四、双轴交叉：真正的架构决策空间

单独看任何一个轴都不够。真正的架构决策发生在两个轴的交叉点上。

让我用几个实际案例来说明：

案例1：Claude Code的架构选择

Claude Code选择了循环收敛 × 自我治理的组合。它的核心Loop是：执行→检查→修正→再检查，直到测试通过。同时，外层有一个Harness层负责成本预算控制、操作权限审查、全链路追踪。

为什么这样选？因为Coding任务的核心挑战是语义不确定性（用户需求模糊）+ 高风险操作（可能删错文件、改坏代码）。循环收敛处理不确定性，自我治理控制风险。

案例2：Salesforce Agentforce的架构选择

Agentforce选择了编排 × 路由的组合。Planner Agent作为编排器分发任务到Specialist Agent（账单、退货、IT、销售），每个Specialist内部使用路由模式处理子请求。

为什么这样选？因为企业客服场景的核心挑战是多领域知识的组织——没有一个Agent能覆盖所有业务领域，但每个请求通常只需要1-2个专业领域。编排处理跨域协作，路由保证单次请求的效率。

案例3：Hermes Agent的架构选择

Hermes选择了层级委派 × 记忆 × 反思的组合。它的核心创新不在执行拓扑上，而在记忆系统——每次完成复杂任务后自动创建Skill文档，Skill在后续使用中自动优化。这让它成为一个"越用越快"的Agent。

为什么这样选？因为个人助手场景的核心挑战是个性化和持续改进——用户的需求会随时间演变，Agent需要记住偏好、积累经验。层级委派处理复杂任务，记忆和反思让Agent持续进化。

交叉矩阵：选型速查

场景特征	推荐拓扑	关键认知能力	代表框架
固定流程，低风险	链式	感知、行动	Dify Workflow
意图分类，快速响应	路由	感知、推理	传统客服Bot
多源数据采集	并行	感知、表达	Deep Research Agent
复杂业务协作	编排	推理、行动、反思	Agentforce Atlas 3.0
质量标准明确，需迭代	循环收敛	反思、治理	Claude Code
长程复杂任务	层级委派	推理、记忆、反思	Hermes Agent

五、下一步：自我进化是终极架构

回到开头的论点：Agent架构的本质是为语义不确定性设计约束机制。

我们已经走过了四个阶段：

1. 被动式ReAct（2023）：一问一答，增强版Chatbot
2. 结构化Workflow（2024）：用工程约束弥补模型不确定性
3. 自主Agent（2025）：复杂规划与长程任务
4. 自进化Agent（2026）：持续学习与自我升级

第四个阶段的核心变化是：Agent不仅在完成任务，更在完成任务的过程中积累经验、优化策略、升级自身。Hermes的Skill自创建、OpenClaw的集体技能树搜索、清华GTR框架的"用过去的自己教现在的自己"——这些都是自进化的早期形态。

这意味着什么？

意味着架构本身也在进化。GoF的架构是静态的——设计模式一旦确定就不会变。分布式的架构是半静态的——熔断阈值、重试策略需要人工调整。而Agent架构正在走向动态自适应——Loop的终止条件可以自己调整，记忆的重要性评分可以自己更新，工具选择策略可以自己优化。

用认知功能的语言来说：Agent正在获得"治理自己"的最高级形态——不是被人治理，而是治理自己。

这可能是软件架构史上最深刻的范式转换。从GoF到分布式再到Agent，架构的演进方向始终是：从外部约束走向内部自治，从确定性设计走向不确定性适应，从静态结构走向动态进化。

结语：架构师的下一步

如果你是Java出身、有分布式经验、现在要转Agent架构，你其实有天然优势。

GoF教会你的"接口抽象、职责分离、松耦合"没变。分布式教会你的"容错设计、幂等性、最终一致性"没变。变的是：你的系统里多了一个"语义推理引擎"（LLM），它的输出不确定、行为不可完全预测、但具备理解和创造的能力。

Agent架构师的核心技能不再是"设计确定性的组件交互"，而是"设计不确定环境下的约束与适应机制"——定义清楚目标是什么、验收标准是什么、出错时怎么处理、成本上限是多少，然后让Agent在这些约束内自主运行。

从写Prompt到写Loop，从操作工到架构师。这就是Agent时代对架构师的要求。

参考来源：

1. Gartner AI Agent Harness Engineering报告 - CSDN解读^[1]
2. Addy Osmani: Loop Engineering - The Next Gen Tech Insider^[2]
3. Agent核心技术范式迭代 - CSDN^[3]
4. 2026年AI Agent十大趋势 - CSDN^[4]
5. Microsoft ISE: Coordinator Patterns - Microsoft DevBlogs^[5]
6. Agentic AI: Architecture, Frameworks and Applications - MDPI^[6]
7. Agent记忆觉醒 - CSDN^[7]
8. OpenClaw vs Hermes - Cognio^[8]
9. Salesforce Agentforce Multi-Agent - Halmob^[9]
10. Databricks Omnigent Meta-Harness - Tokention^[10]
11. Loop Engineering深度解读 - CSDN^[11]
12. Agent元认知能力解构 - CSDN^[12]
13. ADK多智能体编排 - CSDN^[13]
14. 清华GTR框架 - 36Kr^[14]
15. Multi-Agent Systems Practical Guide - JobsByCulture^[15]

引用链接

[1] CSDN解读: https://blog.csdn.net/2501_91473495/article/details/160511196
[2] The Next Gen Tech Insider: https://www.thenextgentechinsider.com/pulse/addy-osmani-introduces-loop-engineering-for-autonomous-coding-agents
[3] CSDN: https://blog.csdn.net/CSDN_224022/article/details/161387343
[4] CSDN: https://blog.csdn.net/qq_31142761/article/details/161346302
[5] Microsoft DevBlogs: https://devblogs.microsoft.com/ise/coordinator-patterns-multi-agent-systems/
[6] MDPI: https://www.mdpi.com/2673-2688/7/6/219
[7] CSDN: https://blog.csdn.net/wuyoudeyuer/article/details/160507777
[8] Cognio: https://cognio.so/resources/guides/openclaw-vs-hermes
[9] Halmob: https://halmob.com/blog/salesforce-agentforce-multi-agent-orchestration-atlas-3
[10] Tokention: https://tokention.com/databricks-open-sources-omnigent-a-meta-harness-that-composes-governs-and-shares-ai-agents-across-claude-code-codex-and-pi/
[11] CSDN: https://blog.csdn.net/TheChosenOnev/article/details/162046785
[12] CSDN: https://blog.csdn.net/2501_91912247/article/details/161266234
[13] CSDN: https://deephub.blog.csdn.net/article/details/159863765
[14] 36Kr: https://36kr.com/p/3856803248847495
[15] JobsByCulture: https://jobsbyculture.com/blog/multi-agent-systems-guide-2026