Cursor 里装完没反应？看一眼 `alwaysApply: false`
有一类问题特别耗人：脚本跑完了，没报错，你以为装好了，回到编辑器里却什么都没变。agency-agents 装进 Cursor 就属于这一类。这篇把排查路径拆开写，重点不在”怎么修好”，而在”怎么确认到底是不是这个原因”——因为同一个”没反应”，背后至少有五六种完全不同的成因，修错方向只会浪费更多时间。
先说结论所在的位置：scripts/convert.sh 里 Cursor 那个转换器的 frontmatter 模板，alwaysApply 和 globs 两个值是写死的，写死成了不自动生效的那一档。
一、现象：文件像是装了，行为上像是没装
典型描述是这样的：跑了仓库的安装脚本，指定了 Cursor，命令行没有报错退出；回到编辑器里干活，agent 的人设、口吻、那些”Critical Rules”一条也没体现出来，跟没装的时候没有区别。
这里要先把一件事讲清楚：agency-agents 这个仓库本质上是一批带 YAML frontmatter 的 markdown 文件，一个 agent 一个 .md。它自己不负责”让 agent 生效”，它负责的是把这批 markdown 转换成各家工具认识的格式，再拷进对应的配置目录。链路是三段：
源 agent markdown → scripts/convert.sh 渲染成各工具格式 → integrations/ → scripts/install.sh 拷到目标目录
也就是说，“装完没反应”这句话里，可能断在三段中的任何一段，也可能三段都没断、断在工具自己那一侧。所以第一件事不是改配置，是定位断点。
二、怎么确认是这个问题：两个可执行的判定动作
判定动作 1：先用 --dry-run 把计划打出来
install.sh 的行为参数里有 --dry-run，语义是只打印计划、不写任何东西。它是这个仓库对新手最有价值的一个开关——在往共享配置目录写一大堆文件之前，先看一眼到底打算写到哪儿。
./scripts/install.sh --tool cursor --dry-run
--tool <a,b> 是选择器，只装列出的这些工具；--dry-run 属于行为参数。两者可以组合，选择器留空则等于全装。（以上为按官方参数语义组合的示例，未逐项实测，以官方文档与 ./scripts/install.sh --help 的实际输出为准。）
看这一步是想确认：脚本认不认得 cursor 这个工具，以及它打算把文件写到哪个路径。
判定动作 2：去落点目录里把 .mdc 文件打开
tools.json 里 Cursor 这一条的信息是：kebab 名 cursor，format 是 cursor-mdc，installKind 是 per-agent，用户级目标路径模板 .cursor/rules/{slug}.mdc。install.sh 的注释里对 Cursor 写的落点是当前目录的 .cursor/rules/。
per-agent 的含义是每个 agent 渲染出一个文件，所以你要找的是一个个以 slug 命名的 .mdc，而不是一个合并文件。打开其中任意一个，看头部的 frontmatter。如果看到的是下面这个形状，那么本文说的就是你遇到的问题：
---
description: ${description}
globs: ""
alwaysApply: false
---
${body}
这是 convert.sh 里 cursor-mdc 转换器的模板原样：三个字段，description 取自源 agent 的 frontmatter，globs 是空串，alwaysApply 是 false。
三、源码语义给出的处置
alwaysApply: false 与 globs: "" 这两行是模板里写死的，不是某次转换的偶然结果，也不是某个参数没传对。它的直接后果是：转换出来的 Cursor 规则默认不会自动生效，需要在 Cursor 里按需引用。
所以处置方向只有两条，且都不在仓库脚本这一侧：
一是按 Cursor 自身对 .mdc 规则的引用方式手动引用它。 具体怎么引用属于 Cursor 自己的规则机制，以 Cursor 官方文档为准，本文不展开——我们没有在 Cursor 里装过任何 agent，不描述界面和操作。
二是修改那两个字段的值。 但改之前要想清楚改在哪一头。install.sh 是把 integrations/ 里已转换的产物拷贝到目标目录的；integrations/ 是产物目录不是源目录。你直接改目标目录里的 .mdc，改的是拷贝出来的那一份。脚本另外提供了 --link 模式，用符号链接代替拷贝，其语义是改动会自动传播——用不用这个模式，决定了你手上这份文件和上游是什么关系。
顺带提一句 --no-convert：install.sh 默认会在集成文件缺失时自动调用 convert.sh，--no-convert 关掉这个自动调用。如果你带了这个参数而 integrations/ 恰好是缺的或者过期的，那就不是本文这个问题了，见第五节。
四、处置后怎么验证
不描述编辑器里的表现，只验证我们有依据验证的部分：
- 文件存在性：落点目录下有没有以你要的 slug 命名的
.mdc文件。slug 不能凭印象写，install.sh有--list [tools|teams|agents]参数，列出后退出，用它核对确切的 slug 拼写。 - frontmatter 三行：
description是不是非空、globs与alwaysApply是不是你处置后期望的值。 - 目录 scope 对不对：Cursor 的落点是当前目录，不是家目录。你在哪个目录下执行的脚本，文件就落在哪个项目里。
- 计划与结果一致：再跑一次
--dry-run，把它打印的计划和你实际看到的文件对一遍。
第 3 条是最容易翻车的。install.sh 注释里列的落点，opencode、cursor、aider、windsurf 这四个写的是”当前目录”，其余多为家目录。这个差别决定了你是给某个项目装还是给整个账户装。另外，tools.json 里还有 dest.project 一类的项目级模板，用户级和项目级不是一回事，要断言某个具体路径请回源文件按当前 scope 现查，不要类推。
五、什么情况说明不是这个原因
这一节是排查文章相对”报错大全”的真正增量。以下五种情况，你看到的都是”装完没反应”，但根因不在 alwaysApply 上：
1）落点目录里压根没有 .mdc 文件。 那说明断在更前面：可能是 --dry-run 只打印没落盘，可能是带了 --no-convert 而 integrations/ 缺失或过期，也可能是选择器把 Cursor 排除掉了。这时候该查的是安装计划，不是 frontmatter。
2）文件落在了别的目录。 install.sh 会在硬编码默认值之前检查一批环境变量，Cursor 对应的是 CURSOR_RULES_DIR。如果这个变量在你的 shell 里有值，落点就被改走了。另外 --path <dir> 也能覆盖安装目录（单一目标）。查一下有没有人在团队的初始化脚本里设过这些变量。
3）你要找的 slug 不存在。 --agent <slug,slug> 传了拼错或者不存在的 slug，选择器自然选不到东西。仓库里带 frontmatter 的 agent markdown 共 255 个，分布在 17 个 division；仓库 markdown 文件总数比这个大，多出来的是 README、strategy/ 下的编排文档、examples/ 等非 agent 文件，别拿总数去对账。用 --list agents 或 --division <a,b> 缩小范围再核。
4）你实际用的不是 Cursor，而是 roster 或 plugin 类的工具。 tools.json 把 installKind 定义为安装机制，一共三种：per-agent 每个 agent 一个文件或一个目录；roster 是所有 agent 合并成一个文件，Aider 的 CONVENTIONS.md 和 Windsurf 的 .windsurfrules 属于这一类；plugin 是构建出来的产物，不能按 agent 渲染成字符串，在所有消费方都只能走 CLI，Hermes 是唯一一个。如果你在 Aider 那边找 {slug}.md 却找不到，那不是装失败，是产物形态本来就不是一 agent 一文件。
5）文件在、字段也按你的意愿改了、依然没有你期望的行为。 那就走出了这个仓库的边界。仓库自带的 lint-agents.sh 检查的是结构（frontmatter 必填 name / description / color、推荐章节、正文有没有实质内容），check-agent-originality.sh 检查的是与已有花名册的重复度（默认阈值 ORIGINALITY_FAIL=40、ORIGINALITY_WARN=20，源码注释给出的库内校准值是最差约 1.5%、中位数 0%）。这些都是结构与重复度层面的质量门，它们不评估提示词好不好用，也管不到编辑器怎么加载规则。这一步之后该去查的是 Cursor 侧的规则机制，或者这个 agent 的提示词本身是否适合你的场景。
六、顺带一句：别一上来就全装
裸调用 install.sh 等于把所有 team 装到所有检测到的工具；在 TTY 下默认会进交互向导。给一个共享配置目录一次性铺进两百多份产物是有代价的——上下文占用、工具启动时的加载、命名冲突都在其中，具体影响多大我们没有测过，不给数字。建议用 --division 或 --agent 收窄，配合 --dry-run 先看计划。
这个仓库在 2026-08-09 的快照里 star 数为 140729，关注度确实高，但这跟它适不适配你的项目是两件事，别用星数替代自己的判断。仓库标注为 MIT，许可条款请以官方 LICENSE 原文为准。
平台方面，脚本注释写明支持 Linux、macOS（需要 bash 3.2+）、Windows 的 Git Bash / WSL。Windows 用户别在 PowerShell 或 cmd 里直接跑 .sh，先进 Git Bash 或 WSL；顺带注意行尾，仓库标准是 LF，lint-agents.sh 的第 0 道检查就是拒绝 CRLF——源码注释解释过原因：行尾多一个 \r 会让后面的 frontmatter 检查报出令人困惑的”missing frontmatter ---“，明明文件开头就是 ---。
延伸阅读
本文依据 agency-agents 官方仓库（github.com/msitarzewski/agency-agents）的 README、tools.json、divisions.json、scripts/ 下的安装与校验脚本整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装或运行过其中任何 agent。目录、脚本与安装路径随上游更新而变动，请以仓库最新内容与 ./scripts/install.sh --help 的实际输出为准。
许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。