无需任何AI和数学知识背景，手把手带你学会大模型应用开发(下篇)，小白也能轻松入门！

上篇

大模型用于实际业务发挥价值

前面举了联网搜索和查询天气的例子，它们都很简单，主要是为了阐明应用的开发流程，并没有发挥LLM更深入的能力。LLM真正的长处是它的理解、推理和对于问题的泛化能力，如果能把它运用到具体业务中，让它学习业务知识，则能发挥巨大的价值。 目前绝大多数对大模型的应用，都是在尝试**“教会”**大模型特定领域知识，再基于大模型的泛化推理能力，去解决一些实际问题。运用的最多的就是知识问答场景和编程助手，比如智能客服、wiki百事通、Copilot。

知识问答场景

在知识问答的场景中，一直有个非常棘手的问题，就是虽然积累了很多文档和案例，但是系统依然很难准确地基于这些内容回答用户的问题。为了更直观地让大家理解问题本身，举个简单的例子：

某足球俱乐部出售赛季套票，官方发文做出规定，限制套票的使用范围——只能夫妻双方使用（一个场次只能来一人）。 虽然官方写得清楚，但是规定文件一大篇，根本没人看。比赛当天，人工客服的电话就被打爆了：

• “喂，我的票我儿子能用吗”——不能
• “喂，我有事来不了，我的票我媳妇儿能用吗”——能
• “喂，我女朋友能用我的票吗”——不能
• ……

这些问题，人工客服回答起来简单，因为他学习了规定有推理能力，所以相关的问题都能回答。但是想做一个智能问答机器人可就不那么简单了。

接着上面的例子，虽然官方规定说了夫妻，但是用户问的是我媳妇儿，这两个词在字面上完全不一样，如果智能助手不能从语义上理解它们的关系，自然就无法给出正确的答案。而这种场景大模型就非常合适，因为它可以理解 规定中的内容而不是只做关键词匹配。比如我们可以这样：

你是一个智能客服系统，以下是我们公司的规定：

${具体规定原文}

你要充分理解上述规定内容，回答必须以规定中的内容为依据，必须要有章可循。除了给出答案，还需要给出你引用的原文部分
返回结构如下：
{"answer":"your answer","refer": "原文中相关描述"}

有了这样的提示词，大模型也知道了你的规定原文，就能够很轻易地回答用户后续的问题了。

比如，用户问：“我的票我女朋友能用吗？”，答：

{"answer": "不能", "refer":"只能夫妻双方使用（一个场次只能来一人）"}

这种做法似乎打开了新世界的大门，假如我把所有业务文档都通过Prompt发给它，那LLM岂不是瞬间成为了超级专家？！！

然而这在目前只是美好的理想罢了，当前的模型能力还无法支持。比如当下最火的deepseek-r1模型，最大支持128K token的上下文，大概就是约20万中文字符。但这不意味着20W以内的长度你就可以随便用，过长的内容会让响应显著变慢，以及生成的结果准确性大大降低等问题。这和人脑很像，太多东西输入进去，脑容量不够肯定记不全。输入得越少，学习和记忆效果越好；一次性给得越多，忘得越快。要深入理解这个问题，需要进一步学习LLM的底层原理，比如Transformer架构、注意力机制等等，这里不展开了。

针对上下文长度有限制这个问题，主流的解决方案就是——RAG(Retrieval-Augmented Generation)，检索增强生成

RAG的核心思路很简单：如果无法一次性给LLM喂太多知识，那就少喂点，根据用户的具体提问去找到和它最相关的知识，把这部分精选后的知识喂给LLM。

举例来说，用户问：“鲁迅家墙外有几棵树”？这时我们就没必要把鲁迅所有文章都发给LLM，只需要检索出和问题相关的内容，最终给到LLM这样的提示词：

这里的关键就是，应用程序要提前根据用户问题，对海量材料进行过滤，把最相关的内容截取出来发给大模型。这种方法就是我们经常在各种技术方案中看到的：RAG (Retrieval-Augmented Generation)，检索增强生成技术。名如其意，通过检索出和问题相关的内容，来辅助增强生成答案的准确性。

RAG需要注意两个问题：

