别再只给 Agent 下命令：用“任务合同”解决假完成、乱补全和失控执行

Agent 最危险的时刻，不是它说“我做不到”，而是它明明没做完，却告诉你“任务已完成”。

你让它调研 10 款主流 AI 产品。几分钟后，一张整齐的表格出现了：产品名称、价格、功能、适合人群，看起来一项不少。

可真正开始复核时，问题才暴露出来：

有些来源链接已经失效；
有些价格没有标注套餐和计费单位；
有些产品信息来自过期页面；
有些字段根本找不到官方依据，却被 Agent 用“合理推测”补齐；
最后还附上一句：“以上信息均已核实。”

这类问题不只是模型能力不足，更常见的原因是：我们只告诉了 Agent 要做什么，却没有定义什么才算完成。

如果一个任务没有验收标准、证据要求和退出机制，那么 Agent 很容易把“生成了一份看起来完整的答案”理解为“完成了任务”。

真正可靠的 Agent Prompt，应该是一份任务合同：

可靠任务 Prompt = 任务目标 + 验收标准 + 证据留存 + 失败退出 + 人工接管 + 固定交付格式

普通聊天 Prompt 追求的是“回答得像不像”；Agent Prompt 要解决的则是另外一组问题：执行过程能否检查、最终结果能否复核、出现异常后能否安全停下。

一、先定义“什么叫完成”，再让 Agent 开始工作

“帮我认真一点”“尽量保证准确”“完成后检查一下”，这些要求对人类尚且模糊，对 Agent 更接近一句没有约束力的口号。

有效的验收标准，至少要具备三个特征：

具体：明确要交付什么；
可观察：能够从结果中直接看到；
可判定：可以归类为通过、未通过或无法验证。

例如，不要只写：

信息尽量准确，完成后自行检查。

应该改成：

每条关键结论至少提供一个可访问来源；价格信息必须标注查询日期、套餐名称与计费单位；无法从官方页面核实的字段标记为“待确认”，不得自行补全。

这样一来，“准确”就不再是一种主观感受，而变成了一组可以逐项打勾的条件。

1. 数量验收

数量验收回答的是：究竟要交付多少内容？

例如：

必须调研 10 款产品；
每款产品至少记录一个官方来源；
至少列出 3 项主要功能；
输出一份结果表和一份异常清单。

需要注意，数量要求不能凌驾于真实性之上。正确的规则应该是：

目标数量为 10 条；若只能核实 8 条，则交付 8 条已核实结果，并说明另外 2 条未完成的原因，禁止编造内容凑数。

2. 字段验收

字段验收用于防止 Agent 交出“看起来有表格，实际上缺关键列”的结果。

以产品调研为例，每条记录可以要求包含：

官网名称；
产品定位；
套餐名称；
套餐价格；
计费单位；
查询日期；
主要功能；
适合用户；
来源链接；
验证状态。

只要缺少必填字段，就不能直接标记为完成。

3. 质量验收

质量验收关注来源、时效性和可验证程度，例如：

价格优先采用官网定价页；
关键结论不得只引用搜索结果摘要；
每个价格必须标注查询日期；
第三方来源必须注明，并与官方来源区分；
无法交叉验证的信息标记为“待确认”；
推测内容不得写成确定事实。

4. 格式验收

如果结果还要进入程序、数据库或下一条自动化流程，格式要求尤其重要。

你可以指定：

面向人类阅读时使用 Markdown 表格；
面向程序读取时返回合法 JSON；
字段名称固定，不得自行改名；
缺失值使用 null，不要用“暂无”“不知道”等多个版本；
状态值只能是 completed、partial、blocked 或 failed。

更重要的是，不能只要求 Agent 在末尾写一句“已检查无误”，而要让它逐项输出：

通过
未通过
无法验证

一句“已检查”只是声明，一张验收表才是检查。

二、不要只要结论，还要让 Agent 交付“证据包”

Agent 很擅长生成语气笃定、结构完整的结论，但“说得像真的”与“能够被复核”是两回事。

最小证据单元可以包含六项内容：

1. 结论

