Skip to content

F5 · 用户如何组织和管理工作空间与项目? - Workspace & Project Management ​

所属知识库:Agent 全栈技术地图
所属领域:04 · Agent Platform
所属章节:03 · Agent Platform 应该提供哪些产品功能? - Product Architecture
文档类型:专题研究 / 产品架构 / 交互与工程参考设计
版本:v1.3
更新日期:2026 年 11 月 1 日
核心问题:Agent Platform 如何帮助用户以工作空间和项目为单位组织成员、Agent、Workflow、Run、资源与产物,同时实现明确的归属、权限、协作、生命周期和跨项目复用?

专题导读 ​

本篇属 Product Architecture。F1 - F2 - F3 - F4 分别解决 Agent 的创建、配置、开发测试及发布共享;F5 研究这些能力在哪里被组织、由谁共同使用、以什么边界归属和治理。工作空间与项目不是单纯的文件夹:它们连接用户协作、运行资源、权限边界、成本归因与成果交付。本文从产品架构出发讨论用户任务与交互,并将技术实现映射到 P1、P3、P6、P10 - P11 - P12。F5 不取代 P11 多租户隔离的底层安全设计,也不取代 F12 的全平台管理。

本文提出的页面、对象模型、API、SQL、指标和测试矩阵属于参考设计,不是已部署或经过用户验证的事实。不同产品可以采用不同组织层级,不存在适用于所有 Agent Platform 的唯一工作空间模型。

研究结论 ​

  1. Tenant、Organization、Workspace、Project 是四个不同概念:租户定义主要安全和计量边界;组织表达成员与治理关系;工作空间是共享资源与协作的主要产品容器;项目围绕具体目标、执行和交付组织工作。实际层级应由产品策略确定,不必机械要求四层都存在。
  2. 对 Studio 初期,推荐用户直接感知 Workspace → Project 两层;租户与组织可在后台实现,不应在创建第一个研究项目时增加不必要步骤。
  3. 资源需要明确的归属(ownership)、可见性(visibility)、使用授权(permission)与引用关系(reference)。将 Agent 关联到项目不必转移其归属。
  4. 工作空间成员权限与项目成员权限应分开建模;Agent 的执行权限仍须在运行时检查资源连接、工具作用域和治理策略。
  5. 项目应统一呈现 Agent、Workflow、Run、Artifact、成员、活动和设置,并提供从研究目标到最终交付的可追溯路径。
  6. 邀请、移交、归档、复制、删除和跨工作空间共享具有不同风险;特别是删除项目不应默默删除被其他项目引用的共享 Agent 或历史审计记录。
  7. 早期 MVP 优先实现工作空间创建、项目创建、成员角色、资源关联、项目工作台、归档恢复和基础审计;复杂组织树、计费与跨租户共享可以后置。

01 · 概念、边界与术语 ​

1.1 四类容器与作用 ​

概念主要回答的问题典型对象产品可见性
Tenant 租户数据与计算属于哪个安全边界?安全上下文、配额、账单归属可隐藏或仅管理员可见
Organization 组织谁共同管理成员和政策?团队、成员关系、组织策略团队版可见
Workspace 工作空间哪些人共享一组 Agent、资源和项目?成员、Agent 库、资源连接、项目列表核心导航容器
Project 项目为了什么目标协作和交付?Workflow、Run、任务、报告、产物核心业务容器

逻辑边界与产品层级必须分开。 一个 Tenant 可以对应一个 Organization,也可以服务多个组织;一个 Workspace 可容纳多个 Project。初期产品可以让个人工作空间隐式创建,避免强迫单人用户理解“租户”。

1.2 F5 与相邻专题的职责 ​

相邻专题负责什么F5 负责什么
F1 - F2 - F3 - F4 Agent 生命周期创建、配置、测试、发布与共享 Agent在工作空间/项目中发现、组织和关联 Agent
F6 Agent Execution启动、暂停、取消具体运行提供项目级任务入口与运行列表
F7 Agent Collaboration多 Agent 协同交互配置项目的参与 Agent、协作者和协作范围
F8 Agent Monitoring查看 Trace、运行状态与质量提供项目级聚合视图和导航
F10 Artifact Management产物版本、审核与交付项目内产物入口、分类和归属
P11 Multi-tenancy底层隔离与跨租户边界用户可理解的成员、空间和项目操作
P12 Governance权限、预算、审批策略的执行权限设置入口、角色反馈与管理流程

1.3 不应混淆的关系 ​

