Agent 架构的“乐高哲学”：控制流、记忆与协作的范式组合之道在真实的工程落地中，没有包治百病的‘银弹’。熟悉这些范式

Hello 大家好，我是 Casper。

本文我希望和你一起深入探讨 Agent 的核心架构范式。虽然 AI 业界目前尚未确立如同 POSIX 协议般的绝对工业标准，但伴随工程实践的收敛与落地，几种极具代表性的架构范式已逐渐成为共识。Agent 架构的演进，都是围绕着‘控制流 (Control Flow) 的转移方式’与‘状态与记忆 (State & Memory) 的管理机制’在做文章。

我们为什么要深入了解这些范式？因为在真实的工程落地中，没有包治百病的‘银弹’。熟悉这些范式，相当于为我们建立了一张高维度的‘架构地图’。当面临系统输出不稳定、多节点协作混乱、或特定任务难以闭环等具体问题时，我们可以跳出单一提示词工程的局限，快速匹配到最成熟的架构模式去解决痛点。

接下来，就让我们共同梳理，当下都有哪些主导业界风向的 Agent 架构范式。我会从范式的核心逻辑、控制流、使用场景、局限性、python伪代码、解决的痛点、实际应用场景来解释每个范式。

单线循环范式：ReAct（Reason + Act）

这个架构模式是目前最普及，也是很多Code Agent的首选的底层骨架。例如Claude Code、OpenCode等。

核心逻辑：交替进行思考和行动。模型不仅输出最终答案，还输出推理轨迹（Thoughts）。
控制流：思考 -> 行动 -> 观察 -> 思考 -> 行动 -> ... -> 结果 形成闭环，直到 Agent 认为任务已经完成
适用场景：步骤比较少的工具调用、简单的问答系统、轻量级的自动化任务。
局限性：当任务链条极长（比如完整的工程交付）时，单线循环极易陷入“死胡同”或无限循环，且随着上下文不断累积，很容易超出 Token 限制导致遗忘。
伪代码：

def react_agent(task_prompt):
    system_prompt = "你是一个可以使用外部工具的 Agent。请遵循 Thought, Action, Observation 的格式。"
    history = [task_prompt]
    
    while True:
        # LLM 生成当前步骤的思考和动作
        response = llm.generate(system_prompt, history)
        thought, action, tool_args = parse_llm_output(response)
        
        print(f"Thought: {thought}")
        
        # 如果判断任务完成，则退出循环
        if action == "FINISH":
            return tool_args # 返回最终结果
            
        print(f"Action: 调用工具 {action} 参数 {tool_args}")
        
        # 执行工具调用 (例如通过 MCP 协议调用本地/远程 API)
        observation = execute_tool(action, tool_args)
        print(f"Observation: {observation}")
        
        # 将观察结果追加到上下文中，进入下一轮迭代
        history.append(f"Observation: {observation}")

