快时尚电商智能体设计思路与应用实践（一）借助超长上下文窗口分钟级构建智能客服系统 TaoToken

1. 快时尚电商客服为什么必须分钟级上线

快时尚电商的节奏有多快，做过这行的人都懂：一周上新两批，促销活动按小时改价，退货政策随季节调整。客服团队每天面对的是"这件衣服什么时候到""能不能改地址""收到的和图片不一样"这类高频问题，而这些问题背后的答案——订单状态、物流节点、退换货规则——几乎每天都在变。

传统做法是训练一个意图分类模型，再配一套知识库检索。问题是：政策一改，模型要重训；上新一季，知识库要重建。等这套流程走完，爆款已经过季了。

我试过用超长上下文窗口的思路来解这个问题：把几百 KB 的 SOP 文档、订单数据、物流决策树一次性塞进模型的上下文，让模型在完整信息下做推理，而不是靠分片检索拼凑答案。这样做的好处是——政策更新时，你只需要替换那段文本，不需要重训任何东西。

这篇文章要交付的，就是一套可运行的快时尚电商智能客服系统。核心是用 Amazon Bedrock 上的大模型做两层意图识别与应答，配合超长上下文窗口承载完整 SOP。你可以跟着步骤直接跑起来，也可以把配置模板搬到自己的项目里。

适合谁看：想快速落地客服智能体的后端工程师、做电商中台的技术负责人、以及想理解"超长上下文窗口到底怎么用"的开发者。读完你能拿到：一份可复制的智能体配置、一套两层模型的调用代码、以及意图识别和多轮对话的验证方法。

2. TaoToken 接入前置：把模型调用通道准备好

在动手写客服系统之前，先把模型调用通道打通。这里我用 TaoToken 作为统一的模型接入层，它的好处是兼容 OpenAI 风格的接口，同时能对接多个模型供应商，切换模型只需要改一个 Model ID。

2.1 为什么需要这一层

Amazon Bedrock 本身提供了converseAPI，可以直接调用 Nova、Claude 等模型。但在实际项目里，你往往需要：

• 在不同模型之间做 A/B 对比（比如 Nova Premier 和 DeepSeek-R1 的客服风格差异）
• 统一管理 API Key，避免每个模型一套凭证
• 在本地开发和云端部署之间无缝切换

TaoToken 的 API 地址是https://taotoken.net/api，兼容 OpenAI 的/v1/chat/completions格式。你可以在官网https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=注册后拿到 Key。

2.2 拿到 API Key 并配置环境变量

登录后进入控制台，在 API Keys 页面创建一个新 Key。建议按项目命名，比如fashion-cs-dev，方便后续排查。

拿到 Key 之后，不要硬编码在代码里。用环境变量管理：

export TAOTOKEN_API_KEY="sk-你的实际key" export TAOTOKEN_BASE_URL="https://taotoken.net/api"

如果你用 Python，可以在项目根目录建一个.env文件：

TAOTOKEN_API_KEY=sk-你的实际key TAOTOKEN_BASE_URL=https://taotoken.net/api

然后在代码里用python-dotenv加载。这样做的好处是，部署到服务器时只需要改环境变量，不用动代码。

2.3 确认可用模型列表

TaoToken 支持多个模型，客服场景常用的有：

你可以先用nova-lite做意图识别，用nova-premier做应答生成。这样分工的好处是：意图识别只需要输出一个关键词，用轻量模型就够；应答生成需要理解完整 SOP，用大窗口模型更稳。

2.4 验证通道是否通畅

在写完整系统之前，先用一段最小代码确认通道可用：

import os from openai import OpenAI client = OpenAI( api_key=os.getenv("TAOTOKEN_API_KEY"), base_url=os.getenv("TAOTOKEN_BASE_URL") ) response = client.chat.completions.create( model="us.amazon.nova-lite-v1:0", messages=[ {"role": "user", "content": "只回复一个词：ORDER 或 LOGISTICS。客户问：我的订单123到哪了？"} ] ) print(response.choices[0].message.content)

如果输出ORDER，说明通道正常。如果报 401，检查 Key 是否正确；如果报 model not found，检查 Model ID 拼写。

