第 13 章 团队协作与知识库运营

本章导读：after-sales-kb 上线了——平台已经稳住(第 12 章)，客服用上了「售后助手」(第 8 章)与画布客服 Agent(第 10 章)。然后，10 月改版来了：政策手册换新、新条款只对部分站点生效，而几天后客服还在引用旧条款。这就是知识腐败(knowledge rot)：上线只是开始，无人治理的知识库会悄悄变坏——旧条款不撤、切片过期、没人敢动、没人负责。本章是全书收束，讲运营三件事：权限与共享治理——谁能对什么做什么(13.2-13.4)；文档更新流程——让新版「确定」生效(13.5)；质量巡检——让衰退被及时发现(13.6-13.7)。最后用一次 10 月改版全流程演练回收贯穿案例，并把全书 12 章路线一句话回顾。读完本章，你能：为团队配置权限与共享、走通一次改版的端到端更新闭环、按日/周/月节奏巡检，并带走一页可落地的运营 SOP。

本章操作流程图

你什么时候需要它

三种典型处境，对应本章三种用法。

多人用一套 RAGFlow，谁能动什么说不清——看 13.2 与 13.3。权限三层模型与生效规则五步是官方的判定顺序，13.4 再补一层「系统管权限、SOP 管秩序」的治理分工——口头约定变成系统行为加书面流程。

文档改版了，怎么让新版「确定」生效——直接看 13.5。数据源同步与手动上传两条路径、重解析与工件重编译的下游动作，末尾的 10 月改版演练是完整示范。

知识库用了几个月，答案开始时好时坏——看 13.6 与 13.7。logs 分层定位、测试集定期回归、日/周/月巡检节奏，配上三个运营指标记账。

前置：第 3 章的数据集创建与 Permissions 字段(它的第一次出场在那里)；第 12 章的生产化基线——平台不稳，运营无从谈起。

13.1 概述：上线只是开始，然后呢

第 1 章说过，LLM 的第一大局限是静态知识——训练快照之外的它不知道。RAG 的对策是「检索段实时从外部知识库取最新内容」，但这句对策有个隐含前提：得有人持续把最新内容喂进知识库。没人喂，RAG 就退化成一台「快速检索旧文档的机器」，而且因为它带着引用、答得笃定，旧知识错得比没有知识更可信——第 7 章样例三(2024 版旧条款被当作现行政策引用)就是预演。

这种衰退有个业界通称：知识腐败(knowledge rot)——本书立场采用这个说法，它不是官方术语。落到 RAG 知识库上，典型症状四条：

对抗它的是三件事——本章的主体结构：

本章反复出现的术语，沿用全书词汇表并补两条(中英对照首次在此集中给出)：

事实边界先声明：13.2 与 13.3 的权限模型、共享范围、成员管理，13.6 的日志能力，全部以官方文档为准(docs/guides/team/、docs/guides/dataset/logs.md，素材核实日期 2026-10-27)；13.4 的治理设计与 13.7 的指标、节奏，是本书立场——官方给了权限的「骨骼」，秩序的「肌肉」要每支团队自己长。

13.2 权限体系：谁能对什么做什么

三层模型

官方对权限体系的定义一句话(docs/guides/team/permission_system_overview/index.md，核实日期 2026-10-27)：RAGFlow 通过三层管理团队协作与资源权限——团队成员关系、资源共享范围、资源操作权限。三层各回答一个问题，层层收紧：

读这张表的正确顺序是自上而下：不在团队，一切免谈；在团队而资源未共享，依然看不到；看得到而操作越权，照样被拦。三层是「与」的关系，不是「或」。

Team 与 Me：两个共享空间

每个 RAGFlow 用户注册即拥有一个个人工作空间(即 Me 空间)，团队页以「昵称 + workspace」为标题；默认情况下，每个用户有一个以自己用户名命名的团队。团队页分两区：Team members(当前工作空间的成员)与 Joined teams(我加入的或被邀请加入的其他工作空间)——机制上，RAGFlow 用 user_tenant 关系记录成员资格：所谓加入团队，就是被加进团队所有者的工作空间。团队角色共四种：

两条官方边界要记：其一，团队成员不能再邀请别人——邀请与移除是 owner 专属动作；其二，团队角色不等于企业版的角色管理(Enterprise roles)——团队角色只定义「是否属于这个工作空间、能做哪些团队级动作」，企业版角色才管理 administrative 资源的操作权限。开源版读者记住前者即可，后者留个印象，免得把两套概念混着用。

