一个能聊天的航班助手，和真正能帮你订票的机器人，差距有多大？
Ed Donner在Udemy上的AI工程课程里抛了个问题：大语言模型（LLM）能回答"去巴黎多少钱"，但让它完成"订一张下周三去伦敦的票"，需要跨越什么门槛。我跟着做了一遍，发现核心就藏在三个Python函数里。
数据库：让AI从"知道"变成"做到"
聊天机器人的幻觉问题，根源在于它只有记忆、没有账本。我搭了个SQLite数据库，两张表解决问题：bookings存用户订单，ticket_prices存目的地和价格。初始化时塞了纽约、巴黎、伦敦等城市的票价数据，AI第一次查询就有东西可抓。
代码层面没什么花哨——就是sqlite3.connect()和execute()的标准操作。但这一步把AI从"嘴炮选手"变成了能写账本的出纳。
run_query()这个辅助函数被复用到所有工具里，参数化查询防注入，返回结果直接喂给模型。数据库轻到只有一个文件，部署时跟着代码走就行。
工具定义：教会AI"什么时候该动手"
LLM工具调用的精髓，在于让模型自己判断"我现在该查价格还是该下单"。我定义了四个工具函数，用结构化描述暴露给OpenAI的接口：
get_ticket_price(location) 查票价，返回格式化字符串；list_destinations() 拉取所有可选城市；create_booking(name, destination, date) 写订单进数据库；还有隐含的参数收集逻辑——模型会主动追问缺什么信息。
工具描述里的docstring就是 prompt 工程的一部分。写清楚每个参数要什么格式，模型犯错的概率直接砍半。
create_booking里加了日期解析：datetime.strptime(date, "%Y-%m-%d").date()，用户说"下周五"模型会先转成标准日期，再执行SQL插入。这个细节没写在课程里，是我踩坑后加的——AI对模糊时间的理解，比想象中脆弱。
对话流：AI怎么学会"追问"
完整订一张票，模型需要收集姓名、目的地、日期三个字段。但用户很少一次性给全。测试时我说"订去巴黎的票"，AI回"请问您的姓名和出发日期是？"——这不是写死的逻辑，是工具描述里required字段驱动的行为。
背后的机制是OpenAI的function calling：模型每轮判断要不要调工具，调完把结果塞回对话历史，继续生成回复。我打印过中间状态，发现模型有时会"自言自语"——先生成一个工具调用JSON，等执行结果回来，再组织成人话。
这个"先想后说"的过程，让AI有了行动前的规划感。比起端到端生成，工具调用把复杂任务拆成了可验证的步骤。
项目跑通后，我试了条边界 case："订一张去火星的票"。模型查完数据库返回"Price not available for Mars"，没有幻觉编造价格，也没有强行下单。这种"知之为知之"的克制，恰恰是工具架构带来的——数据库里没有的，AI不会脑补。
整个项目代码不到200行，依赖只有openai和sqlite3。但把LLM从"问答模式"切换到"代理模式"，需要的不是更多参数，而是清晰的工具边界和可靠的数据层。
你现在用的大模型产品，有多少还停留在"我知道答案"的阶段，又有多少已经能"帮你把事情办了"？
热门跟贴