解决的痛点：大语言模型（LLM）本身是一个“缸中之脑”，虽然有着强大的理解和生成能力，但在实际工程应用中存在几个致命的弱点。ReAct 范式的出现，主要就是为了解决这些痛点：
- 打破“知识孤岛”与时效性限制： LLM 的知识停留在预训练结束的那一刻。ReAct 通过 Action（行动）和 Observation（观察）机制，让模型拥有了“手和眼睛”。它可以调用外部 API（例如通过 MCP 协议接入系统工具或数据库），通过这一循环，Agent可以实现：实时获取最新的股价、系统日志或业务数据，从而解决了知识时效性和本地私有数据无法直接访问的问题。
- 大幅降低“幻觉/Hallucination”：在纯文本生成中，模型很容易在一本正经地胡说八道。ReAct 强制模型在得出结论前，必须基于真实的 Observation（环境反馈）来进行下一轮的 Thought（推理）。这种“用事实引导推理”的闭环，有效收敛了大模型的发散性，极大地降低了业务执行中的幻觉率。
- 解决“盲目执行”的黑盒问题：传统的指令执行往往是单步的（给输入，出结果）。ReAct 将思考过程显式化，每一步操作前都会先输出一段 Thought。这在工程上非常关键，因为它赋予了开发者和系统可解释性（Explainability）——当 Agent 执行出错时，我们可以清晰地通过它的 Thought 知道它是在哪一步逻辑跑偏的。
实际应用场景：因为 ReAct 的控制流是线性的（Thought -> Action -> Observation -> 循环），它的认知负荷和状态管理相对简单。因此，它非常适合需要高频与外部环境交互、且任务链路较短的“单体作战”场景。
- 轻量级终端与研发助手 (Terminal & Dev Assistants)：这是目前开发者最熟悉的场景。比如您在终端里让 Agent “查一下昨天生产环境的报错”。Agent 会先思考（需要查日志），执行 grep 命令查询昨天日期的 Error 级别日志（Action），看到终端返回的几百行堆栈信息（Observation），再次思考（发现是某个特定接口超时），最后执行后续的分析或修复建议。
- 动态信息检索与企业级 RAG 问答：传统的 RAG（检索增强生成）往往只检索一次。而搭载了 ReAct 架构的问答 Agent，可以进行多跳查询（Multi-hop Question Answering）。如果第一轮检索出的知识库文档不够，它会根据阅读到的内容，自动构建新的查询词，发起第二次或第三次数据库检索，直到拼凑出完整的答案。
- 单一职能的 API 调度调度员：非常适合用于客服路由、智能家居控制或轻量级的工单系统。例如，用户发了一段复杂的售后诉求，ReAct Agent 会思考“这是退款请求”，调用“订单查询 API”，观察到“订单符合退款条件”，然后调用“退款审批 API”，最后回复用户。

规划与反思范式 (Planning & Reflection)

为了解决单体 Agent 执行复杂任务容易跑偏的问题，引入了显式的规划和自我纠错机制（如 Reflexion、Plan-and-Solve、Tree of Thoughts）。

核心逻辑：在执行前引入显式的任务分解与策略规划，并在执行后引入自我纠错机制，形成具备进化能力的自主循环 (Autonomous Loops)。
运行机制：
- 规划 (Planning)：接收复杂任务后，不立即行动，而是先生成一棵任务树或子任务序列（如 Plan-and-Solve）。
- 反思 (Reflection)：在每个子节点执行完毕后，Agent 会主动评估当前产出与预期目标的差距。如果失败，系统会记录错误路径，自我修正 Prompt 或调用策略，然后重试。
适用场景：复杂代码逻辑生成、需要不断试错的系统级排错、以及容错率较高的开放性探索任务（例如在 Vibe Coding 模式下让模型自主解决 Bug）。
局限性：Token 消耗极其庞大，且执行链路长导致响应延迟极高，不适合对实时反馈有要求的交互场景。
伪代码：

def reflection_agent(complex_task):
    # 1. 规划阶段：将大任务拆分为子任务树
    plan = llm.generate_plan(complex_task)
    results = []
    
    for sub_task in plan:
        max_retries = 3
        attempts = 0
        
        # 2. 执行与反思阶段：具备自主纠错的 Loop
        while attempts < max_retries:
            code_or_result = llm.execute_task(sub_task, context=results)
            
            # 评估器 (可以是另一个模型或纯代码测试集) 验证结果
            is_success, error_feedback = evaluate_result(code_or_result, sub_task)
            
            if is_success:
                results.append(code_or_result)
                break 
            else:
                # 失败则进行反思，调整 Prompt 或策略再次尝试
                reflection = llm.reflect(f"任务: {sub_task}, 产出: {code_or_result}, 报错: {error_feedback}")
                print(f"Reflecting on error... strategy update: {reflection}")
                attempts += 1
                
        if attempts == max_retries:
            raise Exception("任务执行失败，已达到最大重试次数")
            
    return results

