Sourcegraph Amp CLI 命令速查表 - 终端 AI 编码代理全参数
多数人用终端 AI 代理的方式是开一个前台会话，从头聊到尾：跑到一半忘了自己要干什么，上下文越堆越脏。Sourcegraph Amp 的设计正对着这个痛点——用线程把不同任务隔开，长活可以扔后台继续跑，前台留着回答下一个一次性问题。这张表按安装与认证、单次提问、线程管理、后台与集成、实用技巧分组，讲清线程怎么开、怎么续、amp 与 amp -x 该按什么意图选。判断依据是任务形态：一问就走就用单次执行不必建线程；要迭代、要回看历史改动才值得开线程；耗时长、会阻塞交互的一律后台化。什么时候翻它：一边让 Agent 跑长任务一边继续干别的、CI 里要无头调用做批量巡检、或者需要把输出接进脚本做质量门禁。跟常驻前台会话的代理相比，多付一点管理线程的成本，换来的是上下文不被污染。
安装与认证 5
npm install -g @sourcegraph/ampamp --versionamp loginamp logoutexport AMP_API_KEY=...单次提问 5
amp "重构 user-auth 使用新 session API"amp -x "列出本项目所有 TODO 注释"amp --model claude-opus "写解析 CSV 的函数"amp --no-streamamp --help线程管理 5
amp threadsamp threads newamp threads continue <id>amp threads listamp --resume后台与集成 5
amp -x "跑测试套件" & --json "..."amp --cwd /path/to/repo "..."AMP_API_KEY=... amp -x "..."amp --verbose实用技巧 5
amp -x 偏执行、amp 偏对话threads 分主题隔离上下文CI 用 AMP_API_KEY 跑 -x--json 接脚本处理--model 按需切底层命令示例
一次性提问，带初始提示直接开工
amp "Refactor user-auth to use the new session API"这种一次就走完的活不必建线程。需要在目录之外操作时用 amp --cwd /path/to/repo "..." 明确工作目录。
把耗时的测试套件丢后台
amp -x "run the test suite" &执行模式 + 后台化，终端立刻可用。运行期间去开一个独立线程做别的事，别在同一线程里交替。
让输出可被脚本解析
amp --json "Find unused exports"按事件类型分支判断状态，比只取最后一条文本稳。需要 CI 无头执行时，前面加 AMP_API_KEY=...。
回到之前那个线程继续未完的工作
amp threads continue <id>ID 从 amp threads list 拿；只想要列表、方便脚本消费就用 amp threads list，交互式浏览则用 amp threads。
常见坑与注意事项
- AMP_API_KEY 是可用的凭据，export 到 CI 环境里容易随日志泄出；用平台的 secret 变量注入，别 echo，也不要写进仓库里的配置文件。
- 同一线程里交替处理两个需求会造成上下文互相污染，且事后无法复盘哪段改动属于哪个任务；并行任务一律 amp threads new 各开一个。
- 无头任务直接进 CI 常常因为缺凭据或工作目录不对而白跑一轮；先在本地交互式跑一次同样的提示词确认能通。
- amp --cwd 指错目录会让代理读到另一个仓库甚至大范围改文件；执行前确认路径，再看一次工作区状态。
- --json 输出是事件流而不是单个 JSON 文档，只取最后一条当结果会误判状态；CI 里无头跑之前留 git status 干净，因为代理会改文件。
提示
- Sourcegraph Amp 是 Sourcegraph 出品的终端编码代理，底层可接多种模型；
amp偏对话、amp -x偏执行，按意图选模式。 - 线程（threads）机制可把不同任务上下文隔离开，避免一个长对话污染另一个任务——复杂项目里尤其有用。
- CI/无头环境用
AMP_API_KEY配合amp -x跑自动化，不必依赖交互登录态。 --json输出便于接脚本做程序化解析（如质量门禁、批量巡检）。- 并行任务务必各开一个线程，同一线程里交替处理两个需求，上下文会互相污染到无法复盘。
- 无头跑之前先本地交互确认一次提示词与权限配置，直接进 CI 常因缺凭据而白跑一轮。
- 把 amp 的 JSON 输出接进脚本时，按事件类型做分支而不是只取最后一条文本，能拿到更稳的状态判定。
常见问题
amp 和 amp -x 该怎么选？
amp 偏对话：带着提示进去，倾向讨论方案和写代码。amp -x 偏执行：同样接提示，但更倾向直接动手改文件、跑命令。前者适合要来回确认的题，后者适合需求已经说清楚的活。判断依据是任务形态，不是命令长短。
为什么要给每个任务单开一个线程？
因为线程是上下文边界。amp threads new 开一个新线程，amp threads continue 加 ID 续接旧线程，amp --resume 回到最近一次。两个需求交替塞进同一个线程，代理会把两个任务的文件、约定、甚至结论混在一起，等到需要复盘时已经分不清哪段改动属于谁。
CI 或者没有登录态的环境里怎么跑？
用 export AMP_API_KEY=... 提供 Key，然后走 amp -x 执行模式做无头任务，这样不依赖交互式登录态。更稳的做法是无头之前先在本地交互跑一遍同样的提示词，确认权限配置和凭据都齐了再进 CI。
amp --json 到底解决了什么问题？
它把输出变成结构化事件流，好让脚本按事件类型分支，而不是正则去抠文本。典型用法是拿它做质量门禁或批量巡检：判断某类事件是否出现、统计工具调用次数、确认任务是否正常结束，而不是只取最后一段文字。
耗时长、会阻塞交互的任务怎么处理？
加 & 丢到后台：amp -x "run the test suite" &。这样终端立刻回来，你可以另开线程处理下一个问题，跑完再回来看结果。工具调用过程想看得更细，加上 --verbose 打印逐轮执行详情。
由 巧匠 维护
公开更新于 2026年8月23日，内容持续校对官方文档。