1. 结课十一个月后，我才真正读懂那门AI课在讲什么
去年这个时候，我上完了知乎知学堂的AI课程，当时的感觉是"信息量很大，但好像离我的日常工作有点远"。课程结束后，我回到了自己的岗位，继续做着产品相关的事情，那些关于Agent、RAG、Function Calling的概念就安静地躺在我的笔记本里，偶尔翻到会觉得"这些东西挺有意思"，但并没有真正用起来。
直到今年年初，公司启动了一个跨部门的智能化项目，我被拉进了项目组。第一次需求评审会上，技术负责人抛出了一连串问题："我们的知识库怎么跟大模型对接？""用户的多轮对话状态怎么管理？""工具调用的边界在哪里？"那一刻我突然意识到，这些问题在十一个月前的课程里全都讲过，只是当时我没有场景去承接它们。
这篇文章不是课程笔记的复述，而是我在真实跨部门协作中，把那些"打底"的知识重新激活、重新理解的过程记录。如果你也上过类似的AI课程，或者正在做AI相关的项目，希望我的这些踩坑和顿悟能帮你少走一些弯路。特别是当你发现"学的时候都懂，用的时候全忘"时，这篇文章或许能帮你找到把知识串起来的那根线。
2. 从"知道RAG"到"敢在项目里用RAG"的距离
2.1 课程里讲的RAG和项目里要的RAG，中间隔着什么
课程里讲RAG的时候，逻辑很清晰：文档切分、向量化、检索、拼接上下文、生成回答。当时我觉得这套流程已经烂熟于心了。但真正在项目里落地时，第一个问题就卡住了：我们的文档不是干净的Markdown，而是来自多个业务系统的导出数据，有Excel、有PDF、有富文本，格式五花八门。
课程里演示用的都是结构良好的文本，切分策略用固定长度加重叠就能跑通。但实际业务文档里，一个表格跨了三页，一个流程说明嵌在图片里，还有大量的页眉页脚噪声。这时候我才理解，RAG的第一步不是技术选型，而是数据治理。我们花了整整两周时间做文档清洗和结构化，把非文本内容单独抽出来做OCR，把表格转成结构化数据，把重复的页眉页脚去掉。
另一个课程里没展开讲的是检索策略的调优。课程里用的是默认的向量检索，但实际项目中，用户的问题往往包含大量业务术语和缩写，纯向量检索的召回率并不理想。我们后来采用了混合检索：向量检索加关键词检索，再用一个轻量级的重排序模型做精排。这个思路其实课程里提过一嘴，但当时没有展开，我是在翻课程资料的时候才重新注意到的。
提示：如果你正在做RAG项目，不要一上来就调模型参数，先把数据质量搞定。数据不行，再好的检索策略也是白搭。
2.2 向量数据库选型：课程没告诉你的那些坑
课程里演示RAG用的是内存向量库，跑Demo没问题，但项目里要考虑持久化、并发、扩容。我们当时在几个主流向量数据库之间做选型，踩了不少坑。
第一个坑是维度匹配。课程里用的嵌入模型输出是768维，我们后来换了一个效果更好的模型，输出是1024维。换模型的时候忘了重建索引，导致检索结果完全乱套。这个问题排查了很久，因为表面上看检索能返回结果，只是相关性很差，很容易误以为是模型效果不好。
第二个坑是索引类型的选择。不同的向量数据库支持的索引类型不一样，有的适合高召回，有的适合低延迟。我们的场景是内部知识库，并发不高但对召回要求高，所以选了HNSW索引，牺牲了一些写入速度换召回率。这个取舍课程里没有讲，是我在查阅数据库文档和做压测之后才确定的。
第三个坑是元数据过滤。实际业务中，用户往往需要限定范围检索，比如"只看某个部门的文档"。课程里的Demo没有涉及元数据过滤，但实际项目中这是刚需。我们在向量数据库里给每个文档块加了部门、时间、文档类型等元数据字段，检索时先做元数据过滤再做向量检索，效果提升很明显。
2.3 检索增强的"增强"到底加在哪里
课程里讲RAG的时候，重点在"检索"，对"增强"讲得比较简略。实际项目中我发现，"增强"才是决定效果的关键。
最基础的增强是把检索到的文档块直接拼接到Prompt里。但这样做的问题是，检索到的内容可能有冗余，也可能有冲突。我们后来做了几件事：一是对检索结果做去重和摘要，把相似度高的块合并；二是给每个块加上来源标注，让模型知道不同信息的出处；三是在Prompt里明确告诉模型"如果检索内容不足以回答问题，请明确说不知道"。
还有一个增强策略是查询改写。用户的问题往往很口语化，直接拿去检索效果不好。我们在检索前加了一个查询改写的步骤，用一个小模型把用户问题改写成更适合检索的形式，比如补充同义词、拆解复合问题。这个思路课程里提到过，但当时我没有意识到它在实际项目中的重要性。
3. Agent不是"更聪明的聊天机器人"，而是一套执行框架
3.1 课程里的Agent演示和项目里的Agent需求差在哪
课程里演示Agent的时候，用的是很典型的场景：用户说"帮我查一下明天北京的天气，然后推荐穿什么衣服"，Agent会先调用天气API，再根据天气结果调用推荐逻辑。当时我觉得这个思路很清晰，但项目里真正要做Agent的时候，发现复杂度完全不是一个量级。
项目里的Agent需要处理的是多步骤、多工具、有状态的任务。比如用户说"帮我整理一下上个月的销售数据，生成一份报告，然后发给相关同事"。这个任务涉及数据库查询、数据分析、文档生成、邮件发送等多个步骤，而且每一步都可能失败，需要重试或者回滚。
课程里没有展开讲的是Agent的状态管理。在多轮对话中，Agent需要记住之前做了什么、当前进行到哪一步、哪些信息已经收集到了。我们后来用了一个状态机来管理Agent的执行流程，每个状态对应一个步骤，状态之间的转移由模型决策或者规则触发。这个设计思路其实课程里提过，但当时没有深入讲，我是在实际开发中才慢慢理解的。
3.2 Function Calling的边界设计：什么该让模型决定，什么不该
Function Calling是Agent的核心能力，课程里讲了基本用法：定义函数、模型决定调用哪个函数、传入参数、执行函数、返回结果。但实际项目中，最关键的问题不是"怎么调"，而是"让模型调什么"。
我们一开始把很多操作都暴露给了模型，结果发现模型会做出一些不合理的决策，比如在数据不完整的时候强行调用分析函数，或者在用户没有确认的情况下就调用发送邮件的函数。后来我们重新设计了Function Calling的边界：只把"查询类"和"计算类"的操作暴露给模型，涉及"写入"和"发送"的操作必须经过用户确认。
这个设计思路课程里没有明确讲，但我在回顾课程资料的时候发现，讲师在某个案例里提到过"高风险操作要加确认环节"。当时我没有在意，实际踩坑之后才明白这句话的分量。
另一个经验是函数的粒度。函数太粗，模型难以灵活组合；函数太细，模型容易迷失在细节里。我们后来把函数按照业务领域分组，每组提供一个"入口函数"，模型先选择领域，再在领域内选择具体操作。这样既保证了灵活性，又降低了模型的决策难度。
3.3 Agent执行失败时的兜底策略
课程里演示的Agent基本都是顺利执行的，但实际项目中，失败是常态。工具调用超时、返回结果格式不对、模型决策错误，这些都会导致Agent执行中断。
我们后来设计了一套兜底策略：每个步骤都有超时和重试机制，重试失败后进入降级流程。降级流程可能是换一个工具，也可能是直接返回错误信息让用户决定下一步。还有一个重要的设计是"执行日志"，记录Agent每一步的决策和结果，方便排查问题。
这里有一个课程里没有强调但实际很重要的点：Agent的执行应该是可中断、可恢复的。用户可能在Agent执行到一半的时候改变主意，或者系统需要重启。我们把Agent的状态持久化到数据库里，每次执行前先加载状态，执行后保存状态。这样即使系统重启，Agent也能从上次中断的地方继续。
4. MCP协议：跨部门协作中真正的"通用语言"
4.1 MCP到底是什么，为什么它让跨部门协作变简单了
MCP这个词在课程里出现过，但当时我并没有特别在意，觉得它只是一个协议标准。直到跨部门项目中，我们需要把不同团队开发的工具集成到一起，才发现MCP的价值。
简单来说，MCP定义了一套标准接口，让不同的工具和服务能够以统一的方式被AI模型调用。在没有MCP之前，每个团队开发的工具都有自己的接口规范，集成的时候需要写大量的适配代码。有了MCP之后，只要工具实现了MCP协议，就可以直接被Agent调用，不需要额外的适配。
这个价值在跨部门协作中尤其明显。我们项目组有三个团队：数据团队提供数据查询工具，算法团队提供分析工具，业务团队提供流程工具。如果每个工具都要单独适配，工作量巨大且容易出错。采用MCP之后，每个团队只需要按照协议实现自己的工具，Agent端统一调用，协作效率提升了很多。
4.2 MCP Server的开发和接入：实际踩过的坑
开发MCP Server的过程并不复杂，但有几个坑值得注意。
第一个坑是工具描述的编写。MCP协议要求每个工具提供描述信息，模型根据描述来决定是否调用。我们一开始写的描述很技术化，比如"执行SQL查询并返回结果"，结果模型经常在不该调用的时候调用。后来我们把描述改成了业务语言，比如"查询销售数据，支持按时间、地区、产品筛选"，模型的调用准确率明显提升。
第二个坑是错误处理。MCP协议定义了错误返回的格式，但实际开发中，很多工具的内部错误没有正确转换成MCP格式，导致Agent端收到错误后无法正确处理。我们后来统一了错误处理逻辑，把所有内部错误都转换成MCP标准错误，并在错误信息里包含足够的上下文，方便模型决定下一步。
第三个坑是权限控制。跨部门协作中，不同团队的工具可能有不同的权限要求。MCP协议本身不定义权限模型，需要我们在实现层面自己处理。我们后来在MCP Server里加了一层权限校验，根据调用方的身份和请求的参数来决定是否允许调用。
4.3 MCP和Function Calling的关系：不是替代，是互补
很多人会问：有了Function Calling，为什么还需要MCP？我在实际项目中理解了两者的关系。
Function Calling是模型层面的能力，它让模型能够决定调用哪个函数、传入什么参数。MCP是工具层面的协议，它让不同的工具能够以统一的方式被调用。两者是互补的：Function Calling负责"决策"，MCP负责"执行"。
在实际项目中，我们用Function Calling让模型决定需要调用什么能力，然后用MCP去实际调用对应的工具。这样既保留了模型的灵活性，又保证了工具集成的标准化。课程里没有明确讲这个关系，但我在实际使用中发现，把两者结合起来，Agent的开发效率和可维护性都会好很多。
5. 跨部门协作中，AI知识打底带来的隐性优势
5.1 技术术语对齐：减少沟通成本的关键
跨部门协作中，最大的成本往往是沟通成本。不同团队有自己的术语体系，同一个概念可能有不同的叫法。我在课程里学到的那些术语，在协作中意外地成为了"通用语言"。
比如"RAG"这个词，数据团队可能叫"知识检索"，算法团队可能叫"检索增强生成"，业务团队可能完全不知道这是什么。但当我用课程里学到的标准术语去沟通时，大家很快就能对齐理解。同样，"Agent""Function Calling""MCP"这些词，虽然不同团队可能有不同的实现，但概念层面是相通的。
这种术语对齐带来的效率提升是隐性的，但非常明显。我后来在项目组里做了一个简单的术语对照表，把课程里学到的标准术语和各个团队的习惯叫法对应起来，新加入的同事可以快速上手。
5.2 技术方案评审时，我能听懂"弦外之音"
课程里不仅讲了技术概念，还讲了技术选型的权衡。这些内容在技术方案评审时特别有用。
比如算法团队提出要用某个向量数据库，我能听懂他们说的"召回率""延迟""索引类型"是什么意思，也能判断他们的选型是否合理。数据团队讨论文档切分策略时，我能理解"固定长度切分"和"语义切分"的取舍。这种理解能力让我在评审中能够提出有价值的问题，而不是只能点头。
还有一个隐性优势是，我能识别出方案中的风险点。课程里讲过很多实际项目中的坑，比如向量维度不匹配、Agent状态丢失、MCP工具描述不清晰等。当评审中有人提出类似方案时，我能及时提醒这些风险，避免项目走弯路。
5.3 从"执行者"到"连接者"的角色转变
上完课程后的十一个月里，我一直在做执行层面的事情。但在跨部门项目中，我发现自己不知不觉变成了"连接者"。
因为我对各个技术领域都有基本的理解，所以能够在不同团队之间做翻译和协调。数据团队不懂Agent的需求，我能帮他们理解；算法团队不懂业务场景，我能帮他们对接；业务团队不懂技术限制，我能帮他们设定合理的预期。
这种角色转变不是刻意追求的，而是知识打底带来的自然结果。课程里学到的那些概念和思路，让我在面对跨领域问题时不会发怵，能够快速找到切入点。这可能是那门课程给我带来的最大价值：不是让我成为某个领域的专家，而是让我成为能够连接不同领域的人。
6. 那些课程里没讲、但实际项目中必须面对的事
6.1 模型选型：不是越贵越好，而是越合适越好
课程里演示用的都是当时比较好的模型，但实际项目中，模型选型要考虑成本、延迟、数据安全等多个因素。
我们项目初期用的是一个大参数量的模型，效果确实好，但成本很高，而且响应速度慢。后来我们做了分级处理：简单的意图识别和查询改写用小模型，复杂的分析和生成用大模型。这样既保证了效果，又控制了成本。
还有一个考虑是数据安全。有些业务数据不能出内网，所以我们部署了本地模型。本地模型的效果可能不如云端模型，但在数据安全面前，这个取舍是必须的。课程里没有展开讲这些实际约束，但我在项目中深刻体会到，技术选型从来不是单纯的技术问题。
6.2 评估体系：怎么证明你的AI系统"好用"
课程里没有讲评估，但实际项目中，评估是绕不过去的。你怎么证明你的RAG系统比之前的关键词搜索好？你怎么证明你的Agent比人工处理效率高？
我们后来建立了一套评估体系：对于RAG，用召回率、准确率、回答相关性等指标；对于Agent，用任务完成率、平均执行步数、用户满意度等指标。评估数据一部分来自人工标注，一部分来自用户反馈。
这个评估体系不是一次性的，而是持续迭代的。我们每周都会跑一次评估，看看指标有没有下降，有没有新的问题出现。这种持续评估的思路课程里没有讲，但我觉得是实际项目中必须的。
6.3 用户预期管理：AI不是万能的
跨部门协作中，最大的挑战之一是非技术同事对AI的预期。有人觉得AI什么都能做，有人觉得AI什么都不靠谱。这两种极端预期都会给项目带来麻烦。
我的经验是，在项目初期就要做预期管理。明确告诉业务方：AI能做什么、不能做什么、在什么条件下效果好、在什么条件下可能失败。我们后来做了一个"能力边界文档"，列出Agent能处理的任务类型和不能处理的任务类型，业务方在提需求之前先对照这个文档，避免不合理的预期。
还有一个经验是，让业务方参与测试。我们定期邀请业务同事来试用Agent，收集他们的反馈。这样既能发现实际问题，又能让业务方对AI的能力有更真实的认知。
7. 如果重新上一次那门课，我会怎么学
7.1 带着场景学，而不是带着笔记本学
回顾那门课程，我最大的遗憾是当时没有带着具体场景去学。课程里讲RAG的时候，我如果当时就想"我手头的文档怎么用RAG处理"，学习效果会好很多。课程里讲Agent的时候，我如果当时就想"我工作中的哪个流程可以用Agent自动化"，理解会更深。
所以我的建议是：如果你正在上类似的课程，不要只是记笔记，而是找一个你实际工作中的场景，把课程内容往这个场景上套。哪怕这个场景很简单，哪怕你暂时没有资源去实现，这种"场景化学习"也会让你的理解深刻很多。
7.2 把课程资料当成"字典"，而不是"小说"
课程资料的价值不在于一次性读完，而在于需要的时候能快速查到。我后来把课程资料按照主题重新整理了一遍，做成了一个简单的索引。当项目中遇到RAG相关的问题时，我去翻RAG那部分的资料；遇到Agent的问题时，去翻Agent那部分。
这种"字典式"的使用方式，让课程资料的价值大大提升。因为实际项目中遇到的问题往往是具体的、局部的，你不需要重新看一遍完整课程，只需要找到对应的那部分内容，重新理解一下。
7.3 找到一起学的人，组成一个"互助小组"
一个人学AI课程，很容易陷入"学完就忘"的困境。我后来和几个同样上过课的朋友组了一个小群，大家在群里分享各自项目中遇到的问题和解决方案。这种互助小组的价值在于：你遇到的问题，可能别人已经踩过坑了；别人的经验，可能正好能解决你的问题。
我们群里有一个约定：每个人每个月至少分享一个实际项目中的案例。这个约定逼着大家把课程知识用到实际项目中，也逼着大家把经验整理出来分享。这种输出倒逼输入的方式，效果比单纯听课好很多。
8. 写在最后：打底的价值，在需要的时候才会显现
结课十一个月，我才真正理解那门课程的价值。它不是教你某个具体的工具或技术，而是给你一套理解AI应用开发的框架。这套框架在你没有场景的时候可能感觉不到，但当你真正面对一个AI项目时，它会帮你快速找到方向。
跨部门协作中，我最大的体会是：技术知识的价值不仅在于你会不会用，更在于你能不能和别人对齐、能不能判断方案的合理性、能不能识别潜在的风险。这些能力，都是那门课程在不知不觉中帮我打下的底子。
如果你也上过类似的课程，不要觉得"学完没用"。那些知识可能正在你的脑子里慢慢发酵，等到合适的场景出现时，它们会自然而然地被激活。你要做的，是保持学习的状态，保持对实际问题的敏感，然后在需要的时候，把那些打底的知识重新捡起来。
