从个人到团队：Kody 组织管理、权限授权与包共享完整指南

Kody 是面向个人和团队的 AI agent 云平台（"The cloud for your team's agents"），帮你的 agent 保存记忆、凭证、代码和自动化任务，并且可以在任意 agent 之间移植。当你从一个用户扩展到整个团队，绕不开三件事：组织管理（谁来管、怎么邀请）、权限授权（每个人能动什么）、包共享（如何把一个 package 安全地交给别人用）。这篇指南帮你一次讲清 Kody 组织管理、成员邀请、Grant 权限与包共享的完整玩法，让你几分钟内把团队的 agent 资产管起来。

本指南面向新手和普通用户，尽量少代码、多场景。涉及的官方文档路径都附在文末，方便深入。

一、先搞懂：Kody 里的"组织"是什么

在 Kody 中，组织（Organization，简称 org）是一切资源的归属地：package（包）、secret（密钥）、job（定时任务）、repository、agent 连接……全部归属于某一个 org。org 同时也是计费与数据的边界——它的用量、限额和账单都留在 org 内部。

每个登录用户天然拥有一个个人组织（注册时自动创建，slug 就是你的用户名）；你也可以再创建团队组织来邀请他人、划分小组。

对比项	个人组织	团队组织
创建方式	注册即有（slug = 用户名）	通过 orgCreate 或网页 Create organization
成员/小组	无，需建团队组织才能邀请	支持成员、团队（teams）
包授权	可用 grant / 邀请链接	同上，另有网页版 Grants 面板
资源页面	完整的 Secrets / Jobs / Repos 等页面	全部资源页面按 org 读取

几点值得记住：

• Handle 是永久的：@slug 不会改名，起名字前想清楚。
• org 可以切换：在工作区左上角的工作区名、头像菜单的 Manage 组，或在 MCP 授权页选择。个人组织概览路径是 /@<slug>/-/overview，团队组织是 /@<slug>。
• 一条连接绑定一个 org：同一个 MCP 客户端想连两个 org，需要在授权 URL 上加 ?org=<slug> 各连一次（CLI 用 kody login --org <slug>）。

二、把队友请进来：邀请与邀请链接

团队组织有两类"进门方式"，都记录在 org 的审计日志里。

2.1 定向邀请：指名道姓

给具体的人发邀请（按邮箱或用户名）。被邀请的人会在两处看到待处理卡片，可 Accept 或 Decline：

• 个人 Waiting 页面（/@<org>/-/waiting）；
• 个人 Organizations 页面的 Invites 面板（/account/organizations）。

你发出的邀请也会列在发送页（Members 显示 Pending、可 Revoke）。注意：发到邮箱的邀请，对方需要先完成邮箱验证才能在网页上处理。

2.2 邀请链接：不知道对方邮箱/用户名时

链接邀请是新手最友好的方式——在"本来要添加人的地方"生成一个链接即可：

生成位置	对方接受后	谁能生成
Members（团队 org）	以 Member 或 Billing 身份加入 org	member:write
Teams 某个团队	加入该团队（若不在 org 中则同时以 Member 身份入 org）	team:write + member:write
某个包的 Collaborators 标签页	仅获得该包上选定的 preset（非成员仍是外部协作者）	对该包有 Manage 权限

链接的安全设计很省心：

• 默认有效期 7 天（最长 365 天），可限制使用次数；Members 链接还可要求已验证邮箱域名。
• Kody 只保存哈希，链接完整内容只显示一次。
• 对方点开不会立即生效——必须点 Accept；拒绝即终止（记为 invite.declined）。
• org 停用、目标团队/包被删、或生成者失去权限时，链接自动失效。
• 团队和包链接"每人一次"：把某人移出 org 后，他不能再用已用过的同一条链接回归。

三、权限授权：三种身份 + 三档 Grant

这是 Kody 组织管理的核心心智模型，理解它，后面所有共享都通了。

3.1 org 内三种身份

