Agent 在二手车行业的落地实践

Agent在二手车行业的落地实践：从记忆中台到智能顾问的全链路搭建

过去一年，我主导了从底层记忆中台、中间Agent编排平台到上层二手车交易智能顾问应用的完整AI Agent落地体系，解决了二手车销售咨询场景中人工成本高、规则系统覆盖不全、多轮对话上下文断层等痛点。本文将复盘整个落地过程，从技术架构、核心机制到业务成果，分享行业Agent落地的实践经验。

一、二手车咨询场景的Agent落地痛点

二手车在线销售的咨询场景，一直是行业里的老大难问题：

1. 问题复杂度高：用户的问题跨越车型配置、车况、金融方案、交易流程、售后、车辆推荐等近10个领域，传统规则引擎最多只能覆盖40%的标准化问题，剩下的开放式问题全靠人工坐席处理；
2. 长周期上下文断层：二手车交易周期长达1-2周，客户的交互分散在线聊天、历史跟进消息、APP各种动作行为等多个渠道，销售很难记住客户之前提过的预算、偏好，经常重复问相同的问题，口径不一，体验很差；
3. 能力扩展慢：之前每次上新业务，都要改核心代码，上线周期长达2周，跟不上业务的迭代速度；
4. 稳定性差：早期试过单一模型直答，不仅经常答非所问，遇到高并发场景还经常出现旧回复覆盖新问题的情况，问题排查也非常困难。

为了解决这些问题，我们搭建了一套分层的Agent落地体系：从底层的记忆中台解决上下文问题，到中间的编排平台解决能力沉淀与迭代问题，最终在上层落地了智能顾问中台，实现了咨询的自动化闭环。

二、底层基建：对话记忆中台，解决Agent的「长周期上下文」问题

Agent最核心的能力之一就是「记忆」——没有稳定的长周期记忆，多轮对话就是无根之木。为此我们从0到1搭建了网销记忆中台，把多个来源（企业微信、IM、商城浏览搜索等动作记录）的碎片化数据，加工成Agent可以直接使用的分层记忆。

2.1 整体架构

整个记忆中台采用分层设计，对外提供统一的写入/查询接口，内部通过异步任务处理高耗时的摘要计算：

接口层（FastAPI） -> 编排层（UserStateManage） -> 记忆管理层（Short/Long Memory） -> Agent Prompt层 -> 存储层（Mongo/Redis）

