刚入行的时候，我最怕的不是模型效果差，而是同事嘴里蹦出来的那一串术语。LLM、Token、Agent、MCP、Harness、RAG、Embedding、Fine-tuning……每一个单词都认识，凑在一起就变成天书。更折磨人的是，这些概念还不是孤立的，它们互相嵌套、互相依赖，搞不清关系，连排查问题都不知道该查哪一层。
这篇文章不打算按百度百科的方式去解释，而是站在一个一线开发者的角度，把AI应用开发里最烧脑的8个概念一次讲透。我会告诉你它们各自是什么、解决什么问题、和你熟悉的哪个东西最像，再串一个完整场景把它们全部连起来。看完之后，你再看AI相关的技术文章和产品文档，会顺畅很多。
这8个概念是：LLM、Token、RAG、Embedding、Fine-tuning、Agent、Harness、MCP。它们不是8个平行领域的知识，而是同一条技术链路里的8个关键节点。理解了这条链路，也就理解了大模型应用开发的全貌。
1. 底层基石：LLM 和 Token 到底在干嘛
1.1 LLM：一台会“接龙”的超大型概率机
LLM（Large Language Model，大语言模型）是这两年AI热度的绝对主角。但你如果把LLM想象成一个什么都知道的知识库，方向就错了。它本质上是一个训练出来的“接龙游戏玩家”。
怎么理解？它的核心任务只有一个：给定前面一段内容，预测下一个最可能出现的Token（这个词我们马上讲）。比如你输入“今天天气真”，模型会预测下一个词是“好”还是“热”。如果你输入一句完整的问题，它就一个Token接一个Token地续写下去，直到拼出一段完整的回答。你看到的那些惊艳回答，本质上都是模型“一句一句接龙”接出来的，不是从数据库里查出来的。
这就带来一个非常重要的推论：LLM不保证事实正确，它只保证在概率上“像样”。它学习了海量文本后，学会的是文字的统计规律和语义关联，而不是背下了真理。所以你会看到模型信誓旦旦地说某个不存在的文件“就放在某系统里”，这不是它撒谎，而是它按概率“编”得很顺。
实操中要记住：把LLM当成一个“文字接龙引擎”来设计系统，而不是当成权威信息源来依赖。任何需要精确事实的场景，都要靠外部工具或检索来兜底，这部分后面讲RAG和MCP时会展开。
1.2 Token：大模型眼中的“拼图块”
Token是模型处理文本的最小单位。它可能是半个词、一个词、几个字符，甚至一个标点。大模型不认识“字”，它只认识Token。中文场景下，一个汉字通常对应1到2个Token，英文一个常见单词大概对应1个Token。
为什么这个概念特别重要？因为Token同时决定了成本和上下文窗口。
成本方面，现在主流API基本都是按Token计费，输入和输出都算钱。你以为你上传了5000字，实际计费的Token数可能比这个多，也可能比这个少。我踩过一个坑：把一份合同丢给模型做条款审阅，刚跑完第一步就提示预算超了，一查才发现合同里大量法务术语被拆成了长Token序列，费用远超按“字数”估算的结果。
上下文窗口方面，模型一次能处理的Token数量是限定的，比如4K、8K、32K、128K。超出的部分模型“看不到”。很多人问为什么模型明明很聪明，聊长一点就前言不搭后语？因为前面的Token被截断了。所以设计对话系统时，如何精简历史消息、如何截断过长文档，是绕不开的工程问题。
提示：估算成本时不要按“字数”算，按Token算。一个简单的经验法则是：中文场景下，Token数约等于字数的1.3到1.5倍；英文场景约等于单词数的1.2到1.5倍。如果拿不准，用模型厂商提供的Token计数工具统计一次。
1.3 为什么先搞懂Token比先追新概念更重要
很多新手一上来就研究Agent、Harness，结果一跑通就遇到各种莫名其妙的问题：上下文超限、费用爆炸、性能不稳定。追根溯源，都是没搞懂Token的底层约束。
我举一个真实项目里的例子。某公司做一个客服助手，最初版本直接把整本用户手册（几万字）塞进提示词，让模型“依据手册内容回答”。上线后发现两个问题：一是每次请求的Token消耗巨大，成本高得离谱；二是用户手册一更新，模型回答还是旧的，因为上下文里塞的是旧内容。后来改为把手册做成分块索引，按用户问题只检索相关的两三段内容喂给模型，Token消耗降到原来的十分之一，准确率反而提升了。
这个例子说明：LLM是能力上限，Token是资源约束。一切Agent、Harness的设计，本质上都是在资源约束下，尽可能把LLM上限发挥出来。你不理解Token，后面所有上层工具在你眼里都只是魔法，出了问题根本无从排查。
2. 从“会聊天”到“会答对”：RAG、Embedding 与 Fine-tuning 怎么选
2.1 RAG：给模型装一个“外置资料库”
RAG（Retrieval-Augmented Generation，检索增强生成）解决的是LLM“知识缺失”和“知识过期”的问题。它的思路很朴素：模型不知道没关系，查了再回答。
具体流程是这样：用户提问后，系统先去一个知识库（比如企业内部文档库）里检索出最相关的几段内容，然后把“问题+检索到的内容片段”一起塞给LLM，让LLM基于这些内容生成答复。模型不需要“记住”这些资料，它只需要“阅读”喂到眼前的资料。
实操中RAG最核心的不是“检索”这个动作，而是“检索质量”。我见过不少团队把RAG做成“关键词搜索”，用户问“打印机怎么连WiFi”，检索系统按关键词去找“打印机 WiFi”，召回的段落乱七八糟，LLM生成出来的答案自然也是错的。
真正有效的RAG要解决三件事：
- 文档分块：不能整篇塞，也不能切得太碎。切太碎语义不完整，切太大上下文又装不下。一般按段落或语义边界分块，每块控制在200-500个Token左右。
- 向量化与召回：用户问题先用Embedding转成向量，在向量库里找最相似的几块内容。这一步比关键词匹配理解语义强得多。
- 重排：召回20-50个候选片段后，用重排模型挑出最精准的3-5个喂给LLM。
RAG适合什么场景？知识库问答、产品帮助中心、企业规章制度查询、实时信息对答。一句话总结：凡是答案在某份文档里、但模型没见过的，优先考虑RAG。
2.2 Embedding：让文字变成“坐标点”
Embedding（向量嵌入）是把文本映射成高维空间里的一组数字。这些数字可以理解为文字的“坐标”。语义相近的文字，坐标距离就近；语义无关的文字，坐标距离就远。正是这个性质，保障了RAG能“按意思找文档”。
生活中比较好理解的类比：你把一道菜的口味描述成一个向量，比如“辣度=8、咸度=5、甜度=2”。想吃辣的人，他的口味向量也是“辣度=9、咸度=4、甜度=1”，你俩的口味向量距离很近，推荐这道菜就合理。反过来说，一个偏清淡口味的人向量是“辣度=1、咸度=2、甜度=8”，距离远，就不要推荐。
实际操作中，Embedding模型有不同等级，常见的有几百维到几千维不等。维度越高，表达力越强，但计算和存储成本也越高。选型时要综合考虑语义精度和成本。我有个建议：做中英文混合场景时，优先测几款中文效果好的Embedding模型，拿你自己领域的100个问题做一轮召回准确率测试，比看宣传指标靠谱得多。
注意：Embedding模型不是“越大越好”。某项目一开始用了高维模型，向量库里存了数百万条片段，检索时延迟直接飙到3秒。换成中等维度模型，精度只降了2%，延迟降到100毫秒不到。这个交换非常划算。
2.3 Fine-tuning：给模型做“岗位培训”
Fine-tuning（微调）是在预训练好的模型基础上，用特定数据继续训练，让模型学会某种风格、某种输出格式、或者某种特定任务。
和RAG的区别要划清楚：RAG是给模型喂参考资料，让它在回答时现查现用；Fine-tuning是给模型“换脑子”，让它彻底学会一种行为模式。前者不改变模型本身，后者会改变模型的权重。
什么场景适合Fine-tuning？我总结下来有这么几类：
- 格式要求严格：比如要求模型只输出JSON、只按固定模板生成报告，通用模型总爱加一句“希望对您有帮助”，你需要它闭嘴。
- 风格定制：比如把回复语气调成幽默、专业、冷酷。
- 领域术语学习：比如医疗报告、法律文书里的大量专有名词和表达习惯。
- 特定任务能力增强：比如从吐槽文本里提炼“情绪+事件+诉求”结构化字段。
但Fine-tuning有个前提：你的数据质量得足够高，数量也不能太少。我做过的项目里，少于几百条样本的微调效果很难有质的提升，反而容易让模型“学坏”，连之前的通用能力都下降。业内通常的做法是：先用RAG解决知识问题，不行再用Fine-tuning解决行为问题。别一上来就微调。
2.4 三者的分工：一张表看清
| 概念 | 解决的问题 | 一句话类比 | 典型场景 |
|---|---|---|---|
| RAG | 知识缺失、知识过期 | 考试时带一张翻查索引卡 | 企业知识库问答、产品FAQ |
| Embedding | 让文本可被语义检索 | 给文字画坐标，量距离 | 语义搜索、去重、聚类 |
| Fine-tuning | 行为风格与输出格式定制 | 上岗前的岗位培训 | 固定输出格式、领域术语、风格调节 |
RAG重知识，Embedding是RAG的支撑技术，Fine-tuning重行为。这三者不是竞争关系，而是经常配合使用。例如，某个金融问答系统，用RAG接入实时行情文档，用Embedding做召回，同时对输出格式做了少量微调，答出来的内容是“新知识，老规矩”，非常稳定。
3. 让AI真正“动手干活”：Agent 与 Harness 的关系
3.1 Agent：从“回答问题”到“完成目标”
Agent（智能体）是目前热度极高的概念。它的本质，是让LLM不只输出一段文字，而是能够自主规划步骤、调用工具、根据中间结果再决策，直到完成一个目标任务。
你可以把Agent想象成一个“实习生”。你给他一个目标，比如“帮我把这20份简历按硬性要求筛选一遍，符合条件的发面试通知”。他需要自己决定：先看哪些字段，怎么判断硬性条件，筛选完哪些需要人工复核，最后怎么发通知。聪明的实习生会拆步骤、会问问题、会用工具；笨实习生可能干一半就卡住了，或者自作主张把事情办砸。Agent也一样。
一个典型的Agent工作循环是这样的：
- 接收用户目标
- 把目标拆解成若干子步骤
- 执行当前步骤，可能需要调用一个工具（比如搜索引擎、数据库、代码解释器）
- 观察工具返回的结果
- 根据结果决定下一步做什么
- 循环直到任务完成
这里最重要的特征是**“循环”**。普通的单轮问答是“输入问题-输出答案”，Agent是“多次输入-多次输出-中间穿插工具调用”的动态过程。
但Agent的问题也很明显：不稳定。LLM毕竟是概率模型，它可能在第五步走岔路，也可能在工具调用时参数传错。所以纯粹靠“模型自由发挥”的Agent，在真实生产环境里基本跑不通。这时候就需要Harness来管住它。
3.2 Harness：Agent的“操控台”和“安全带”
Harness（运行框架/操控台），是把“模型自由发挥”变成“工程可控流程”的那一层。它负责给Agent提供结构、约束和基础设施。
传统开发里我们很熟悉“框架”这个概念：Web框架管请求、鉴权、路由；测试框架管用例、断言、报告。Harness对标的就是这类角色，只不过它管的不是HTTP请求，而是“Agent的行为”。
具体来说，Harness承担这几件事：
- 任务编排：定义Agent的拆解方式，哪些步骤必须按顺序来，哪些可以并行。
- 提示词管理：给每个子任务注入合适的上下文和约束，避免模型“天马行空”。
- 工具调用封装：Agent要调用某个API，Harness统一处理参数校验、重试、超时、报错。
- 状态管理：多轮决策之后，当前做到哪一步了、已经拿到了哪些结果、还需要什么，都要记录。
- 安全与容错：比如限制工具权限、检测输出里是否有敏感信息，Agent跑偏时能中止或回退。
为什么需要Harness？因为Agent本质是“一个会自作聪明又没有稳定性的实习生”，你不能让他完全裸奔。Harness相当于在他周围搭好的操作台和安全护栏：一方面他把活了干得更好，另一方面他如果乱来，你能及时按停止键。
实操心得：很多项目里Agent效果不好，不是模型不行，而是Harness太弱。最典型的表现是：同一个Agent，在十次任务里有六次表现优秀，另外四次自己绕进了死胡同。加上一个带重试和回退机制的Harness之后，成功率能明显提高。别急着换更贵的模型，先把编排框架打结实。
3.3 两者不是“选谁”，而是“配合”
不少初学者会问：“我应该用Agent还是Harness？”这个问题本身就把它们对立了，实际上它们是配套关系。Agent是“决策和执行的主体”，Harness是“承载Agent的运行时环境与行为约束体系”。没有Agent，Harness只是空架子；没有Harness，Agent跑不稳。
类比传统开发：Agent像是你写的核心业务逻辑，Harness像是你部署和运行这个逻辑所用的服务框架与基础设施。业务逻辑写得再好，没有框架的异常处理和资源管理，上了生产环境照样崩。
目前市面上已经出现了不少成熟的Harness实现，有的是图文并茂的可视化编排，有的是纯代码工作流，有的偏向自由Agent。选型时关注的不是“谁功能多”，而是“谁能管住你的模型”。你的应用场景如果步骤固定、输出格式严格，优先选择确定性更强的工作流型Harness；场景高度开放、需要探索执行，再考虑自由度更高的Agent框架。
4. 打通工具边界：MCP 怎么改变AI接外设的方式
4.1 MCP：给AI接工具的“通用插座”
MCP（Model Context Protocol，模型上下文协议）是最近一年里非常关键的协议级概念。一句话解释：它定义了LLM应用如何统一地连接外部工具和数据源。
以前的情况很分裂：每个工具都有自己的API，模型想调用某个外部系统，开发者得针对这个工具专门写一套适配代码。接一个工具写一套，接十个工具维护十套。而每个Harness又各有各的接入方式，换个框架就得重写。MCP解决的就是这种“碎片化”，它像USB-C接口一样，把“工具接入”这件事标准化了。
在MCP架构里：
- 有一个MCP服务器（Server），它封装了某个具体工具的能力，比如查天气、执行SQL、发邮件、访问某个业务系统。
- 有一个MCP客户端（Client），它运行在LLM应用侧，负责与服务器握手、发现能力、调用工具。
- 两者之间通过统一的协议格式传输，而不是每个工具搞一套私有格式。
更关键的是，MCP定义了三种能力原语：资源（Resource）、工具（Tool）、提示词（Prompt）。资源的场景是“读取数据”，比如读文件、读数据库、读当前上下文；工具的场景是“执行操作”，比如发消息、创建工单、改配置；提示词的场景是“给模型提供可复用的指令模板”。
4.2 一个完整的工具调用链路长什么样
我带你走一遍MCP工具箱里的典型调用过程。假设你的AI助手需要查询某业务系统的订单状态：
- Agent接收到用户问题：“订单F2024001到哪儿了？”
- Harness识别出这需要调用外部系统。
- MCP Client向已注册的MCP Server发起请求，查询该订单接口。
- MCP Server返回工具列表和参数说明。
- Agent根据返回说明，填入参数（订单号F2024001），发起调用。
- MCP Server执行查询，把结果返回给Agent。
- Agent阅读结果，组织成自然语言回复给用户。
没有MCP的时候，这个过程里每一环都需要手工定制：参数要怎么传、鉴权怎么做、结果怎么解析，全都硬编码。有了MCP，这些通用机制被协议层消化掉了，开发者只需要关注工具本身的业务逻辑。
4.3 实操中怎么判断工具要不要用MCP
我的建议是：如果你的应用只接一个固定工具，而且未来大概率不会扩展，直接写个简单函数调用即可，没必要引入MCP增加复杂度。但如果你的应用会陆续接入多个工具，或者工具被多个Agent复用，尽早统一到MCP模式，后面省心得多。
另一个实操点是安全边界。MCP把工具调用变得很容易，这本身就是双刃剑。在Harness里必须做权限拦截，哪些工具Agent可以自动执行、哪些必须人工确认，要在一开始就设计清楚。我见过一个Agent把测试环境的配置项给改了，就是因为MCP Server的权限放得太大。协议好用归好用，权限该控还得控。
4.4 部署测试MCP的小注意点
实操中最容易踩坑的是MCP Server的标准输入输出连接方式。很多框架里Server跑在本地子进程，通过标准输入输出与LLM通信。这意味着部署环境里必须装好对应依赖，路径不能乱配，资源占用也要控制。调试时先单独测试Server能否正常响应，再接入Agent，不要一上来就端到端调试，不然完全分不清是模型理解出错还是Server调用出错。
另一个常见问题是不注意Server的生命周期。某个框架里，如果MCP Server没有正确退出，每次调试都会残留一个僵尸进程，拖慢整机速度。我现在的习惯是：每次写完Server集成，先跑一遍“启动-调用-退出”全流程，确认没有进程残留，再进下一轮开发。
5. 一个完整场景：把这8个概念串成一条线
5.1 场景构建：做一个“合同审查助手”
前面的概念都是单个拆开讲的，但真实项目里它们是混合工作的。我拿一个完整的项目“某合同审查助手”来串联，你跟着走一遍，8个概念的关系就清楚了。
业务需求是这样：法务部门的同事把一份合同文档上传后，系统要自动提取关键条款、对照公司的合规知识库找出风险点、生成审查意见，并把需要修改的条目推送到OA系统生成待办。
技术团队最终设计成这样的架构：
- LLM是核心生成引擎。负责条款提取、风险分析、意见撰写这些自然语言任务。
- Token是硬约束。一份合同动辄好几万字，直接塞给LLM必然超限。实际做法是把合同切片，每片控制在500个Token以内，逐片分析后合并结果，同时统计每次调用的Token消耗，控制成本。
- Embedding在知识召回中发挥作用。合规知识库里存了上百份内部管理制度和风险条款案例，全部切成语义块后生成向量索引。合同中的某一条风险条款，先被Embedding转成向量，去知识库里找最相近的合规依据。
- RAG把搜索到的相关合规片段拼装成带依据的参考资料，喂给LLM生成“风险点+依据条款+修改建议”，让结论有出处。
- Fine-tuning加持了输出格式。团队里收集了上千条评分高的审查意见，微调了一个“审查风格模型”，专门负责让输出格式稳定：结论放前面，依据引用放中间，修改建议放最后，禁止出现含糊用语。
- Agent负责整个任务的端到端编排。它先判断这份合同属于什么类型，再决定要审查哪些章节，逐段启动审查流程，中途如果发现某部分知识不足，主动去知识库里检索，最后一并汇总生成报告。
- Harness是整个Agent的操控台。它定义了Agent的工作流节点、每一节点的超时时间、失败重试次数。比如知识库检索这块，分配了两次重试机会；OA推送这个工具调用，要求必须有审批确认。没有Harness，Agent大概率会在某一环节自由发挥跑偏。
- MCP统一接入了外部工具。合同调取、知识库检索、OA待办创建，这些能力全部按MCP协议独立封装成Server。Agent调用它们时，不关心底层系统在哪里、用什么语言写的，只通过统一的MCP Client去调用，各Server在本地或远程独立运行。
5.2 一次典型任务的实际流转
用户上传合同后，整个流程大致是这样流转的：
- Agent接收合同文件，Harness把它登记为一次审查任务，并初始化上下文状态。
- Agent调用“合同解析工具”（经过MCP协议接入）提取合同正文，并统计Token用量。
- Embedding把合同条款逐条映射成向量。
- RAG在合规知识库里检索相关依据，将最相近的3-5个知识片段召回。
- LLM基于“合同原文片段+合规知识片段”生成该条款的风险分析和修改建议。
- 输出结果经过Fine-tuned格式模型统一排版，生成审查报告。
- Agent再次启动MCP协议里的“OA待办”工具，将需要修改的条目推送过去。
- Harness全程监控每一步的状态和成本，如果有一步失败自动重试，并输出一份执行日志。
这一条线走下来，你会发现：LLM和Token在最底层，Embedding和RAG解决的是“凭据和知识”，Fine-tuning保证“表达风格”，Agent负责“拆解目标”，Harness负责“约束行为”，MCP负责“连接万物的方式”。8个概念在同一个项目里各司其职，没有谁是孤立存在的。
注意：这不是一个理想化的架构，而是这类智能文档处理系统常用的实际形态。区别只在于各块的复杂度不同：简单场景可以不拆Agent，用Harness里固定的工作流；工具少的情况下，可以暂时不引入MCP，直接写函数调用。架构服务于场景，能最稳妥解决业务问题的，就是好架构。
6. 新手最容易踩的5个认知坑
6.1 把Token当成“字数”，预算和上下文全算错
这是我反复提醒的问题。每次看到有人汇报“我们一次请求才几万字”，我就知道一定没把Token的事搞清楚。Token和字数存在明显的换算关系，尤其在中文场景，标点、特殊符号、Markdown语法都会额外占用Token。处理长文档时，如果按字数估算上下文，模型极有可能警告超限；按Token计费时，费用也会远高于预期。
正确做法是：在设计阶段就用Token计数工具对样本做测量，不同模板都要测，把“平均每次请求Token数”作为核心指标来优化。上下文窗口不够时，优先优化提示词精简度，其次才是换更大窗口的模型。
6.2 以为RAG就是“把文档塞进提示词”
有人觉得RAG很简单：把所有资料贴在提示词里，让模型自己找答案。但真上了生产环境就会发现：资料越多，模型越容易抓错重点；资料一长，Token暴涨；资料里的噪音还会带偏回答。RAG的难点根本不在于“塞”，而在于“检索质量”和“分块策略”。
想做好RAG，要把精力花在这些地方：文档清洗、块大小调优、向量模型选型、召回数量、重排策略、以及“召回不到怎么办”的兜底答案。我在某型设备售后问答项目里，光是调整分块逻辑，就让答案命中率从57%涨到了83%，而这只是最基础的一步。
6.3 把Agent当成“自动调用API”
不少团队把Agent理解成“能用工具调用接口的机器人”，结果写出来的Agent只有一个简单的“判断该用什么工具-调用-返回”的流程，碰到需要多轮探索、需要根据上一步结果调整策略的任务就完全失灵。真正的Agent重点是任务拆解和循环决策，工具调用只是它的一只手，不是大脑。
如果要上手Agent开发，先从“固定的三步任务”练起，比如“提取合同里的金额字段，然后对照报价单计算差额，最后生成差额报告”。跑顺之后再逐步放开自由度，比如让它自己决定是否需要查询额外资料。一步到位做“完全自主的Agent”，大概率是开发地狱。
6.4 以为MCP一上就万事大吉
MCP标准化了接入方式，但并不负责工具的质量、权限和稳定性。有很多开发者接入了MCP Server后，发现调用报错、权限混乱、超时无人处理，就觉得MCP“不过如此”。这其实是对协议边界有误解：MCP是运输通道，不是货物质量保障。工具本身的逻辑要靠自己维护，服务的高可用要靠部署设计，权限审计要结合Harness层实现。
另外，MCP的生态还在快速演进，不同实现之间的兼容性问题仍然真实存在。遇到问题要看日志、拆边界：是Server内部出错、Client协议解析出错、还是Agent决策用错了工具。把这条链路掰开揉碎了，再难的问题也能定位。
6.5 让Fine-tuning背“万能的锅”
总有人问：模型回答不准，是不是微调一下就好了？答案是不一定。回答不准的原因可能是知识缺失（该用RAG）、引导不到位（该优化提示词）、输出格式不符（该做Few-shot示例），而不是模型能力不行。盲目微调，不仅在数据成本上投入高，还可能让模型在无关任务上的能力退化。
我的原则是：能检索的不要微调，能提示词解决的不要检索，确实需要行为定制的才微调。微调数据要精而不是多，如果数据里有一半是低质量标注，那效果可能连不微调的基准都不如。先做评估集，再决定动不动手。
7. 按角色选优先级：应该先学什么
7.1 如果你是开发者
优先级建议：Token → LLM调用 → Embedding/RAG → Harness → MCP → Agent → Fine-tuning。
第一步先用LLM的API做几次完整的文本处理，统计Token消耗，感受上下文限制。然后做一个最小可用的RAG问答，跑通“文档切块-向量化-召回-生成”链路。之后再玩Agent。直接跳到Agent层会很容易失控，因为你连底层资源约束都没有体感。
开发排期上也建议这样分配：RAG的落地周期通常比Fine-tuning短，效果也更可控；如果需要Fine-tuning，先把数据质量搞扎实，留出充足评估和试错时间。MCP的引入要看场景数量，工具多了再上，一个工具时不必着急。
7.2 如果你是产品经理或业务负责人
优先级建议：LLM → Token预算概念 → RAG和Agent的能力边界 → MCP的价值 → Fine-tuning的成本评估。
你最需要回答的问题是“这个AI系统能做什么、不能做什么、烧多少钱”。所以不要纠缠于实现细节，重点搞清楚：RAG上限在哪里，Agent当前稳定性如何，MCP能带来多大扩展价值，Fine-tuning要多贵、多久见效。你不需要能写代码，但需要能听懂工程师说“上下文不够”、“召回率上不去”、“Agent在第五步卡了”分别是什么意思。
7.3 如果你只是想把AI新闻看懂
优先级建议：LLM → Token → RAG → Agent → MCP。
这篇文章提到的8个概念，如果你能把下面这段话看懂，就已经超过一大半看新闻的人了：AI是用海量文本训练出来的“接龙高手”，它靠切碎后的Token来读写文字，成本也按Token算；它并不知道最新和私家的信息，所以要用向量化检索来把需要的资料找出来；为了让AI干更复杂的事，人们给它套上Agent这层“执行外壳”让它能调用外部工具，用MCP这个标准化协议来接各种工具，再用Harness这个操控台保证它不失控。
7.4 一句话记忆卡
| 概念 | 一句话类比 | 一句话记忆 |
|---|---|---|
| LLM | 接龙选手 | 按概率续写文本，不是查知识库 |
| Token | 拼图块 | 文字的最小单位，算成本、卡上下文 |
| RAG | 外置资料库 | 先检索再回答，知识常新常准 |
| Embedding | 文字坐标 | 把语义变成距离，让机器能“找意思” |
| Fine-tuning | 岗位培训 | 定制输出风格和行为，不改事实知识 |
| Agent | 带目标的实习生 | 拆解任务、循环决策、调用工具 |
| Harness | 操控台和安全带 | 管住Agent的流程、状态、权限 |
| MCP | 万能插座 | 标准协议，一套方式接所有工具 |
我自己在带新人时经常说一句话：不要被新名词吓到，AI应用开发还是软件工程，逃不开资源管理、模块解耦、稳定性和成本控制这些基本功。LLM、Token、RAG、Agent这些概念只是把传统问题换了一副面孔，底层的工程思维反而更重要。把基础打扎实，看着再烧脑的概念，拆开也就是一层又一层你熟悉的套路。这套链路里最值钱的经验，永远是先跑通一个最小的闭环，再动手加厚度。
