Warp Agentic Terminal 教程：从仓库规则、代码修改到人工审批与云端任务

这篇教程会完成什么

这篇教程不会追求“一句话生成整个应用”。目标是建立一个可以长期复用的 Warp 工作流：让 Agent 先读项目规则，再处理一个边界清楚的小任务；命令和文件修改保持可见；测试失败时停止；最后由人审查 Diff 并决定是否提交。

完成后你会得到：

• 一套适用于 macOS、Windows 或 Linux 的基础设置。
• 一个写清楚范围、验证命令和禁止事项的仓库规则。
• 一次从计划、修改、测试到 Review 的完整任务。
• 一份决定哪些任务可以交给云端 Agent 的检查清单。
• 一个记录 credits、返工和审查时间的成本方法。

开始前需要准备

选择一个非生产、可本地运行、已有 Git 和测试的仓库。最好创建独立练习分支，并保证工作区没有不明来源的改动。

任务应控制在 30 到 60 分钟内，例如：

• 修复一个已有复现步骤的 Bug。
• 给一个纯函数补边界检查和单元测试。
• 替换一个已弃用 API，但不升级整个依赖树。
• 为现有命令增加参数校验和错误提示。

不要从数据库迁移、身份认证、支付、云资源或生产部署开始。这些任务的外部副作用太大，不适合第一次测试 Agent 权限。

同时记录基线：当前测试结果、分支名、未提交文件和预期改动范围。若仓库包含客户数据、私钥或生产配置，先移除或改用干净副本。

第一步：安装 Warp 并确认平台限制

Warp 支持 macOS、Windows 和 Linux。可从官网下载，macOS 也可使用 Homebrew，Windows 可使用 WinGet，Linux 提供常见发行版包与 AppImage。

安装后先把 Warp 当普通终端使用，确认：

1. 默认 Shell、PATH 和包管理器正确。
2. Git 身份、SSH Agent 和凭据来源符合预期。
3. 项目启动、测试和格式化命令在 Warp 中能正常运行。
4. 在 Windows 上确认使用 PowerShell、WSL 或 Git Bash 的具体路径。
5. 在远程或 SSH 场景中确认文件树、代码编辑和索引功能是否可用。

不要在第一天导入所有 Shell 配置。先使用最小配置，排除主题、插件和启动脚本带来的干扰。

第二步：先配置隐私、数据和成本

打开 Warp 设置，检查隐私、遥测、云端会话和代码库索引。团队管理员还应查看数据控制、Agent 自主等级、目录和命令策略。

建议初始配置：

• 只索引练习仓库，不自动索引新目录。
• 关闭不需要的遥测或内容收集。
• 不上传包含客户信息、凭据或受限代码的仓库。
• 把 Agent 自主等级设为每次敏感操作都询问。
• 暂时禁用自动充值，先观察一个计费周期。
• 为云端会话设置保留和删除规则。

Warp 的免费版可体验核心终端、Agent CLI 和有限云端能力。Build 提供更多 credits 和完整 Agent 使用，额外用量仍可能按量计费。开始前记下当前 credits，任务结束后再记录一次，建立真实成本基线。

第三步：写清仓库规则

Agent 不会自动知道团队约束。可以在仓库中维护 AGENTS.md 或 Warp Rules，至少写清以下内容：

## Scope
- Only edit src/parser.ts and tests/parser.test.ts
- Do not change public API names
- Do not add dependencies

## Validation
- npm test -- parser
- npm run typecheck
- npm run lint

## Safety
- Do not access network services
- Do not read .env or credential files
- Ask before deleting or moving files
- Stop after two failed implementation attempts

规则要具体到文件、命令和停止条件。“遵循最佳实践”无法代替明确约束。若项目有格式化、生成代码、迁移或快照更新，也要说明哪些可以自动运行、哪些需要人工批准。

把规则提交到仓库前先由团队 Review。错误规则会稳定地产生错误结果。

第四步：让 Agent 先调查，不要立即修改

在 Warp 中进入仓库，先给只读任务：

阅读项目规则和与解析器相关的实现。复现失败测试，解释根因，并给出最多五步的修复计划。暂时不要修改文件，也不要安装依赖。列出你需要的任何假设。

检查 Agent 是否：

• 读取了正确的规则和文件。
• 使用了允许的只读命令。
• 能复现问题，而不是猜测根因。
• 计划中的文件与任务范围一致。
• 明确说出没有验证的部分。

如果计划偏离范围，立即纠正。不要期待 Agent 在错误前提下执行后能自行恢复。

第五步：批准最小修改和验证命令

确认计划后，要求 Agent 只完成第一版最小修复：

按已确认计划实施最小改动，只编辑允许的两个文件。先补失败测试，再修改实现。完成后依次运行指定测试、类型检查和 Lint。任何命令连续失败两次就停止并说明原因。不要提交、推送或访问网络。

逐项检查命令。以下操作建议始终手动批准：

