什么是Cursor CLI Agent
Cursor CLI Agent 是一个把编码任务交给命令行代理执行的工具，核心入口是 `agent` 命令。它面向的并不是单纯的问答，而是更接近“在终端里让代理实际做事”：既可以让它创建新功能、搭建小型应用，也可以用于重构已有模块、分析代码库结构，或在只读模式下审查变更。证据包显示，它支持多种前沿模型，包括 GPT-5、Claude Opus/Sonnet、Gemini、Grok 等，使用者可以根据任务复杂度与偏好切换模型。
这个工具的一个关键前提，是它本质上属于交互式终端程序，必须在 PTY 模式下运行，否则命令可能直接挂起。这一点决定了它和普通一次性 shell 命令的使用方式不同：要么在指定工作目录中交互执行，要么把长任务放到后台，再通过进程管理能力查看日志、轮询状态、补发输入或直接终止。证据包里反复强调 `workdir + background + pty` 的组合，说明它的设计重点不仅是“能生成代码”，还包括如何在真实开发流程中稳定地运行较长时间任务。
从执行方式看，Cursor CLI Agent 提供了几种很不同的工作模式。默认是交互式模式，适合边执行边观察；`–yolo` 或 `–force` 用于自动批准操作，追求速度，但风险更高；`–plan` 则只给出计划、不改文件，适合先评估再动手；`–mode ask` 更像只做解释和问答。比较特别的是 `–print` 非交互模式，它可以把结果直接输出到控制台，还支持 JSON 和流式 JSON 格式，这使它不只是一名“终端里的编程助手”，也能作为脚本、自动化任务和 CI/CD 流程中的一个可解析组件来使用。
核心功能特点
- 通过 `agent` 命令执行编码、重构、代码分析等任务，可按需选择 GPT-5、Claude、Gemini、Grok 等模型。
- 依赖 PTY 运行，适合在真实终端会话中交互工作；长任务可切到后台，并用会话日志、轮询和输入提交方式持续跟进。
- 支持多种执行模式：默认交互式、自动批准的 `–yolo`、只读规划的 `–plan`、仅问答的 `–mode ask`。
- 提供 `–print` 非交互输出，可直接生成控制台结果、JSON 或流式 JSON，便于脚本解析和接入 CI/CD。
- 可限定工作目录，减少读取无关文件；还能配合 git worktree 在隔离分支环境中并行处理多个独立任务。
适用场景
如果团队主要把它当成“开发代理”来用，最直接的场景就是新功能开发和较大规模重构。比如在某个明确的项目目录里，让代理搭一个小应用、补一项功能、改造认证模块，或者先让它分析代码库结构，再决定是否进入执行阶段。对于时间较长、步骤较多的任务，后台运行尤其有意义：主线程不用一直阻塞，开发者可以通过会话管理查看实时输出，只在需要确认或补充指令时再介入。这种模式比较适合把重复性高、上下文相对明确的工程工作外包给命令行代理。
另一类很实用的场景是代码审查，尤其是 PR review。证据包明确建议在临时目录中检出待审 PR，再以 `–plan` 只读模式运行审查，这样既避免误改文件，也把分析范围限制在当前审核对象上。对于需要同时处理多个 PR 的团队，它还可以并行启动多个后台代理，分别审查不同变更，再由人工汇总意见并回写到协作平台。这种做法更像是把代理当成“批量代码阅读器”和“初步问题发现器”，适合在安全检查、代码质量筛查、差异比对这类任务上节省时间。
它也适合进入自动化流水线和脚本场景。`–print` 模式让代理不再依赖完整交互界面，而是把输出直接交给控制台或结构化 JSON，这对于需要机器继续处理结果的流程很关键。比如在 CI/CD 中生成代码库摘要、列出接口、输出可解析的分析结果，或者在批量任务里统一调用代理能力。再进一步，如果项目需要并行修复多个问题，还可以配合 git worktree 为每个任务建立隔离工作树，各自启动独立代理处理，再分别跟踪进度。对需要同时推进多个独立事项的团队来说，这种隔离并行的方式比在同一工作区里混合操作更可控。