Agent 跑通一次不算交付：用 20 个历史任务测出真实稳定性

“这个 Agent 昨天明明跑通了，为什么今天执行同一个任务，却调用了三次工具，还把同一条消息发了两遍？”

这是 Agent 从演示环境走向真实业务时，最容易出现的错觉。

在 Demo 里，输入完整、接口正常、上下文干净，Agent 像一名表现完美的新员工：理解需求、调用工具、输出结果，一气呵成。

可一旦换个用户表达，或者碰上接口超时、字段缺失、限流，问题就来了：

• 工具选对了，参数却传错；
• 调用失败后不断重试，成本和延迟一起失控；
• 明明缺少关键信息，仍然继续写库、发消息；
• 工具其实没有成功，Agent 却回复“已处理完成”。

判断 Agent 是否能上线，不能靠“多聊几次感觉不错”，而要从真实业务中抽取历史任务，建立一套可重复、可对比、可追责的回放测试。

本文案例和数值均为脱敏后的可复现演示数据，用于说明评测方法，不代表特定模型或平台的真实测试结论。

一、为什么跑通一次几乎说明不了问题

传统软件的大部分行为由确定性代码控制。相同输入、相同环境，通常会得到相同结果。

Agent 不一样。

它的执行过程同时受到模型输出波动、上下文内容、工具返回值、网络状态、提示词版本和采样参数影响。最终答案相似，不代表中间路径相同。

例如，让 Agent“查询客户最近一笔订单并生成摘要”，两次运行可能分别走出这样的路径：

运行 A：
search_customer → get_orders → 生成摘要

运行 B：
get_orders（缺少 customer_id）
→ search_customer
→ get_orders
→ get_orders（重复调用）
→ 生成摘要

第二次最终也可能给出正确答案，但它已经暴露出三个问题：

1. 调用顺序错误；

2. 首次参数不合法；

3. 出现无意义的重复执行。

如果 get_orders 只是读取数据，损失可能只是多花一些 Token 和时间；如果换成 send_message、create_order 或 delete_record，重复调用就可能直接变成业务事故。

所以，Agent 稳定性测试不能只看最终回答，而要同时检查：

• 它选了什么工具；
• 传入了哪些参数；
• 失败后如何重试；
• 何时停止自动执行；
• 是否留下了足够的信息供人工接管。

二、先从历史记录里选出 20 个有效任务

一套最小可用的测试集，不需要一开始就做几百条。对多数团队而言，20 个有代表性的历史任务，已经足以发现第一批关键问题。

但不要只选“表达清楚、接口正常、一次完成”的简单题。那相当于只在晴天测试雨伞。

建议把任务分为四组：

每条任务还要完成三项准备。

1. 脱敏

替换姓名、手机号、订单号、密钥和内部地址，但保留数据结构。例如将真实客户 ID 替换为 customer_demo_001，不要直接删除字段，否则测试难度会发生变化。

2. 固定环境

至少记录：

• 模型与版本；
• 系统提示词版本；
• 工具 schema 版本；
• 知识库快照；
• 温度等随机参数；
• 接口模拟规则。

否则一次改了模型、一次改了提示词、一次又换了工具参数，结果就无法比较。

3. 提前定义通过标准

不要等 Agent 跑完后再凭感觉打分。每条用例应事先写清：

• 允许调用哪些工具；
• 预期关键步骤；
• 哪些行为绝对禁止；
• 最多允许重试几次；
• 什么情况下必须请求人工确认。

三、回放时重点盯住三条链路

1. 工具调用链路

工具调用不能只看“选没选对”，还要看参数、顺序和次数。

下面是一次正常任务的完整 Agent Trace，可作为发布时的脱敏截图样式：

[Case agent_007]
用户输入：查询客户最近一笔订单并生成摘要

01 模型判断：需要先识别客户
02 工具调用：search_customer
参数：{"name":"张某"}
03 工具返回：{"customer_id":"customer_demo_001"}
04 工具调用：get_orders
参数：{"customer_id":"customer_demo_001","limit":1}
05 工具返回：{"order_no":"order_demo_882","status":"已发货","amount":"*"}
06 参数校验：通过
07 最终结果：已输出订单号、状态、金额

重点检查四个问题：

• 工具是否选对；
• 必填参数是否合法；
• 工具顺序是否符合依赖关系；
• 是否发生重复调用或无意义循环。

案例一：工具选对了，参数却错了

search_customer(name="李某") → customer_id="C102"
get_orders(customer_id="李某", start_date="上个月")

• 使用 JSON Schema 校验参数类型；
• 日期必须先转换为明确起止时间；
• 工具调用前检查参数来源；
• 校验失败时不允许直接执行。

2. 失败重试链路

重试不是简单地“再来一次”。

如果接口已经返回 429，Agent 立即连续请求三次，通常不会让限流突然消失，只会继续增加成本和延迟。

一次失败重试的调用链可以这样记录：

send_message → HTTP 429
原因：rate_limit
等待：0 秒
send_message → HTTP 429
等待：0 秒
send_message → HTTP 429
状态：达到重试上限，停止自动执行

案例二：限流后机械重复请求

• 对 429、超时采用指数退避；
• 设置全局重试上限；
• 写操作必须携带幂等键；
• 结果未知时先查询状态，不直接重放。

例如：

for attempt in range(max_retries + 1):
result = run_agent(
test_case,
idempotency_key=test_case["case_id"]
)

if result.success:
break

if not result.retryable:
handoff_to_human(result)
break

3. 人工接管链路

Agent 主动停下来，不一定代表能力差。

在高风险任务中，错误地自动执行，往往比请求人工确认更糟。

案例三：信息不足却继续执行

search_orders(status="重复")
→ 返回 2 条疑似订单
delete_order(order_id="order_demo_103")