身份	能力
Owner	拥有 org 内一切权限
Member	org 基础权限（org:read、member:read、team:read、search:read）+ 被授予的 grant
外部协作者	不在 org 内，仅有目录搜索（search:read）+ 被授予的 grant

权限词法都是 resource-type:action 的形式，例如 package:read、package:execute、org:execute。你不需要背全部清单，知道"每个操作都对应一个可授予的权限"即可。

3.2 包上的三档 Grant 预设

对一个 package，grant 就是"给某个人或某个团队一档预设权限"：

预设	在这个包上意味着
Use	能读源码 + 能运行（package:read、package:execute）
Contribute	Use 全部 + 能写（package:write）
Manage	Contribute 全部 + 能发布、删除、管理该包的访问

高级玩法可以用显式权限列表代替预设。任何预设都不包含 billing:*，也不会泄露 secret 的值——这是硬边界。

3.3 授权/回收的常用入口

• 给已有人授权：accessGrant（需要对该包有 Manage），accessList 查看全 org 的授权，accessRevoke 按 grant_id 回收；再次对同一人 accessGrant 即可改档。
• 包的协作者管理：packageCollaboratorList / packageCollaboratorSet / packageCollaboratorRemove，覆盖团队与 org 成员；网页上就是包页面（/@owner/<package>/collaborators）的 Collaborators 标签页。
• 给还没权限/还没账号的人：inviteCreate（kind: "grant"）发定向邀请，或从 Collaborators 标签页 Share with a link 生成链接（可选 preset、使用次数、天数，默认 7 天）。
• 邀请整个 org 成员：inviteCreate（kind: "membership"）——注意个人组织不支持成员邀请，想组队就先建团队 org。

四、包共享实战：外部协作者到底能干什么

这是新手最容易踩坑的地方，值得展开。

假设 Jesse 对你们 org 的 @acme/bot 只有 Use，且他不是成员——他就是一名外部协作者。他必须在授权（consent）时选中你的 org 连接，然后可以：

• 读取并运行他持 Use 的包；
• 运行能 import 这些包的临时代码（execute）；
• 搜索共享目录。

他不能看到你 org 里的其他东西，不能看到任何 secret 值，也不能改包（除非 grant 明确给了写权限）。

4.1 账单算谁的？

org 是计费边界。Jesse 以拥有方 org 身份连接，他每次运行消耗的积分、预算、出站抓取、execute 限额，全部计在你们 org 头上，与他个人套餐无关。而且他只算"使用者"，不占你们 org 的付费席位，也不会让 execute 池变大。

execute 限额是org 级一个池子：Free 计划每 org 每日 150 / 每周 400 个独立 worker；Pro 计划随付费席位（Owner + Member）增长。

4.2 密钥与集成：Use 包 ≠ 能用密钥

每一次运行都"以某个人"的身份执行，凭证只有当这个人持有该凭证的 Use 时才会解析。所以：

• 密钥值、集成 token 来自你们 org；Jesse 从 Use 包授权中不会自动获得 secret:read；
• 包用到的每个 secret / 集成，都需要对 Jesse 单独授予 secret:use / integration:use（对凭证本身 accessGrant），并且包的允许列表（host allowlist / allowed_packages）也要放行；
• 凭证改名后 grant 自动跟随，凭证被删则 grant 自动失效。

4.3 共享包里的定时任务：谁开启，就以谁的身份跑

Kody 有一条很稳的规则：自动化（job / 订阅 / webhook）只为你自己开启的那份开关运行，且运行时只拥有开启者当下的实时权限：

• 运行只做开启者"此刻手动能做的"事，绝不会更多；
• 开启者失去权限（离开 org、失去 package:execute、失去某凭证 Use）时，任务自动暂停，权限恢复后自动继续，永远不降级为以别人或 Owner 身份运行；
• 用量计入触发器所属的 org，审计记到开启者头上；
• 角色/成员变更、账单变更等高危操作必须真人在场，自动化一律会收到 Capability "<name>" needs a live person 的报错。

