LangChain

一、LangChain 的核心定位和功能是什么？

1. 核心定位：AI 应用的底层基础设施

LangChain 的定位类似于 Java 生态中的 Spring Boot——为构建复杂、可定制的 AI 应用提供底层基础设施。它不是一个可视化的低代码平台，而是一个代码优先的框架，强调灵活性和工程可控性，适用于需要深度定制或与企业系统集成场景。其核心理念是：大语言模型最有价值的时候，是能够连接到外部世界——文档、数据库、API 和工具——而不是孤立地调用 API。

2. 三大基础能力

• 统一的模型抽象：提供一致的接口调用 50 多种 AI 提供商的模型，包括 OpenAI、Anthropic、Google、Azure OpenAI、Cohere 等，开发者无需因更换模型而重写应用逻辑
• 可组合的编排原语：通过 LangChain Expression Language（LCEL）的管道符 | 将多个组件串联成执行链，支持声明式编程构建复杂工作流
• 丰富的集成生态：覆盖文档加载、向量存储、工具调用、消息历史管理等全链路组件，每个组件独立可用也可自由组合

3. 从"胶水框架"到"Agent 基础设施"的演进

早期 LangChain 被称为"胶水框架"，主要解决不同 LLM API 之间的适配问题。到 2026 年，随着 Agent 范式的兴起，LangChain 已演进为以 LangGraph 为状态引擎、以 create_agent 为标准入口、以 Middleware 为扩展点的完整 Agent 开发生态。2025 年 10 月发布的 v1.0 版本标志着框架从快速迭代期进入生产成熟期，承诺 v1.x 系列无破坏性变更。

二、LangChain 的技术架构包含哪些核心模块？

1. 三层模块化架构

LangChain 采用分层设计，各层职责清晰且可独立使用：

• 基础层：定义 LangChain 与模型之间的通信协议，是所有上层功能的地基。包含标准化消息格式（Messages）、提示词模板（Prompts）、统一模型接口（Models）、工具定义（Tools）、对话记忆（Memory）、结构化输出（Structured Output）、流式输出（Streaming）和中间件（Middleware）等八个核心模块
• 能力层：建立在基础层之上，提供可自由组合的核心能力组件。包括 Chain（链式编排）、Retrieval（RAG 检索增强生成）、Agent（自主规划执行）等
• 应用层：面向业务场景的顶层模块，组合下层能力解决实际问题，如问答系统、智能代理、多 Agent 协作等

2. 包结构重组（v1.x）

v1.x 对包结构进行了彻底重构，解决了 v0 时代"一个包塞满一切"的问题：

生产环境建议直接依赖 langchain-core 加所需集成包，避免引入整个 langchain 全家桶。

3. 核心组件分类

三、LangChain 中的 Chain（链）是如何工作的？

1. Chain 的基本概念

Chain 是 LangChain 最基础的流程组合单元，将提示词、模型、解析器、工具等组件串联成完整的业务流程。在 v1.x 中，传统 Chain 类已进入废弃通道，官方推荐统一迁移到 LangGraph；直线型流程使用 LCEL 的管道符表达同样简洁，但获得了更强的可组合性。

2. LCEL 管道表达式

LCEL（LangChain Expression Language）使用管道符 | 将多个 Runnable 对象串联，写法简洁且可读性强：

rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

上述表达式表示：先将检索结果格式化，同时将原始输入透传，两者合并后送入提示词模板，再交给 LLM 处理，最后用字符串解析器输出结果。

3. Chain 的常见类型

• Simple Sequence Chain：最简单的线性链，按顺序执行一系列操作
• Sequential Chain：前一个 Chain 的输出作为下一个 Chain 的输入，适合多步骤处理流程
• LLM Chain：最基础的链，由提示词模板、LLM 和输出解析器组成
• Pipeline Chain：支持更复杂的嵌套编排，可在一个 Chain 内组合多个子 Chain

4. Runnable 接口体系

