知识库用于组织相关资料，并统一配置分块、向量模型、检索索引、Wiki 和知识图谱。文件、网页、手写 Markdown 和 FAQ 等内容作为知识条目管理，入库后按配置解析和建立索引。 不同知识库可以使用独立的处理配置。提问时可限定检索范围，成员访问与组织共享也按知识库授权。 创建知识库时选择内容类型、模型与索引方式，再上传文件、导入网页或编写 Markdown。普通资料使用文档库，标准问答使用 FAQ 库 。向量存储创建后不可更改，应在建库前确定。 上传确认页可设置标签和本批文件的解析选项，包括是否生成文档摘要（默认开启；关闭后解析、索引及其他处理照常执行）。单次处理选项优先于知识库配置，知识库配置再优先于空间默认值。已有文档需要重新解析才能使用修改后的分块参数。 批量上传时，页面右下角的上传任务面板汇总所有文件：最多同时传输 3 个，显示已传字节、剩余时间以及可检索、处理中、失败和已存在的数量。单个文件可以取消或重试，全部上传完成后可以离开页面，解析会在后台继续。大文件的上传超时按文件大小自动延长。 文档列表和卡片显示每篇文档的解析状态。超过 20 分钟没有进展时，状态会变为「排队中」或「疑似卡住」：前者表示仍有任务在队列中等待，通常无需处理；后者表示已无任务推进该文档，可以打开解析时间线查看停在哪个阶段，或停止解析后重试。长时间无进展的文档会被系统自动标记为失败，错误码为 TASK_STALLED 。 解析时间线按阶段展示耗时与结果。失败时，顶部错误卡片说明出错的阶段和原因，并提供重试入口。 文档知识库的「画廊」页签汇总从文档提取的图片，以瀑布流持续加载。可搜索图片描述和 OCR 文字，按系统提供的图片属性、来源文档等筛选；点击图片可查看大图、描述、OCR 与来源。来源文档筛选支持多选，便于核对某批文件的解析结果。 画廊展示已有图片资源，不要求开启图片向量检索。 多模态 Embedding 与图片检索 ​ 支持图片输入的 Embedding 模型将文本与原图编码到同一向量空间，使文字问题能够召回相关图片。已支持的模型包括腾讯 WeMM-Embedding、Qwen3-VL-Embedding 等，接入时需匹配图片输入能力与请求协议；WeMM 的服务部署与接入见 模型配置 。 在知识库设置中开启多模态处理和「图片向量检索」，并选用支持图片输入的向量模型。图片向量默认关闭，已有文档需要重新解析才会补建图片向量，扫描 PDF 页不生成图片向量。详细参数与限制见下文「图片向量」。 文件夹用于按目录归档，一篇文档只属于一个文件夹。上传整个目录可保留层级结构；在文件夹树中重命名或移动时，子目录路径会一并更新，目标目录已存在时合并内容。文档在同一知识库内移动文件夹只调整归类，不重新解析。 标签用于交叉分类，一篇文档可关联多个标签。上传时可以预设标签，也可勾选文档后批量修改；批量对话框预选所选文档共有的标签。按多个标签筛选时，匹配任一标签的文档即可返回。 开启自动标签后，系统在解析完成时从已有候选标签中选择匹配项。默认每篇最多关联 3 个，已有标签时跳过。配置只影响后续解析，不自动补齐历史文档，模型失败也不会阻塞文档完成。 在文档详情中编辑文本分块，可修正解析错误并重建索引。每次编辑或回滚都会生成新版本；若其他用户已更新同一分块，界面会提示刷新后重试。索引更新失败时会保留编辑内容并显示失败状态，再次提交可重试。 自定义元数据用于补充部门、密级或版本号等信息，最多 20 项。修改元数据会触发摘要刷新；详细的字段长度和支持类型见参考部分。 复制知识库可复用已有配置与内容。跨库移动时，可选择复用向量或重新解析：复用要求两库绑定同一向量存储，重新解析允许使用目标库的存储和处理配置。移动为异步任务，可查询进度。 勾选文档后点击「批量下载」，所选文件的原始文件会打包为 ZIP，并保留知识库中的文件夹结构，解压后可按文件夹重新上传。每批最多 200 个文档、原始文件合计不超过 512 MiB；网页导入等没有原始文件的条目会被跳过。「全选已加载」只包含当前已加载的文档。批量下载与单个文件下载的权限相同，需要 Contributor 及以上且对知识库有编辑权限。 知识库设置的「活动」记录配置、文档、分块、共享和 Wiki 变更。该入口面向符合资源管理权限的登录用户，API Key 不可访问。通过 API Key 发起的操作会在操作人下方额外显示 Key 名称。 通过组织共享以只读（Viewer）权限访问的知识库，界面不显示上传、编辑、删除和设置入口。 存储配额按工作空间计算，涵盖文件、文本、向量和索引。创建知识库与上传前会检查配额，删除内容后回收对应用量。 internal/types/knowledgebase.go ： 更新 KB 时会清除与其类型不匹配的配置（如非 FAQ 库的 FAQConfig ）。 VectorStoreID 使用 GORM <-:create 标签， 创建后不可修改 （防止索引与存储错位）。 ChunkingConfig（分块配置） ​ IndexingStrategy（索引管线开关） ​ VLMConfig（视觉语言模型） ： 启用判定： Enabled && ModelID != "" ，或旧版 ModelName != "" && BaseURL != "" 。 ASRConfig ： enabled / model_id / language （语言提示，可选）。 ImageProcessingConfig（图片属性观察、条件 OCR 与图片向量） ： 选择 smartocr 后，模型逐项观察属性并产出描述。OCR 决策主要使用以下观察项；开启自动预处理时还会观察版面属性（完整注册表见 GET /api/v1/image-attrs/schema ，只读、需 Viewer 权限；该注册表是全局的，不随知识库变化）： OCR 决策是代码纯函数 DecideOCR （ internal/application/service/image_attr_decision.go ），不落库： 满足 contain.text == block 或 contain.data_visual == true → 跑 OCR； 策略读取到的属性 缺键 （模型漏答该行，或答了非法取值）→ 按 on_unobserved 兜底（默认仍 OCR）； 全部属性都被观察到、且都不命中 → 跳过 OCR。 模型答非所问或属性缺失时按 on_unobserved 策略处理，默认继续 OCR；若将其设为 false ，未观察到属性的图片也会跳过 OCR。完整的负值观察结果可能使 OCR 被跳过，因此仍需抽查模型判断与文字提取结果。注意 属性缺键是正常结果 ：观察失败时不会写入保守默认值（schema 版本 attrs/2 ），因此 image_attrs 可能为空对象，读取方需区分「未观察到」与「观察到了负值」。 管线与观察结果记录在图片处理轨迹中。当前管线标识为 default / smartocr ，不是旧版的 caption_ocr / observation_driven 。轨迹可查看观察、描述、预处理、OCR 的实际结果以及跳过或失败原因。 OCR 预处理默认关闭。可在管线中选择自动判断或对可处理页面始终执行，预处理失败或繁忙时使用原图。修改配置仅影响后续解析，已有图片需重新解析才会更新。 OCR 会在入库前拒绝空响应、只有分隔符的内容，以及占据输出主体的长串重复内容；正常短标签、数字和表格仍可保留。OpenAI 兼容 VLM 返回 finish_reason=length 时，非空的截断输出也按失败处理。普通图片提示词按可见文字转录，截图中的按钮和标签逐行输出，仅真实表格使用 Markdown 表格；扫描 PDF 使用专用文档布局提示词。 OCR 的模型调用和输出校验分别记录处理状态。失败、截断或异常重复内容不会作为有效 OCR 分块索引；图片描述等成功结果仍可保留，因此需要区分整图失败与部分步骤失败。对已有异常内容，应检查处理轨迹后重新解析相应文档。 可通过 WEKNORA_OCR_TEST_FIXTURE 指定本地 JSON 文件（ {"model": <模型配置>, "image_paths": [<本地图片路径>]} ），运行 go test ./internal/application/service -run '^TestLiveImageOCRValidation$' -v -count=1 验证实际模型。私有端点需配置 SSRF_WHITELIST 。该测试使用内存分块仓库，不写业务数据库；带凭证的配置和原图应放在版本控制之外。 单次上传 / 重新解析可在请求体的 process_config （ KnowledgeProcessOverrides ）里按文档覆盖 image_pipeline 、 image_pipeline_params 、 image_attrs_enabled 与 image_actions ；未传的项沿用知识库设置。 image_actions 按 action key 合并（ on 整体替换）。接口字段见 知识库 API ，管线细节见 文档解析 。 图片向量（ image_vector_enabled ） ：默认关闭，升级后已有知识库也保持关闭（库里存的配置没有这个键，读出来就是 false），需要在知识库设置「图像处理配置 → 图片向量检索」里（开启多模态后出现）或通过 API 显式开启。只有 开关打开且向量模型能处理图片 时才生效，两者缺一则入库不生成图片向量、检索也不召回图片向量。之所以不随模型能力自动开启：能处理图片的向量模型常常只是被用来编码文本，自动开启会给这些知识库凭空增加每张图片一次的向量调用，并改变检索行为——开启后文档向量检索的候选池放大 1.5 倍，图片命中按 min(VectorThreshold, 0.1) 的单独阈值过滤。 图片向量在多模态任务里生成，所以还需要开启多模态（VLM）：图片向量的 Content 复用图片描述（没有描述时用 OCR 文本）；扫描件 PDF 页不生成； 开关只影响此后入库或重新解析的文档；已有文档要补图片向量需重新解析； 开关关闭时，已有的图片向量（关闭前生成的，或文档从开启了图片向量的知识库 移动 过来时随文档带来的）连同其分块会保留，但检索时一律丢弃，不再召回；删除或重新解析文档、删除知识库时随文档一起清除；重新开启开关后，这些保留的图片向量恢复召回。 复制 文档到未开启的知识库则不会复制图片向量； 多知识库联合检索时按知识库各自的开关判断，未开启的知识库不召回图片向量； 检索引擎无法按来源类型过滤，不召回的图片行（未开启知识库的图片向量命中，以及关键词检索命中的任何图片行）只能在结果返回后丢弃。为免它们占满候选池、把文本挤出去，文档向量池或关键词池打满且含这类图片行时，会把 TopK 翻倍重新检索，直到凑够不需丢弃的候选（文本命中，以及开启了图片向量的知识库的图片命中）、索引耗尽或到达 500 条候选上限（以默认的 50 条池计，每个池最多多 4 次查询）。因此含图片行的 store 组可能多出几次检索查询；排在文本前面的图片行超过约 500 条时，文本命中仍可能被漏掉。补检失败或只部分返回时保留上一轮的完整结果。 QuestionGenerationConfig（问题生成） ： enabled ； question_count 每分块生成问题数（默认 3，上限 10）； custom_instructions 目标受众 / 风格说明。 ExtractConfig（知识图谱） ： enabled 、 text 、 tags 、 nodes []*GraphNode{name, chunks, attributes} 、 relations []*GraphRelation{node1, node2, type} 、 custom_instructions （领域提取指导）。 FAQConfig（仅 FAQ 库） ： index_mode （ question_only / question_answer ，默认后者）、 question_index_mode （ combined / separate ，默认 combined），详见 FAQ 篇。 WikiConfig（打开 indexing_strategy.wiki_enabled 的知识库） ——注意它不是 type = "wiki" 专属：普通文档库打开 Wiki 索引后， UpdateKnowledgeBase 会自动给它建一份空的 WikiConfig 承载这些可调项： 所有 custom_instructions 类字段在更新时经 validateKnowledgeBasePromptInstructions 校验长度与合法性（ internal/handler/knowledgebase.go ）。 StorageProviderConfig （新）： provider ∈ {local, minio, cos, tos, s3, oss, ks3, obs} ； StorageBackendID ：绑定具体存储后端实例； StorageConfig （遗留 cos_config 列）： secret_id / secret_key / region / bucket_name / app_id / path_prefix / provider / endpoint / use_ssl / force_path_style 。 列表 / 详情响应附带： knowledge_count （不含删除中的文档，与文档列表一致）、 chunk_count 、 is_processing （FAQ 库）、 processing_count （文档库处理中知识数）、 share_count （共享到的组织数）、 creator_name 、 is_pinned / pinned_at （当前用户置顶状态）。 另有一个存储字段 is_temporary ：标记 临时（ephemeral）知识库 ，正常的知识库列表里不展示。它由系统内部使用，典型场景是联网搜索把抓回来的网页缓存成可检索内容。手工建库不会产生临时库。 在文档知识库的标签相关设置中开启自动标签，先准备好候选标签，再选择聊天模型。解析完成后，系统异步从已有标签里挑选匹配项，不创建新标签。 auto_tag_config 仅适用于 document 类型： 配置仅对之后新解析或重新解析的文档生效，不自动回填历史文档。模型失败不阻塞文档完成，异步任务按队列策略重试。候选标签取知识库排序前 500 个；自动关联不删除人工标签。数据源按来源名称添加标签是另一条机制。 知识库有两段描述： description 是用户手写的"这个库是干什么用的"， generated_profile 是系统从文档画像推导出的"这个库里实际有什么"。两者互不覆盖，智能体在运行时上下文里同时读取，用来判断一个问题该在哪个绑定知识库里检索。 生成分三层，只有最后一层调用模型： 文档画像 ：文档摘要任务在生成短摘要的同时输出结构化画像（ knowledges.profile ）：一句话 gist、3 到 5 个主题词、文档类型、一个典型问题。它随文档一起存在、随文档删除而消失。 知识库聚合 ：纯数据库统计——文档数、文件类型、标签计数、主题词计数（大小写与标点归一）、文档类型计数、按主题轮询抽样的典型问题、均匀抽样的标题，并对输入算一个哈希。删除、移动、重新解析都不需要特殊处理，重算即精确。 描述文案 ：把聚合（一两千 token，与文档数无关）交给模型，得到 gist、合并后的主题列表和 3 到 5 个典型问题。聚合哈希没变就跳过模型调用。 profile_config 仅适用于 document 类型： 无论是否开启自动刷新，知识库设置页都可以点击"生成 AI 描述"立即生成一次，并可一键把 gist 采纳为手写描述。 generated_profile.status 为 ready / empty （无已解析文档，不调模型）/ failed （保留上一次文案并记录错误）。关闭了文档摘要的上传只贡献标题、类型和标签，不贡献主题词。 知识（Knowledge）管理 ​ internal/types/knowledge.go 。关键字段： type （ manual 手动 Markdown / faq / 文件类型）、 source / channel （摄入渠道）、 parse_status 、 summary_status 、 enable_status 、 file_name/type/size/hash/path 、 storage_size 、 metadata （JSON，手动知识存 ManualKnowledgeMetadata{content, format, status(draft/publish), version} ）、 custom_metadata （JSON，用户自填元数据）、 last_faq_import_result 。 custom_metadata 保存用户维护的部门、密级、版本号等描述性字段； metadata 保存处理流程的内部状态与 ID。自定义元数据最多 20 项，键为 1–64 字符，值支持字符串、数字、布尔值或 null，长度不超过 1000 字符。修改后会自动刷新摘要。 实现中， Knowledge.CustomMetadataText() 按键排序生成 键: 值 文本，供摘要生成和文档级模型上下文使用。字段由迁移 000078 引入。 摄入渠道常量： web 、 api 、 browser_extension 、 wechat 、 wecom 、 feishu 、 feishu_drive 、 lark_drive 、 dingtalk 、 slack 、 im 、 notion 、 confluence 、 yuque 、 rss 、 ima 。

