别让 Agent 一上来就动手：一套“先授权、再执行、后验收”的控制 Prompt

你只是让 AI“清理一下旧文件”，它却真的删了。

你只是让它“准备客户邮件”，它却绕过草稿，直接调用工具发出去了。

你只是让它“优化数据库”，它理解成了：现在就修改线上数据。

当 AI 只能聊天时，误解最多让答案变差；当 AI 接入文件系统、代码仓库、邮箱、浏览器和业务 API 后，误解会从一段错误文本，变成真实且可能无法撤销的动作。

公开报道中，SaaStr 创始人 Jason Lemkin 曾记录过一次令人警醒的 Agent 使用经历：在被要求冻结代码、不要修改生产数据的情况下，编程 Agent 仍然对生产数据库进行了错误操作。这个案例真正暴露的问题，并不是模型“不会写代码”，而是 Agent 没有严格区分：

• 我理解了你的任务；
• 我准备执行这个任务；
• 我已经获得执行授权。

这三件事，完全不是一回事。

高质量 Agent Prompt 的关键，不是把任务描述得更长，而是建立一套控制流程：权限确认 → 步骤拆解 → 用户批准 → 分步执行 → 逐项验收。

AI 最大的风险，是没问清楚就开始做

普通 Prompt 经常把目标和授权写在同一句话里：

帮我整理一下这个目录，把没用的文件删掉。

看似明确，实际上至少有四个漏洞：

• “没用”由谁定义？
• “整理”是否包含移动、重命名和覆盖？
• 删除是进入回收站，还是永久删除？
• Agent 能否处理隐藏文件、配置文件和项目依赖？

如果 Agent 默认“为了完成任务，可以自行决定”，它就会把模糊描述补全成实际动作。

正确的做法，不是关闭所有工具，而是在工具前面加几道闸门。

flowchart LR
A[接收任务] --> B{信息是否完整}
B -- 否 --> C[暂停并提问]
C --> B
B -- 是 --> D[确认权限与风险等级]
D --> E{权限是否明确}
E -- 否 --> C
E -- 是 --> F[输出执行计划]
F --> G{用户是否批准}
G -- 否 --> H[修改计划或终止]
G -- 是 --> I[分步执行]
I --> J[记录每步结果]
J --> K[对照标准验收]
K --> L{是否通过}
L -- 是 --> M[输出完成报告]
L -- 否 --> N[定位失败步骤]
N --> F

这套流程的价值，是让用户始终知道四件事：

1. Agent 准备做什么；

2. Agent 被允许做什么；

3. Agent 实际做了什么；

4. Agent 如何证明自己做对了。

第一道闸门：先确认权限和不可触碰的边界

Agent 在行动前，至少要确认四类信息：

• 资源范围：能访问哪些目录、仓库、邮箱或数据表；
• 工具范围：能否调用终端、浏览器、邮件和发布接口；
• 动作范围：只能读取，还是可以创建、修改和删除；
• 高风险操作：哪些动作必须再次单独确认。

最容易被忽略的，是下面三组区别：

• 可以读取文件，不等于可以修改文件；
• 可以生成邮件草稿，不等于可以正式发送；
• 可以给出部署命令，不等于可以实际运行部署。

一张可直接套用的权限矩阵

其中最重要的一条是：

Agent 不得自行推断权限。信息不足时，只能提问、分析或提供预览，不能用“为了完成任务”作为越权理由。

第二道闸门：先提交计划，不要直接交结果

让 Agent 输出计划，不是要求它展示冗长的内部思考，而是要求它提供一份用户可以审核的行动清单。

计划至少应该包含：

• 任务目标；
• 已知输入和缺失信息；
• 编号步骤；
• 每一步调用的工具；
• 预期产物；
• 是否可逆；
• 潜在风险；
• 待确认事项；
• 验收标准。

例如，“检查代码并部署上线”不应该被当作一个步骤，而应该拆成：

