群里 @ 一下 AI，让它把上周的讨论摘要出来——这件事在很多企业已经能做。但真正要上生产，起决定作用的不是"能不能读到"，而是这次读取用的是谁的身份，以及结果最后能进谁的屏幕。
千问办公网页端 11 月 1 日的更新日志里有一条安全条目：后台群内容改用各资源原绑定人的身份读取，不再因身份不符而读取失败。这条更新解释了此前一类读取失败的原因，但也把一个更麻烦的问题摆到台面上：资源是 A 绑定的，提问的是 B，结果转发给了 C。三者的权限该怎么对齐，日志只说了第一段。
本文按接入视角拆这套链路，给一份可以照着跑的验收清单。文中的目录结构、日志字段和配置片段都是示例写法，不是某个产品的既定实现。
一、四个对象，不能用一个"已连接"状态代替
接入时最常见的偷懒，是把"资源可读"当成"权限通过"。实际上要分开看：
| 对象 | 要问的问题 | 可核查的证据 |
|---|---|---|
| 资源绑定身份 | 群/文件最初由谁授权绑定，凭据谁维护 | 连接器配置、资源标识、授权账号、绑定时间 |
| 请求发起身份 | 当前是谁在问，请求如何关联到具体员工 | 登录账号、组织角色、调用记录里的用户标识 |
| 结果接收范围 | 摘要、引用、转发能被谁看到 | 成员/非成员账号、引用链接访问结果、撤权后行为 |
| 审计主体 | 谁发起、用哪个身份读了哪个资源 | 工作台调用日志、连接器认证身份、目标系统记录 |
这四行里任何一行没验，都不能算通过。尤其是"读取身份"和"结果可见范围"，它们常常被同一句"群已连接"糊在一起。
二、先确认身份可映射，再谈读取
如果 AI 侧账号和目标系统的员工账号之间没有稳定映射，"用谁的权限读"在一开始就没有答案。这一层要在接入时单独验证，不能等出问题再倒查。
一个最小可用的测试记录结构，字段是示例：
{
"test_case": "group_summary_identity_check",
"resource": {
"type": "group",
"resource_id": "<示例-资源标识>",
"bound_account": "<示例-绑定账号>",
"bound_at": "2026-11-01T10:00:00+08:00",
"org_scope": "<示例-组织范围>"
},
"request": {
"actor": "<示例-提问员工>",
"org_role": "member",
"question": "上周这个群里关于交期变更的结论是什么"
},
"observed": {
"read_identity": "<实际使用的读取身份>",
"returned_fields": ["摘要", "引用链接"],
"visible_to": ["member"],
"audit_trace_ids": ["<工作台-调用id>", "<目标系统-访问id>"]
},
"result": "PENDING_REVIEW"
}
关键在于 read_identity 和 visible_to 必须分开记录。把它们写成一个字段，后面就没法判断问题出在哪一段。
三、五步验收，重点是第 4 步
- 选低风险资源。记录资源 ID、绑定账号、组织范围、成员列表和管理员配置，不要用真实敏感群聊做首次样本。
- 准备三类测试身份：资源绑定人、当前群成员、无群访问权限的员工。业务允许的话，再加转岗和绑定人离岗。
- 同一个问题，让每个身份各问一次。分别看实际读取的资源、返回字段、引用链接；再从各自账号打开结果、转发一次，确认接收范围。
- 撤销授权后复测。移除成员或撤销资源授权，检查新查询、历史会话、已生成产物、引用链接各自怎么变。这一步是分水岭——很多方案在新查询上做了控制，但历史产物和引用链接不在管控范围内。
- 交叉对账三侧日志。按时间和请求标识把工作台调用记录、连接器认证身份、目标系统访问记录对齐。共用凭据的场景要额外确认日志还能不能认出真实请求人。
第 4 步之所以关键，是因为它检验的是"状态已经变了"之后的系统行为，而不是稳态下的表现。稳态下能读、能看，说明不了撤权是否生效。
四、异常路径怎么记
- 授权变更后历史摘要仍可打开：记为待确认项，写明产品是否明示规则，不推断为自动撤权。
- 读取成功但审计对不上：先查是否共用凭据，再看连接器认证身份与目标系统记录的时间差。
- 同一问题不同身份返回不同内容：先分清是读取层差异还是展示层过滤，两者修复方式不同。
- 结果被转发到外部：转发行为本身可能绕过组织边界，需要在分享链路上单独定义规则。
这些现象都不要用"重试一次"掩盖。记成可复现的用例，才能在下一次发版时回归。
五、连接层的边界
星云PLUS AI 系统连接器面向不换现有系统的 AI 接入，按接入条件复用员工身份与权限，关键操作由人确认，调用过程可追溯；具体权限映射和兼容范围以项目验证为准。在已确认的范围内，它可以把 AI 用户映射到目标系统的员工个人账号，按员工或组织授权业务能力，由目标系统按自身规则判断数据权限，调用记录可用于查询与追溯。
但连接层不等于群平台的成员治理。群资源、历史内容、引用和分享范围，仍归目标平台控制。接入方案里要把这几层分别列出来，而不是假设其中一层能兜住全部。
对这个话题更完整的拆解和数据边界，见白皮书：www.xingyunzuo.cn/resources/a…
本文由星云PLUS团队整理。文中第三方产品的行为描述来自其公开更新日志与文档，核验日期为 2026 年 11 月 6 日，不表示存在官方合作；具体规则以产品文档与实际测试为准。