解决的痛点：如果说 ReAct 是“走一步看一步”，那么 Planning & Reflection 就是“谋定而后动，知止而有得”。它主要解决了大模型在复杂任务中的两个核心瓶颈：
- 解决长流程任务的“全局视野缺失”与“上下文灾难”：当面临一个宏大的目标（比如从头开发一个 Web 平台）时，单一的 Prompt 往往会让模型首尾不能兼顾，累积的无效对话更会带来极高的“上下文税 (Context Tax)”。规划 (Planning) 机制强制 Agent 在写第一行代码或执行第一个动作前，先将复杂任务拆解为树状或线性的子任务序列（如 Plan-and-Solve）。这保证了系统始终有一个“全局路线图”，不会因为走得太远而忘记为什么出发。
- 解决单次生成“容错率极低”的脆弱性：传统的代码生成，一旦大模型写错了一个变量，整个链路就会崩溃。反思 (Reflection) 机制引入了闭环的自我纠错能力（如 Reflexion 框架）。当子任务执行失败（比如编译不通过、测试用例跑挂），Agent 不会直接把错误抛给人类，而是将错误日志作为新的输入，反思“我刚才哪里做错了？”，然后自我修正策略并重试。这种机制把大模型从“一次性生成器”变成了具备韧性的“自主循环体 (Autonomous Loops)”。
实际应用场景：因为这种范式需要消耗大量的 Token 进行任务树的构建和不断的试错重试，它并不适合要求毫秒级响应的实时交互场景，而是极度契合那些重交付、重逻辑、且容错率较高的离线异步任务。
- Vibe Coding 与全自动软件工程：这是目前该范式最闪耀的舞台。在 AI 辅助开发中，为了彻底降低开发者人工 debug 的“心跳监控”成本，我们可以让 Agent 自主接管复杂的重构工作。Agent 会先规划出模块结构和 API 定义，然后再逐个实现。如果运行报错，Reflection 机制会自动捕获终端日志，自我修复代码，直到所有的单测跑通。这真正意义上解放了开发者的双手。
- 深度的量化分析与复杂研报撰写：在处理金融级的数据分析任务时，不能依靠大模型一气呵成。系统需要先规划出获取 OHLCV 数据、运行统计模型（如 GARCH）、绘制图表的步骤。如果中间哪一步数据清洗格式不对导致报错，Agent 会反思并调整 Python 脚本，直到成功提取出可靠的因子数据，最后再汇总生成研报。
- 作为高级 Agent 沉淀“过程式记忆”的前置条件：这也是非常硬核的一个应用点。当我们想要构建具备自我进化能力的智能体（比如基于 Hermes 思想的架构）时，反思机制是必不可少的。只有当 Agent 通过反思机制成功解决了一个复杂的 Bug，它才能把这段“犯错到纠错再到成功”的经验，提炼成固化的技能（Skill），存入过程式记忆库中，供未来复用。

这里有一个代表例子：OpenHands 是目前最具代表性的自主软件工程师项目之一。当给它一个复杂的 Issue 或功能需求时，它不会立刻盲目写代码，而是进入规划层：生成一个开发步骤列表。在执行写代码的子任务时，它会在沙箱环境中实际运行代码（Action），如果终端抛出错误日志（Observation），它会触发反思机制（Reflection），分析报错原因，自我修改 Prompt 和代码，然后再次运行，直到测试通过。

记忆驱动 / 认知架构 (Memory-Centric Architectures)

这种范式是希望让Agent能够模拟人类的认知结构，将“记忆”提升到了核心位置，致力于让 Agent 具备长期演进的能力。

核心逻辑：高度模拟人类认知结构，将“记忆”作为系统的核心枢纽，致力于让 Agent 能够跨越会话边界，实现真正的长期演进。
运行机制：系统将上下文与状态存储进行严格分层。
- 短期记忆：维护当前上下文窗口。
- 长期记忆：进一步精细化拆解。声明式记忆 (Declarative Memory) 负责固化事实、业务文档和历史状态（通常存入向量库或知识图谱）；过程式记忆 (Procedural Memory) 则负责提炼以往成功的执行经验，将其沉淀为可复用的代码逻辑、标准化流程或具体技能 (Skills)。
适用场景：需要长期伴随并学习用户行为习惯的专属智能体、具备深度自我优化能力的复杂 Agent 系统的底层调度内核。
局限性：工程实现复杂度极高。核心瓶颈在于长尾记忆的检索召回率、知识冲突的解决、以及如何设计优雅的记忆衰减（遗忘）机制以防止记忆库污染。
伪代码：

