模式

模式是什么

模式是空间的属性，以空间行上的一列存储。空间内的每一段对话都共享它，子对话也不例外——子对话和其他任何对话一样，继承其所属空间的模式。因此，同一个智能体可以同时在不同的空间里处于不同的模式；切换某个空间的模式会改变下一轮发生的事情，却完全不触及该智能体。

一共只有四种：chat、review、plan、orchestrate。枚举本身不携带任何策略。一个模式所保证的一切只声明一次，写在能力配置里，每一层强制执行机制都从它投影出来：

工具面——在该模式下究竟存在哪些工具，表述为最高审批层级、一份允许列表、一份拒绝列表，以及一组被拒绝的效果类别。
必需的输出动词——一次运行必须调用什么，才算交付了东西。
被拒绝的效果类别——操作护栏会直接拒绝哪些东西。
工作树姿态——工作树是否可写。它是通过把会改变状态的工具从工具面中剥离来强制执行的，正因如此它才在所有主机上都成立。若主机带有操作系统沙盒，同一姿态还会刻出文件系统的写入规则——只读模式以只读方式挂载工作树——但那只是这份保证的第二份副本，真正在干活的并不是它。
系统提示词区块——一段_生成的_能力前言，源自实际物化出来的工具列表，再加上手写的指导。

每一层强制执行机制都从这一份配置投影，因此工具面、护栏、工作树姿态和提示词不可能相互矛盾。

四种模式

聊天——显示为“Agent”

这是默认模式，也是唯一没有任何额外约束的模式：直到执行层级的完整工具面、可写的工作树、没有被拒绝的效果类别，也没有完成契约。用它来实现功能、修复缺陷、询问代码库相关问题，以及任何临时任务。

注意这个标签：在输入框中，该模式显示为 “Agent”，而不是“聊天”。

计划——只读，单一交付物

计划模式把工作树设为只读，并把写入工具从工具面中彻底剥离，因此这项限制是结构性的，而不是靠指令说出来的。智能体读取、搜索、调研，并且只交付一件东西：一次 submit_plan 调用，携带一张带类型的依赖图——一个目标，外加若干节点，每个节点都有键、标题、描述，以及它所依赖的节点键。

计划在对话中显示为一行紧凑的条目，并在旁边的标签页里打开 Plan Studio。批准它会把这幅图编译成一次编排、运行生成出来的工作，并把发起该计划的空间切回智能体模式。

如果一次计划模式运行结束时始终没有调用 submit_plan，循环会先注入一条提醒，说明在该调用成功之前计划并不存在。这条提醒明确授权一个诚实的“这里不需要计划”的退出方式，因为计划模式是一项空间设置，在里面问一个普通问题不该被迫产出一份假计划。

还有第二种、彼此独立的退出方式：exit_plan_mode。它是一道硬性审批闸门，而不是输出动词——调用它而不调用 submit_plan 的智能体什么也没有交付。第一次调用会开启一项持久的 plan_exit 审批并返回 pending，空间保持只读；重复调用仍然是 pending，而不会开启第二道闸门。只有在审批获批之后，后续调用才会把空间切到聊天模式。拒绝则允许智能体新开一个请求，以获得修订后的计划。

要自己离开计划模式，切换输入框中的下拉菜单（或按 Shift+Tab）。exit_plan_mode 由 MCP 工具 decide_approval 裁决。收件箱里的“智能体审批”行是另一回事：它们来自正在运行的智能体，是逐轮的确认提示。

审查——只读，没有契约

审查模式用于 PR 审查。它把工作树设为只读，把工具面封顶在执行层级之下，并应用一份精心挑选的允许列表，涵盖审查、工单和沟通类工具。为某个 pull request 打开的空间会自动以审查模式创建。

智能体的输出是结构化的发现项——审查节点——以及审查定稿时的一份结论。一个节点带有类型（bug、suggestion、recommendation、question 或 ticket）、从 P0（阻断发布）到 P3（有则更好）的优先级、一个自评置信度、一个可选的锚点（文件加一个行范围；全仓库范围的笔记没有锚点），以及一个生命周期状态：一旦有同行——绝不是作者本人——确认，它就从 open 变为 consensusReady。优先级或置信度缺失、或超出范围的发现项，会在读边界被丢弃，而不会污染结论。