2. 来源或文件位置

3. 获取时间

4. 原始摘录或工具返回值

5. 可信度

6. 异常说明

例如，Agent 写“某产品专业套餐按月计费”时，不应只交付这句话，还要绑定对应的官方定价页、页面中的原始文字以及查询时间。

不同任务需要保留的证据也不同。

搜索调研任务

建议保留：

页面 URL；
页面标题；
页面发布日期或更新时间，如页面可见；
查询时间；
支撑结论的原文摘录；
页面是否需要登录或存在地区限制。

数据处理任务

建议保留：

输入文件名和版本；
原始行数与输出行数；
删除、合并或转换规则；
异常记录；
无法解析的数据行。

代码任务

建议保留：

运行环境；
执行命令；
测试用例；
测试结果；
报错日志；
修改过的文件路径。

文件和网页操作任务

建议保留：

生成文件路径；
文件大小、版本或哈希；
关键页面状态；
涉及提交、发布或订单操作时的确认编号；
必要的关键步骤截图。

不过，证据留存也不是把 Agent 的每一步“思考过程”全部保存下来。那会制造大量噪声，增加调用和复核成本。

优先保存三类证据即可：

直接影响最终结论的证据；
涉及付款、删除、发布等不可逆操作的证据；
未来可能产生争议的证据。

三、不会停下来的 Agent，才是真正的风险

很多 Prompt 只描述成功路径：打开网页、收集数据、生成报告。

但真实世界充满异常：网页打不开、验证码出现、账号权限不足、接口连续报错、文件格式不符合预期。假如没有退出规则，Agent 可能反复尝试，甚至为了完成目标而换用不可靠来源。

因此，任务合同中必须明确失败退出条件，例如：

连续失败达到 3 次；
遇到登录、验证码或权限限制；
关键数据无法验证；
预计执行时间超过上限；
预计调用成本超过预算；
操作涉及付款、删除、发布或覆盖原文件；
继续执行可能造成重复下单、重复发送或数据损坏。

失败退出不是承认 Agent 不够聪明，而是在自动化流程外面加上一道保险丝。

其中，高风险操作不能依靠一句含糊的“谨慎执行”。应当明确规定：执行付款、删除、发布、批量发送等操作之前，必须暂停并获得人工确认。

“暂停”和“失败”不是一回事

暂停或阻塞 blocked：问题可以恢复，但需要账号、验证码、权限或人类决策；
失败 failed：任务在当前条件下无法继续，或者已经触发不可恢复错误；
部分完成 partial：已经交付一部分有效结果，但未满足全部验收标准。

无论是哪一种状态，都不能为了让结果看起来完整，把“8/10”写成“10/10”。

一份合格的人工接管输出

任务状态：BLOCKED

当前进度：已完成 8/10 条

阻塞原因：
剩余 2 条价格信息仅登录后可见，公开页面无法验证。

已尝试：
1. 官网价格页
2. 官方帮助中心
3. 官方公开文档

未继续原因：
任务规则禁止绕过登录限制，也禁止采用无法验证的第三方价格。

需要人工决定：
A. 提供具备访问权限的账号后继续
B. 接受这 2 条标记为“待确认”
C. 将最终样本数量调整为 8 条

暂停期间禁止执行：
使用非官方价格填补缺失字段
注册或登录新账号
将推测价格写入正式结果

这段输出没有“强行成功”，却比一张虚构完整的表格更可靠。

可靠的 Agent 不一定永远成功，但必须诚实地失败。

四、Agent 任务的正确流程

下面这张流程图展示了一个相对完整的 Agent 执行闭环：

flowchart TD
A[接收任务目标] --> B[检查输入与权限]
B --> C{输入是否完整}
C -- 否 --> H[生成接管包并暂停]
C -- 是 --> D[执行任务]
D --> R{是否涉及高风险操作}
R -- 是 --> H
R -- 否 --> E[留存关键证据]
E --> F[逐项对照验收标准]
F --> G{是否全部通过}
G -- 是 --> I[正式交付结果]
G -- 否 --> J{问题是否可以重试}
J -- 否 --> H
J -- 是 --> K{是否达到失败阈值}
K -- 否 --> D
K -- 是 --> H