class SimpleHermesMemoryAgent:
    def __init__(self):
        self.declarative_db = VectorDB() # 声明式记忆：存事实、文档、偏好
        self.procedural_db = SkillDB()   # 过程式记忆：存可执行的经验和代码片段
        self.short_term_memory = []      # 工作记忆：当前 Session
        
    def process_query(self, user_query):
        # 1. 从长期记忆中检索上下文和用户偏好
        facts = self.declarative_db.search(user_query)
        # 例如检索到历史强制规则："数据库设计必须使用 single table design (单表设计)"
        
        # 2. 检索是否已有现成的处理技能 (Skill)
        skills = self.procedural_db.match_skill(user_query)
        
        # 3. 结合记忆生成 Prompt 并执行
        prompt = build_prompt(user_query, facts, skills, self.short_term_memory)
        response = llm.generate(prompt)
        
        # 4. 记忆固化：从当前交互中提取新的知识或技能，沉淀到长期记忆中
        new_fact = llm.extract_knowledge(user_query, response)
        if new_fact: self.declarative_db.save(new_fact)
        
        new_skill = llm.extract_procedural_logic(response)
        if new_skill: self.procedural_db.save(new_skill)
        
        return response

解决的痛点：大家在实际开发中肯定遇到过这种抓狂的情况：Agent 昨天刚通过“反思”踩过了一个坑，今天开启一个新会话，遇到一模一样的问题，它居然又要重新踩一遍。为了解决这种“每天都是初恋”的跨会话遗忘症，业界开始将目光转向人类的认知科学，记忆驱动 / 认知架构 (Memory-Centric Architectures) 也就应运而生。这也是目前构建具备真正自主进化能力的顶级 Agent 的必经之路。相比于单纯依赖外部向量数据库的 RAG（检索增强生成），记忆驱动架构有着本质的区别，它主要攻克了以下几个核心痛点：
- 突破大模型的“上下文窗口”极限：无论模型的 Context Window 扩展到几百万 Token，把所有历史丢给模型都是极其昂贵且低效的（也就是我们常说的 Context Tax 过高）。记忆架构通过精细化的分层调度（类似操作系统的内存分页机制），只在必要时将长期记忆“唤醒”到工作记忆中，实现了逻辑上的“无限上下文”。
- 跨越会话边界的“状态持久化”：普通的 Agent 刷新页面就重置了。而记忆架构让 Agent 拥有了时间连续性。它能记住用户的偏好、历史的失败教训，以及系统环境的状态变量，让每一次交互都建立在过往的经验之上。
- 实现系统层面的“自我进化 (Self-Evolution)”：这是记忆架构最迷人的地方。系统不再仅仅是被动查询数据，而是能在每次“规划与反思”成功后，主动从经验中提炼知识，沉淀为新的底层能力。
实际应用场景：记忆驱动架构工程复杂度极高，主要应用于需要长期陪伴和深度个性化的场景：
- 深度个性化的专属 AI 研发伙伴：在极客的 Vibe Coding 工作流中，我们需要的是一个能懂自己代码习惯的副驾驶。基于记忆架构的 Agent 会在日复一日的协作中，记住你公司的特定鉴权逻辑、你偏好的命名规范、甚至是你私有部署的 API 接口。时间越久，它的沟通成本越低。
- 可进化的垂直领域专家系统：在打造一站式工程交付平台或复杂的量化投研系统时，底层引入记忆内核，可以让系统不仅能生成代码或研报，还能将高级工程师或量化研究员的优秀“解题思路”沉淀为系统的 Procedural Memory，让系统能力伴随团队的使用不断升维。

这里在多说一些，在先进的架构设计（例如业界探讨的 Hermes 等前沿高阶认知架构思想）中，系统的记忆通常会被严格划分为以下几个区域：