所有 Chain 组件都实现了 Runnable 接口，支持三种核心操作模式：

• invoke()：单次执行
• batch()：批量执行
• stream()：流式逐 token 输出

这种统一接口使得组件之间可以无缝拼接，也为调试和观测提供了标准化的入口。

四、LangChain 中的 Agent（智能体）如何实现自主决策？

1. Agent 的核心机制：ReAct 循环

LangChain Agent 通过 ReAct（Reasoning + Acting）框架驱动自主决策，形成"思考→行动→观察→再思考"的闭环。具体执行过程如下：

• 推理（Reason）：LLM 根据当前状态（任务、对话历史、工具描述）生成思考文本和决策
• 行动（Act）：Agent 解析 LLM 的输出，识别工具调用指令并执行对应工具函数
• 观察（Observe）：工具执行结果作为新的观察输入反馈给 LLM
• 循环判断：如果 LLM 继续请求调用工具，则重复上述步骤；如果输出 Final Answer，则循环终止

2. create_agent：v1.x 标准入口

在 LangChain v1.0 中，create_agent 成为唯一推荐的 Agent 创建方式，取代了旧的 AgentExecutor 和 initialize_agent 等碎片化写法。其底层统一运行在 LangGraph 上，自带 ReAct 循环：

from langchain.agents import create_agent

agent = create_agent(
    model=model,
    tools=[get_weather, search_movies],
    system_prompt="You are a helpful assistant.",
)

create_agent 自动处理工具调用的循环逻辑，开发者只需提供模型、工具和系统提示词即可。

3. Agent 的关键组件

• Agent（决策大脑）：基于 LLM 进行推理和决策，决定下一步该做什么
• Tools（执行手脚）：标准的 Python 函数，带有名称、描述和参数定义。描述至关重要，因为 LLM 通过阅读工具描述来决定是否以及如何调用它
• Prompt（指令模板）：包含系统指令、工具描述、历史对话和用户输入的模板，直接决定 LLM 的推理质量
• AgentExecutor（运行时引擎）：负责管理 ReAct 循环的执行，处理解析、调用和状态推进

4. Agent 的工作流程

• 组装提示：将用户问题、对话历史（来自 Memory）、可用工具列表及其描述组合成详细提示词
• LLM 推理：分析提示词，生成遵循约定格式的结构化文本（Thought/Action/Action Input 或 Final Answer）
• 解析分发：识别 Action 则调用对应 Tool 函数，识别 Final Answer 则终止循环
• 执行与观察：工具返回结果标记为 Observation，连同之前的 Thought、Action 等作为新上下文再次发送给 LLM
• 结束与记忆：循环终止后，最终问答对存入 Memory

五、LangChain 的 RAG（检索增强生成）能力是如何实现的？

1. RAG 的基本原理

RAG（Retrieval-Augmented Generation）是一种让大语言模型不局限于训练知识的架构——通过从外部知识库检索相关信息，将其作为上下文注入提示词，再让模型基于这些信息生成回答。这有效解决了模型知识过时、幻觉问题和无法访问私有数据等局限。

2. LangChain 的 RAG 完整流水线

LangChain 提供了一套完整的 RAG 实现链路，涵盖五个核心步骤：

• 文档加载（Load）：通过 DocumentLoader 从 PDF、网页、目录等多种来源加载文档，支持 PyPDFLoader、WebBaseLoader、DirectoryLoader 等数十种加载器
• 文档切分（Split）：使用 TextSplitter（推荐 RecursiveCharacterTextSplitter）将大文档递归切分为合适大小的 chunk，控制 chunk_size 和 chunk_overlap 以平衡搜索精度和上下文完整性
• 嵌入向量化（Embed）：通过 Embedding 模型将每个文本 chunk 转换为数值向量，使语义相似的内容在向量空间中距离更近。支持的 Embedding 提供商包括 OpenAI、Azure、Google Gemini、Cohere、Voyage AI 等
• 向量存储（Store）：使用 VectorStore 索引 chunk 及其嵌入向量以便高效检索。支持的向量数据库包括 Chroma、Pinecone、FAISS、Milvus、Qdrant、Weaviate 等，腾讯云也提供了向量数据库（Tencent Cloud Vector Database）作为云原生选项
• 检索与生成（Retrieve + Generate）：将用户查询转为向量，在 VectorStore 中进行相似度搜索获取相关 chunk，注入提示词后由 LLM 生成答案