• 检索结果 和 解答问题需要参考的资料 越相关，生成结果越准确
• 检索出过多的内容，又会引入更多的噪声，影响LLM注意力，增加幻觉风险，生成的质量反而降低

那怎么样才能根据用户的提问，高效而准确地找到和问题相关的知识呢？——这就进入到非AI相关背景的开发者比较陌生的领域了。但不用担心，我会用最简单的方式帮大家做个梳理，帮助大家了解整体原理，并不会深入具体的细节原理。

做过滤，最简单的也是我们最熟悉的，可以用搜索引擎进行关键词搜索过滤。这种做法虽然可以**“过滤”**，但是效果却不会很好。一些显而易见的原因，包括但不限于：

• 过滤后的内容可能依然非常多，还不够精简
• 关键词过滤可能把同义词给漏掉了（妻子->老婆），导致真正有价值的文档被忽略

这种办法就不展开了，基本也很少用，或者是和别的方法一起联合使用。

为了尽可能准确地找到和原始问题相关的内容，我们需要某种程度上尽可能 理解原问题的语义。但你可能越想越不对劲。我不就是正因为 用户的语义不好理解，才要借助大模型的吗……现在倒好，要我先把和问题相关的内容检索出来再提供给大模型。为了检索和问题相关的内容，我不得先理解问题的语义吗，圈圈绕绕又回来了？感觉是典型的鸡生蛋蛋生鸡问题啊…

有这个困惑很正常，解决困惑最直接的回答就是——语义理解并不是只有大模型才能做（只是它效果最好）。在大模型出来之前，AI领域在这个方向上已经发展了很多年了，通过深度神经网络训练出了很多模型，有比较成熟的解决方案。

点击领取：2025最新最全AI大模型资料包：学习路线+书籍+视频+实战+案例…

Embedding&向量相似度检索

老婆和妻子这两个词在面上完全不同，我们人类是怎么理解它们其实是一个意思的呢？又是怎么理解 老子这个词在不同的上下文中 意思完全不同呢？我们的大脑中是怎么进行思维判断的，对这些词的理解，在大脑中是以什么形式存储的呢？ 这个问题在当下并没有非常深入的答案，科学家对此的研究成果只能告诉我们，记忆和理解在大脑中涉及到多个不同脑区域的协同，比如海马体、大脑皮层和神经突触。但具体是如何存储的，还有很长的研究路程要走。

但是，我们训练出的神经网络，倒是可以给出它对于这些词语的理解的具体表示。比如，输入一个词语老婆，神经网络模型对它的理解是一个很长的数组：[0.2, 0.7, 0.5, ...]。我们用[x,y]表示二维坐标，[x,y,z]三维坐标，而模型这长长的输出，则可以理解为是n维坐标，我们也称之为 高维向量。就像人类无法理解3维以外的世界，所以你也不用尝试理解模型输出的高维向量是啥含义，神经网络模型能理解就行。

但我们可以做出一些重要假设：

• 语义越相似的文本，在向量空间中的位置越相近
• 语义差异越大，在向量空间中的距离越远

基于这种假设，我们可以通过数学上的向量计算，来判断向量的相似度（在训练模型时主要也是通过这种方式来评判效果，最终让模型的输出尽量满足上述两个假设）。比如，我们可以计算出不同向量的欧拉距离，来判断语义的相似性。除了欧拉距离还有很多其它距离，如余弦距离等等，这里就不展开了。

向量相似度检索 就是基于这种方式，使用训练好的神经网络模型去“理解”文本，得到对应的高维向量。再通过数学上的相似度计算，来判断文本之间的语义相关性。 我们可以把 ”模型理解文本“ 这个过程看成是一个函数:

func convert(word string) -> []float32

基于这个函数，我们就可以分别得到老婆、妻子、抽烟等任意文本的高维向量表示。然后计算它们向量的距离，距离越近，代表它们的语义就越相近，反之则语义差距越大。

至于如何训练神经网络让它的语义理解能力更强，这就是这么多年来AI领域一直在做的事情，有一定学习门槛，感兴趣再看。不同模型有不同的使用场景，有的适合文本语义理解，有的适合图片。通过模型把各种内容（词、句子、图片、whatever）转化成高维向量 的过程，我们称为 Embedding（嵌入）。