单个富化子任务（摘要、问题生成、图谱、Wiki）失败不会让文档变为 failed ，文档在子任务全部结束后进入 completed 。卡在 pending 、 processing 、 finalizing 或 deleting 的文档由后台巡检回收，见 异步任务系统 。 摘要独立状态： summary_status ∈ {none, pending, processing, completed, failed} 。 internal/types/knowledge.go 的 KnowledgeListFilter + internal/handler/knowledge.go ： 文件夹用于按项目、来源或目录层级组织文档，支持上传时保留目录结构，以及入库后的重命名和移动。 上传整个目录 ：目录结构会被原样保留，不需要事后手工建文件夹； 新建 / 重命名 / 移动文件夹 ：文档列表左侧的文件夹树上操作。重命名会连子目录一起改路径；目标路径已存在时两个文件夹合并；不允许把文件夹移到自己的子目录下； 重新归类文档 ：勾选文档后移动到指定文件夹（也可以移回根目录）。这只改归类，不重新解析、不影响索引； 按目录浏览 ：列表接口的 folder_path 决定视图模式——不传是全库平铺，传空字符串是根目录（不含子目录），配 folder_recursive=true 则连子目录一起列。 文件夹与标签解决的是不同问题，可以叠加使用： 文件夹是唯一归属 （一篇文档只在一个目录下，适合按项目/来源归档）， 标签是多对多 （一篇文档可带多个标签，适合按主题、密级、状态交叉筛选）。检索时两者都能作为范围限定条件。 目录路径保存在 knowledges.folder_path ， file_name 仅保存文件名。迁移 000079 已从历史文件名中回填目录路径。 文件夹接口为 GET/PUT /knowledge-bases/:id/knowledge/folders 与 POST /knowledge/folder ，详见 知识库 API 。 标签（KnowledgeTag） ​ internal/types/tag.go + internal/handler/tag.go ： 一篇文档可以带多个标签。 早期是单标签（ knowledges.tag_id 一列），migration 000063 换成了关联表 knowledge_tag_relations ：建表时把原有的单标签数据迁进去，然后 删掉了 knowledges.tag_id 列 。所以现在： 读： Knowledge.Tags 是查询时按 knowledge_id 批量 JOIN 出来的（ gorm:"-" ，不落在 knowledges 表上）； 写：整体替换语义—— PUT /knowledge/tags 传 {knowledge_id: [tag_ids]} ，实现先删该文档的全部关联再写入新集合； 过滤： tag_ids 是 OR 语义 （命中任一标签即返回），SQL 走 knowledges.id IN (SELECT knowledge_id FROM knowledge_tag_relations WHERE tag_id IN (...)) ； FAQ 条目是另一套：它本身是 chunk，标签存在 chunks.tag_id 上（ 单标签 ），与文档的多标签关联表不是同一条路径。 标签本身的管理路由： GET /knowledge-bases/:id/tags （Viewer+）、 POST （OwnedKBOrAdmin）、 PUT/DELETE /knowledge-bases/:id/tags/:tag_id （OwnedKBOrAdmin）； tag_id 路径参数同时接受 UUID 与整数 seq_id 。 批量打标签 ：文档列表勾选若干文档后，批量操作栏的「标签」按钮打开 BatchTagDialog.vue 。对话框会把所选文档 共有 的标签预选中，支持搜索、直接跳转标签管理，提交后刷新列表； 上传时设置标签 ：上传确认对话框（ UploadConfirmDialog.vue ）可在文件入库前直接指定标签与解析选项，省去先传后改。 在文档详情中可以编辑分块正文，修正 OCR、表格或公式的解析错误。保存后会重建索引，并保留历史版本供查看和回滚。 实现上（ internal/application/service/chunk.go ，migration 000078 ）： 只有 text 类型分块可编辑 ；内容去空白后不能为空，上限 200000 字节； 乐观并发 ：请求可带 expected_revision ，与当前版本不符返回 409，前端提示刷新后重试； 不能新增图片 ：编辑内容中出现源内容里没有的图片 URL 会被拒绝；删除某张图片的 Markdown 引用时，对应的 OCR / caption 子分块被 停用 而非硬删除，这样回滚历史版本可以把它们重新启用； 父子分块一致性 ：编辑子块后按偏移量把改动叠加回父块（父块的 source_content 保持不可变，替换按倒序应用，长度变化不会打乱坐标系）； 索引失败处理 ：重建索引失败时行照常保存，但 index_status = failed ，界面据此提示；再次提交相同内容会触发重试； 保留生成问题 ：内容编辑后原有的检索问题保留，只是被标记为「与当前正文版本不匹配」，可以单条改写（ PUT /chunks/by-id/:id/questions ）或整体重新生成（ POST /chunks/by-id/:id/questions/regenerate ）； 摘要联动 ：内容或启停状态变化会入队一次文档摘要刷新， summary_status 转为 pending ；也可以用 POST /knowledge/:id/regenerate-summary 手动触发。 回滚（ POST /chunks/:knowledge_id/:id/revert ）本身也是一次新编辑：目标历史版本的内容被写为当前内容，版本号继续递增，原内容进入历史列表，因此「回滚的回滚」同样可行。 接口清单见 API 参考：分块与标签 。 在文档内容预览中可编辑摘要并保存，用于修正自动摘要。 PUT /knowledge/:id 的 description 省略时保持原摘要，显式空字符串清空；更新摘要不会等同于修改原始文档内容。需要重新生成时使用「重新生成摘要」，内容/元数据变化也可能触发摘要刷新。 文档分块按页加载，切换文档和检索跳转会更新分页状态。完整字段见 知识 API 与 分块 API 。 GET /knowledge/:id/preview 的安全机制由 internal/handler/knowledge_preview_security_test.go 固化验证： 测试用例明确验证：HTML 文件即使内容是 <script>alert(1)</script> ，也只会作为二进制附件传输。下载端点（ /knowledge/:id/download 与批量下载 /knowledge-bases/:id/knowledge/batch-download ）要求更高的 Contributor+ 且走 KBAccessWrite 门禁。 预览返回的是原始文件本身，通过只读共享（组织共享的 viewer、经共享智能体可见）访问时同样可以预览。「只有 Editor 及以上才能下载」是产品上的便利性限制，不是访问控制边界：能读到一个 KB 的人，就能拿到其中的原文件。 复制（Copy / Duplicate）与 Preflight ​ internal/application/service/knowledge_clone_move.go ，preflight 规则由 internal/handler/knowledgebase_copy_preflight_test.go 固化： POST /knowledge-bases/copy ：整库复制（配置 + 内容），body 传 source_id ；异步任务，进度查 GET /knowledge-bases/copy/progress/:task_id （活动流记 kb.clone_started / kb.clone_completed / kb.clone_failed ）。 POST /knowledge-bases/:id/duplicate ： 仅复制配置 （不复制内容 / 索引 / 共享记录），活动流记 kb.duplicated 。 Preflight（复制前校验，直接同步拒绝）： 源 / 目标 KB 的租户隔离（跨租户拒绝）； VectorStore 兼容性 ： reuse_vectors 模式不支持跨向量库的 KB（向量不可直接搬移）； StorageBackend 兼容性 ：跨存储后端复制不支持； API Key 调用时源 / 目标 KB 均须在 allow-list 内。 知识移动门禁（move gate） ​ POST /knowledge/move 支持两种模式，约束在 handler 与 service 双层 校验（ internal/handler/knowledge_move_gate_test.go 与 internal/application/service/knowledge_move_gate_test.go 双重佐证）： reuse_vectors 模式 ：直接复用既有向量， 要求源 KB 与目标 KB 绑定同一 VectorStore ； reparse 模式 ：目标库重新解析生成向量，允许跨向量库移动。 同库判定 SharesStoreWith() 的规范化语义（空字符串归一化为 nil，nil 表示环境默认 store）： GET /knowledge-bases/:id/move-targets 返回符合门禁的候选目标库；移动为异步任务，进度查 GET /knowledge/move/progress/:task_id 。 配额挂在租户上（ internal/types/tenant.go ）： 创建 KB 与上传知识前都会执行配额检查（ internal/handler/knowledgebase.go 创建校验链），超限拒绝写入；每条知识记录自身 file_size 与 storage_size ，删除时回收用量。 （门禁语义见《租户、用户与认证授权》篇； KBAccessRead/Write 会解析组织共享路径。） 创建流程 （ internal/handler/knowledgebase.go ）：Contributor 校验 → 租户存储配额检查 → EmbeddingModelID 校验 → VectorStoreID 绑定校验 → 创建 → 返回 KB + vector_store_display 。 删除级联 ：删除 KB 下全部 Knowledge → Chunk → 向量索引 → 关键词索引 → Wiki 页面 → 标签 → 存储文件 → 软删除 KB 本身。共享侧的 editor 无法删除源 KB（删除要求 owner 租户 + Admin 侧权限）。 混合检索（Hybrid Search） ​ POST /knowledge-bases/:id/hybrid-search （ internal/handler/knowledgebase.go + internal/application/service/knowledgebase_search*.go ）按 KB 的 IndexingStrategy 组合召回：向量（vector_enabled）+ 关键词 BM25（keyword_enabled），经 rank fusion 融合与重排（rerank），可叠加知识图谱增强（graph_enabled）；多 KB 场景由 knowledgebase_search_fanout.go 并发扇出、 knowledgebase_search_fusion.go 融合；共享 KB 检索路径见 knowledgebase_search_shared.go 。FAQ 库检索有专门的命中策略（负例过滤 / 迭代召回），见 FAQ 篇。 internal/application/service/knowledge_create.go / knowledge_process.go / knowledge_process_config.go ： 配置合并优先级 （ EffectiveProcessConfig ）： Knowledge.ProcessOverrides （单次上传覆盖，存于知识 metadata 的 KnowledgeProcessOverrides ，可覆盖 parser 规则 / 分块 / VLM / ASR / 问题生成 / 图谱开关 / 摘要开关等）> KB 配置 > 租户默认。 Chunk 类型（ internal/types/chunk.go ）： text 、 parent_text 、 image_ocr 、 image_caption 、 summary 、 entity 、 relationship 、 faq 、 web_search 、 table_summary 、 table_column 、 wiki_page ；chunk 支持 is_enabled 开关与 flags 位标志（bit0 = 可推荐）。 知识库活动流（KB Activity） ​ 知识库设置的「活动」页签记录配置修改、文档上传与删除、分块编辑、共享变更和 Wiki 更新，包含操作人、时间与结果。 internal/application/service/kb_activity.go 复用审计日志体系（ AuditLog ，scope 为 knowledge_base），通过 recordKBActivity(ctx, audit, tenantID, kbID, action, targetType, targetID, outcome, details) 记录： 活动动作 （ internal/types/audit_log.go ）： kb.created / kb.updated / kb.deleted / kb.duplicated / kb.clone_started / kb.clone_completed / kb.clone_failed 、 kb.share_added / kb.share_permission_changed / kb.share_removed ，以及知识 / chunk 级的增删改动作； 触发源 ：context 中的 kbActivityTaskMetadata{TaskID, Trigger} （ user 用户操作 / system 后台任务）自动并入 details；根据 outcome 自动补 processing_status （accepted→pending、success→completed、partial→partial、failed/denied→failed、canceled→canceled）； API Key 身份 ： X-API-Key 调用写入 details.api_key_id / details.api_key_name （名称快照）。活动页在原发起人后额外显示 Key 名称；JWT 网页操作不加这两项。异步任务只把 Key 展示身份放进 TaskInitiator ，不把 Key 权限 scope 恢复进 worker； 批量操作样本标题 ： kbActivityAppendSampleTitles 为批量操作附带最多 5 个去重标题（第一个作为 title ，其余进 titles 数组），保证活动流可读且有界； 抑制机制 ： withKBActivitySuppressed(ctx) 可让内部级联操作不产生重复活动记录。 查询端点： GET /knowledge-bases/:id/activity （OwnedKBOrAdmin，仅 JWT 用户，API Key 不可访问）。