生效规则：五步判定的顺序

当用户对资源执行一个操作时，RAGFlow 按以下顺序评估权限(permission_effective_rules.md 原文顺序)：

1. 用户是否已正式加入资源所属的团队；
2. 资源的共享范围是否允许团队访问；
3. 用户是否拥有知识库级、资源级或协作者级的 Read、Write 或 Manage 权限；
4. 目标文档是否还有文档级的 Read、Write 或 Manage 权限要求；
5. 当前操作是否被该资源类型的权限表允许。

配套三条规则：资源所有者永远拥有一切权限；资源设为 Only me 时只有所有者能访问，设为 Team 时只有满足权限条件的团队成员能访问；若存在更细粒度的权限(如知识库内的文档级权限)，它叠加在资源访问权限之上继续生效。

用一次走查把五步跑一遍——新邀请的店铺运营成员想访问 after-sales-kb(贯穿案例演示，第 3 章建库时 Permissions 已设为 Team)：①她接受了邀请，角色是 normal，在团队里；②数据集共享范围为 Team；③知识库级权限允许其读取；④目标文档无额外的文档级限制；⑤她的操作是查看与提问，在权限表允许范围内——五关全过，访问成立。若第③步她只有 Read 级权限而操作是上传文件，判定就会停在那里。官方同时明确：共享知识库的团队成员可以上传并解析文件(share_knowledge_bases.md)——第③步对「用库」的成员通常放行到写操作，但对「删库」不放行：删除知识库更严格，一般要求操作者是创建者(resource_sharing_from_the_team_perspective.md)。

资源类型与权限级别

操作权限覆盖的资源类型共七类，常见权限级别为 Read(读)、Write(写)、Manage(管理)，不同资源使用不同的级别组合；所有者永远拥有该资源的最高权限：

诚实注记：官方文档列出了七类资源与三个常见级别，但没有逐一给出每类资源「哪个级别对应哪些具体操作」的完整映射表——这一层以界面实际展示为准，本书不杜撰。运营上够用的粒度是：Read 大致对应查看与使用，Write 对应上传、解析与配置修改，Manage 对应共享与权限管理类的重操作；拿不准的操作，以界面按钮是否可见、是否报权限错误为准。

13.3 共享机制：默认不共享，显式才生效

共享范围配置(开源版)

开源版的共享范围通过资源配置页的 Permissions 字段配置，两个选项(open_source_edition_sharing_scope_configuration.md 原文)：

• Only me：仅资源所有者可以访问；
• Team：资源在团队内共享。

最重要的一条官方原文单独放这里：资源不会自动共享——要让其他用户能用，必须显式配置共享范围或权限。这不是限制，是安全默认：知识库默认待在 Me 空间里，直到 owner 决定把它交给团队。同时别忘了 13.2 的三层结构：设为 Team 也不必然人人可见——系统仍会检查用户是否属于 owner 的团队、资源是否支持团队共享、操作是否被权限规则允许。

三类资源的共享入口

支持团队共享的资源——知识库、Agent、聊天助手、搜索应用、Memory——各有各的配置入口，落点不同：

共享知识库有一条值得单独记的行为差异：用与改的门槛不同——成员可以上传与解析(官方明确)，而删除知识库一般要求创建者本人。运营含义：把共享库想成「团队的公共工作台，但门锁与拆迁权在 owner 手里」。

团队内共享之外还有更大的出口：知识经 MCP Server 暴露给平台侧 Agent 消费(见第 11 章)(→ mcp 书)——MCP Server 同样在七类资源之列，共享给平台 Agent 时知识版本与内容的治理约定，在 mcp 书展开；本章先把「人」这一层管好。

邀请与成员管理(轻)

邀请流程四步(invite_members.md)：打开 Team 页 → 在 Team members 区点击 Invite → 输入对方 email → 点击 OK。三条边界：email 必须属于已存在的 RAGFlow 用户，否则返回 user-not-found 错误；已加入或已在邀请中的用户，重复邀请会被拒绝；邀请创建后成员记录以 invite 角色存在，对方接受后才转为 normal——团队页的 Joined teams 区里能看到待接受的邀请。

四步流程的起点画面是下面这张。这张截图来自 2026-11-04 实测于本机 Docker 部署的 RAGFlow v1.0.0-rc2，owner 账号「书舟」的 Team 页：

