Cursor permissions.json autoRun schema：allow_instructions、block_instructions、local.customTools 与嵌套子 Agent

Cursor 6 月 SDK 更新乍看像一个日常质量包：自定义工具、自动审核分类器、JSONL 持久化存储、嵌套子 Agent，外加一批稳定性修复。但搜索需求更具体：团队在问 permissions.json 里的 autorun.allow_instructions 和 autorun.block_instructions 应该如何配置，local.customTools 与 local.autoReview 到底如何协同，以及 JSONL store 是否能留下可审计的运行轨迹。以运营商视角再读一遍，图景截然不同。Cursor SDK 0.1.6 将三件过去需要手动搭建的事——MCP 接入、审批管控和运行可观测性——整合为 SDK 原生能力。 这改变了本地 agent 集群的设计方式，也改变了 AI gateway 需要回答的问题。

发布内容

五项变更对运营商影响最大：

• 通过内置 MCP 暴露自定义工具。 local.customTools 允许在 Agent.create() 或每次 send() 时传入函数定义。SDK 通过一个名为 custom-user-tools 的内置 MCP server 将这些工具暴露给 agent，调用路径和权限管控与其他 MCP 工具完全一致。父 agent 的自定义工具对所有子 agent 同样可见。
• 基于自然语言规则的自动审核。 无人值守的本地 agent 此前会不经审批直接执行工具调用。local.autoReview 现在将调用路由给一个分类器。你可以在 permissions.json 中通过 autoRun.allow_instructions 和 autoRun.block_instructions 设置自然语言规则，例如"只读检查 ./dist 构建产物是安全的"或"删除操作必须暂停等待人工确认"。
• JSONL 与可插拔持久化。 agent 和运行元数据此前存储在 SQLite。现在可以切换到 JsonlLocalAgentStore（纯追加文件，可 diff、可提交），或实现公开的 LocalAgentStore 接口——in-memory 适合 CI 临时运行，Postgres 适合生产环境。
• 任意深度嵌套子 Agent。 子 agent 可以再生成自己的子 agent，每个拥有独立 prompt 和模型。无需 feature flag——子 agent session 自动注册所需的 executor 来调用 Task。
• requestId 关联与稳定性修复。 每次 send() 携带平台生成的 requestId，暴露在 Run 和 RunResult 上并跨三种存储持久化。cloud agent session 在 HTTP/1.1 transport 上正确流式传输。wait() 不再在终态结果写入之前 resolve。本地 shell 使用捆绑的 rg，避免在 Windows 上污染 PATH。

还有一行不起眼但影响重大的内容：仍在使用已退役 composer-2 slug 的脚本会被静默路由至 Composer 2.5。 这是供应商管理的模型迁移，不是废弃窗口，且与新的自动审核分类器同批发布——两者都是 Composer 2.5 的地盘。

对 AI 工程团队的意义

在 0.1.6 之前，将 Cursor 本地 agent 投产意味着手动拼接三件事：一个外部 MCP server 暴露内部工具、一个薄封装来拦截破坏性调用、一套自定义存储或精心管理的 SQLite 以防多进程编排丢失状态。每件都是一个小项目，也各自是独立的审计边界。

这个版本将三者纳入 SDK：

• 自定义工具 = 不需要独立 MCP server 的 MCP。 此前让 agent 使用内部 lint 配置需要一个 stdio MCP server、一个进程管理器和一条权限记录。现在一个函数定义就够了。MCP 层依然存在——只是内嵌了——意味着相同的 allow-list、相同的工具命名规范、与远程 MCP 工具相同的审计面。
• 自动审核 = 可读的治理策略。 permissions.json 中的自然语言规则可以 review、可以 diff、可以由不写 Cursor SDK 代码的人来 code review。安全或平台团队可以拥有 block_instructions 而不需要拥有 agent 脚本。权衡是真实的：调用是由分类器来决策的，"分类器说可以"与"人工说可以"是不同的审计故事。
• JSONL + requestId = 可观测性契约。 追加式 JSONL 可以 grep、可以 diff、可以接入日志管道。requestId 可以将单次 send() 调用关联到 in-memory、SQLite 和 JSONL 三种存储的后端日志、埋点和支持工单。对于一直在 agent 运行中手动维护关联 ID 的团队，这是一次有实质意义的契约升级。
• 嵌套子 Agent = 一个路由树问题。 "reviewer 委托给 test-writer，test-writer 再委托下去"——这正是悄悄推高 coding agent 集群 token 成本的多层编排模式。每一层可以选择自己的模型，这意味着现在每层嵌套都有一个真实的路由策略决策，而不只是顶层 agent。