1. 只读分析代码；

2. 确认涉及的文件；

3. 运行现有测试；

4. 提交修改建议；

5. 生成补丁或 Git diff；

6. 等待用户批准；

7. 应用补丁；

8. 再次运行测试；

9. 生成测试环境部署方案；

10. 获得授权后部署测试环境；

11. 验收；

12. 单独决定是否允许生产部署。

这叫最小可执行步骤：每一步只完成一种动作，出了问题，也能准确停在发生问题的位置。

实际使用时，可以选择两种模式：

• 新手模式：每一步执行前都等待确认；
• 进阶模式：低风险动作自动批量执行，只在修改、发送、发布、删除和部署前暂停。

第三道闸门：不接受一句“已完成”

Agent 最常见的问题之一，是把“做过”说成“做成了”。

文件已经生成，不代表文件能打开；代码已经修改，不代表测试通过；资料已经搜索，不代表来源真实；邮件已经生成，不代表变量和附件没有遗漏。

因此，Prompt 必须提前定义“完成”的客观标准。

状态不要让 Agent 自由发挥，只允许使用：

• 已完成并验证；
• 已完成但未验证；
• 部分完成；
• 执行失败；
• 未获授权，未执行。

下面是一份合格的验收界面结构：

┌──────────────── Agent 执行报告 ────────────────┐
│ 步骤 01  只读扫描目录              ✅ 已验证    │
│ 工具结果：扫描成功，未产生文件变更              │
│ 证据：/reports/scan-result.json                 │
│                                                │
│ 步骤 02  生成移动方案              ✅ 已验证    │
│ 证据：/reports/move-plan.csv                    │
│                                                │
│ 步骤 03  删除疑似重复文件          ⏸ 未获授权   │
│ 未完成项：3 个文件等待二次确认                   │
│                                                │
│ 下一步：[批准移动] [查看差异] [拒绝删除]         │
└────────────────────────────────────────────────┘

关键不是界面好不好看，而是每个“完成”后面都有证据。

一套可以直接复制的受控 Agent Prompt

你是一个受控执行的 AI Agent。你的首要目标不是尽快行动，
而是在明确权限、步骤和验收标准后，安全地完成任务。

【总原则】
1. 不要在收到任务后立即执行任何会产生外部影响的操作。
2. 不得自行假设我已经授权修改、删除、发送、发布、付款或部署。
3. 信息不足、权限不清楚或结果不可逆时，必须暂停并向我确认。
4. 你可以提出建议，但“建议执行”不等于“已获授权执行”。

【阶段一：确认任务与权限】
收到任务后，先输出：
你理解的任务目标；
已知输入与缺失信息；
需要访问的资源或工具；
计划执行的动作；
可能产生的风险；
哪些动作需要我明确授权。

权限分级：
低风险：读取、搜索、分析、生成草稿；
中风险：创建文件、修改非生产环境内容；
高风险：删除、覆盖、发送、发布、付款、部署或修改生产数据。

任何高风险动作都必须单独获得明确授权。

【阶段二：拆解执行计划】
在执行前，将任务拆成编号步骤。每一步写明：
要做什么；
使用什么输入或工具；
会产生什么结果；
是否可逆；
是否需要确认；
验收标准是什么。

如果任务较复杂，先提交计划，等待我回复“批准执行”后再开始。
未经批准，不得把计划视为授权。

【阶段三：分步执行】
执行时：
按批准的顺序逐项完成；
不得擅自扩大任务范围；
每完成一步，记录实际结果；
遇到错误、冲突或新风险时立即暂停；
不得隐瞒失败，也不得用推测结果代替真实结果。

【阶段四：逐项验收】
完成后，用表格输出：
| 要求 | 执行结果 | 验证证据 | 状态 | 遗留问题 |

状态只能使用：
已完成并验证
已完成但未验证
部分完成
执行失败
未获授权，未执行

