Agent学习笔记 - 技术栈

学习笔记

1. SSE场景，优先使用原生 fetch，为什么不用axios呢？他们有什么不同导致他们使用场景有巨大区别。

一般企业项目才用axios，因为他有几大优势而fetch 有缺陷：

fetch 只有网络失败才 reject；HTTP 400/500 不会抛异常 ；axios 默认：只要状态码不在 2xx 区间，直接 reject，自动进入 catch，统一错误处理非常方便。
fetch 没有请求 / 响应拦截器，项目通用需求：请求前自动带上 token；响应统一处理：401 未登录自动跳登录页、500 统一提示。axios 原生支持 interceptors.request / interceptors.response。fetch 想要拦截，你只能自己封装一层函数，每次调用都走这个封装函数，手写一遍拦截逻辑。
缺少常用便捷能力：fetch没有请求取消（AbortController 可以实现，但代码写起来繁琐）；axios 自带 cancelToken / AbortController 封装；fetch 不自带超时控制，需要手动套 Promise.race；axios 直接配置 timeout:5000；fetch 上传进度监听麻烦；axios 简单 onUploadProgress；重复请求取消：axios 很容易封装，fetch 要自己维护请求池
数据序列化
fetch POST 请求：必须手动 JSON.stringify(body) + 手动设置 Content-Type: application/json；axios：传 JS 对象，自动序列化 + 自动加请求头

bash 复制代码

// fetch
fetch(url, {
  method: "POST",
  headers: {"Content-Type":"application/json"},
  body: JSON.stringify({name:"test"})
})

// axios
axios.post(url, {name:"test"}) // 一行搞定

那什么时候可以直接用 fetch？

简单小项目、demo、个人玩具项目，接口数量很少
SSE、流式场景：axios 处理流式反而麻烦（因为 axios 对流式 chunk 读取体验一般） 。前端调用流式接口，用原生 fetch + ReadableStream 读取后端 SSE 流非常合适。
不想引入额外第三方包，减少打包体积

2.为什么FAQ 不用SQL来查做相似度匹配如SQL LIKE '%退货%'，而用Embeddings？

LIKE 只能匹配字面，用户问"东西不想要了怎么办"匹配不到"退货政策"
向量检索看语义，"不想要了"和"退货"在 embedding 空间里距离很近，照样能命中
政策类问题表达多样，模糊匹配比精确匹配更符合客服场景

3.langchain_core高频子集使用：

langchain_core/

├── messages/ # 消息对象：HumanMessage/AIMessage/SystemMessage（高频）

├── language_models/ # BaseChatModel、BaseLLM（你写自定义LLM，高频）

├── outputs/ # ChatResult、ChatGeneration，模型返回结果结构（高频）

├── runnables/ # Runnable, RunnableLambda, RunnablePassthrough（LCEL编排，高频）

├── prompts/ # ChatPromptTemplate 提示词模板（高频）

├── retrievers/ # BaseRetriever 检索器基类（RAG知识库，高频）

├── documents/ # Document 文档对象，向量库返回的文档（高频）

└── tools/ # BaseTool 工具基类（做Agent的时候才用）