这里最关键的变化，是在“执行”与“交付”之间增加了验收关卡；在高风险操作和异常状态前增加了人工接管。

Agent 不应该从开始到结束都完全自治。自治程度越高，越需要明确中止点。

五、从一句命令，升级成一份任务合同

改写前

帮我调研 10 款主流 AI 产品，整理价格和主要功能。

这个版本的问题不是太短，而是缺少可执行边界：

“主流”由谁判断？
价格采用官网还是第三方文章？
按月、按年和按量计费如何区分？
找不到价格时怎么办？
链接打不开是否可以换来源？
完成 8 款后能否用推测凑够 10 款？
什么状态才可以宣布完成？

改写后

调研 10 款符合范围要求的 AI 产品。每款必须包含官网名称、产品定位、套餐价格、计费单位、查询日期、主要功能、适合用户和来源链接。价格与关键功能优先引用官方页面；无法核实时标记为“待确认”，不得自行补全。遇到登录墙、验证码或地区限制时停止该条目的继续执行，并将其加入待人工确认列表。最终输出结果表、证据表、验收检查表以及未完成项说明。

Prompt 并不是单纯变长了，而是从一句愿望变成了可执行规范。

单次案例应该怎样复盘

在没有经过多轮、跨模型测试前，不应声称任务合同一定能降低多少字段缺失率或节省多少复核时间。更稳妥的做法，是把它标注为单次案例或小样本测试，并按以下维度记录实际差异：

这样得到的数据才属于你的真实测试结果，而不是为了证明模板有效而预设结论。

六、可直接复制的通用 Agent 任务合同

# 角色与任务目标

你需要完成：[具体任务]

任务的最终用途是：[用途]

任务范围：
[包含内容 1]
[包含内容 2]

排除范围：
[不包含内容 1]
[不包含内容 2]

输入与约束

可使用的输入：
[文件、网址或数据]

允许使用的工具：
[工具列表]

执行限制：
时间上限：[时间]
预算上限：[预算]
最大调用或重试次数：[次数]

禁止执行：
未经确认进行付款、删除、发布或覆盖操作
猜测补全无法验证的信息
绕过登录、验证码、权限或地区限制
隐藏失败或将未完成标记为完成

验收标准

只有同时满足以下条件，任务才算完成：

1. 数量标准：[必须交付多少条或多少项]
2. 字段标准：[每条必须包含哪些字段]
3. 来源标准：[哪些结论必须提供来源]
4. 时效标准：[查询日期或数据时间范围]
5. 完整性标准：[缺失值如何处理]
6. 格式标准：[Markdown、JSON或指定结构]

每项验收结果必须标记为：
通过
未通过
无法验证

不得只输出“已检查无误”。

证据留存

对于每条关键结论，必须记录：

结论
来源 URL、文件位置或工具名称
获取时间
原始摘录或工具返回值
可信度
异常说明

优先保留影响最终结论、涉及不可逆操作或可能产生争议的证据。

失败退出

出现以下任一情况时，停止继续执行：

连续失败达到 [N] 次
遇到登录、验证码、权限或地区限制
关键数据无法验证
预计超出成本或时间上限
操作涉及付款、删除、发布或其他不可逆风险
继续操作可能造成重复执行

不得为了满足数量要求而编造、推测或隐藏失败。

人工接管

需要人工处理时，请输出：

1. 当前任务状态
2. 当前进度
3. 已完成内容
4. 已尝试的方法
5. 失败原因与证据
6. 可选解决方案
7. 需要我做出的决定
8. 暂停期间禁止继续执行的动作

输出后暂停并等待确认，不得自行继续。

最终交付格式

A. 任务结果
B. 证据清单
C. 验收检查表
D. 未完成项与原因
E. 风险及后续建议

七、填好即可使用的竞品调研实战版

# 角色与任务目标

你是一名产品研究助手，需要调研 [10] 款符合要求的 [AI 产品]。

