在大模型应用刚开始流行的时候，很多人对智能体的理解还停留在“给它一段提示词，它就会按照要求完成任务”。你是一个订单客服助手，只能回答订单、物流、退款相关的问题。看起来这已经足够明确了。模型知道自己是谁，也知道自己应该做什么。可问题在于，大模型并不是传统意义上的程序，它不会像if-else一样严格执行每一条规则。它面对的是自然语言，而自然语言里既有正常问题，也可能夹杂着新的指令、诱导、伪装甚至攻击。

最近在看 Agent 相关项目时，我发现一个挺容易被忽略的问题：很多人提到Agent 记忆，第一反应就是“把用户说过的话存下来”。这个想法很自然。毕竟对于一个能持续对话的 Agent 来说，如果它上一轮刚问完用户订单信息，下一轮就忘了用户在说哪件商品，体验一定很差。于是我们很容易继续往下想：既然要记住，那是不是把聊天记录全部存起来就行？再进一步，是不是直接丢进向量库，后面需要的时候检索出来？但真实

很多人第一次接触 Agent 时，都会有一个很自然的期待：既然它能自己规划任务、调用工具、读取文件、执行命令，那它做错了之后，是不是也能像人一样自己发现问题，然后自己改回来？比如让 Agent 写一段代码，它第一次生成的版本跑不通；让它调用一个接口，它传错了参数；让它整理一份资料，它漏掉了关键约束。这个时候，我们往往会补一句：“你再检查一下。神奇的是，很多时候它真的能改。它会重新阅读报错信息，重新

做RAG系统时，很多人都会遇到一个很反直觉的问题：检索器明明已经把相关文档找出来了，最后生成的答案却还是不对。一开始，我们很容易把问题归因到检索本身。是不是embedding模型不够好？是不是chunk size切得不合理？是不是topK太小？是不是应该再加一层reranker？这些方向当然都有价值，但它们默认了一个前提：只要相关文档被召回，后面的LLM就能稳定地读懂它、筛选它，并把它转化成正确答

这两年只要聊大模型应用，RAG几乎是绕不开的话题。最早大家理解RAG，通常是把它看成一个“给大模型外挂知识库”的方案：用户提出问题之后，系统先去知识库里检索相关内容，再把检索结果和用户问题一起塞进Prompt，最后让大模型基于这些材料生成回答。这个理解没有错，但它只解释了最基础的。在很多早期场景里，这套方案已经足够好用。比如产品文档问答、接口说明查询、企业制度检索、FAQ 客服机器人，本质上都是把

很多人第一次接触大模型时，会误以为它“天然”就会查天气、调数据库、发消息、调用接口。大模型原生只会生成内容，它并不会真的执行工具。所谓Tool Calling，本质上是开发者在模型外部，为模型接上了“感知世界和操作系统”的手脚。这篇文章的核心不是教语法，而是让读者产生一个认知：只会Prompt，本质上是在“调模型”；会Tool Calling，才是在“构建系统”。

这两年聊 Agent 开发，很多人第一反应还是把 Prompt 写好就行了。这也正常。同一个问题，换一种问法，答案质量可能完全不一样。于是大家开始研究怎么写提示词，怎么设定角色，怎么约束输出格式，怎么让模型少跑偏。但我最近越来越觉得，Agent 开发真正难的地方，已经不在“怎么把 Prompt 写漂亮”了。因为一旦任务从“回答一个问题”变成“完成一件事情”，问题的性质就变了。比如让模型解释一段代码

最近在做一个 agent 项目，里面有一块是知识库语义检索，底层用的是pgvector。数据库里明明有数据，SQL 里也没加额外过滤条件，只是多了一个 ORDER BY distance LIMIT k，查询结果居然直接变成空数组了。更离谱的是，这个问题还不是稳定复现的。同样一套代码：query = “重启” ，能查出来query = “你好，怎么用知识库检索？” ，查不出来，直接返回 []当时我

如果有上亿用户，怎么设计一个实时排行榜？这个问题看起来很常规，很多人的第一反应应该都是 Redis ZSet。一个成员对应一个分数，按分数排序，查 Top N 也方便。但真要把这个答案拿到面试里讲，只说“用 Redis ZSet”肯定不够。为什么不用 MySQL 排序？ZSet 里数据太多怎么办？首页排行榜被高频访问，会不会出现热 key？Redis 挂了之后，榜单数据怎么恢复？新发布的内容怎么和

假设我们有一张订单表，里面已经有 1000 万条数据。SELECT *从语义上看，这条 SQL 很简单：按照id排序，从第 1000000 条之后开始，取 20 条数据。但问题也出在这里。很多人第一次看到这条 SQL 时，容易下意识觉得：既然最后只返回 20 条数据，那查询成本应该也只和这 20 条数据有关。可实际上，MySQL 并不是直接“跳到”第 1000000 条记录，然后取后面的 20 条