工作记忆 (Working / Short-term Memory)：可以理解为计算机的 RAM，或者是当前的 Prompt 上下文窗口。它负责处理当下的任务，容量有限，但是访问速度最快、相关性最高。
声明式记忆 (Declarative Memory)：可以理解为“静态事实库”。Agent 会主动将沟通中的业务事实、历史状态和环境偏好固化在这里。比如在系统开发中，Agent 记住了“当前业务库的统计模块必须严格遵循单表设计，不可过度设计”，在未来的会话中，它就会自动调取这条记忆来约束代码生成。
过程式记忆 (Procedural Memory)：这是记忆架构的灵魂所在，可以理解为“动态技能库”。它存储的不是死板的事实，而是“如何做某事”的执行逻辑。当 Agent 经历了一次艰难的“试错-反思-成功”循环后，底层的记忆管理机制会提取出这套成功的“行动序列”，将其封装成一段可直接调用的 Skill 代码。下次遇到同类问题，Agent 不需要再重新规划反思，直接从过程式记忆中调取该技能即可。

除了我们提到的Hermes Agent 还有另外一个例子： Letta, Letta的设计理念非常硬核，它将操作系统的内存分层管理机制引入了 LLM。它明确划分了 Main Context（类似内存 RAM，受限于 Token 窗口，存放系统 Prompt 和短期对话）和 External Context（类似硬盘磁盘，依托向量库，存放长期记忆和海量历史文档）。它通过主动调度分页（Paging）技术，让 Agent 能够根据需要，自主判断何时将短期对话固化到长期记忆中，何时又从长期记忆里将遗忘的事实检索回工作台。

当然了，大家可能会有一个疑问：“如果我外挂一个向量数据库来存储用户画像和用户的一些记忆，之后将如何使用这些内容通过MCP注册到Agent中，那么和当前的设计模式有什么区别呢？” 从工程实现的角度来说，我们目前通过 Vector Store + MCP 协议注册记忆工具的方案，其实已经是在构建“声明式记忆 (Declarative Memory)”了。这是目前业界非常主流且高效的落地手段。但在更高维度的理论与顶层系统设计中（比如构建一个极其庞杂的通用大模型交付平台，或者类似于某些旨在实现自我演进的智能体底层引擎），你现在的做法和原生的“认知记忆架构”在控制反转 (Inversion of Control)、生命周期管理以及记忆形态上，依然存在决定性的差异。这里主要有三个差异点：

架构核心差异：是谁在掌控“控制流”？ (控制反转) 这是最本质的区别。 Vector Store + MCP 工具调用：LLM 是系统的主导者。Agent 收到任务后，LLM 的主干推理流必须先进行 Thought：“我现在处理的这个任务，可能需要用到用户的环境配置或历史偏好，我应该调用一下 MCP 里的 fetch_user_memory 工具”。这里的隐患在于：它极度依赖当前 LLM 的指令遵循能力和状态。如果任务本身极其复杂（比如让它写几百行代码），LLM 的注意力资源会被核心任务榨干，它极有可能“忘掉”去调用这个 MCP 工具，导致记忆失效。但是在“认知架构”中，记忆管理器（Memory Manager）是系统的主导者。在这种架构中，LLM 只是一个“计算内核（CPU）”，外面包裹着一层“操作系统（OS）”。当用户输入 Query 时，并不是直接丢给 LLM 的。底层的 Memory Manager 会先拦截请求，主动进行语义检索和状态比对，将关键的环境记忆无缝拼接到当前的工作记忆（Working Memory / Prompt上下文）中。LLM 在开始推理的第一秒，记忆就已经在它的“脑子”里了，它根本不需要去思考“我要不要去调用工具查一下”。
记忆的生命周期：是被动存储，还是后台的异步演进？如果我们选择外挂的形式，数据往往是外部系统或开发者提前灌入 Vector Store 的。如果想要 Agent 自主学习，你需要给它再注册一个 save_memory 的 MCP 工具，让 Agent 在完成任务后自己决定要不要保存。这又加重了单体 Agent 的认知负担。但是在“认知架构”的逻辑中，当一个复杂的业务流结束时，主 Agent 的工作就完成了。但系统后台会启动专门的 Reflection 守护进程。这个进程会自动回顾刚才的会话，评估哪些是瞬时噪音，哪些是核心事实，然后将其压缩、向量化，甚至更新现有的知识图谱。这种“白天工作，夜晚做梦沉淀”的机制，是脱离主干流程独立存在的。
记忆的形态：只有“文本事实”，还是包含“可执行技能”？向量存储+工具调用主要处理的是“声明式记忆 (Declarative Memory)”向量库里存的大多是 Fact（事实）。比如你告诉 Agent 你的代码习惯，它通过 MCP 查到了：“哦，用户的数据库偏好是只用单表设计 (Single Table Design)”。这非常棒，它指导了下一次的代码生成。认知记忆架构中更强调整合“过程式记忆 (Procedural Memory)”。如果在一次复杂的报错排查中，Agent 发现了一种特殊的处理某个框架高并发的逻辑。底层的记忆引擎不仅会记录文本，还会将这段成功的逻辑提炼为一段可执行的代码或 AST（抽象语法树），封装成一个新的 Skill。当下一次触发相似场景时，系统不是把“文本经验”喂给 LLM 让它重写一遍，而是直接把这个封装好的 Skill 作为新的原生工具注入到运行环境中。这是从“查阅文档”到“肌肉记忆”的根本飞跃。

