当很多员工和 AI 助手共用一套企业知识时，一个现实问题会出现：谁可以修改它？如果每次对话都能把临时判断写进正式知识，几天之后同一条规则就可能出现多个版本。比较清楚的分工是：使用者读取知识、提交补充线索；整理者结合来源统一更新；涉及业务裁定的事项由负责人确认。
这并不意味着日常维护都要人工操作。整理 Agent 可以承担归并、改写、关联和检查，但它要有固定职责与发布范围，而不是让每个业务 Agent 顺手改几页。
消费知识与修改知识是两种权限
销售助手读取报价规则，品质助手读取检验标准，项目助手读取交付流程。它们为了完成当次工作，都可能发现知识缺口，却不天然拥有修改全公司规则的权限。
例如，某位销售说“这单可以特殊处理”，业务助手应把它理解为需要核实的个案信息。即使这个例外最终获批，也不能自动改成所有订单都适用的新规则。知识写入要判断决定者、适用对象和批准依据。
新信息进入一个可追踪的收件入口
工作消息、会议记录、文档变更和人工纠错，可以进入统一整理入口。每项输入保留来源、时间、涉及对象和提交身份，让维护者知道这条线索从哪里来。
整理时不必逐条机械新增页面。重复信息可以归并，没有改变现行认识的记录可以只保留证据；影响当前状态的内容更新原有档案；构成新规则的内容则进入对应职能页面。处理结果应能说明是采用、补充、待确认还是不进入长期知识。
一次知识更新应完成的工作
| 环节 | 核心判断 | 形成的结果 |
|---|---|---|
| 读取上下文 | 已有哪些现行说明 | 找到受影响页面 |
| 对照来源 | 新信息是否可靠、适用于谁 | 判断变化与冲突 |
| 改写正文 | 当前读者应该知道什么 | 完整可读的现行内容 |
| 检查关联 | 哪些入口受影响 | 关联页与引用一致 |
| 检查共享 | 是否超出可见范围 | 合适的发布位置 |
| 留下记录 | 为什么修改 | 来源与修改说明 |
重要的是改写后的页面仍然像一份清楚的工作资料，不能只是不断追加“补充一、补充二、再次更正”，把判断负担重新交给读者。
冲突交给能够裁定的人
新消息比旧消息晚，不代表它一定正确。制度文件与一次口头建议冲突，可能需要职能负责人确认；两个业务系统对同一状态不同步，需要查清哪个是权威来源；不同项目的规则不同，则可能根本不存在冲突。
整理 Agent 应先呈现具体矛盾及各自适用条件，再提出需要确认的问题。没有批准依据时，可以保持原有规则并标记待确认事项，不能为让页面看起来完整而自行选边。
失败与恢复也属于维护职责
来源读取失败、附件无法解析或一轮更新只完成部分工作时，应保留明确处理状态。已经形成的正式知识继续可读，未完成部分不要标为已经更新。下一轮处理应知道从哪里继续，避免反复把同一输入写进多个页面。
人工发现错误后，应能定位影响页面、回查原始依据并修正。版本记录用于理解变化和恢复错误，不应把使用者带进复杂的工程操作。普通员工只需要指出“这条不对”，系统把反馈送到正确维护路径。
用两个同时发生的变化做验收
可以安排一条产品说明更新与一条项目例外同时进入，再检查：产品档案是否更新、项目例外是否只作用于指定项目、通用规则是否保持正确、消费 Agent 是否读到同一正式结果。
这种验收比让整理 Agent 总结一份干净文档更有价值，因为它检验的是多人共用知识时的秩序。相关目录组织见档案、职能与横切页，范围管理见员工库与管理库，建设服务见企业知识中枢。
更多同主题内容见企业 AI Agent 落地专题。