但是，和LLM有上下文长度限制一样，使用模型进行Embedding时，对输入的有长度也是有限制的。我们不能直接把一篇文章扔给模型做Embedding。通常需要对内容进行一定的切分（Chunk），比如按照段落或者按照句子进行Chunk（关于Chunk后文再展开）。

当把文档按如上流程Embedding之后，我们就可以得到这篇文档的向量表示[[..], [..], [..]]。进一步，我们可以把它们存储到向量数据库。对于一个给定的待搜索文本，我们就可以把它以用样的方式进行Embedding， 然后在向量数据库中执行相关性查找，这样可以快速找到它语义相近的文本。

向量数据库

从上面你就可以看到，向量数据库其实和我们平时使用的数据库有挺大的差别。我们平时使用的mysql mongo等数据库，主要是做"相等性"查找。而向量数据库的场景中，只会去按向量的相似性进行查找。可以把向量数据库的查询场景进一步简化方便大家理解：在3维坐标系中有很多点，现在给定一个点，怎么快速找出离这个点最近的N个点。向量查询就是在N维空间中找最近点。这种场景的查找和我们平时使用的DB基于树的查找有很大区别，它们底层不论存储的数据结构、计算方式还是索引方式的实现都不一样。

因此，随着RAG的火热，专门针对向量的数据库也如雨后春笋般出现了。我们常用的数据库很多也开发了新的向量索引类型来支持对向量列的相似度查询。一个向量相似性查询的sql类似于：

SELECT [...]
FROM table, [...]
ORDER BY cosineDistance(向量列名, [0.1, 0.2, ...]) // 余弦距离
LIMIT N

新的专业向量数据库很多查询语句不是基于sql的，但是用法是类似的。对于向量数据库更多的内容就不展开了，它作为一个数据库，各种存储、分布式、索引等等的内容自然也少不了，并不比其他数据库简单。在本文中，大家理解VectorDB和其他DB的差异以及它能解决的问题就够了。但在实际项目中，我们就需要进一步学习不同vectorDB的特性，不同场景下使用什么距离计算效果更好，不同场景下使用什么索引效果更好，不同数据规模的查询性能，这样才能更好的地适配线上业务。

Chunk + Embedding + VectorDB = RAG

了解了embedding和vectorDB后，再回到之前的例子——开发一个 “鲁迅百事通” 问答机器人。 我们可以按照如下方法对鲁迅的文章进行预处理：

• 把所有文章按照自然段做切分，分别对个自然段进行Embedding，得到一系列向量
• 把这些向量以及文章相关信息，存入向量数据库 [ [文章id, 自然段编号, 向量], [...]]

在处理用户提问时，我们可以把用户的原始问题也进行Embedding，然后去VectorDB里做相似度查询，找到相关性最高的TopN（再映射出其对应的原文片段）——这个过程也叫召回。然后把这部分内容嵌入到prompt中向大模型提问，这样大模型就可以充分利用你提供的知识来进行推理并生成最终的回答。 应用程序最终发送给大模型的prompt就是类似如下的内容：

你是一个鲁迅百事通问答助手，结合以下给出的一些鲁迅文章的原文片段，回答用户的提问

${段落的原文1}
${段落的原文2}
${...N}

用户的问题是：鲁迅家门口有几棵树

这就是所谓的检索增强生成：通过 检索 ，拿到和问题相关内容，去 增强 prompt，从而 增强 大模型 生成 的回答质量—— RAG 完整的流程如下：

基于这样的流程，我们就可以开发一个鲁迅百事通 大模型问答系统，它可以回答关于鲁迅文章中的各种问题。只是，回答质量可能并不好，这又涉及到非常多的优化。

我们可以认为，一个问答系统的输出质量和以下两个因素正相关：

• RAG召回数据的质量（相关性）
• 大模型本身的推理理解能力

在这两个因素中，大模型本身的能力，一般是应用开发团队无法控制的，即使基座大模型能力暂时领先，随着开源模型的迭代进步，其它团队也会逐步追上。因此应用的开发团队的 核心工作 就应该是 提高检索召回内容的质量，这才是核心竞争力。

