知识归属，指团队在让 Agent 读取资料之前先说清楚：谁维护、谁确认生效、哪个版本作数、出了错如何追溯。这篇讲为什么它决定 Agent 答案的可靠性，以及从哪一类资料开始。
团队准备让 Agent 接触内部资料时，第一反应往往是「把文件接进去」。
产品文档、制度、项目记录、客户方案，似乎只要放进某个知识库，Agent 就能开始帮忙。但用不了多久，问题会换一种形式回来：销售 Agent 读到的报价规则和财务手里的版本不一样；项目助手引用了一份已经作废的交付说明；有人问它答案从哪里来，它只能给出一段看起来合理的话。
这不只是模型能力的问题。模型、解析和检索都会影响答案；但资料被不同的人、不同工具和不同流程各自保存时，Agent 会更快地把原本不容易看见的不一致暴露出来。
先问：这份知识到底归谁管
团队里的知识不必都放进同一个地方，但每一类重要资料都应该有一个明确的源头。
有些资料需要频繁更新，应该由某个业务角色维护；有些是项目期间的临时判断，过了阶段就不该继续影响后续工作；还有一些涉及权限，销售能看、交付未必能看。
在接入 Agent 前，至少要说清楚几件事：谁负责更新，谁确认生效，哪个系统或文件是准本，以及旧版本何时失效、如何撤下。知识服务不必取代这些源头；它更应该跟随源头，把可用的版本持续同步出来。
权限也不能只在导入资料时粗略分一次。每次检索都要根据提问者和 Agent 的身份筛选结果。否则，把资料接进来，实际是在扩大它可能被不该看到的人读到的范围。
如果这些边界没有先说清楚，给 Agent 增加资料只是在扩大它能访问的范围。它也许会答得更快，却未必答得更可靠。
我会建议团队先挑一类边界清楚的资料开始。比如当前生效的产品资料，或者一个项目组共同维护的交付规范。先把谁更新、谁确认、旧版本怎么处理说清楚，再考虑接入多少 Agent。
Agent 给出的答案要能回到原处
人在会议里引用一份资料时，通常会说「这个结论来自上周的方案」或者「我记得合同里有一条」。Agent 也应该有类似的能力。
一次回答至少应能回到原始资料：是哪份文件、哪个版本或生效日期、哪一段内容。必要时，还应留下当次检索到哪些资料的记录。这样当结果不对时，团队才知道该改资料、补同步、调检索，还是改 Agent 的使用方式。
引用本身不是答案正确的保证：它仍可能引用过期、无权限或不够相关的内容。但可核对的来源，能让团队不必因为一句回答听起来流畅就接受它，也不必在每次出错后重新猜测发生了什么。
两个 Agent 开始读同一批资料时
第一个 Agent 往往可以在自己的应用里维护少量知识。它服务一个明确场景，先把事情做起来更重要。
第二个 Agent 出现后，事情会变得有些别扭。两边都要导入同样的文件，都要决定怎么切分、怎么更新、怎么处理权限。一次资料修订，可能要在两个地方重复操作；一边同步失败，旧内容就可能继续被引用。
这时，团队需要共享的已经不是文件副本，而是把权威资料变成可检索、可核对知识的过程：导入、版本、权限、更新和来源依据。
我在做的 琅嬛 是其中一种工程实践：把这套过程放在一个独立的知识服务里，让不同的 Agent 或应用按自己的需要调用。它不替团队决定答案，也不替代原始业务系统；它负责把当下能核对、可授权的资料交出来。
从一小块资料开始
不必一开始就整理整个组织的知识。
选一类正在反复被问到、又经常因为版本不清而出问题的资料。让一个 Agent 使用它，准备一组团队认可的问题，观察几周：谁在维护，资料更新后多久能生效，答案是否能回到来源，哪些问题真的被解决，哪里仍然需要人判断。
如果这件事跑通了，再扩大范围会轻松很多。否则，越早把资料接进 Agent，越早把原来的混乱放大。