这一步看起来简单，但很多后续问题都出在通道没打通。先把这步跑通，再往下走。

3. 可复制的智能体配置：两层模型 + 超长上下文

这一节是核心。我会给出完整的配置模板，包括模型参数、SOP 注入方式、以及两层模型的调用结构。你可以直接复制到自己的项目里。

3.1 整体架构：两层模型分工

客服系统的流程是这样的：

第一层：意图识别。客户提问后，先用轻量模型判断这是"订单问题"还是"物流问题"。输出只有一个关键词，不需要完整句子。

第二层：专业应答。根据意图，把对应的决策树和 SOP 注入到提示词里，用大窗口模型生成回复。订单问题走订单决策树，物流问题走物流决策树。

这样做的好处是：意图识别快且便宜，应答生成准且稳。两层之间通过 conversation_id 共享对话历史，保证多轮对话的连贯性。

3.2 配置文件：settings.json

在项目根目录建一个config/settings.json，把模型参数和路径集中管理：

{ "taotoken": { "base_url": "https://taotoken.net/api", "api_key_env": "TAOTOKEN_API_KEY" }, "models": { "intent": "us.amazon.nova-lite-v1:0", "order_agent": "us.amazon.nova-premier-v1:0", "logistics_agent": "us.amazon.nova-premier-v1:0" }, "context": { "max_sop_tokens": 800000, "conversation_history_limit": 20, "order_data_file": "data/order_data.txt" }, "prompts": { "intent_template": "prompts/intent.txt", "order_template": "prompts/order.txt", "logistics_template": "prompts/logistics.txt" } }

这个配置的关键点是max_sop_tokens。快时尚电商的 SOP 通常在几百 KB，换算成 token 大约 200K 到 500K。设成 800K 是留足余量，确保完整决策树能一次性注入。

3.3 SOP 注入：把决策树写进提示词

在prompts/目录下建三个文件。先看意图识别的intent.txt：

你是快时尚电商客服的意图识别模块。 分析客户问题，判断属于以下哪一类： 1. ORDER - 订单状态、修改、支付、取消 2. LOGISTICS - 物流地址、配送方式、包裹问题 只回复一个关键词：ORDER 或 LOGISTICS。 不要回复完整句子。 客户问题：{user_question}

再看订单决策树的order.txt：

你是快时尚电商的订单客服专员。 以下是订单问题处理决策树： # 订单问题决策树 1. 订单状态查询 1.1 客户问"我的订单到哪了" -> 用订单ID查询状态 2. 订单修改 2.1 能否修改/删除订单 -> 检查订单是否还在处理中 2.2 想加商品 -> 检查订单是否还在处理中 3. 地址修改 3.1 订单未发货 -> 直接更新地址 3.2 订单已发货 -> 告知无法修改，建议联系物流 当前订单信息： {order_info} 对话历史： {history} 客户问题：{user_question} 请严格按决策树回复。不确定时先向客户确认细节。 这是即时通讯场景，回复尽量简短。不要用"此致敬礼"。

物流决策树类似，把订单相关的分支换成物流分支。这里的关键是：决策树全文注入，不做分片检索。这样模型能看到完整的条件分支，不会因为检索丢失关键逻辑。

3.4 两层调用代码

核心代码结构如下。先加载配置和 SOP：

import json import os from openai import OpenAI with open("config/settings.json") as f: config = json.load(f) client = OpenAI( api_key=os.getenv(config["taotoken"]["api_key_env"]), base_url=config["taotoken"]["base_url"] ) def load_prompt(path): with open(path) as f: return f.read() INTENT_TEMPLATE = load_prompt(config["prompts"]["intent_template"]) ORDER_TEMPLATE = load_prompt(config["prompts"]["order_template"]) LOGISTICS_TEMPLATE = load_prompt(config["prompts"]["logistics_template"])

意图识别函数：

def recognize_intent(user_question): prompt = INTENT_TEMPLATE.format(user_question=user_question) response = client.chat.completions.create( model=config["models"]["intent"], messages=[{"role": "user", "content": prompt}], temperature=0 ) text = response.choices[0].message.content.strip().upper() if "ORDER" in text: return "ORDER" elif "LOGISTICS" in text: return "LOGISTICS" return "UNKNOWN"