3. 高级 RAG 技术

LangChain 还支持多种进阶 RAG 技术以提升回答质量：

• Multi-Query Retrieval：用 LLM 生成多个变体查询，提高召回覆盖率
• Ensemble Retriever：结合 BM25 关键词检索和向量语义检索的混合搜索策略
• Contextual Compression：检索后通过 LLM 压缩和提取最相关的信息片段
• Conversational RAG：在多轮对话中维护上下文，支持基于历史对话的追问

4. Deep Agents 中的 RAG 模式

在 Deep Agents 中，RAG 支持多种编排模式：

• Skills-guided retrieval：Agent 加载相关 skill 指导如何搜索 corpus
• Rubric-checked grounding：审核子 Agent 评估回答是否基于检索到的材料
• Todo-driven investigation：Agent 创建待办清单逐项调查文档
• Retrieve, offload, and delegate：检索 chunk 写入文件系统，子 Agent 并行读取和分析

六、LangChain 中的 Memory（记忆）机制有哪些类型？

1. Memory 的设计目的

大语言模型本质上是无状态的，每次 API 调用都是独立的。Memory 组件通过显式管理对话历史和上下文状态，将无状态的 LLM 调用转化为有连续性的对话体验。所有 Memory 组件统一实现 load_memory_variables() 和 save_context() 接口。

2. 五种 Memory 类型

• ConversationBufferMemory（全量缓存记忆）：完整保存所有对话轮次，不做任何压缩。优点是精确无误，缺点是随着对话增长会无限消耗 Token，最终超出模型的上下文窗口。适用于短对话、轮次少的场景
• ConversationBufferWindowMemory（滑动窗口记忆）：只保留最近 K 轮对话，丢弃更早的内容。通过设置 k 参数控制保留轮数，在 Token 使用和记忆范围之间取得平衡。适用于话题切换频繁的一般聊天场景
• ConversationSummaryMemory（摘要记忆）：使用 LLM 定期将长对话压缩为摘要，摘要随每轮对话更新。相比全量缓存大幅减少 Token 占用，代价是需要额外的 LLM 调用成本，且可能丢失细节。适用于主题连贯的长对话
• ConversationSummaryBufferMemory（摘要缓冲混合记忆）：结合上述两种方式的优点——近期对话以全文形式保留，早期对话被摘要压缩。通过 max_token_limit 控制总 Token 上限，超过后 oldest messages 被摘要化。这种混合方案兼顾了近期上下文的精确性和长期上下文的成本控制
• VectorStoreRetrieverMemory（向量库长期记忆）：将对话片段向量化存入向量数据库（如 FAISS、Chroma），通过语义搜索而非时间顺序检索相关记忆。模拟人类的"联想记忆"，能从海量历史中精准抓取相关信息，适合构建个人专属助手或需要跨会话长期记忆的系统

3. 持久化记忆方案

对于生产环境，Memory 需要支持跨会话持久化。LangChain 提供了多种持久化后端：

• Redis 后端：通过 RedisChatMessageHistory 实现，速度快、支持过期时间配置，适合实时性要求高的场景
• SQL 后端：通过 SQLChatMessageHistory 支持 SQLite、PostgreSQL 等关系型数据库
• MongoDB 后端：通过 MongoChatMessageHistory 实现文档型存储
• LangGraph Checkpointer：通过 LangGraph 的检查点机制实现 durable execution，支持状态持久化和断点续跑

