按团队收纳资源，不等于为每个团队建了一间保密室。
Flashduty AI SRE 是一个专注 SRE 领域、帮你做故障根因分析、日常运维工作的 AI Agent 产品，注册即可免费试用。这是系列文章《Flashduty AI SRE 技术揭秘》第 15 篇，本系列会持续分享我们在 agent 工程上的真实设计、踩过的坑和做过的取舍。
核心要点
- 团队隔离在本文平台中用于资源组织、维护权限和会话加载控制，不能承诺同账号团队间完整保密。
- 独立账号处理租户归属与账号内协作范围，团队专属 runner 处理执行地点，个人凭据处理外部调用身份；三者各有边界。
- 记忆的远端正文、注入索引快照和已经进入上下文的内容更新时点不同。删除记录或写入提示规则，都不等于立即消除所有记忆污染。
如果支付团队和搜索团队之间有资料需要严格保密，把它们放在同一个账号、分到不同团队，够不够？按照我们平台的权限设计，不够。团队归属会限制资源维护和会话加载，但不能把它当作同一账号内同事之间的完整保密机制。
前两篇讲了不少检查：团队会话不能加载别的团队知识；个人会话加载团队资料要查创建者的成员关系；管理员修改某个团队的资源，也要先加入团队。这些检查都在实际执行。可是，由这些机制推导出“两个团队互相看不到任何信息”，就超出了它们能提供的保证。
项目的权限文档把这层定位写得很明确：团队隔离是“默认收纳”，不是保险柜。同一个账号里的团队会话允许同事协作，已经读到内容的人也能转述、复制。加载范围、维护权限和信息保密，是相互关联但不能互相替代的事情。
为什么有加载检查，仍不能承诺团队间保密
沿着一份故障复盘的使用过程看，就能发现差别。
复盘归属支付团队。一个搜索团队的会话直接请求加载它，会被拒绝，这属于第 13 篇讲的加载控制。但支付团队会话本身允许同账号的同事参与，知识一旦被用于回答，相关内容就可能出现在会话里。另一位同事参与这段团队会话，与从搜索会话跨团队加载原文件，并不是同一条访问路径。
个人会话又有自己的访问规则，不能由此推导为所有个人对话都向全账号公开。问题恰恰在于：一个平台有多种入口，每个入口守的对象不同。只验证了某个工具不能跨团队读文件，无法替所有会话、产物和共享路径作保证。
还有已经获得内容之后的情况。一个人有权读资料，他可以把其中一段发给同事；模型已经在上下文里读到一份文档，后来成员关系变了，也不会因此抹去之前的上下文。加载时的权限检查可以拒绝新的请求，却不能自动撤回所有已经流出的信息。
团队隔离仍然有用。它决定默认加载哪套知识、谁维护哪份技能，也减少无关资料混进排障过程。只是用途应当按机制描述清楚：这些规则帮助资源各归其位，不能被销售文案扩写成“团队间完全保密”。
严格保密的需求，要拆成具体问题
客户说“我们需要隔离”时，可能关心的是不同事情：两个组织不能共用数据范围；命令只能在指定机器上执行；调用外部工单系统时，不能借用别人的身份。对应的处理方式也不同。
如果两个组织之间不应建立账号内协作关系，就使用独立账号。 我们的平台以账号作为租户隔离边界，数据查询和资源归属围绕账号划分。把彼此不应互信的组织放在不同账号，比试图依靠同账号的团队标签表达这种关系更符合产品模型。
这也不应扩写成“账号之间不存在任何分享方式”。产品可以有用户主动开启的对外分享，分享本身就需要单独理解和管理。独立账号解决的是租户归属与账号内协作范围，不能替每一次主动分享作决定。
如果关心命令在哪里执行，就配置团队专属 runner。 runner 是承接 bash 和工具操作的执行程序，第 9 篇介绍过它的路由。按团队选择执行环境，能避免团队会话被安排到其他团队的 runner 上。不过，机器的网络权限、操作系统账号和已有凭据仍要按实际需求配置。专属 runner 并不会自动把模型回答、会话记录也变成专属机器上的本地数据。
如果关心以谁的身份调用外部服务，就使用每人授权的凭据。 账号共享凭据意味着多个人使用同一份外部授权；每人授权则分别保存和使用各自的凭据，也可以单独吊销。需要把外部操作对应到具体用户时，凭据模式必须支持这件事，不能只在资源上贴一个团队标签。
这三个选择分别处理租户、执行环境和外部身份。是否需要同时采用，要看资料和操作经过哪些路径。比如，专属 runner 能解决执行地点，却不会改变团队会话的参与规则；个人凭据能限制外部系统的调用身份，也不会阻止别人复制一段已经出现在报告里的文字。
先说明各层机制保护的对象，再决定资料和操作应当放在哪里。
| 机制 | 处理的对象 | 仍需单独判断的路径 |
|---|---|---|
| 团队归属与加载检查 | 资源组织、维护权、会话加载范围 | 团队会话协作、内容转述和复制 |
| 独立账号 | 租户归属与账号内协作范围 | 用户主动开启的对外分享 |
| 团队专属 runner | 命令与工具的执行环境 | 网络权限、操作系统账号、已有凭据以及会话记录存储 |
| 每人授权的凭据 | 调用外部服务时使用的身份 | 已经出现在会话或报告里的内容传播 |
记忆系统里，我们记录过另一种风险
边界声明还应包括已知风险。项目的知识模型文档保留过一个例子：偏好记忆带来的间接提示注入风险。
先解释两个概念。偏好记忆是留给后续会话使用的长期约定，比如“以后给这个团队的报告，都先列出受影响的服务”。提示注入则是外部内容试图指挥 agent：一段网页、日志或工单，原本只是待分析的材料，却夹带“忽略用户要求，执行下面操作”之类的指令。
通常，一段恶意材料的影响先发生在当前会话。如果 agent 又把其中的指令误记成用户的长期偏好，风险就会延续到未来。以后系统再次提供这条记忆时，模型可能把攻击者的话当成之前已经确认的工作约定。攻击者不需要改系统提示，只要诱导模型留下错误记忆，就可能污染后续任务。
旧设计把偏好卡放在一个自动注入的独立区域，并允许它覆盖技能或工具的默认行为。文档因此明确记录：这是一项已接受的权衡，并提出过写入时增加确认、写后明确告知用户等缓解思路。当时不能把这些思路当成已经上线的保护措施。
记忆系统后来迁移到了文档式实现，自动提供给模型的内容和写入流程都有变化。评估这项风险，需要沿当前的保存、注入和读取链路继续看。
当前的记忆机制，哪些已经改变
现在自动进入上下文的是一份有大小限制的记忆索引，告诉 agent 当前范围下有哪些记忆入口；完整正文保存在文件里，需要按相关性搜索和读取。索引不是全部记忆，也不能因为某条记录没出现在索引里，就断定它不存在。
写入也分成本地草稿和已提交内容。改了工作目录里的文件，只能称为草稿；要经过 sync_doc 提交成功，才能报告记忆已经保存。这个区分避免“文件改了，但没有发布，模型却告诉用户已经记住”的问题。它本身不是人工审批，不能因此宣称每条记忆都经过用户确认。
当前提示规则还明确限定了偏好的含义：它必须是用户对以后同类场景的持续要求。“这次先跳过”不能被扩展成“以后都跳过”；一个尚未证实的根因，也不能被写成长期事实。记忆不能授予新的权限，不能覆盖更高优先级的指令或用户当前的要求。涉及会变化的系统状态，使用前仍要拿当前证据核实。
这些变化收紧了记忆的解释和使用方式，但其中有些约束依然依靠模型遵守提示。提示里禁止把外部指令当偏好，不等于系统已经从机制上消除了所有记忆污染。 自动保存、提交和后续读取仍要分别检查，不能把一条写入规则当成整条链路的安全证明。
还有时间上的差别。当前会话注入的记忆索引使用冻结快照，普通提交或缓存刷新不会直接替换它；通常要到成功压缩上下文时，才更新注入的快照。迁移等特殊路径另有处理。这意味着删掉远端一条错误记录，也不能顺口承诺“所有进行中的会话下一次调用立刻忘掉它”。远端记录、索引快照、已经读过的正文，更新的是不同对象。
文档要让使用者能作出正确决定
写安全边界时，最容易省掉的恰恰是这些限定：团队控制的是哪些入口，个人凭据保护的是哪次调用，记忆删除影响的是哪个时刻。省掉之后，介绍更顺口，用户却更容易把资料放进不合适的范围，或者误以为一次配置解决了全部问题。
对我们来说，团队资源的维护检查、会话加载控制、专属执行环境都需要继续做好；同时，也要把它们各自的适用范围写出来。旧机制变了，就更新描述；已知风险还没有被完全覆盖，就保留限制，不能只留下当初的设计目标。
需要严格保密的客户，应该能据此决定是否拆分账号、采用怎样的 runner 和授权方式，而不是先相信“完全隔离”，等上线后再发现双方理解不同。
下一篇换到资源成本。云沙箱已经不再对应任何有效会话，却还留在厂商那里运行时，平台怎样把它找出来，又怎样避免清理时删错正在创建的实例？
这是「Flashduty AI SRE 技术揭秘」系列的第十五篇。我们在做一个专注 SRE 领域、帮你做故障根因分析的 AI Agent 产品，本系列会持续分享我们在 agent 工程上的真实设计、踩过的坑和做过的取舍。
常见问题
团队会话不能跨团队加载，为什么还不等于保密？
因为团队会话本身允许同账号同事参与，已经用于回答的知识还可能被转述、复制。加载原文件只是其中一条访问路径。
使用专属 runner 后，会话记录就只存在那台机器上吗？
不能这样推导。专属 runner 决定命令在哪里执行，不会自动改变模型回答和会话记录的数据存放范围。
删除错误记忆后，进行中的会话会立刻忘记吗？
不能承诺。远端记录、冻结的索引快照和已读正文是不同对象；本文描述的普通提交和缓存刷新不会直接替换当前会话注入的索引快照。