应答生成函数：

def generate_response(intent, user_question, order_info, history): if intent == "ORDER": template = ORDER_TEMPLATE model = config["models"]["order_agent"] else: template = LOGISTICS_TEMPLATE model = config["models"]["logistics_agent"] prompt = template.format( order_info=order_info, history=history, user_question=user_question ) response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=0.3 ) return response.choices[0].message.content

注意temperature的设置：意图识别用 0，保证输出稳定；应答生成用 0.3，让回复稍微自然一点，但不会太发散。

3.5 订单数据管理

订单数据存在data/order_data.txt，格式用 JSON：

[ {"order_id": "123", "customer_name": "Alice", "items": ["T恤", "牛仔裤"], "address": "北京西城区", "status": "Processing"}, {"order_id": "456", "customer_name": "Bob", "items": ["连衣裙", "鞋子"], "address": "北京海淀区", "status": "Shipped"}, {"order_id": "789", "customer_name": "Charlie", "items": ["夹克", "帽子"], "address": "北京东城区", "status": "Delivered"} ]

地址修改的逻辑：先查订单状态，如果是 Processing，直接更新；如果是 Shipped 或 Delivered，告知客户无法修改。这个判断在代码里做，不交给模型，避免模型误判。

4. 验证请求：意图识别与多轮对话实测

配置写完了，现在跑起来验证。这一节给出完整的测试流程和预期结果。

4.1 启动交互式会话

写一个简单的命令行入口：

def interactive_session(): conversation_id = None history = [] print("快时尚电商客服已启动，输入 exit 退出") while True: user_input = input("\n客户：") if user_input.lower() == "exit": break intent = recognize_intent(user_input) print(f"[意图识别] {intent}") order_info = get_order_info(user_input) response = generate_response(intent, user_input, order_info, "\n".join(history)) print(f"客服：{response}") history.append(f"客户：{user_input}") history.append(f"客服：{response}")

运行后，你会看到意图识别的结果和客服回复。

4.2 测试用例一：订单状态查询

输入：我的订单123现在什么状态？

预期输出：

[意图识别] ORDER 客服：您的订单123目前正在处理中，包含T恤和牛仔裤，配送地址是北京西城区。

这里验证的是：意图识别正确分类为 ORDER，应答模型从订单数据里提取了正确信息。

4.3 测试用例二：地址修改

输入：能把订单123的地址改成北京朝阳区吗？

预期输出：

[意图识别] LOGISTICS 客服：您的订单123还在处理中，可以修改地址。已为您更新为北京朝阳区。

验证点：地址修改走的是 LOGISTICS 意图，代码里检查了订单状态为 Processing，然后执行更新。

4.4 测试用例三：多轮对话

第一轮：订单456显示已送达，但我没收到

预期：[意图识别] LOGISTICS，客服询问是整包丢失还是部分商品缺失。

第二轮：整包都没收到

预期：客服确认地址是否正确。

第三轮：地址是对的

预期：客服根据决策树提供补发或退款选项。

这个测试验证的是多轮对话的连贯性。每一轮的 history 都会累积，模型能看到之前的对话内容，不会重复询问已经确认的信息。

4.5 测试用例四：边界情况

输入：你好

预期：[意图识别] UNKNOWN，客服回复"请问您是想咨询订单问题还是物流问题？"

这个测试验证的是：当意图不明确时，系统不会强行分类，而是引导客户补充信息。

5. 常见报错排查：401、model not found、上下文超限

实际部署时，你大概率会遇到这几个报错。我按出现频率排序，给出排查路径。

5.1 401 Unauthorized

报错信息：

openai.AuthenticationError: Error code: 401 - {'error': {'message': 'Invalid API key'}}

原因：API Key 没设置、设置错了、或者环境变量没加载。

排查步骤：

第一，确认环境变量存在：

echo $TAOTOKEN_API_KEY

如果输出为空，说明没设置。检查.env文件是否被加载，或者直接在终端 export。

第二，确认 Key 没有多余空格。从控制台复制时容易带上换行符。用len()检查一下长度是否合理。

第三，确认 base_url 正确。TaoToken 的地址是https://taotoken.net/api，不要漏掉/api，也不要多加/v1（OpenAI SDK 会自动加）。

