组织与团队

一个组织就是一个项目，其 kind = "org"。这一个想法就免费带来了嵌套结构：一个组织可以容纳子项目（一个团队、一个客户、一个试点），每一个都有自己的智能体、设备、文件和积分，角色沿着树向下流动。成员身份是继承的——把一个人加入组织一次，他们就会以对应的角色出现在它的所有项目中。

# Create an org (it's a project with kind=org) and add a teammate.
curl https://api.commandagi.com/orgs \
  -H "Authorization: Bearer $COMMANDAGI_API_KEY" \
  -d '{ "name": "Acme Robotics" }'
# → { "org": { "id": "org_…", "kind": "org" } }

curl https://api.commandagi.com/orgs/org_.../members \
  -H "Authorization: Bearer $COMMANDAGI_API_KEY" \
  -d '{ "email": "teammate@acme.com", "role": "member" }'

四种角色，从权限最低到最高，每次请求都会核验：

• viewer（查看者）——观看会话、读取共享资源。
• member（成员）——运行智能体、启动机器、创建和编辑资源。
• admin（管理员）——管理成员、项目和设置。
• owner（所有者）——完全控制，包括账单和删除。

设置在一个容器上的角色会应用到其下的一切，所以你可以在与工作相匹配的层级上授予访问权限，而不必逐个资源去做。

子项目让工作——以及支出——保持有序。积分和按项目的并发上限都被限定在一个项目内，所以一个试点无法超支预算，一个共享工作区也能保持可预测（参见账单与配额）。在任意父级下创建一个：

# A nested project inherits the org's members and roles.
curl https://api.commandagi.com/projects \
  -H "Authorization: Bearer $COMMANDAGI_API_KEY" \
  -d '{ "name": "Warehouse pilot", "parentId": "org_..." }'

一个服务账户是一个项目拥有的主体，有自己的 API 密钥。用它来做共享、可审计的自动化，而不是用个人密钥：它有自己的权限范围，它执行的每一个操作都会被记录（谁、做了什么、针对哪个资源、是否被允许），撤销它也不会影响任何人的个人访问权限。参见身份验证。

一个组织可以配置它所管理的成员账户（POST /orgs/:id/users）——用于一支收益结算给组织实体的用工队伍——并开放一个注册通道，让人们以供给方的身份加入。这就是一家企业如何把自己的一支人员与机器车队，作为定位容量运营；面向人员一侧的流程是上线赚钱。

一个组织带有一份章程——一种实体类型，决定它在多大程度上可以被信任承担债务。两个独立的选择，在设置 → 账单中设定：

• 责任——无限（义务可以追及成员，所以组织的信任额度包含其成员自身可追偿的余额——追索权已被计入价格）或有限（义务被限定在组织自己的资金池内，所以它必须缴纳一份资本充足保证金——至少是任何义务的 20%——以换取这层保护）。
• 资金池——单一（一个资金账户，由所有者自行决定支出）或共享，在共享模式下，支出需要通过一次M-of-N 管理者审批：所有者指定管理者与阈值，任何成员都可以提出一笔支出（如果超出信任额度会被直接拒绝），管理者投票，一份获批的提案由所有者或管理员执行。这相当于你积分余额的一个多签方案。

信任额度是该组织能够可信地承担的最大义务；它会随着资金池、成员背书和保证金的变化而实时更新。第一方主体拥有完全的信用背书，不参与评分。