• 删除、付款、发送、写库统一设置确认节点；
• 返回多个候选对象时禁止自动选择；
• 接管信息必须包含已完成步骤、候选对象和待确认内容。

人工接管界面应清楚展示：

自动执行已暂停

原因：发现 2 条可能重复的订单，无法安全判断删除对象
已完成：订单查询、重复状态检查
尚未执行：delete_order
需要确认：请指定订单号，并确认是否删除

四、一套最小可用的回放系统怎么搭

完整系统可以很复杂，但最小版本只需要四部分：任务集、执行器、故障注入器和评分器。

1. JSONL 测试用例

{"case_id":"agent_007","input":"查询客户最近一笔订单并生成摘要","allowed_tools":["search_customer","get_orders"],"expected_steps":["search_customer","get_orders"],"forbidden_actions":["update_order","send_message"],"max_retries":2,"requires_confirmation":false,"success_criteria":{"must_include":["订单号","状态","金额"]}}

每行保存一个任务，便于批量执行和版本管理。

2. Python 回放执行器

import json
import time

def replay(path, run_agent, rounds=3):
records = []

with open(path, encoding="utf-8") as f:
cases = [json.loads(line) for line in f]

for case in cases:
for round_id in range(1, rounds + 1):
start = time.perf_counter()
result = run_agent(
case,
idempotency_key=f'{case["case_id"]}:{round_id}'
)

records.append({
"case_id": case["case_id"],
"round": round_id,
"success": result.success,
"first_pass": result.retry_count == 0 and result.success,
"retry_count": result.retry_count,
"tool_calls": result.tool_calls,
"handoff": result.handoff,
"latency_ms": int(
(time.perf_counter() - start) * 1000
),
"cost": result.cost
})

return records

3. 注入超时、429 和空返回

def inject_fault(tool_name, call_index, original_call):
faults = {
("get_orders", 1): "timeout",
("send_message", 1): "429",
("search_customer", 2): "empty"
}

fault = faults.get((tool_name, call_index))

if fault == "timeout":
raise TimeoutError("simulated timeout")
if fault == "429":
return {"ok": False, "status": 429, "retryable": True}
if fault == "empty":
return {"ok": True, "data": []}

return original_call()

故障注入的价值在于：不用等待线上接口真的出问题，也能验证 Agent 会不会安全恢复。

4. 生成 CSV 报告

import csv
import statistics

def export_report(records, output="agent_report.csv"):
latencies = [r["latency_ms"] for r in records]
total = len(records)

summary = {
"runs": total,
"first_success_rate": sum(r["first_pass"] for r in records) / total,
"final_success_rate": sum(r["success"] for r in records) / total,
"avg_retries": sum(r["retry_count"] for r in records) / total,
"handoffs": sum(r["handoff"] for r in records),
"p50_latency_ms": statistics.median(latencies),
"avg_cost": sum(r["cost"] for r in records) / total
}

with open(output, "w", newline="", encoding="utf-8-sig") as f:
writer = csv.DictWriter(f, fieldnames=summary.keys())
writer.writeheader()
writer.writerow(summary)

return summary

不要只跑一轮。建议每个任务至少回放 3 次；预算允许时可运行 5—10 次，观察偶发性错误和输出波动。

整体流程如下：

flowchart LR
A[历史任务输入] --> B[模型判断]
B --> C[工具选择与参数生成]
C --> D[参数与权限校验]
D -->|通过| E[调用工具]
D -->|高风险或信息不足| H[人工接管]
E --> F{执行成功?}
F -->|是| G[校验最终结果]
F -->|可恢复| I[有界重试]
F -->|不可恢复| H
I --> E
G --> J[记录指标与报告]
H --> J

五、不要迷信总分，要看 Agent 如何失败

下面是一份演示用结果总表，假设 20 个任务各运行 5 次，共 100 次回放：

乍看之下，85% 的最终成功率似乎不错。但继续往下看，就会发现两个危险信号：

• 首次成功率只有 60%，说明系统严重依赖重试；
• 出现两次重复执行，如果对应消息、订单或扣款，已经不能安全上线。

改造前后对比同样使用演示数据：

这里有一个容易被误解的变化：人工接管次数增加了。

这不一定是退步。对删除、付款、发送等操作而言，正确触发接管，说明 Agent 开始知道自己的边界。真正应该减少的是错误接管和高风险误执行，而不是一味追求“全自动”。

上线判断也不该依赖一个笼统总分：

• 可自动执行：低风险、可撤销任务，成功率和工具准确率达到团队预设门槛；
• 适合灰度：大部分任务可完成，但延迟、成本或偶发错误仍然明显；
• 必须人工确认：发送、付款、删除、写库、提交订单等不可逆操作；
• 不得上线：存在静默失败、重复执行、越权调用或无法停止的循环。

可靠的 Agent 不是永远不出错，而是出错可见、重试有界、操作可撤、随时能交给人。

现在就跑出第一份稳定性基线

如果你已经整理好历史任务，下一步就是固定模型与 API 环境，把同一套 20 个任务分别运行 3—5 轮，再将成功率、延迟、成本和接管记录写入评分表。

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

建议先从脱敏后的低风险任务开始，不要直接连接生产数据库、支付、删除或真实消息发送工具。

回放测试解决了“如何发现 Agent 不稳定”的问题，但还有一个更棘手的工程环节：同一个工具被调用两次时，怎样避免重复发消息、重复写库，甚至重复扣款？

下一篇，我们将用一个完整工作流拆解 Agent 的幂等设计，包括幂等键、状态机、补偿操作，以及不可逆动作的确认机制。

#Agent #AI教程 #Agent评测 #人工智能 #工作流 #Python #8848AI