别再让 Agent“假装完成”：一套可验收、可追溯、会退出的任务契约 Prompt

“任务已完成，所有内容均已检查无误。”

这可能是 Agent 最让人放松警惕，也最危险的一句话。

检查了什么？依据是什么？哪些步骤真正执行成功了？如果它没有访问权限，为什么没有停下来？如果资料互相冲突，它凭什么给出确定结论？

很多人遇到 Agent 敷衍、幻觉和反复返工，第一反应是模型能力不够，或者自己的 Prompt 写得不够长。于是继续补背景、加要求、塞案例，最后把指令写成一堵文字墙。

但真正缺失的，往往不是更多任务描述，而是一份明确的任务契约：

• 怎样才算完成；
• 拿什么证明完成；
• 无法完成时，应该怎样安全退出。

Agent 最重要的能力，不只是完成任务，还包括证明自己完成了，以及承认自己无法完成。

为什么“完成任务”是一个危险指令

假设你给 Agent 的指令只有一句：

帮我完成竞品调研并给出结论。

它可能搜索几个结果，读两段产品介绍，然后输出：

任务已完成。

综合来看，产品A功能最全面，产品B价格更有优势，
产品C更适合中小团队。

这段话看起来完整，甚至像一份结论明确的报告。但你无法回答以下问题：

• 它到底研究了几个竞品？
• 价格来自官网、媒体文章，还是搜索摘要？
• 信息是否仍然有效？
• 不同来源出现冲突时，它采用了哪一个？
• 有没有无法确认的字段？
• “更适合中小团队”的判断依据是什么？

问题不一定出在模型不会搜索，而在于你把“完成”的判定权完全交给了执行者。

“做过”不等于“做完”

更可靠的指令应该是这样：

调研5款同类AI工具，分别整理产品定位、核心功能、价格模式、
适用人群、官网地址和信息来源。

每款产品至少检查官网信息；涉及价格和功能限制时，尽量使用第二个
独立来源进行交叉验证。

只使用近期仍可访问的信息。无法确认的字段标记为“待核实”，
不得根据常识补全。

只有5款产品全部完成字段检查，并附上来源链接后，才能标记为SUCCESS。

此时，“完成”不再是一种语气，而是一组可以检查的条件。

理想输出也会从一句“已完成”，变成：

STATUS: PARTIAL

已收集5款产品，其中4款字段完整。
产品C的企业版价格仅提供“联系销售”，无法确认具体金额。

验收结果：
样本数量达到5款：PASS
每款包含6个指定字段：PASS
价格信息完成交叉验证：FAIL
所有结论附带来源：PASS

前一种输出听起来更自信，后一种输出却更可信。因为它把不确定性暴露出来了。

当 Agent 同时扮演执行者和验收者，它很容易把“我执行过”误判成“任务已完成”。

配图1：模糊 Prompt 下，Agent 没有展示来源或检查记录，却直接宣布“任务已完成”。截图应框出完成声明和证据缺失区域，账号及内部信息需打码。

一套可复用的任务契约：验收、证据、退出

可靠的 Agent Prompt，至少要有三个互相约束的模块。

1. 验收标准：定义什么叫完成

好的验收标准应该具备三个特点：

• 能观察：结果是否存在，可以直接看到；
• 能计数：数量、字段和步骤可以核对；
• 能判定：可以明确返回 PASS 或 FAIL。

例如：

• 差：“调研要尽量全面。”
• 好：“至少收集5个有效样本，每个样本包含6个指定字段。”

• 差：“认真检查代码。”
• 好：“运行指定单元测试，退出码为0，且既有接口签名不变。”

• 差：“文章质量要高。”
• 好：“正文包含标题、摘要、三级以内的小标题、引用来源和待确认事项。”

验收标准的意义，是把“感觉不错”改造成“条件满足”。

2. 证据留存：让结论能够被追溯

只有验收标准还不够。Agent 仍然可能口头声称“全部满足”。

因此，每一项关键验收结果，都要绑定证据。证据可以是：

