企业官网建设流程全解析

从 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 一次完整请求包含哪几个环节

一次典型的购物车请求从用户输入开始，经过四个环节：

1. 用户把自然语言消息发送给 LLM。
2. LLM 根据工具定义判断是否需要调用工具，如果不调用就直接生成回复，如果需要调用则在返回体中附带tool_calls。
3. 后端接收tool_calls，逐个执行真实购物车函数，并把执行结果以tool角色消息回传给 LLM。
4. 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 至少需要四个操作：

实际项目中还可以增加get_item_availability、apply_coupon、checkout等，但最小案例只需要上面四个。工具越少