结论是 ship、hold 或 block，而折入其中的各轴结果只会让它变得_更_严厉：受门控的轴失败会强制为 block，受门控的轴无法运行则至少强制为 hold。证据缺失永远不会让一道门控变绿。

与计划和编排不同，审查没有完成契约。发现项通过 add_review_node 积累，并由 finalize_review 发布，两者都完全可以被调用零次——以审查模式运行的流水线智能体，可能只是来完成一张工单的。

编排——只读，提议一支团队

编排模式把一个目标变成一份属于整支团队的计划。与计划模式一样，它是只读的，不能写文件；在研究工具面之上，它有一个唯一的特权动词 propose_orchestration，会产出一份结构化提案：角色、一棵子工单树、一个综合步骤和一份预算。提示词只列出工具面上的工具，因此模型不会把轮次花在讲述它无法调用的招聘或工单工作上。

在你批准之前，提案里的任何内容都不会执行。批准时，一个确定性的物化器会聘用智能体，创建工单和一个项目，并运行一条生成的流水线。批准仅限操作者：没有对应的 MCP 工具，因此智能体可以提议，但永远不能批准自己的计划。由智能体发起的重新提议受两分钟冷却时间的限制，因此连续的重新规划会被拒绝，并被要求合并。参见编排。

两条值得了解的规则

模式自己的输出动词永远不会被拒绝。 submit_plan 和 propose_orchestration 被钉进工具面，并一律越过工具过滤器、审批闸门和操作护栏，获得预先批准，因此按空间生效的自主程度旋钮无法让某个模式的交付物沉默。harness 的 ask_user 出于同样的原因被钉住：它_正是_一次运行触达操作者的方式，对它加门控会让一次需要提问的运行死锁。它属于读取层级，因此每种只读模式都保留它；它还豁免于审批包装层——在没有连接任何审批者时，提示词前面再加一层提示词会直接失败关闭，而这会剥夺智能体提问这一行为。

只读模式不会拒绝网络访问或密钥。 审查、计划和编排所拒绝的效果类别，都是会改变世界的那些：删除文件、写入工作树之外、创建提交、推送到远程仓库、创建和发布 PR、写入外部跟踪器、安装软件包、运行进程、更改工作区结构以及操控隔离舱。网络出口和密钥访问则有意保持各自的默认值——研究本来就是只读模式的全部意义。

选择和更改模式

输入框中的模式下拉菜单提供三个选项：Agent（聊天模式）、Plan 和 Orchestrate。review 不能由用户选择——它由系统在创建 PR 审查空间时设置，也由流水线步骤设置。

一个打开空间的流水线节点，可以用 extras['mode'] 键（chat、review 或 plan）固定该空间的模式。该键要求精确匹配：其他任何写法——包括 orchestrate——都会被静默忽略，空间会拿到请求体的默认值（在创建空间的请求体上是 review）。智能体步骤加入的是它没有创建的空间，不会重新设置其权限。

解析本身很简单。调度器读取空间的 mode 列；不带空间的派发——一次性运行、CLI 调用，或来自另一个工作区的空间 id（它根本不在这个工作区的数据库文件里）——会解析为 chat。更改模式从下一轮开始生效。

这项保证真正成立的地方

模式的工具面由内置 harness 构建并强制执行。它是唯一能把工具变得不可见、而不只是拒绝调用，能在每次调用运行前加以门控，并能观察完成契约的传输通道。

在 Claude Code 传输通道上，非聊天的模式会以 --permission-mode plan 传入。Claude 只是按惯例遵守这一点；它自己的读取、写入和编辑工具都在视野之外运行，shell 命令也只由一个读取命令行的钩子检查。对该传输通道而言，模式只是指导，而不是 Control Center 的边界——参见智能体模型。

允许列表约束的是写入层级及以上的工具。内置 harness 的读取层级仍能触达没有任何列表点名的工具；而在 Claude Code 上，允许列表未收录的工具会被拒绝，无论服务器是否提供它。