• 接口层：提供/onchat/historychat/action`三类写入接口，分别承接在线聊天、历史跟进消息、APP行为数据，统一用Pydantic做参数校验；
• 编排层：统一处理不同来源的数据，做清洗、去重，过滤掉系统消息、机器人话术等噪声；
• 记忆管理层：核心是两级记忆沉淀机制：
  • 短期记忆：对最近的对话做消息级摘要，保留实时上下文；
  • 长期记忆：对整个会话做会话级摘要，沉淀客户的需求、偏好、关键问题等长期信息；
• 存储层：用Mongo做主存储，Redis做队列和分布式锁，预留了Milvus/ES的向量检索接口，为后续语义召回做扩展。

2.2 核心机制

（1）多源数据统一处理

我们把在线聊天、历史消息、APP行为三类完全不同的数据，统一标准化成了Agent可以理解的格式，同时做了噪声过滤：比如过滤掉系统通知、重复的机器人话术，把APP的点击行为转化成「用户查看了XX车源」这类语义化信息。

（2）双触发的记忆压缩

为了平衡上下文完整性和Token成本，我们设计了双触发的截断策略：

• 长度触发：当单轮聊天的消息数超过阈值时，把历史窗口转成摘要，保留最近的实时消息；
• 时间触发：按时间差切分会话，超过2小时的历史自动转成长期摘要，避免实时上下文被旧数据污染。

（3）异步化与并发控制

把耗时的LLM摘要计算从主接口链路剥离，用Celery做异步消费，同时对每个用户加了分布式锁，避免并发Worker重复做摘要、覆盖记忆，保证了记忆的一致性。

最终这个中台，把之前高噪声的碎片化交互数据，变成了Agent可以直接调用的chat_history/short_memory/long_memory，解决了长周期对话的上下文断层问题，为上层的所有Agent应用提供了基础的记忆能力。

三、中间层：基于Langgraph的Agent编排，让能力可沉淀、可迭代

有了记忆能力之后，我们需要解决的下一个问题是：怎么管理大量的领域Agent？怎么让业务能力可以快速迭代、稳定上线？

我们基于Langgraph搭建了一套Agent编排与发布体系，把 workfow graph 作为核心资产，实现了「主路由+领域子Agent」的分层架构，让不同的专业Agent各司其职，同时保证整个系统的可迭代性。

3.1 整体架构

整个编排平台的核心是分层的工作流设计：

前置上下文工程 -> 主路由中台 -> 领域子Agent集群 -> 缓存与发布治理

• 上下文工程：统一做会话历史压缩、词槽定位、隐私脱敏、查询改写，把用户的输入处理成标准格式，给下游Agent使用；
• 主路由中台：核心是「规则优先+LLM兜底」的路由策略，先通过query_type、精确匹配、正则这些规则做路由，规则没命中的再用LLM做意图识别，保证路由的准确性和可解释性；
• 领域子Agent：把车况、价格、金融、服务与权益等不同领域的能力，拆成独立的子Agent，每个Agent只负责自己的领域，保证专业度；
• 发布治理：所有的Agent工作流都用langgraph进行workflow图管理，支持多环境配置、灰度发布、快速回滚，解决了之前Agent迭代乱、难回滚的问题。

3.2 核心能力

（1）可控的路由策略

我们没有用纯LLM做路由，而是设计了多阶段的融合路由：

query_type -> postback -> 精确匹配 -> 正则匹配 -> LLM识别

90%的常见问题都可以通过规则命中，剩下的10%才会交给LLM，既保证了路由的速度和稳定性，又能覆盖开放式的问题，路由准确率提升到了95%以上。

（2）标准化的上下文工程

我们把所有Agent共用的上下文能力抽成了统一的流水线：

• 历史压缩：只保留和当前问题相关的历史轮次，把Token成本降低了40%；
• 查询改写：把用户的模糊指代（比如「这个车多少钱」）补全成完整的问题，提升下游Agent的理解准确率；
• 隐私脱敏：统一识别手机号、身份证等敏感信息，做脱敏处理，保证合规。

（3）workflow资产化与发布治理

所有的Agent工作流都存成Git管理的graph文件，变更后自动触发发布流程，支持 online/preview/test多环境切换，还可以做灰度发布，出问题了可以一键回滚，把业务能力的上线周期从2周缩短到了1天，迭代效率提升了非常多。

四、上层应用：智能网销顾问，打造可执行的行业Agent

在底层记忆和中间编排的基础上，我们最终落地了核心的业务应用：汽车销售AI顾问中台，把之前分散的能力整合起来，实现了从用户咨询到业务动作触发的完整闭环。

4.1 整体架构

汽车销售AI顾问中台的核心是三段式智能体链路+插件化技能体系，既保证了核心链路的稳定性，又支持业务能力的快速扩展：

接口层（FastAPI） -> 应用服务层 -> 智能体层 -> 技能层 -> 基础设施层

• 智能体层：核心是用户问题改写 -> 编排规划 -> 总结三段式主链路：
  1. QueryParseAgent：对用户的问题做改写和结构化意图提取；
  2. OrchestratorAgent：做技能选择、执行规划、脚本运行和工具调度；
  3. SummarizerAgent：把技能执行的结果，聚合生成用户能看懂的回复；
• 技能层：把车况、推荐、金融这些业务能力，做成了可插拔的技能插件，每个技能只需要写SKILL.md和执行脚本，就可以快速接入到系统里，不用改核心代码；
• 基础设施层：用LiteLLM做模型路由，保证主模型挂了可以自动切fallback；用Langfuse+OTEL做全链路追踪，方便问题排查；用Celery做异步任务调度，处理高并发场景。

4.2 核心业务流程

用户的一次咨询，会走完这样的完整闭环：

1. 请求接入：新消息进来的时候，我们会在Redis里写一个用户级的中断标记，自动中断用户之前的旧任务，避免旧回复覆盖新问题；
2. 预处理：先做短路判断（比如黑名单、人工接管场景直接跳过），然后把语音、图片这些多媒体消息，通过ASR/OCR转成文本；
3. 上下文注入：把记忆中台的短/长期记忆、用户画像、渠道信息注入到上下文里；
4. 三段Agent执行：先做意图解析，然后调度对应的技能执行，最后生成结构化的回复；
5. 后处理与任务触发：把回复转成文本或者卡片下发，同时自动触发业务动作，比如给销售发跟进提醒、自动加企业微信好友；
6. 记忆回写：把这次的对话写回记忆中台，供下一轮使用。

4.3 我们解决了哪些落地的难点？

做行业Agent，最大的挑战不是算法有多先进，而是生产环境的稳定性，我们在落地过程中解决了几个核心的痛点：

1. 多技能调用失控：早期Agent经常反复调用同一个技能，陷入死循环，我们设计了工具状态机，把技能调用分成加载、执行、总结三个阶段，限制每个阶段的调用行为，把无效循环的概率降到了0.1%以下；
2. 高并发的旧任务覆盖：之前用户发了新消息，旧的慢请求还在处理，结果旧回复覆盖了新的，我们做了用户级的Redis中断信号，新消息进来直接终止旧任务，彻底解决了这个问题；
3. 依赖多导致的链路脆弱：技能调用要依赖很多外部接口，经常挂掉影响整个链路，我们做了统一的降级策略：短路、兜底文本、失败隔离，哪怕某个技能挂了，主链路也能正常运行，可用性从95%提升到了99.5%；
4. 问题难定位：之前Agent出了问题，根本不知道是哪一步错了，我们引入了Langfuse+OTEL的全链路追踪，每个请求的每一步都有打点，问题排查时间从2小时缩短到了5分钟。

4.4 业务成果

最终这个系统上线后，取得了非常明显的业务效果：

• 复杂咨询的自动处理率提升到了70%，人工坐席的处理成本降低了30%；
• 响应时效从平均15秒缩短到了2秒，用户咨询的满意度提升了25%；
• 业务能力的扩展成本降低了60%，新场景的上线周期从2周缩短到了1天。

更重要的是，这个系统不是只会回答问题的聊天机器人，而是真正能执行业务动作的智能顾问：它可以自动触发跟进任务、加微、甚至帮销售做客户的需求分析，真正把Agent落地到了业务的流程里。

五、行业Agent落地的4个核心经验

过去一年的落地实践，我总结了几个行业Agent落地的核心经验，分享给大家：

1. 分层解耦，不要做大一统的Agent：不要试图用一个通用Agent解决所有问题，分层搭建底层基建、中间编排、上层应用，每一层解耦，既能保证稳定性，又能快速扩展；
2. 可控性比先进性重要：生产环境的Agent，首先要保证稳定、可解释、可控制，不要盲目追最前沿的算法，规则优先+LLM兜底、工具状态机、降级策略，这些看似不高端的设计，才是落地的关键；
3. 工程化比算法更重要：很多人做Agent只关注Prompt和算法，但是生产环境里，异步处理、中断机制、可观测性、发布治理这些工程化的能力，才是决定你的Agent能不能上线、能不能稳定运行的核心；
4. 插件化沉淀能力：把业务能力做成可插拔的插件，而不是耦合在核心代码里，这样才能快速响应业务的变化，让你的系统可以持续迭代。

六、未来展望

目前我们的体系已经跑通了核心的咨询场景，接下来我们还会在几个方向继续优化：

1. 完善Sub-Agent的协作模式，支持更复杂的多Agent协作场景；
2. 把向量检索落地到记忆中台，做语义化的记忆召回，提升长周期记忆的准确性；
3. 搭建编排策略的A/B实验框架，持续优化路由和技能执行的效果，提升成交转化。

过去一年的实践让我深刻感受到，行业Agent的核心不是把大模型套上去，而是要结合行业的业务痛点，搭建一套从底层基建到上层应用的完整体系，让Agent真正能解决业务问题，而不是实验室的玩具。希望这篇分享能给正在做行业Agent落地的同学一些参考。