5.2 model not found

报错信息：

openai.NotFoundError: Error code: 404 - {'error': {'message': 'Model not found'}}

原因：Model ID 拼写错误，或者该模型在你的账户下不可用。

排查步骤：

第一，对照可用模型列表检查拼写。注意us.amazon.nova-lite-v1:0里的us.前缀和:0后缀都不能少。

第二，确认模型区域。有些模型只在特定区域可用，比如us.前缀表示美国区域。

第三，如果用的是 Bedrock 原生 SDK，确认boto3.client('bedrock-runtime', region_name='us-west-2')里的 region 和 Model ID 前缀一致。

5.3 上下文超限

报错信息：

This model's maximum context length is 300000 tokens, however you requested 350000 tokens

原因：SOP 文档太大，加上对话历史，超过了模型的上下文窗口。

排查步骤：

第一，检查 SOP 的实际 token 数。用 tiktoken 估算：

import tiktoken enc = tiktoken.get_encoding("cl100k_base") with open("prompts/order.txt") as f: tokens = len(enc.encode(f.read())) print(f"SOP tokens: {tokens}")

第二，如果超过模型窗口，有两个选择：换更大窗口的模型（比如从 nova-lite 的 300K 换到 nova-premier 的 1M），或者对 SOP 做压缩——把不常用的分支折叠成摘要。

第三，限制对话历史长度。在配置里设conversation_history_limit，超过就丢弃最早的几轮。

5.4 回复不符合决策树

现象：模型没有按决策树的分支回复，而是自由发挥。

原因：提示词里的指令不够强，或者 temperature 太高。

排查步骤：

第一，在提示词里加粗指令：请严格按决策树回复，不要自行发挥。

第二，把 temperature 降到 0.1 或 0。

第三，检查决策树是否完整注入。如果 SOP 被截断，模型看不到完整分支，就会猜。

5.5 多轮对话丢失上下文

现象：第二轮对话时，模型忘记了第一轮说的内容。

原因：history 没有正确传递，或者 conversation_id 没有复用。

排查步骤：

第一，确认每一轮都把之前的对话追加到 history 里。

第二，确认 conversation_id 在同一个会话里保持不变。如果每次调用都生成新 ID，历史就断了。

第三，检查 history 的格式。推荐用客户：xxx\n客服：xxx的纯文本格式，模型更容易理解。

6. 从验证到生产：把客服智能体接入你的系统

跑通上面的流程后，你已经有了一个可运行的客服智能体。接下来要考虑的是怎么接入生产环境。

6.1 接入方式选择

如果你只是想快速验证模型效果，用模型对话页面直接测试就行，不需要写代码。

如果你要做长期编码和 Agent 开发，建议用 Coding Plan，它提供了更稳定的调用配额和更高的并发限制。

如果你要把客服系统接入现有的电商后台，用 API Keys 配合接入文档，把上面的代码封装成 HTTP 服务即可。

6.2 生产环境的三个注意事项

第一，SOP 更新要热加载。不要把 SOP 硬编码在代码里，而是放在外部文件或配置中心。政策变更时，替换文件即可，不需要重启服务。

第二，加一层敏感词过滤。模型回复生成后，过一遍敏感词库，避免出现不当表述。这一步在代码里做，不依赖模型自身的安全机制。

第三，记录完整的对话日志。每一轮的意图识别结果、模型回复、耗时都要落库。这些数据是后续优化决策树的依据。

6.3 下一步优化方向

当前方案用的是两层模型 + 超长上下文。如果你想进一步提升，可以考虑：

引入 Prompt Caching，把不常变的 SOP 部分缓存起来，降低重复计算的成本。

用 LangGraph 编排更复杂的多智能体流程，比如订单查询、物流跟踪、退款处理各用一个专门的 Agent。

接入 MCP 协议，让智能体能直接调用你的订单系统和物流接口，而不是靠文本注入数据。

这些方向在后续文章里会展开。当前这套方案的价值在于：它足够简单，能在分钟级跑起来，而且核心逻辑（超长上下文承载 SOP）是可复用的。你可以先把它跑通，再根据业务需求逐步迭代。