优化RAG的质量——应用开发时关注的重点

再回忆下之前我们对 知识内容 进行预处理的流程：

从这个流程可以看到，由于写入VectorDB后剩下的相似度检索是纯数学计算，因此决定召回数据质量的核心在写入DB之前：

• Chunk
• Embedding

Embedding前面说过了，它是非常关键的一个环节。如果你选用的模型能力差，它对于输入的内容理解程度不够，那基于它输出的向量去做相关性查询，效果肯定就不好。具体选择什么样的模型去做Embedding就是团队需要根据业务实际去尝试了，可以找开源的模型，也可以训练私有模型，也可以使用有些大语言模型提供的Embedding能力。这些方法各有优劣：

• 开源模型：
  • 优点：成本低，响应速度快，数据安全性高
  • 缺点：效果一般
• 训练自有模型：
  • 优点：效果好，响应速度快，数据安全性高
  • 缺点：训练成本极高（人力、显卡），团队技术储备要求高
• LLM Embedding：
  • 优点：效果好，使用简单
  • 缺点：响应速度慢，按量付费有持续成本，数据出境风险

要在Embedding这个方向去深入的话，尤其是对生成质量要求很高，很可能需要训练自有模型。如果是走这个方向，团队就需要有相关的人才储备，还需要结合业务数据的特点进行持续深入的研究。

除了Embedding以外，Chunk其实也是 非常非常重要 的。之前为了讲流程，我对Chunk几乎是一笔带过，但Chunk其实是非常关键的一环。举例来说，有如下两个对话：

敖丙：师傅，我要去救哪吒！
申公豹：你去…去…
（敖丙转身迅速离去）
申公豹：…了就别回来了

---

水蜜桃：十二金仙最后一个位置给你吧
申公豹：不……不
（低头抱拳作揖）
水蜜桃：不要算了
（转身离去）
申公豹：…胜感激

这是哪吒中的两个笑话，我们需要看完整个对话才能明白意思，上下文很关键。如果Chunk时是按单个句子进行切分，就会丢失关键的上下文，导致句子的意思完全被误解。为了解决这个问题，最直接的就是扩大切分范围，比如按照自然段来切分。但自然段的长度也不可控，遇到文章作者不喜欢分段，每个段落都很长怎么办？即使按段落切分了，依然会有问题：

• 只要有切分，就有相当概率会丢失一部分上下文，段与段间也有联系
• 更长的文本会包含更多的冗余信息，这会稀释关键信息的密度，进而影响Embedding的质量

也就是说，并不是切分的块越大越好，但越小的块又有更大的概率丢失上下文。因此，如何在尽量保证上下文语义的连贯性的同时，又能够让切分的块尽量的小，对Embedding的质量至关重要。而Embedding的质量又直接决定了RAG召回的质量。所以你可以看到，在向量检索这块，里面的门道非常多。需要团队投入相当大的精力去打磨和优化。

近期，公司内外都有大量的 知识库+LLM 类产品对外发布，原理就和我们例子中的鲁迅百事通是一样的，相信你现在也大概了解这类应用 大致 是如何构建出来的了。当然，除了和RAG相关的开发，知识库类产品还涉及到 如何准确解析不同格式的文档 的问题，比如怎么对任意网页对内容进行抓取，怎么解析文档中的图片（这对理解文档非常重要），怎么支持doc ppt pdf markdown等等类型的导入… 但最关键的点还是在于各个产品如何解决上述提到的的：Chunk 和 Embedding 这两个问题，这直接决定了回答的效果。

当然，只要能提高召回的质量，各个方向都可以优化。除了Chunk和Embedding这两大核心，召回策略上也会做很多优化。比如先使用向量相似度检索，快速获取候选集，再使用更复杂的模型对结果进行二次重排序…这里面的工程实践很多，做推荐算法的应该很熟悉，感兴趣可以自行研究。

代码助手

除了知识问答场景，**代码助手（Copilot）**也是应用非常广泛的一个领域。 和知识问答场景一样，Copilot也是 RAG + LLM 的典型应用。并且，Copilot的场景会比知识问答场景更加复杂。

