24 篇博文 含有标签「devops」

这里有一个应该让你感到不安的数字：根据《2025 年 DORA AI 辅助软件开发现状报告》，人均合并的开发者 PR 增长了 98%，而每个 PR 导致的事件增长了 242.7%。部署频率看起来处于“精英”水平。但系统的单位变更故障率比 DORA 测量过的任何时期都要高。

你的仪表盘是一片绿色。你的值班工程师却精疲力竭。测量尺度出了问题。

当生产环境出现故障时，工程师们首先会想到 git blame。提交哈希值指向 PR，PR 指向作者，而作者则指向上下文——Slack 讨论串、设计文档，或者是记住了代码初衷的那个大脑。这条链路是团队排查事故、进行安全审计以及积累机构知识的方式。它假设每一行代码都有一个理解自己在做什么的人类作者。

AI 已经悄然打破了这一假设。目前约 46% 的代码由 AI 生成，在 Java 团队中，这一比例甚至超过了 60%。这些代码中的大部分都不携带任何有意义的溯源元数据。git blame 链条依然在运转——只是现在它终止于一名开发者，他们接受了一个可能并未完全理解的建议，而且没有记录提示词、模型版本或 AI 拒绝的备选方案。

你的测试环境通过了所有检查。LLM 对每个测试提示词都做出了正确响应。延迟表现良好。质量评分看起来也不错。你发布了。然后，两天后，生产环境开始在你的评估集从未涵盖的一类查询中出现幻觉，你的成本飙升了 3 倍，因为缓存是冷的，而且你的供应商推送的模型更新静默地改变了行为，而你的旧测试套件无法检测到。测试环境显示一切正常，生产环境却给出了截然不同的结果。

这并不是一个可以通过编写更多测试用例来弥补的测试差距。预发布环境对 AI 系统具有结构性的误导，而对传统软件则不然。失败模式是系统性的，解决办法不是更好的测试环境，而是一种不同的架构。

大多数平台工程师都有过类似的故事：他们让 AI 助手生成一个 Terraform 模块或 Kubernetes 部署清单，结果看起来非常合理，CI 流水线也顺利通过了，但几周后坏事发生了。一个带有通配符权限的 IAM 角色。一个本不该公开的 S3 存储桶。一个因为没人检查安全上下文（security context）而以 root 身份运行的 Kubernetes pod。

核心问题不在于 LLM 写错了语法 —— 它们很少犯这种错。问题在于 IaC 的正确性与语法几乎无关。一个 terraform validate 允许通过的 Terraform 文件仍可能部署出一个安全灾难。一个 kubectl apply --dry-run=client 允许通过的 Kubernetes 清单仍可能调度具有危险能力的 pod。你的 CI 流水线用来检查代码的工具大多检查错了重点。

你的工程师每天都在交付 AI 生成的代码。你的审计人员正在审查变更管理控制——而这些控制是为一个"每行代码都由审批人亲自编写"的世界设计的。两件事同时成立，如果你所在的是受监管行业，这一缺口就是一种你可能尚未充分估量的法律风险。

AI 生成代码的合规认证问题，并非供应商问题——你的 AI 编码工具的 SOC 2 报告并不覆盖你的变更管理控制。这是一个流程认证问题：SOC 2 CC8.1、HIPAA 安全规则变更控制以及 PCI-DSS 第 6 节背后的根本假设是，审批代码变更的人理解代码内容。这一假设已不再成立。

AI评估的命运遵循着一条可以预测的弧线。冲刺零阶段：所有人都认同评估至关重要。上线周：套件运行顺畅，演示效果完美。第六周：CI任务开始被跳过。第十周：有人调高了失败阈值以消除告警。第四个月：绿色仪表盘已毫无意义，人人心知肚明，却无人点破。

这就是评估疲劳周期，它几乎普遍存在。尽管业界在自动化评估工具上持续投入多年，其市场渗透率仍仅有38%——这意味着大多数团队依然依赖人工审查作为主要的质量门控。当下一个模型版本升级，或本周Prompt已是第三次更改时，这些人工审查往往第一个被牺牲掉。

大多数工程团队都能准确地告诉你哪个环境变量在控制他们的数据库连接池。但几乎没有人能告诉你现在是哪个版本的 system prompt 在处理 90% 的流量 —— 或者自上一次收到模型行为投诉以来发生了哪些变化。

这就是 AI 配置足迹（AI configuration footprint）问题。构建基于 LLM 功能的团队会积累一个隐形的配置层 —— 模型选择、采样参数（sampling parameters）、system prompts、工具 schemas、重试预算 —— 这些配置决定了他们的产品在生产环境中的行为。这一层的大部分内容都没有记录在案（system of record）。它们通过直接修改代码、交付电子表格或 Slack 消息进行更新。当出现问题时，没有人能说清楚发生了什么变化。

这不是流程问题，而是架构问题。解决方案需要以成熟团队对待环境配置、功能旗标（feature flags）和基础设施即代码（infrastructure-as-code）同样的严谨态度来处理 AI 配置。

大多数团队处理提示词变更的方式，就像他们在2008年处理配置文件变更一样：编辑字符串，重新部署，然后祈祷。没有版本标签，没有测试套件，没有回滚计划。区别在于，配置文件变更很少会改变整个产品的语义行为——而提示词变更几乎总是会这样做。

