要维护这个团队的资源，先成为团队成员。
Flashduty AI SRE 是一个专注 SRE 领域、帮你做故障根因分析、日常运维工作的 AI Agent 产品，注册即可免费试用。这是系列文章《Flashduty AI SRE 技术揭秘》第 14 篇，本系列会持续分享我们在 agent 工程上的真实设计、踩过的坑和做过的取舍。
核心要点
- join-to-govern 约束团队资源的维护权：包括 owner 和管理员在内，先加入目标团队，才能创建或编辑该团队资源。
- 参与团队会话、运行时加载知识、创建资源、编辑资源是不同权限，不能从其中一项推导其余各项。
- 资源转移同时检查当前归属和目标归属；设为账号级共享是维护权变化，现已收为 owner 和管理员专属。
假设你是账号管理员，排查故障时发现支付团队的一份操作手册需要修改。很多系统会直接放行：管理员当然可以改。我们的平台会先查一件事——你是不是支付团队的成员？没有加入，就先加入，再修改。
这条规则叫 join-to-govern，意思就是“加入之后再治理”。它约束的是团队资源的维护权：谁能在团队下创建技能、修改知识包、调整连接器、维护子 agent 或 runner 配置。管理员仍能治理账号级共享资源，但管理员这个身份，不再自动等于每个团队的维护者。
为什么要多这一步？因为平台里“能用”和“能改”承担不同的责任。如果把它们都塞进一个“管理员全权”的判断，团队归属很快就只剩一个展示标签，权限判断却不再需要它。我们希望归属能够约束实际的修改行为。
从一个例子分清几种权限
支付团队维护了一套排障技能，一位搜索团队的同事参与支付故障的会话。他能协作排查，并不意味着他应该顺手改掉支付团队的技能；反过来，某人有权维护一份知识，也不表示它应该在所有会话中自动加载。
理解这个区别后，再看平台的权限就容易一些。我们分别处理使用、创建和编辑，运行时加载还有第 13 篇讲过的独立规则。
使用侧，账号内允许协作。 已经归属某个团队的会话，账号内其他同事也可以查看、继续对话、发起 fork。fork 就是从已有对话另起一段会话。这种参与权不等于管理权，改名、删除等管理操作仍另有判定。个人会话的访问也另有规则，不能从团队会话的协作方式推导为“所有人的个人对话都公开”。
创建一个绑定支付团队的会话，则要求创建者确实属于支付团队，管理员没有豁免；另有服务端确认身份的系统代建通道，用于战情室等场景。普通调用者不能自己声明是系统身份。绑定之后，会话归属固定，后续参与者不会把它改成另一个团队的会话。
资源使用同样要看具体入口。团队会话只加载账号级和自己团队的资源；个人会话加载其他团队资源，要看创建者是否属于那个团队。“账号内允许协作”不能被解释成“在任意会话里都能调用任意团队的工具”。
创建资源，看目标归属。 要把一份技能建在支付团队下面，就必须是支付团队成员；要创建账号级共享技能，则必须是账号 owner 或管理员。这里的 owner 指账号所有者，权限判断与管理员一样处理。
编辑资源，看当前归属。 修改、删除支付团队的资源，同样要求真实成员身份，owner 和管理员也不能跳过。如果要把资源搬到搜索团队，还得拥有目标团队的资格。能从原处搬走，不代表能随意放到别人的团队里。
| 动作 | 团队范围 | 账号级共享范围 |
|---|---|---|
| 创建可定制资源 | 必须是目标团队成员，管理员无豁免 | 必须是 owner 或管理员 |
| 编辑、删除可定制资源 | 必须是当前归属团队成员，管理员无豁免 | 必须是 owner 或管理员 |
| 转移可定制资源 | 先满足当前资源编辑资格，再满足目标范围资格 | 转入共享还需 owner 或管理员身份 |
上表针对技能、知识包、连接器等可定制资源。用户生成的产物另有归属语义，不能直接套用这张表。
加入团队，要能真正改变下一次判定
如果系统提示“加入团队即可编辑”，加入之后却还得等一天，或者重新登录，用户很难理解这个规则。我们的成员关系来自实际的团队成员服务，只在单个请求内缓存。加入团队后，后续请求重新查询就能获得新的成员关系；查询失败也不会缓存成“你不属于任何团队”。
账号 owner 在这套模型里也是一个真实的人，可以正常加入团队。他不是一个悬在组织之外、永远没有团队的特殊身份。否则，“管理员先加入”的规则就只适用于一部分管理员，到了 owner 这里又不得不开例外。
拒绝文案也要能帮助人继续操作。对于管理员，错误会说明资源归属哪个团队、当前是什么角色、可以写哪些范围，以及加入目标团队后就能编辑。普通成员还可以得到另一条建议：如果只是想做自己的版本，可以 fork 到有权维护的团队里修改，不必直接改原件。
这些提示不能替人批准入队，但能避免用户面对一句 permission denied，反复猜测自己到底缺了哪个权限。
我们确实给管理员开过例外，后来又收回了
这套规则并非始终如此。代码历史里，管理员曾拥有查看和编辑其他团队资源的豁免。后来我们收回这条捷径，让所有角色都查询自己的真实团队关系。
这样的变动会影响两个地方。编辑接口需要按真实成员关系判断；管理页面的资源列表也应当呈现相同的范围，否则页面列出了许多资源，点进去却不能维护，归属规则就难以理解。
那次修改中，八个已有的 Customize 列表处理器不需要逐个重写，就随公共函数一起收紧了：公共函数原先对管理员返回全量范围，后来改为返回本人所在团队。消费这份结果的列表自然跟着变化。
这段历史说明了权限判断为什么需要集中。若每个列表都自己写一句“管理员看全部”，收回规则就得挨个找；漏掉一个，页面之间便会出现不同答案。公共判定减少了需要同步修改的位置，但每个入口是否正确使用结果，仍要靠代码检查和测试确认。
“设为共享”为什么曾让用户失去编辑权
同一时期，我们加过一条自助通道：团队成员可以把本团队资源设为账号级共享，不用找管理员。比如，支付团队写了一份适用于全公司的排障技能，维护者希望分享给所有团队，点一下就能搬过去。
问题出在搬完之后。账号级共享资源只有 owner 和管理员能编辑。如果操作的人是普通成员，资源一进入共享范围，他就不再有编辑权。想改回来也不行，因为从账号级搬走，首先得有权修改当前这份账号级资源。
于是，“分享给大家”实际变成了维护权移交。用户点按钮之前能改，点完之后不能改，也不能自行撤回。这是旧规则下的单向门，管理员仍可处理，但原维护者无法独立恢复。
已移除的通道：一次设为共享，同时改变了资源的维护权限。
我们随后把“设为共享”收为管理员专属。理由与创建规则一致：从头创建账号级资源需要管理员身份，把已有资源搬成账号级，也不能绕过同一道要求。
而且这不是说管理员能随便把任何团队的资源搬走。修改接口要先检查对当前资源的编辑权，再检查目标范围的资格。管理员要把支付团队的技能设为共享，仍需先具备支付团队资源的维护资格。
被废弃的豁免，不能只留一个永远为假的开关
收回管理员全量可见之后，代码里还留过一些残余分支。公共函数不再返回“管理员看全部”，但调用方仍接着那个开关，只是它永远为假，分支暂时进不去。
这些分支散落在列表过滤、集群 agent 和自动化规则等模块。如果以后有人只把公共函数的返回值改回真，几处全量可见的路径就会一起恢复。维护者可能只想修一个页面，结果同时改变了多个模块的权限。
因此，后续清理把开关、参数和对应分支整条移除。权限模型已经不再接受的豁免，不该通过一段旧代码继续存在。否则下次改动时，代码呈现出来的可能性，会比产品实际认可的规则更多。
同一个团队字段，也可能有不同含义
还有一个容易照搬出错的地方。对技能、知识包、连接器这些可定制资源来说，team_id=0 表示账号级共享；对用户生成的报告、页面等产物来说，零值表示个人归属。
因此，把一个产物转为个人归属，只允许创建者本人操作，不能直接套用“零值由管理员治理”。否则管理员就能把别人的产物搬成个人物品。产物在账号内如何打开、是否对外分享，又是另外的访问规则，不能只看归属字段下结论。
join-to-govern 解决的是团队资源由谁维护。它让管理员的治理动作也对应一份真实的团队关系，让创建、编辑和转移的规则能够相互解释。但它没有把同一账号里的各个团队变成互不信任的组织：团队会话仍允许账号内协作，成员也仍能转述自己已经看到的内容。
下一篇会继续讲这个限制。面对需要严格保密的资料，应该选择怎样的账号、执行环境和凭据安排，不能仅凭“团队隔离”四个字来决定。
这是 Flashduty AI SRE 技术揭秘 系列的第十四篇。我们在做一个专注 SRE 领域、帮你做故障根因分析的 AI Agent 产品，本系列会持续分享我们在 agent 工程上的真实设计、踩过的坑和做过的取舍。
常见问题
管理员为什么也要先加入团队？
管理员身份不自动代表某个团队的维护者。真实成员关系让团队归属约束实际修改行为，同时管理员仍可治理账号级共享资源。
普通成员还能把团队资源设为账号级共享吗？
本文描述的现行规则不允许。设为共享需要 owner 或管理员身份，且仍要先通过当前团队资源的编辑检查；旧自助通道会使普通成员失去编辑和移回权限，已被移除。
team_id 为 0，总是表示管理员治理吗？
不是。可定制资源的零值表示账号级共享，产物的零值表示个人归属；把产物转为个人归属只允许创建者本人操作。
