术语表
核心实体
标题为“核心实体”的部分智能体：具备身份、角色、技能和适配器的 AI 工作者。恰好属于一个工作区。系统中的主要行动者。
适配器：执行智能体回合的运行器。产品内置两种：Control Center（内置）——与模型提供方通信的进程内 harness——以及通过 claude -p 运行的 Claude Code。Cursor、Codex、Anthropic、OpenAI 等其余都是内置适配器上的提供方，而不是独立的 CLI。参见管理适配器与模型。
工作区：顶级的隔离租户。将智能体、仓库、空间、工单、记忆和流水线归组在一起。隔离是结构性的，而非约定俗成：每个工作区都有自己的 SQLite 文件（<dataDir>/<workspaceId>/workspace.db），因此跨工作区读取根本无法通过编译。应用内每条路由都带 /workspaces/:workspaceId 前缀——参见路由图。
代码托管平台：代码托管服务——GitHub、GitLab 或 Bitbucket Cloud。代码托管平台是每个仓库的属性，在注册时从其 origin 远端读取，并决定该仓库使用哪个 API 适配器和凭据。一个工作区可以同时容纳来自这三者的仓库；聚合类界面（收件箱、PR 队列）会向所有出现的代码托管平台扇出请求并合并结果，同时隔离故障，使某个不可达的平台绝不会让其他的也变空。各代码托管平台支持的能力不同——参见连接代码托管中的能力表。
仓库：注册在某个工作区内的 Git 仓库。以工作区为作用域——同一个检出注册到两个工作区就是两行彼此独立、id 各异的记录；跨工作区的仓库身份按文件系统路径判定，绝不按 id。注册要求该 git 工作树的 origin 远端指向受支持的代码托管平台。每个仓库都带有自己的代码托管平台（github / gitlab / bitbucket），由它决定所用的 API 适配器和凭据。
隔离仓库：某个已注册仓库的、以工作区为作用域的工作树。在支持该原生实现的平台上通过 rift 做写时复制；Windows 上使用 git worktree。按空间预配——该空间中的每段对话共享同一份检出——因此智能体绝不会改动源仓库。
空间：以工作区为作用域的协作容器，包含人类与智能体参与者、持久化的 Mode、预配状态，以及一个 SpaceKind（topic / agentPeer / system / pr / slack），后者决定它如何被分区、静音、加徽标和垃圾回收。它拥有其对话所共享的隔离工作树（通过 rift 写时复制；Windows 上为 git worktree）。
对话：空间内部的一条消息流，拥有自己的 id、历史和智能体运行上下文。同一空间内的各段对话完全平等——不存在主流程或“主”流。每段对话都作为一个编辑器标签页打开；空间的未读状态会跨所有这些对话汇总。
讨论串：设置了 anchorMessageId 的对话：锚定到同一空间内某个同级对话的一条消息，并由那条锚点消息播种出全新的智能体上下文。只允许一层深度——讨论串绝不会锚定到讨论串。
工单：工作单元的聚合根。与厂商无关：默认是 local，并为 Linear、GitHub Issues、Jira Cloud 和 ClickUp 提供同步适配器——不过应用内没有任何界面会创建同步连接。支持层级、链接和委派。将工单指派给智能体只记录归属关系，不派发任何东西；指派给团队是例外（由 TeamRoutingService 派发负责人）。
流水线：基于 DAG 的工作流，把各个步骤（智能体派发、脚本、条件）串联起来。由模板定义；以运行的形式执行。
值对象
标题为“值对象”的部分AgentRole：枚举角色（CEO、coder、reviewer、QA、designer、security、devops、PM、general）。决定人格、记忆访问权限和层级。
AgentSkills：一组不区分大小写的技能标识符，在派发时把相关上下文注入提示词。
技能源：按工作区注册为技能目录的 GitHub 仓库。按构造即不可信：该仓库的元数据仅用于展示，且每次安装都必须先通过失败即关闭的扫描闸门，之后任何内容才能落到磁盘或进入提示词。参见安装和管理技能。
skills-lock.json：按工作区记录的已安装技能清单：每个技能的源仓库、仓库内路径、所固定的提交，以及一个汇总内容哈希。安装、更新和卸载都会让它保持最新；verify_skills 会拿它与磁盘核对。
智能体运行网关：cc_server 上的一个回环端点，在智能体的沙盒内应用操作策略。智能体发起的每一次 GitHub 推送都会被路由到这里，按推送到远程仓库规则检查，再用一个智能体从不持有的写入令牌转发；Claude Code 的 Bash 命令则经由同一端点上的钩子检查。参见沙盒与安全。
模式：chat、plan、review 或 orchestrate。按空间存储，因此同一个智能体可以在不同空间处于不同模式；空间内的每段对话共享它。它控制系统提示词、沙盒写入规则和 MCP 工具允许列表。输入框只提供 chat、plan 和 orchestrate；chat 的标签是“智能体”。
SandboxBackend：microvm（隔离的虚拟机——唯一带有内核边界的后端，用于交互式终端）、native（macOS 上是 Seatbelt，Linux 和 WSL2 上是 bubblewrap）或 none。启动时探测一次；native 可用时会包裹智能体派发，包裹 Claude Code CLI 和 harness 的 bash 工具。Windows 没有原生后端，Linux 需要 bwrap 加 socat，因此那里的运行不会被包裹；--sandbox off 会刻意选择退出。
机台：智能体实时操控的一台可丢弃机器——一个隔离的浏览器或 Linux 桌面、由宿主机管理的 Android 模拟器或 iOS 模拟器，或一个隔离终端。通过它自己的全分辨率通道实时观看，接管由服务器端强制执行。以对话为作用域，因此人类标签页与智能体的 browser_use / computer_use / mobile_use / ios_use 调用面对的是同一台默认机器。参见机台与隔离舱。
隔离舱：由虚拟机支撑的机台所能提供的更强边界——内核边界、一次性覆盖磁盘、默认拒绝的网络闸门和凭据代理。Android 和 iOS 机台是可丢弃的，但使用宿主机管理的网络，因此不宣称具备这道边界。操控任何机台都会用到 enclosureControl 护栏类别。
RunCost：单次智能体运行的令牌/成本统计（输入令牌、输出令牌、以分为单位的估算成本）。
唤醒原因：智能体被派发的原因。共六个取值：用户消息、工单指派、失败后的恢复性重派、子工单完成、定时的后续心跳和流水线步骤。
SandboxPort：管理沙盒生命周期（探测、启动、事件、exec、销毁）。
CredentialBrokerPort：为沙盒启动铸造按作用域限定的凭据——智能体环境中为只读，写入权限仅用于服务器端的推送路径——并在拆除时撤销它们。
GitRepoInspectorPort：从本地 Git 仓库路径中提取元数据（owner、repo、branch）。
EmbeddingPort：生成用于语义搜索的单位范数文本嵌入向量。
NotificationPort：显示原生的桌面通知，并遵守类别/路由门控。
TicketProviderPort：通往工单后端的与厂商无关的边界（创建、获取、列出、更新、转换状态、指派）。
PipelineEnginePort：从模板启动一次流水线运行，使调用方与具体引擎解耦。
领域服务
标题为“领域服务”的部分AgentDispatchService：启动智能体运行：预配隔离仓库、构建提示词、创建运行日志、返回实时事件流。
TicketWorkflowService：纯领域的工单生命周期引擎，带有乐观并发变更收口点和工作区隔离强制。它强制执行的转换图只约束智能体和自动化；用户驱动的界面变更会传入 force: true 并绕过它。对于智能体受让人并没有工单派发器——AgentDispatchService 负责派发，把工单指派给智能体不会启动任何运行。把工单指派给团队是例外（由 TeamRoutingService 派发负责人）。
PipelineEngine：编排运行执行：启动运行、调度步骤、持久化状态、处理路由器/汇合/失败继续，并在重启后恢复进行中的运行。
PipelineTriggerDispatcher：订阅领域事件，并为已启用的触发器自动启动匹配的流水线运行。
MemoryAccessPolicy：解析并强制执行各领域上按智能体角色划分的记忆权限。
HarnessCostCalculator：依据 models.dev 目录，把内置 harness 的令牌用量折算为一个 RunCost。派发会把该统计持久化到运行日志上。
BudgetEnforcementService：计算每个智能体的月度支出，并产生一个派发前阻断（checkInvocationBlock）。该阻断只会被恢复类对账器（OrphanRunReaper、StrandedTicketReconciler）查询，绝不会被普通的用户或智能体派发查询。
BudgetGovernanceService：在每次运行后评估每个智能体的月度支出——达到软阈值会记录一条警告事件；耗尽则记录一条严重事件，并把智能体的生命周期翻转为 paused。
DomainEventBus：用于跨功能通信的进程内广播式发布/订阅总线。事件是带类型的；订阅者消费 on<T>() 流。
DomainEvent：基础接口。每个事件都有 occurredAt。主要类别：工作区/智能体、PR/审查、消息、工单、流水线、会议/日历、身份、机台、可观测性。
会议与日历
标题为“会议与日历”的部分会议：在本地录制并转录的会议会话。捕获麦克风和系统音频，使用可选的 ASR 模型在设备上转录（默认是 Parakeet TDT v3；Parakeet TDT v2、Whisper large-v3-turbo 和 Whisper base.en 是备选方案），区分说话人，并总结为笔记、行动项和决策。选定的 ASR 模型会在启动时强制安装，录制相关功能在重启一次后启用。以工作区为作用域；数据留在本机。
MeetingSegment：一段被转录的音频窗口，带说话人标记（me/them）、一个说话人分离标签和毫秒级偏移量。
MeetingActionItem / MeetingDecision：由总结流水线提取并以独立行存储的结构化输出。行动项可以链接到一张工单。
CalendarEvent：同步的 Google Calendar 条目，以某个工作区和已连接账号为作用域。与会议不同：事件是已安排的承诺；会议是已录制的会话。通过 MeetingCalendarLink 一对一关联。
CalendarAccount：已连接的 Google 账号，按工作区和邮箱区分。OAuth 刷新令牌以 google_* 键的形式存储在 <dataDir>/secrets.json 中，永远不会到达客户端；设备码流程在服务器上完成。一个 authExpiredAt 标志驱动重新连接横幅。
架构术语
标题为“架构术语”的部分整洁架构：依赖规则：表现层 → 应用层/提供方层 → 领域层 ← 基础设施层。领域层对基础设施的导入为零。
端口与适配器：领域层定义抽象接口（端口）；基础设施层提供具体实现（适配器）。组合根把它们绑定起来。
共享内核：core/domain/ 中跨 3 个及以上功能共享的实体、值对象、端口和服务。
以功能为先：代码按业务领域（智能体、流水线、消息）组织，而不是按技术分层组织。
多人协作、身份与速度
标题为“多人协作、身份与速度”的部分主体：把人类与智能体统一为单一行动者抽象的密封值——UserPrincipal(userId) 或 AgentPrincipal(agentId)。每条消息、每张工单、每次审查、每个计划和每份运行日志都通过主体来归属。
用户：人类身份，存储在 global.db 中，因此跨工作区全局唯一。创建工作区的主体成为其所有者——在同一次操作中盖到 Workspace.ownerUserId 上，并写入一行所有者角色的成员记录。其他人通过邀请或 SSO 加入。
WorkspaceMember / WorkspaceRole：把 User 以某个角色（owner / admin / member / viewer / guest）绑定到 Workspace 的成员记录。成员身份——而不是配对密钥——才是访问边界。 按仓库授予的权限让成员身份不会比代码托管平台拥有更高特权。
ParticipantPresence：针对某个主体的临时感知（状态、位置、光标、正在输入、智能体的实时状态与运行费用）。从不持久化；由服务器集中中转；在扇出前先按仓库授权过滤。
跟随模式：点击某个头像即可跟随其视口，直到你自己动手，然后脱钩。对人和智能体都适用（“观看智能体干活”）。
自主程度：按空间、按智能体的控件——propose-only / act-with-approval / act-freely——以动作护栏存储之上的一个具名档位实现。
ActionClass：包含 13 种效果类别的封闭集合（fileDelete、gitPush、prCreate、networkEgress、processSpawn、enclosureControl 等等）。每个变更类工具都会声明自己的类别；护栏引擎按作用域解析出 allow / prompt / deny（space > agent > workspace > mode preset > built-in default）。
WriteLedger / 幂等键：每次变更都携带一个由客户端生成的幂等键（UUIDv7，按逻辑操作划分）。以工作区为作用域的账本会在处理器运行之前去重；重放会返回字节级完全一致的原始结果。从构造上就让重连和多客户端变得安全。
Needs me 收件箱：一条跨越各个支柱的队列，规则严格——只有当某个条目_阻塞_了某事（某个智能体、一次合并、一次同步），或它明确请求操作者介入时，它才会出现。
Plan Studio：交互式规划界面——可编辑的带类型 DAG 计划，带有按步骤的成本、时间和风险，以及部分批准。
审查计算：服务器端的 PR 审查计算（由图谱推导的队列、带类型的图表、视觉差异、API 契约差异、多轴门禁），通过 review_studio.* 提供，并汇总进评审标签页。
审查空间：PR 唯一的底层空间（模式 review，类型 pr），以幂等方式创建，并通过 ReviewSpaceAssociation 与该 PR 关联。每位审查者都把发现项提交在其中，这正是它们可比较的原因；它的隔离工作树中，PR 已检出至其 head。
审查节点：AI 审查发现项的结构化单元：类型（bug、suggestion、recommendation、question、ticket）、优先级 P0–P3、一个类别/严重程度/工作量的分诊三元组、一个文件与行的锚点、可选的建议修复，以及一个置信度分值。通过 add_review_node 提交；判定是根据节点计算出来的，而不是根据散文。
已达共识：只有在另一位同行审查者确认某个发现项后才会到达的审查节点状态——智能体无法确认自己提出的发现项。评审标签页的发布到 GitHub 按钮会发送所有仍然未解决的发现项（selection: all_open）；MCP 工具 publish_review_to_github 仍然只默认发布经同行确认的发现项。
审查级别：工作区策略（light、balanced、thorough），拨动派出哪些审查者（仅工程师；+qa+architect；+security+perf），以及低于阈值的发现项呈现在哪里。绝不删除任何发现项。
审查轴：每次审查的五条评分通道之一：correctness、security 和 testGap 取自审查者的发现项；visual 和 apiContract 是确定性的。受门禁约束的轴会汇总进判定，并且只会让它更严重——partial 或 unavailable 的门禁会拖住判定，而不是让它通过。
审查判定：ship、hold 或 block。任何置信度 ≥ 0.7 的 P0 发现项都会阻断；任何其他 P0 或任何 P1 则拖住；否则就是 ship。受门禁约束且失败的轴会强制阻断，且无法被发现项投票推翻。
机群与评测
标题为“机群与评测”的部分cc_worker：无界面的纯 Dart 机群执行器二进制文件。与某个 cc_server 配对，声明其宿主机能力，拉取租约作业，执行它们并把进程事件流式回传。不持有任何持久状态——一台权威服务器，N 条笨拙的手脚。
JobSpec：一切可执行对象（智能体运行、流水线步骤、代码索引、金样渲染、基准测试、评测批次）的带类型规格。
评测套件：以工作区为作用域的评测定义（提示词、目标智能体与模式、评分器）。创建工作区时会预置五个入门套件；可观测性 → 质量会列出它们。
部署与客户端
标题为“部署与客户端”的部分瘦客户端架构：没有任何客户端会打开数据库；一个无界面的 cc_server 进程持有数据，并通过 WebSocket RPC 对外提供。每个客户端（桌面端、Web、手机）都只是那一条 RPC 连接之上的渲染层。
cc_server：无界面的服务器二进制文件（纯 Dart，不含 Flutter 引擎）。持有 Drift/SQLite 数据库，通过 WebSocket 提供仓库 RPC，并运行后台服务（流水线、MCP、对账器）。
ServerConnectionMode：桌面端连接其服务器的方式——local（在本机启动一个 cc_server，这是默认值）或 remote（连接别处的服务器）。Web 客户端始终是 remote。
RemoteRpcClient：每个瘦客户端用来与其服务器通信的、与传输无关的 JSON-RPC 客户端——可经由 WSS、回环或经代理中转的中继。
按调用限定工作区范围：服务器是无状态的——不存在按会话绑定工作区的机制，因此同一服务器上的多个客户端绝不会共享同一个“当前工作区”。每个以工作区为作用域的 repo/call 和 sub/subscribe 都必须在其参数中携带 workspace_id；缺失或未注册的 id 会在任何数据库被打开之前被拒绝。访问随后由工作区成员身份和角色把关，而不是由会话把关。
cc_remote：手机瘦客户端——一个 Flutter Web PWA，通过经代理中转的中继远程控制机群，并采用默认拒绝的工具策略。
cc_signaling_server：无状态的 WebSocket 中继代理，托管需邀请才能加入的房间——一个笨拙的中继，只转发端到端密封的帧，不保存任何应用数据，也永远看不到配对 PSK。