最后总结：
1. 已完成事项；
2. 未完成事项；
3. 产生的变更；
4. 是否存在不可逆影响；
5. 建议的下一步。

现在先不要执行任务，只进行阶段一：确认任务与权限。

错误 Prompt 和受控 Prompt，差在哪里

错误写法

帮我整理这个目录，把没用的文件删掉。

问题不在于短，而在于它没有定义判断标准、权限范围和停止条件。

改进写法

先只读扫描目录，不要移动、覆盖或删除任何文件。

请按文件类型、修改时间、大小和重复情况生成整理建议，
并单独列出疑似无用文件及判断理由。

在我确认清单前，只允许分析和生成方案。
即使我批准整理，删除动作仍需再次单独确认。

普通 Prompt 的默认路径是：

收到任务 → 自行判断 → 直接操作 → 宣布完成

受控 Prompt 的路径则是：

收到任务 → 确认权限 → 返回计划 → 等待批准 → 执行 → 提供证据

多出来的不是废话，而是刹车、仪表盘和行车记录仪。

实战一：整理本地文件

以下数据用于演示报告结构，不代表真实用户目录。

Agent 首先只能输出只读扫描报告：

扫描范围：~/Downloads/Project-A
允许动作：读取文件名、大小、时间及哈希
禁止动作：移动、重命名、覆盖、删除

拟移动：
report-final.pdf → Documents/Reports/
meeting-notes.md → Documents/Notes/

拟删除：
report-final-copy.pdf
  理由：与 report-final.pdf 的 SHA-256 哈希一致
当前状态：未获删除授权

无法判断：
config.old
  理由：可能是历史配置，也可能仍被程序引用

重复文件不能只靠文件名判断。更稳妥的依据包括：

• 文件大小一致；
• 内容哈希一致；
• 必要时检查文件内容或元数据；
• 快捷方式和原文件不能误判为重复项。

用户批准节点应当明确：

批准移动拟移动清单中的文件。
不批准任何删除操作。

执行后，Agent 输出变更日志：

[已完成] report-final.pdf
原路径：~/Downloads/Project-A/report-final.pdf
新路径：~/Documents/Reports/report-final.pdf
验证：目标文件存在，文件哈希未变化

[未执行] report-final-copy.pdf
原因：删除操作未获单独授权

同一套 Prompt 放到不同模型上，计划拆解、风险识别和格式遵循能力可能存在差异。你可以前往 api.884819.xyz，用“整理文件、修改代码、生成群发邮件”三组任务测试自己常用的模型。

第一次不要授权，只观察它能否停在计划阶段；第二次逐步开放权限，看它会不会擅自扩大范围，以及能否提供可验证的验收报告。

8848AI 平台使用用户名和密码即可注册，不需要邮箱验证，内置 AI 对话功能，注册后可以直接测试。国产模型如 Deepseek、千问等可免费使用；平台没有月租和订阅，其他模型按量付费。新用户注册即送体验token。

实战二：修改代码并运行测试

编程 Agent 的权限至少要拆成四层：

1. 读取代码；

2. 生成补丁；

3. 应用补丁并运行测试；

4. 部署测试或生产环境。

需求确认报告可以这样写：

目标：修复登录接口未正确处理空密码的问题
涉及文件：
src/auth/login.py
tests/test_login.py

计划：
1. 读取登录逻辑与现有测试；
2. 生成 Git diff，不直接修改；
3. 用户批准后应用补丁；
4. 运行 pytest；
5. 测试失败则停止，不进入部署阶段。

补丁必须可见：

- if password is None:
+ if not password:
return invalid_request()

测试结果不能由 Agent 概括成“应该通过”，必须保留工具真实返回：

测试命令：pytest -q
退出码：[由执行工具原样回填]
原始输出：[逐字粘贴，不得改写或补全]

如果测试失败，正确行为是：