Copilot要解决的问题其实可以看成 知识问答 的超集，它除了要能够回答用户对于代码的提问，还需要对用户即将编辑的代码进行预测进而实现自动补全，并且这个过程速度一定要快，否则用户会等得很没有耐心。

具体来讲，首先还是看Copilot的 知识问答 场景。前面我们已经知道，回答的准确度强依赖于RAG的数据召回质量。Copilot是无法一次性把所有代码丢给LLM去理解的，必须要针对用户的提问，高效地检索相关的代码片段。要做到这点，最核心就是前面提到的 Chunk 和 Embedding 。而这两个，处理代码和处理wiki文档，做法上的差异就巨大了。

我们可以看看现在最火的AI Editor [cursor]的做法（from cursor forum）：

1. 在你的本地把代码Chunk成小片段
2. 把小片段发送到cursor服务器，它们服务器调用接口来对代码片段进行Embedding（通过OpenAI的Embedding接口或者自己训练的神经网络模型）
3. 服务器会把Embedding的向量 + 代码片段的起始位置 + 文件名 等存入VectorDB（不存储用户具体的代码）
4. 使用VectorDB中的数据来实现向量相关性检索

可以看到它的基本流程和开发一个wiki问答机器人是一致的。

对代码进行Embedding是关键的一步，不过我们可以很容易地预见到，直接使用 “理解自然语言” 的神经网络模型去对代码进行Embedding，效果肯定是不会好的——自然语言和代码它们之间差异太大了。代码中虽然有部分英语单词，但是绝大部分都是逻辑符号，控制流语句，这些对于理解代码的含义至关重要。加上有些程序员的函数、变量命名本身就晦涩难懂，因此一般的模型很难捕捉到代码中的逻辑信息。 为了提高效果，需要根据代码的特点针对性地训练模型，才能在Embedding时“理解”更多代码逻辑。而这对团队的AI人才储备提出了较高要求，虽然也可以找开源的code embedding模型，但是如果你是开发AI IDE的厂商，就靠这个挣钱，那这就属于你的核心竞争力，你的护城河。护城河靠开源是不行的，因为大家就在一条线上了。所以，Copilot团队在这块儿需要投入很多人才和资源。

除了Embedding，另一个问题就是Chunk。由于代码本身是有严格语法的，对代码进行Chunk就不能像对wiki文章切分那么简单。当然，简单是相对的，wiki文章中有各种复杂的格式、图片，切分起来也很不简单，只是Chunk的策略对代码的影响会更大。前面也说了，切分的关键是：

1. 尽最大可能保留完整上下文
2. 1的基础上尽可能简短

而代码的上下文分析起来则相当复杂，如：

• 函数内调用了很多外部函数，依赖外部变量
• 函数接收了闭包作为入参，闭包的实现也很关键
• 对象实现了interface，interface的定义也是关键上下文
• ……

有时候为了更好地Chunk，可能需要对代码做语法和语义分析…相关论文也不少，感兴趣的可以搜搜。

所以你可以看到，做Copilot这个方向，除了对AI领域要有足够深入的理解，可能还需要对编译原理有很深地研究，才能提升Chunk和Embedding的效果。 而且，这些可能也还不够。比如用户问：“这个项目是怎么实现鉴权的”。如果直接根据问题去查找相关的代码，可能定位到的就是：

import common

func AuthMiddleware(ctx context.Context, ...) {
  common.CheckAuth(ctx)
  // ...
}

如果不进一步展开common.CheckAuth的具体实现，那这段代码对大模型理解实现逻辑几乎没有什么帮助，大模型很容易生成奇怪的回答。因此应用侧可能还需要对问题进行多轮召回，每轮需要对结果做一些分析再决定下一轮怎么搜，以及什么时候终止。这里实现起来也是比较有挑战性的。

效果的差异可能并不来自于大模型

上面分别介绍了知识问答领域和Copilot领域的一些实现逻辑和难点，希望大家看完之后能够理解一些具体的现象。

在使用各种AI编程助手时，不论是github copilot、工蜂助手、cline还是cursor，它们并不只是一个大模型的proxy + 调用些IDE接口这么简单。即使使用相同的基座大模型（deepseek-v3/o3-mini/cluade3.5-sonnet），最终生成的代码质量差别也很大。甚至很多时候，在A copilot上即使换到了更强大的基座大模型，但生成质量可能还不如B copilot上使用更老一点的模型生成的代码质量好。

