AI Agent 学习

很多人第一次给 Agent 加“定时任务”能力，直觉上会这样做： 用户说“明天早上 9 点提醒我写周报” 服务端解析出一个时间 到点后调用一段固定逻辑 这套思路并不完全错，但它只适合“预先写死的动作”

学完 LangChain 第一阶段之后，如果你脑子里留下的只是 ChatModel、PromptTemplate、OutputParser、tool、memory、RAG、LCEL 这些 API 名字

很多人第一次学 LangChain 的 LCEL，都会有一个共同感受：概念不难，但很难判断它到底该用在什么地方。 因为从语法上看，LCEL 很像是在做一件很朴素的事： 把 PromptTemplate

很多开发者第一次接触 LangChain 的 LCEL 时，直觉都是一样的：这不就是把原来一段一段的调用，换成了 pipe 和 Runnable 的写法吗？ 如果只是做一个“用户提问 -> Promp

很多人第一次学 LangChain 的 LCEL，都会有一个共同感受：概念不难，但很难判断它到底该用在什么地方。 因为从语法上看，LCEL 很像是在做一件很朴素的事： 把 PromptTemplate

很多人第一次接触 LangChain，会把它理解成一组“帮你调模型”的工具类：PromptTemplate 负责拼 prompt，ChatOpenAI 负责调模型，OutputParser 负责解析结

做 RAG 或 Agent 项目时，很多人最早写出来的代码都差不多： 系统提示词一段 用户问题一段 检索结果一段 历史对话一段 最后拼成一个超长字符串发给模型 Demo 阶段这么写没有问题，甚至是最快

很多团队第一次做 AI 应用时，都会把“结构化输出”理解成一个很小的实现细节：无非就是让模型别返回大段自然语言，改成 JSON 就行了。 这个理解太浅了。 在真实系统里，结构化输出解决的不是“格式好不

很多团队第一次做 LLM 应用时，都会写出这样一段代码：在 prompt 里补一句“请返回 JSON”，然后在代码里 JSON.parse() 一把梭。它在 demo 阶段通常能跑，但一进真实业务，很

很多人一开始做聊天机器人、RAG 助手或者 Agent，都会把 Memory 理解成一件很朴素的事：把用户和模型的对话一条条存起来，下次继续带上就行。 这个理解不算错，但只对了一半。 真正到了工程落地

很多人第一次接触 RAG，最容易形成一种错觉：只要把文档切块、算向量、丢进向量数据库，再接一个大模型，事情就结束了。 但真正做过项目的人通常很快会发现，问题并不在“能不能把向量存进去”，而在于这条链路

一个被忽视的问题：MySQL 解决不了的语义检索 假设你在做一个 AI 日记本应用，用户问："我哪几天的日记心情比较好？" 如果你把日记存在 MySQL 里，你会怎么查？SELECT * FROM d

很多人在刚接触 RAG 时，注意力都会集中在向量数据库、Embedding 模型和相似度检索上。这当然没错，因为这些组件直接决定了“问的时候能不能找到资料”。 但如果你真的开始做一个能落地的知识库系统

很多刚接触大模型应用开发的同学，都会先遇到一个非常现实的问题：模型看起来很聪明，但一旦问题超出训练语料，或者涉及企业内部文档、最新业务规则、私有知识库，它就开始一本正经地胡说八道。 这不是模型“故意骗