13.2 说的「团队页以昵称 + workspace 为标题」就是这块页面：标题里的书舟 workspace 是 owner 的工作空间，Joined teams 区里始终有创建者自己一行——工作空间即团队，自己就是第一个成员。邀请动作的入口是右上角的 Invite member 按钮，四步流程从这里开始。

在 Invite 弹窗输入 demo2@ragflow-book.local 并确认后，同一个页面变成下面这样（同日同实例实测）：

上一段正文的「邀请创建后成员记录以 invite 角色存在」在这里兑现：State 列的 Invite 徽标就是 invite 角色——接受前不算正式加入，owner 随时可从 Action 列的删除图标撤掉邀请。一个实测前提要补：邀请前对方必须已完成注册——实测邀请未注册邮箱会报「102 user not found」，弹窗提示 Only registered users can be invited，与本节「email 必须属于已存在的 RAGFlow 用户」的边界一致。

同一份邀请在被邀请方那边长这样。这张截图来自同日实测：切换到「演示二号」账号登录后的 Team 页，对应正文说的「Joined teams 区里能看到待接受的邀请」：

待接受的邀请不在通知里，而在被邀方自己的 Joined teams 区，接受动作就在这一行——Accept 之后，13.2 的成员关系（user_tenant）才正式建立，角色由 invite 转 normal；Decline 则直接谢绝。前两张图与这张合起来是邀请链路的两侧：owner 侧看到 Invite 徽标，成员侧看到 Accept/Decline。

成员管理一句话总结：默认每人一个同名团队；只有 owner 能邀请与移除；成员加入后能帮上三件官方点名的忙——向共享数据集上传文档、解析共享数据集中的文档、使用共享的 Agent。最后一步是运营动作(本书立场)：配置完共享，换一个成员账号登录验证可见性——共享范围配错方向(该 Team 的留在 Only me)或配过头(不该共享的共享了)，都只有换账号才看得出来。

「换一个成员账号登录验证可见性」的实测结果就是下面这张。这张截图来自同日实测：演示二号接受邀请后，登录自己的 Dataset 页：

「资源不会自动共享，显式配置才生效」在这张图里是可验证的：owner 侧把 Permissions 设为 Team 之后，成员账号的 Dataset 列表出现同一数据集，卡片上以他人昵称「书舟」标注共享来源——共享范围配错方向（该 Team 的留在 Only me，或不该共享的共享了），只有这样换账号才看得出来，本节的运营动作由此有据。

13.4 多租户知识库治理：系统管权限，SOP 管秩序(本书立场)

本节与 13.7 的治理设计为本书立场：官方提供的是权限能力，本节给的是把这些能力组织成秩序的方法。

先校准「多租户」

开源版语境里的「租户」要和 SaaS 的多租户区分开：RAGFlow 中每个用户即一个工作空间(tenant)，团队协作的本质是把成员加进 owner 的 tenant(13.2 的 user_tenant 关系)；第 12 章配置 Langfuse tracing 时「userId = 租户」指的正是这层。所以一套部署服务多个业务团队时的隔离形态是逻辑多租户(本书立场表述)：每个业务团队以一个账号为 owner 建 Team，知识资产归属 owner 的工作空间，隔离边界由团队边界 + 共享范围构成——不是物理隔离，是权限隔离。

业务域与店铺划分

贯穿案例的设定(第 3 章)：after-sales-kb 的 Permissions 设为 Team，「客服与各店铺运营共用」。把它推广成治理约定(本书立场)：一个业务域一个 Team，一批数据集归属这个 Team 的 owner。划分的判据不是组织架构图，而是知识的使用边界：谁日常要检索这批知识、谁对它的正确性负责，谁就该在同一域内。跨域消费不靠把所有人拉进一个超大团队，而靠应用层组合——第 7 章的多数据集检索已经演示过：应用按需挂载数据集，数据集按域归属。

数据集命名规范

数据集多了之后，列表页的第一道秩序是命名。本书立场给一条最小规范：{业务域}-{内容类型}[-{限定项}]，小写连字符：

配套两条：命名写进建库申请单(见下)；个人试验数据集留在自己的 Me 空间，成熟一个、规范命名一个、再共享一个——共享空间的列表页保持干净。

生命周期：建 → 审 → 更 → 撤

每个数据集都有生命周期，四态(本书立场)：

数据集生命周期(本书立场)

「审 → 撤」两端是治理最薄弱的地方，也是第 7 章样例三的直接教训：2024 版旧文档当年没有人执行「撤」，才有了新旧切片同场的抽签。下架不是删文件了事——归档留痕(何时下架、谁批准、替代版本是哪份)，让「为什么库里没有 2024 版」随时可答。

