2026 年 10 月 20 日，Microsoft 介绍 Work IQ 的 MCP 工具 retrieve。官方文档说明，它可以检索用户获授权的工作来源，返回面向模型的 Markdown 内容及带元数据的检索命中，并保留两者之间的引用关系。Microsoft 开发者说明
这为企业知识服务提供了一个具体参考：AI 需要可理解的上下文，使用者又需要回查依据。我们的建议是把两者作为同一份返回结果设计，避免只返回一段没有出处的综合摘要。
可读内容与原始命中各有用途
面向模型的内容适合组织当前问题相关的信息；原始命中与元数据则帮助应用定位来源、展示引用和处理不同资料范围。二者关联后，回答中的关键结论才能回到对应依据。
企业自建知识服务也可以采用这种分工。无需把整份数据库原样交给模型，而应提供当前任务需要的正文、对象身份、来源与时效。需要查看完整条件时，再支持回读原始页面或记录。
一份业务证据包应包含什么
| 部分 | 使用目的 | 检查重点 |
|---|---|---|
| 相关正文 | 让AI理解规则与背景 | 是否包含限制和例外 |
| 对象身份 | 确认说的是同一项目或产品 | 编号、别名与关联是否正确 |
| 来源入口 | 回查原文与记录 | 链接是否有效且可访问 |
| 时间信息 | 判断是否适用于当前工作 | 来源时间与生效时间是否清楚 |
| 访问范围 | 限制资料使用 | 是否符合当前请求人权限 |
| 缺失与冲突 | 说明不能直接确认的部分 | 是否被摘要悄悄抹平 |
“证据包”是这里对业务返回内容的称呼，不意味着建立一套复杂新格式。重点是让答案与依据保持对应，方便人核对、系统处理和后续纠错。
引用存在不等于引用正确
一个链接能够打开，只能证明页面存在。还要检查它是否真的支持这条结论、是否适用于当前型号、是否仍是现行版本。引用了正确文件中的错误段落，同样可能误导工作。
验收时应逐项对照结论和来源，特别关注数字、范围、否定条件和例外。对于模型综合推断出的建议，应明确它是建议，不能让读者误以为原文已经这样决定。
检索与委派分开设计
Microsoft 的说明区分了取上下文与委派工作的工具用途。这一分工值得借鉴：找资料应返回证据，执行工作应进入明确的任务和动作路径。用户只要求查询时，不应因为检索到了操作说明就自动触发业务动作。
企业实现时，可以让知识服务提供规则和相关入口，再由业务 Agent 判断任务是否需要动作，并交给后端权限与审批机制执行。知识可读权限和业务可写权限分别核验。
全量问题不能只靠相关命中
“与这个项目有关的资料”适合检索，“所有尚未完成的订单及金额合计”需要业务系统完整查询。检索命中通常按相关性挑选内容，不天然证明集合完整。
即便返回的证据包结构很好，也不能改变这个边界。消费 Agent 要知道什么时候继续查系统、什么时候需要分页、什么时候只能给出已找到的范围。否则包装精致的检索结果仍可能产生错误统计。
让服务接口服务于真实任务
建议使用一次跨来源任务检查返回结果：规则来自文档、决定来自会议、当前状态来自业务系统。让员工核对答案是否清楚区分三者，是否能打开出处，是否知道还缺少哪些信息。
再换一个访问范围较小的身份，确认受限内容不会通过摘要或命中记录泄露。产品文档能说明设计，但本企业的权限和任务效果需要在自己的环境验证。
评测方式见任务型知识验收，时效边界见背景读知识、状态查系统，整体建设见企业知识中枢。
更多同主题内容见企业 AI Agent 落地专题。
