很多 AI Agent 在演示环境里表现惊艳，进入真实业务后却很快暴露问题：用户不会按预设路径提问，工具会返回异常数据，多轮对话会逐渐偏离目标，合规边界也可能在长链路中被突破。真正的难点不是让 Agent 完成一次成功任务，而是持续证明它在大量未知场景下仍然可靠。
来源分享的核心思路是把 Agent 测试从人工抽查升级为“仿真驱动测试”：用合成用户画像生成多样的多轮交互，让 Agent 在上线前反复经历边缘情况，再通过轨迹分析、自动评分和 CI/CD 门禁筛选版本。这样，测试就不再是发布前的一次性活动，而成为 Agent 持续学习和迭代的一部分。
Demo 为什么很难直接变成产品
Demo 通常只验证一条精心设计的成功路径：用户目标清楚，工具响应正常，上下文长度可控，异常分支几乎没有出现。生产环境则同时增加了几种不确定性：
- 用户行为不确定：用户可能改变目标、重复提问、提供矛盾信息，或者在中途插入无关请求。
- 工具行为不确定：搜索、数据库和外部 API 可能超时、返回空结果、改变字段，甚至返回格式错误的数据。
- 策略约束更复杂：Agent 需要在帮助用户、保护隐私、遵守业务政策之间做出稳定选择。
- 多轮错误会累积：某个早期判断的小偏差，可能让后续规划、工具调用和最终答案全部偏离。
只看最终答案也不够。一个答案即使表面正确，内部仍可能调用了不该调用的工具、泄露了敏感字段，或在过程里浪费了大量步骤。因此，生产评估需要同时观察结果和轨迹。
用合成用户覆盖真实的不确定性
仿真测试的关键不是随机生成更多问题，而是设计能够施加压力的用户 Persona。一个 Persona 可以包含目标、知识水平、表达方式、耐心程度、隐含约束和可能的反应。例如，客服 Agent 的测试用户可以分别表现为：
- 目标明确但信息不完整的普通用户；
- 会不断改变要求的犹豫用户；
- 试图获取他人账户信息的越权用户；
- 遇到工具错误后要求 Agent 给出替代方案的用户。
同一任务在不同 Persona 下产生的对话轨迹越多，越容易暴露 Agent 对单一路径的过拟合。可以用轨迹熵作为一个有用的观察指标：当面对同类任务时，如果所有轨迹都异常集中，可能说明 Agent 过度依赖固定模板；如果轨迹分散但成功率和合规分数稳定，则说明它具有更好的适应性。熵本身不是质量分数，必须和任务成功率、违规率、步骤数等指标一起解释。
一个实践中的最小事件格式可以如下：
{
"session_id": "sim-0042",
"persona": "impatient_customer",
"goal": "change_delivery_address",
"turns": 6,
"success": true,
"policy_violations": 0,
"tool_calls": 4,
"trajectory": [
{"actor": "user", "text": "我想改收货地址"},
{"actor": "agent", "action": "ask_order_id"},
{"actor": "tool", "name": "lookup_order", "status": "ok"}
]
}
把多轮评估接入 CI/CD
评估管线可以拆成四步：生成场景、运行对话、评分轨迹、执行发布门禁。下面是一个可以改造的最小 Python 示例。它不依赖具体 Agent SDK，假设被测 Agent 暴露了一个接收消息并返回结果的 agent.chat 接口。运行前，将 AgentUnderTest 替换为项目中的客户端，并补充真实的业务评分器。
from dataclasses import dataclass
from typing import Callable
@dataclass
class Scenario:
name: str
messages: list[str]
expected_keyword: str
class AgentUnderTest:
def chat(self, message: str) -> str:
# 替换为真实的 Agent API、SDK 或本地调用。
return f"已收到：{message}"
def run_scenario(agent: AgentUnderTest, scenario: Scenario) -> dict:
transcript = []
for message in scenario.messages:
reply = agent.chat(message)
transcript.append({"user": message, "agent": reply})
final_reply = transcript[-1]["agent"]
passed = scenario.expected_keyword in final_reply
return {
"scenario": scenario.name,
"passed": passed,
"turns": len(transcript),
"transcript": transcript,
}
def evaluate(results: list[dict], min_pass_rate: float = 0.8) -> None:
pass_rate = sum(item["passed"] for item in results) / len(results)
print(f"pass_rate={pass_rate:.2%}")
if pass_rate < min_pass_rate:
raise SystemExit("evaluation gate failed")
scenarios = [
Scenario(
name="incomplete_request",
messages=["我想改地址", "订单号是 A-100"],
expected_keyword="A-100",
),
Scenario(
name="context_switch",
messages=["查询订单 A-101", "顺便告诉我客服电话"],
expected_keyword="客服电话",
),
]
results = [run_scenario(AgentUnderTest(), item) for item in scenarios]
evaluate(results)
在 CI 中可以把脚本作为发布前检查：
name: agent-evaluation
on:
pull_request:
push:
branches: [main]
jobs:
evaluate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- run: pip install -r requirements.txt
- run: python tests/evaluate_agent.py
实际项目中，门禁不应只看一个总分。可以同时设置最低任务成功率、最高政策违规率、最大平均工具调用次数和最长响应时间。对高风险场景，还应采用“任何一次违规都失败”的规则，而不是允许它被其他普通样本的高分抵消。
评估什么：结果、过程和边界
一个可操作的评分体系至少应包含以下维度：
- 任务结果：Agent 是否完成了用户目标，答案是否包含必要信息。
- 过程轨迹：规划是否合理，工具调用是否必要，是否出现重复循环或无效步骤。
- 合规性：是否暴露隐私、绕过权限、违反业务政策，或在拒绝场景中提供了可被滥用的细节。
- 交互质量：是否保持上下文，是否在信息不足时澄清，而不是编造事实。
- 资源成本：Token、工具调用次数、延迟和失败重试是否在预算内。
自动评估器可以由规则、结构化断言和模型评分共同组成。规则适合检查 JSON 字段、权限结果、工具调用白名单等确定性条件；模型评分适合判断表达是否满足目标，但必须使用固定 rubric，并通过人工标注样本校准。对于合规和财务等高风险指标，不能把模型评审作为唯一裁判。
从测试集到自学习闭环
仿真系统的长期价值在于形成反馈闭环：失败轨迹进入错误分类，错误分类推动新增 Persona 或测试场景，修复后的版本重新运行回归集，稳定通过后才进入生产。这样，测试集会随着真实事故和新业务规则增长，而不是停留在最初的几十个 happy path。
但自动生成测试也有边界。合成用户可能共享同一种语言习惯，无法代表真实用户的低频表达；评分器可能和被测 Agent 使用相同偏见；为了追求更高通过率，团队还可能无意中把场景设计得过于简单。因此，仿真数据应与脱敏真实会话、专家构造的对抗样本和线上监控结合使用。
落地检查清单
可以按下面的顺序启动：
- 先定义 5 到 10 个最重要、最容易出错的业务任务。
- 为每个任务建立正常、缺信息、改目标、工具失败和越权等 Persona。
- 保存完整多轮轨迹，而不只保存最终回答。
- 将成功率、违规率、步骤数、延迟和成本作为独立指标。
- 在 Pull Request 阶段运行小型回归集，在夜间或发布前运行大规模仿真。
- 为高风险规则设置硬门禁，并保留人工复核通道。
- 每次线上事故都转化为可重复的测试场景。
AI Agent 的生产化不是把 Demo 部署到更大的服务器，而是建立一套能持续发现未知失败、解释失败原因并阻止回归的工程系统。仿真用户、轨迹熵和自动化 CI 评估提供了这套系统的骨架；真正决定效果的，则是场景质量、评分边界以及团队是否愿意把失败样本持续加入测试资产。