先说一个判断：把大模型真正用起来，最难的地方从来不是调一个API，而是怎么跟现有业务深度结合。今天聊的这个案例——活动组件AI助手，恰好展示了这一路是怎么从“能用”走到“好用”的。

02

背景

活动组件AI助手的落地，大致经历了三个阶段：

• 快速落地：先拿Dify平台做原型，验证AI跟业务结合到底行不行，快速跑通第一版；
• 优化性能：换成LangChain开发第二版，重点提升RAG能力，把推荐组件的性能拉上来；
• 丰富功能：到了第三版，干脆把Agent能力加进来，让AI不光能推荐，还能自己动手查历史活动、复用组件。

之前在《AIGC在活动业务中的探索与应用》里聊过第一版怎么用Dify快速落地。但Dify那条路，说实话，到了后期有点瓶颈——流程复杂、性能也不够理想。所以第二版用LangChain重写了RAG流程，把推荐性能优化了不少。组件推荐这块站稳之后，新想法跟着就来了：能不能根据用户描述，直接去查历史活动，找到类似的组件直接用？这就催生了第三版的Agent能力。现在这个AI助手，可以自主规划任务、调用工具，把历史和组件数据翻出来，甚至直接复用，算是真正朝着“智能助手”迈进了一大步。

03

活动组件AI助手效果展示

RAG实践效果

用户提个需求，AI就能推荐合适的活动组件，连参考方案都一并给出，省去手动翻文档、挑组件的时间成本。

Agent实践效果

Agent能自主规划、拆解任务、反思步骤、推理逻辑、执行工具调用——说白了，就是让AI自己判断该用什么工具来解决问题。

举几个例子：

查活动信息：“最近一个月最火的3个“x游戏”活动”——Agent会自动去库里捞数据。

查组件使用情况：“最近有哪些活动在用这个组件xxxx”——直接给出活动列表。

篇幅关系，这里只列了一部分功能。

04

活动组件AI助手落地实现

LangChain RAG 实践 ：LCEL + 云原生数据仓库

LangChain Expression Language（LCEL）是一个声明式的链组合工具，设计初衷就是让原型能直接线上跑。从最简单的“prompt + LLM”链，到上百步的复杂链，都能用同一套代码搞定，不用改逻辑。这一点在生产环境里非常实用。

加上云原生数据仓库自带向量检索能力，RAG的检索服务也就顺理成章地搭起来了。

RAG的核心流程也很清晰：

LLM先对用户需求做润色，转换成结构化数据 → 拿着结构化数据去知识库做召回 → 捞回上下文，再跟用户需求一起送给LLM → 最后输出推荐组件。

几个关键细节：

• 自然语言 → 结构化数据；
• 数据格式得跟知识库匹配，同时带上可筛选的分类信息；

• 先做分类匹配，缩小范围；
• 召回 relevant_size 个 top k 结果；
• 捞回来的数据再根据 score 做二次筛选；

结构化业务数据；

把结构化数据呈现给用户。

LangChain Agent 实践

这个版本的目标很明确：让AI能根据用户描述，自己规划任务、调用工具，去查活动和组件数据。

核心流程上，Agent需要具备：计划能力、任务拆解能力、反思能力、推理能力、工具执行能力。这样一来，AI就能自己判断用什么工具解决什么问题。

为了做到这一点，没有直接用LangChain内置的Agent——它太通用、太简单了，对付不了实际的复杂业务需求。所以动手自己写了一个ReAct Agent。

不同大模型在Agent上的表现，差异其实不小。理解能力强的模型明显更适合复杂任务。

打印一下ReAct Agent的规划过程：

—— 用户需求：最近一周访问量最高的3个“x游戏”活动。

第一轮思考：...

第二轮思考：...

总结：1. 耗时较长（50-70s）；2. 准确性不够高，理解能力差点——比如要查询PV最少的活动，它理解成了按PV降序排，实际应该按升序。

—— 同样的需求：最近一周访问量最高的3个“x游戏”活动。

总结：1. 性能好很多（10-20s）；2. 准确性高，理解能力强。

对比下来，大模型2在tool_call方面做了微调，对工具调用的需求特别敏感，更适合实现复杂Agent。

最后，把RAG和Agent的能力通过前置AI路由统一起来，实现AI服务的单一入口。这样用户不管提什么需求，都能被正确路由到对应的处理链路。

05

总结

整个过程下来，核心思路就是：用LangChain开发RAG和Agent应用，来解决活动业务中的实际问题。

• 案例展示了活动组件AI助手的两项核心能力：推荐组件、查询历史活动和组件数据；
• 落地过程中，RAG和Agent的实现思路分别做了拆解；
• 最后对比了不同大模型在Agent规划中的实际表现，并给出了完整的总体架构图。