livekit-simulations

⚠️ 模拟功能目前处于私人测试阶段（尚未全面开放）。

• 尚无文档 / MCP 覆盖。 对于 lk agent simulate 命令，请使用 lk agent simulate --help 和 LiveKit Cloud 控制面板，而不要在模拟功能有文档之前使用 lk docs / MCP。
• 需要较新版本的 SDK。 运行模拟需要使用 livekit-agents 的 1.6 系列版本。 请确认已安装的版本，不要想当然。
• 可用范围有限 / 需要身份验证。 创建运行需要项目已启用 模拟功能，并且当前存在 lk cloud auth 会话。（生成场景—— 这是此技能的主要工作——两者都不需要；整个过程完全在本地进行。）

生成模拟场景

使用模拟功能最有价值的方式，是为用户的 Agent 生成优质测试场景——这些场景以 Agent 的实际代码和用户希望进行压力测试的内容为依据——然后运行它们。整个过程在本地进行：你使用常规工具读取代码（不会上传任何内容），而你（编码 Agent）就是负责生成场景的模型，因此不需要额外的 API 密钥或服务。

场景 = 模拟用户的角色设定和目标（instructions），以及通过标准（agent_expectations）。模拟会让 Agent 通过文本与每个场景交互，并由一个 LLM 评审器进行评分。你的任务是生成一组高质量、多样化且切中目标的场景，并将其写入 CLI 可以运行的 YAML 场景文件。

这为什么比自动驾驶模式更好

简单地说“生成一些测试”的做法抓不住重点。这项技能的价值体现在以下三点：

1. 它会读取 Agent 的实际代码——因此场景会考虑 Agent 实际能够执行的操作和受阻之处（尤其是约束条件 / 无法提供的项目），而不是根据名称猜测。
2. 它会根据用户的需求进行调整。 用户知道自己担心什么。务必了解用户的意图，并在整个过程中加以体现。这是核心重点——请参阅 references/user-guidance.md。
3. 它能确保覆盖每一项风险。 如果不加引导，生成过程往往会偏向看似合理的顺利流程调用，并悄然跳过棘手案例——缺少必填字段、提供无效值、查询结果为空，以及防护措施 / 滥用场景（超出范围、有害内容、专业建议、敏感数据、提示词提取）。此技能会将 Agent 的约束转化为明确的风险检查清单，并要求每项风险至少对应一个场景——请参阅 references/analyzing-the-agent.md 和 references/writing-scenarios.md。

流程

1. 描述 Agent + 构建风险检查清单——在本地读取其代码，并撰写面向测试的描述（Identity / Capabilities / Constraints）到 description.md，再将明确的风险检查清单写入 risks.yaml（每项必须测试的约束/防护措施对应一条记录，每条记录都包含 id 和 category）。遵循 references/analyzing-the-agent.md。切勿上传代码。
2. 了解用户的测试重点——如果用户没有说明要探查哪些内容，就询问。按照 references/user-guidance.md 应用重点（在 description.md 中追加 # Test Focus，并据此调整编写方向）。重点是叠加的——它会深化选定风险的测试，但绝不会降低每项风险的最低覆盖要求。如果用户确实没有偏好，就生成广泛覆盖的场景并说明这一点。
3. 编写场景——每项风险至少一个——编写一组多样化的约 10 个场景，依据 description.md 和测试重点生成，并根据自己的判断丰富角色设定 / 情绪 / 情境（此版本不附带属性库）。确保覆盖：risks.yaml 中的每一项都必须至少有一个专门测试它的场景，采用能实际触发该风险的形式编写，并标记 covers: [<risk id>, …]。遵循 references/writing-scenarios.md（架构、“Party A talks to the agent”规则、无先前状态、无真实个人身份信息、基于结果的预期、对抗性形式分类、覆盖检查、不要编写糟糕的测试）。将场景写入 authored.yaml。也在此添加用户指定的必测项。
4. 组装配置（强制覆盖）—— python scripts/build_scenarios.py assemble --in authored.yaml --agent-description-file description.md --risks risks.yaml --strict --out scenarios.yaml （验证架构，若任何风险未被覆盖则失败，并输出 lk agent simulate --scenarios 可加载的 YAML 场景文件。）修复缺漏并重新运行，直到通过。
5. 运行——lk agent simulate --scenarios scenarios.yaml（使用 --help 确认准确的标志；需要 Beta 说明块中提到的 SDK / 身份验证）。向用户展示结果，并提供重新运行、调整重点或添加场景的选项。

将已保存的 scenarios.yaml 文件用作回归测试套件——在更改提示词 / 模型 / 工具后重新运行。

原则

• 绝不上传用户的代码。 在本地读取代码才是关键；代码属于用户的知识产权。
• 用户的意图是差异化所在——每次都要纳入考虑；不要不作说明地自动处理。
• 每个场景都要以描述为依据，尤其是 Constraints——对于 Agent 根本不可能满足的要求（或它理应拒绝的防护措施），场景的预期必须如实反映这一点。
• 脚本负责确定性的组装工作；你负责生成。 让 build_scenarios.py 处理组装和覆盖检查；由你来读取、判断、确保多样性并编写场景。

核实，不要臆测（永久冻结）

此技能是方法（不附带库——多样性由你自行提供）。准确的 lk agent simulate 标志、CI 等待/失败标志、最低 SDK 版本和仪表板信息均来自实时来源，因为它们会变化——请使用 lk agent simulate --help，以及（Beta 阶段之后）lk docs / LiveKit MCP 服务。标志错误会浪费一次运行；应查询确认，而不是猜测。

运行后：根据结果采取行动（次要）

运行完成后，查看每个场景的通过/失败情况、运行摘要，以及失败场景的对话记录。若失败确实存在，就修复 Agent 并重新运行；若失败实际源于场景不佳，就修复场景。保持流程轻量——现代模型已经擅长修复；此技能的持久价值在于生成并保留场景。