2026年4月9日:AI助手做饭靠什么?后端Agent架构与Function Calling原理深度拆解

小编头像

小编

管理员

发布于:2026年04月20日

4 阅读 · 0 评论

2026年4月初春,整个科技圈正因为一只“龙虾”陷入狂热——名为OpenClaw的开源AI智能体框架在短时间内引发了从大厂员工到普通用户的全民“养虾”热潮,一个典型AI助手做饭的场景正在从科幻走进现实:用户只需一句“帮我做个番茄炒蛋”,AI就能自动感知食材、规划步骤、调用设备完成烹饪-1。很多开发者在面试中被问及相关技术时往往只能说出“用了大模型”,却讲不清Agent、Workflow和Function Calling之间的逻辑关系。本文将从最基础的后端AI架构出发,由浅入深讲解Agent与Workflow的概念区分、Function Calling的实现原理,并辅以可运行的代码示例和高频面试题,帮助你构建完整的AI智能体知识链路。

一、痛点切入:为什么传统后端架构搞不定AI做饭?

在AI智能体出现之前,一个烹饪助手功能通常是这样实现的:

python
复制
下载
 传统实现:硬编码的烹饪助手

def cooking_assistant(user_input): if "番茄炒蛋" in user_input: return {"recipe": ["番茄2个", "鸡蛋3个"], "steps": ["打蛋", "切番茄"]} elif "红烧肉" in user_input: return {"recipe": ["五花肉500g"], "steps": ["焯水", "炒糖色"]} 用户说"把番茄换成土豆"怎么办?需要再加elif分支 else: return "抱歉,我只会做这两道菜"

这种硬编码实现存在致命缺陷:耦合高、扩展性差、维护困难。每新增一道菜就需要修改代码、增加elif分支,用户稍微换个问法系统就无从应对。

AI做饭场景本质上是非结构化的自然语言输入结构化的执行动作转换的过程。用户说“帮我做个清淡点的”,系统需要理解“清淡”对应的食材和烹饪方式——这是传统后端逻辑根本无法解决的问题-1。于是,Agent智能体架构应运而生:它将大模型作为“大脑”,由模型自主理解意图、规划任务、调用工具执行。

二、核心概念讲解:Agent(智能体)

标准定义

Agent(智能体) 是一种能够自主感知环境、制定决策并执行动作的AI系统,其核心特征是“LLM + 工具 + 循环”。

关键词拆解

一句话理解Agent的本质:“Agent = LLM + 工具 + 循环”-59

其中:

  • LLM(大语言模型) 是Agent的“大脑”,负责理解和规划。你用的ChatGPT、Claude、DeepSeek底层都是大语言模型,它通过学习海量文本数据掌握了人类语言的规律和知识。

  • 工具 是Agent的“手脚”,包括API调用、数据库查询、设备控制等外部能力。

  • 循环 是Agent区别于普通对话系统的关键——它不是一问一答就结束,而是会不断地思考→行动→观察结果→再思考,直到任务完成-59

生活化类比

想象你让一位助理帮你做饭。大模型(LLM)就是这位助理的大脑——它知道番茄炒蛋的菜谱、懂得食材搭配的逻辑。但它只有大脑还不够,它需要手和脚(工具)去实际开火、翻炒,还需要眼睛和耳朵(感知能力)来判断火候是否合适。更重要的是,它需要在做的过程中不断思考:“先打蛋还是先切番茄?番茄放进去之后要翻炒多久?”——这个不断调整的过程就是Agent的“循环”。

三、关联概念讲解:Workflow(工作流)

标准定义

Workflow(工作流) 是一种预先编排好的任务执行流程,按照固定的步骤顺序执行,每个节点完成后自动进入下一个节点,不涉及自主决策。

与Agent的关系

Workflow是实现Agent的一种具体手段。当任务路径明确、不需要灵活决策时,可以用Workflow实现确定性执行;而Agent中的循环推理过程,本质上也是一个由模型动态决策的Workflow。

对比与差异

维度AgentWorkflow
决策方式模型自主决策,动态规划人工预先编排,固定路径
适应能力强,能应对未知场景弱,只能执行已知路径
可控性相对较低,结果有概率性高,每一步结果可预期
适用场景非结构化任务,如烹饪助手结构化流程,如审批流

简单示例说明运行机制

一个Workflow烹饪助手的伪代码:

python
复制
下载
 Workflow:固定流程