核心差异就是各个Copilot的Chunk策略、Embedding模型、以及召回策略调优，这些共同决定了最终给到大模型的相关代码的质量，而这也直接影响了大模型生成的内容质量。如果召回的代码相关性太差，那后面甚至就还到不了比拼大模型能力的时候。之前我一直是cursor用户，deepseek出来后cursor没有马上支持，为了使用ds我又切到了vscode+cline。切换之后，deepseek是用上了，但使用下来体感差距很大，最后又回到cursor。继续使用**“相对过时的claude”**，但明显感觉效果反而更好。这就充分说明了 不同厂家在Chunk Embedding这些方面的工作，对结果影响巨大。（现在cursor新增了claude sonnet 3.7，这就更强大了，20刀真的值…）

由于Chunk和Embedding对Copilot生成质量的影响巨大，除了厂商，我们开发者其实也可以双向奔赴。个人预测，下一个爆发点很可能就是 面向Copilot的代码设计模式，How to write AI-friendly Code，我也正在深入研究这块。

除了Copilot了，知识库应用也是类似的。Chunk、Embedding、召回策略，这些对回答问题的准确性也是至关重要的。不同团队在这3个方向的投入都不尽相同，自然效果也会大相径庭。大家在进行知识库选择时需要仔细对比实际效果，而不是只看各家的基座大模型（这反而是最容易追上的）。

普通程序员应该关注的机会

以上 基于文档的知识问答 和 AI Copilot，是目前大模型应用开发渗透最深入、使用最广泛的业务场景。我们普通开发者，可以学习借鉴这种思路，并在合适的场景中运用到自己的业务中来提升效率。但是，并不是所有业务都适合，也不是所有开发者都有这样的机会。正所谓，“纸上得来终觉浅，绝知此事要躬行”。但如果业务线没有场景，大家没有合适的机会参与，是不是就会掉队呢？

其实不然，我可以很明确地说，AI应用开发还有 非常广阔的 且 马上就能想到 且 还没怎么开卷 且 不需要懂AI 的空间等着大家去发挥。

前面例子中讲到的场景，不知道大家有没有发现，主要还是在问答场景，不论是基于知识库的问答，还是copilot基于代码仓库的问答，交互都是一问一答的场景。 你通过提问，知道了该怎么做，然后按照AI的指导去解决问题。相比于之前遇到问题去网上搜索，然后还需要在各种垃圾消息中过滤有效信息的费时费力，这已经是很大的进步了。但其实，既然AI这么智能，我们能不能让它 直接帮我们把活干了，而不是告诉我们该怎么干。

文章的前半部分，我们讲到了开发复杂应用的一些基本原理和方法，核心就是依赖反转，利用LLM的function calling能力，我们去提供工具进而增强LLM的能力。 比如，我们可以实现一个Tool，它可以在本地执行输入shell命令，并返回执行结果。有了这个工具，大模型就相当于有了在本机执行命令的能力了。 具体流程类似于：

在应用层实现一些能力供大模型调用，从而让它可以和 现实环境 产生交互（查询数据、执行命令）。这类应用业界有个专有名词，叫做—— AI Agent。引用IBM对AI Agent的一个定义：

An [artificial intelligence (AI)]agent refers to a system or program that is capable of autonomously performing tasks on behalf of a user or another system by designing its workflow and utilizing available tools

简而言之，AI Agent就是 可以利用外部工具帮你干活 的应用。但是很显然，它能干哪些活，完全取决于你提供了哪些Tool。

然而现实中大部分任务不是单个工具、单轮交互就能完成的，通常需要较长的流程、多轮交互、组合使用多个工具。比如我们要开发一个 同事今日运势 的应用，它要实现的功能是 给指定同事算命并给出建议，例如：

问：@echoqiyuli 今日运势如何

答：
根据生辰八字测算，今日事业运势不佳，面对非确定性的事情时容易得到不好的结果。
但从TAPD上得知，echoqiyuli今天安排了线上发布，建议编个理由拖一天，以免遭遇重大Bug。
今日爱情运势极佳，以下是从内网BBS抓取的3个和她八字相合的男生的交友贴：url1, url2, url2 ...

