Kilo 企业级子组织（Sub-organizations）管理完全指南：多团队隔离、配额分发与权限治理-编程实验室

Kilo 企业级子组织（Sub-organizations）管理完全指南：多团队隔离、配额分发与权限治理

【免费下载链接】kilocodeKilo is the all-in-one agentic engineering platform. Build, ship, and iterate faster with the most popular open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kilocode

本指南以 Kilo 官方文档 sub-organizations.md 为骨架，系统讲解如何在 Kilo 企业组织中创建与治理直接子组织（direct sub-organizations）：从访问入口、创建流程，到人员（People）、用量（Usage）、额度（Credits）、资金分发（Distribute funds）、模型（Models）与权限（Permissions）六大管理板块的完整实操，并给出官方推荐的组织治理实践。读完本文，你将掌握如何在单个父组织下隔离团队/业务单元/成本中心，同时统一管理成员、额度与模型策略。

适用前提：子组织管理功能仅对企业版（Enterprise）组织开放，且要求存在父组织（parent organization）与直接子组织，普通团队版不可用。

子组织是什么：核心概念与适用场景

子组织（Sub-organization）是 Kilo 企业组织中用于隔离团队、业务单元或成本中心的组织形态。所有子组织都从同一个父组织（parent organization）下创建，并由父组织统一管理。

每个子组织独立保有以下资源与配置：

成员（members）：各子组织维护自己的成员名单，父组织成员不会自动成为子组织成员；
额度（credits）：拥有独立的余额、消费与有效期；
用量（usage）：独立统计请求数、Token 消耗与活跃用户；
策略（policies）：独立配置模型访问控制、SSO 等组织级策略。

层级结构的关键约束是：层级只有一级。父组织可以拥有多个直接子组织，但子组织不能再包含子组织（不允许嵌套），因此治理模型是扁平的"父 — 子"两级结构。

从设计意图上看，子组织解决的是"一个账号体系下的多成本中心治理"问题：不同团队共用父组织的管理视野，但彼此的成员、额度与策略互相独立，互不干扰。

访问子组织管理区域

进入子组织统一管理区域的步骤如下：

登录 Kilo Web App；
打开父组织（parent organization）；
在组织导航中选择Sub-organizations，或在组织概览页的 Sub-organizations 卡片上选择Manage Sub-Organizations。

访问权限有严格边界：只有父组织的Owner（所有者）、Admin（管理员）与 Billing Manager（计费管理员）可以打开这个统一管理区域。父组织的普通成员以及各子组织自己的 Owner不能借此查看其他子组织的内部信息——这保证了各子组织在运营层面的数据隔离。

下图为子组织管理概览页，集中展示了各直接子组织的成员、席位、余额与近期消费：

创建子组织

父组织的Owner 和 Admin可以创建直接子组织，具体步骤：

在父组织中打开Sub-organizations；
选择Overview标签页；
点击Create sub-organization；
输入组织名称（organization name）；
点击Create sub-organization确认创建。

新子组织以"空"状态启动：它不会自动复制父组织的成员、模型策略或组织设置。父组织的 Owner、Admin 和 Billing Manager 会自动获得继承式管理权限（inherited management access），但不会成为新子组织的成员，也不消耗子组织席位。

需要特别注意的是：Billing Manager 可以查看子组织并执行财务相关操作，但不能创建子组织——创建权仅限 Owner 与 Admin。

下图为创建子组织的对话框，只需填写组织名称即可完成创建：

使用六大管理板块

子组织管理区域将"报表查看"与"管理操作"拆分为六个聚焦的板块，职责互不重叠：

板块	展示内容
Overview（概览）	每个直接子组织的成员、席位、余额与近期消费
People（人员）	父组织及其子组织范围内每个身份一行记录，含父组织角色、已接受成员关系与待处理邀请
Usage（用量）	选定时间范围内的请求数、Token、成本与活跃用户
Credits（额度）	额度余额、已获取/已使用额度、有效期、自动充值状态、Kilo Pass 分配、近期消费与预估可运行时长（runway）
Distribute funds（资金分发）	将组织额度从父组织转移到一个或多个子组织
Models（模型）	跨组织对比已配置的模型、供应商、分组、自动路由与数据收集策略
Permissions（权限）	审查所有权、角色、SSO 策略、功能开关、每日消费上限与继承式父组织访问

