4. 了解哪些其他的 Agent 设计范式？Agent 和 Workflow的区别是什么？

💡 简要回答

我理解 Agent 和 Workflow 最核心的区别是「谁来决定下一步」。Workflow 是我提前把流程写死的，每一步怎么走都是固定的，确定性高、好控制；Agent 是让 LLM 自己决定下一步做什么，灵活但不可控。常见的设计范式除了纯 Agent 之外，还有 ReAct、Plan-and-Execute、Reflection 这几种。我在实际工程里用得最多的反而是把两者混用，固定流程的部分用 Workflow，需要灵活决策的节点嵌入 Agent 能力，这样既保住了整体可控，又有局部的灵活性。

📝 详细解析

在 Agent 开发里有一个非常基础但经常被忽视的问题：什么情况下该用 Agent，什么情况下该用 Workflow？ 这是实际工程里最常碰到的架构决策，弄错了要么过度工程化，要么系统一点都不可控。

Workflow 和 Agent 的区别

先把两者的本质区别说清楚。Workflow 就是一个确定性的流程图，你提前定好「第一步做 A，A 完了做 B，B 失败了走分支 C」，每一步的逻辑都是你硬编码进去的，LLM 只是其中某个节点的执行工具，不负责决策流程本身。好处是行为完全可预测、容易测试、出了问题好排查；坏处是灵活性低，遇到你没预料到的情况就会走入死胡同。

Agent 则相反，它把「下一步做什么」这个决策权交给了 LLM。你只告诉它目标，它自己判断该调哪个工具、该不该继续、什么时候算完成。好处是能处理你事先没设计进去的情况；坏处是行为不确定，同样的输入可能走出不同的路径，线上出了问题也很难复现。

光说文字可能还不够直观，我用代码结构来对比一下，你一眼就能感受到区别：

 Workflow 风格：流程固定，每步都是确定的，LLM 只是工具
def workflow_answer_question(user_query: str):
    # 第一步：固定做向量检索
    docs = vector_db.search(user_query, top_k=5)
    # 第二步：固定做 rerank（重排序，筛选最相关的结果）
    reranked = reranker.rank(user_query, docs)
    # 第三步：固定喂给 LLM 生成答案
    answer = llm.generate(user_query, context=reranked)
    return answer

 Agent 风格：流程不固定，LLM 自己在运行时动态决定每一步
def agent_answer_question(user_query: str):
    while True:
        # LLM 自己决定：要搜索？要计算？还是直接回答？
        action = llm.decide(user_query, history=memory)
        if action.type == "search":
            result = vector_db.search(action.query)
            memory.append(result)
        elif action.type == "calculate":
            result = calculator.run(action.expr)
            memory.append(result)
        elif action.type == "final_answer":
            return action.content

对比来看，Workflow 的每一行都是明确的指令，控制流完全由代码决定；Agent 的 loop 里只有 llm.decide()，所有路径都是 LLM 在运行时动态选的。两种风格在代码结构上就完全不一样，Workflow 是「开发者在驾驶」，Agent 是「LLM 在驾驶，开发者在副驾驶设了一些安全限制」。

Agent 三种设计范式

在具体的 Agent 设计范式上，目前主流的有这几种：

ReAct（Reasoning + Acting）是最常见的一种。它让 LLM 交替输出「思考」和「行动」，每次行动前先写出推理过程，行动后再根据结果继续思考。好处是推理过程可见，便于调试，决策也更稳定。
Plan-and-Execute 是把规划和执行分开的范式。先让一个 LLM 专门做规划，输出完整的任务步骤列表；再让另一个 LLM 或模块逐步执行。规划和执行解耦之后，复杂任务的整体结构更清晰，也方便在执行过程中对计划做局部修改。
Reflection（反思） 是在 Agent 完成一步之后，加一个自我评估的环节，让 LLM 判断这步做得对不对、结果是否符合预期，不行就重试或者调整策略。这能显著提升输出质量，但也会增加 token 消耗和延迟。

实际工程里，纯 Agent 模式其实用得不多，因为太难控制。

更常见的做法是**「Agentic Workflow」**，整体用 Workflow 框住主流程，在需要灵活处理的节点嵌入 Agent 能力。比如一个客服系统，意图识别 -> 知识检索 -> 回答生成这条主链路是固定的 Workflow，但「知识检索」这个节点内部可以用 Agent 来动态决定检索几轮、用哪些工具。这样既保住了整体可控，又有局部的灵活性，这是目前生产环境里最主流的做法。

两种模式的核心差异，直接对照看更直观：

维度	Workflow	Agent
决策者	开发者（硬编码流程）	LLM（动态决策）
确定性	高，行为完全可预测	低，同输入可能走不同路径
灵活性	低，流程固定	高，能处理预料之外的情况
调试难度	容易，链路清晰	困难，行为不确定
适用场景	流程相对固定的业务	需要灵活判断的复杂任务