从 LLM 到购物车Portugal这条链路表面上看是跨领域的两个词组合本质上却是一个最小可运行的 LLM Agent 工具调用闭环。用户用葡萄牙语说出购物意图LLM 把意图翻译成结构化的购物车操作后端执行操作并返回结果模型再根据结果回复用户。下面以这个场景为例从零跑通一个可交互的购物车 Agent并重点解释工具 schema、状态维护、数字格式和生产环境差异。这篇文章适合已经有 Python 基础并且接触过 LLM API 调用的开发者。读完以后你可以复现一个能处理Adiciona 2 garrafas de vinho do Porto这类葡萄牙语指令的购物车助手也能把同一套思路迁移到订单、库存、预约等其他业务系统。在实际项目中购物车看似简单但它能把 LLM 应用里最容易出问题的几个点全部暴露出来工具定义是否准确、上下文是否完整、数值格式是否可靠、业务状态是否可验证。在动手之前先把链路中的每个环节拆开看清楚用户输入、模型上下文、工具调用、业务执行、结果回写、最终回复。任何一环出错都会让整条链路表现得很“笨”。1. 先拆解“从 LLM 到购物车”这条链路1.1 为什么购物车是一个适合入门 LLM Agent 的场景购物车状态简单只有商品、数量、单价和总价。操作边界清晰无外乎加商品、删商品、改数量、查看购物车。验证也容易执行工具后可以直接看到购物车 JSON 是否变化。相比聊天机器人只是“说”结果购物车 Agent 必须真正改变业务状态这就逼着开发者把 LLM 从文本生成器变成业务系统的操作入口。很多刚接触 LLM 的人会把模型输出直接当成业务结果。比如用户说“我要两瓶水”就让 LLM 直接返回一段自然语言描述然后后端去解析这段文本。这种做法在简单 demo 里能跑但一旦说法变得复杂比如“两瓶水和三盒牛奶哦水只要一瓶”自然语言解析就会失控。正确做法是让 LLM 输出结构化工具调用参数由后端代码执行业务操作最后再让模型根据执行结果生成回复。购物车场景正好把这种模式压缩到了很小一个工具函数就是一次状态变更一个tool_calls数组就是一次业务操作序列。把这条链路打通后面的订单、支付、库存都只是增加更多工具函数的问题。1.2 一次完整请求包含哪几个环节一次典型的购物车请求从用户输入开始经过四个环节用户把自然语言消息发送给 LLM。LLM 根据工具定义判断是否需要调用工具如果不调用就直接生成回复如果需要调用则在返回体中附带tool_calls。后端接收tool_calls逐个执行真实购物车函数并把执行结果以tool角色消息回传给 LLM。LLM 拿到执行结果后生成面向用户的最终回复例如“已把 2 瓶波特酒加入购物车当前总价为 19.00 欧元”。这个循环非常像函数式编程里的映射模型负责把自然语言映射成参数业务代码负责执行模型再看结果做收尾。关键设计决策是业务规则不要放在提示词里而要放在工具函数里。比如“数量不能为负数”“总价必须使用 Decimal 计算”这些规则如果只是写在 system prompt 里模型不一定会遵守但如果写在工具函数的参数校验里无论如何都会被执行。1.3 为什么选葡萄牙语场景作为例子项目标题里的 Portugal 不是装饰它能带出三个非常实际的问题。第一是语言理解。葡萄牙语动词变位和介词组合会让模型承担更多解析压力例如Adiciona 2 garrafas de vinho do Porto和Quero remover o queijo都需要映射到不同工具调用。第二是数字格式。葡萄牙语环境经常使用逗号作为小数分隔符例如1,5 kg表示 1.5 千克。这会给从长文本提取数量带来额外挑战。第三是货币和商品目录。葡萄牙使用欧元购物车金额必须用 EUR 表示商品名称应该能和本地 SKU 对应上。用葡萄牙语场景跑通以后换成西班牙语、法语、德语只是替换商品目录和语言描述的问题核心链路不需要改动。2. 设计购物车工具协议先于写代码2.1 明确工具清单和数据结构在设计工具之前先确定购物车需要哪些操作。一个最小购物车 Agent 至少需要四个操作工具名作用主要参数add_item向购物车添加商品sku、name、quantity、unit_priceremove_item删除购物车中的商品skuupdate_quantity更新商品数量sku、quantitylist_cart返回当前购物车完整状态无实际项目中还可以增加get_item_availability、apply_coupon、checkout等但最小案例只需要上面四个。工具越少