4. Memory 选型建议

选择 Memory 类型时可根据以下维度判断：对话时长较短（20 轮以内）选用 Buffer Memory；需要保留近期上下文但控制成本选用 Buffer Window；长对话且关注成本选用 Summary Memory；需要从大量历史中精确回忆特定事实选用 Vector Store Memory；需要跨会话持久化则配合 Redis 或 SQL 后端。许多生产应用会组合使用多种 Memory 类型。

七、LangChain 的工具调用（Tool Calling）机制是如何运作的？

1. Tool 的定义方式

LangChain 通过 @tool 装饰器将普通 Python 函数转化为 LLM 可调用的工具。装饰器自动提取函数的 docstring 作为工具描述，利用类型注解定义参数 schema，LLM 通过阅读工具描述来决定是否以及如何调用该工具：

from langchain_core.tools import tool

@tool
def get_weather(city: str, date: str = "today") -> str:
    """获取指定城市和日期的天气信息"""
    ...

2. 工具调用的执行流程

• LLM 在推理阶段分析用户请求和工具描述，决定是否需要调用工具以及调用哪个工具
• LLM 输出包含工具名称和参数的结构化消息（tool_calls）
• AgentExecutor 解析 tool_calls，找到对应的 Python 函数并传入参数执行
• 工具执行结果封装为 ToolMessage，回传给 LLM 作为下一轮推理的输入
• LLM 根据工具返回结果生成最终回答或继续调用其他工具

3. 高级工具特性

• 并行工具调用：LLM 可以在一条消息中同时发出多个 tool_calls，AgentExecutor 会并行执行这些独立工具调用，显著降低端到端延迟
• 异步工具调用：支持 asyncio 实现的异步工具执行，进一步提升并发性能
• 工具路由筛选：使用 RouterToolkit 或自定义 ToolSelector 根据用户意图预筛工具子集，避免 LLM 在大量工具中盲目尝试
• 工具结果验证：在 Observation 后插入校验链（如 JSON Schema 解析器），过滤非法返回防止下游工具崩溃

4. 工具安全与权限控制

v1.x 版本增强了工具调用的安全机制，包括工具级别的权限控制和沙箱隔离。企业场景中可通过中间件在 wrap_tool_call 钩子中拦截工具执行结果，实施内容审查和数据脱敏。

八、LangChain 的中间件（Middleware）系统支持哪些场景？

1. Middleware 的设计思想

Middleware 是 LangChain v1.x 引入的一等公民概念，暴露了一组钩子（Hooks），允许开发者在每个执行步骤前后插入自定义逻辑。Middleware 是可组合的，多个中间件可以按需叠加，互不干扰。

2. 两类钩子机制

• 节点级钩子（Node-Style Hooks）：按顺序在特定生命周期点触发，不直接改变执行流程（除非显式跳转或抛出异常）。包括 before_agent（智能体启动前，仅触发一次）、before_model（每次模型调用前）、after_model（每次模型返回后）、after_agent（智能体结束后，仅触发一次）
• 包装级钩子（Wrap-Style Hooks）：包裹目标函数，拥有是否调用、调用次数和是否绕过的完全控制权。包括 wrap_model_call（包裹模型调用）和 wrap_tool_call（包裹工具调用），是实现重试、缓存、限流的核心位置

3. 内置中间件场景

LangChain 内置了多款常用中间件：

• PII 脱敏中间件：在 before_model 和 after_model 钩子中自动检测并掩码/哈希个人信息，支持 HIPAA 合规需求
• 摘要中间件（SummarizationMiddleware）：在 before_model 钩子中监控 Token 使用量，当消息历史超过阈值时自动摘要压缩，防止上下文溢出
• LLM 工具选择中间件（LLMToolSelectorMiddleware）：在 wrap_model_call 钩子中使用轻量 LLM 预先筛选相关工具子集，减少上下文膨胀
• 重试中间件：在 wrap_model_call 中实现指数退避重试逻辑，自动处理网络抖动和临时故障
• 人工审批中间件：在 after_model 钩子中实现 human-in-the-loop，在模型输出发送给客户端前先经过人工确认