如果你发布过面向客户的LLM功能，你可能已经经历过这种情况：为了"改善"语气而编辑了系统提示词，将其与无关的错误修复一起部署，三周后却不知道为什么用户满意度下降了。提示词才是罪魁祸首，但你根本没有办法知道这一点。

我上个季度合作的一个团队在周二凌晨 2:14 向生产环境推送了一个回归错误。值班警报触发了，因为其摘要代理（summarization agent）下游的 JSON 解析器以“尾随逗号错误”拒绝了二十分之一的响应。模型没变。提示词（prompt）没变。评估套件在前一天晚上的通过率为 96.4%，稳稳高于 95% 的准入门槛。改变的只是 package.json 中的一行：模型提供商的 SDK 从 4.6.2 升级到了 4.6.3。补丁更新（Patch bump）。由依赖机器人自动合并。发布说明里写着“内部清理”。

所谓的“内部清理”是一个收紧的 JSON 模式解析器，它删除了一个宽容的后备路径，而这个路径此前一直在默默修复模型工具调用输出中反复出现的尾随逗号怪癖。模型的行为没有改变。但 SDK 对该行为的解释改变了。团队的评估套件从未发现这个回归，因为评估套件运行的 SDK 版本与依赖机器人刚刚推送的版本不同。

这就是 LLM SDK 升级税，它是当今生产环境 AI 中最隐蔽、代价最昂贵的故障模式之一。SDK 不是被动的传输工具。它是你提示词行为的积极参与者，而那些在没有评估的情况下升级 SDK 的团队，实际上是在进行一场伪装的模型发布。

关于编程智能体（coding agents）的讨论总是陷入二元对立：自主还是受监督，YOLO 模式还是手握方向盘，--dangerously-skip-permissions 还是“批准每一次按键”。这种构想框架本身就是一个范畴错误。编程智能体执行的并非“一个动作”，而是一系列动作，其成本跨越了至少七个数量级 —— 从读取文件（免费、可撤销、无副作用）到合并至主分支（不通过 revert PR 则不可逆），再到向集群发布二进制文件（六位数成本级别的事故）。用一个自主性开关来处理如此广泛的范围，就像是为停车场和高速公路设置统一的限速一样。

如果团队在发布“无所不能的智能体”时，没有将每个动作映射到其爆炸半径（blast radius），那么只需一个带有提示词注入风险的 GitHub 评论，就足以引发一场事后复盘 —— 事实上，我们已经有了这种失败模式的公开案例。Anthropic 的 Claude Code 安全审查、Google 的 Gemini CLI Action 以及 GitHub Copilot Agent 在 2026 年都被证实可以通过精心设计的 PR 标题和 issue 正文被劫持，研究人员将这种攻击模式命名为“评论并控制”（Comment and Control）。这些智能体并非在抽象意义上损坏了，而是因为自主性层级悄无声息地将低信任输入抹平为“一视同仁”，从而基于这些输入执行了高阶动作（如推送代码、开启 PR）。

接下来需要建立的规范是：针对每个动作的曲线、随层级扩展的闸门、与爆炸等级匹配的回滚速度，以及一个测试工具组合升级而非单一动作失败的评估程序。

我本季度交流过的一个平台团队发布了一个封装了 kubectl 并支持英语指令的 Slack 机器人。一名工程师输入了 “清理 staging 中未使用的分支”。这个机器人非常“热心地”删除了 12 个命名空间——其中一个的名字匹配到了子字符串 “branch”，但它恰好托管了移动团队已经使用了一周的长期集成环境。没有任何异常被抛出。机器人发起的每一次调用都是它合法持有的权限。复盘报告无法指出任何违背的访问规则，因为确实没有规则被打破。该机器人完全按照其 IAM 策略允许的操作执行。

Unix 哲学是一种隐藏在审美偏好下的隔离策略。具有窄接口的小型工具意味着任何单个命令的爆炸半径都受到它所接受的谓词和标志 (flags) 的限制。rm -rf 极其危险，因为这是大家的共识；kubectl delete namespace 要求操作者完整输入命名空间名称，而这种手动输入就是一道关卡。最小特权原则之所以容易执行，是因为权限是词法化的：命令的形式告诉了你行动的形式。

随后，封装层开始接受英语。现在，“命令的形式”变成了 LLM 认为它是什么，它就是什么。

上个季度我交流过的一个团队发布了一个客户支持智能体，其系统提示词存储在 Postgres 的一行中，每个租户一行。这个方案听起来很合理：企业客户要求定制语气，“让提示词可编辑”是实现这一目标最廉价的方式。六个月后，发生了三件事。评估套件从 200 个案例膨胀到了 11,000 个，因为每个租户的提示词现在都需要自己的回归测试集。提示词更新工作流悄然变成了一个没有审核的写入路径，因为产品负责人被赋予了对表的直接访问权限。此外，由于部署流水线根本不知道提示词发生了变化，一个韩国租户提示词中损坏的 UTF-8 字符导致该租户的聊天机器人下线了两天，却没人察觉。

这些结果都不是需求强制导致的。它们是由一个无人刻意做出的架构决策所强制导致的：系统提示词存放在哪里？在代码中？在配置文件中？还是在数据库行中？团队选择了“数据库”，因为这是实现功能最快的路径，而后果在接下来的几个月里级联影响到了每一个相邻系统。