一个人离职带着三年的踩坑记录走了新人刚来同一批问题在团队里被反复问了一遍又一遍。这个场景我相信每个团队都经历过但真正把它解决掉的产品没几个。腾讯开源的那个 AI 管理项目第一次打动我的不是它又接了多少个大模型而是它把“团队经验自动传承”这件事拆成了一条可以落地的工程链路。它像一把瑞士军刀能抓聊天记录、能抽工单结论、能生成文档、能做问答还能把经验编排成自动化流程。本文不聊大模型跑分也不评价代码风格只从一个使用者的角度聊聊这套开源工具解决什么问题、核心技术怎么拆、落地时怎么避坑。适合技术 Leader、AI 应用开发者、知识管理负责人参考。1. 项目概述为什么需要一把 AI 管理“瑞士军刀”第一次见这个项目是在 GitHub 上搜“AI knowledge management”时刷到的。当时团队正好处于一个很尴尬的阶段核心骨干要调走手上的运维经验、业务规则、客户案例全散落在聊天记录和个人笔记里。我们试过知识库建设但传统的 wiki 根本没人写也试过让老人带新人可老员工自己每天都被钉在工位上处理重复问题。所以当我看到“团队经验自动传承”这个定位时第一反应是这玩意儿能自动从聊天记录里挖出经验不会是又一个套壳笔记软件吧。1.1 传统经验传承的三个痛点传统团队知识管理其实绕不开三个死结。第一文档滞后。项目忙的时候没人会停下来整理文档等有空整理了细节早就忘了。即便写了也常常是“为了写而写”文档里只有操作结果没有思考过程后人照着做还是踩坑。第二人肉问答成本高。新人遇到问题第一反应是去群里问。一个问题有 3 个人回答3 个版本三天后同一个问题又得重新问一遍。专家的时间被大量低水平重复问题占掉真正的技术决策反而没时间做。第三隐性知识断层。很多关键经验不在文档里而在老员工的脑子里。比如“这个服务频繁超时别急着加机器先看连接池配置”“这个客户的数据导入失败多半是编码格式问题”。这些东西没办法通过看代码发现只能靠长期踩坑积累。一旦人走了经验就断了。这三个痛点单独看都难解组合在一起就更麻烦。你缺的不是另一个“文档工具”而是一套能够自动发现、抽取、存储、再用起来的系统。腾讯开源的这个 AI 管理项目本质上就是在做这件事。1.2 这个开源项目解决什么问题这套工具的目标不是让人不写文档而是让“写文档”这件事不再依赖人的主动性和自律。它会把团队日常产生的对话、工单、代码评审意见、会议纪要等“过程数据”自动收集起来用大模型抽取成结构化经验再放进知识库。之后通过问答机器人、搜索、Agent 工作流等方式把经验重新用起来。我测试下来的感受是它把我以前“靠人传承经验”的模式变成了“靠系统传承经验”的模式。老员工的会话记录被自动沉淀成知识新人提问时直接查知识库就能拿到带出处的答案某些高频处理流程还能被固化成一个自动化工作流连人都可以不用介入。当然它也不是银弹。底层的抽取效果取决于模型能力、数据质量和 Prompt 设计权限隔离和成本控制也需要自己花时间调。但至少从架构上它把“经验自动传承”这条链路的每一环都补齐了你不需要从零开发一套。1.3 核心技术组成这套工具底层是一套标准的 AI 应用架构核心模块可以分成六层。模块职责典型技术选型接入层对接 IM、工单、GitLab、会议系统等数据源Webhook、API、定时同步抽取层用 LLM 把原始文本转成结构化知识条目大模型 Prompt 工程存储层保存知识条目、向量、元数据PostgreSQL、pgvector、对象存储索引层建立向量索引和关键字索引支持混合检索Milvus、Qdrant、ES问答层基于 RAG 实现智能问答带引用溯源Embedding Rerank LLMAgent 层把经验编排成可执行的工作流任务编排、API 调用、审批节点这样设计的优势在于每一层都可以独立替换和扩展。想换 embedding 模型改个配置就行。想把知识库从 pgvector 迁到 Milvus接口层适配完即可。这种“瑞士军刀”式的模块化让团队可以根据自己的实际情况做裁剪而不是被某一个供应商绑定。2. 核心细节拆解经验自动传承的四个关键引擎项目能跑通是一回事跑得好是另一回事。要真正实现“自动传承”需要把四个模块做到位经验抽取、知识存储、检索问答、Agent 执行。下面逐个拆。2.1 经验抽取把“聊天记录”变成“结构化知识”经验自动传承的第一步不是存聊天记录而是从聊天记录里抽出“有用结论”。群里 80% 的内容都是寒暄、表情包、进度播报直接喂给大模型只会让知识库变成垃圾场。所以我格外关注工具的抽取设计。正常的处理链路是先拿到原始会话或工单文本然后通过 LLM 抽取关键字段。比如在一个客服群里一段对话是A客户反馈上传 CSV 一直报错。 B看下文件是不是带 BOM 头带的话会多一个看不见的字符。 A确实是去掉后就好了。这条信息如果没人记录三天后就丢了。用抽取模块处理后大概会变成这样一段 JSON{ title: CSV 上传报错处理, category: 数据处理, keywords: [CSV, BOM, 上传报错], problem: 客户上传 CSV 文件报错, solution: 检查文件是否带 BOM 头去除后重试, applicable_scene: 文件导入、数据上传, source: im_group#123, confidence: 0.92 }这条结构化知识进入知识库后后续任何一个人搜“CSV 上传报错”都能命中这段经验。抽取层的核心是 Prompt。我实测下来直接用“请总结这段对话”会得到一堆废话。正确做法是给模型一个模板强制它输出 JSON并且配上几个 Few-shot 示例。我当时用的一个简化 Prompt 模板是你是一个团队知识萃取专家。请从下面的对话/工单中提取可复用的经验。如果包含明确的问题和解法则输出 JSON如果没有有价值信息则输出 {empty: true}。 字段要求 - title: 简短标题 - category: 所属分类 - problem: 遇到的问题 - solution: 解决方案 - keywords: 3-5个关键词 - source: 来源标记 示例 对话用户说登录超时管理员说查一下令牌过期时间。 输出{title:登录超时排查,category:认证,problem:用户登录超时,solution:检查访问令牌过期时间,keywords:[登录,超时,令牌],source:im} 对话 {input_text}这个小细节特别关键。不加 Few-shot 时抽取结果经常漏掉 solution加了之后准确率提升非常明显。另外为了减少噪声建议对聊天数据做一层预过滤比如只保留包含疑问句、解决动词“试试”“改成”“检查”的消息对或者按主题把分散消息聚合到一个会话上下文里再抽取。还有一个很重要的问题脱敏。团队经验里常常混着客户名、手机号、内部代码路径不能直接进知识库。所以我在抽取链路里加了一道脱敏步骤用正则或 NER 模型识别敏感字段替换成占位符。这一步建议放在 LLM 抽取之后、入库之前。2.2 组织与存储为什么选 RAG 而不是微调很多人会问既然要大模型理解经验为什么不直接把团队历史数据拿去微调一个专属模型我的答案是给团队知识库做微调几乎是一件投入产出比极低的事。微调的缺点很明显。第一团队经验每天都在产生微调完成后新知识又出来了模型永远跟不上第二微调会把知识混进模型参数里很难做细粒度的权限隔离——同一个模型没法做到“这个部门看不到那个部门的知识”第三微调成本高需要训练资源、数据清洗和模型部署普通团队根本玩不转。所以这套工具走的路线是 RAG检索增强生成。模型本身不保存团队知识只是根据用户的问题先从向量库里检索出相关片段把片段塞进 Prompt 再生成回答。这样知识库更新只改索引权限隔离可以在检索时按元数据过滤幻觉概率也低得多。存储层我用的是 PostgreSQL pgvector数据量不大时可以省掉独立的向量数据库。核心配置是文档切分。切得太碎语义不完整切得太长检索噪声大。经验值一般是 chunk_size 512 字符、overlap 64 字符但这只是起点。如果文档本身有 Markdown 结构最好按标题切分不要把两个小节拼在一起。切分完后每一条知识还要打上元数据所属团队、项目、时间范围、权限级别、来源类型。这些元数据是后续权限隔离和精细检索的基石。比如运维团队在查询知识时可以强制追加一个过滤条件team ops避免把支付核心团队的数据召回出来。2.3 检索与问答让经验能被“用起来”知识库建好了还得让团队愿意用。这套工具的问答层做得比较完整的点在于它把“检索”和“生成”之间的细节处理得比较细。首先是混合检索。只靠向量相似度经常会漏掉关键词完全匹配的答案只靠 BM25 关键词又理解不了语义。所以问答模块默认跑了“向量召回 关键词召回 重排”。先用两种方式各召回 top 50再用 Rerank 模型比如 bge-reranker把结果重新打分最后取 top 5 喂给大模型。参数上top_k 不能一味求大。我把 top_k 从 5 调到 10发现回答确实变“全”了但幻觉也跟着变多因为模型会把不相关片段强行关联起来。更合理的做法是检索阶段 top_k 可以放到 20 到 30重排后取 top 3 到 top 5。这样既保证召回又保证生成质量。问答 Prompt 也要设计。官方默认的 Prompt 偏通用我改成更贴近团队语境的版本你是团队的智能知识助手。请基于提供的知识片段回答用户问题。规则 1. 只能使用给定片段中的信息不要编造。 2. 回答简洁分步骤说明。 3. 每条结论末尾标注来源编号如 [1][2]。 4. 如果片段不足以回答明确说“知识库中没有找到相关答案”。 知识片段 {context} 用户问题 {question}这样出来的答案末尾会带上引用编号点开就能看到原始来源。这一点是非常重要的“信任建设”——团队刚开始不相信 AI 回答一旦能溯源到某条聊天记录或工单接受度会高很多。问答之后还要有反馈闭环。每条回答下面加“有用/无用”按钮无用的结果会被打回人工审核。这套工具可以把反馈数据回流用作后续检索质量评估和 Prompt 优化。我们上线两周后根据反馈数据发现“问题定位类”的提问比例最高就专门优化了这一类知识的抽取模板效果立刻肉眼可见。2.4 Agent 编排从“能问”到“能执行”问答只是把经验变成“参考”Agent 编排则是把经验变成“执行”。这是我认为“AI 瑞士军刀”这个称呼里最值钱的部分。举个真实的例子。我们的运维群里每天都会出现“某个服务内存告警”的消息。过去处理流程是新人问、老人答然后新人手工敲命令。用这套工具后我们把历史告警处理经验抽取出来编排成一个“告警处理工作流”收到告警事件 → 检索知识库中的处理 SOP → 调用监控 API 获取当前指标 → 判断是否需要人工介入 → 自动在小群里输出处理建议。流程看起来不复杂但实现需要两个前提一是知识库里的经验已经足够结构化能提取出“检查顺序”“判断阈值”“处理动作”二是工具支持把知识条目注册成 Agent 可调用的工具函数。比如一条“内存告警排查 SOP”的知识注册成工具后Agent 就会知道何时调用它、需要哪些输入参数、输出什么格式。还有一个很典型的新人场景入职第一天让新人问知识库“新环境部署需要哪些步骤”系统能给出清单再往下走还可以触发一个“新人环境准备”工作流自动创建账号、分配权限、拉取代码。这项工作如果靠人带至少花半天时间用 Agent 编排后老员工只需要做最后审批。需要注意Agent 自动执行涉及权限变更、数据修改等高风险操作必须加审批节点。我见过不少团队为了追求“全自动”把审批去掉结果 Agent 误删了资源得不偿失。最好的策略是查询和推荐可以全自动变更类操作必须人工确认。3. 实操过程从零搭建一套经验传承系统理论讲完来说实操。以下是我在一个 20 人技术团队里的落地过程每一步都验证过可以直接参考。3.1 环境准备与部署先说硬件。知识库类的应用对算力要求不算高但内存不能太小。如果使用外部大模型 API只跑服务和向量库的话8G 内存的机器就能跑起来如果想本地跑一个 7B 量级的开源模型做抽取建议 32G 内存加一张显存 16G 以上的显卡。我们最初用的是一台 16G 内存的云服务器接的云端 API跑得很稳。部署方式很传统拉到代码仓库后先看docker-compose.yml。核心服务大概包括三个API 服务、向量存储、任务队列。我不贴完整文件只给一个最少可用的编排示例services: api: image: your-registry/ai-knowledge-api:latest ports: - 8080:8080 env_file: - .env depends_on: - db - queue db: image: pgvector/pgvector:pg16 environment: POSTGRES_USER: knowledge POSTGRES_PASSWORD: change-me POSTGRES_DB: knowledge volumes: - db_data:/var/lib/postgresql/data queue: image: redis:7-alpine volumes: - redis_data:/data.env里的静态配置是关键。我通常会检查这几项LLM_API_KEYsk-xxxx LLM_BASE_URLhttps://your-llm-endpoint LLM_MODELyour-chat-model EMBEDDING_MODELyour-embedding-model VECTOR_DB_URLpostgresql://knowledge:change-medb:5432/knowledge DEFAULT_CHUNK_SIZE512 DEFAULT_CHUNK_OVERLAP64 MAX_CONCURRENCY4MAX_CONCURRENCY这个参数容易被忽略。如果同时跑几十个抽取任务LLM API 会被限流。我一开始没设置并发结果抽取任务大量 429后来限制到 4 并发才稳定下来。这个数值要根据你的 API 套餐配额和模型响应速度动态调整原则是“宁可慢不能挂”。3.2 接入数据源部署完成后最繁琐的是接数据。我当时优先接了三类数据源IM 聊天记录、工单系统、代码仓库评审记录。IM 聊天记录一般可以导出成 JSONL每行一条消息。为了让抽取器理解上下文我写了个小程序把单条消息聚合为会话组按同一个话题关键字、时间窗口内、参与人交集三个条件聚合。聚合完的消息组整理成纯文本存成input.txt。脚本大概是这样的import json conversations {} for line in open(im_export.jsonl, encodingutf-8): msg json.loads(line) key (msg[topic], msg[thread_id]) conversations.setdefault(key, []).append( f{msg[sender]}: {msg[content]} ) with open(conversations.txt, w, encodingutf-8) as f: for key, lines in conversations.items(): f.write(\n.join(lines) \n----SPLIT----\n)工单系统接入更直接。调用它提供的开放 API拉取“已解决”状态的工单过滤掉自动生成的工单和评价过低工单把“问题描述”“处理过程”“解决方案”拼成一段文本。这里有一个坑很多工单虽然状态是“已解决”但解决过程并不完整甚至只有一句“重新部署后好了”。这种数据价值很低建议加一个前置过滤解决方案字段少于 30 个字符的工单不进入抽取流程。GitLab 代码评审记录是通过 Webhook 接入的。每次 MR 被合并后系统把评审评论拉下来重点提取“要求修改”“原因说明”和“最终解决方式”。代码评审里的经验特别适合沉淀为“编码规范类”知识比如“不要在事务里做远程调用”这种结论直接来自真实踩坑。3.3 配置经验抽取任务与问答机器人数据源接入后需要创建知识空间。知识空间相当于一个隔离的容器每个团队一个空间。我建了“后端组”“运维组”“产品组”三个空间并在每个空间里配置了不同的数据源和权限成员。抽取任务可以配置为定时执行也可以由 Webhook 触发。我使用的是“新消息进来后 5 分钟触发一次”的低频触发方式避免频繁抽取对 API 造成压力。每次触发时系统会把新聚合的对话喂给抽取模块生成结构化 JSON入向量库。配置抽取 Prompt 时除了第二节提到的通用模板我还针对工单数据准备了一个单独模板。因为工单的结构很明确可以直接把字段映射到 JSON不需要让模型过多理解上下文。问答机器人主要挂在两个地方一个是 IM 群一个是内部的 Web 页面。IM 机器人配置时只需要设置一个回调地址把用户问题 POST 给 API 服务再把回答回传到群里。上线前我列了一个验收 checklist问“CSV 导入失败怎么办”能返回带步骤的答案并标注来源。问“为什么支付回调超时”如果知识库没有明确回答“未找到”。群成员 A 看不到其他部门权限范围内的知识。回答带有“有用/无用”反馈按钮且反馈数据能回流。高耗时查询不超过 10 秒。这些看起来基础但每一条都对应着真实使用体验。尤其“找不到就明确说找不到”这一条能避免机器人一本正经地胡说八道。3.4 上线后的调优指标系统上线只是一个开始。我建议从上线第一天起就记录四个核心指标持续调优。指标计算方式初期目标知识覆盖率知识库能命中的问题数 / 团队总问题数 60%回答采纳率用户点击“有用”次数 / 总反馈次数 70%抽取准确率人工抽检 100 条知识可用条数占比 80%新人上手效率新员工完成常见任务的平均用时下降 30%如果知识覆盖率低说明数据源接入不够优先增加数据接入渠道如果回答采纳率低重点检查检索和 Prompt如果抽取准确率低大概率是数据质量不行或 Few-shot 示例太少如果新人上手效率没变化多半是知识库使用入口太深大家根本不打开。4. 常见问题与排查实录落地过程中一定会踩坑。下面这几个问题是我自己遇到的也帮几个朋友团队排查过按出现频率排序。4.1 抽取结果太泛没有可用信息上线第一周我打开知识库一看抽出来的大量条目都是“某个问题出现了大家讨论了一下”。没有明确的解决过程也没有可复用的结论。原因有两个一是输入数据太碎片化单独两三条消息构不成完整上下文二是 Prompt 太开放模型不知道该输出什么。解决办法是双管齐下。首先在数据预处理阶段把同一主题的会话聚合到足够上下文至少包含“问题提出→讨论分析→最终结论”三段如果一段对话没有结论就不进抽取队列。其次修改 Prompt强制要求 “solution” 字段里必须包含动作和效果并对没有 solution 的结果标记为 empty。我还加了两个 Few-shot 示例一个正例、一个反例模型输出质量明显提升。4.2 问答答非所问用户问“订单超时怎么办”机器人答“订单超时可能是网络原因请检查网络”。这个回答看着对但解决不了问题因为没有结合团队内部的实际经验。我排查时先看召回结果检索出的 top 3 片段到底有没有包含“订单超时”的历史处理方案。结果发现原始知识片段被切碎了问题在对话开头解决方案在几十行之后chunk 没包含到。这里靠调参数解决把 chunk_size 从 512 调到 768overlap 从 64 调到 128同时启用了“按会话边界切分”保证同一个问题讨论不会被切断。还有一个更隐蔽的问题用户问题里的“订单超时”和知识库里的“交易超时”在向量空间里相似度不够高但关键词不同。这就要靠混合检索里的 BM25 来兜底把关键词匹配的结果也带上。4.3 权限隔离怎么做我第一次上生产的时候考虑到安全问题没有直接开放所有知识。每个知识条目入库时都会带上permission_group字段比如backend、ops、product。检索时要求必须带群组过滤# 伪代码演示权限过滤 user_group get_current_user_group() results vector_store.search( queryquestion, filter{permission_group: user_group}, top_k20 )用 PostgreSQL 做向量存储时pgvector 支持在 SQL 里加 WHERE 条件所以过滤很自然。比较麻烦的是 Agent 工具调用权限。自动执行类的 Agent 要单独配置“可调用 API 清单”不能从一个知识条目里自动生成工具权限。我的经验是最小授权原则默认所有 Agent 工具只读需要执行变更操作的工具要逐个开启并指定审批人。4.4 成本与性能控制大模型 API 的成本是团队最容易忽略的。抽取和问答每天调用几千次一个月下来账单蛮可观。我做了三件事来控制成本第一抽取用便宜模型问答用好模型。抽取任务对逻辑要求相对低用轻量模型就够问答要直接面对用户用更强的模型。两套模型分开配置成本差好几倍。第二对高频问题做缓存。同一个问题在短时间内重复出现直接从缓存返回不走模型。第三批量处理非实时抽取任务放到夜间的低价时段跑。如果用的是按量计费的 API夜间价格可能便宜一半。4.5 常见问题速查表问题可能原因解决方案抽取结果都是空条目数据太碎、缺少上下文聚合话题、过滤无结论对话抽取内容有敏感信息脱敏逻辑缺位增加 NER 识别和字段替换问答不相关召回不足或 chunk 切断调整 chunk_size、用混合检索加 Rerank权限失效过滤条件没有作用到所有查询在 API 层统一强制过滤不信任前端参数成本超支重复问答太多加缓存、区分模型、夜间批量处理Agent 执行出错经验条目不够精确先人工审核知识条目再开放给 Agent 调用混沌数据污染知识库所有对话都进抽取设置白名单只抽取已解决工单和高赞答复落地这套工具后我最大的体会是自动传承不是“一键开启”的功能而是一条需要持续喂养和调优的工程链路。它最大的价值不是省掉写文档的功夫而是把那些原本散落在聊天记录里的、极具情境感的“现场经验”抢救了下来。哪怕一个团队只用好了“会话抽取 智能问答”这两个能力新人培养速度都会有肉眼可见的提升。最后再分享一个小技巧上线一个月后别只盯着使用率每周抽半小时看“无用反馈”最集中的问题。那些问题往往不是系统 bug而是团队经验里的“盲区”——大家默认会、但新人完全不知道的东西。把这些盲区补进去比优化一百个参数都管用。