多智能体协同范式 (Multi-Agent Systems, MAS)

当单体 Agent 无法处理高度复杂的工程交付时，多智能体架构通过分工协作来降低单一模型的认知负荷。

核心逻辑：通过“角色分工”和“群体智慧”，将庞大复杂的任务拆解给多个专精领域的小模型或特定设定的 Agent，从而大幅降低单一 Agent 的认知负荷和幻觉率。
运行机制：通过定义不同的拓扑结构进行编排：
- 流水线模式：上游 Agent（如需求分析）的输出，作为下游 Agent（如代码编写）的输入。
- 中心路由模式：一个主管 Agent 负责意图识别，将任务分发给具体的专家 Agent。
- 辩论/对抗模式：多个 Agent 针对同一份产出互相 Review 和提出质疑，最终达成共识。
适用场景：端到端的工程流水线交付（如一站式 Web 工程生成）、深度的商业或金融量化分析报告撰写、多视角的决策推演。
局限性：多节点通信带来的协同开销极大；若编排不当，Agent 之间容易产生“旁观者效应”或陷入无限争论；极难保证整个系统的全局输出一致性。
伪代码：

def multi_agent_delivery_system(requirement_doc):
    # 定义不同专长的 Agent
    pm_agent = Agent(role="Product Manager", model="claude-3.5-sonnet")
    arch_agent = Agent(role="Software Architect", model="gemini-1.5-pro")
    dev_agent = Agent(role="Developer", model="gpt-4o")
    qa_agent = Agent(role="QA Engineer", model="claude-3.5-sonnet")
    
    # 瀑布流编排 (流水线模式)
    print("PM 正在拆解需求...")
    prd = pm_agent.run(requirement_doc)
    
    print("架构师正在设计 API 与数据表...")
    system_design = arch_agent.run(prd)
    
    print("开发正在编写代码...")
    source_code = dev_agent.run(system_design)
    
    print("QA 正在进行 Review 与测试验证 (对抗/审查模式)...")
    feedback = qa_agent.review(source_code, prd)
    
    if feedback.has_issues:
        # 打回重写
        source_code = dev_agent.run(f"根据 QA 意见修复: {feedback.details}", context=source_code)
        
    return source_code