举例：Bea 是 @acme 的 Member 且对 @acme/digest 有 Use，她开启了它的夜间 job。此后每晚以 Bea 的身份和 grant 运行——她读不了没有 Use 的 secret，即使她后来升为 Owner 也不能借 job 改角色。若 Owner 把 Bea 移出 org，job 暂停，直到别人为自己重新开启。

五、Fork 还是 Grant？一张表帮你选

社区目录（Community catalog）里的公共包不在普通 search 结果里，要用 communitySearch 找。面对别人的成果，两种取法：

场景	选择	结果
对方应该拥有并修改自己的副本	Fork	复制进你的 org（communityFork 或网页一键安装），你完全拥有它，可改可再发布
对方应该运行你那份线上包	Grant（Use/Contribute/Manage）	包留在你的 org，对方连接你的 org 来读取与运行

Fork 的几个要点：

• Fork 得到的是惰性副本：不发布就不运行；一键安装若发布检查通过会立即激活；
• 跨 org 的 import 永远不可解析——A org 的包不能 import B org 的包，即便有 grant。想复用别 org 的公共包，就 fork 一份再 import；
• Fork 后记得做安全审查（社区内容视为不可信）、改写 ## Intent、处理跨 scope 引用，然后 repoPublishSession 发布。

决策口诀：共享我的活包 → Grant；各玩各的副本 → Fork；跨 org 依赖 → Fork 后再用。

六、免费团队组织的限额与付费席位

新团队组织和个人组织一样，从 Free 计划起步（没有单独的"免费团队版"）。免费档关键数字：

限额	Free
你可拥有的免费 org（含个人）	2 个（即 1 个免费团队 org + 个人）
席位	Free 不收费；Pro 席位仅 Owner + Member，$12/席/月 或 $120/席/年
保存的包 / 仓库	10 / 20
定时 job	5 个（最快间隔 15 分钟）
Execute（独立 worker）日/周	150 / 400
出站抓取 日/周	1,000 / 2,500
Job 运行 / 日	500
Secrets / 存储	25 / 16 MiB

升级到 Pro 后，每个在线 Owner 和 Member 都是一个席位，并且每增一席，org 的 execute 池就变大；Billing-only 成员与外部协作者不占席。

七、常见疑问速查

• "为什么我邀请的人什么都看不到？" 他必须在 consent 时选中你的 org；外部协作者只能看到被 grant 的资源 + 目录搜索。
• "我给他 Use 了包，他还能看到我的密钥吗？" 不能。Use 不含 secret:read；要用密钥需对凭证单独授 secret:use 且包允许列表放行。
• "链接邀请了 3 个人，能撤回吗？" 可以。每个页面都列出活跃链接（用量 + 到期时间），点 Revoke 立即失效；链接只对未使用过的人有效。
• "我把人移除了，他之前用过的链接还能回来吗？" 团队/包链接是每人一次，不能。发新链接即可。
• "定时任务能改成员角色吗？" 不能。角色与账单变更要求真人操作，否则报错 needs a live person。
• "同一个客户端能连两个 org 吗？" 能。MCP URL 各加一次 ?org=<slug>，CLI 用 kody login --org <slug>。

八、延伸阅读与文档路径

以下文档覆盖了本指南的全部细节，建议按需深入：

• 组织与席位：docs/guides/organizations.md
• 包共享与访问管理：docs/guides/package-sharing.md
• 包生命周期（复用 / execute / Fork / 创建）：docs/guides/package-lifecycle.md
• 社区公共包与 Fork 细节：docs/use/community-packages.md
• 权限体系架构（面向开发者）：docs/contributing/architecture/authorization.md
• 计划与配额模型：docs/contributing/architecture/entitlements.md
• Kody 是什么：docs/guides/what-is-kody.md

一句话总结：在 Kody 里，org 是边界，grant 是阀门，Fork 是复制，邀请是入口。把"谁能进 org、能用什么档的 grant、任务以谁的身份跑"这三件事想清楚，你的团队 agent 资产就从"个人小作坊"升级成了"可审计、可计费、可协作"的团队云。