要实现这个应用，我们需要至少给大模型提供以下这些Tool：

• 根据英文名查询同事的个人信息（最关键的：中文名、性别、生日）
• 调用外部算命服务API（input: userInfo, output: 算命结果）
• 查询今天日期
• 去TAPD上查询指定用户在指定日期的task
• 去内网BBS查询N条相亲贴

有了这些Tool还不够，我们需要专门设计prompt，例如（不work，会意就行）：

你是个算命先生，给鹅厂的程序员算算今日运势，并针对性给出一些建议。

以下是你可以调用的工具：
${各个工具的openapi表示…}

输出需要包含：
1. 用户的今日事业运 + 针对这个运势结合TAPD上用户的工作计划，给出对应的建议
2. 用户的今日爱情运势 + 针对性地从BBS上抓取相亲贴做出推荐

指令：算下${user}的今日运势

最后，结合一个好用的开发框架 + 支持function calling的基座大模型，就能开发出这样一个应用了。分析这个应用，我们可以发现，除了构思Prompt以外，绝大部分时间都是在开发Tool来作为LLM的“眼和手”。如果想把大模型应用在实际工作中直接帮我们做事情，这里面需要大量的工具。并且这些工具可以支持新增，我们的LLM就会得到持续地加强。开发这些工具，就是我们可以快速参与生态建设并把AI运用到实际工作中产生价值的机会。

MCP——串联AI Agent生态的协议

如果开发一个LLM应用，你当然可以把所有Tool能力都自行开发，就像你开发一个后台服务，你可以全栈自研，不使用第三方库，不调用中台提供的服务。但是这显然不是一个好的做法，尤其是在对效率追求如此高的当下，怎么样建设相关生态方便共享和复用才是关键。比如，你需要一个Linux Command Runner工具，它可以代理大模型执行shell命令。你当然可以很简单地实现一个Tool，但是为了安全性，这个工具最好要支持配置命令黑白名单，支持配置只能操作指定目录的文件，支持自动上报执行记录等等功能…要做得Robust就不简单了。因此Tool也需要开放的生态。

不仅如此，大模型应用本身也可以整体提供给其他应用使用。比如，我开发一个 线上问题快速排查 的应用，在排查具体问题时，它可能需要去查iwiki上的文档。而我们前面的例子也说了，要做好知识问答话涉及很多RAG相关的能力建设和优化。最好的办法就是直接使用iwiki问答机器人，而不是重新造轮子。

这和我们现在的开发复用方式其实没啥两样：

• Tool复用： 相当于我们依赖一个开源库
• 应用级复用：相当于我们依赖一个中台服务

但在LLM应用场景中，由于它足够聪明，因此有更 AI-Native （从Cloud-Native学的叫法）的复用方式，这就是 MCP Server。

[MCP]全称 Modal Context Protocol，它的官方介绍比较抽象：

Model Context Protocol is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you’re building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.

它其实是 一种流程 + 流程中使用的通信协议。如果要类比，有点类似于建立TCP连接，它包含了具体的握手流程，需要几次交互，每次发送什么内容，以什么格式描述。MCP也是如此。这样讲依然抽象，看个例子就好懂了：

假如你是个足智多谋但手脚残疾的军师，你现在需要带兵打仗（设定可能有点奇怪）…因为你无法行动，所以你只能靠手下去完成任务。于是你进入军营的第一件事是大喊一声：“兄弟们，都来做个自我介绍，说说你的特长”。然后，兄弟们就依次介绍自己的能力，你把这些都记在了心中。当打仗时，你就可以知人善用了：“A你负责去刺探敌情，B你负责驻守正门，C你领一队人去偷袭敌后…”

MCP其实就是描述了这样一个流程，它分为两个角色：mcp-client 和 mcp-server。mcp-client就是上面说的军师（也就是我们自己正在开发的大模型应用，主调方），mcp-server就是各个士兵，提供具体的能力的被调方。用户可以配置不同的mcp-server的地址，这样mcp-client在初始化时，就可以分别去访问这些服务，并问：“你提供哪些能力”。各个mcp-server就分别返回自己提供的能力列表[ {tool_name, description, 出入参...} ]。mcp-client知道了各个server有哪些能力，后续在解决问题时，就可以按需来使用这些能力了。这种方式的好处就是，我们的应用(mcp-client)可以再不改动代码的情况下对接新的能力，各种AI Agent能够很方便地被复用