“位于某个项目”“被某项目引用”“由某项目创建”“由某项目拥有”并非同义。比如工作空间拥有的调研 Agent 被三个项目引用;其中一个项目归档,不应影响另两个项目继续运行。数据库模型应使用独立的关联表表示使用关系,而不是只靠 project_id 表示全部语义。

02 · 用户、角色与关键任务 ​

2.1 用户角色 ​

用户核心目标典型痛点必要能力
个人创作者快速启动项目并积累资产创建前配置过多默认个人工作空间、模板项目
项目负责人组织任务、人员与交付进度与成果分散项目概览、成员、状态、里程碑
Agent 构建者跨项目复用 Agent复制后版本漂移受管引用、版本固定、更新提示
研究成员查看资料、执行工作、提交审核权限和入口不清角色明确、任务列表、活动记录
工作空间管理员控制成员、资源、成本资源泄露和超额使用邀请审批、授权、配额和审计
外部审阅者有限范围查看成果不应看到内部 Prompt/凭证受限审阅链接、独立授权

2.2 用户任务清单 ​

用户应能完成:创建或加入工作空间;创建项目并填写目标;邀请成员和设置角色;选择已有 Agent/Workflow 或从模板开始;连接工作空间资源;启动研究任务;查看任务与产物;管理项目活动和状态;归档、复制或移交项目;在权限允许时跨项目复用资产。管理员还需要识别资源所有者、访问历史、成本和待处理邀请。

2.3 三条核心旅程 ​

个人首次使用: 注册 → 自动进入个人 Workspace → 选择“创建研究项目” → 填写项目目标 → 使用默认研究工作流 → 启动第一轮任务 → 查看产物。首次成功不应依赖创建组织、分配管理员或理解租户术语。

团队协作: 管理员创建 Workspace → 邀请成员 → 创建项目 → 指定负责人 → 关联共享 Agent 与资源 → 设置项目权限 → 启动工作流 → 人工审核 → 交付报告。

跨项目复用: 在项目 A 发布 Agent → 将 Agent 共享至 Workspace → 项目 B 建立受管引用 → 绑定项目 B 的知识和凭证 → 运行时固定版本 → 后续收到上游更新提示。

03 · 产品功能架构与信息架构 ​

3.1 功能模块 ​

模块核心功能最小版本
Workspace Home工作空间切换、概览、最近项目必须
Workspace Members邀请、角色、成员移除必须
Workspace LibraryAgent、Workflow、资源目录必须
Workspace Settings名称、默认权限、基础配额必须
Project Directory项目创建、搜索、筛选、归档必须
Project Overview目标、负责人、状态、最近运行、产物必须
Project ResourcesAgent/Workflow/知识/工具关联必须
Project Runs执行记录、状态、入口必须
Project Artifacts成果、版本、审核、导出入口必须
Project Members项目协作者、权限建议首期
Project Activity关键变更与审计入口建议首期
Project Templates项目模板、复制与初始化第二阶段
Cross-workspace Sharing受控共享、授权撤销后期

3.2 推荐导航 ​

text
Workspace Switcher
├── Overview
├── Projects
│   └── Project Detail
│       ├── Overview
│       ├── Workflow
│       ├── Runs
│       ├── Agents & Resources
│       ├── Artifacts
│       ├── Members & Activity
│       └── Settings
├── Agents
├── Workflows
├── Resources
├── Members
└── Settings

导航原则: 工作空间负责“可复用能力”,项目负责“具体业务成果”;项目页面可以提供关联资产的快捷入口,但不必复制其完整管理页面。页面内始终显示当前工作空间和项目上下文,降低误操作风险。

3.3 项目首页应回答什么 ​

项目首页优先回答六个问题:这是一个什么项目?当前处于什么阶段?下一步由谁行动?哪些 Agent/Workflow 参与?最近发生了什么?最终成果在哪里?建议将项目目标、工作流状态、待审核事项、最新产物和活动时间线置于首屏,而非以资源卡片数量衡量完成度。

04 · 对象模型、关系与身份 ​

4.1 核心对象 ​

对象关键字段不变量
Workspaceid, tenant_id, name, status, owner_id所属租户不可凭客户端参数任意修改
WorkspaceMembershipworkspace_id, user_id, role, status同一成员关系唯一且可审计
Projectid, workspace_id, name, status, owner_id始终属于明确的 Workspace
ProjectMembershipproject_id, user_id, role不可越过工作空间或显式访客授权边界
ProjectAssetLinkproject_id, asset_type, asset_id, version_policy引用不改变资产原有归属
ProjectRunLinkproject_id, workflow_run_id运行关联须经对象级授权
ProjectActivityproject_id, actor, action, target, timestamp关键管理行为保留审计依据
Invitationworkspace_id, email/identity, role, expiry, status邀请一次性、可撤销、有期限
ProjectTemplatetemplate_id, version, manifest模板引用与实例分离

