专场：上下文工程与知识工程
......
专场出品人：
......
......
李鑫
群核科技 软件开发资深工程师
群核科技 质量效能部 测试架构团队 软件开发资深工程师 ， 目前负责群核科技知识库、数字员工搭建，以及负责CI自动化建设。21年毕业后入职群核科技。从事CI自动化、故障演练、AIGC平台开发、知识库建设等工作。
待定
待定
Agent 总答不准，问题不全在模型：
群核 AI 知识库从多源混乱到可信闭环的工程实践
议题背景：
企业落地 AI Agent 后，我们很快遇到一个反直觉的问题：很多“答不准”并不完全是模型能力问题，而是知识没有被工程化管理。同一个业务口径可能同时散落在 Confluence、帮助中心、Repo Wiki、客服会话、故障复盘、质检 QA 和业务系统里；更典型的是产研场景里，代码才是更新最快、最权威的知识源，但代码本身并不等于 AI 可直接稳定消费的知识。没有体系化的代码知识库，Agent 往往只能临时翻局部文件，难以理解项目结构、模块职责、接口关系和关键实现。有些文档过期了还在被召回，有些正确文档因为权限、目录或关键词问题根本搜不到。更麻烦的是，用户点踩一句“答错了”之后，团队往往不知道是知识缺失、召回失败、文档过期，还是 Agent 用错了检索工具，问题很难回到具体负责人和修复流程。
因此，我们没有把知识库当成一个搜索框来做，而是把它作为 Agent 规模化落地的基础设施来建设。群核科技建设了统一 AI 语料库 / 知识库中台，通过“节点 + 文档”组织知识资产，打通 Confluence、帮助中心、Word、Webhook、Repo Wiki 等多源导入，并向 MCP、Skill、客服机器人、业务 Bot 和数字员工输出统一检索能力。其中 Repo Wiki 负责把代码仓库转成可翻阅、可检索、可被 Agent 引用的体系化工程文档，沉淀项目概览、架构关系、模块职责、接口说明、依赖关系和关键实现，并在代码提交后同步更新，相当于为研发场景建设一套持续演进的代码知识库。平台同时提供向量语义检索与文本精确检索，让 Agent 根据问题自主选择检索策略；再结合反馈看板、负责人路由、低质文档熔断、召回回归与 AI 质检，形成从“答错了”到“知识被修好”的治理闭环。实践中，知识库运营从约 15% 人工抽检升级到 100% AI 质检 + 人工复核 + 自动入库，支撑客服、研发、销售与数字员工复用同一套可信知识底座。
内容大纲：
1. 问题定义：为什么 Agent 规模化落地首先卡在知识工程
企业落地 AI Agent 后，我们很快遇到一个反直觉的问题：很多“答不准”并不完全是模型能力问题，而是知识没有被工程化管理。同一个业务口径可能同时散落在 Confluence、帮助中心、Repo Wiki、客服会话、故障复盘、质检 QA 和业务系统里；更典型的是产研场景里，代码才是更新最快、最权威的知识源，但代码本身并不等于 AI 可直接稳定消费的知识。没有体系化的代码知识库，Agent 往往只能临时翻局部文件，难以理解项目结构、模块职责、接口关系和关键实现。有些文档过期了还在被召回，有些正确文档因为权限、目录或关键词问题根本搜不到。更麻烦的是，用户点踩一句“答错了”之后，团队往往不知道是知识缺失、召回失败、文档过期，还是 Agent 用错了检索工具，问题很难回到具体负责人和修复流程。
因此，我们没有把知识库当成一个搜索框来做，而是把它作为 Agent 规模化落地的基础设施来建设。群核科技建设了统一 AI 语料库 / 知识库中台，通过“节点 + 文档”组织知识资产，打通 Confluence、帮助中心、Word、Webhook、Repo Wiki 等多源导入，并向 MCP、Skill、客服机器人、业务 Bot 和数字员工输出统一检索能力。其中 Repo Wiki 负责把代码仓库转成可翻阅、可检索、可被 Agent 引用的体系化工程文档，沉淀项目概览、架构关系、模块职责、接口说明、依赖关系和关键实现，并在代码提交后同步更新，相当于为研发场景建设一套持续演进的代码知识库。平台同时提供向量语义检索与文本精确检索，让 Agent 根据问题自主选择检索策略；再结合反馈看板、负责人路由、低质文档熔断、召回回归与 AI 质检，形成从“答错了”到“知识被修好”的治理闭环。实践中，知识库运营从约 15% 人工抽检升级到 100% AI 质检 + 人工复核 + 自动入库，支撑客服、研发、销售与数字员工复用同一套可信知识底座。
内容大纲：
1. 问题定义：为什么 Agent 规模化落地首先卡在知识工程
1.1 一个典型故障链路：AGENT 答错之后到底该找谁
1.1.1 用户反馈“答错了”，但后台只看到一次问答结果，无法判断是没有知识、召回没命中、文档过期、权限过滤，还是工具选择错误。
1.1.2 业务同学希望“模型再聪明一点”，平台同学却发现真正的问题分散在知识源、索引、权限、反馈和责任人流程里。
1.1.3 如果问题不能回到具体文档和负责人，知识库就会停留在“能搜”，而不是“能治理”。
1.1.2 业务同学希望“模型再聪明一点”，平台同学却发现真正的问题分散在知识源、索引、权限、反馈和责任人流程里。
1.1.3 如果问题不能回到具体文档和负责人，知识库就会停留在“能搜”，而不是“能治理”。
1.2 企业知识的三类典型断点
1.2.1 知识分散：Confluence、帮助中心、Repo Wiki、客服会话、故障复盘各自沉淀，Agent 接入成本高。
1.2.2 权威不清：同一业务在多个系统重复维护，模型不知道哪篇是最新、可信、可回答的原文。
1.2.3 代码不可读：代码仓库里有真实实现，但缺少项目级概览、模块关系和接口语义，Agent 很难直接形成体系化项目认知。
1.2.4 反馈断链：用户点踩、未命中、答错后，问题很难回到具体文档、节点负责人和修复流程。
1.2.2 权威不清：同一业务在多个系统重复维护，模型不知道哪篇是最新、可信、可回答的原文。
1.2.3 代码不可读：代码仓库里有真实实现，但缺少项目级概览、模块关系和接口语义，Agent 很难直接形成体系化项目认知。
1.2.4 反馈断链：用户点踩、未命中、答错后，问题很难回到具体文档、节点负责人和修复流程。
1.3 从“文档管理”到“AI 可消费知识资产”
1.3.1 面向人阅读的文档，不能天然满足 AI 对结构、权限、来源、索引和质量状态的要求。
1.3.2 好知识库不是搜索框，而是“导入、组织、检索、反馈、治理、权限”的一体化工程。
1.3.3 核心转变：从“把文档放上去”到“让 AI 找得到、答得准、能追溯、可修复”。
1.3.2 好知识库不是搜索框，而是“导入、组织、检索、反馈、治理、权限”的一体化工程。
1.3.3 核心转变：从“把文档放上去”到“让 AI 找得到、答得准、能追溯、可修复”。
2. 平台定位：统一知识中台如何支撑多类 AI 应用
2.1 当时遇到的问题：接入越多，混乱越多
2.1.1 初期多业务各自接知识，客服、研发、销售、数字员工都在重复建设自己的知识入口。
2.1.2 研发侧还有一个更特殊的问题：代码每天都在变，但传统文档跟不上，导致“代码是最新的，知识库是滞后的”。
2.1.3 多源导入后并不是知识越多越好，重复、冲突、过期、权限不一致会直接拉低 Agent 回答质量。
2.1.4 如果没有统一的数据模型和生命周期管理，平台只能解决“有没有文档”，解决不了“哪篇文档可信、谁负责、能不能被召回”。
2.1.2 研发侧还有一个更特殊的问题：代码每天都在变，但传统文档跟不上，导致“代码是最新的，知识库是滞后的”。
2.1.3 多源导入后并不是知识越多越好，重复、冲突、过期、权限不一致会直接拉低 Agent 回答质量。
2.1.4 如果没有统一的数据模型和生命周期管理，平台只能解决“有没有文档”，解决不了“哪篇文档可信、谁负责、能不能被召回”。
2.2 解决思路：一套知识底座，多类业务复用
2.2.1 多源接入：Confluence、帮助中心、Word、Webhook、Git Repo / Repo Wiki、开放文档、故障复盘。
2.2.2 统一组织：用节点树表达业务边界、权限边界、负责人和检索范围。
2.2.3 统一消费：向 MCP、Skill、客服机器人、业务 Bot、数字员工提供标准检索能力。
2.2.4 统一治理：无答案、答错、召回不准、文档质量差统一进入反馈看板和回归流程。
2.2.5 统一权限：不同用户、Agent 和 MCP 只能访问授权范围内的知识。
2.2.6 代码知识库：通过 AI 将代码仓库自动整理成 Repo Wiki，并随代码提交增量更新，让 Agent 不只检索文档，也能理解项目。
2.2.2 统一组织：用节点树表达业务边界、权限边界、负责人和检索范围。
2.2.3 统一消费：向 MCP、Skill、客服机器人、业务 Bot、数字员工提供标准检索能力。
2.2.4 统一治理：无答案、答错、召回不准、文档质量差统一进入反馈看板和回归流程。
2.2.5 统一权限：不同用户、Agent 和 MCP 只能访问授权范围内的知识。
2.2.6 代码知识库：通过 AI 将代码仓库自动整理成 Repo Wiki，并随代码提交增量更新，让 Agent 不只检索文档，也能理解项目。
2.3 “节点 + 文档”的数据模型
| 对象 | 核心职责 | 解决的问题
| 节点 | 表达业务归属、负责人、权限和检索范围 | AI 应该在哪个范围内找 |
| 文档 | 保存标题、正文、来源链接、来源 ID、状态和质量标记 | AI 应该引用哪篇权威原文 |
| 索引 | 同时服务语义召回与文本精确检索 | AI 如何更稳定地找准 |
| 反馈 | 记录未命中、答错、低质和召回问题 | 答错后如何修复和验证 |
| 节点 | 表达业务归属、负责人、权限和检索范围 | AI 应该在哪个范围内找 |
| 文档 | 保存标题、正文、来源链接、来源 ID、状态和质量标记 | AI 应该引用哪篇权威原文 |
| 索引 | 同时服务语义召回与文本精确检索 | AI 如何更稳定地找准 |
| 反馈 | 记录未命中、答错、低质和召回问题 | 答错后如何修复和验证 |
2.4 多源导入如何变成可治理资产
2.4.1 Confluence：按标签、根目录、单篇链接导入，适合规范、SOP、体系化知识和 FAQ。
2.4.2 帮助中心 / Word：承接存量产品说明、客服口径、线下 SOP 和历史资料迁移。
2.4.3 Webhook：把工单复盘、质检沉淀、外部系统推送接入业务流水线。
2.4.4 Repo Wiki：基于 AI 分析代码仓库，自动生成项目概览、架构关系、模块职责、接口说明、依赖关系和关键实现，把 repo 变成可翻阅的工程知识文档。
2.4.5 代码提交同步：每次代码提交后同步更新受影响的 Repo Wiki 内容，避免“代码已经变了，知识库还停在旧版本”。2.4.6 状态管理：删除、失效、重复和过期内容进入生命周期管理，避免继续参与召回。
2.4.2 帮助中心 / Word：承接存量产品说明、客服口径、线下 SOP 和历史资料迁移。
2.4.3 Webhook：把工单复盘、质检沉淀、外部系统推送接入业务流水线。
2.4.4 Repo Wiki：基于 AI 分析代码仓库，自动生成项目概览、架构关系、模块职责、接口说明、依赖关系和关键实现，把 repo 变成可翻阅的工程知识文档。
2.4.5 代码提交同步：每次代码提交后同步更新受影响的 Repo Wiki 内容，避免“代码已经变了，知识库还停在旧版本”。2.4.6 状态管理：删除、失效、重复和过期内容进入生命周期管理，避免继续参与召回。
2.5 代码知识库：REPO WIKI 如何让 AGENT 理解项目
2.5.1 问题：代码仓库是最真实的知识源，但文件多、依赖深、上下文分散，新人和 Agent 都很难快速理解系统全貌。
2.5.2 做法：通过 AI 将 repo 自动整理成结构化 Wiki，把项目结构、核心模块、接口入口、依赖关系、关键实现和调用链路显性化。
2.5.3 同步：代码提交后触发增量同步，让代码知识库跟随 repo 演进，而不是依赖研发手工维护文档。
2.5.4 价值：研发 Agent 在做项目问答、代码解释、功能开发、问题排查时，可以先基于 Repo Wiki 建立项目级上下文，再回到具体代码文件做验证和修改。
2.5.2 做法：通过 AI 将 repo 自动整理成结构化 Wiki，把项目结构、核心模块、接口入口、依赖关系、关键实现和调用链路显性化。
2.5.3 同步：代码提交后触发增量同步，让代码知识库跟随 repo 演进，而不是依赖研发手工维护文档。
2.5.4 价值：研发 Agent 在做项目问答、代码解释、功能开发、问题排查时，可以先基于 Repo Wiki 建立项目级上下文，再回到具体代码文件做验证和修改。
3. 检索能力建设：把策略选择权交给 AI
3.1 当时遇到的问题：纯向量检索并不稳定
3.1.1 自然语言问题、流程咨询、相似表达更适合语义召回，但错误码、接口名、字段名、配置项往往需要精确命中。
3.1.2 只做向量检索时，平台容易召回“看起来很像”的文档，但关键字段并不匹配，Agent 会基于错误上下文生成更像真的错误答案。
3.1.3 如果所有策略都写死在后端规则里，不同业务场景很难快速调整，也不利于 Agent 自己做工具选择和交叉验证。
3.1.2 只做向量检索时，平台容易召回“看起来很像”的文档，但关键字段并不匹配，Agent 会基于错误上下文生成更像真的错误答案。
3.1.3 如果所有策略都写死在后端规则里，不同业务场景很难快速调整，也不利于 Agent 自己做工具选择和交叉验证。
3.2 解决思路：语义召回 + 精确文本双工具
3.2.1 know_search：基于向量语义召回，适合模糊问题、流程问答、排障建议和相似表达。
3.2.2 know_text_search：基于正文关键词检索，适合错误码、接口名、字段名、专有名词和配置项。
3.2.3 Agent 可先语义召回建立上下文，再用文本检索验证关键字段；也可以在精确命中后补充相邻文档上下文。
3.2.4 工具边界清晰后，召回问题也更容易定位：到底是语义召回没找准，还是文本检索关键词、分词、权限范围出了问题。
3.2.2 know_text_search：基于正文关键词检索，适合错误码、接口名、字段名、专有名词和配置项。
3.2.3 Agent 可先语义召回建立上下文，再用文本检索验证关键字段；也可以在精确命中后补充相邻文档上下文。
3.2.4 工具边界清晰后，召回问题也更容易定位：到底是语义召回没找准，还是文本检索关键词、分词、权限范围出了问题。
3.3 MCP 与 SKILL 的边界设计
| 能力 | MCP | Skill |
| 主要用途 | 给业务 Agent 提供固定范围的稳定检索工具 | 让 Codex / Cursor / Claude Code 等 Agent 帮人查、管、排查知识库 |
| 范围控制 | 通过 MCP ID 绑定一组知识节点 | 通过个人 Token、默认根节点白名单和负责人节点控制 |
| 典型用户 | 客服机器人、业务 Bot、数字员工 | 研发、运营、知识库负责人和 Agent 调试人员 |
| 是否维护知识 | 通常只检索 | 有权限时可维护、排查和反馈 |
| 主要用途 | 给业务 Agent 提供固定范围的稳定检索工具 | 让 Codex / Cursor / Claude Code 等 Agent 帮人查、管、排查知识库 |
| 范围控制 | 通过 MCP ID 绑定一组知识节点 | 通过个人 Token、默认根节点白名单和负责人节点控制 |
| 典型用户 | 客服机器人、业务 Bot、数字员工 | 研发、运营、知识库负责人和 Agent 调试人员 |
| 是否维护知识 | 通常只检索 | 有权限时可维护、排查和反馈 |
4. 质量治理闭环：从“答错了”到“知识被修好”
4.1 当时遇到的问题：反馈多了，但质量没有自然变好
4.1.1 用户点踩、无答案、答错都能被收集，但如果没有标准分类，最后只会堆成一个待办池。
4.1.2 业务负责人经常拿不到足够上下文，不知道用户问了什么、命中了哪篇文档、期望文档是什么，也无法判断该新增知识还是修复召回。
4.1.3 修复完成后如果没有回归验证，同类问题下一次仍可能答错。
4.1.2 业务负责人经常拿不到足够上下文，不知道用户问了什么、命中了哪篇文档、期望文档是什么，也无法判断该新增知识还是修复召回。
4.1.3 修复完成后如果没有回归验证，同类问题下一次仍可能答错。
4.2 解决思路：反馈类型标准化
4.2.1 无答案：系统未回答，但需要判断是知识缺失还是召回失败。
4.2.2 答案错误：文档存在但内容错误、过期或不适用。
4.2.3 质量差：方向正确，但结构不清、步骤缺失、表达不完整。
4.2.4 知识缺失：确认知识库中没有相关内容，需要新增。
4.2.5 召回不准：正确文档存在，但检索没有命中或排序过低。
4.2.2 答案错误：文档存在但内容错误、过期或不适用。
4.2.3 质量差：方向正确，但结构不清、步骤缺失、表达不完整。
4.2.4 知识缺失：确认知识库中没有相关内容，需要新增。
4.2.5 召回不准：正确文档存在，但检索没有命中或排序过低。
4.3 负责人路由与低质文档熔断
4.3.1 反馈上报后，根据命中文档、期望文档或根节点推导负责人。
4.3.2 看板支持待处理、处理中、已处理、不处理等状态流转，不处理必须说明原因。
4.3.3 同一文档短期内多次被反馈答案错误或质量差后自动熔断，修复并验证后恢复召回。
4.3.4 这样可以避免低质文档持续污染 Agent 上下文，把“答错了”转成可分派、可处理、可验证的知识质量问题。
4.3.2 看板支持待处理、处理中、已处理、不处理等状态流转，不处理必须说明原因。
4.3.3 同一文档短期内多次被反馈答案错误或质量差后自动熔断，修复并验证后恢复召回。
4.3.4 这样可以避免低质文档持续污染 Agent 上下文，把“答错了”转成可分派、可处理、可验证的知识质量问题。
4.4 从人工抽检到 AGENTOPS 回归评测
4.4.1 每次 MCP / Skill 检索记录 requestId、问题、检索类型、命中文档、候选数量、耗时和结果。
4.4.2 召回问题处理完成后沉淀为黄金用例，保留用户问题、期望文档和根节点范围。
4.4.3 通过全量或指定节点回归，持续观察 Top-N 命中率、平均 Rank 偏移、失败明细和耗时。
4.4.4 知识库运营从“人工巡检”升级为“AI 发现问题 -> 人工复核 -> 文档修复 -> 回归验证”。
4.4.2 召回问题处理完成后沉淀为黄金用例，保留用户问题、期望文档和根节点范围。
4.4.3 通过全量或指定节点回归，持续观察 Top-N 命中率、平均 Rank 偏移、失败明细和耗时。
4.4.4 知识库运营从“人工巡检”升级为“AI 发现问题 -> 人工复核 -> 文档修复 -> 回归验证”。
5. 业务案例：知识库如何支撑客服、研发、销售与数字员工
5.1 客服知识闭环：从抽样质检到全量发现
5.1.1 原有客服知识维护依赖人工抽样和手工提炼，覆盖率有限，知识更新滞后。
5.1.2 通过客服会话沉淀标准 QA，未命中和点踩驱动补充知识，七鱼等客服场景复用统一知识检索能力。
5.1.3 知识库运营从约 15% 人工抽检升级为 100% AI 质检 + 人工复核 + 自动入库，避免多套知识口径并行维护。
5.1.2 通过客服会话沉淀标准 QA，未命中和点踩驱动补充知识，七鱼等客服场景复用统一知识检索能力。
5.1.3 知识库运营从约 15% 人工抽检升级为 100% AI 质检 + 人工复核 + 自动入库，避免多套知识口径并行维护。
5.2 研发知识检索与代码知识库：让 AGENT 进入真实工作流
5.2.1 研发知识分散在 Repo Wiki、故障复盘、接入指南、排障手册中，更新快、上下文强，单独维护知识库意愿低。
5.2.2 Repo Wiki 把代码仓库转成可翻阅的工程文档，沉淀项目概览、模块职责、接口关系、依赖关系和关键实现，让代码本身进入知识库体系。
5.2.3 每次代码提交后同步更新代码知识库，解决研发文档最常见的“写完就过期”问题。
5.2.4 通过 MCP 和 Skill，把 SOA、发布、回滚、接口、错误码等知识接入研发 Agent、Codex、Cursor 等工具。
5.2.5 Skill 不只帮助研发人员查原文，也能排查召回问题并修复文档；研发 Agent 则可以基于 Repo Wiki 先理解项目，再结合代码检索完成解释、排障和功能开发。
5.2.2 Repo Wiki 把代码仓库转成可翻阅的工程文档，沉淀项目概览、模块职责、接口关系、依赖关系和关键实现，让代码本身进入知识库体系。
5.2.3 每次代码提交后同步更新代码知识库，解决研发文档最常见的“写完就过期”问题。
5.2.4 通过 MCP 和 Skill，把 SOA、发布、回滚、接口、错误码等知识接入研发 Agent、Codex、Cursor 等工具。
5.2.5 Skill 不只帮助研发人员查原文，也能排查召回问题并修复文档；研发 Agent 则可以基于 Repo Wiki 先理解项目，再结合代码检索完成解释、排障和功能开发。
5.3 数字员工与业务 BOT：把知识范围绑定到任务边界
5.3.1 每个数字员工通过 MCP 绑定自己的知识范围，避免跨业务、跨权限误召回。
5.3.2 知识库作为数字员工回答问题、执行任务前的可信上下文来源。
5.3.3 当 Agent 答错时，反馈可回到文档和节点负责人，而不是停留在“模型幻觉”层面。
5.3.2 知识库作为数字员工回答问题、执行任务前的可信上下文来源。
5.3.3 当 Agent 答错时，反馈可回到文档和节点负责人，而不是停留在“模型幻觉”层面。
5.4 销售与商机探索：把对话数据变成可运营资产
5.4.1 从客服和业务会话中识别购买、升级、增购信号。
5.4.2 实时性高的线索实时推送，时效要求较低的场景走 T+1 挖掘。
5.4.3 让存量对话数据从“服务成本”变成可运营的数据资产。
5.4.2 实时性高的线索实时推送，时效要求较低的场景走 T+1 挖掘。
5.4.3 让存量对话数据从“服务成本”变成可运营的数据资产。
6. 踩坑经验与 H2 展望
6.1 六大工程踩坑
6.1.1 只建搜索不建治理：检索效果差时，必须能定位是知识缺失、权限问题、召回不准还是内容过期。
6.1.2 只做向量检索不够：错误码、接口名、字段名等确定性问题需要文本检索兜底。
6.1.3 目录越细不一定越好：目录过深会增加维护成本，也会让 Agent 更难判断检索范围。
6.1.4 导入不等于可用：没有标题规范、来源追溯、节点负责人和质量反馈，导入越多越难治理。
6.1.5 代码不等于代码知识：直接让 Agent 翻仓库只能解决局部上下文，Repo Wiki 需要把项目结构、模块关系和关键实现先显性化，才能支撑体系化理解。
6.1.6 MCP 与 Skill 要分工：MCP 适合稳定问答，Skill 适合排查维护，混在一起会让权限和操作边界变复杂。
6.1.7 反馈必须能回归验证：点踩、无答案、召回不准如果不能进入负责人待办和黄金用例，质量不会自然变好。
6.1.2 只做向量检索不够：错误码、接口名、字段名等确定性问题需要文本检索兜底。
6.1.3 目录越细不一定越好：目录过深会增加维护成本，也会让 Agent 更难判断检索范围。
6.1.4 导入不等于可用：没有标题规范、来源追溯、节点负责人和质量反馈，导入越多越难治理。
6.1.5 代码不等于代码知识：直接让 Agent 翻仓库只能解决局部上下文，Repo Wiki 需要把项目结构、模块关系和关键实现先显性化，才能支撑体系化理解。
6.1.6 MCP 与 Skill 要分工：MCP 适合稳定问答，Skill 适合排查维护，混在一起会让权限和操作边界变复杂。
6.1.7 反馈必须能回归验证：点踩、无答案、召回不准如果不能进入负责人待办和黄金用例，质量不会自然变好。
6.2 H2 重点方向
6.2.1 AgentOps 评测：持续评估不同知识库、MCP 和业务场景的检索质量。
6.2.2 知识准入标准：建立标题、正文、节点、来源、负责人和验收问题的统一规范。
6.2.3 代码知识库增强：完善 Repo Wiki 的生成质量、增量同步、模块关系梳理和代码问答链路，让代码提交自动沉淀为可被 Agent 消费的工程知识。
6.2.4 事件驱动沉淀：代码提交、工单、客服会话、故障复盘、Issue 变更自动触发知识生成和审批。
6.2.5 多端深度接入：让 Codex、Cursor、客服平台、数字员工统一使用同一套知识底座。
6.2.6 检索增强：结合 rerank、关键词兜底、权限过滤和负反馈数据持续优化召回。
6.2.2 知识准入标准：建立标题、正文、节点、来源、负责人和验收问题的统一规范。
6.2.3 代码知识库增强：完善 Repo Wiki 的生成质量、增量同步、模块关系梳理和代码问答链路，让代码提交自动沉淀为可被 Agent 消费的工程知识。
6.2.4 事件驱动沉淀：代码提交、工单、客服会话、故障复盘、Issue 变更自动触发知识生成和审批。
6.2.5 多端深度接入：让 Codex、Cursor、客服平台、数字员工统一使用同一套知识底座。
6.2.6 检索增强：结合 rerank、关键词兜底、权限过滤和负反馈数据持续优化召回。
听众收益：
1. 一套可复用的企业知识库中台架构：听众可以带走“多源导入 -> 节点治理 -> Repo Wiki 代码知识库 -> 双检索工具 -> MCP/Skill 接入 -> 反馈看板 -> 质量熔断 -> 召回回归”的完整设计模板，理解如何把分散文档和代码仓库变成 AI 可稳定消费的知识资产。
2. AI Agent 知识接入的工程化经验：分享会具体展开向量检索与文本检索如何分工、为什么要把工具选择权交给 AI、MCP 与 Skill 如何划清边界，以及权限控制、检索排查、召回反馈分类的实践方法。
3. 从“答错了”到“修好了”的治理方法论：不只讲平台功能，而是讲如何用 AI 质检、未命中反馈、负责人路由、文档熔断、Repo Wiki 同步和召回回归，把知识运营从人工抽样升级为全量治理，并支撑客服降本、研发提效、数字员工可信回答和销售线索挖掘。
1. 一套可复用的企业知识库中台架构：听众可以带走“多源导入 -> 节点治理 -> Repo Wiki 代码知识库 -> 双检索工具 -> MCP/Skill 接入 -> 反馈看板 -> 质量熔断 -> 召回回归”的完整设计模板，理解如何把分散文档和代码仓库变成 AI 可稳定消费的知识资产。
2. AI Agent 知识接入的工程化经验：分享会具体展开向量检索与文本检索如何分工、为什么要把工具选择权交给 AI、MCP 与 Skill 如何划清边界，以及权限控制、检索排查、召回反馈分类的实践方法。
3. 从“答错了”到“修好了”的治理方法论：不只讲平台功能，而是讲如何用 AI 质检、未命中反馈、负责人路由、文档熔断、Repo Wiki 同步和召回回归，把知识运营从人工抽样升级为全量治理，并支撑客服降本、研发提效、数字员工可信回答和销售线索挖掘。
敬请期待
......
.....
待定
待定
敬请期待
....
关注QECon公众号
议题投稿
speaker@qecon.com.cn
商务合作
151-2264-3988 木子
票务联系
135-2067-8913 媛媛
媒体合作
135-1619-6409 皮皮
添加QECon小助手，获取
会议最新资讯
购票咨询
13520678913 媛媛
