我们长期面对一个有些反常识的处境企业里沉淀了海量的产品手册、销售话术、客户案例、竞品分析和历史方案但真正需要这些知识的人——售前工程师、销售、市场运营却总是找不到、来不及看、用不上。处理客户质疑时依赖于某个资深同事的私人经验写方案时反复复制粘贴旧文档再手工修改发布新功能时市场团队要花一周时间消化技术材料才能产出第一篇推文。这不是执行力问题而是知识没有形成系统。过去几年市场推广相关的技术栈GTM Stack一直在加工具CRM、营销自动化、CDP、呼叫记录、数据看板。工具越来越多但知识依然散落在文档、聊天记录、会议纪要和人的大脑里。最近“Knowledge Systems知识系统”这个概念开始成为新的GTM技术栈背后并不是又换了一轮软件而是AI工程化让知识第一次可以像系统一样被设计、编排和调用。这篇文章想聊清楚一件事为什么知识系统正在成为GTM团队的新基础设施AI Engineer在这个体系里到底做什么以及如果你想在自己团队里落地这么一套系统第一步应该怎么走。1. 为什么知识系统会成为新的GTM技术栈先明确一下GTM的含义。GTM是Go-to-Market的缩写指产品从有了之后到推向市场、触达客户、完成转化的整个过程。传统GTM技术栈主要由CRM客户关系管理、营销自动化、线索管理、数据分析等“记录型系统”组成。它们擅长回答“客户在哪里”“销售动作发生了什么”但并不擅长回答“客户为什么这么说”“我该怎么回应”“这个方案应该怎么写才更有说服力”。知识系统的出现解决的正是后一类问题。如果把GTM技术栈分成两层底层是记录系统System of Record负责管理客户、线索、合同、订单上层则需要一个推理系统System of Intelligence负责理解客户意图、生成沟通内容、匹配最佳策略。知识系统就是这一层的新基础设施。它和传统知识库最大的区别在于传统知识库是被动查询的人想起来了才去搜索知识系统是主动参与流程的它会出现在销售写邮件、售前做方案、市场写文章、产品做培训这些具体动作中通过大模型和Agent把知识转化为输出。这意味着GTM团队正在经历一次技术升级从“把数据记录在系统里”转向“把知识转化为行动”。正是这种变化让Knowledge Systems成为值得重点关注的新GTM技术栈。对于AI Engineer来说这是一个新的机会窗口。过去AI工程师主要服务推荐系统、风控、搜索这些偏后端的场景而GTM领域因为知识密度高、动作标准化程度低很长一段时间被认为是“AI难以落地”的地方。如今大模型在语言理解和生成上的能力让知识和业务动作之间第一次可以形成自动化闭环。2. 传统GTM技术栈与知识系统的本质差异为了不把“知识系统”变成一个空洞的热词我们需要放到具体对比里去理解。维度传统GTM技术栈知识系统核心任务记录客户、管理流程、统计转化理解上下文、生成内容、推荐策略数据形态结构化数据为主字段、状态、金额结构化与半结构化、非结构化数据并重使用方式人录入、人查看、人分析系统主动检索、推理、生成并介入动作输出物报表、看板、提醒话术、方案、邮件、内容、客户洞察处理单元记录Record知识与上下文Knowledge Context价值衡量数据是否准确、流程是否高效回答是否准确、决策是否更优、内容是否有效传统GTM技术栈的价值是被动的它帮助企业更高效地“管理客户”。知识系统的价值是主动的它帮助企业更准确地“理解客户并采取行动”。举一个具体的场景。公司准备发布新产品市场部需要写一份产品定位说明过去这个过程中市场人员要找产品经理要功能清单找研发看技术架构找销售要客户反馈找客服要常见问题自己消化所有材料提炼卖点产出文档。整个过程可能要一周而且高度依赖人。知识系统化之后这些资料被提前接入知识库AI Agent可以在几分钟内生成一版包含功能要点、技术优势、适用客户画像和常见问答的初稿市场人员基于初稿做判断式修改而不是从零开始。这里的关键在于知识系统不是简单地“把文档喂给大模型”而是把知识获取、知识组织、知识推理、知识应用整合成一个可编排的系统。3. 知识系统背后的核心技术概念要理解知识系统至少有四个概念需要拎清楚RAG、Agent、Skill、知识图谱。它们不是互相替代的关系而是不同层次上的组件。3.1 RAG知识系统的基础检索骨架RAGRetrieval-Augmented Generation检索增强生成是知识系统最核心的机制。它的基本思路是不直接让大模型凭空回答而是先从知识库中检索出相关的资料片段再把这些片段作为上下文提供给大模型让它基于这些材料生成答案。这样做的好处非常直接知识更新快大模型不需要重新训练更新知识库即可答案可溯源可以指出来自哪份文档方便核查降低幻觉风险模型基于给定材料回答而不是依赖内部记忆。RAG是整个知识系统的“地基”没有它后面的Agent和Skill都无从谈起。3.2 Agent从问答到执行RAG解决的是“回答”问题Agent解决的是“执行”问题。Agent是一个智能体它可以根据任务目标自己规划步骤、调用工具、检查结果、调整动作。在GTM场景中Agent的价值在于能够完成一个相对完整的工作流。例如当客服收到一条客户消息时Agent可以先调用客户管理系统获取客户信息再检索知识库里相关的产品文档和历史案例然后生成一版针对性回复最后把这次沟通记录写回系统。这种多次调用工具、多步骤完成的交互是单个RAG问答链路无法完成的。3.3 Skill让Agent学会特定业务动作Skill可以理解为赋予Agent的一种“技能包”。就像一个新人销售需要学习如何破冰、如何报价、如何处理异议一样Agent也需要针对具体业务场景训练和配置对应的技能。一个Skill通常包含触发条件什么情况下使用这个技能执行流程先做什么、再做什么参考知识调用哪些知识库和文档输出模板最终应该产出什么样的格式。Skill的意义在于把 Agent 的通用能力变成业务团队可描述、可复制、可优化的标准化能力。3.4 知识图谱让知识之间产生关联知识图谱解决的是知识之间关系的问题。文档是离散的但业务问题是关联的。客户问“私有化部署”背后关联的可能是“安全合规”“运维成本”“数据隔离”“部署周期”等多个话题。知识图谱通过实体和关系把“私有化部署”和“数据不出域”“内网环境”“合规要求”等概念关联起来。当知识检索遇到图谱时系统不仅能找到内容匹配的片段还能顺着关系找到更全面的上下文。需要说明的是并不是所有知识系统都必须用知识图谱。很多场景下做好RAG和Agent编排就已经能产生价值。知识图谱更适合知识密度高、关联关系复杂的场景比如大型企业售前体系、复杂产品矩阵的市场知识库。4. AI Engineer 在知识系统建设中的角色“AI Engineer”这个名字在标题中很显眼。它到底是一个什么样的角色与传统机器学习工程师偏向模型训练不同AI Engineer更关注如何把已有的模型、工具、数据和业务场景高效集成。在GTM知识系统建设中AI Engineer做的不是训练模型而是构建“知识到行动”的管道。具体来说AI Engineer的工作包含以下几个方面第一知识源的接入和治理。企业内部的知识散落在各种地方产品文档、销售手册、FAQ、会议纪要、邮件、工单系统。AI Engineer需要定义哪些知识需要接入、以什么格式接入、如何清洗和去重、如何做版本管理。第二检索质量的调优。RAG系统的效果好坏很大程度上取决于文档切分、向量化、重排序这些细节。AI Engineer需要根据业务反馈不断调整检索策略减少“查不到”和“查不准”。第三Agent与Skill的编排。这是AI Engineer最核心的增量工作。设计Agent的任务分解逻辑配置Skill的触发条件和执行流程定义Agent调用外部工具CRM、邮件、文档系统的方式并保证整个过程在权限允许的范围内运转。第四效果的评估与迭代。与业务指标联动比如知识回答的被采纳率、售前方案生成的时间缩短比例、销售自助获取信息的成功率用这些指标反推系统优化方向。换句话说AI Engineer是知识系统建设的“架构师交付工程师”同时也是业务团队和技术模型之间的翻译器。这个角色在GTM领域越来越重要是因为GTM知识系统的难点已经从模型能力转移到了工程整合能力。5. 环境准备与项目结构下面用一个最小示例来演示“从知识源到GTM Agent”的实现路径。示例选用Python生态使用LangChain作为编排框架、Chroma作为本地向量库。整体设计偏教学化实际生产环境可以根据团队技术栈替换组件但核心思路是通用的。5.1 环境要求建议使用以下环境Python 3.10 或以上版本一个可用的OpenAI API Key或兼容接口的其他大模型服务操作系统不限Windows / macOS / Linux 均可建议使用虚拟环境管理依赖关于具体库的版本这里以官方最新稳定版为准。大模型和编排框架的API迭代较快本文重点演示通用思路不要将示例代码中的写法视为永久API。5.2 安装依赖python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate pip install langchain langchain-openai langchain-community chromadb5.3 项目目录结构gtm-knowledge-system/ ├── knowledge_sources/ │ ├── product.md # 产品功能说明 │ ├── cases.md # 客户案例 │ └── faq.md # 常见问题 ├── src/ │ ├── knowledge_loader.py # 知识加载与切分 │ ├── knowledge_store.py # 向量化与检索 │ └── gtm_agent.py # GTM Agent 示例 ├── data/ │ └── chroma_gtm/ # 向量库存储目录 └── .env # 环境变量6. 完整示例从知识源到 GTM Agent6.1 第一步准备知识源文件创建一个示例产品文档路径为knowledge_sources/product.md。这里用一段简化文本演示实际项目中你需要把产品手册、竞品对比、客户案例等内容放进来。# 产品A 功能说明 产品A 是一款面向中大型企业的数据分析平台支持私有化部署和SaaS两种模式。 私有化部署的核心优势 - 数据不出域满足金融、政务、医疗等行业合规要求 - 支持内网环境可在无外网条件下运行 - 可与客户现有单点登录系统集成 - 支持与客户数据仓库进行双向数据同步。 主要功能模块 - 数据接入与清洗 - 可视化报表与自助分析 - 智能预警与异常检测 - 权限管理与审计日志。 适用客户场景 - 企业已有数据仓库希望提升内部数据分析效率 - 对数据安全和合规要求较高的行业 - 需要自建数据分析平台但缺乏完整开发资源的团队。6.2 第二步加载与切分知识创建src/knowledge_loader.py负责读取目录下的文档并切分成适合检索的片段。# 文件路径src/knowledge_loader.py from langchain_community.document_loaders import DirectoryLoader from langchain_text_splitters import RecursiveCharacterTextSplitter loader DirectoryLoader( ./knowledge_sources/gtm, glob**/*.md, show_progressTrue, ) documents loader.load() print(f共加载 {len(documents)} 个文档) splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap100, ) chunks splitter.split_documents(documents) print(f切分为 {len(chunks)} 个片段)这里的关键参数是chunk_size和chunk_overlap。片段太短信息不完整太长检索精度下降。800字符加上100字符重叠是一个适合产品文档类知识的起始值具体需要根据内容结构调整。6.3 第三步向量化并建立检索库创建src/knowledge_store.py将切分后的文档片段embedding化存入Chroma向量数据库。# 文件路径src/knowledge_store.py import os from dotenv import load_dotenv from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma load_dotenv() # 1. 加载上一步切分好的文档 from knowledge_loader import chunks # 2. 初始化 embedding 模型 embedding OpenAIEmbeddings(modeltext-embedding-3-small) # 3. 写入向量数据库并持久化 vector_store Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./data/chroma_gtm, ) print(向量库建立完成) # 4. 测试检索 retriever vector_store.as_retriever( search_typesimilarity, search_kwargs{k: 5}, ) query 产品A的私有化部署有哪些合规优势 results retriever.invoke(query) for i, doc in enumerate(results, start1): print(f第 {i} 个结果) print(doc.page_content) print(---)这一步是RAG系统中的关键环节。文本被转换成向量后检索时通过向量相似度找到语义上最接近的片段而不是依赖关键词匹配这是它与传统搜索引擎的核心区别。6.4 第四步构建 GTM Agent创建src/gtm_agent.py这次不是简单做“问答”而是构建一个Agent让它可以基于检索工具完成更复杂的GTM任务——比如生成一段标准应答话术。# 文件路径src/gtm_agent.py import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate from langchain.tools.retriever import create_retriever_tool from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings load_dotenv() # 1. 加载向量库和检索器 embedding OpenAIEmbeddings(modeltext-embedding-3-small) vector_store Chroma( persist_directory./data/chroma_gtm, embedding_functionembedding, ) retriever vector_store.as_retriever( search_typesimilarity, search_kwargs{k: 5}, ) # 2. 创建检索工具 tool create_retriever_tool( retriever, namegtm_knowledge_search, description检索产品手册、客户案例、竞品对比等市场推广相关知识。当需要回答客户问题或生成沟通内容时使用。, ) # 3. 初始化大模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0) # 4. 构造 Prompt prompt ChatPromptTemplate.from_messages([ ( system, 你是GTM助手协助市场、销售和售前团队完成日常工作。 回答时只依据检索到的知识库内容不要编造事实。 如果知识库没有相关信息请明确告知用户。, ), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 5. 构建 Agent agent create_tool_calling_agent(llm, [tool], prompt) executor AgentExecutor( agentagent, tools[tool], verboseTrue, handle_parsing_errorsTrue, ) # 6. 运行一个典型GTM任务 question ( 请帮我们生成一段客服话术客户打电话来询问产品A的私有化部署方式 重点说明数据合规优势和内网部署能力语气要专业且友好。 ) response executor.invoke({input: question}) print(response[output])这个示例展示了Agent和普通RAG问答之间的区别Agent不是在单次检索后直接生成答案而是通过工具调用获取信息并经模型推理后生成符合任务要求的输出。对话过程中Agent可以决定“我需不需要检索”“检索什么”“如何基于检索结果组织输出”这种主动性是GTM场景中处理复杂业务问题的关键。6.5 补充让Agent支持多轮上下文如果你希望Agent在一次会话中记住前面聊过的内容可以把消息历史传给Executorfrom langchain_core.messages import HumanMessage, AIMessage, SystemMessage # 历史消息示例客户之前问过部署模式 chat_history [ SystemMessage(content你是GTM助手只依据知识库内容回答。), HumanMessage(content产品A支持哪些部署模式), AIMessage(content产品A支持私有化部署和SaaS两种模式其中私有化部署可满足数据不出域的合规要求。), ] response executor.invoke({ input: 那私有化部署需要多长时间, chat_history: chat_history, })实际落地时你可以用数据库存储会话消息并在每次调用时把最近N轮历史传入Prompt。7. 运行结果与效果验证7.1 运行步骤先确认.env文件内容OPENAI_API_KEYsk-你的密钥执行向量库建立脚本第一次会下载相关模型权重和构建索引cd src python knowledge_store.py预期输出类似共加载 3 个文档 切分为 18 个片段 向量库建立完成 第 1 个结果 # 产品A 功能说明 产品A 是一款面向中大型企业的数据分析平台支持私有化部署和SaaS两种模式。 ...然后执行Agent脚本python gtm_agent.pyAgent会先打印检索工具调用的过程最终输出一段基于知识库生成的应答话术。7.2 如何判断成功回答中引用的信息与知识库内容一致没有无中生有的细节回答结构符合GTM场景要求比如先表达理解、再说产品优势、最后引导下一步检索出的片段与问题语义相关而不是只匹配了少量关键词。如果发现回答与知识库不符优先检查检索是否返回了正确的片段。可以在Agent之外单独测试检索器观察返回结果是否合理。8. 常见问题与排查思路问题现象可能原因排查方式解决方案回答中出现了知识库没有的信息检索结果不相关模型只能基于自身知识生成打印检索返回的片段确认是否包含答案相关证据调整chunk_size、增加检索数量、补充重排序环节检索结果很相似但答非所问文档切分不合理语义被截断检查片段上下文是否完整增大chunk_overlap或改为按标题/章节结构切分Agent没有使用工具就直接回答工具描述不清楚模型判断无需检索查看Agent日志观察是否调用工具优化tool描述明确告知“什么时候必须使用工具”回答风格太像机器不够贴近业务Prompt中缺少业务语境检查System Prompt是否定义了角色和表达要求在Prompt中加入GTM场景说明、语气要求和输出模板向量库建立耗时太长文档数量多或使用了大模型embedding查看日志定位耗时环节使用批量embedding、优化批量大小或换用更快的embedding服务私有部署知识经常查不到知识库中相关文档缺失或表述不一致在知识库中搜索关键词变体补充文档增加同义词和别名内容排查的最核心思路是把链路拆开定位问题在哪一段。先检查知识库有没有这条知识再检查检索返回了什么最后检查模型基于什么上下文生成了什么答案。只要链路透明问题就一定能复现和定位。9. 最佳实践与工程建议知识系统的技术实现并不复杂复杂的是让它真正在GTM团队里产生持续价值。基于这类项目在工程侧的一般经验有几点建议值得提前想清楚。第一从最小闭环开始不追求一步到位。不要一开始就想着把所有文档接入、把所有场景Agent化。选择一个最痛的场景比如“售前方案素材检索”或“客服标准话术生成”先跑通再扩展。最小闭环的好处是能让业务团队在几天内看到效果也更容易收集真实反馈。第二知识治理是最大的工程。很多知识系统项目最后失败不是模型不行而是知识源太乱。同一款产品的功能描述在不同文档里可能有两种说法旧版本的材料没有归档竞品信息散落在销售个人笔记中。AI Engineer要推动建立知识源的所有权、更新频率、质量标准和版本管理机制。第三权限与安全必须前置。知识系统一旦接入企业知识库就涉及大量敏感业务信息。在架构设计阶段就要明确什么角色可以查询什么内容Agent能否调用内外部工具知识库访问是否需要审计。最小权限原则在这里同样适用宁可初始权限收得紧一些后续根据业务需要再放宽。第四效果评估要与业务指标挂钩。技术指标如检索准确率、召回率很重要但业务团队真正关心的是“上周客服自助解决问题的比例有没有提升”“方案准备时间有没有缩短”。建议在系统上线前定义好基线上线后再持续跟踪用业务结果倒推技术优化方向。第五Agent是用来辅助人不是用来替代人。目前GTM知识系统最合理的定位是“增强型助手”它负责处理重复性信息收集、初稿生成、要点提炼人类负责判断、决策和最终执笔。如果想让系统承担更高频的业务动作一定要在一段时间内保持人在回路中逐步积累置信度数据后再放开。第六可观测性必不可少。要给Agent加上日志追踪记录每次调用的输入、检索结果、模型输出和人工反馈。只有看到完整的执行记录才能持续优化Prompt、检索策略和Skill配置也才能在出现错误时快速定位原因。10. 总结与后续学习方向知识系统成为新的GTM技术栈本质原因是大型模型的工程化让企业第一次能把“组织知识”和“业务动作”连接起来。传统GTM技术栈管理的是客户和流程知识系统管理的是认知和响应能力。它对AI Engineer提出了一种新的能力要求不仅懂模型和工程还要能深入理解GTM业务场景把散落的知识变成可检索、可编排、可评估的系统资产。如果你打算切入这个方向建议按这样的路径推进先掌握RAG的基本实现跑通一个文档问答原型再学习Agent和Tool Calling机制让系统具备调用外部动作的能力然后选择一个具体的GTM场景做深度优化比如售前方案生成或客户异议处理最后再考虑知识图谱和更复杂的编排设计。真正拉开差距的不是模型选择而是对业务的理解和知识治理的扎实程度。知识系统不是一个一次性交付的项目它是一个需要持续运营和迭代的基础设施。谁能让它贴合业务团队的真实工作流谁就能在即将到来的GTM智能化周期里占据先机。 知识系统如何成为GTM新基础设施：从RAG到AI Agent实战
我们长期面对一个有些反常识的处境企业里沉淀了海量的产品手册、销售话术、客户案例、竞品分析和历史方案但真正需要这些知识的人——售前工程师、销售、市场运营却总是找不到、来不及看、用不上。处理客户质疑时依赖于某个资深同事的私人经验写方案时反复复制粘贴旧文档再手工修改发布新功能时市场团队要花一周时间消化技术材料才能产出第一篇推文。这不是执行力问题而是知识没有形成系统。过去几年市场推广相关的技术栈GTM Stack一直在加工具CRM、营销自动化、CDP、呼叫记录、数据看板。工具越来越多但知识依然散落在文档、聊天记录、会议纪要和人的大脑里。最近“Knowledge Systems知识系统”这个概念开始成为新的GTM技术栈背后并不是又换了一轮软件而是AI工程化让知识第一次可以像系统一样被设计、编排和调用。这篇文章想聊清楚一件事为什么知识系统正在成为GTM团队的新基础设施AI Engineer在这个体系里到底做什么以及如果你想在自己团队里落地这么一套系统第一步应该怎么走。1. 为什么知识系统会成为新的GTM技术栈先明确一下GTM的含义。GTM是Go-to-Market的缩写指产品从有了之后到推向市场、触达客户、完成转化的整个过程。传统GTM技术栈主要由CRM客户关系管理、营销自动化、线索管理、数据分析等“记录型系统”组成。它们擅长回答“客户在哪里”“销售动作发生了什么”但并不擅长回答“客户为什么这么说”“我该怎么回应”“这个方案应该怎么写才更有说服力”。知识系统的出现解决的正是后一类问题。如果把GTM技术栈分成两层底层是记录系统System of Record负责管理客户、线索、合同、订单上层则需要一个推理系统System of Intelligence负责理解客户意图、生成沟通内容、匹配最佳策略。知识系统就是这一层的新基础设施。它和传统知识库最大的区别在于传统知识库是被动查询的人想起来了才去搜索知识系统是主动参与流程的它会出现在销售写邮件、售前做方案、市场写文章、产品做培训这些具体动作中通过大模型和Agent把知识转化为输出。这意味着GTM团队正在经历一次技术升级从“把数据记录在系统里”转向“把知识转化为行动”。正是这种变化让Knowledge Systems成为值得重点关注的新GTM技术栈。对于AI Engineer来说这是一个新的机会窗口。过去AI工程师主要服务推荐系统、风控、搜索这些偏后端的场景而GTM领域因为知识密度高、动作标准化程度低很长一段时间被认为是“AI难以落地”的地方。如今大模型在语言理解和生成上的能力让知识和业务动作之间第一次可以形成自动化闭环。2. 传统GTM技术栈与知识系统的本质差异为了不把“知识系统”变成一个空洞的热词我们需要放到具体对比里去理解。维度传统GTM技术栈知识系统核心任务记录客户、管理流程、统计转化理解上下文、生成内容、推荐策略数据形态结构化数据为主字段、状态、金额结构化与半结构化、非结构化数据并重使用方式人录入、人查看、人分析系统主动检索、推理、生成并介入动作输出物报表、看板、提醒话术、方案、邮件、内容、客户洞察处理单元记录Record知识与上下文Knowledge Context价值衡量数据是否准确、流程是否高效回答是否准确、决策是否更优、内容是否有效传统GTM技术栈的价值是被动的它帮助企业更高效地“管理客户”。知识系统的价值是主动的它帮助企业更准确地“理解客户并采取行动”。举一个具体的场景。公司准备发布新产品市场部需要写一份产品定位说明过去这个过程中市场人员要找产品经理要功能清单找研发看技术架构找销售要客户反馈找客服要常见问题自己消化所有材料提炼卖点产出文档。整个过程可能要一周而且高度依赖人。知识系统化之后这些资料被提前接入知识库AI Agent可以在几分钟内生成一版包含功能要点、技术优势、适用客户画像和常见问答的初稿市场人员基于初稿做判断式修改而不是从零开始。这里的关键在于知识系统不是简单地“把文档喂给大模型”而是把知识获取、知识组织、知识推理、知识应用整合成一个可编排的系统。3. 知识系统背后的核心技术概念要理解知识系统至少有四个概念需要拎清楚RAG、Agent、Skill、知识图谱。它们不是互相替代的关系而是不同层次上的组件。3.1 RAG知识系统的基础检索骨架RAGRetrieval-Augmented Generation检索增强生成是知识系统最核心的机制。它的基本思路是不直接让大模型凭空回答而是先从知识库中检索出相关的资料片段再把这些片段作为上下文提供给大模型让它基于这些材料生成答案。这样做的好处非常直接知识更新快大模型不需要重新训练更新知识库即可答案可溯源可以指出来自哪份文档方便核查降低幻觉风险模型基于给定材料回答而不是依赖内部记忆。RAG是整个知识系统的“地基”没有它后面的Agent和Skill都无从谈起。3.2 Agent从问答到执行RAG解决的是“回答”问题Agent解决的是“执行”问题。Agent是一个智能体它可以根据任务目标自己规划步骤、调用工具、检查结果、调整动作。在GTM场景中Agent的价值在于能够完成一个相对完整的工作流。例如当客服收到一条客户消息时Agent可以先调用客户管理系统获取客户信息再检索知识库里相关的产品文档和历史案例然后生成一版针对性回复最后把这次沟通记录写回系统。这种多次调用工具、多步骤完成的交互是单个RAG问答链路无法完成的。3.3 Skill让Agent学会特定业务动作Skill可以理解为赋予Agent的一种“技能包”。就像一个新人销售需要学习如何破冰、如何报价、如何处理异议一样Agent也需要针对具体业务场景训练和配置对应的技能。一个Skill通常包含触发条件什么情况下使用这个技能执行流程先做什么、再做什么参考知识调用哪些知识库和文档输出模板最终应该产出什么样的格式。Skill的意义在于把 Agent 的通用能力变成业务团队可描述、可复制、可优化的标准化能力。3.4 知识图谱让知识之间产生关联知识图谱解决的是知识之间关系的问题。文档是离散的但业务问题是关联的。客户问“私有化部署”背后关联的可能是“安全合规”“运维成本”“数据隔离”“部署周期”等多个话题。知识图谱通过实体和关系把“私有化部署”和“数据不出域”“内网环境”“合规要求”等概念关联起来。当知识检索遇到图谱时系统不仅能找到内容匹配的片段还能顺着关系找到更全面的上下文。需要说明的是并不是所有知识系统都必须用知识图谱。很多场景下做好RAG和Agent编排就已经能产生价值。知识图谱更适合知识密度高、关联关系复杂的场景比如大型企业售前体系、复杂产品矩阵的市场知识库。4. AI Engineer 在知识系统建设中的角色“AI Engineer”这个名字在标题中很显眼。它到底是一个什么样的角色与传统机器学习工程师偏向模型训练不同AI Engineer更关注如何把已有的模型、工具、数据和业务场景高效集成。在GTM知识系统建设中AI Engineer做的不是训练模型而是构建“知识到行动”的管道。具体来说AI Engineer的工作包含以下几个方面第一知识源的接入和治理。企业内部的知识散落在各种地方产品文档、销售手册、FAQ、会议纪要、邮件、工单系统。AI Engineer需要定义哪些知识需要接入、以什么格式接入、如何清洗和去重、如何做版本管理。第二检索质量的调优。RAG系统的效果好坏很大程度上取决于文档切分、向量化、重排序这些细节。AI Engineer需要根据业务反馈不断调整检索策略减少“查不到”和“查不准”。第三Agent与Skill的编排。这是AI Engineer最核心的增量工作。设计Agent的任务分解逻辑配置Skill的触发条件和执行流程定义Agent调用外部工具CRM、邮件、文档系统的方式并保证整个过程在权限允许的范围内运转。第四效果的评估与迭代。与业务指标联动比如知识回答的被采纳率、售前方案生成的时间缩短比例、销售自助获取信息的成功率用这些指标反推系统优化方向。换句话说AI Engineer是知识系统建设的“架构师交付工程师”同时也是业务团队和技术模型之间的翻译器。这个角色在GTM领域越来越重要是因为GTM知识系统的难点已经从模型能力转移到了工程整合能力。5. 环境准备与项目结构下面用一个最小示例来演示“从知识源到GTM Agent”的实现路径。示例选用Python生态使用LangChain作为编排框架、Chroma作为本地向量库。整体设计偏教学化实际生产环境可以根据团队技术栈替换组件但核心思路是通用的。5.1 环境要求建议使用以下环境Python 3.10 或以上版本一个可用的OpenAI API Key或兼容接口的其他大模型服务操作系统不限Windows / macOS / Linux 均可建议使用虚拟环境管理依赖关于具体库的版本这里以官方最新稳定版为准。大模型和编排框架的API迭代较快本文重点演示通用思路不要将示例代码中的写法视为永久API。5.2 安装依赖python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate pip install langchain langchain-openai langchain-community chromadb5.3 项目目录结构gtm-knowledge-system/ ├── knowledge_sources/ │ ├── product.md # 产品功能说明 │ ├── cases.md # 客户案例 │ └── faq.md # 常见问题 ├── src/ │ ├── knowledge_loader.py # 知识加载与切分 │ ├── knowledge_store.py # 向量化与检索 │ └── gtm_agent.py # GTM Agent 示例 ├── data/ │ └── chroma_gtm/ # 向量库存储目录 └── .env # 环境变量6. 完整示例从知识源到 GTM Agent6.1 第一步准备知识源文件创建一个示例产品文档路径为knowledge_sources/product.md。这里用一段简化文本演示实际项目中你需要把产品手册、竞品对比、客户案例等内容放进来。# 产品A 功能说明 产品A 是一款面向中大型企业的数据分析平台支持私有化部署和SaaS两种模式。 私有化部署的核心优势 - 数据不出域满足金融、政务、医疗等行业合规要求 - 支持内网环境可在无外网条件下运行 - 可与客户现有单点登录系统集成 - 支持与客户数据仓库进行双向数据同步。 主要功能模块 - 数据接入与清洗 - 可视化报表与自助分析 - 智能预警与异常检测 - 权限管理与审计日志。 适用客户场景 - 企业已有数据仓库希望提升内部数据分析效率 - 对数据安全和合规要求较高的行业 - 需要自建数据分析平台但缺乏完整开发资源的团队。6.2 第二步加载与切分知识创建src/knowledge_loader.py负责读取目录下的文档并切分成适合检索的片段。# 文件路径src/knowledge_loader.py from langchain_community.document_loaders import DirectoryLoader from langchain_text_splitters import RecursiveCharacterTextSplitter loader DirectoryLoader( ./knowledge_sources/gtm, glob**/*.md, show_progressTrue, ) documents loader.load() print(f共加载 {len(documents)} 个文档) splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap100, ) chunks splitter.split_documents(documents) print(f切分为 {len(chunks)} 个片段)这里的关键参数是chunk_size和chunk_overlap。片段太短信息不完整太长检索精度下降。800字符加上100字符重叠是一个适合产品文档类知识的起始值具体需要根据内容结构调整。6.3 第三步向量化并建立检索库创建src/knowledge_store.py将切分后的文档片段embedding化存入Chroma向量数据库。# 文件路径src/knowledge_store.py import os from dotenv import load_dotenv from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma load_dotenv() # 1. 加载上一步切分好的文档 from knowledge_loader import chunks # 2. 初始化 embedding 模型 embedding OpenAIEmbeddings(modeltext-embedding-3-small) # 3. 写入向量数据库并持久化 vector_store Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./data/chroma_gtm, ) print(向量库建立完成) # 4. 测试检索 retriever vector_store.as_retriever( search_typesimilarity, search_kwargs{k: 5}, ) query 产品A的私有化部署有哪些合规优势 results retriever.invoke(query) for i, doc in enumerate(results, start1): print(f第 {i} 个结果) print(doc.page_content) print(---)这一步是RAG系统中的关键环节。文本被转换成向量后检索时通过向量相似度找到语义上最接近的片段而不是依赖关键词匹配这是它与传统搜索引擎的核心区别。6.4 第四步构建 GTM Agent创建src/gtm_agent.py这次不是简单做“问答”而是构建一个Agent让它可以基于检索工具完成更复杂的GTM任务——比如生成一段标准应答话术。# 文件路径src/gtm_agent.py import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate from langchain.tools.retriever import create_retriever_tool from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings load_dotenv() # 1. 加载向量库和检索器 embedding OpenAIEmbeddings(modeltext-embedding-3-small) vector_store Chroma( persist_directory./data/chroma_gtm, embedding_functionembedding, ) retriever vector_store.as_retriever( search_typesimilarity, search_kwargs{k: 5}, ) # 2. 创建检索工具 tool create_retriever_tool( retriever, namegtm_knowledge_search, description检索产品手册、客户案例、竞品对比等市场推广相关知识。当需要回答客户问题或生成沟通内容时使用。, ) # 3. 初始化大模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0) # 4. 构造 Prompt prompt ChatPromptTemplate.from_messages([ ( system, 你是GTM助手协助市场、销售和售前团队完成日常工作。 回答时只依据检索到的知识库内容不要编造事实。 如果知识库没有相关信息请明确告知用户。, ), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 5. 构建 Agent agent create_tool_calling_agent(llm, [tool], prompt) executor AgentExecutor( agentagent, tools[tool], verboseTrue, handle_parsing_errorsTrue, ) # 6. 运行一个典型GTM任务 question ( 请帮我们生成一段客服话术客户打电话来询问产品A的私有化部署方式 重点说明数据合规优势和内网部署能力语气要专业且友好。 ) response executor.invoke({input: question}) print(response[output])这个示例展示了Agent和普通RAG问答之间的区别Agent不是在单次检索后直接生成答案而是通过工具调用获取信息并经模型推理后生成符合任务要求的输出。对话过程中Agent可以决定“我需不需要检索”“检索什么”“如何基于检索结果组织输出”这种主动性是GTM场景中处理复杂业务问题的关键。6.5 补充让Agent支持多轮上下文如果你希望Agent在一次会话中记住前面聊过的内容可以把消息历史传给Executorfrom langchain_core.messages import HumanMessage, AIMessage, SystemMessage # 历史消息示例客户之前问过部署模式 chat_history [ SystemMessage(content你是GTM助手只依据知识库内容回答。), HumanMessage(content产品A支持哪些部署模式), AIMessage(content产品A支持私有化部署和SaaS两种模式其中私有化部署可满足数据不出域的合规要求。), ] response executor.invoke({ input: 那私有化部署需要多长时间, chat_history: chat_history, })实际落地时你可以用数据库存储会话消息并在每次调用时把最近N轮历史传入Prompt。7. 运行结果与效果验证7.1 运行步骤先确认.env文件内容OPENAI_API_KEYsk-你的密钥执行向量库建立脚本第一次会下载相关模型权重和构建索引cd src python knowledge_store.py预期输出类似共加载 3 个文档 切分为 18 个片段 向量库建立完成 第 1 个结果 # 产品A 功能说明 产品A 是一款面向中大型企业的数据分析平台支持私有化部署和SaaS两种模式。 ...然后执行Agent脚本python gtm_agent.pyAgent会先打印检索工具调用的过程最终输出一段基于知识库生成的应答话术。7.2 如何判断成功回答中引用的信息与知识库内容一致没有无中生有的细节回答结构符合GTM场景要求比如先表达理解、再说产品优势、最后引导下一步检索出的片段与问题语义相关而不是只匹配了少量关键词。如果发现回答与知识库不符优先检查检索是否返回了正确的片段。可以在Agent之外单独测试检索器观察返回结果是否合理。8. 常见问题与排查思路问题现象可能原因排查方式解决方案回答中出现了知识库没有的信息检索结果不相关模型只能基于自身知识生成打印检索返回的片段确认是否包含答案相关证据调整chunk_size、增加检索数量、补充重排序环节检索结果很相似但答非所问文档切分不合理语义被截断检查片段上下文是否完整增大chunk_overlap或改为按标题/章节结构切分Agent没有使用工具就直接回答工具描述不清楚模型判断无需检索查看Agent日志观察是否调用工具优化tool描述明确告知“什么时候必须使用工具”回答风格太像机器不够贴近业务Prompt中缺少业务语境检查System Prompt是否定义了角色和表达要求在Prompt中加入GTM场景说明、语气要求和输出模板向量库建立耗时太长文档数量多或使用了大模型embedding查看日志定位耗时环节使用批量embedding、优化批量大小或换用更快的embedding服务私有部署知识经常查不到知识库中相关文档缺失或表述不一致在知识库中搜索关键词变体补充文档增加同义词和别名内容排查的最核心思路是把链路拆开定位问题在哪一段。先检查知识库有没有这条知识再检查检索返回了什么最后检查模型基于什么上下文生成了什么答案。只要链路透明问题就一定能复现和定位。9. 最佳实践与工程建议知识系统的技术实现并不复杂复杂的是让它真正在GTM团队里产生持续价值。基于这类项目在工程侧的一般经验有几点建议值得提前想清楚。第一从最小闭环开始不追求一步到位。不要一开始就想着把所有文档接入、把所有场景Agent化。选择一个最痛的场景比如“售前方案素材检索”或“客服标准话术生成”先跑通再扩展。最小闭环的好处是能让业务团队在几天内看到效果也更容易收集真实反馈。第二知识治理是最大的工程。很多知识系统项目最后失败不是模型不行而是知识源太乱。同一款产品的功能描述在不同文档里可能有两种说法旧版本的材料没有归档竞品信息散落在销售个人笔记中。AI Engineer要推动建立知识源的所有权、更新频率、质量标准和版本管理机制。第三权限与安全必须前置。知识系统一旦接入企业知识库就涉及大量敏感业务信息。在架构设计阶段就要明确什么角色可以查询什么内容Agent能否调用内外部工具知识库访问是否需要审计。最小权限原则在这里同样适用宁可初始权限收得紧一些后续根据业务需要再放宽。第四效果评估要与业务指标挂钩。技术指标如检索准确率、召回率很重要但业务团队真正关心的是“上周客服自助解决问题的比例有没有提升”“方案准备时间有没有缩短”。建议在系统上线前定义好基线上线后再持续跟踪用业务结果倒推技术优化方向。第五Agent是用来辅助人不是用来替代人。目前GTM知识系统最合理的定位是“增强型助手”它负责处理重复性信息收集、初稿生成、要点提炼人类负责判断、决策和最终执笔。如果想让系统承担更高频的业务动作一定要在一段时间内保持人在回路中逐步积累置信度数据后再放开。第六可观测性必不可少。要给Agent加上日志追踪记录每次调用的输入、检索结果、模型输出和人工反馈。只有看到完整的执行记录才能持续优化Prompt、检索策略和Skill配置也才能在出现错误时快速定位原因。10. 总结与后续学习方向知识系统成为新的GTM技术栈本质原因是大型模型的工程化让企业第一次能把“组织知识”和“业务动作”连接起来。传统GTM技术栈管理的是客户和流程知识系统管理的是认知和响应能力。它对AI Engineer提出了一种新的能力要求不仅懂模型和工程还要能深入理解GTM业务场景把散落的知识变成可检索、可编排、可评估的系统资产。如果你打算切入这个方向建议按这样的路径推进先掌握RAG的基本实现跑通一个文档问答原型再学习Agent和Tool Calling机制让系统具备调用外部动作的能力然后选择一个具体的GTM场景做深度优化比如售前方案生成或客户异议处理最后再考虑知识图谱和更复杂的编排设计。真正拉开差距的不是模型选择而是对业务的理解和知识治理的扎实程度。知识系统不是一个一次性交付的项目它是一个需要持续运营和迭代的基础设施。谁能让它贴合业务团队的真实工作流谁就能在即将到来的GTM智能化周期里占据先机。