在生产环境部署前构建 AI Agent 游乐场

一个编程 Agent 曾在一个它认为是 staging 数据库的环境中运行清理脚本。实际上，那是生产环境。由于它使用了错误的凭据并完全执行了指令，该 Agent 删除了四个月的客户订单。

这种失败并不是避开 Agent 的理由。它是构建一个游乐场（playground）的理由。

你不会在一名新工程师入职的第一天就授予其生产数据库的访问权限。你会给他们一个 staging 环境、只读权限和受监督的任务。Agent 也需要同样的入职流程。它们每分钟可以执行上千次操作，因此跳过游乐场所付出的代价要高出千倍。

一个真正的游乐场必须做到三件事：

• 让 Agent 运行其完整的决策循环。
• 防止所有副作用影响到真实系统。
• 记录一切以便检查。

不要只测试提示词（prompt）。测试提示词只是提出一个问题并阅读答案。Agent 的行为是一系列工具调用（tool calls）的序列。真正的失败发生在循环的中途，即当工具返回了非预期的数据时。

你不需要对模型进行沙盒化。你需要对执行器（executor）进行沙盒化。

在工具调用转化为实际操作的地方设置一个接缝（seam）。使用使用 Mock（模拟）而非实时执行器的游乐场执行器。Agent 循环不应该感知到这种区别。如果你的 Agent 直接调用数据库客户端，你就没有接缝，也没有安全性。

测试三个特定领域：

• 行为：Agent 是否按正确的顺序选择了正确的工具？
• 工具调用：参数是否正确且在安全范围内？
• 失败模式：当 API 超时或返回垃圾数据时会发生什么？

一个总是成功的 Mock 对 Agent 没有任何教学意义。你的游乐场必须允许你注入故障，例如网络超时或格式错误的数据。通过这种方式，你可以观察 Agent 是在理智地重试，还是开始产生幻觉（hallucinating）。

如果你的 Agent 运行代码，你需要强大的隔离机制。对于不可信的代码，请使用 microVMs。不要仅仅因为简单就从简单的容器（containers）开始。简单的设置可能会导致严重的安全性事故。

请记住，Agent 是非确定性的。一次通过的测试并不意味着 Agent 是可靠的。你必须多次运行相同的任务。如果一个 Agent 在 10 次中有 7 次通过，那么它在约 30% 的真实用户面前会失败。一致性是你最重要的指标。

最后，要防御对抗性的工具输出。Agent 会将工具数据视为指令。恶意用户可能会通过提示词注入（prompt injection）在数据库中植入内容，从而误导 Agent。在游乐场中通过喂给它具有攻击性的负载（hostile payloads）来测试你的 Agent。

构建一条“毕业路径”，而非“启动按钮”：

• 从 Mock 和完全沙盒化开始。
• 测试多次运行的一致性。
• 测试对抗性输入。
• 转向针对“生产环境形态数据”的空运行（dry-run）模式。
• 只有到那时，才授予受限、受控且受监控的访问权限。

给你的 Agent 一个低成本犯错的地方。这样，它才能在关键时刻做到正确。

Source: https://dev.to/nazar_boyko/building-an-ai-agent-playground-before-giving-it-production-access-4glh

Optional learning community: https://t.me/GyaanSetuAi