从workflow到ReAct提升AI Agent智能化水平

使用workflow模式的Agent

我们先分析之前运维案例中的workflow，它们执行步骤和逻辑是在workflow中预设好的：

这不由得让人反思我们这类智能体的“智能”体现在哪里呢？答案是这些Agent中不仅仅有workflow，更关键是其中用到的LLM。

比如在这个运维案例中，是利用LLM的文字生成和整合能力，输出故障的最终解决方案，虽然前序知识检索环节有可能检索到故障对应的答案，但这些答案往往比较简略，还需要LLM根据Prompt指令“按【原因分析】、【影响范围】、【处置建议】结构化输出”，并且指定如果当前序环节没有检索到答案时，还需要LLM能自行分析并生成解决办法。

我们再看看笔者之前另外一个中考小助手案例中，利用的是LLM进行语义理解和意图识别，要区分用户输入的问题是在问某个学校的分数线，还是在问某个分数能上什么学校，还是其他问题等，然后在workflow中才能根据不同的意图，走不同分支的处理逻辑。

所以在我们大多数场景中，用workflow这种模式，再结合LLM的语义理解、意图识别、文字生成和整合能力就能够实现一个较好的Agent。

使用Function Call实现ReAct框架

以上workflow模式的Agent核心是执行逻辑是可预设的，但有些业务场景中业务执行逻辑是不确定的，是要依据前序环节的执行结果，动态决策下一步该怎么做，也就是对应ReAct框架的思考-行动-观察的闭环，如下图所示（源图来自https://react-lm.github.io/）：

这个图很好地说明了右边ReAct框架相比原有模式的区别，每次要观察observe上一次行动action的结果，也就是将上次调用结果作为输入，再输入给LLM，一起去思考下一步该如何action。

ReAct框架‌（Reasoning + Acting）是一种结合推理与行动的多步骤高阶任务执行范式，而上图中LLM与外部工具/环境ENV交互action的‌基础能力‌，就是依靠Function Call作为底层支撑技术。

‌Function Call‌是大型语言模型（LLM）通过‌语义理解与结构化输出‌调用外部工具的核心能力，其实现依赖以下关键环节：

1. 
   如图所示整个过程包括：定义函数，生成函数描述Schema，将用户输入和函数描述一起输入调用LLM，解析LLM的输出，如果有输出函数名和参数则执行该函数，再将函数结果反馈给LLM，实现下一轮调用，直至输出最终结果。

• 这个过程中，大家经常说的通过function call让LLM具备了调用外部工具的能力实际只是一种形象化的表达，真正函数调用或者说工具执行，还是在agent的代码里去实现的，这里LLM‌的作用主要是两点（也就是图中红色块内容）：
• ‌动态决策‌：根据上下文判断是否需要调用函数（例如回答天气查询时要反馈get_weather()函数）‌。
• ‌输出接口：通过JSON等格式输出函数名和对应参数，确保外部工具的可执行性‌。
• 为了更直观地理解这个过程，我让LLM生成一段Python样例代码，如下：

import openai
import json
from typing import get_type_hints
# 示例函数定义
def get_current_weather(location: str, unit: str = "celsius") -> str:
    """获取指定地区的当前天气情况"""
    # 这里模拟天气数据
    weather_data = {
        "beijing": {"celsius": 22, "fahrenheit": 72},
        "new york": {"celsius": 18, "fahrenheit": 64}
    }
    returnf"{location}天气：{weather_data.get(location.lower(), {}).get(unit, '未知')}°{unit}"
def calculate(expression: str) -> float:
    """执行数学计算（支持加减乘除）"""
    try:
        returneval(expression.replace("^", "**"))
    except:
        return"计算错误"
# 生成函数描述JSON Schema
def generate_function_schema(func):
    hints = get_type_hints(func)
    doc = func.__doc__.split("\n") if func.__doc__ else""
    
    return {
        "name": func.__name__,
        "description": doc,
        "parameters": {
            "type": "object",
            "properties": {
                param: {
                    "type": "string"if hints.get(param) == strelse"number",
                    "description": f"{param}参数"
                } for param inlist(hints.keys())[:-1]  # 排除返回类型
            },
            "required": list(get_type_hints(func).keys())[:-1]
        }
    }
