一家企业可能同时使用办公平台里的 AI、员工个人助手和业务系统中的智能功能。最容易重复建设的部分，是每个入口都上传一份产品资料、写一套公司介绍、维护一套业务规则。入口增加之后，版本也跟着分叉。
比较稳妥的建设方向，是把企业正式知识作为独立服务维护，各个获授权入口按需读取。员工可以选择合适的工作入口，公司的档案、规则和来源关系仍然只有明确的维护位置。
共用知识不等于共用全部对话
企业共享的是正式工作知识，不是把每个员工的私人偏好和全部对话放在一起。个人助手可以记住使用者喜欢怎样表达，企业知识负责产品、职责、流程和获授权的业务背景。
一段个人对话中的纠错，可以提交给整理者；是否成为公司正式知识，仍需看来源、范围和批准关系。这样的分工能避免一个员工的临时意见被其他入口当作公司规定。
先定义知识服务返回什么
无论通过 API、MCP 还是现有平台连接器调用，都应向消费方说明页面内容、对象身份、来源、时效和可回源位置。接口形式可以不同，信息含义要一致。
| 服务内容 | 解决的问题 | 容易遗漏的部分 |
|---|---|---|
| 概览与目录 | 让AI知道企业有哪些知识 | 没有明确使用规则 |
| 关键词或语义检索 | 找到相关页面 | 只给片段、不支持全文 |
| 正文回读 | 理解条件与例外 | 断章取义 |
| 对象关联 | 找到同一项目相关资料 | 名称重复、身份混淆 |
| 来源与时效 | 判断可否直接使用 | 把整理时间当数据时间 |
| 反馈入口 | 纠正缺失与错误 | 每个入口各自改版本 |
检索能力并非越多越好。先让几项高频能力可靠、含义清楚，往往比一次暴露几十个近似工具更便于消费 Agent 使用。
身份必须跨入口对应到同一授权范围
员工在办公平台中的身份、业务系统账号和 AI 入口账号，可能不是同一个编号。接入时需要建立明确映射，并由知识服务或业务后端执行权限判断。
不能因为接口使用一个公共凭据，就让所有入口获得管理员可见内容。也不能把“这个Agent属于某部门”当作最终授权依据，仍要结合当前请求人、业务对象和企业授权规则限制数据范围。
读知识与做动作分别接入
共用知识解决背景与规则一致性，但查询当前库存、提交申请或更新单据仍然需要业务系统接口。知识页可以告诉 Agent 去哪个系统、按什么规则处理，真正的动作权限由业务后端决定。
例如，技术助手能读到某产品的选型资料，不代表它有权修改产品主数据；销售助手能看报价规则，也不代表可以越过审批发布特殊价格。把两种权限分开，才能让同一知识服务支持不同岗位。
接入能力逐个核实
支持同一种协议，不等于任何入口都能无改造接通。认证方式、可用工具、文件读取、长任务与引用展示能力，仍要逐一验证。采购材料可以约定可移植的知识格式和接口，但不能把“符合标准”写成“所有平台即插即用”。
对暂时不支持直接调用的入口，可以提供经过授权的导出或轻量适配，但要标明更新方式。否则一次导出很快会变成新的孤立知识库。
用同一道题检验一致性
让两个入口分别回答同一条现行流程问题，再修改正式规则并重复提问。检查它们是否读取同一生效版本、引用是否可回查、权限是否一致。再问一个实时状态问题，确认两个入口都去原系统查询。
这些检查能够区分“共用知识服务”和“复制了相同文件”。知识维护分工见统一整理机制，实时数据边界见知识与查数的分工，服务范围见企业知识中枢。
更多同主题内容见企业 AI Agent 落地专题。