• 来源链接；
• 文件路径；
• 截图编号；
• 工具返回结果；
• 测试命令与退出码；
• 变更文件列表；
• 关键 diff；
• 校验值或操作日志。

证据不是越多越好，而是要和验收标准一一对应。否则 Agent 可能生成大量日志，却仍然无法证明核心任务是否完成。

例如，代码 Agent 说“测试已通过”没有意义；下面这种表达才可验证：

验收标准：现有单元测试全部通过
结果：PASS
证据：
命令：pytest tests/test_user_api.py
退出码：0
日志：artifacts/test-user-api.log

3. 失败退出：允许 Agent 诚实地停下来

很多 Prompt 只规定成功时做什么，却没有告诉 Agent 失败时怎么办。

当 Agent 遇到权限不足、资料缺失、接口异常时，如果没有退出机制，它通常会走向两个极端：

• 不断重试，持续消耗时间、Token 或调用费用；
• 在证据不足时自行猜测，生成一个看似完整的答案。

因此需要预先规定 Exit Conditions：

• 缺少必要输入或访问权限；
• 信息来源冲突且无法交叉验证；
• 连续指定次数尝试仍未通过验收；
• 继续操作可能造成不可逆影响；
• 达到时间、Token 或费用上限。

三部分缺一不可：

• 只有验收，没有证据，Agent 可能口头宣布达标；
• 只有证据，没有验收，Agent 可能堆积无用日志；
• 没有退出机制，Agent 可能无限重试或冒险继续。

一份可以直接复制的任务契约 Prompt

下面这份模板适合资料调研、代码修改、文件处理、内容发布和多步骤自动化任务。

你是负责执行任务的 Agent。请完成以下任务，但不要仅根据“是否执行过”
来判断完成，必须严格按照验收标准进行自检。

【任务目标】
{{需要完成的任务}}

【可用输入与资源】
{{输入资料}}
{{允许使用的工具}}
{{可访问的范围}}

【执行边界】
不得：{{禁止行为}}
未经确认不得：{{高风险操作}}
最大尝试次数：{{N}}
时间或成本上限：{{限制}}

【验收标准】
只有同时满足以下条件，任务才可标记为 SUCCESS：
1. {{可观察、可验证的条件 1}}
2. {{可观察、可验证的条件 2}}
3. {{数量、格式、准确性或完整性要求}}
4. {{必须通过的最终检查}}

【证据留存】
对每项验收标准提供对应证据，包括：
证据类型：来源链接 / 文件路径 / 截图编号 / 工具返回结果 / 校验值
关键内容摘要
证据与验收标准的对应关系

不得使用“已完成”“确认无误”等主观表述代替证据。

【失败退出条件】
出现以下任一情况时停止继续执行：
缺少必要输入或访问权限
信息来源相互冲突，且无法完成交叉验证
连续 {{N}} 次尝试仍未通过验收
继续操作可能产生不可逆影响
已达到时间、Token 或费用上限

退出时不要伪造结果，返回 BLOCKED 或 FAILED，并说明：
1. 卡在哪一步
2. 已完成哪些尝试
3. 保留了哪些证据
4. 还缺什么条件
5. 建议由用户采取的下一步

【最终输出格式】
STATUS: SUCCESS / PARTIAL / BLOCKED / FAILED

SUMMARY:
{{结果摘要}}

ACCEPTANCE_CHECK:
标准 1：PASS / FAIL；证据：{{...}}
标准 2：PASS / FAIL；证据：{{...}}

ARTIFACTS:
{{文件、链接、日志或其他交付物}}

RISKS_AND_GAPS:
{{未解决的问题}}

NEXT_ACTION:
{{建议下一步}}

其中四种状态需要提前约定清楚：

• SUCCESS：所有强制验收标准均通过；
• PARTIAL：交付了部分有效结果，但仍有明确缺口；
• BLOCKED：受到权限、输入或环境限制，当前无法继续；
• FAILED：已经执行，但在限制范围内无法通过验收。

配图2：加入任务契约后，Agent 逐项返回 PASS/FAIL，并为每一项附上来源或工具结果。重点框出状态、验收结果和证据三部分。