permissions.json 自动审核配置：真正要写什么

这次发布对应的搜索需求很具体：团队不只是想知道 Cursor 是否加入了自动审核，而是在问 如何配置 .cursor/permissions.json 给 auto-review classifier 使用。实操模型可以拆成四层：

• local.autoReview 为无人值守的本地 agent 启用分类器审批。
• permissions.json 通过 autoRun.allow_instructions 和 autoRun.block_instructions 承载自然语言策略。
• local.customTools 会通过内置 custom-user-tools MCP server 暴露 SDK 本地函数，因此这些工具仍然要像远程 MCP 工具一样接受策略审查。
• 任何允许文件写入、shell 执行、包管理器变更、部署步骤、凭据访问或网络调用的规则，都应该写成窄例外，而不是宽泛授权。

安全的起步方式是让 allow list 尽量保守，让 block list 足够明确：允许只读检查、确定性的测试命令，以及仅限生成产物目录内的写入；阻止删除、读取密钥、访问生产端点、发布包、修改云资源，以及任何执行前无法解析目标路径的工具调用。这不能让分类器审批等同于人工审批，但至少让 reviewer 面对的是可 diff 的具体 schema，而不是一句模糊的“信任 agent”。

路由/运营商视角

如果你运营 AI gateway、内部 coding agent 集群，或两者兼有，这次 SDK 更新推动了一些不能再拖延的决策。

1. 明确哪些自定义工具走 SDK 本地，哪些走 gateway 中转。 内置 custom-user-tools MCP server 在 agent 进程内部运行，本地文件操作没问题。但触及生产系统的工具不应如此——那些应该流经 gateway，以保留集中的认证、限流和审计。local.customTools 用于仓库本地能力；生产系统调用保留在 gateway 可见的远程 MCP server 后面。
2. 将 permissions.json 视为代码形式的策略。 autoRun.allow_instructions 和 autoRun.block_instructions 是自然语言，容易被低估。将其提交到与 agent 同一仓库，像配置文件一样 code review，并考虑在 CI 中加入当 block instructions 被删除时失败的检查。如果你的平台团队在其他地方管理沙箱策略（Claude Code 的 availableModels、Codex 的沙箱 profile），对齐措辞，让工程师无论使用哪个工具都能看到一致的意图。
3. 为每个环境明确持久化策略。 SQLite 是默认；JSONL 是审计友好的；自定义 store 让你把状态落到 Postgres 或已有的事件日志。正确选择取决于是否需要跨进程可见性（Postgres）、廉价持久日志（JSONL）还是快速本地恢复（SQLite）。主动决策——不要任由每台机器各自默认。
4. 将 requestId 作为关联原语。 把 Run.requestId 写进 Cursor SDK agent 的每一条日志、每一个计费事件和每一次支持升级。如果你已经为非 SDK 流量发放 gateway request ID，决定哪个是权威 ID 以及它们如何映射。现在是最便宜的时机，在脚本和 dashboard 形成各自的关联惯例之前。
5. 审计嵌套子 Agent 深度。 "任意深度"对大多数团队来说是错误的默认值。在 Agent.create() 外面加一个封装，强制最大嵌套层数，为每一层单独归因 token 花费，并在某层没有路由策略指定模型时拒绝继续生成。否则集群里最便宜的模型最终做了最多的工作，最贵的模型反而在五层深的地方做 review。
6. 注意 Composer 2 → Composer 2.5 的静默路由。 任何盘点工作都应该标记仍在请求 composer-2 的 SDK 客户端。它们今天靠供应商好意拿到 Composer 2.5，并非合同保证。在客户端代码里把这些 pin 向前推，避免未来路由规则变化带来意外。

更大的信号：coding agent 供应商正在将 MCP、审批策略和可观测性整合进 SDK。这对个人开发者是好事，也悄悄给 AI gateway 施加压力——不只是路由，而是成为工具清单、审批策略和运行关联跨 Cursor、Claude Code、Codex 及后续产品汇合的地方。

TheRouter 用户的行动建议

如果你已经通过 TheRouter 路由 Cursor 流量，当前的审计很直接：列出仓库里所有 local.customTools 定义，将每一条映射到"仅本地"或"必须经过 gateway"，把触及生产系统的那些移到 gateway 可见的远程 MCP server 后面。更长远的方向是将 permissions.json、availableModels 和 gateway allow-list 视为用三种方式表达的同一套策略，并将 requestId 接入计费和故障响应管道，让单次 SDK send() 调用可以端到端追踪。随着嵌套子 Agent 成为常态，路由层的价值越来越体现在成本归因和深度管控，而不只是为顶层 agent 挑选合适的模型。