# 可用函数列表
available_functions = {
    "get_current_weather": get_current_weather,
    "calculate": calculate
}
# 生成函数描述列表
functions = [generate_function_schema(func) for func in available_functions.values()]
# 与LLM交互的核心函数
def run_conversation(user_query: str):
    # 第一次LLM调用（选择函数）
    response = openai.ChatCompletion.create(
        model="gpt-3.5-turbo-0613",  # 要选择支持函数调用的模型
        messages=[{"role": "user", "content": user_query}],
        functions=functions,   # 输入函数定义
        function_call="auto"
    )
    
    response_message = response["choices"]["message"]
    
    # 如果LLM选择调用函数，就会在输出response_message中，把要调用的函数和对应参数都输出
    if response_message.get("function_call"):
        function_name = response_message["function_call"]["name"]
        function_args = json.loads(response_message["function_call"]["arguments"])
        
        print(f"LLM选择调用函数: {function_name}")
        print(f"参数: {function_args}")
        
        # 执行对应函数
        if function_name in available_functions:
            function_to_call = available_functions[function_name]
            
            # 参数类型转换
            try:
                args = {k: str(v) for k,v in function_args.items()}  # 统一转为字符串
                if function_name == "calculate":
                    args["expression"] = args["expression"].replace(" ", "")
                # 敲黑板 注意：实际执行函数还是本地代码，并不是LLM直接去调用哈 
                result = function_to_call(**args)  
                returnf"执行结果: {result}"
            except Exception as e:
                returnf"执行错误: {str(e)}"
        else:
            return"未知函数调用"
    else:
        return"未触发函数调用"
# 测试用例
if __name__ == "__main__":
    test_cases = [
        "北京现在的气温是多少？",
        "帮我计算(3 + 5) * 2^3的值",
        "今天纽约的天气怎么样？用华氏度"
    ]
    
    for query in test_cases:
        print(f"\n用户问：{query}")
        print("->", run_conversation(query))

1. 很多同学用Coze和元器来配置Agent时，可以直接写提示词来说明Agent的处理流程，可以指定插件挂载工具，有同学就问这种算什么模式？我们修改下之前那个中考小助手案例，这次我们不去配置工作流，而是按如下配置：
   

   笔者个人理解如果Prompt中把执行步骤描述得很清楚，就应该算是workflow模式，无非它是用文字来表达执行逻辑，同时利用LLM的function call能力，根据预定的执行逻辑调用预设好的插件。

   但如果Prompt只是描述目标，没有对执行步骤做详细描述，那应该可以说是ReAct模式，它通过右边的插件设置，将所有可以调用的工具/函数都提前注册进来，运行时和Prompt一起输入给LLM，由LLM自行规划处理路径，中间何时要调用外部插件，都是LLM自行决策的。

   无论怎么理解，只能说Coze的这个智能体已经很智能了。

2. 
   

从Function Call到MCP

搞清楚ReAct框架和Function Call的关系以后，我们再看看MCP（Model Context Protocol）大模型上下文协议，去年Anthropic推出的MCP概念，今年以来热度持续上升，尤其是OpenAI也宣布支持MCP以后，似乎一页之间万能手、通用agent等概念都有了落脚点。官网对MCP架构的介绍可以参考这个链接，主要架构图如下（https://modelcontextprotocol.io/introduction）：

其实笔者认为mcp和function call本质上没有太大区别，只是把函数调用的规范做了统一，按统一规范由mcp client发给远程某个MCP Server再执行具体tool。为了更直观地对比在ReAct框架中MCP和function call区别，我们画个图来表示，如下：

要实现mcp这种方式的工具调用，首先也是需要将函数/工具的描述信息schema先要输入给LLM，只不过functioncall是在本地生成函数描述的，而mcp则是远程从mcp server中自动拉取的工具描述，远程mcp server端有哪些工具的描述，是基于server端工具在开发时用注解的方式描述函数名、用途和参数信息来自动生成的。

和上文介绍的function call机制一样，LLM本身也不会真的去调用mcp server里的工具，LLM是个语言模型，它的输入输出永远是一段文本，它只是识别需要调用哪个工具，并将要调用的工具名、参数以json格式结构化文本输出，然后是由LLM所在的Host去调用。

这个Host有一个误区，网上看到的各种mcp文章，都是用Claude desktop、cursor或者dify、cherry studio这种工具来举例，很容易让人和mcp client这个概念混淆起来，实际这个host更常见的是Agent所在的代码，是通过在这个代码中引入mcp client包去发给远程mcp server去执行的。