• 安装或升级依赖。
• 删除、移动或批量覆盖文件。
• 运行来自网络的脚本。
• 修改 Git 历史或推送远程。
• 访问数据库、云账户或生产服务。
• 读取 .env、SSH Key、Token 或浏览器凭据。

如果 Agent 请求超出范围的权限，先让它解释必要性，并寻找更小的替代方案。

第六步：审查 Diff，而不是只看总结

任务结束后打开 Warp 的文件树和 Diff Review。按以下顺序审查：

1. 范围：是否只修改允许的文件。
2. 行为：测试是否覆盖原问题和边界情况。
3. 接口：是否意外改变公开 API、错误类型或返回结构。
4. 复杂度：是否引入重复逻辑、过度抽象或无关重构。
5. 安全：是否拼接命令、泄露敏感信息或扩大权限。
6. 验证：测试、类型检查和 Lint 是否真的运行成功。

不要只接受 Agent 的“测试已通过”文字。查看实际命令与退出状态；必要时在新终端中独立重跑。

对不满意的局部修改，优先要求解释或手动调整。连续多轮让 Agent 重写同一区域，可能增加上下文噪声和 credits 消耗。

第七步：提交前做人工门禁

确认结果后再由人决定是否提交。推荐提交说明包含：

• 问题与根因。
• 修改范围。
• 执行的验证命令。
• 未覆盖的风险。
• 是否使用 AI Agent，以及人工审查人。

Warp 可以帮助准备提交或 PR，但不要在第一次流程中授予自动推送、自动合并或部署权限。先证明 Review、回滚和审计都可靠，再逐步增加自治。

第八步：什么时候使用 Warp Agent CLI

Warp Agent CLI 适合你已经有偏好的终端、需要 SSH、在容器中工作，或希望把 Agent 加入脚本化流程的场景。

CLI 任务仍应携带相同规则、目录限制和验证命令。非交互运行要额外设置最大时长、失败退出、结构化日志和预算上限。不要把个人长期 API Key 直接写在命令历史或配置文件中。

第九步：什么时候交给云端 Agent

适合云端的任务通常满足四个条件：

• 输入和验收标准清楚。
• 能在隔离环境中构建和测试。
• 不需要生产凭据或实时人工判断。
• 失败不会产生外部副作用。

例如依赖更新草稿、测试补全、静态分析、Issue 分诊和初步 PR Review。生产部署、数据修复和紧急事故操作不应默认无人值守。

配置云端环境时指定固定 Docker 镜像、仓库、Setup Commands 和秘密管理。限制出站网络，使用短期 Token，并为任务设置停止条件。运行完成后检查日志、Diff、测试和资源使用。

第十步：安全接入 MCP 与外部工具

MCP 能让 Agent 访问 GitHub、Linear、Sentry 等系统，但每增加一个 Server 都扩大权限边界。

接入前逐项确认：

• MCP Server 的发布者和更新来源。
• 可调用的工具及其读写范围。
• Token 是否最小权限、可撤销且有过期时间。
• 云端运行时秘密如何注入，是否进入日志。
• 写操作是否要求单独批准。
• 如何查看审计记录并立即停用。

先以只读工具开始。只有当团队能稳定检查任务输出时，才开放创建 Issue、更新 PR 或触发部署等写操作。

常见错误

Agent 一开始就大范围重构

原因通常是任务边界模糊。改成指定文件、禁止无关重构，并要求先给计划。

测试一直失败仍继续消耗 credits

设置失败次数和停止条件。两次相同失败后要求总结阻塞点，由人决定是否继续。

代码索引包含不该上传的内容

关闭自动索引，使用排除规则和独立干净仓库。敏感代码应遵循组织的数据分类和合同要求。

云端任务找不到依赖

把环境写成可复现配置：固定基础镜像、安装步骤、运行时版本和缓存策略。避免依赖个人电脑的隐式状态。

Diff 很大但功能变化很小

要求最小改动，禁止格式化无关文件。把重构与 Bug 修复拆成不同 PR。

什么时候应该换别的工具

如果你只需要纯 CLI，并且主要使用 Claude，Claude Code 可能更轻。团队已经使用 ChatGPT/Codex 且经常委派云端开发任务，可以比较 OpenAI Codex。希望免费、开源并接入 Google 生态，可测试 Gemini CLI。只想在 VS Code 中逐步批准模型调用，则可看 Cline。

不要因为 Warp 功能多就全部启用。最适合的配置，是保留团队真正能审查和维护的那一部分。

最终检查清单

• 仓库和分支是隔离的。
• Rules 明确范围、验证和停止条件。
• 没有向 Agent 暴露生产密钥。
• 每个敏感命令都经过人工确认。
• 测试输出和退出状态已独立检查。
• 最终 Diff 已由人逐文件审查。
• credits、重跑次数和审查时间已记录。
• 云端或 MCP 写权限只在必要时开放。

完成一次小任务后，再重复三到五次。只有当失败模式、成本和审查时间都可预测时，才把 Warp 扩展到更多仓库或自动化入口。