def workflow_cooking():
    step1 = recognize_intent()       固定:先识别意图
    step2 = query_recipe_db()        固定:再查菜谱库
    step3 = generate_instructions()  固定:生成步骤
    step4 = call_device()            固定:最后调用设备
    return step4

而Agent的运行机制则是动态的:模型先判断用户意图,再决定要不要查数据库、查完结果是否符合预期、不符合就换条路径——每一步都是“动态决策”而不是“执行固定代码”。

四、概念关系与区别总结

三者关系可以一句话概括:Agent是设计思想(让AI自主行动),Workflow是实现方式(确定性流程),Function Calling是底层能力(让模型能调用外部工具) -56

用做饭场景来理解:Agent相当于“一个会自己思考的厨师”,Workflow相当于“一份菜谱”(步骤固定的流程),而Function Calling则相当于“厨师的手和菜刀”(执行动作的能力)。

核心记忆点:Agent是“目标导向的自主执行”,Workflow是“路径固定的顺序执行”,Function Calling是“让LLM输出可执行指令的技术能力”。

五、代码示例:用LangChain构建一个烹饪助手Agent

下面展示如何使用LangChain(目前最主流的AI智能体编排框架)构建一个带有记忆功能的烹饪助手-25

安装依赖

bash
复制
下载
pip install langchain==1.2.8 langchain-openai==1.1.7

核心代码

python
复制
下载
!/usr/bin/env python
 -- coding: utf-8 --
"""AI烹饪助手Agent"""

from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, SystemMessage

class CookingAgent:
    """烹饪助手Agent"""
    
    def __init__(self, user_id: str):
        self.user_id = user_id
         步骤1:初始化LLM——Agent的“大脑”
        self.llm = ChatOpenAI(model="gpt-4", temperature=0.7)
        self.system_prompt = """
        你是专业的烹饪助手“小厨”。你的任务是:
        1. 根据用户的描述推荐合适的菜品
        2. 提供详细的烹饪步骤
        3. 记住用户的饮食偏好(如不吃辣、海鲜过敏等)
        """
        self.history = []   存储对话历史——Agent的“短期记忆”
    
    def chat(self, message: str) -> str:
        """处理用户消息——Agent的“思考-行动”主循环"""
         步骤2:构建上下文(包含历史对话)
        messages = [
            SystemMessage(content=self.system_prompt),
            self.history[-6:],   最近3轮对话
            HumanMessage(content=message)
        ]
        
         步骤3:调用LLM生成响应——Agent做决策
        response = self.llm.invoke(messages).content
        
         步骤4:更新记忆——Agent记住这次交互
        self.history.extend([
            HumanMessage(content=message),
            SystemMessage(content=response)
        ])
        
        return response

 使用示例
agent = CookingAgent(user_id="user_001")
print(agent.chat("我想做一道清淡的菜"))
print(agent.chat("把番茄换成土豆行吗?"))   Agent记住了上文

执行流程解析

第1步:初始化LLM,相当于给Agent配备了一个“大脑”。第2步:构建包含用户偏好的System Prompt——这是Agent的“规则手册”。第3步:调用LLM生成响应——模型根据规则和用户输入“思考”出答案。第4步:更新历史记录——这是Agent的“短期记忆”,让它在下一轮对话中记得刚才聊过什么。

值得指出的是,这个示例中Agent的“工具”仅限于语言回答;要真正实现“做饭”,还需要引入Function Calling能力来调用设备API,这将在原理部分深入讲解。

六、底层原理:Function Calling的完整链路

Function Calling是实现Agent调用外部工具能力的核心技术。2026年的AI应用开发已经形成“以编排为中心”的通用范式,而Function Calling正是这一范式的基石-44

完整链路(三步走)

第1步:定义工具(JSON Schema)

python
复制
下载
tools = [{
    "type": "function",
    "function": {
        "name": "control_stove",
        "description": "控制灶具的火力",
        "parameters": {
            "type": "object",
            "properties": {
                "action": {"type": "string", "enum": ["on", "off", "adjust"]},
                "power": {"type": "integer", "description": "火力值1-10"}
            },
            "required": ["action"]
        }
    }
}]

开发者通过自然语言向模型描述工具的功能和参数定义,模型在对话过程中自主判断是否需要调用工具-49

第2步:模型返回调用指令

当用户说“开大火烧水”时,模型分析后返回JSON格式的调用指令:

json
复制
下载
{
    "name": "control_stove",
    "arguments": {"action": "adjust", "power": 10}
}

模型不直接执行任何函数,只返回一个结构化JSON对象,由后端代码真正执行-44

第3步:执行并回填结果

后端代码调用实际的灶具API,将执行结果(成功/失败、温度变化等)回传给模型,模型再基于结果生成自然语言回复给用户。

底层依赖的技术栈

Function Calling的底层依赖主要包括:

  • SFT(Supervised Fine-Tuning,监督微调) :通过在大量“用户问题-工具调用”配对数据上进行微调,让模型学会输出规范的工具调用格式-55

  • JSON Schema解析:模型需要理解参数的类型约束(如power必须是整数)并正确生成参数值。

  • 多轮上下文维护:当用户需求需要多次调用工具时,系统需要维护对话历史上下文,逐轮处理工具调用和结果回填-49

七、高频面试题与参考答案

Q1:LLM和Agent有什么区别?

参考答案:LLM(大语言模型)是Agent的“大脑”,本质上是“预测下一个字”的概率模型,只能根据输入生成文本输出。Agent则在LLM基础上增加了三个核心能力:工具使用(通过Function Calling调用外部API)、循环执行(多轮思考-行动-观察)、记忆管理(短期/长期对话记忆)。简单说,LLM只会“说”,Agent还能“做”-59

踩分点:点明LLM是组件、Agent是系统;说明Agent的三大能力增量。

Q2:Function Calling的实现原理是什么?

参考答案:Function Calling让大模型能够输出可执行的函数调用指令,完整链路分三步:① 开发者通过JSON Schema定义可用工具,作为参数传入API请求;② 模型判断需要调用工具时,返回包含函数名和参数的JSON对象,不实际执行;③ 后端代码接收JSON后真正调用对应函数,将结果回填给模型,模型再生成最终回答-44。底层依赖SFT微调让模型学会输出规范格式。

踩分点:讲清“模型只输出指令不执行”的机制;说明JSON Schema定义和SFT训练的作用。

Q3:如何保证大模型返回的数据格式正确?

参考答案:三种方法组合使用:① JSON Schema约束:在System Prompt中定义严格的字段类型和取值范围,模型输出不符合Schema时触发重试;② Prompt约束 + Pydantic校验:在Python中使用Pydantic模型对返回结果进行二次校验,类型不匹配时报错;③ 有限重试机制:解析失败时将错误信息以JSON格式返回给模型,给1-2次重试机会,超限后降级为纯文本回复-58

踩分点:说明约束方法层次(Prompt层 + 代码层);提到降级兜底方案。

Q4:Agent和Workflow在实际项目中如何选择?

参考答案:核心判断标准是任务的结构化程度。如果任务路径明确、步骤固定(如OA审批、定时任务),优先选择Workflow,优势是可预期、易调试、成本低。如果任务需要灵活应对未知情况、依赖模型理解自然语言(如烹饪助手、客服机器人),必须用Agent。实际工程中常常“混合使用”:用Agent做意图识别和规划,再用Workflow执行确定性子任务。

踩分点:明确判断标准;提出混合架构的工程实践。

八、结尾总结

本文围绕“AI助手做饭”这一场景,系统讲解了AI智能体后端架构的三个核心层次:

  • 概念层:Agent是“目标导向的自主执行”设计思想,Workflow是“路径固定的顺序执行”实现方式,Function Calling是实现工具调用的底层技术能力。

  • 代码层:通过LangChain构建烹饪助手Agent,直观展示了“LLM + 循环”的核心模式。

  • 原理层:深入剖析Function Calling的完整链路——定义工具 → 模型返回JSON指令 → 后端执行并回填结果。

  • 考点层:LLM vs Agent、Function Calling原理、格式校验、Agent vs Workflow选择策略,覆盖2026年AI后端面试高频考点。

重点回顾

  • Agent = LLM + 工具 + 循环

  • Workflow是确定性执行路径,Agent是动态规划执行

  • Function Calling的“三步走”链路是Agent能力的关键

易错点提醒:Function Calling是模型输出调用指令,不是模型直接执行函数;Agent的循环机制要求开发者设计好终止条件和异常兜底,否则容易陷入无限循环。


下一篇预告:深入LangGraph多智能体协作架构,讲解如何编排多个Agent协同完成复杂任务,欢迎持续关注。

标签:

相关阅读