解决的痛点：用“分工与协作”来对抗问题的复杂性。它主要解决了单体大模型在复杂工程中的两大死穴：
- 化解“角色冲突”与“注意力稀释”：如果你让一个 Agent 同时扮演产品经理和测试工程师，它的大脑是分裂的。产品经理的潜意识是“快速实现功能”，而测试的潜意识是“找茬和保持严谨”。在 MAS 范式下，我们通过实例化具有不同 System Prompt 的专家 Agent，实现了物理层面的身份隔离。专门写代码的就专注逻辑，专门 Review 的就专注挑错，让每个模型将注意力100%聚焦在单一领域。
- 将人类的 SOP（标准作业程序）代码化：单体模型往往缺乏宏观的工程学常识。MAS 架构允许开发者将一家成熟软件公司的组织架构和流水线流程，直接翻译成 Agent 之间的网络拓扑结构，从而大幅提升复杂交付物的规范性和成功率。
实际应用场景：多智能体协同范式几乎是目前所有企业级“端到端”生成平台的核心基石。
- 一站式全栈工程自动交付：当你想要打造一个能根据一句话需求，自动生成前后端代码、API 接口并完成部署的平台（也就是我们常说的高级 General Agent 平台）时，MAS 是唯一解。复杂的工程必须拆解给多个互相协作的数字员工。
- 深度的研报撰写与数据推演：例如在一套量化分析系统中，抓取数据、清洗数据、运行统计模型、撰写分析报告这四个步骤，跨越了截然不同的领域。让数据处理 Agent 和金融分析 Agent 各司其职，通过 Router 调度，产出的报告质量会产生质的飞跃。
- 仿真环境与游戏 NPC 生态：斯坦福经典的“AI 小镇”就是 MAS 的代表作。多个具备不同设定和短期/长期记忆的 Agent 在同一个沙盒环境中交互，涌现出复杂的社会行为。

这里再介绍一个架构 MetaGPT 严格模拟了一家标准软件公司的 SOP（标准作业程序）。在这个框架下，你输入一句话的老板需求，系统会依次实例化产品经理 Agent（写 PRD）、架构师 Agent（设计系统骨架与接口）、工程师 Agent（编写业务代码）和测试 Agent（质量把控）。

工作流与状态机范式 (Workflow & FSM)

刚才我们提到，多智能体系统（MAS）虽然强大，但 Agent 越多，系统就越像个“草台班子”。几个大模型在一起“开会”，沟通成本极高，甚至有时候会陷入为了讨论而讨论的无限死循环。在真实的企业级生产环境中，我们绝不能容忍这种失控。比如：金融数据不能被幻觉篡改，核心业务代码不能因为两个 Agent 意见不合而无限期卡住。为了给这群聪明但不稳定的天才们套上一个绝对安全的“缰绳”，我们迎来了目前工业界落地最深、也是最重要的压轴范式：工作流与状态机 (Workflow & FSM)。

这是一种混合架构，将 LLM 的非确定性生成能力与传统软件工程的确定性控制流结合起来（例如 LangGraph 的设计思想）。

核心逻辑：将大模型非确定性的生成能力，关进传统软件工程确定性的控制流“笼子”里，实现可控的 AI 交付。
运行机制：将完整的业务流程定义为有向无环图 (DAG) 或有限状态机 (FSM)。图中的每一个“节点”可以是执行具体任务的 Agent，也可以是传统的纯代码函数。节点之间的“边”则通过 LLM 的分类输出或传统的 if-else 逻辑进行严格的路由流转。
适用场景：追求极高稳定性和确定性交付的企业级内部研发平台、严谨的量化交易执行链路、工业生产线级别的自动化系统。
局限性：大幅牺牲了 Agent 本身的自主探索性和灵活性；系统的构建前置成本极高，需要开发者预先投入大量精力去设计和定义详尽的流程状态图。
伪代码：

from state_machine import StateMachine, State

def build_quant_workflow():
    workflow = StateMachine()
    
    # 定义确定性的节点 (有些是纯代码，有些是 LLM 节点)
    node_fetch_data = CodeNode(action=fetch_ohlcv_data)
    node_run_model = CodeNode(action=run_garch_model)
    node_llm_analysis = LLMNode(prompt="根据以上量化数据，生成策略研报。")
    node_alert = CodeNode(action=send_dingtalk_alert)
    
    # 定义严格的流转逻辑 (Edges)
    workflow.add_transition(source="START", target=node_fetch_data)
    workflow.add_transition(source=node_fetch_data, target=node_run_model)
    
    # 路由分支：根据代码运行结果决定走向
    def check_volatility(context):
        return "HIGH_VOLATILITY" if context.data['volatility'] > 0.5 else "NORMAL"
        
    workflow.add_conditional_edges(
        source=node_run_model,
        condition_func=check_volatility,
        routes={
            "HIGH_VOLATILITY": node_alert,       # 波动率高，直接触发报警
            "NORMAL": node_llm_analysis          # 波动率正常，交由 LLM 写分析报告
        }
    )
    workflow.add_transition(source=node_llm_analysis, target="END")
    
    return workflow