谁拥有谁巡检 + 系统/SOP 分工表

本节的立场可以压成一句话：谁拥有，谁巡检——owner 权限系统已经给了(永远拥有最高权限)，巡检责任要靠 SOP 落实(13.6、13.7)。官方能力与团队秩序的分工总表：

表格的读法：左列是目标，中列是系统已经白给的，右列是必须写进团队规范、指定责任人的部分——治理设计的大部分工作量在右列，这正是本节存在的理由。

13.5 文档更新流程：让新版「确定」生效

两条更新路径

文档更新的第一条分叉：内容从哪来。两条路径的节奏完全不同：

自动同步路径最常见的问题官方也给了排查入口：「明明改了，知识库里怎么还是旧的」——先查刷新间隔到没到、同步状态、数据源日志(add_to_knowledge_base_and_sync.md；第 3 章 3.4 已给过同一处方)。物流时效公告(shipping-notice)这类持续更新的内容走数据源路径；《售后政策手册》这类「一版一定稿、改版要审批」的内容走手动路径——贯穿案例两类都有，不是巧合：按内容的变更性质选路径，而不是按文档格式选(本书立场)。

变更审批、重解析与工件重编译

手动路径的第一个闸门是变更审批(本书立场)：业务 owner 审内容(条款对不对、生效范围是哪些站点)，知识库 owner 审配置(新文档的元数据、解析配置是否沿用)。审批通过后，进入技术侧的连锁动作——每一步都有第 4、6 章立过的约定：

• 重解析：配置变更不回溯(4.6.3)——改了切片配置、列角色、元数据规则，都只对之后的解析生效，存量文档必须重新解析才吃得到新配置。第 4 章的约定在这里升格为纪律：「改配置 → 重解析 → 检索测试」是一个动作，不是三步。
• 工件重编译：工件不随文档更新自动重生成(第 6 章)——文档增删后 Artifacts 页出现 Update 提示与待更新数量，核对后手动同步；同一文档内容更新的提示行为以界面实测为准，但无论提示是否出现，新版解析完成后导航工件必须人工确认重编译，并按 6.5 检查表抽检。
• 换模型的特例(官方 FAQ，核实日期 2026-10-27)：换 embedding 模型触发兼容性检查——抽样对比新旧向量，平均相似度不低于 0.9 才允许切换且无需重解析；不达标则必须清空切片重解析，或用新模型另建数据集。换 reranker 只影响排序、换 LLM 只影响生成，都不需要重解析。

把常见变更的下游动作合成一张表，更新时照单执行：

更新流程全景

文档更新流程：两条路径汇入同一条技术链

贯穿案例：《售后政策手册》10 月改版全流程演练

把本章前半部的所有机制串成一次真实改版(日期与站点设定为贯穿案例演绎)：

第 6 步值得单独说透，它是本章权限机制与第 7 章检索机制的会合点：共享范围管「谁能进库」，元数据过滤管「能看到哪条」——团队共享(Team)让东南亚与欧洲的店铺运营都能访问 after-sales-kb，站点级的差异隔离不靠再建一个数据集，而靠元数据 + 检索过滤在内容层完成。两层各管一段，混着用(比如为每个站点建一个独立数据集)会让数据集数量膨胀、维护翻倍；只用一层(只建元数据不配过滤)则等于没隔离。

13.6 质量巡检：让衰退被及时发现

先看哪本账：logs

巡检的第一入口是数据集的 Logs 页(docs/guides/dataset/logs.md，核实日期 2026-10-27)。页面顶部是统计行：Total files、Processing、Downloading 等；下方按日志类型分两层——注意官方特别强调：两者不是父子日志或汇总关系，记录的是不同类型的任务：

排查口诀一句话(官方原文归纳)：先判断问题发生在单个文档还是整个数据集，再去对应的日志看。Status 为 Failed 就打开 Operations 里的日志详情看具体错误；长时间停在 Pending、Running 或 Schedule，先核对状态与开始时间再判断是否仍在正常运行。日志把「解析坏了」从感觉变成记录——13.6 的日巡检扫的就是这本账。

这本账在真实实例里是下面这个样子。这张截图来自 2026-11-04 实测于本机 Docker 部署的 RAGFlow v1.0.0-rc2，after-sales-kb 的 Logs 页，四个文档全部解析完成：

