GitHub Actions 与 CI

CI 需要 shell 执行能力、可用的 Cursor API Key，以及到 Cursor API 的网络连接。先让 CLI 完成分析或文件生成，再由明确的流程步骤处理提交与发布。

密钥与安装

在仓库 Settings > Secrets and variables > Actions 添加 CURSOR_API_KEY，再映射到任务环境。以下片段展示官方 GitHub Actions 页的安装和调用方式：

- name: Install Cursor CLI
  run: |
    curl https://cursor.com/install -fsS | bash
    echo "$HOME/.cursor/bin" >> $GITHUB_PATH

- name: Run Cursor Agent
  env:
    CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
  run: |
    agent -p "Explain the project structure"

此处是 steps 片段，需要放入已有 workflow；执行前应已准备好目标仓库。Windows runner 的安装使用 irm 'https://cursor.com/install?win32=true' | iex。

官方 CI 示例把 ~/.cursor/bin 加入 PATH，而通用安装页写的是 ~/.local/bin。两页不一致，实际 runner 应检查安装输出及 agent --version；找不到命令时按实际安装目录修正 PATH，而不要假定两者始终相同。

限制 Agent 的职责

官方推荐生产 CI 采用权限限制。项目 .cursor/cli.json 可按任务设置：

{
  "permissions": {
    "allow": ["Read(**/*.md)", "Write(docs/**/*)", "Shell(grep)", "Shell(find)"],
    "deny": ["Shell(git)", "Shell(gh)", "Write(.env*)", "Write(package.json)"]
  }
}

提示中也可说明只修改文档，但提示本身不替代权限。Git 分支、commit、push 和 PR 评论由独立 workflow 步骤实现，便于检查授权和失败处理。

判断是否完成

检查 CLI 退出码、输出和实际 diff，执行项目校验后再进入后续步骤。打印模式能够使用写入工具；--force 会自动允许未被显式拒绝的操作，应只在配置与任务范围明确时使用。结构化结果见输出格式。