# 执行状态机
quant_agent = build_quant_workflow()
quant_agent.run(stock_code="TSLA")

例子：Dify (或 Coze) 则在前端提供了可视化的拖拽面板。这种基于 DAG（有向无环图）的编排，是打造一站式通用智能体（General Agent）平台（如企业内部的 JoyGen 等系统）的核心基础设施。
解决的痛点：大模型的本质是基于概率的“非确定性”文本生成器，而传统的软件工程追求的是“绝对确定性”。Workflow 范式的核心逻辑，就是将 LLM 的非确定性，关进传统软件工程确定性控制流的“笼子”里。
- 终结“发散与失控”，保证 100% 确定性的交付：在纯粹的 Agent 系统中，控制流是由 LLM 自己决定的（比如 ReAct 靠大模型自己决定下一步干嘛）。而在工作流范式中，控制流是被硬编码（Hard-code）在系统里的。这保证了无论模型内部怎么发散，系统的宏观生命周期必须严格按照人类设定的节点流转。
- 实现“纯代码”与“大模型”的完美混编：在真实的业务线中，并非所有任务都需要大模型。比如读取数据库、发送鉴权邮件、抓取一段低频的 OHLCV 股票数据。在工作流范式下，我们可以将大模型降级为一个个普通的“功能节点”，与传统的API、函数无缝衔接。
- 实现“纯代码”与“大模型”的完美混编：在真实的业务线中，并非所有任务都需要大模型。比如读取数据库、发送鉴权邮件、抓取一段低频的 OHLCV 股票数据。在工作流范式下，我们可以将大模型降级为一个个普通的“功能节点”，与传统的 Python 函数无缝衔接。
实际应用场景：只要是追求极高稳定性和严谨性的场景，都必须引入工作流范式。
- 比如我们打造一个量化 Agent。它的底层绝不能完全交给大模型自由发挥。我们必须用 FSM 框死它的流程：第一步 Code Node 稳定调用接口获取市场数据，第二步 Code Node 运行本地的统计模型。只有当这些确定性极高的数据处理完毕后，状态机才会进入下一个环节，把清洗好的因子数据传给 LLM Node 进行自然语言层面的深度研报撰写。

到这里我们已经盘点完了目前业界最核心的五大 Agent 架构范式。从最基础的 ReAct，到谋定后动的规划反思，再到赋予系统灵魂的记忆架构、集中力量办大事的多智能体协同，最后是兜底工业级交付的工作流。

结语：

单一的范式往往只能解决某一类特定问题。随着 Agent 承担的任务越来越复杂，单纯依赖大语言模型的上下文涌现能力已经触及天花板。因此，在实际的工业级开发中，我们几乎不会“孤立”地使用某一种架构。目前业界将这种融合了多种 Agent 范式、外部工具和传统软件工程设计模式的复杂系统，统称为复合 AI 系统 (Compound AI Systems)。在真实的业务落地中，这些架构范式通常是相互配合、协同工作的。例如，我们往往会用工作流与状态机 (FSM) 来作为整个系统的“宏观骨架”，以确保核心业务流转的确定性；而在某些需要发散和创造的复杂节点内部，则会引入多智能体协作 (MAS) 来进行分工；当任务进一步细分到底层时，具体的 Agent 则通过 ReAct 闭环和规划反思 (Reflection) 机制来独立攻克技术难点；同时，全局的记忆架构作为基础设施，在整个生命周期中默默沉淀着经验教训。在这个阶段，没有任何一种架构范式是包治百病的“银弹”。我们去深入剖析和了解这些主流的 Agent 范式，核心目的正是为了打破思维局限。只有清晰地认知到每种设计的核心逻辑、适用场景与局限性，我们才能在面对真实的业务挑战时，游刃有余地根据系统的容错率、复杂度和性能要求，将它们像搭积木一样灵活组合起来，从而更好、更可控地解决复杂问题。