4. 自定义中间件

开发者可以通过继承 AgentMiddleware 类或使用装饰器（@before_model、@after_model、@wrap_model_call 等）编写自定义中间件。中间件可以读取和修改 Agent State，实现状态统计、日志记录、指标上报、动态配置注入等功能。

九、LangChain 实现多智能体协作的典型模式有哪些？

1. 为什么需要多 Agent

单 Agent 在面对复杂任务时存在局限性：工具过多导致选择困难和 Prompt 膨胀、角色混乱影响专业深度、资源浪费（即使只问客服问题也加载全部工具）。多 Agent 通过分工协作解决这些问题，类似一家公司中客服专员、软件工程师、财务分析师各司其职。

2. 五种官方推荐的多 Agent 模式

• Subagents（子智能体）模式：主 Agent（Supervisor）将子 Agent 包装为工具来调用，所有路由通过主 Agent 传递。子 Agent 默认无状态，历史记忆由主 Agent 统一维护。适用于多领域分工明显、子 Agent 不需要直接与用户长期对话的场景，如企业助理、商旅规划等混合系统
• Handoffs（交接）模式：行为由状态驱动变化，工具调用更新状态变量触发 Agent 切换或配置调整。适用于必须按步骤推进、不同阶段交互方式不同的场景，如售后流程、审批流、表单收集等带状态机的对话流程
• Skills（技能）模式：单个 Agent 保持控制，按需加载专门的提示词和知识上下文。适用于一个 Agent 但领域众多、想做渐进式暴露工具与知识的场景，不想引入复杂的多 Agent 编排时使用
• Router（路由）模式：通过路由步骤对输入进行分类，引导至不同的专业化 Agent，最后汇总结果。适用于先判断任务类型再派单的场景，如技术问答走 research_agent、计划制定走 planner_agent
• Custom Workflow（自定义工作流）：使用 LangGraph 构建 bespoke 执行流程，混合确定性逻辑和 Agent 行为，可将上述模式作为节点嵌入图中

3. 三种协作执行方式

• 串行模式（Serial）：Agent A → Agent B → Agent C，每一步依赖前一步的结果。流程清晰、每步结果可单独检查，但总耗时为各步骤之和
• 并行模式（Parallel）：协调器 Agent 同时启动多个子 Agent 处理独立子任务，最后汇总结果。大幅缩短总耗时，但需处理结果合并和容错逻辑
• 委托模式（Delegation/Supervisor）：主管 Agent 动态决定将任务交给哪个专家 Agent，支持多跳路由和结果合成

4. 多 Agent 设计的核心考量

多 Agent 系统的核心是上下文工程——决定每个 Agent 能看到哪些信息。系统设计时需权衡模型调用次数、Token 处理量和延迟。Subagents 模式通常产生最多模型调用（4 次），Handoffs 和 Skills 模式约 3 次，Router 模式也是 3 次。实际生产中常混合使用多种模式。

十、LangChain 如何实现对结构化输出的控制？

1. 结构化输出的重要性

在生产环境中，AI 应用的输出往往需要符合特定的数据结构（如 JSON Schema、Pydantic Model），以便下游系统可靠消费。结构化输出确保 LLM 返回格式一致、类型正确、可直接序列化的结果。

2. 两种结构化输出策略

• ProviderStrategy（厂商原生策略）：优先使用模型提供商的原生结构化输出 API（如 OpenAI 的 JSON Mode）。效率最高，因为直接在模型层面约束输出格式，不消耗额外的工具调用 Token。适用于明确支持原生结构化输出的模型
• ToolStrategy（工具调用策略）：将结构化 Schema 转为虚拟工具，LLM 通过调用虚拟工具输出符合 Schema 的结果。兼容所有支持工具调用的模型，通用性最强。当模型不支持原生结构化输出或原生能力不可靠时使用