与上面对比表的一个实测差异要如实给出：rc2 的日志实际分 File / Dataset / Data source 三层并列标签，比官方文档写的「两层」多出 Data source 一层（数据源同步任务的日志），口径以界面为准。任务表里 Ingestion pipeline 列直接显示每份文档用的解析管线——前三份走 general，.eml 邮件归档走 email，第 3 章的数据源接入与第 4 章的管线选型在这里留下记录；顶部 Processing 卡片的 Success 4 / Failed 0，就是日巡检要扫的那个数。

日志之外的定位框架沿用官方 FAQ 的四步：「答案不对」先分层——文档解析是否正确 → 切片是否包含预期内容 → Retrieval Testing 能否召回相关切片 → 检索正常而回答仍错，才查应用设置、Prompt 与模型。配套两条 FAQ 结论值得贴在巡检手册里：解析成功不等于可检索成功(还要过切片、嵌入、阈值、rerank 几关)；答案在库里不等于会被检索到、更不等于模型会遵循(幻觉三查：索引、召回、生成)。这两条是巡检时「别急着归罪解析」与「别急着归罪模型」的依据。

定期回归：测试集是巡检的仪表盘

13.6 的技术底座全部在第 7 章：32 条测试集、期望切片、命中率与 MRR。巡检语境下只补三条运营约定(本书立场)：

• 周检抽测，月检全量：周巡检只跑版本敏感型子集(改版后最容易回退的一类)；月巡检按基线配置快照全量复跑，产出命中率与 MRR 与上月并排。
• 重解析之后先修测试集再回归：切片边界变了，期望切片映射整体失效——直接跑只会得到假警报(7.6 的特殊情形条款)。
• 回退逐条归因：退步条目按三分定位法(7.5)归类，归了类才知道改动该回滚还是补配套——巡检记录里存「结论」而不只是「分数」。

巡检节奏表

把 logs、回归、权限、工件合成一张节奏表(本书立场，频率与责任人为建议值，团队按规模裁剪)：

演练的巡检记录(13.5 第 7 步)落到这张表上就是三行台账：更新时延 D0→D+2(手动路径，含审批)、回归命中率与上轮持平且版本敏感子集全过、2024 版手册已下架归档(批准人、替代版本留痕)。台账不必精美，必须存在——它是 13.7 指标的原始凭证。

13.7 运营指标与 SOP(本书立场)

三个起步指标

运营要记账，指标先于仪表盘(→ langfuse 书 的线上指标体系管「回答质量」，本节的三个数管「知识供给」——两者互补，不重复)。起步只记三个：

第三个指标最容易被忽视也最要紧：工单反哺测试集是「检索质量是运营出来的」(第 7 章)在机制上的闭环——客服答不好的问题，先查是知识没进库(13.5)、进库没召回(第 7 章)、还是召回没答对(第 8 章)，定位后把问题沉淀进测试集，下一轮回归就有了新考题。线上 trace(第 12 章，→ langfuse 书)与工单是它的两个输入口。

一页 SOP

把本章全部动作压成一页可落地的清单，贴墙即用(频率与角色沿用 13.6 节奏表，触发式条目除外)：

全书收束：13 章路线回顾

最后把贯穿案例走过的路完整收一遍——部署 → 构建 → 调优 → 消费 → 运营，每一章一句话，每句话落一次案例足迹：

这条线的起点是第 1 章那个翻车的客服问答——「运输破损的赔偿标准是多少」答出三段不相干的物流文字；终点是本章：同一家公司的政策手册完成了 10 月改版，两天内新版条款对指定站点「确定」生效，旧版归档有据，回归全绿有台账。起点到终点之间没有一行魔法代码，是 13 章的工程方法在接力：部署把引擎跑起来(第 2 章)，建库与解析把知识放进去(第 3、4 章)，增强与编译把知识加工好(第 5、6 章)，调优把检索做可信(第 7 章)，应用把知识交到用户手上(第 8-11 章)，运维把平台稳住(第 12 章)，运营让这一切持续成立(本章)。

本章小结