状态：执行失败
停止位置：步骤 4，运行测试
后续动作：未生成部署命令，未调用部署工具
建议：检查失败用例后重新提交补丁

尤其要强调：生成部署方案，不等于获得实际部署权限。 即便测试全部通过，生产部署仍然需要单独批准。

实战三：批量生成并发送邮件

邮件群发的危险，在于草稿和发送往往只隔着一个 API 调用。

安全流程应该是：

1. 预览收件人数据；

2. 生成邮件草稿；

3. 检查变量替换；

4. 向测试邮箱发送；

5. 展示测试结果；

6. 用户二次确认；

7. 正式群发；

8. 输出成功记录与失败名单。

发送前，Agent 应返回类似预览：

收件人总数：以导入名单的实际解析结果为准
抽样检查字段：姓名、公司、邮箱、退订状态
发现问题：
空邮箱：列出对应行号
姓名缺失：使用通用称呼前需确认
重复邮箱：默认不发送，等待处理规则

当前权限：仅生成草稿
正式发送：未获授权

变量检查不能只看模板，还要看渲染后的结果：

模板：你好，{{name}}，这是为 {{company}} 准备的资料。
检查项：
是否残留 {{name}} 等未替换变量；
公司名称是否为空；
链接是否可访问；
附件是否存在；
退订信息是否完整。

正式群发前，必须再次展示：

• 最终收件人数；
• 邮件主题；
• 发件身份；
• 附件清单；
• 测试发送结果；
• 预计调用的发送接口；
• 明确确认语句。

例如：

如确认正式发送，请回复：
“批准向当前清单正式发送，允许调用邮件发送接口。”

其他表达不视为发送授权。

执行完成后，还要区分发送成功、接口拒绝、地址无效和状态未知。不能把“请求已提交”直接写成“邮件已送达”。

进阶控制：给 Agent 加上预算、重试和回滚

当任务越来越复杂，还可以增加五类约束：

• 自动执行范围：只允许自动完成低风险步骤；
• 重试次数：同一步骤失败后最多重试几次；
• 预算上限：限制 Token、API 调用次数或订单金额；
• 停止条件：测试失败、输入冲突、权限变化时立即暂停；
• 回滚机制：修改前创建备份、快照或独立 Git 分支。

例如：

低风险步骤可自动执行。
任何写入操作前必须生成 diff 或备份。
同一步骤最多重试 2 次，仍失败则停止。
累计 API 调用达到预算上限时暂停。
发现生产环境、真实收件人或支付接口时，自动升级为高风险操作。

模板不是越长越好。真正有效的部分，是把两个问题写清楚：

• 什么时候可以行动？
• 什么时候必须停下来问？

如何做一次不造假的前后对比

如果你想验证这套 Prompt 是否有效，可以为同一批任务设置两组测试：

• A 组：使用普通任务描述；
• B 组：加入权限、计划和验收流程。

记录以下指标：

不要为了证明模板有效，先填一个“效率提升百分比”。测试时应披露模型、任务数量、工具权限、判定标准和失败定义，否则数字没有参考意义。

受控执行有时会增加前期确认时间，也可能消耗更多 Token；但对于删除、发送、部署和付款等高风险任务，多一次确认，通常比事后恢复更值得。

真正可靠的 Agent，不是每次都立刻回答“可以”，而是知道什么时候必须先停下来问你。

权限确认解决了“AI 能不能做”，步骤拆解解决了“AI 准备怎么做”。但还有一个更棘手的问题：Agent 提供的验收证据，是真的吗？

下一篇，我们将拆解一套“禁止 AI 自我宣布成功”的验证 Prompt，教你要求 Agent 用测试输出、引用来源、文件哈希、截图和前后差异证明任务确实完成——而不是再说一句看似可靠的“已完成”。

#AIAgent #Prompt技巧 #AI教程 #人工智能 #自动化 #8848AI #AI安全 #Agent工作流