LangChain v1.x 中，create_agent 支持直接传入 Pydantic Model 作为 response_format 参数，框架会自动推断使用哪种策略：优先尝试 ProviderStrategy，失败则降级为 ToolStrategy。

3. Schema 支持类型

ToolStrategy 支持多种 Schema 定义方式：

• Pydantic BaseModel：带有字段验证的类型化模型，返回经过验证的 Pydantic 实例
• 数据类（Dataclass）：使用标准库 dataclass 定义的结构
• TypedDict：使用 TypedDict 定义的键值对结构
• JSON Schema：直接使用 JSON 模式规范字典
• 联合类型（Union）：多种模式选项，模型根据上下文选择最合适的

4. 错误处理机制

ToolStrategy 提供灵活的 handle_errors 配置：可以捕获所有错误并重试、使用自定义错误消息、仅捕获特定异常类型，或设置为 False 不进行重试直接抛出异常。这在生产环境中非常关键，因为 LLM 偶尔会输出不符合 Schema 的内容。

十一、LangChain 如何集成向量数据库实现语义搜索？

1. 向量检索的基本原理

向量数据库通过 Embedding 模型将文本转换为高维数值向量，将语义相似度计算转化为向量间的数学运算（如余弦相似度、欧氏距离）。当用户发起查询时，查询文本也被转为向量，系统在向量数据库中查找最接近的向量对应的文档片段，实现语义层面的匹配而非关键词匹配。

2. LangChain 的向量存储抽象层

LangChain 为各种向量数据库提供了统一的接口抽象，开发者可以用相同的 API 操作不同的后端。核心流程包括：

• 使用 Embedding 模型将文档切片转换为向量
• 通过 VectorStore.from_documents() 将文档和向量持久化存储
• 调用 as_retriever() 将 VectorStore 转为 Retriever 接口
• 通过 retriever.invoke(query) 执行语义搜索获取相关文档

3. 支持的向量数据库

LangChain 支持 60+ 种向量存储集成，常见的包括：

• Chroma：轻量级、易于本地部署，适合快速原型开发
• Pinecone：云原生托管服务，支持大规模生产环境
• FAISS：Facebook 开源的高性能向量搜索引擎
• Milvus / Qdrant / Weaviate：企业级云原生向量数据库
• OpenSearch / PostgreSQL (pgvector)：通用数据库扩展方案

国内开发者可使用腾讯云向量数据库（Tencent Cloud Vector Database）获得稳定的云原生向量检索服务，与 LangChain 的向量存储接口兼容。

4. 检索优化技术

• 元数据过滤：在向量检索基础上增加基于元数据的精确过滤，如按来源、日期、类别筛选
• Hybrid Search：结合关键词检索（BM25）和向量语义检索的混合搜索，提升召回精度
• 重排序（Re-ranking）：初步检索后用重排序模型对结果进行精细打分和排序
• 自适应检索参数：根据查询复杂度动态调整检索数量 k 值和相似度阈值

十二、LangChain 的企业级功能有哪些？

1. LangSmith 可观测性平台

LangSmith 是 LangChain 配套的 Agent 工程平台，提供生产环境所需的完整可观测性能力：

• 分布式追踪：将每次 Agent 运行分解为结构化的时间线，精确展示每个步骤的执行顺序和原因。支持 Python、TypeScript、Go、Java SDK 接入
• 分析洞察：聚合趋势指标、AI 驱动的分析报告，自动检测使用模式和失败模式
• 评估体系：支持人类评审、LLM-as-judge、成对比较、CI/CD 集成和多轮对话评分，使用真实生产数据持续改进 Agent 表现
• 交互式调试：Polly 工具支持自然语言调试和提示词工程

截至 2026 年，LangSmith 已处理超过 150 亿次追踪和 100 万亿个 Token。

