关于 running-livekit-simulations
面向 LiveKit Agent 开发者的模拟测试技能，用 LLM 驱动的模拟用户与评审器检查完整对话结果。支持文本回归测试和语音流水线评估，并提供结果导出与失败排查指引。
主要功能
- 01运行文本或音频模拟
- 02评估多轮对话结果
- 03测试语音交互行为
- 04导出完整对话记录
- 05排查 Agent、场景与模拟环境问题
适用场景
- 01部署前检查长对话是否达到目标
- 02评估语音轮次与打断处理
- 03对发布候选版本运行音频测试
- 04通过 CI 自动执行文本回归测试
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/running-livekit-simulations确认已加载。
详细介绍
运行 LiveKit 模拟
模拟会使用由 LLM 驱动的模拟用户，让真实 Agent 应对某个场景，然后由评判者对对话记录进行评分。单元测试会断言某一轮的结果，而模拟会告诉你整个对话是否达到了预期结果。
运行前请先阅读 lk agent simulate --help。子命令和标志会发生变化，用错标志会浪费一次付费运行，本指南不会重述这些内容。其余信息请参阅 reading-livekit-docs。
何时使用模拟
在部署到生产环境前，使用模拟对长流程行为进行回归测试：多轮对话在来电者改变主意时是否能达到预期结果，早期收集的详细信息是否能保留到最后，Agent 在压力下是否能遵循指令，以及是否结束在正确的状态。对于单轮测试，请使用 testing-livekit-agents；编辑时想试探行为，请使用 debugging-livekit-agents。
运行
在 Agent 的项目目录中运行。模式是一个子命令：
lk agent simulate text --scenarios scenarios.yaml # see --help for the current flags
如果没有场景文件，CLI 会根据 Agent 的源代码生成场景。这会上传代码，CLI 会先请求确认。场景生成属于 writing-livekit-scenarios。
默认情况下，CLI 会将 Agent 作为本地 worker 启动，将场景分派给它，并在运行结束时停止它。也可以选择按名称对已运行的 Agent 进行评分。由于没有本地源代码可供生成，因此需要提供场景文件。
每次运行和每个项目的并发数都有限制。当前限制请参阅文档。
文本或音频
默认使用文本，这也是正确的选择。模拟用户通过文本与 Agent 交互，因此运行会测试大模型、工具和对话逻辑，同时由框架关闭 STT、TTS 和 VAD。文本模式更快、更便宜，也更具确定性。迭代开发和自动化测试都应使用文本模式。
**音频模式会通过完整的语音管线运行相同的场景。**模拟用户会像真实来电者一样说话、倾听和打断，运行还会评估只有语音场景才会暴露的问题：
- 轮流发言：来电者还没说完就开始说话，或让已经说完的来电者继续等待。
- 打断处理：对插话做出让步，并区分简短的确认回应和新一轮发言。
- 双向转写准确度：分别评估重要内容，包括姓名、数字、地址和确认码。
- 感知延迟：来电者实际听到的延迟，与 Agent 对自身延迟的报告不同。两者之间的差距就是用户实际体验到的延迟。
音频模式会实时运行，每一轮都会调用 STT 和 TTS 提供商，计费费率也更高。请将其留给候选发布版本，或涉及语音、轮流发言或打断处理的变更。不要将其纳入定期任务。
音频子命令提供了用于降低模拟来电者音频质量的选项（噪声、劣质麦克风、丢包）。使用这些选项测试 Agent 如何处理听不清楚的语音。它应该请求对方重复，而不是猜测。也可以组合使用这些选项，模拟最不利的来电情况。
自动化发布前运行
你只需要一个已提交的场景文件，以及一个定时任务或发布分支任务。当 CLI 未连接到终端时，会输出纯文本；如果任何场景失败，还会以非零状态码退出，因此无需额外配置，任务就会失败。文档提供了一个可作为起点的 CI 示例。自动化运行请始终使用文本模式。已提交文件中的每个场景都必须通过，否则任务就会失败。因此，请将 Agent 尚未通过的期望性场景单独存放在一个文件中，按需运行。
阅读结果
一次运行会为每个场景打印判定结果和一个仪表板链接。判定结果告诉你发生了什么；记录会告诉你原因，因此应从记录入手。仪表板链接是给人查看的。你要用的是 export：它会以 JSON 格式输出已完成的运行，以及每个场景的完整对话上下文——你可以从中阅读失败的记录、对比两次运行，或将运行存档为构建产物。list 可以查找运行 ID，也支持机器可读的输出；--help 会列出各个标志。
排查故障时，先判断属于以下哪种情况：
- Agent 中的 Bug。 修复 Agent 后重新运行。先检查指令和工具描述。看似推理不佳的问题，往往是因为工具描述从未说明何时使用该工具。
- 场景有问题。 预期要求 Agent 做不该做的事，或者描述过于含糊，导致裁判无法一致地判定。修复场景。
agent_expectations含糊，是判定结果在不同运行间反复变化的最常见原因。 - 模拟环境存在缺口。 场景测试通过了，但生产环境中失败了，或反之。通常是 Agent 获取了不同的数据、派生出的指令遗漏了导致问题的那一轮对话，或者故障只会在音频场景中出现，而文本运行无法发现。
修复后，运行整个文件，不要只运行正在处理的场景。针对某段对话的修复，往往也会影响相邻的对话。
将反复出现的故障下移到更低层进行处理。 如果某个场景每次都以相同方式失败，说明这是一个回合级 Bug。用单元测试来锁定该问题，成本更低，也能更早发现。请参阅 testing-livekit-agents。
相关技能
- 编写和组织场景：
writing-livekit-scenarios - 交互式调试故障：
debugging-livekit-agents - 更低成本的每次提交覆盖：
testing-livekit-agents - 部署本次运行所评测的 Agent：
operating-livekit-agents - 标志、版本、变更日志：
reading-livekit-docs