三个典型任务，看看改写后有什么不同

案例一：调研5款AI工具

#### 原始 Prompt

帮我调研5款AI工具，做一个对比。

#### Agent 可能犯的错

它可能把搜索摘要当作正式来源，遗漏价格模式，或者为了填满表格而猜测没有公开的信息。最终虽然交付了5行内容，但没有一行可以稳定复核。

#### 改写后的 Prompt

调研5款AI工具，整理以下字段：
产品名称、官网、核心功能、价格模式、适用人群、信息来源。

验收要求：
1. 必须包含5个有效产品；
2. 每款产品的6个字段必须逐项检查；
3. 核心功能与价格优先使用官网来源；
4. 关键结论尽量由第二个独立来源交叉验证；
5. 无法确认的信息标记为“待核实”，不得猜测补全；
6. 输出表格，并在表格后列出来源和冲突项。

只有全部要求通过时才能返回SUCCESS。

#### 输出结果

Agent 不再被迫维持“每个格子都有答案”的假象。若某款产品没有公开价格，它可以标记待核实，并返回 PARTIAL。这不是能力下降，而是可信度提升。

案例二：让代码 Agent 修复接口报错

#### 原始 Prompt

修复用户接口的报错。

#### Agent 可能犯的错

它可能修改接口参数、引入不必要的依赖，甚至删除失败的测试用例，让测试表面上变绿。

#### 改写后的 Prompt

修复用户接口报错。

验收标准：
1. 指定单元测试全部通过；
2. 接口路径、请求参数和返回字段签名不变；
3. 不新增高危依赖；
4. 输出根因、变更文件列表和关键diff；
5. 提供测试命令、测试日志与退出码。

禁止行为：
不得删除、跳过或弱化现有测试；
不得修改无关模块；
未经确认不得执行线上部署。

退出条件：
连续两次修改仍未通过测试；
缺少依赖、运行环境或必要权限时，返回BLOCKED。

#### 输出结果

一个合格的结果不只是“Bug 修好了”，而应包含：

STATUS: SUCCESS

ACCEPTANCE_CHECK:
单元测试通过：PASS
  证据：pytest tests/test_user_api.py，退出码0
接口签名不变：PASS
  证据：关键diff未修改路由及响应结构
无新增高危依赖：PASS
  证据：依赖文件无变更

ARTIFACTS:
src/api/user.py
artifacts/test-user-api.log

如果缺少运行环境，则应该返回 BLOCKED，而不是声称“理论上可以运行”。

案例三：生成并发布文章

#### 原始 Prompt

写一篇文章并发布出去。

#### Agent 可能犯的错

最危险的地方在于，“生成内容”和“对外发布”被混成了一个动作。接口短暂超时后，它还可能重复请求，造成同一篇文章发布多次。

#### 改写后的 Prompt

根据资料生成文章草稿，并完成发布前检查。

默认只生成草稿，不得直接发布。

验收标准：
1. 草稿包含标题、摘要、正文和来源；
2. 完成敏感信息与链接检查；
3. 生成发布预览；
4. 用户明确确认预览后，才能进入发布阶段。

禁止行为：
未经确认不得调用正式发布接口；
接口状态不明确时不得重复发布；
不得保存或输出账号密钥。

退出条件：
缺少发布授权；
预览检查未通过；
发布接口返回异常或结果状态不明确。

#### 输出结果

这里最重要的不是文案质量，而是把任务拆成两个阶段：

1. 可逆阶段：生成、检查、预览；

2. 不可逆阶段：发布、发送、删除或修改线上配置。

“准备完成”不等于“执行完成”。任何不可逆操作，都应该设置独立的人工确认点。

用 JSON 把任务契约接入 API 和工作流

如果你需要让程序继续处理 Agent 的结果，建议使用固定 JSON，而不是依赖自然语言判断。

成功结果可以这样返回：

