要解决的问题
企业把智能体发布到 Teams 后，常让它回答内部文档的问题。SharePoint 的访问权限因人而异，财务、人事和项目经理看到的文档并不相同。托管智能体默认以自身身份运行，如果检索也用这个身份，就无法按提问者的权限过滤结果。
来源文章的核心判断是：这不是换模型或改提示词能解决的，架构必须把用户身份一路带到 SharePoint。
文章给出的做法
方案的原则是分工：模型推理仍用智能体自己的身份，检索则以登录用户的身份执行。文章列出三个环节：
- 智能体侧的 FoundryToolbox 在每次工具调用时附带请求标识，让平台知道调用属于哪位用户。
- 一个 UserEntraToken 类型的连接，把用户的 Entra ID 令牌传给 Azure AI Search 上的 Foundry IQ 知识库，即所谓的身份透传。
- 远程 SharePoint 知识源通过 Microsoft 365 Copilot Retrieval API 实时查询，并限定在指定站点路径内，内容不会被复制进索引。
落地分四步：创建知识库、建立带用户身份的连接并封装成只暴露检索工具的 toolbox、编写智能体、用 azd 部署并发布到 Teams。
适用场景与取舍
文章把这一模式与 Work IQ 做了区分：需要覆盖用户更广泛的 Microsoft 365 工作上下文时用 Work IQ；只允许智能体在限定的几个 SharePoint 站点内作答时，用本方案。我的理解是，这更像把 SharePoint 当作有明确边界的受控知识源。
对开发者而言，吸引力在于不必自建服务器、不必在检索路径放客户端密钥，也不必维护自定义的 OBO 代理。
几个值得记住的坑
文章总结了几类常见问题：
- 连接使用托管身份会导致检索失败，应使用 UserEntraToken。
- 每位最终用户都需要 Search 服务上的 Search Index Data Reader 角色，否则能访问智能体但检索失败。
- 自写 MCP 客户端可能丢失请求标识，作者在测试中观察到用户被错误地当成最先授权的人。
验证方式也值得借鉴：用两个用户、一份只有其中一人能打开的文档，在不同会话中测试，权限变更后重复。无权限的用户应得到“现有来源不包含答案”的回复。
仍待观察
文章注明，Foundry IQ 的远程 SharePoint 知识源在写作时仍处于预览阶段。预览功能的稳定性、区域支持和计费方式，上线前需要自行确认。另外，用户需要 Microsoft 365 Copilot 许可，这会影响推广成本。我的推测是，规模化部署时角色分配和权限回归测试会成为主要的运维负担。
原文链接：https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/building-permission-aware-hosted-agents-for-sharepoint-in-foundry-agent-service/4562526
- 作者:月明
- 链接:https://lunalight.top//article/azure-foundry-2026-10-14-4562526
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
