在前几篇文章中，项目已经完成了 TFT 阵容顾问的资源构建、英雄识别、装备识别和截图路由层。旧方案主要依赖 tft_screen_capture.py，通过 OpenCV 完成六边形边框检测、HSV 直方图粗筛、灰度 NCC 模板匹配等流程。这套方案的优点是实现清晰、依赖轻、CPU 即可运行，但随着识别场景变复杂，它的上限也逐渐暴露出来：截图来源不统一、边框颜色变化、英雄头像缩放、UI 遮挡、无框

TFT战术顾问的第一版采用单LLM调用模式：将阵容数据与用户问题拼接为prompt，直接请求大模型生成分析结果。第一，分析深度不足。单个prompt需同时覆盖经济运营、阵容战力、站位布局三个维度，大模型倾向于对每个维度给出概括性描述，难以深入展开。该现象的本质是注意力分散——当prompt中同时存在多个异构任务时，模型对每个任务的token分配与推理深度呈反比。第二，思维模式冲突。

在TFT 阵容顾问项目里，tft_fetch_assets.py 不仅一个“下载图片”的脚本，如果把整个项目串起来看，该文件承担的是 模板资源构建器 的角色。它上游连接 tft_data_manager.py 生成的赛季数据，下游直接服务 tft_screen_capture.py 的 OpenCV 模板匹配，是截图识别链路里非常关键的一层。

随着大语言模型技术的快速发展，越来越多的智能问答系统、推荐系统和辅助决策系统开始集成第三方大模型接口。为了提升系统的可扩展性与可维护性，本文设计并实现了一个统一的大语言模型客户端 LLMClient。该客户端采用面向对象思想，对 Anthropic 与 OpenRouter 两类模型服务进行统一封装，实现了模型选择、API Key 解析、消息请求发送以及异常处理等功能。该设计降低了业务层与底层模型