一、简历项目描述
按工作年限 × 目标岗位方向，找到对应的组合直接使用。
── 1-3 年 / 初中级前端 ──
【纯前端方向】
极速购 AI 智能客服系统
技术栈：Vue3 · Composition API · SSE 流式输出 · Node.js · LangChain.js
参与开发电商 AI 客服系统前端模块，独立完成对话界面、Agent 状态展示、知识库问答等四个功能页面。
- 使用 Vue3 Composition API 封装 useChat、useAgent、useRag、useGraph 四个 Composable，将流式对话、SSE 解析、历史管理等逻辑与视图层完全解耦，组件代码量减少约 60%
- 实现基于 Fetch API + ReadableStream 的 SSE 流式消费，逐字渲染 AI 回复，同时处理 content / step / answer / done 四种事件类型，用户等待感知提升明显
- 在 Agent 页面实时展示工具调用中间步骤（调用工具名 + 参数 + 结果），让用户看到 AI 的思考过程，交互体验区别于普通对话产品
- 使用 vue-router 实现四页面单页应用，抽离全局导航组件，统一页面切换逻辑
【全栈方向】
极速购 AI 智能客服系统
技术栈：Vue3 · Node.js · Express · LangChain.js · DeepSeek API · PostgreSQL
独立完成电商 AI 客服系统前后端开发，涵盖基础对话、订单查询 Agent、知识库问答三个核心模块。
- 后端使用 Express + LangChain.js 搭建 AI 服务层，封装 DeepSeek API 调用，基于 LCEL 管道语法（prompt | model | parser）实现可复用的对话 Chain，支持流式 SSE 输出
- 实现 ReAct Agent，定义订单查询、物流跟踪、用户订单列表三个 Tool，使用 zod 规范参数 Schema，Agent 可根据用户意图自动选择工具并多轮调用，最终返回自然语言结果
- 搭建 RAG 知识库问答系统：使用 RecursiveCharacterTextSplitter 切分商品手册和售后政策文档，通过智谱 AI Embedding API 向量化后存入 pgvector，实现语义检索问答
- 前端使用 Vue3 Composition API 封装对话逻辑，实时展示 Agent 工具调用步骤和 RAG 引用来源
【AI 应用开发方向】
极速购 AI 智能客服系统
技术栈：LangChain.js · LangGraph · RAG · pgvector · DeepSeek API · Vue3 · Node.js
基于 LangChain.js 从零构建电商 AI 客服系统，完整实践 LLM 应用开发全流程。
- 掌握 LangChain.js 核心抽象：ChatPromptTemplate 管理提示词模板，LCEL 管道串联 Prompt / Model / Parser，ChatOpenAI 统一对接 DeepSeek / 智谱 AI 等国内模型
- 实现 ReAct Agent + Function Calling：用 tool() 定义工具，AgentExecutor 驱动 Thought → Action → Observation 循环，returnIntermediateSteps 暴露推理链路给前端展示
- 完成完整 RAG 流程：文档加载 → RecursiveCharacterTextSplitter 切分（chunkSize 500 / overlap 50）→ Embedding 向量化 → pgvector 存储 → 相似度检索（Top-K = 4）→ 上下文注入 → LLM 生成回答
- 使用 LangGraph 构建多 Agent 工作流：StateGraph 定义节点和边，addConditionalEdges 实现意图路由，streamMode: updates 流式推送节点执行状态
── 3-5 年 / 中高级前端 ──
【纯前端方向】
极速购 AI 智能客服系统
技术栈：Vue3 · Composition API · TypeScript · SSE · LangChain.js · Node.js
主导前端架构设计与开发，将 AI 能力以工程化方式集成到 Vue3 应用中。
- 设计四层前端架构：视图层（View）/ 逻辑层（Composable）/ 通信层（SSE fetch）/ 类型层（接口约定），各层职责清晰，新增功能页只需实现对应 Composable 即可复用通信和状态管理逻辑
- 封装统一的 SSE 消费模型，处理后端分类型推送（node / step / sources / answer / done / error），通过事件类型驱动前端状态机更新，避免多个 if-else 造成的状态混乱
- 实现 Agent 推理过程可视化：实时渲染工作流节点轨迹（意图识别 → 订单查询 → 整理回答），展示工具调用参数和执行结果，将 AI 黑盒变成可观测的透明过程
- 对接 LangGraph 多 Agent 工作流，前端按节点事件驱动 UI 更新，做到节点级别的加载状态和错误处理，用户体验细腻
【全栈方向】
极速购 AI 智能客服系统
技术栈：Vue3 · Node.js · Express · LangChain.js · LangGraph · RAG · pgvector · DeepSeek API
主导系统全栈设计与实现，从 AI 服务层架构设计到前端交互体验，独立完成全链路开发。
- 设计分层后端架构：models 层（模型封装）/ prompts 层（模板管理）/ chains 层（LCEL 流程）/ tools 层（工具定义）/ agents 层（Agent 实例）/ graphs 层（LangGraph 工作流）/ routes 层（HTTP 接口），职责清晰，横向扩展成本低
- 封装 createModel 工厂函数统一管理模型实例，通过替换 baseURL 和 apiKey 实现 DeepSeek / 智谱 AI / 百炼等国内模型的无缝切换，业务代码零改动
- 基于 LangGraph StateGraph 构建多 Agent 中枢：意图识别节点 → 条件路由 → 三条并行路径（订单 Agent / RAG 节点 / 通用对话）→ 答案综合节点，通过 addConditionalEdges 实现动态分流，系统扩展新意图只需添加节点和边
- RAG 链路全自研：文档切分策略调优（chunkSize / overlap 参数选择依据）、pgvector 向量表设计、检索 Top-K 选择、Prompt 防幻觉指令设计，系统能准确识别知识库外的问题并如实告知
【AI 应用开发方向】
极速购 AI 智能客服系统
技术栈：LangChain.js · LangGraph · RAG · Function Calling · pgvector · DeepSeek · Vue3 · Node.js
主导设计并实现完整的 AI 全栈应用，系统覆盖 LLM 应用开发的四个核心能力层。
- 基础层：基于 LCEL 实现流式对话 Chain，ChatPromptTemplate 管理 System / History / Human 三段式 Prompt，StringOutputParser 提取输出，全链路 SSE 流式推送
- 工具层：ReAct Agent 驱动 Function Calling，tool() + zod schema 定义工具，temperature=0 保证工具参数格式精确，AgentExecutor 暴露中间步骤供前端实时展示
- 知识层：完整 RAG 流程，RecursiveCharacterTextSplitter 文档切分，pgvector 向量存储，RunnableSequence 组装检索 + 生成流程，ragChainWithSources 返回答案来源引用
- 编排层：LangGraph StateGraph 多 Agent 工作流，Annotation.Root 定义共享状态，条件边实现意图路由，stream updates 模式流式推送节点执行状态，前端可视化工作流轨迹
── 5 年以上 / 高级资深前端 ──
【纯前端方向】
极速购 AI 智能客服系统
技术栈：Vue3 · Composition API · LangChain.js · LangGraph · SSE · Node.js
主导 AI 客服系统前端架构设计，将 LLM 应用能力以工程化方式落地到 Vue3 生产环境。
- 建立 AI 前端分层架构范式：将 SSE 流解析、事件分发、状态驱动、视图渲染四个关注点完全分离，Composable 层处理所有 AI 交互逻辑，View 层只做声明式渲染，实现业务逻辑与框架无关的可迁移架构
- 针对 LangGraph 多 Agent 场景设计前端状态模型：消息列表 / 当前节点轨迹 / 工具调用步骤三个维度独立管理，每类 SSE 事件（node / steps / answer / done）对应精确的状态更新路径，彻底避免异步竞态问题
- 提炼 AI 对话类产品的通用前端交互模式：流式占位 → 逐步填充 → 最终固化，覆盖加载态 / 流式态 / 完成态 / 错误态四种状态，可作为团队 AI 产品开发的前端规范模板
- 主导模型无关性设计，前端通过统一 SSE 协议与后端解耦，后端切换 DeepSeek / Claude / 本地模型无需前端改动
【全栈方向】
极速购 AI 智能客服系统
技术栈：Vue3 · Node.js · Express · LangChain.js · LangGraph · RAG · pgvector · DeepSeek API
主导系统架构设计与全链路研发，构建可横向扩展的 AI 应用基础架构。
- 建立模型抽象层：createModel 工厂函数封装所有模型配置，利用 DeepSeek / 智谱 AI / 百炼对 OpenAI 协议的兼容性，实现国内模型零切换成本接入，推广到团队作为模型接入规范
- 设计 RAG 知识库工程化方案：文档切分策略（结构化文档 chunkSize 500 / overlap 50）、向量维度与存储结构设计、检索参数调优（Top-K / 相似度阈值）、Prompt 防幻觉设计（知识库无相关内容时明确告知），形成可复用的 RAG 落地方案
- 基于 LangGraph 设计多 Agent 编排架构：意图识别节点解耦路由逻辑，各处理节点职责单一（订单 Agent / RAG 节点 / 通用对话），answerSynthesizer 汇合结果，扩展新意图类型只需增加节点，对已有路径无侵入
- 设计前后端 SSE 协议规范：type 字段分类事件（node / steps / sources / answer / done / error），前端按事件类型驱动状态更新，协议版本可向后兼容，作为团队 AI 流式接口的设计标准
【AI 应用开发方向】
极速购 AI 智能客服系统
技术栈：LangChain.js · LangGraph · RAG · Function Calling · pgvector · DeepSeek API · Vue3 · Node.js
主导 AI 应用全栈架构设计，系统性落地 LLM 应用开发的核心技术栈，形成可复用的工程化方案。
- 建立 AI 服务分层架构：模型层（多模型统一接入）/ Prompt 层（模板管理与版本化）/ Chain 层（LCEL 组合逻辑）/ Agent 层（工具定义与执行）/ Graph 层（多 Agent 编排）/ API 层（SSE 流式接口），各层边界清晰，可独立测试和替换
- RAG 工程化落地：完整实践文档处理流水线（加载→切分→向量化→存储），调优 chunkSize / overlap / Top-K / 相似度阈值四个关键参数，设计 ragChainWithSources 返回引用来源，实现可解释的 AI 问答
- LangGraph 多 Agent 编排实践：StateGraph 建模业务流程，Annotation.Root 定义类型安全的共享状态，条件边实现意图路由，stream updates 模式实现节点级别的流式推送，前端可视化完整工作流轨迹
- 提炼国内模型接入最佳实践：利用 OpenAI 兼容协议对接 DeepSeek / 智谱 AI / 百炼，总结 Embedding 模型选型（智谱 embedding-3 / 百炼 text-embedding-v3），形成团队 AI 选型参考文档
── 架构师 / 技术负责人 ──
【技术负责人 / 架构师方向】
极速购 AI 智能客服系统
技术栈：LangChain.js · LangGraph · RAG · Function Calling · pgvector · Vue3 · Node.js · Docker
主导 AI 客服中台从 0 到 1 的技术选型、架构设计与落地，建立团队 AI 应用开发规范。
- 完成技术选型与可行性验证：评估 LangChain.js vs 直接调用 API 的工程化成本，确定 LangGraph 替代 AgentExecutor 的适用边界（单工具链用 AgentExecutor，多意图分支用 LangGraph），输出团队技术选型文档
- 设计六层 AI 服务架构（模型层 / Prompt 层 / Chain 层 / Agent 层 / Graph 层 / API 层），制定各层接口规范和扩展约定，新增业务模块只需遵循规范添加节点，对已有架构零侵入
- 建立 RAG 知识库工程规范：文档分类策略、切分参数标准、向量存储表结构设计、检索参数调优方法论、防幻觉 Prompt 模板，形成团队可复用的 RAG 落地手册
- 主导 AI 前后端协议设计：SSE 分类型事件协议（支持流式内容 / 节点状态 / 工具步骤 / 来源引用四类信息），协议设计与具体 AI 框架解耦，后端切换底层模型或框架时前端接口不变
- 搭建本地开发环境标准化方案：Docker Compose 管理 pgvector 依赖，.env.example 规范化配置管理，pnpm ingest 脚本化知识库入库，新成员 30 分钟内完成环境搭建
二、技术亮点提炼
以下是面试中可以重点展开的五个技术亮点，每个亮点附有能说明深度的关键细节。
亮点一：LCEL 管道设计
不是简单调用 API，而是通过 prompt | model | parser 组合式设计实现关注点分离。Prompt 模板化管理，输出解析器统一处理，Chain 可任意组合复用。核心价值是把 AI 调用变成可测试、可替换的工程化组件。
亮点二：Function Calling 的工具设计
工具的 description 写法直接决定 LLM 的工具选择准确率，不只是"描述功能"，更要说明"什么场景下调用"。zod schema 的 .describe() 字段给 LLM 提供参数格式示例，Agent 场景 temperature 固定 0 保证格式准确，returnIntermediateSteps 暴露推理链路实现可观测性。
亮点三：RAG 的工程化细节
不只是"接入向量数据库"，而是完整的工程化决策：chunkSize 选 500 的依据（结构化文档保留完整语义）、overlap 50 防语义断裂、Top-K = 4 的平衡点、防幻觉 Prompt 指令设计、ragChainWithSources 引用来源增加可信度。
亮点四：LangGraph 的架构价值
能说清楚什么时候用 AgentExecutor、什么时候用 LangGraph：前者适合单线任务，后者适合多意图分支、多模块协作、中间状态传递的复杂场景。StateGraph 的节点职责单一原则，条件边实现路由解耦，扩展性体现在新增意图类型只需加节点加边。
亮点五：SSE 流式架构设计
后端不是简单 res.write，而是设计了 type 字段的分类型事件协议，前端按事件类型精确驱动状态更新。这个协议与具体 AI 框架解耦，后端换模型前端不用改，体现了接口设计的前瞻性。
三、面试高频问题 + 标准回答 SOP
Q1：介绍一下这个项目
回答结构：背景 → 架构 → 我的职责 → 技术亮点 → 结果
这是一个电商 AI 客服系统，基于 LangChain.js + Vue3 + Node.js 全栈开发。系统分四个能力层：基础流式对话、Agent 订单查询、RAG 知识库问答、LangGraph 多 Agent 编排。
我负责整个系统的设计和开发，核心工作是把 LLM 的能力工程化地落地到生产可用的服务里。前端用 Vue3 Composition API 封装了四个 Composable 处理不同的 AI 交互逻辑，后端按照模型层、Prompt 层、Chain 层、Agent 层、Graph 层分层设计，职责清晰，扩展方便。
技术上有几个我觉得比较有价值的点：RAG 流程的完整工程化实践、LangGraph 多 Agent 的编排设计，以及一套前后端 SSE 分类型事件协议，让 AI 的中间推理过程对前端完全透明。
Q2：RAG 是怎么做的，怎么保证回答质量？
回答结构：流程 → 关键参数决策 → 质量保障措施
RAG 分两个阶段。离线阶段是入库：用 RecursiveCharacterTextSplitter 切分文档，chunkSize 选 500 是因为我们的文档是结构化的商品手册和政策条款，每条规则在 500 字以内能保持语义完整，overlap 50 防止内容在边界处被切断。切好之后用智谱 AI 的 embedding-3 模型向量化，存到 pgvector。
在线阶段是检索 + 生成：用户问题向量化后做余弦相似度检索，返回 Top-4 片段，拼入 Prompt 让 LLM 基于检索内容回答。
质量保障做了两点：一是 Prompt 里明确写了"如果知识库没有相关内容，如实告知用户，不要编造"，防止 LLM 在检索内容不相关时仍然凭空生成答案；二是接口返回 sources 字段，前端展示引用来源，让回答有据可查，用户可以自己判断可信度。
进一步调优可以加相似度阈值过滤低质量检索结果，以及用重排序模型对 Top-10 结果再筛选 Top-4，但在当前规模下 Top-4 直接用效果已经够好。
Q3：Function Calling 是怎么实现的，LLM 怎么知道调哪个工具？
回答结构：原理 → 实现 → 踩坑经验
Function Calling 的本质是：把工具的名称、描述、参数结构格式化成 JSON Schema 附在请求里一起发给 LLM，LLM 判断当前问题需要哪个工具，返回一个结构化的调用指令（工具名 + 参数），由外部代码执行后把结果传回，LLM 再基于结果给出最终回答。
LLM 选择工具的依据完全是 description 字段，所以我在写工具描述时特别注意两点：一是说清楚什么问题应该触发这个工具，比如 getOrderInfo 的描述写的是"当用户询问订单状态、订单内容时调用"，而不只是"查询订单"；二是在 zod schema 的 .describe() 里给出参数格式示例，比如"订单号，格式为 ORD-xxx，例如 ORD-001"，避免 LLM 传错格式。
踩过的坑：temperature 设高了之后 LLM 会在工具参数格式上犯错，比如把字符串传成对象，所以 Agent 场景 temperature 固定设 0。另外工具返回值体积要控制，返回整个用户订单列表的话 Token 消耗会很高，实际做了摘要处理，只返回关键字段。
Q4：LangGraph 和直接用 AgentExecutor 有什么区别，为什么要用它？
回答结构：对比 → 适用场景 → 本项目选择理由
AgentExecutor 是线性的：LLM 想一想，选个工具，执行，再想一想，直到给出最终答案。适合工具数量少、目标单一的场景，比如"查一个订单"这种任务。
LangGraph 是图结构：每个节点是一个独立的处理单元，节点之间通过边连接，可以分支、汇合，节点间通过共享 State 传递数据。适合有分支逻辑、多模块协作、中间状态需要传递的场景。
我选 LangGraph 是因为客服场景的问题类型差异很大：有的要查订单数据，有的要查知识库，有的是闲聊。如果把所有工具和文档都丢给一个 AgentExecutor，工具列表会很长，LLM 决策质量明显下降，而且无法精确控制流程分支。
用 LangGraph 之后，意图识别是一个节点，订单查询是一个节点，RAG 是一个节点，条件边根据意图决定走哪条路，最后在汇合节点综合结果。每个节点职责单一，可以独立调试，扩展新的问题类型只需加节点加边，对已有逻辑没有任何影响。
Q5：流式输出是怎么做的，前端怎么处理的？
回答结构：后端实现 → 协议设计 → 前端消费
后端用 SSE（Server-Sent Events）实现流式推送。SSE 是基于 HTTP 的单向推送协议，服务端通过 Content-Type: text/event-stream 响应头建立长连接，然后持续 res.write() 推送数据，格式是 data: JSON\n\n。
我在协议上做了一个设计：用 type 字段区分不同类型的事件，而不是只推文本内容。具体有这几种：node 表示 LangGraph 某个节点开始执行，steps 表示工具调用中间步骤，sources 表示 RAG 检索到的来源，answer 是最终回答内容，done 表示结束，error 是错误信息。
前端用 Fetch API 的 ReadableStream 消费，循环读取 Uint8Array，TextDecoder 解码成字符串，按换行分割后解析每行 data 字段的 JSON，根据 type 字段更新对应的响应式状态。
这样设计的好处是前后端协议解耦，后端换底层模型或框架，只要保持 type 字段规范，前端一行代码不用改。
Q6：前端 Composable 是怎么设计的？
回答结构：设计思路 → 具体实现 → 解决了什么问题
我把四个功能页面的交互逻辑分别封装成 useChat、useAgent、useRag、useGraph 四个 Composable。
设计的核心原则是：Composable 只管数据和逻辑，View 只管渲染。每个 Composable 对外暴露响应式状态（messages、streaming、error 等）和操作方法（sendMessage、clearMessages），View 层声明式绑定这些状态，不包含任何 SSE 解析或状态管理的细节。
这样做有几个好处：View 组件代码量很少，逻辑和渲染分离方便独立测试，Composable 可以在多个页面复用，而且换 UI 框架的时候逻辑层不需要改动。
具体实现上，SSE 读取用 while(true) 循环 + reader.read()，每次读到数据就解析推送给对应的 ref，nextTick 之后触发滚动回调，保证 DOM 更新和滚动时机正确。
Q7：这个项目是你自己独立做的还是团队项目，遇到什么困难？
推荐回答方向
如果是个人项目，可以这样说：
这是我独立设计和开发的项目，目的是系统化掌握 LLM 应用开发的完整链路。遇到的主要困难有两个：一是 RAG 初版的检索质量不理想，排查后发现是入库和检索用了不同的 Embedding 模型，向量空间不一致导致相似度计算失效，统一之后明显改善；二是 LangGraph 在调试阶段中间状态不透明，后来把 verbose 打开并且在后端 console.log 关键节点的 State，结合前端展示的节点轨迹，才把调试效率提上来。
如果要往团队协作方向说，可以加：这套架构后续我在团队内做了分享，把模型封装、RAG 流程、SSE 协议设计抽象成了可复用的模板，团队其他同学在此基础上快速开发了另外两个 AI 功能模块，复用率比较高。
Q8：Token 超限怎么处理？上下文管理怎么做的？
回答结构：问题本质 → 方案 → 本项目实现
LLM 每次调用都是无状态的，多轮对话需要把历史消息全部传入，随着轮数增加 Token 消耗线性增长，超过上下文窗口就会报错，而且长上下文也会增加延迟和费用。
常见方案有三种：固定窗口截断（只保留最近 N 轮）、摘要压缩（用 LLM 把历史总结成摘要）、向量检索记忆（把历史存向量库，按相关性检索）。
本项目用的是最简单也最可靠的固定窗口：前端发请求时只传最近 10 条历史消息（通过 .slice(-10) 截断），后端接收后通过 formatHistory 转换成 LangChain 消息格式传入 Prompt。这对客服场景足够，因为用户的问题通常在几轮内能解决，不需要超长记忆。
如果上下文需求更复杂，比如用户在一次会话里问了十几个不相关的问题，可以引入 LangChain 的 ConversationSummaryMemory，用一个小模型实时压缩历史摘要，这是下一步可以扩展的方向。
Q9：如果让这个系统支持 10 万用户并发，你会怎么设计？
回答结构：当前架构的瓶颈 → 扩展方向 → 优先级
当前架构是单进程 Node.js 服务，瓶颈主要在三个地方：LLM API 调用本身的延迟（每次 2-5 秒）、每个 SSE 连接占用一个 HTTP 长连接、pgvector 查询在高并发下的吞吐量。
扩展方向按优先级：
首先是水平扩展后端服务，Node.js 是 I/O 密集型，用 PM2 集群模式或者容器化部署，多实例分担请求。
其次是 LLM 调用加请求队列，防止瞬时流量压垮 API 限额，队列里的任务可以配置优先级，会员用户优先处理。
然后是 Redis 缓存热点问题，对于重复度高的问题（比如"退货政策是什么"）缓存 RAG 检索结果和回答，避免重复调 Embedding API 和 LLM。
最后是 pgvector 读写分离，高频检索走只读副本，入库走主库，用连接池控制并发数。
SSE 连接方面，可以考虑在前面加一层 Nginx，用 upstream 做负载均衡，后端服务无状态，SSE 连接在哪个实例上都行。
Q10：为什么选 DeepSeek 而不是 GPT？
回答结构：技术角度 + 工程角度
有几个实际的考量：一是国内网络访问稳定性，OpenAI 在国内需要代理，生产环境有额外的运维复杂度；二是成本，DeepSeek 的价格约是 GPT-4o 的十分之一，在学习和原型阶段差异很显著；三是 DeepSeek 兼容 OpenAI 的 API 协议，在 LangChain.js 里只需替换 baseURL 和 apiKey 就能切换，业务代码完全不动。
这也是我在架构上做了模型无关性设计的原因——通过 createModel 工厂函数封装所有模型参数，如果将来需要换成 Claude 或者本地部署的 Qwen，改一个配置就行。实际上项目里的 Embedding 就用了两种模型：智谱 AI 的 embedding-3 和阿里百炼的 text-embedding-v3，切换时只需修改 embedding.js 里三个字段。
四、加分项补充说明
如果面试官问到"还有什么其他考虑"或者"后续怎么扩展"，可以抛出以下话题展示深度：
关于 Prompt Engineering：System Prompt 是控制 LLM 行为最重要的地方，我做了三件事：限定回答范围（只回答客服相关问题）、控制输出格式和长度、对知识库查询结果的处理方式（没有相关内容时如实告知）。好的 Prompt 能省掉很多代码级别的后处理。
关于可观测性：AI 应用最难调试的是中间过程不透明。我通过两个手段解决：后端 AgentExecutor 开 verbose 打印完整推理链路，前端 LangGraph 展示节点执行轨迹，让 AI 的每一步决策都可见，调试效率提升明显。
关于成本控制：Token 消耗直接影响线上成本，我在工具返回值上做了摘要处理，RAG 检索数量控制在 Top-4，对话历史窗口限制在 10 轮，这三个措施在实际使用中能把每次对话的 Token 消耗控制在合理范围。
关于扩展性：LangGraph 的节点化设计天然支持扩展，新增一个意图类型（比如商品推荐），只需写一个新节点、在路由函数里加一个分支、连一条边，不影响已有的订单查询和知识库逻辑，这是单体 AgentExecutor 方案做不到的。