{
"status": "SUCCESS",
"summary": "任务结果摘要",
"acceptance_check": [
{
"criterion": "至少收集5个有效样本",
"result": "PASS",
"evidence": ["artifacts/research.csv"]
}
],
"artifacts": [
{
"type": "file",
"path": "artifacts/research.csv"
}
],
"risks_and_gaps": [],
"next_action": "无需进一步操作"
}

遇到权限不足时，则应返回：

{
"status": "BLOCKED",
"summary": "已完成文章草稿和发布前检查，但缺少正式发布授权",
"acceptance_check": [
{
"criterion": "生成完整文章草稿",
"result": "PASS",
"evidence": ["artifacts/article-draft.md"]
},
{
"criterion": "文章成功发布",
"result": "FAIL",
"evidence": ["发布接口未获得授权，未发起正式请求"]
}
],
"artifacts": [
{
"type": "file",
"path": "artifacts/article-draft.md"
}
],
"risks_and_gaps": [
"缺少正式发布权限",
"尚未获得用户对预览内容的确认"
],
"next_action": "请用户确认预览并提供发布授权"
}

配图3：在 API 调试界面中，对不同模型运行同一组“原始 Prompt”和“任务契约 Prompt”。只比较状态遵守、证据完整度和格式合规性，不应凭少量测试包装成普遍排名。

配图4：并排展示 SUCCESS 与 BLOCKED 的 JSON 响应，框出 status、evidence、risks_and_gaps 和 next_action。敏感路径、密钥及账号信息必须打码。

日常轻任务，不需要每次复制完整版

完整版模板适合代码修改、付费调用、外部发布和多步骤 Agent。普通任务可以压缩成下面这版：

请完成：{{任务}}

完成条件：
1. {{可验证条件1}}
2. {{可验证条件2}}
3. {{交付格式要求}}

请为关键结论附上来源或验证结果。
无法确认的内容标记为“待核实”，不要猜测。

如果缺少输入、权限或连续两次尝试仍失败，请停止并返回：
当前状态：PARTIAL / BLOCKED / FAILED
已完成内容
失败原因
所需补充条件
建议下一步

判断是否启用完整版，可以看任务有没有这些特征：

• 会修改文件或代码；
• 会调用付费 API；
• 会发送邮件或消息；
• 会发布公开内容；
• 会删除数据；
• 会修改线上配置；
• 失败后可能产生不可逆后果。

风险越高，任务契约就应该越完整。

下发任务前的30秒检查表

在点击运行之前，快速检查这6个问题：

• 完成是否有客观判定条件？
• 每个关键结果是否有对应证据？
• Agent 是否知道哪些操作不能做？
• 遇到阻塞时，它会停止还是自行猜测？
• 是否设置了尝试次数、费用或时间上限？
• 输出能否区分成功、部分完成、阻塞与失败？

如果其中三项以上答不上来，就不要急着让 Agent 开始执行。先花几十秒补全任务契约，通常比事后反复追问“你真的做了吗”更省时间。

你还可以打开 api.884819.xyz，用平台内置的 AI 对话功能，分别运行文中的原始指令和任务契约版 Prompt，观察不同模型是否真的遵守 SUCCESS / PARTIAL / BLOCKED / FAILED，以及能否为结论提供对应证据。

平台注册只需用户名和密码，无需邮箱验证，没有月租和订阅，按量付费；Deepseek、千问等国产模型可免费使用。新用户注册即送体验token。

测试时不要急着评价哪一个模型“更聪明”，先看三个更实际的指标：

1. 是否严格执行验收标准；

2. 是否用证据支撑完成声明；

3. 无法完成时是否愿意诚实退出。

不要只让 Agent 交答案，还要让它交验收结果、证据链，以及无法完成时的诚实退出。

写清“怎样算完成”，只能阻止 Agent 草率交差；但如果它拥有删除文件、发送邮件、发布内容或持续调用付费 API 的权限，仅靠 Prompt 仍然不够。

下一篇我们将继续拆解：怎样给 Agent 设置权限边界、预算上限、人工确认点和可回滚机制，把“失败退出”升级成真正的安全护栏。

#Agent #Prompt技巧 #AI教程 #人工智能 #AI工作流 #大模型 #8848AI