智能体模型
什么是智能体？
标题为“什么是智能体？”的部分智能体是一个具名的行动者，带有人格、一组技能，以及一个用于运行的适配器。智能体 与人类一样都是主体：它们撰写消息、拥有工单、留下评审，并出现在同一份名册上。 它们才是真正做事的对象。
每个智能体只属于一个工作区。这是一条硬性不变量——agent.workspaceId 不可为
空，由智能体自己的工作区决定它的行落在哪个数据库文件里，而创建一个没有工作区
的智能体会被拒绝。
智能体同时还是一个目录。它的定义位于工作区数据目录下的
agents/<slug>/AGENTS.md，它持有的技能则以符号链接的形式指向
agents/<slug>/.agents/skills。数据库行与文件是一起写入的。预置是幂等的：如果
智能体行已经存在，磁盘上的文件和技能链接依然会被重写。生产环境的调用方是创建
工作区，而不是每次启动服务器。
智能体包含什么
标题为“智能体包含什么”的部分| 属性 | 作用 |
|---|---|
name |
简短的类 slug 标识符（architect、qa），也是 @mentions 解析时所依据的名称 |
title |
人类可读的职位名称 |
persona |
自由文本的性格与行为指令，会作为提示词的一个小节注入 |
systemPrompt |
可选的附加指令，会作为 “Agent instructions” 小节注入——它们不会取代组装好的提示词的其余部分 |
skills |
不区分大小写的技能名称集合，会以磁盘上的技能链接形式镜像 |
adapterId |
智能体派发到哪个运行器。为空时回退到内置循环 |
modelId |
在该适配器内使用哪个模型 |
effort |
推理强度档位，取自所选模型自身的词汇表 |
contextSize |
上下文窗口的覆盖值 |
silenceTimeoutMinutes |
针对静默看门狗的按智能体覆盖值（1–240） |
reportsTo |
上级智能体 id——组织结构图据此绘制的汇报链 |
以上全部都在 设置 → 工作区 → 智能体 中编辑。新建智能体会创建一个未命名的 智能体，之后由你来填写。
技能是智能体实体上不区分大小写的名称。围绕它们会发生两件彼此独立的事情：
- 这些名称会列在组装好的提示词中一个名为 “Skills” 的小节下。这就是该实体的 集合本身所做的全部——并不存在以它为索引的按技能提示词库。
- 每个具名技能的目录（工作区中的
skills/<slug>/SKILL.md）会被链接进智能体 自己的文件夹。在内置运行器上，被链接技能的前置元数据会自动加载到系统提示词 中，智能体按需读取正文；在对话中输入/skill:<name>会将该正文作为本轮的 指令加载。
从外部获取的技能会在抓取与写入之间经过一道失败关闭的供应链扫描——没有判定，
任何技能内容都不会落到磁盘上或进入提示词。外部指的是你自己注册为技能来源的
GitHub 仓库：产品没有精选商店，因此仓库自身的元数据（它的描述、它的星标数、
技能的名称）都是不可信的展示数据，扫描判定才是唯一的安全信号。一次安装会抓取
技能的整个目录，在 skills-lock.json 中把它固定到来源提交上，之后的更新在
替换任何内容之前会重新过一遍这道关卡。具体做法见
安装和管理技能。
仓库作用域的技能
标题为“仓库作用域的技能”的部分仓库可以在任何常规位置（.agents/skills/、.claude/skills/、
.opencode/skills/）随附自己的技能。空间会把每个已链接的仓库并排检出到
repos/<name>/ 下，但一个智能体一次只在一个仓库中工作——因此它只携带该
仓库的技能，移动时技能集合也随之切换。
哪个仓库处于活动状态，是根据智能体触碰的文件推断出来的：在 repos/<name>/
下写入一个文件会把该仓库设为活动仓库，而仅仅跨仓库读取则不会，所以为追踪一个
符号而进入兄弟服务，绝不会让技能集合在任务进行中被换掉。在只有单个仓库的空间
里，答案在第一轮开始前就已经确定。
这种作用域限定是一项上下文预算决策。技能索引在每一轮都位于提示词中，而技能
正文不在，所以一次性列出每个仓库的技能会持续消耗 token——而且当工作其实发生在
另一个服务里时，来自某个服务的 testing 技能会主动误导智能体。同样的道理也
解释了为什么智能体的索引只携带一个仓库，而输入框不受这种作用域限制：自己给
技能命名是一个明确的动作，因此 /skill:<repo>:<name> 可以触达空间中的任何
仓库。
仓库技能会为每一个适配器加载，而不只是内置运行器。活动仓库的技能会被物化
到智能体的工作目录中——这正是 Claude Code 本来就会扫描的路径；同一份索引也会
被编入内置运行器所读取的 AGENTS.md。在这一切发生之前，仓库的技能要经过与
已安装技能相同的失败关闭扫描——检出的仓库就是克隆来的内容，而它的前置元数据
会进入提示词。
智能体自身不带任何权限标志。它能否创建提交、推送、打开 pull request、写入跟踪器或访问网络，由操作护栏决定——在工作区、智能体或空间范围内选择允许、先询问或拒绝——无论由哪个适配器运行它，都适用同样的规则。
一次运行被_交付_了什么，并不随这些规则而改变。在 GitHub 工作树中的运行始终拿到一个只读的 GitHub 令牌，而推送会在发生的那一刻被询问：智能体的 git 配置会把每一次 GitHub 推送都经由 Control Center 发送，Control Center 在转发之前应用推送到远程仓库规则。
这是如何运作的，包括在文件系统层面哪些会被强制执行、哪些不会，见沙盒与安全。
适配器决定哪些约束可以执行
标题为“适配器决定哪些约束可以执行”的部分智能体身上影响最大的单个字段就是它的适配器，因为适配器的传输方式决定了 Control Center 的策略究竟有多大一部分可以真正执行。
| 传输方式 | 适配器 | Control Center 强制执行的内容 |
|---|---|---|
| 内置运行器 | Control Center (built-in) | 全部。工具面是根据模式_构建_出来的，因此被禁用的工具是不可见的，而不仅仅是被拒绝；每次调用都会经过审批关卡与操作护栏；完成契约可以催促一次运行，并在它结束时缺少交付物的情况下将其判为失败 |
| Claude CLI | Claude Code | 它被提供的 mcp__* 工具，以及它的 Bash 命令——钩子会在这些命令运行前把它们发给操作策略。Claude 自带的读取、写入和编辑工具运行在它自己的进程里且不被看见——而且它启动时带有 --dangerously-skip-permissions，因为非交互式的 claude -p 否则会永远阻塞在它自己的提示上 |
具体来说，只有内置运行器支持子智能体、运行中引导、暂停与恢复（因而也支持 接管）以及结构化的模式强制执行。 Claude Code 一样都没有。
没有适配器的智能体会回退到 Control Center (built-in)——服务器内部的
循环，因此不必安装任何 CLI——它的运行日志会记录 cc-harness。每个预置的智能体
在创建时都没有适配器和模型，所以新工作区的五个智能体都在那里运行，使用
Anthropic 的默认模型，直到你为每个智能体设置适配器和模型。上手流程中的
“默认适配器”选择只是客户端偏好，服务器从不读取它，它也不会追溯应用到
已经创建的智能体上。
智能体的来源
标题为“智能体的来源”的部分- 随工作区预置。 每个工作区——不只是第一个——都会得到一个 CEO 外加四个向
它汇报的专员（
qa、architect、engineer、librarian），在工作区创建时 于后台幂等地创建。见工作区与隔离。 - 手动添加，在 设置 → 工作区 → 智能体 中。让智能体去雇佣一位同事 并不会创建一行记录；请使用那个界面。
实时状态
标题为“实时状态”的部分智能体没有存储的状态列。它的实时状态在每次被读取时，都从它最近的运行日志中 推导出来：
| 状态 | 含义 |
|---|---|
neverRun |
不存在运行日志 |
running |
当前至少有一次运行正在进行 |
failed |
最近一次运行出错，或它的存活状态为失败或已死亡 |
blocked |
最近一次运行的存活状态为阻塞、停滞或陷入循环 |
idle |
其他一切情况——该智能体运行过，且当前没有任何进行中的任务 |
另外两个状态 queued 和 succeeded 存在于对话运行树中的单次运行上；名册从不
产生它们，因为一次已完成的运行为绿色是关于这次运行的事实，而不是关于这个智能体
的事实。
在线状态名册展示的是一幅平行而更粗略的图景，由服务器端根据实时运行事件合成 ——思考中、运行中、等待审批、完成——正是它让智能体能出现在人类旁边。见 多人协作。