90分钟手写电商AI Agent：数据库工具调用实战

从生成内容到执行操作：AI Agent 到底强在哪

生成式AI（GenAI）已经能写文案、出图、生成代码，但它本质上只做一件事——输出内容。你问「我的订单在哪」，聊天机器人可以礼貌作答，却无法真的去数据库里查。真正让AI从「会说」变成「会做」的，是智能体AI（Agentic AI）。

据B站UP主在90分钟实战课程中的演示，AI Agent与普通聊天机器人的核心差异在于：Agent会思考并规划行动，把目标拆解成可执行步骤，并通过「工具」去连接数据库、API、向量库等外部系统，完成查询、更新等真实操作，再基于执行结果生成自然语言回复。

这期课程用一个电商客服Agent贯穿始终：前端用Streamlit搭界面，后端用Python + LangChain，模型绑定OpenAI GPT，数据库用MySQL的orders表。用户输入订单ID，Agent能查到状态；用户要求取消订单，Agent会先判断状态是否允许取消，再决定执行还是拒绝。

基于这个问题

工具调用：Agent 执行操作的核心机制

工具就是函数，文档字符串就是说明书

课程中最关键的概念是工具调用（Tool Calling）。工具本质上就是一个普通函数，负责执行特定动作。在电商案例里，开发者写了两个函数：get_order_status(order_id) 和 cancel_order(order_id)。通过 LangChain 的 @tool 装饰器，这两个函数被暴露成工具并绑定到大语言模型上。

说个细节，LM 本身并不执行工具。它的职责只有工具选择：根据用户问题和工具的文档字符串（docstring），判断该调用哪个工具、传什么参数。真正的函数执行、数据库读写，全部由开发者的应用代码完成。

UP主在演示中特意删掉了工具的文档字符串，结果应用直接启动失败并报错提示「函数必须有文档字符串」。这印证了一个容易被忽视的细节：文档字符串不是注释，而是LM做工具路由的唯一依据。函数名可以随意，描述必须准确。

你设置数据库

Function Calling（函数调用） 是 OpenAI 在 2023 年 6 月为 GPT-3.5/GPT-4 引入的能力，允许模型在对话中输出结构化的 JSON 来请求调用开发者预定义的外部函数，而不是直接生成文本。LangChain 的 @tool 装饰器本质上是对这一底层协议的封装：它把 Python 函数的名称、参数类型和 docstring 转成 JSON Schema，随请求一起发给模型。模型返回的并非函数调用本身，而是一个 tool_calls 字段，其中包含函数名与参数，由应用代码解析后自行执行。因此「工具调用」的准确说法是「工具选择 + 应用执行」，模型侧始终处于建议者角色。这一机制也让模型输出具备可校验的结构，降低了解析自由文本的脆弱性。

两次LM调用：Agent 的工作流骨架

普通GenAI应用只和LM通信一次，而Agent应用通常要通信两次。课程给出的标准流程是：

步骤0：创建工具并绑定到LM客户端对象；
用户提出问题，问题被发送给已绑定工具的LM；
LM返回工具选择结果（工具名 + 参数）；
应用执行对应工具，工具访问MySQL并返回结果；
将原始问题与工具结果一起再次发给LM，由LM生成最终回复。

这个「选择—执行—再生成」的闭环，就是Agent能落地业务的关键。第一次调用解决「做什么」，第二次调用解决「怎么说」。

ReAct（Reasoning + Acting） 是理解上述两次调用闭环的理论背景。该范式由 Shunyu Yao 等人于 2022 年提出，核心是让语言模型交替进行「推理」和「行动」：先思考当前状态需要什么信息，再选择一个动作（如调用工具），观察返回结果，然后继续推理。课程中的流程正是 ReAct 的一个最简实现——第一次 LM 调用对应 Thought/Action，工具执行对应 Observation，第二次 LM 调用对应基于观察生成最终答案。LangChain 的 AgentExecutor 在更复杂的场景下会把这一循环重复多轮，直到模型判断无需再调用工具为止。理解 ReAct 有助于开发者预判 Agent 在多工具、多步骤任务中的行为路径与失败模式。

业务逻辑要写进代码，而不是指望模型

电商Agent演示中最能体现工程思维的一幕，是取消订单的防护逻辑。开发者没有让LM去判断「已送达的订单能不能取消」，而是在cancel_order函数内部先查询当前状态：如果状态是「已送达」，直接返回「订单无法取消，因为已经送达」；如果已经是「已取消」，则提示无需重复操作；只有状态允许时才执行UPDATE。

那么我们可以去取消订单

结果就是：订单1001状态为「已发货」，Agent成功取消；订单1002状态为「已送达」，Agent回复「您的订单已送达，无法取消」。数据库里只有「已送达」三个字，但最终回复是LM结合工具返回结果生成的完整句子。业务规则由代码保证，表达由模型完成，两者边界清晰。

这种设计也解释了为什么工具调用对Agent如此重要：LM无法直接访问你的私有数据库、公司文档、支付API或邮件系统。工具就是给模型开的一扇受控窗口，数据不出应用，权限留在代码里。

我们将通过传递问题来调用这个函数

权限与信任边界是 Agent 工程中常被低估的一环。工具调用把模型与真实系统连接起来，但也意味着模型的一次误判可能触发写操作（如 UPDATE、退款、发邮件）。业界通行的做法是遵循最小权限原则：为 Agent 使用的数据库账号只授予必要的表和操作权限，写操作工具在函数内部做二次校验，敏感动作可要求人工确认或写入审计日志。课程中把状态校验锁进 cancel_order 函数，本质上是把「模型不可信」作为设计前提。这一思路与传统的输入校验一致——不依赖调用方（此处是 LM）自觉，而是在系统边界处强制约束，从而把 Agent 的风险控制在可预期范围内。

实操路径与踩坑记录

课程的项目搭建分为六步：建库建表并插入三条示例订单、创建项目与虚拟环境、配置.env中的OpenAI密钥、编写数据库服务、实现带工具调用的Agent、最后用Streamlit做UI。依赖包括openai、langchain、streamlit、mysql-connector-python和python-dotenv。

演示中也暴露了真实的兼容性问题：开发者最初使用response_api=true参数时遇到「意外关键字参数」报错，换用GPT-3.5时又提示不支持该函数工具调用，最终切换到GPT-4o才跑通。这说明工具调用能力与具体模型版本强相关，选型时需要先确认模型是否支持function calling。

另一个值得借鉴的做法是：Agent核心逻辑写完后，直接把代码交给ChatGPT生成Streamlit界面，前端逻辑一行不用手写。对于没有前端经验的开发者，这是快速验证Agent效果的低成本路径。

编辑观点：Agent 的门槛不在模型，在工程约束

这期课程的价值不在于教会一个电商查询demo，而在于揭示了Agent开发的真实分工：模型负责理解和选择，开发者负责定义工具、编写业务规则、执行操作。工具描述写得好不好，直接决定路由准不准；业务校验放在哪一层，直接决定Agent会不会闯祸。

对想上手Agent的开发者来说，建议从「一个动作一个工具」开始，先把文档字符串写清楚，再把状态校验、权限判断这类硬逻辑锁死在函数内部。模型会越来越强，但「哪些事能做、哪些事不能做」的边界，始终应该掌握在代码手里。