Agent 成功完成一次任务，证明的是“这次能做”，不是“下次也能做”。对于准备接入业务流程的开发者，这个区别决定了系统能否从演示走向生产：偶尔生成正确答案，与持续执行正确操作，是两种不同的工程能力。
提供的来源只有标题，没有正文摘要。因此，下面围绕标题提出的可靠性问题展开工程实践，不推断原文采用了什么实验、指标或工具。
一次成功，可能掩盖哪些问题？
假设一个 Agent 的任务是查询订单、判断退款条件，然后提交退款申请。一次成功的执行路径可能十分顺畅：订单唯一、接口及时返回、退款规则没有歧义。
但真实请求还会遇到：
- 同一客户有多个相似订单，Agent 选错目标。
- 查询接口超时，Agent 在没有拿到结果时继续操作。
- 工具已经成功执行，但响应丢失，Agent 再次提交。
- 模型输出措辞变化，解析器无法识别结果。
这些问题不一定体现在最终回答里。一个回答“退款已提交”的 Agent，可能实际上没有提交，也可能提交了两次。
因此，评估对象不能只有文字答案，还应该包括工具调用、参数、执行结果和最终业务状态。
把“做对”写成可以检查的契约
可以这样实践：在运行评估前，为每种任务定义成功条件和禁止行为。
| 任务 | 成功条件 | 禁止行为 |
|---|---|---|
| 查询订单 | 返回正确订单的状态 | 泄露其他客户的信息 |
| 提交退款 | 对符合条件的订单创建一次申请 | 重复提交或绕过审批 |
| 修改配置 | 目标配置符合要求且校验通过 | 修改无关配置 |
这里需要区分两个维度：
结果是否正确：任务有没有完成？
过程是否合规：是否违反权限、执行了额外写操作，或消耗了不可接受的时间和费用？
Agent 通过反复重试最终完成任务，不代表这条执行路径适合生产环境。对于有副作用的工具，重试必须与幂等机制一起设计，不能把“再试一次”当成默认补救措施。
可以这样实践：先做一个重复运行测试
下面是一个只依赖 Python 标准库的最小评估脚本。它使用一个故意偶发出错的模拟 Agent，演示如何记录重复成功率和错误类型。
假设说明：这不是任何产品的真实 API，也不是对来源实验的复现。接入自己的系统时，替换 run_agent()，并让它返回可验证的执行结果。示例中的期望值只供评估器使用，不传给 Agent。
将代码保存为 repeat_eval.py，使用 Python 3 运行：
import json
import random
from collections import Counter
TASKS = [
{"id": "a", "input": {"a": 7, "b": 5}, "expected": 12},
{"id": "b", "input": {"a": 20, "b": 3}, "expected": 23},
]
REPEATS = 20
rng = random.Random(42)
def run_agent(payload):
"""模拟 Agent；替换为自己的调用逻辑。"""
if rng.random() < 0.15:
raise TimeoutError("tool timeout")
result = payload["a"] + payload["b"]
if rng.random() < 0.10:
result += 1
return {"result": result}
records = []
for task in TASKS:
for trial in range(REPEATS):
try:
output = run_agent(dict(task["input"]))
ok = output.get("result") == task["expected"]
error = None if ok else "wrong_result"
except Exception as exc:
ok = False
error = type(exc).__name__
records.append({
"task_id": task["id"],
"trial": trial,
"ok": ok,
"error": error,
})
with open("runs.jsonl", "w", encoding="utf-8") as file:
for record in records:
file.write(json.dumps(record, ensure_ascii=False) + "\n")
for task in TASKS:
runs = [r for r in records if r["task_id"] == task["id"]]
successes = sum(r["ok"] for r in runs)
errors = Counter(r["error"] for r in runs if not r["ok"])
print(
f"{task['id']}: {successes}/{len(runs)} passed; "
f"all_passed={successes == len(runs)}; "
f"errors={dict(errors)}"
)
运行命令：
python3 repeat_eval.py
这里同时输出两个观察角度：
- 单次成功比例：用于观察总体表现和版本变化。
- 本轮是否全部成功：用于发现某个任务是否存在间歇性失败。
“本轮全部成功”只是这批样本的描述，不是未来不会失败的保证。二十次重复也只是演示规模，不能直接作为生产验收标准。
真实评估还应该记录模型版本、提示词版本、工具版本、耗时和成本。不要为了方便排查，把访问令牌或客户敏感数据直接写进日志。
重复测试之外，还要改变运行条件
同一输入跑很多遍，可以暴露部分随机波动，但不能覆盖真实环境中的变化。可以逐步加入三组测试：
- 表达变化：保持业务目标不变，改变用户措辞、信息顺序和上下文长度。
- 工具异常：注入超时、限流、空结果以及“执行成功但响应丢失”。
- 状态变化：让目标对象在执行期间发生变化，检查 Agent 是否重新确认前提。
对写操作，应使用沙箱或可重置的测试环境。重复运行退款、发邮件或删除资源的任务，本身就可能产生损害；评估系统也必须具备隔离和清理能力。
上线门槛应该跟失败代价绑定
不要给所有 Agent 设同一个成功率目标。文案草稿出错可以人工修正，资金操作出错则可能需要审计和追责。
上线前可以检查：
- 成功条件是否由独立评估逻辑判断，而不是让 Agent 自己宣布成功？
- 是否区分了错误结果、工具故障和违规操作？
- 写操作是否具备权限限制、幂等保护和必要的人工确认？
- 每次模型、提示词或工具升级后，是否重跑相同测试集？
- 失败时能否安全停止，而不是继续猜测和执行？
一次成功适合展示能力，重复评估才开始回答可靠性问题。真正值得上线的 Agent，不只是能完成任务，还要让团队知道它在什么条件下会失败，以及失败时如何把影响限制住。