一、LangChain 相关内容

LangChain 是用于增强大模型能力的开发框架，基础大模型本身不具备记忆功能—— 它仅能根据当前用户输入与有限上下文返回结果，能力依赖训练后固化的参数。需注意，大模型的通用能力并非仅由 “规模” 决定，还与训练数据质量、模型架构、训练目标等因素强相关，规模只是影响因素之一。

1. 那么在 LangChain 框架中，如何为大模型赋予记忆功能？核心思路是：将历史对话上下文封装为 “记忆数据”，并作为下一轮输入的一部分传递给大模型，让大模型能感知此前的对话信息，从而实现 “记忆效果”。
2. 在 LangChain 中，可通过多种 “记忆组件” 实现对话存储：
   • 用ConversationBufferMemory以 “消息列表” 格式存储全部历史对话；
   • 用ConversationWindowMemory存储指定轮次的近期对话（避免历史过长导致输入冗余）；
   • 用ConversationSummaryMemory存储上下文摘要 —— 需传入一个大模型（LLM），由其自动生成历史对话的摘要，减少记忆数据量。
3. 基础大模型不具备主动调用工具的能力，而 LangChain 的Agent 组件可赋予其工具调用能力：其核心逻辑是，先让大模型分析用户需求、识别适配的工具，再按照工具要求的参数格式调用目标工具，最后将工具返回的结果回传给大模型 —— 大模型结合该结果与用户问题，生成最终答案。
4. 在 LangChain 中创建智能体（Agent）的方式有两种：

   1. 通过指定AgentType创建（如 AgentType.REACT、AgentType.FUNCTION_CALLING）：这种方式无法自定义 Prompt，仅能使用框架内嵌的提示词；

   2. 通过create_react_agent、create_function_agent等特定构造函数创建：支持自定义 Prompt，灵活性更高。

      需注意，无论哪种方式，创建后的智能体仅为 “配置好的组件”，需通过AgentExecutor加载智能体并传入工具列表，才能执行具体任务。

二、大模型相关内容

1. 快手在 Agent 研发中采取了 “垂直领域优先” 的策略：未优先开发通用 Agent，而是先聚焦垂直场景（如销售圈智能客服），为其构建 “RAG+Agent” 融合架构。该架构中 RAG 模块分为在线、离线两部分：
   • 离线部分：先对已有知识文档进行预处理（清洗、分词、实体提取），再基于文档内的概念关联关系搭建知识图谱；同时将文档内容与知识图谱节点分别进行向量化处理，存入向量数据库实现持久化存储。此外，还设计了 “多路召回机制”，支持 GraphRAG 召回、向量检索、Elasticsearch（ES）全文检索三种方式；
   • 在线部分：用户提问后，先对问题进行 “泛化处理”（如补充同义词、扩展相关概念，避免因表述差异导致漏召回），再通过多路召回获取相关结果，对结果按 “相关性分数 + 业务权重” 重排序；
   • 最终流程：将重排序后的召回结果与用户问题一同输入大模型，由大模型生成回答，经内容风控审核通过后返回给用户。
2. 在 Agent 调用工具的场景中，能否对工具进行 “编排与分层”？这一思路具有可行性，具体可设计为：
   1. 工具分层：将工具按 “功能复杂度” 划分为三层 ——
      • 基础层：单功能工具（如数据查询工具、格式转换工具、时间戳获取工具）；
      • 组合层：基于基础工具组合的流程化工具（如 “商品数据查询→库存判断→价格计算” 组合工具）；
      • 模板层：针对特定问题的固化流程工具（如 “客户投诉记录查询→问题分类→解决方案匹配” 模板工具）；
   2. 流程沉淀：每次成功解决某一类问题后，将对应的处理流程（如 “用户退款咨询→调用订单查询工具→调用退款规则工具→生成答复”）封装为模板层新工具 —— 这类似于人类总结经验，下次遇到同类问题可直接复用流程；
   3. 智能筛选：大模型调用工具时，可根据问题复杂度匹配对应层级工具（如简单数据查询调用基础层，复杂投诉处理调用模板层），无需重复拆解流程，提升效率。
3. 当任务复杂度较高时（如 “年度财务报表异常分析→原因定位→整改建议→报告生成”），大模型在 “任务分解” 环节的推理效果往往不佳 —— 容易出现子任务遗漏、逻辑混乱等问题。对此，可通过 “复杂流程工具化” 优化：将完整的复杂问题处理流程封装为专用工具（例如上述财务分析任务，可封装为 “财报异常分析工具”），大模型调用该工具时，无需重新拆解任务，仅需传入关键参数（如报表年份、分析维度），即可直接获取结构化结果，进而显著提升解决复杂问题的效率与准确性。