2. 生产级部署能力

• LangGraph Platform：提供可扩展的分布式运行时，支持 Agent 的弹性伸缩、持久化状态管理和定时任务调度
• 人机协同（Human-in-the-Loop）：Agent 执行过程中可暂停等待人工审批，适用于金融、法律、医疗等高 stakes 场景
• 类型安全流式传输：支持消息、UI 组件和自定义事件的类型安全流式传输
• A2A 和 MCP 协议支持：原生支持 Agent-to-Agent 通信协议和 Model Context Protocol

3. 企业安全和治理

• SOC 2 Type II 认证：满足企业级安全合规要求
• SSO/SAML 和 RBAC：支持单点登录和基于角色的访问控制
• 审计日志：完整的操作审计追踪
• 客户管理加密密钥（CMK）和 VPC Peering：满足数据驻留和加密管控要求
• 自托管选项：支持私有化部署 LangSmith 和 LangGraph Platform

4. NVIDIA 企业级集成

2026 年 3 月，LangChain 与 NVIDIA 宣布全面整合，推出企业级 Agent AI 平台：

• GPU 加速执行：NVIDIA 优化的 LangGraph 执行策略，包括并行执行（自动识别独立节点并发运行）和推测执行（同时运行条件分支）
• NVIDIA NIM 微服务：在云、本地和混合环境中提供最高 2.6 倍的吞吐量
• NVIDIA OpenShell：基于策略的安全护栏沙盒运行时，控制 Agent 可访问的数据库、网络连接和云调用
• NeMo Agent Toolkit：提供身份验证、速率限制、内置调试 UI 和 GPU 集群规模计算器

5. 企业级中间件能力

• PII 合规：内置 PII 检测和脱敏中间件，满足 GDPR、HIPAA 等隐私法规
• 内容审核：在模型输出后插入内容安全检查
• 动态模型切换：根据负载、成本和延迟需求动态选择模型
• 限流和熔断：在 wrap_model_call 中实现细粒度的流量控制

十三、LangChain 在金融、医疗、法律等行业有哪些应用场景？

1. 金融行业

• 智能投研分析：Agent 自动检索最新市场数据、财报信息和研报，综合生成投资分析报告
• 风控合规审查：利用 RAG 技术构建合规知识库问答系统，自动审查合同条款和交易记录的合规性
• 客户服务自动化：多 Agent 协作处理开户咨询、账户查询、产品推荐等场景，复杂问题转接人工
• 量化研究辅助：Agent 调用代码解释器和数据分析工具，辅助研究员进行因子挖掘和回测

2. 医疗健康

• 临床决策支持：基于医学文献和指南的 RAG 系统，为医生提供循证医学参考
• 病历智能整理：Agent 自动从非结构化病历中提取关键信息，结构化归档至电子病历系统
• 患者咨询服务：7×24 智能问答机器人，处理预约咨询、用药指导等常见问题
• 医学影像报告辅助：结合多模态模型，辅助放射科医生生成和审核影像报告

3. 法律服务

• 法律文书审查：Agent 自动审阅合同条款，识别潜在风险和不利条款
• 案例检索与分析：基于向量检索的判例搜索系统，律师可快速找到相似案例和裁判观点
• 法律知识库问答：将法律法规和司法解释构建为 RAG 知识库，提供精准的法律咨询回答
• 诉讼策略辅助：综合分析案件事实、证据材料和法律规定，辅助律师制定诉讼策略

4. 通用企业场景

• 企业知识库问答：将企业内部文档（Wiki、手册、FAQ）构建为 RAG 系统，员工随时提问获取准确信息
• 智能客服工单处理：多 Agent 协作完成工单分类、自动回复、升级流转等全流程
• 代码开发辅助：Agent 理解项目代码库，辅助开发者完成代码生成、审查和调试
• 运营自动化：Fleet 功能支持将日常重复性任务（调研、跟进、状态检查）自动化为 recurring agent