4.2 对象关系 ​

mermaid
erDiagram
    TENANT ||--o{ WORKSPACE : contains
    WORKSPACE ||--o{ PROJECT : contains
    WORKSPACE ||--o{ WORKSPACE_MEMBERSHIP : has
    USER ||--o{ WORKSPACE_MEMBERSHIP : joins
    PROJECT ||--o{ PROJECT_MEMBERSHIP : has
    USER ||--o{ PROJECT_MEMBERSHIP : joins
    PROJECT ||--o{ PROJECT_ASSET_LINK : references
    AGENT_VERSION ||--o{ PROJECT_ASSET_LINK : referenced_by
    WORKFLOW_VERSION ||--o{ PROJECT_ASSET_LINK : referenced_by
    PROJECT ||--o{ WORKFLOW_RUN : initiates
    WORKFLOW_RUN ||--o{ ARTIFACT : produces
    PROJECT ||--o{ PROJECT_ACTIVITY : records

此图为逻辑关系示意;由于 ProjectAssetLink 可以引用多种资产类型,生产实现可以选择多张强类型关联表,避免无法由数据库外键保证的多态引用。

4.3 身份与版本语义 ​

Workspace 和 Project 使用稳定不可重用 ID;可编辑名称与 URL slug 不应作为授权依据。Agent 与 Workflow 的“版本”由 Registry 管理,项目关联应存储固定版本或明确的版本解析策略。Run 创建时必须把可变别名解析为实际不可变版本并持久化,保证历史可追溯。

05 · Workspace 生命周期与交互 ​

5.1 创建工作空间 ​

创建向导建议仅要求名称、可选描述;系统从当前身份确定租户与创建者。默认创建者获得 Owner 角色,但必须防止最后一名 Owner 意外退出。可选项如地区、计费计划、组织域名、数据驻留策略应在实际需求出现时提供。

5.2 工作空间状态 ​

mermaid
stateDiagram-v2
    [*] --> Active: 创建成功
    Active --> Suspended: 管理停用或治理冻结
    Suspended --> Active: 复核恢复
    Active --> Closing: 请求关闭
    Suspended --> Closing: 请求关闭
    Closing --> Archived: 保留期/归档完成
    Archived --> [*]: 合规删除完成

关闭工作空间前需提示受影响的项目、成员、运行、共享授权、外部连接和未交付产物。停用应阻止新执行,但在途运行是立即取消还是允许完成,需要单独的治理策略。

5.3 成员邀请 ​

推荐流程:管理员选择角色 → 输入身份 → 系统校验邀请权限和席位限制 → 创建短期邀请 → 受邀者验证身份 → 明示将加入的工作空间和权限 → 接受 → 写入成员关系与审计事件。邀请链接不得直接充当长期访问凭证;加入后依赖正常认证与授权。

06 · Project 生命周期与交互 ​

6.1 创建项目 ​

建议三步:①输入名称、目标与说明;②选择空白项目或项目模板;③确认工作空间、成员与初始资源。创建项目成功的最小标准是项目对象持久化且可重新打开;模板初始化、知识导入、Agent 配置可以作为异步后续步骤。

6.2 项目状态 ​

状态含义允许的典型操作
Draft项目建立但尚未正式启动编辑目标、配置资源、邀请成员
Active正在开展工作创建 Run、提交审核、管理产物
Paused暂停新工作查看、整理、恢复;在途 Run 按独立策略处理
Completed业务目标已完成查看、交付、归档;重启需显式操作
Archived不再活跃,保留历史只读、按权限恢复或导出
Deletion Pending删除待处理阻止新增任务,执行保留与依赖检查

“Completed”属于业务状态,“Workflow Run Succeeded”属于执行状态,两者不能相互替代。一个项目可以有多次 Run,也可能某次 Run 成功但报告审核未通过。

6.3 归档、复制、移交、删除 ​

归档应保留可追溯性并停止默认新运行;复制项目应复制项目结构和允许复制的配置,不应复制密钥、隐私数据或未经授权的共享资产;移交需验证接收者权限并保留记录;删除须先检查保留期、法律保全、外部引用、共享资产和运行状态。对于高风险删除,应展示明确影响预览与二次确认。

07 · 角色、权限与协作 ​

7.1 参考角色矩阵 ​

操作Workspace OwnerWorkspace AdminProject OwnerProject EditorProject Viewer
修改工作空间设置✓✓(受限)---
邀请工作空间成员✓✓---
创建项目✓✓按策略按策略-
修改项目目标✓✓✓✓-
关联 Agent/Workflow✓✓✓✓(按授权)-
启动项目 Run✓✓✓按策略-
查看项目产物✓✓✓✓按资产权限
删除项目✓按策略按策略--
管理项目成员✓✓✓--

矩阵仅是产品默认建议,不是实现层的最终授权规则。实际应综合租户边界、工作空间成员关系、项目角色、资源 ACL、工具作用域与治理策略计算。管理员角色也不意味着可以直接读取所有敏感密钥或私有数据。

7.2 权限继承与覆盖 ​

推荐采用“显式授权 + 有界继承”:工作空间授予基础访问资格,项目进一步限定具体操作;资产级权限可继续收紧。若支持外部审阅者,应使用独立的受限授权而非隐式加入整个工作空间。冲突策略必须可预测,例如明确拒绝优先于一般允许;不可仅通过隐藏 UI 按钮实现安全。

7.3 协作体验 ​

项目页面需要清楚呈现负责人、成员、待办与审核者;重要修改显示操作者和时间。多人编辑项目说明或 Agent 草稿时,应采用乐观并发控制、冲突提示和修订历史。评论与任务指派可以后置,但审核动作必须有可追踪的执行身份。

08 · Agent、Workflow 与资源的项目级组织 ​

8.1 资源归属与关联策略 ​

建议将 Agent 和 Workflow 作为工作空间级可复用资产;项目通过 ProjectAssetLink 关联。项目专属的临时草稿可归属项目,但发布为共享能力时须经过显式迁移或发布流程。模型连接、工具凭证、知识库授权应独立管理,不随项目引用自动复制。

8.2 版本策略 ​

策略含义适用情况风险
Pinned固定指定 Agent/Workflow Version审核严格、长期研究需主动升级
Channel-bound引用稳定渠道,新 Run 解析版本快速迭代不同 Run 可能使用不同版本
Forked派生独立副本大幅定制上游修复不能自动同步

项目详情应显示实际关联版本和更新可用状态。历史 Run 永远保留执行时解析的版本;切换渠道不重写历史。

8.3 资源绑定检查 ​

项目绑定共享 Agent 时,系统至少检查:目标项目是否可见 Agent、是否有使用许可、依赖工具是否可用、连接凭证是否属于允许范围、知识库是否允许该项目访问、预算是否足够、工作流版本是否兼容。绑定成功也不代表运行时授权可以跳过。

09 · 项目级运行、审核与产物 ​

9.1 运行视图 ​

项目 Runs 页面应聚合 Workflow Run、Agent Run、状态、发起人、开始时间、耗时、成本、当前节点、失败原因和产物入口。每条 Run 应能跳转到 F8 的详细 Trace。项目聚合视图不应伪装成底层监控系统。

9.2 审核与待办 ​

待审核事项应显示对象、提交者、审阅者、截止时间、输入摘要、产物版本和允许操作。审核决定必须绑定具体版本或内容摘要,避免审批后内容变化却继续沿用旧批准结果。对于已过期或被撤销的审批应阻止执行。

9.3 产物组织 ​

项目 Artifacts 页面可按“草稿、审核中、已批准、已交付”筛选,展示来源 Run、版本、责任人、更新时间与下载权限。项目目录中的文件展示是资产索引,不等于文件的物理所有权或完整存储路径。 真实内容与权限由 P10 资产服务管理。

10 · Studio 贯穿案例:多 Agent 研究报告项目 ​

10.1 场景 ​

一个 Workspace 名为“研究工作室”,其中有三个 Project:“Agent 技术地图”“设计知识库”“文创产业报告”。工作空间共享选题 Agent、调研 Agent、分析 Agent 和审核 Agent,但各项目使用不同知识库、报告模板和审批人。

10.2 用户操作流程 ​

  1. Workspace Owner 创建“研究工作室”,邀请研究成员与审阅者。
  2. Project Owner 创建“Agent 技术地图”项目,填写研究目标、交付标准和负责人。
  3. 在项目的 Agents & Resources 页面关联四个已发布 Agent,并选择固定版本。
  4. 关联工作空间内可访问的检索服务与项目专属文献库;验证资源授权。
  5. 选择“研究报告工作流”版本,设定预算与审核节点。
  6. 启动 Workflow Run,项目首页显示进度、待审核节点和最新产物。
  7. 审阅者对具体报告草稿版本提交“通过/退回”,系统记录审核意见。
  8. 产物通过后发布为项目报告,导出 Markdown;必要时将正式报告共享到工作空间知识资产库。
  9. 项目结束后设为 Completed,归档时保留 Run、引用与审核记录。

10.3 用户界面示意 ​

text
研究工作室 / Agent 技术地图
┌─────────────────────────────────────────────────────────────┐
│ 项目目标:构建 Agent 技术研究体系   状态:Active   负责人:… │
├─────────────────────────────────────────────────────────────┤
│ 当前工作流:研究报告 v1.2   运行中:1   待审核:2           │
│ 选题 → 调研 → 分析 → 审核 → 交付                            │
├─────────────────────────────────────────────────────────────┤
│ Agents: 选题 v2 / 调研 v3 / 分析 v1 / 审核 v2               │
│ Resources: 文献库 / 搜索连接 / 报告模板                      │
├─────────────────────────────────────────────────────────────┤
│ 最新产物:E4 技术专题草稿 v3    最近活动:审核意见已提交     │
└─────────────────────────────────────────────────────────────┘

10.4 典型异常 ​

项目 B 引用的共享 Agent 被撤销授权时,平台应禁止新运行并提示管理员修复,不应悄悄切换到另一个 Agent。项目归档时若仍有运行中的任务,应要求选择“等待完成、取消或暂缓归档”,并展示外部副作用风险。成员退出工作空间后,其历史审核记录仍应保留不可伪造的身份快照,具体个人信息保留需遵循适用政策。

11 · 技术映射与参考系统架构 ​

mermaid
flowchart TB
    UI[Workspace & Project UI]
    API[Workspace / Project API]
    AUTH[Identity & Authorization]
    DB[(PostgreSQL)]
    REG[Agent / Workflow Registry]
    RES[Resource Gateway]
    CP[Control Plane]
    EXEC[Execution Plane]
    ASSET[Asset Service]
    AUDIT[Audit & Events]
    UI --> API
    API --> AUTH
    API --> DB
    API --> REG
    API --> RES
    API --> CP
    CP --> EXEC
    EXEC --> ASSET
    API --> AUDIT
    CP --> AUDIT

对于 Studio 的早期规模,Workspace/Project 服务可作为模块化单体中的独立业务模块,不必立即拆为微服务。数据库事务负责项目创建与成员关系等核心一致性;跨 Registry、执行和资产服务的操作通过明确的异步事件、补偿或重试处理,不能假设跨服务事务天然存在。

12 · 数据模型与约束示例 ​

以下 PostgreSQL DDL 仅用于说明关键约束,省略身份服务、完整 RLS 策略、迁移及索引调优。

sql
CREATE TABLE workspaces (
  id uuid PRIMARY KEY,
  tenant_id uuid NOT NULL,
  name text NOT NULL,
  status text NOT NULL CHECK (status IN ('active','suspended','closing','archived')),
  owner_user_id uuid NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now(),
  UNIQUE (tenant_id, id)
);

CREATE TABLE workspace_memberships (
  tenant_id uuid NOT NULL,
  workspace_id uuid NOT NULL,
  user_id uuid NOT NULL,
  role text NOT NULL CHECK (role IN ('owner','admin','member','viewer')),
  status text NOT NULL CHECK (status IN ('active','invited','suspended')),
  PRIMARY KEY (workspace_id, user_id),
  FOREIGN KEY (tenant_id, workspace_id) REFERENCES workspaces(tenant_id, id)
);

CREATE TABLE projects (
  id uuid PRIMARY KEY,
  tenant_id uuid NOT NULL,
  workspace_id uuid NOT NULL,
  name text NOT NULL,
  description text,
  status text NOT NULL CHECK (status IN
    ('draft','active','paused','completed','archived','deletion_pending')),
  owner_user_id uuid NOT NULL,
  revision bigint NOT NULL DEFAULT 1,
  created_at timestamptz NOT NULL DEFAULT now(),
  updated_at timestamptz NOT NULL DEFAULT now(),
  UNIQUE (tenant_id, workspace_id, id),
  FOREIGN KEY (tenant_id, workspace_id) REFERENCES workspaces(tenant_id, id)
);

CREATE TABLE project_memberships (
  tenant_id uuid NOT NULL,
  workspace_id uuid NOT NULL,
  project_id uuid NOT NULL,
  user_id uuid NOT NULL,
  role text NOT NULL CHECK (role IN ('owner','editor','viewer')),
  PRIMARY KEY (project_id, user_id),
  FOREIGN KEY (tenant_id, workspace_id, project_id)
    REFERENCES projects(tenant_id, workspace_id, id)
);

CREATE TABLE project_agent_links (
  tenant_id uuid NOT NULL,
  workspace_id uuid NOT NULL,
  project_id uuid NOT NULL,
  agent_id uuid NOT NULL,
  pinned_version_id uuid,
  release_channel text,
  created_at timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (project_id, agent_id),
  FOREIGN KEY (tenant_id, workspace_id, project_id)
    REFERENCES projects(tenant_id, workspace_id, id),
  CHECK ((pinned_version_id IS NOT NULL) <> (release_channel IS NOT NULL))
);

CREATE INDEX idx_projects_workspace_status ON projects(workspace_id, status, updated_at DESC);

project_agent_links 还需要应用层或跨库校验 Agent Registry 的实际归属、版本存在性与授权。若 Registry 位于同一数据库,可进一步添加强外键。所有表的跨租户隔离需使用数据库 RLS、受控连接身份和应用层对象授权共同保障;上面的复合外键只是防线之一。

13 · API 与交互契约 ​

13.1 推荐接口 ​

方法路径语义
POST/v1/workspaces创建工作空间
GET/v1/workspaces列出当前主体有权访问的工作空间
GET/v1/workspaces/{id}查看工作空间
POST/v1/workspaces/{id}/invitations邀请成员
PATCH/v1/workspaces/{id}/members/{user_id}修改成员角色
POST/v1/workspaces/{id}/projects创建项目
GET/v1/workspaces/{id}/projects项目列表、筛选、分页
GET/v1/projects/{id}查看项目详情
PATCH/v1/projects/{id}更新项目元数据,支持并发控制
POST/v1/projects/{id}/agent-links关联 Agent
GET/v1/projects/{id}/runs查看项目运行
GET/v1/projects/{id}/artifacts查看项目产物
POST/v1/projects/{id}/archive归档项目
POST/v1/projects/{id}/restore恢复归档项目

13.2 创建项目请求 ​

http
POST /v1/workspaces/ws_123/projects
Idempotency-Key: 4b7f6c0b-0c8d-45aa-981f-45f29dd7e0e8
Content-Type: application/json

{
  "name": "Agent 技术地图",
  "description": "构建系统化的 Agent 技术研究知识库",
  "template_id": "research-project-v1"
}

成功响应建议返回 project_id、workspace_id、status、revision 和初始化任务状态。模板初始化若异步执行,应明确区分“项目创建成功”和“模板资源初始化完成”。

13.3 并发与幂等 ​

项目创建、邀请和归档等写操作应使用幂等键或明确的重复请求语义。项目编辑可通过 ETag/If-Match 或 revision 实现乐观锁;冲突返回 409 或 412 并提供可恢复操作。授权必须由服务端根据认证身份和数据库归属解析,不能信任客户端传来的 tenant_id。

14 · 安全、隐私、可靠性与治理 ​

14.1 威胁与控制 ​

威胁可能后果参考控制
跨工作空间 ID 枚举未授权读取项目对象级授权、租户过滤、最小错误信息
成员角色越权私自提升权限服务端权限矩阵、职责分离、审计
共享 Agent 泄露私有知识数据外流资源绑定独立授权、运行时重新检查
邀请链接泄露非预期成员加入短期令牌、身份绑定、一次性使用
删除项目误删共享资产其他项目故障引用计数/依赖检查、软删除、保留期
项目模板携带密钥凭证泄露模板清洗、密钥仅使用受控引用
并发修改覆盖项目元数据丢失乐观锁、冲突提示、修订历史
成本归属错误预算失控Run 固定项目/工作空间上下文、计量审计

14.2 审计事件 ​

至少记录 workspace.created、workspace.member.invited、workspace.member.role_changed、project.created、project.updated、project.archived、project.restored、project.asset_linked、project.asset_unlinked。事件应包含操作者、目标对象、租户与工作空间、时间、请求追踪 ID、必要的前后状态摘要;敏感内容和凭证不得直接写入日志。

14.3 删除与数据保留 ​

项目删除不能等同于立即删除所有底层 Blob:共享引用、法律保全、审计保留、备份窗口和已发布资产可能阻止物理删除。产品必须明确“从列表隐藏”“归档”“撤销访问”“进入删除流程”“物理删除”各自的含义和时效。

15 · 产品指标与可用性验证 ​

指标定义解读注意事项
Time to First Project首次进入到成功创建项目的耗时不应以牺牲授权清晰度换取速度
First Run Conversion创建项目后成功启动首次 Run 的比例需区分资源配置失败和用户放弃
Workspace Activation工作空间在观察窗口内产生有效项目活动的比例有效活动应排除纯浏览
Project Completion项目达到业务完成状态的比例不等同于 Run 成功率
Reuse Rate跨项目复用 Agent/Workflow 的比例高复用不必然代表高质量
Access Denial Quality用户是否理解权限拒绝及补救方式不能泄露被保护资源细节
Archive Recovery归档恢复成功率与耗时需要包含依赖资源失效场景
Unauthorized Access未授权跨项目访问成功数目标为零,需持续自动化测试

研究方法应结合任务可用性测试、访谈、日志漏斗与安全验证。建议分别邀请首次使用者、项目负责人和管理员完成真实任务,观察其是否理解 Workspace 与 Project 的边界。

16 · 分阶段开发路线 ​

阶段 1:个人工作空间与项目闭环。 自动创建个人 Workspace;支持项目创建、列表、详情、Agent/Workflow 关联、Run 和 Artifact 聚合。验收标准是单人用户无需理解组织管理即可完成一份研究报告。

阶段 2:团队协作。 增加成员邀请、角色、项目负责人、项目级访问控制、活动日志和审核入口。验收标准是不同角色能完成任务且不能越权。

阶段 3:资产复用与项目模板。 增加工作空间共享库、模板项目、固定版本引用、依赖校验、项目复制与归档恢复。验收标准是项目 B 能安全复用项目 A 的 Agent 而不复制密钥。

阶段 4:组织治理。 增加组织层级、预算归因、工作空间策略、跨项目分析与复杂成员管理。验收标准是权限、成本和审计能够跨项目一致运行。

阶段 5:跨组织协作。 按实际市场需求增加外部审阅、跨工作空间共享、专属租户环境和迁移工具。此阶段须以 P11/P12 的隔离与治理验证为前提。

17 · 工程验证与验收矩阵 ​

以下为待执行测试计划,不是已通过测试的报告。

ID测试场景预期结果
T01首次用户进入自动创建或正确引导进入 Workspace
T02重复提交创建项目幂等返回同一结果,不重复创建
T03未授权用户创建项目拒绝并记录安全事件
T04项目名称含特殊字符正确转义、显示,不产生注入
T05Workspace A 访问 Workspace B 项目访问被拒绝,信息不泄露
T06枚举项目 ID不暴露无权访问的项目
T07移除成员后访问旧页面后续请求立即受新权限约束
T08最后一个 Owner 退出阻止或要求先完成所有权移交
T09邀请过期后接受拒绝并提供重新邀请流程
T10邀请被重复使用不重复授予成员资格
T11低权限成员提升自身角色拒绝并审计
T12同时编辑项目元数据版本冲突被检测,不静默覆盖
T13项目关联已发布 Agent检查共享与使用授权
T14项目关联未授权 Agent拒绝关联
T15Agent 可见但工具凭证不可用明确提示依赖缺失,不泄露凭证
T16上游 Agent 渠道升级历史 Run 保留固定版本
T17撤销 Agent 共享权限新 Run 禁止使用;历史记录按政策保留
T18项目归档时仍有运行中 Run提示并执行明确的处理策略
T19归档后发起新 Run按策略拒绝或要求恢复项目
T20项目恢复时依赖已删除展示失效依赖与修复步骤
T21复制项目不复制密钥与未授权资产
T22删除项目但 Agent 被其他项目引用共享 Agent 不被误删
T23项目产物权限低于项目可见性产物继续遵守独立 ACL
T24成员离开后查看历史审核审核记录仍可追溯
T25跨租户缓存复用不返回其他租户数据
T26工作空间配额耗尽新操作按治理策略受限
T27运行成本归因关联正确的 Workspace/Project/Run
T28项目列表分页与筛选稳定排序,不遗漏或越权
T29Workspace 停用新运行被阻止,在途任务按策略处理
T30项目模板初始化失败项目创建状态与初始化失败可区分、可恢复
T31外部审阅者打开产物仅可访问显式授权范围
T32并发归档与创建 Run状态检查与任务准入一致,不产生幽灵任务
T33项目活动日志含敏感字段敏感内容被过滤或脱敏
T34工作空间所有权移交新旧 Owner 权限按原子规则更新
T35项目复制后的 Run 历史不伪造新项目的历史执行记录
T36备份恢复项目归属、引用和审计关联保持一致

验收应同时覆盖 API 集成测试、数据库隔离测试、端到端用户流程和故障注入。生产环境中的权限与隔离必须通过独立安全测试,而非仅依赖界面演示。

18 · 局限、权衡与开放问题 ​

  1. 组织层级与产品复杂度: 个人工具与企业 SaaS 对 Organization 的需求差异显著;过早设计复杂组织树会拖慢核心工作流。
  2. 共享与隔离的张力: 共享 Agent 提高复用率,但其 Prompt、知识依赖和工具权限可能携带敏感信息,必须分层授权。
  3. 项目作为容器还是业务实体: 研究 Studio 的项目往往是持续演化的研究计划,不能完全套用一次性任务管理模型。
  4. 成本归因: 同一共享 Agent 被多个项目调用时,执行成本应归属实际 Run,而不是 Agent 所有者;固定成本分摊需要独立规则。
  5. 跨工作空间迁移: 迁移不仅涉及项目记录,还涉及资源许可、产物引用、历史运行、审计和数据驻留约束。
  6. 协作与一致性: 实时协作、评论和复杂审批可在用户需求明确后逐步引入,不能以此替代核心版本与授权机制。

附录 A:参考文献与原始资料 ​

以下优先列出官方技术资料。它们支持身份授权、资源组织、对象访问与工程实践中的具体原则,并不直接定义统一的 Agent Workspace/Product 标准。

  1. Kubernetes Documentation. Namespaces. kubernetes.io/docs/concepts/overview/working-with-objects/namespaces (资源命名空间与隔离边界参考;Kubernetes Namespace 不等于产品 Workspace)。
  2. Kubernetes Documentation. Using RBAC Authorization. kubernetes.io/docs/reference/access-authn-authz/rbac (角色、权限和授权范围参考)。
  3. PostgreSQL Documentation. Row Security Policies. www.postgresql.org/docs/current/ddl-rowsecurity.html (数据库行级安全)。
  4. PostgreSQL Documentation. Constraints. www.postgresql.org/docs/current/ddl-constraints.html (复合外键与数据完整性)。
  5. OpenAPI Initiative. OpenAPI Specification. spec.openapis.org/oas/latest.html (接口契约)。
  6. IETF. HTTP Semantics, RFC 9110. www.rfc-editor.org/rfc/rfc9110 (条件请求、状态码等 HTTP 语义)。
  7. OWASP. API Security Top 10 - 2023. owasp.org/API-Security/editions/2023/en/0x11-t10 (对象级授权与 API 安全)。
  8. NIST. Digital Identity Guidelines, SP 800-63. pages.nist.gov/800-63-4 (身份与认证体系参考)。
  9. NIST. Zero Trust Architecture, SP 800-207. csrc.nist.gov/pubs/sp/800/207/final (不因网络位置或先前授权自动信任)。
  10. Open Policy Agent. Documentation. www.openpolicyagent.org/docs/latest (策略评估与分布式执行参考)。
  11. OpenFGA. Documentation. openfga.dev/docs (关系型访问控制参考)。
  12. Temporal. Documentation. docs.temporal.io (持久化工作流及长任务参考)。
  13. LangGraph. Documentation. docs.langchain.com/oss/python/langgraph/overview (Agent 工作流、持久化和人机协作参考)。
  14. OpenAI. Agents SDK Documentation. openai.github.io/openai-agents-python (Agent 运行、工具和追踪能力参考)。
  15. JSON Schema. Specification. json-schema.org/specification (项目模板和配置校验参考)。

附录 B:研究证据、验证声明与适用边界 ​

B.1 证据分层 ​

  • 标准与官方文档支持: HTTP API、数据库约束、RLS、RBAC、对象级授权、持久化工作流等通用工程机制。
  • 工程推论与参考设计: Workspace/Project 的两层导航、对象关系、角色矩阵、Studio 页面结构、项目状态机、数据表、接口路径、指标与阶段规划。
  • 尚未验证: 真实用户是否理解导航、权限设计在特定组织中的可用性、数据库模型在生产负载下的性能、跨服务事务与故障恢复、所有安全控制的有效性。

B.2 适用范围 ​

适用于以 Agent、Workflow、Run、Artifact 为核心对象的多用户 Agent Platform,尤其适合研究、内容生产与多 Agent Studio 场景。对于单用户本地 Agent 工具,可进一步简化 Workspace;对于受监管企业 SaaS,可能需要加强身份联合、审计、数据驻留、合规审批与租户隔离。

B.3 验证声明 ​

本文为截至 2026 年 11 月 1 日的架构研究稿。示例代码和接口未经生产部署、负载测试、渗透测试或正式用户研究;测试矩阵为建议验收项目,不代表实际通过。外部资料链接应在正式发布前进行可访问性和版本复核。