其中People、Usage、Credits、Models、Permissions为只读的对比/审查视图，真正的变更操作（邀请成员、修改角色、调整模型策略等）需要到对应组织自己的设置页完成。

跨层级查找人员：People 板块

People板块将同一个人合并为一条记录，即使该人同时属于多个子组织，也不会出现重复行。这个视图用来回答"整个组织体系里到底有谁、处于什么状态"这一问题，主要能力包括：

按姓名或邮箱搜索；
按子组织、角色、成员状态或分配状态过滤；
按身份、父组织角色或子组织成员数量排序；
区分已接受的成员关系与待处理的邀请；
找出未分配给任何子组织的父组织成员。

需要强调的是，People 板块只反映当前成员状态。若要邀请新成员、修改角色或移除成员，必须打开对应组织的成员设置页进行操作。

下图为 People 板块的界面，提供了搜索、角色、状态、分配与组织等过滤条件：

审查用量与额度：Usage / Credits / Distribute funds

Usage（用量）用于在同一时间段内跨子组织对比活动量，可按模型或供应商过滤，并在成本、请求数、Token、活跃用户四种口径之间切换。适合回答"哪个团队消耗了最多的算力预算"。

Credits（额度）用于跨子组织对比财务状态，核心字段包括：

额度余额（credit balances）；
已获取与已使用额度（acquired and used credits）；
额度有效期（expirations）；
自动充值状态（auto top-up status）；
Kilo Pass 分配——代表组织共享的额度池容量（pooled credit capacity），而不是分配给个人的 Pass 数量；若未来的分配与当前分配不同，表格会单独显示过渡（transition）；
近期消费（recent spend）与预估可运行时长（runway）。

Distribute funds（资金分发）用于在需要时转移额度余额。此处要牢记一个重要区别：Kilo Pass 容量与额度余额是两个相互独立的量，必须分开管理——资金分发操作的是额度余额，不会改变 Kilo Pass 分配。

下图为 Credits 板块，对比了各子组织的余额、有效期、Kilo Pass 分配、消费与可运行时长：

对比模型与权限：Models / Permissions

Models（模型）板块并排比较父组织与每个子组织的模型配置。核心语义是：

父组织与子组织的策略相互独立：修改父组织的模型策略，不会改变或约束任何子组织的策略，也不会自动向下传递；
板块会区分"已配置的限制"与"被组织套餐实际执行的限制"——配置了但当前套餐不生效的限制会被明确标注；
修改模型策略需要进入对应组织自己的设置页（详见下方"模型访问控制"部分）。

下图为 Models 板块，逐组织对比已配置的模型与供应商策略：

Permissions（权限）板块用于三个典型的治理检查：

找出没有独立 Owner 的子组织——这是最常见的治理隐患；
审查各组织生效中的 SSO 策略；
查看哪些父组织用户拥有继承式访问权——注意，继承式访问不会在子组织创建成员关系，也不会消耗子组织席位。

与模型访问控制、Groups、SSO 的协同关系

子组织的 Models/Permissions 板块是"观察窗口"，真正的策略配置发生在各组织自身的设置中。理解下面三个邻近机制，才能把子组织治理做到位：

Model Access Controls（模型访问控制，仅企业版）：采用黑名单（blocklist）机制——默认放行一切，管理员显式屏蔽不可访问的模型或供应商。屏蔽某供应商会连带屏蔽其当前及未来的全部模型；只有Owner可以修改模型访问控制，且它是全组织范围的硬性上限（hard ceiling）。详见 model-access-controls.md。
Groups（成员组）：用于在不创建子组织的情况下为成员批量附加策略（如模型访问授权）。成员的有效权限 = 组织上限 ∩（默认策略 ∪ 组策略并集），组授予不能超出组织级模型访问控制的天花板。详见 groups.md。
SSO（单点登录）：企业版可通过 WorkOS 对接 Okta、Google Workspace、Azure AD 等身份提供商，支持域策略与用户自动开通（provisioning）；注意当前不支持 IdP 发起的登录，用户需从 Kilo Web App 登录。详见 sso.md。

在子组织场景下，这三者的正确组合是：父组织用模型访问控制设定全局天花板，各子组织在自身设置页独立配置策略（模型、SSO），再用 Groups 在子组织内部做细粒度分组授权。