16 篇博文 含有标签「devops」

每个 DevOps 团队都有一套凭据轮换政策。大多数团队已经针对其服务、CI 流水线和数据库实现了自动化。但当你部署一个持有跨五个不同集成的 API 密钥的自主 AI Agent 时，那套轮换政策就变成了一个地雷。Agent 正在执行任务中——分拣 Bug、更新工单、发送 Slack 通知——突然它的 GitHub 令牌过期了。进程看起来很健康。日志显示没有崩溃。但无声无息地，一切都不再起作用了。

这是无人从 DevOps 映射到 AI 的凭据轮换问题。传统的轮换假设工作负载是可预测的、由人管理的，并且具有清晰的边界。自主 Agent 打破了每一个这样的假设。

你的 Agent 在预发布环境中通过了每一项测试。然后它进入了生产环境，发送了 4,000 封电子邮件，向一名客户收取了两次费用，并删除了一条本不该触碰的记录。预发布测试没有错 —— 它们只是测试了错误的东西。预发布环境让 Agent 看起来很安全，因为所有它可能破坏的东西都以错误的方式被伪造了：Mock 得足以不崩溃，但也真实得足以让你误以为测试是有意义的。

这就是“模拟保真度陷阱”。这与普通的软件测试失败不同。对于确定性函数，镜像生产环境 Schema 和 API 的预发布环境通常就足够了。对于 Agent 来说，行为产生于推理、工具输出以及跨多步轨迹的累积状态之间的相互作用。如果在这些维度中的任何一个上与生产环境存在偏差，预发布环境都会产生对其实际行为过度自信的 Agent。

你的代码通过一个流程发布：特性分支 (feature branch) → 合并请求 (pull request) → 自动化测试 → 预发布 (staging) → 生产环境 (production)。每一步都有门槛。如果没有通过你定义的检查，任何东西都无法到达用户手中。这种“枯燥”正是它最好的地方。

现在想象你需要更新一个系统提示词 (system prompt)。你在仪表盘中编辑字符串，点击保存，更改立即生效 —— 没有测试，没有预发布，版本控制中没有 diff，除了手动改回去之外没有回滚的方法。这就是大多数团队的运作方式，也是提示词更改成为 LLM 应用非预期生产事故主要原因的原因。

挑战不在于团队粗心大意。而在于持续交付 (continuous delivery) 的规范是为确定性系统构建的，而 LLM 并非确定性的。整个思维模型需要从头重建。

一个团队在客服提示词中增加了三个词，为了让它“更具对话感”。几小时内，结构化输出错误率激增，一条创收流水线停滞。工程师们花了将近一整天的时间调试基础设施和代码，才有人想到去检查提示词。没有版本历史。没有回滚机制。这三个词的修改是由一位产品经理直接在配置文件中内联完成的，他完全没理由认为这会有风险。

这是一个典型的生产环境提示词事故。类似的戏码在各种规模的公司中上演，其根源几乎总是一样的：提示词被视作临时配置，而不是软件。