工厂型企业和贸易型企业在做询盘 Agent 时，面临的其实是两个不同的问题。
工厂通常只做一两个品类，问题集中在技术参数与选型，Agent 的挑战是"答得深"；而广州大量外贸公司的情形正好相反——SKU 横跨消费电子、家居、五金多个品类，问题类型极其分散，Agent 的挑战是"分得对"。
本文讲后者：当一个入口要承接 N 个品类的问询时，路由层应该怎么设计。
一、为什么"一个大模型答所有"会失效****
直觉做法是把所有产品知识塞进一个知识库，让模型自己去检索。在小规模时这能跑，但品类一多就会出现三个典型故障：
1. 检索串味。 采购商问 A 品类的 MOQ，检索结果里混进 B 品类的参数，模型拼出一个似是而非的答案。
2. 意图误判。 同一句 "Do you have stock?" 在不同品类下的处理完全不同——Standard 品是库存查询，定制品是产能排期问题。
3. 无法评估。 所有问题走同一条链路，出错了定位不到是哪个品类、哪个环节的问题。
结论：品类一多，就必须显式引入路由层，而不是指望模型隐式处理。
二、路由优先的四层架构****
| 层 | 职责 | 关键设计 |
|---|---|---|
| 接入层 | 官网表单、邮件、社媒统一入口 | 多渠道路由、会话去重 |
| 路由层 | 判定品类 + 意图 | 二维分类、置信度阈值 |
| 应答层 | 按分片检索并生成 | 分片知识库、术语约束 |
| 升级层 | 转人工与线索分级 | 强制转人工规则 |
路由层是整个架构的核心。它不直接回答用户，但决定了后面所有环节的准确性。
三、二维意图：品类 × 意图****
单一维度的意图分类在单品类场景够用，多品类场景必须拆成二维：
INTENT_SCHEMA = {
"category": "electronics|home|hardware|other", # 品类维度
"intent": "price|spec|sample|cert|oem|logistics|spam", # 意图维度
"entities": {
"quantity": "int|null",
"target_market": "str|null",
"spec_requirement": "str|null",
"urgency": "high|normal|low"
},
"confidence": "float"
}
为什么要显式识别品类？因为后续的知识库检索要按品类分片。先确定品类，再去对应的分片里检索，串味问题就从根上被隔离了。
意图维度的标签建议按外贸场景固定下来，不要开放生成：
| 意图 | 典型表述 | 处理策略 |
|---|---|---|
| price | "price for 500 pcs" | 报价区间 + 引导规格确认 |
| spec | "does it support 380V" | 品类分片精确检索 |
| sample | "can I get a sample" | 走样品流程 |
| cert | "CE certificate available?" | 返回认证文件 |
| oem | "need our logo on it" | 转人工 |
| logistics | "shipping cost to Hamburg" | 物流话术 + 引导信息补全 |
| spam | 群发推广 | 过滤 |
四、知识库分片与检索路由****
按品类分片是核心动作。工程上可以用 metadata 过滤实现，不需要建多个物理索引：
def route_and_retrieve(query_vec, category: str, intent: str, kb, top_k=4):
"""先按品类过滤，再在该分片内做语义检索"""
flt = {"category": category}
if intent == "spec":
# 参数类问题优先命中结构化字段完整的单元
flt["has_structured"] = True
hits = kb.search(query_vec, filter=flt, top_k=top_k)
if not hits:
# 分片内无结果 -> 不降级到全库，直接转人工，避免串味
return None
return hits
一个关键设计决策：分片内检索不到时，不要降级到全库检索。
很多团队会在召回为空时放开过滤条件，让模型"尽量答一点"。在多品类场景下这非常危险——它会显著增加跨品类串味的概率。宁可转人工，也不要拿相邻品类的信息拼答案。
五、多语应答：术语一致性优先****
外贸询盘的语言分布很散，英语之外还常见西语、阿语、俄语。常见错误做法是"英文生成 + 机翻"，问题在于外贸术语有固定行业用法，机翻经常译错，而采购商对术语错误极其敏感。
推荐做法是按语种生成 + 术语表硬约束：
GLOSSARY = {
"en": {"MOQ": "MOQ", "lead_time": "lead time", "FOB": "FOB"},
"es": {"MOQ": "pedido mínimo", "lead_time": "plazo de entrega", "FOB": "FOB"},
"ar": {"MOQ": "الحد الأدنى للطلب", "lead_time": "مدة التسليم", "FOB": "فوب"},
}
def build_prompt(hits, lang: str, intent: str) -> str:
terms = GLOSSARY.get(lang, GLOSSARY["en"])
return (
f"用 {lang} 回复采购问询。\n"
f"硬约束：\n"
f"1) 只能使用下方知识片段中的事实，不得补充或推测；\n"
f"2) 术语必须严格采用：{terms}；\n"
f"3) 片段不足以回答时，只输出 NEED_HUMAN，不要编造。\n\n"
f"意图：{intent}\n知识片段：{hits}"
)
第 3 条是幻觉防线。让模型有权利说"我不知道"，比逼它回答重要得多。
六、线索分级与人工边界****
不是所有询盘都值得立刻跟进。用"规则 + 信号"做加权：
def score_lead(parsed: dict, contact: dict) -> int:
s = 0
ent = parsed.get("entities", {})
q = ent.get("quantity")
if q and q >= 500: s += 30
elif q and q >= 100: s += 15
if ent.get("target_market"): s += 10
if ent.get("urgency") == "high": s += 15
if parsed.get("intent") == "oem": s += 20
domain = contact.get("email", "").split("@")[-1]
if domain and domain not in GENERIC_MAIL_DOMAINS: s += 20
return s
同时，以下情况必须强制转人工，不允许模型自行发挥：
· 价格谈判与折扣请求；
· 定制 / OEM 需求；
· 投诉与售后纠纷；
· 分片内无命中（检索返回 None）；
· 模型自身输出 NEED_HUMAN；
· 品类置信度低于阈值（说明可能分错了品类）。
"置信度低就转人工"这一条最容易漏，但它恰恰是路由架构的价值所在——分错品类比答错一个参数更严重，因为整个回答方向都会偏。
七、评估：怎么判断路由对不对****
多品类 Agent 的评估不能只看"回答满意度"，要单独看路由质量：
| 指标 | 计算方式 | 关注点 |
|---|---|---|
| 品类准确率 | 路由正确的样本 / 总样本 | 路由层核心指标 |
| 意图准确率 | 意图标签正确率 | 影响下游处理策略 |
| 分片命中率 | 分片内有检索结果的占比 | 过低说明知识覆盖不足 |
| 转人工率 | 转人工样本占比 | 过高说明知识不足，过低可能过度自信 |
| 串味率 | 答案中出现非目标品类事实的比例 | 多品类场景特有，应接近 0 |
建议每周抽样人工复核一次路由结果，把错例加进分类体系的迭代。分类体系的演进依赖真实错例，不靠凭空设计。
八、三个工程要点****
1. 路由先行于生成。 先花力气把品类和意图判准，生成环节的压力会小很多。
2. 日志要记全。 品类判定、置信度、命中分片、转人工原因，这些日志是迭代的唯一可靠输入。
3. 知识分片要随业务调整。 品类结构变了，分片策略要跟着改，不要一套分片用到底。
九、小结****
多品类询盘 Agent 的核心矛盾不是"模型够不够聪明"，而是信息边界有没有被显式管理。路由层划清品类边界，分片检索隔离知识串味，术语表约束多语一致性，人工边界兜住风险——这四件事做好，Agent 才敢放在真实的询盘入口上。
这也是为什么完整方案把智能体放在最后一环：先有品牌独立站与结构化知识库，再有内容与信源把 AI 推荐做起来，最后才轮到智能体承接。广州贸启航面向华南外贸企业提供的全案服务，正是按「品牌网站＋原创内容＋高质量外链＋AI智能体」这条链路组织，并依托自研外贸行业大模型"艾斯基模"与自有算力支撑多语言应答。
免责声明：本文为 AI Agent 工程实践类稿件，架构与代码示例基于通用智能体工程思路编写，供开发者参考。不同企业的品类结构、语种分布与业务规则差异较大，实际落地需结合自身数据验证，不构成任何效果承诺。