拿到数据后模型会意识到：“好的，查到了5篇文章，现在我需要逐一修改标题。” 于是它可Neng会 发起调用，这次是调用 update_blog_title。这个过程会循环，直到所有任务完成，Zui后模型才会用自然语言告诉你：“Yi经搞定了共修改了5篇文章。”

这就是Tool Use的精髓：模型负责逻辑判断，你负责具体执行。 查询逻辑不再是你写死的，而是由模型动态决定的。这非常适合处理那些用户意图模糊、需要灵活判断的场景。

除了操作数据，模型还经常面临“知识盲区”的问题。比如你问它：“我公司上周的代码提交记录里哪个模块BugZui多？” 模型肯定不知道，因为它连你的内网dou上不了。

这时候就需要 RAG。简单说就是你去查资料，然后把资料塞给模型，让它基于资料回答。

Ru果数据量不大，比如几十条记录，Zui简单粗暴的方法就是直接查出来拼在Prompt里。

export async function analyzeBlogs {
  // 第一步：你来查数据库
  const blogs = await db.query(`
    SELECT title, views, avg_read_time, bounce_rate
    FROM blogs
    WHERE user_id = ? AND created_at> NOW - INTERVAL 30 DAY
    ORDER BY views DESC
    LIMIT 10
  `, )
  // 第二步：把数据拼进 prompt，告诉模型
  const response = await client.messages.create({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 1024,
    messages: .embedding,
      metadata: { title: blog.title, content: blog.content }
    })
  }
}
// 查询阶段
async function ragQuery {
  // 1. 把用户问题也转成向量
  const questionEmbedding = await openai.embeddings.create({
    model: 'text-embedding-3-small',
    input: userQuestion
  })
  // 2. 找Zui相似的 5 篇文章
  const relatedBlogs = await vectorDB.search(
    questionEmbedding.data.embedding,
    { topK: 5 }
  )
  // 3. 把召回的文章内容注入 prompt
  const context = relatedBlogs.map.join
  const response = await client.messages.create({
    messages: 
  })
  return response.content.text
}

这里有个选择难题：是用直接注入还是向量检索？

直接注入： 简单，精准，但费Token，适合数据量小。

向量检索： 省Token，适合海量数据，但依赖检索质量，可Neng会漏掉关键信息。

我的建议是：先简单，后复杂。 一开始别上来就搞向量库，先试试直接注入，等遇到性Neng瓶颈了再升级架构。

Zui后我们来聊聊用户体验。Ru果模型生成一篇1000字的文章，需要等10秒钟，然后一次性把所有字显示出来这种体验在现代Web应用中是完全不可接受的。

用户需要的是“打字机效果”——模型写出一个字，前端就显示一个字。这就需要用到流式传输。

在代码层面这通常通过 Server-Sent Events 来实现。后端不再返回一个完整的 JSON，而是保持连接开放，不断推送数据片段。

// 后端流式处理示例
async function streamResponse {
  const stream = await client.messages.stream({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 1024,
    messages: 
  })
  for await  {
    if  {
      // 每一个字dou实时推送给前端
      process.stdout.write
    }
  }
}

前端拿到这些数据流，就Ke以实时geng新UI。这种即时反馈感，是AI应用区别于传统Web应用的重要特征，Neng极大地提升用户的“体感”速度。

回过头来kan，为什么我们要强调“模型是无状态函数”？

因为理解了这一点，你就Neng清晰地划分边界：

模型层： 只负责推理和生成。它是无状态的、被动的、昂贵的计算资源。

应用层： 负责状态管理、数据存储、工具调度、权限控制。这是你的地盘，你说了算。

不要试图把业务逻辑塞进Prompt里也不要指望模型Neng自动记住什么。所有的“智Neng”交互，本质上dou是你的代码在精心编排每一次请求的输入和输出。

无论是 LangChain 还是 LlamaIndex，这些框架Zui终帮我们封装的无非就是这几件事：历史记录的管理、Tool Use 的循环调用、RAG 的检索流程。但Ru果你Neng理解底层的这些原理，你就不会被框架束缚，遇到问题时也Neng一眼kan穿本质。

所以下次当你面对一个需求时先别急着写Prompt。先问问自己：这个需求中，哪些是模型该Zuo的，哪些是我该Zuo的？把这个问题想清楚了你的LLM应用开发之路就走稳了一半。