任务的最终用途是：[竞品分析与产品选型]。

任务范围：
产品类型：[填写具体范围]
目标市场：[中国市场/全球市场]
信息范围：产品定位、公开套餐价格、主要功能和适合用户

排除范围：
已停止维护的产品
无法确认官网身份的产品
只有第三方介绍、没有可靠官方信息的产品

输入与约束

优先使用：
1. 产品官网
2. 官方定价页面
3. 官方帮助中心与公开文档
4. 官方公告

禁止使用：
无法确认时间与来源的转载内容
搜索摘要代替原始页面
推测价格或功能
绕过登录、验证码与地区限制

最大连续失败次数：[3] 次。

涉及登录、注册、付款或提交信息时，必须暂停并请求人工确认。

验收标准

每款产品必须包含：

1. 官网名称
2. 官网 URL
3. 产品定位
4. 套餐名称
5. 套餐价格
6. 计费单位
7. 查询日期
8. 主要功能
9. 适合用户
10. 来源链接
11. 验证状态

关键价格和功能至少提供一个官方来源。

无法核实的字段填写“待确认”，不得自行补全。

只有 [10] 款产品全部满足必填字段与来源要求时，状态才可标记为 completed。

若只有部分产品通过验收，应标记为 partial 或 blocked。

证据留存

每条关键结论记录：

对应产品
结论
官方来源
查询时间
原文摘录
可信度
异常说明

最终交付

依次输出：

A. 产品结果表
B. 证据清单
C. 验收检查表
D. 待确认项目
E. 风险与建议

适合程序读取的 JSON 结构

{
"status": "completed | partial | blocked | failed",
"results": [
{
"product_name": "",
"official_url": "",
"positioning": "",
"plan_name": "",
"price": null,
"billing_unit": "",
"checked_at": "",
"main_features": [],
"target_users": [],
"source_urls": [],
"verification_status": "verified | pending | unavailable"
}
],
"evidence": [
{
"result_id": "",
"claim": "",
"source": "",
"retrieved_at": "",
"original_excerpt": "",
"confidence": "high | medium | low",
"exception": null
}
],
"acceptance_checks": [
{
"item": "",
"condition": "",
"status": "passed | failed | unverifiable",
"evidence_location": "",
"failure_reason": null
}
],
"unresolved_items": [],
"handoff_required": false,
"handoff_request": null
}

八、发布前 30 秒检查表

下面这张表可以直接截图保存，每次提交 Agent 任务前快速检查：

提交之前，再问自己五个问题：

是否定义了什么叫完成？
是否要求关键结论附带证据？
是否限制了重试次数和执行成本？
是否规定了高风险操作必须人工确认？
是否设计了阻塞后的接管格式？

如果其中任何一项答案是否定的，这份 Prompt 就还只是一条命令，而不是任务合同。

把模板交给不同模型，重点测试“守不守规矩”

复制模板后，不要只测试一次。

你可以把同一份任务合同交给不同模型，重点比较三件事：

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

2. 是否真实保留证据，而不是只给结论；

3. 遇到阻塞时，是否会按规则停止。

如果你正在通过 API 搭建自己的 Agent 工作流，可以前往 api.884819.xyz，将返回格式固定为 JSON，再由程序自动判断 completed、partial、blocked 或 failed。

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

新用户注册即送体验token。

你现在可以做三件事：

复制 Agent 任务合同模板
前往 api.884819.xyz 测试
用同一任务对比不同模型的执行结果

好的 Agent Prompt，不是逼 AI 无论如何交出答案，而是让它知道什么叫完成、拿什么证明完成，以及什么时候必须停下来叫人。

当然，让 Agent 知道什么时候退出，只解决了一半问题。

下一篇我们继续拆解更容易被忽视的一环：Agent 失败后到底该不该自动重试？为什么一句“再试一次”，可能造成重复下单、重复发消息和 API 费用失控？届时会给出一套可直接复用的“重试次数＋退避策略＋幂等保护＋成本熔断”模板。

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#Agent #AI教程 #Prompt技巧 #人工智能 #工作流自动化 #8848AI #AI学习