1. 上线只是开始：知识腐败(knowledge rot)是无人治理时的默认趋势；对抗它的是运营三件事——权限与共享治理、更新流程、质量巡检，本章各节一一对应。
2. 权限三层 + 生效五步：团队成员关系 → 共享范围 → 操作权限，层层收紧；判定按官方五步顺序走；owner 永远全权限，删除知识库一般要求创建者。
3. 默认不共享，显式才生效：开源版 Permissions 字段 Only me/Team 两档；知识库共享后成员可上传与解析；邀请只有 owner 能做，invite 角色接受后才转 normal。
4. 治理 = 系统能力 + SOP：系统管权限边界，SOP 管命名、生命周期(建→审→更→撤)与巡检责任——谁拥有谁巡检(13.4，本书立场)。
5. 更新是流程不是事件：两条路径(自动同步/手动上传)汇入同一条技术链——审批、重解析(配置不回溯)、工件提示制重编译、测试集回归、应用落盘与共享复核；「共享范围管谁能进库，元数据过滤管能看到哪条」。
6. 质量是巡检出来的：logs 分文档级与数据集级两层；周抽测、月全量回归；更新时延、命中率、工单反哺三个指标记账，SOP 一页贴墙。

全书完。下一步不在书里，在你的知识库上：把第 13 章的 SOP 表改成你们团队的版本，填上真实的人名与频率——从今天的第一条台账开始。

验收清单

读到这里，你应该能：

• ☐ 按顺序说出权限三层模型与生效规则五步，并用一个新成员访问共享数据集的例子走一遍判定；
• ☐ 为一位新成员走通「邀请 → 接受 → 配置共享 → 换账号验证可见」的完整流程，并说出邀请为什么只有 owner 能做；
• ☐ 说出「Team 共享 ≠ 自动可见」与「删除知识库一般要求创建者」两条规则的出处与运营含义；
• ☐ 为一次文档改版列出完整下游动作清单：审批、重解析、工件重编译、测试集回归、应用落盘与共享复核，并说出漏掉每一步各会发生什么；
• ☐ 区分文档日志与数据集级日志的适用症状，并按日/周/月节奏表为自己的知识库排出巡检班表；
• ☐ 用更新时延、巡检命中率、工单反哺数三个指标为自己团队的运营记一个月的账；
• ☐ 把 13 章路线表讲给一位新同事：每章一句话，指出贯穿案例在第几章完成第几步。

延伸阅读

• 第 12 章(生产运维)——与本章互为两半：第 12 章管平台稳定，本章管内容质量，两章合起来才是「生产就绪」的完整含义。
• 第 7 章(检索测试与调优)——巡检回归的技术底座；测试集台账、三分定位法与本章节奏表对接。
• 第 6 章(知识编译与知识工件)——Update 提示制与工件检查表的出处；13.5 演练第 4 步的依据。
• (→ mcp 书)——知识经 MCP 共享给平台侧 Agent 时的版本协同与内容治理(见第 11 章)；本章管「人」的共享，那边管「Agent」的共享。
• 官方文档 Team 全节(docs/guides/team/)与 dataset/logs.md——本章权限、共享、成员与日志素材的原文；权限模型随版本演进较快，争议时以官方最新文档为准。

复核清单(发布前)

• [ ] 全章对照官方素材原文复核(docs/guides/team/ 下 permission_system_overview、sharing_scope_configuration、team_management 三组，docs/guides/dataset/logs.md，docs/guides/data_source/add_to_knowledge_base_and_sync.md，docs/faq.mdx 相关条目；素材核实日期 2026-10-27)——权限与共享模型随版本演进快，发布前重对一遍
• [x] 部分界面操作已于 2026-11-04 实测(截图见本章):Team 页邀请全流程(邀请→invite 徽标→被邀方 Accept→换账号可见共享数据集)、Logs 页;实测补充:邀请前对方必须已完成注册(未注册邮箱报 102 user not found)
• [ ] 仍待实测:Permissions 字段切换后的实际可见性矩阵、Agent 设置对话框与 Memory 高级设置的共享入口、Artifacts 页 Update 提示
• [ ] Read/Write/Manage 到具体操作的映射官方未逐一载明，13.2 仅给「常见级别」的运营粒度表述——待界面截图确认后决定是否补充
• [ ] 「同一文档重新解析是否触发工件 Update 提示」：官方明确文档增删触发提示，同文档内容更新的提示行为待实测(影响 13.5 演练第 4 步表述)
• [ ] 演练设定(改版日期、东南亚站点划分、version/region 元数据取值)与巡检节奏、指标定义、SOP 角色分工均为本书立场或案例演绎，非官方素材——已在文中标注，定稿时确认标注完整
• [ ] 13.7 收束表中第 8、9、10 章的一句话回顾依据第 1 章路线图与第 12 章衔接段撰写，未逐章复核原文——发布前对照各章小结核对