img

以上就是一个应用使用 MCP 去对接生态能力的示例。这里我说的是“生态能力”而不是“AI能力”，核心原因是，MCP-SERVER不一定是一个基于AI的应用，它可能就是一个网页搜素服务、天气查询服务，也可能运行在本地负责文件读取or命令行执行。只要这个服务实现了MCP-SERVER定义的接口，那么mcp-client就可以对接上它，进而使用它提供的能力。

上图中可能唯一让人迷惑的可能就是 *stdio**。在MCP中，实际上定义了 **两种** 传输方式，一种是基于 **网络RPC** 的，这种是大家最最熟悉的，client和server可以在任意的机器上，通过网络进行通信。而另一种则是基于 **stdio** 的，这种比较少见，它要求*client和server必须在同一机器上。基于stdio通信主要是面向诸如 linux command runner（本地执行linux命令）, file reader（读取本地任意文件内容）等等需要在本地安装的场景。这种场景下，mcp-server不是作为一个独立进程存在，而是作为mcp-client的子进程存在。mcp-server不是通过网络端口收发请求，而是通过stdin收请求，把结果输出到stdout。

比如，我们给mcp-client配置的mcp-server形如:

[
  {"type":"http/sse", "addr":"a.com/x", ...},
  {"type":"local", "command": "/usr/local/bin/foo -iv"}
]

对于local模式的mcp-server，client就会用给定的command来启动子进程，并在启动时拿到stdin stdout的句柄用来读写数据。 但是不论是走网络还是走stdio，client和server之间传输数据的协议（数据结构）都是一样的。

以上就是对 MCP 的一个简单介绍，从这里你可以看到，如果各种AI应用都实现MCP协议，那整个生态就可以快速地发展起来，我们开发一个应用时也能很容易地用上其它的AI能力。

所以，我们可以踊跃地尝试开发MCP-Server，把我们的日常工作Tool化，然后尝试使用Cluade-desktop这样的集成了mcp-client的LLM应用去使用我们开发的Tool，来最大程度解放我们双手提升效率。当然，我们也可以尝试自行开发带mcp-client能力的LLM应用作为我们日常使用的入口，比如企微机器人等。但由于企微机器人在远端，无法操作你的本机，因此可能效果不如desktop版本好用。

总结

本文主要讲了AI大模型应用的开发是怎么一回事、它的具体流程以及在不同应用场景中大模型是怎么发挥价值的。举了很多例子，也比较粗显地介绍知识问答场景和Copilot场景的原理和挑战。最后花了比较多的篇幅讲MCP，这是我们把大模型运用到实际工作中发挥价值的关键，且人人都可参与。 如果要用更简单的方式来概括大模型应用开发的几个方向，我可能把它分成：

• 开发框架（infra）：目前处于百花齐放的状态，感兴趣可以去玩玩
• RAG（给大模型引入业务领域知识）：RAG是把大模型和业务相结合的关键，也是 产品的核心竞争力 所在。RAG大的脉络不难，但具体实践和优化比较硬核，需要相当专业的知识。Chunk/Embedding/基座大模型，在不同业务场景中都需要不同的优化思路，且都对最终结果有很大的影响。
• MCP-Server：让大模型和真实世界进行交互的关键，想要让大模型作为助手真正帮我们解决问题，需要构建很多很多很多MCP-Server。这块没有开发门槛，适合所有人上手参与。

希望本文对大家了解AI大模型应用开发有帮助，并且能够积极地参与进来，跟上时代的步伐。

最后

如果你真的想学习大模型，请不要去网上找那些零零碎碎的教程，真的很难学懂！

你可以根据我这个学习路线和系统资料，制定一套学习计划，只要你肯花时间沉下心去学习，它们一定能帮到你！

点击领取：2025最新最全AI大模型资料包：学习路线+书籍+视频+实战+案例…