共享经验，不共享隐私：团队如何管理上下文
编辑标准与来源政策: 编辑标准, 团队. 内容均链至原始来源，见 方法论.
个人 Agent 记住用户偏好时，问题相对简单：这条记忆属于当前用户。
一旦进入团队，问题会立刻变复杂。
一套排障经验可以分享给所有开发 Agent，但客户信息可能只能给特定成员；架构 Wiki 可以面向项目组，个人工作习惯却不应该默认被管理员读取；Release Agent 需要发布 Skill，却不一定需要市场访谈记录。
因此，团队记忆的第一原则不是“全部共享”，而是“共享必须是一个明确动作”。
默认私有，是团队协作的起点
TencentDB Agent Memory 中，新产生的 Chat Memory 和 Skill 默认保持私有。当前仓库定义了四种可见性：
private：仅 Owner 可读，团队管理员也不例外；team：团队成员可以读取，由 Owner 或 Admin 管理；restricted：通过 User、Role 或 Agent ACL 精确授权；agent：在同一团队内定向装配给指定 Agent。
这套模型表达了一个重要立场：团队共享不能以默认泄露个人记忆为代价。
一条记忆从私人资产变为团队资产，需要明确的分享行为。需要收回时，也应该能够撤销授权或解除绑定。
“有权访问”不等于“应该出现在 Prompt 中”
权限控制通常回答某个人能否打开一份资料。但在 Agent 系统中，还要再回答一步：即使某个 Agent 有权访问，它是否应该在当前任务中获得这份信息？
TencentDB Agent Memory 通过 Fixed Binding 与 ACL 决定 Agent 的可用资产范围：先按照 Team、User、Agent 和可见性缩小边界，再结合当前请求召回。
例如：
- Release Agent 配装发布 Skill；
- 开发 Agent 共享架构 Wiki；
- Coder 与 Reviewer 使用项目 CodeGraph；
- Scout 使用市场研究 Wiki，但不读取工程成员的私人 Chat Memory。
这让权限从“谁能浏览资产”进一步延伸到“哪个 Agent 在执行任务时可以携带什么”。
为什么记忆资产需要 Owner、版本和状态
记忆并不是永久正确的静态事实。
产品决定会改变，操作流程会升级，文档会过期，代码关系会演化，自动抽取也可能出现偏差。如果系统只保存内容，却不知道内容由谁负责、哪个版本有效，就很容易把过期经验重新带回工作现场。
因此，一条可治理的记忆资产还需要 Owner、版本、状态、来源、可见性和绑定关系。人必须能够检查系统沉淀了什么，对错误内容进行校准，并在必要时撤回共享。
自动化可以帮助团队提取经验，但不应该取消人的最终控制权。
团队记忆需要身份链路
如果系统无法确认“当前是谁、属于哪个团队、使用哪个 Agent”，后续 ACL 就没有可靠基础。
TencentDB Agent Memory 的 Proxy 会把用户身份与团队、Agent、任务绑定起来，再按可见性决定资产范围。当前公开 CHANGELOG 还显示，Panel 登录侧已经兼容标准 OAuth2，并提供连接企业内部 OA/SSO 的适配骨架。
这里需要准确理解“兼容”的边界：不同企业的 OAuth2/OA 端点与字段仍可能需要适配。它是一条可实施路径，而不是对所有身份系统的零配置承诺。
可观测性也是治理的一部分
团队不仅需要知道“系统有没有记忆”，还需要知道哪些能力被调用、资产是否真的在使用，以及异常发生在哪个环节。
当前项目提供可选的数据分析与可观测性路径，用于记录 Memory、Skill、Wiki 与 CodeGraph 的工具调用。该能力默认关闭，并需要额外配置 ClickHouse。
这类限制应该在对外内容中明确说明。企业治理的可信度来自具体边界，而不是覆盖一切的承诺。
共享经验的前提是可以不共享
一个团队级 Agent Memory 的成熟度，不能只看它召回了多少信息，还要看：
- 它是否尊重所有者与团队边界；
- 是否只把相关资产提供给相关 Agent；
- 能否追溯来源与有效版本；
- 人能否修正、撤回和重新授权；
- 没有足够权限或证据时，系统能否不提供内容。
共享经验，不共享隐私。
对团队级 Agent Memory 来说，这不是一个附加功能，而是产品成立的前提。