36 篇博文 含有标签「governance」

绿色 CI 并不意味着“这个提示词有效”。绿色 CI 的本质是“编写评测的工程师想不出这个提示词会如何出错”。这是两个截然不同的断言，而它们之间的差距正是生产事故的温床。一个评测套件并不是对模型的测量——它是对编写者的冰冷写照。他们的方言、领域知识、资历、偏好的失败模式，以及他们在编写测试用例时恰好使用的模型。根据构造，工程师没想到的测试内容统统未经测试。更糟糕的是：他们会从同一个视角不断扩展套件，因此随着套件的增长，盲点并不会缩小，反而会变得根深蒂固。

这就是评测作者单一化（eval-author monoculture）问题，也是当今 AI 工程中讨论最少、风险最高的可靠性问题。团队痴迷于裁判偏差、位置偏差、冗长偏差、泄漏和污染——但上游偏差其实是最初决定测试用例的人的偏见。其他任何评测误差来源都会被它放大。如果你的套件是由一个人编写的，那么你就拥有了一个带有性格的基准测试，而这种性格正是你的 CI 能够捕获风险的无形天花板。

一位产品经理写下了一段话：“助手应当乐于助人、准确且简洁，绝不能让客户感到匆忙。”一位工程师读了这段话，打开一个 YAML 文件，编写了 47 个加权标准，以便 LLM-as-judge 能够为每一个追踪（trace）生成一个分数。六个月后，那个 YAML 文件成了产品的实际规范。每一次发布都受其把关。每一次回归警报都基于它触发。每一个“达到发布质量”的决策都通过它来路由。而产品经理从未读过它。

这是当今 AI 工程中最为常见的、无意间发生的产品所有权转移。评估准则（rubric）不是对规范的衡量 —— 它就是规范，就像编译器不是对语言的描述，而是它的运行真相。就像编译器一样，评估准则也有决定语义的实现细节。哪种失败模式得 0 分而不是 0.5 分？哪个标准的权重是 0.3 而不是 0.05？哪些行为在评估准则中缺失，从而完全未被计算？每一个都是产品决策。而它们都没有出现在最初的任务书中。

一个客户给客服发邮件，询问为什么你的 CRM 智能助手停止起草他们的 NDA 了。你根本不知道你的 CRM 智能助手竟然在起草 NDA。一位资深用户抱怨说，你的客服机器人的他加禄语（Tagalog）翻译质量自上周以来有所下降。你根本不知道你的客服机器人还会他加禄语。一个论坛帖子传播了一个提示词，能将你的代码审查助手变成一个还算凑合的安全扫描器，不到一个季度，你就收到了针对该助手生成结果提交的 CVE 报告。其中的每一项都是一个拥有用户群、业务影响力，但完全没有组织归属的功能——没有评估（eval）、没有 SLA、没有在 UX 中体现、没有列入路线图，而且还有一个隐蔽的、仅为 1 的公交因子（bus factor）：那个摸索出这种用法的客户。

当你的产品封装了一个能力范围（capability surface）远超你设定范围的模型时，就会发生这种情况。用户会探索更广阔的能力范围，寻找能解决他们问题的行为，并在这些行为之上构建工作流。然后，当你进行下一次模型升级时，即便你的路线图上没有任何变动，他们也会将其视为一种退化（regression）。你与用户之间的契约不再是你书面写下的那份。它包含了模型碰巧为他们做到的、且你碰巧没有破坏掉的所有事情。

将此视为工程上的意外——“我们会强化提示词，增加护栏，下次我们会捕获到它”——这是一种范畴错误（category error）。“发现的能力”（Found capabilities）是一个产品管理问题。这门学科的核心不在于防止它们发生，而在于检测它们、决定如何处理它们，并记住你曾做出的决定。

走进任何一家有五十名工程师在生产环境编写 LLM 代码的公司，你都会发现七个网关形态的产物。推荐团队造了一个用于在 OpenAI 和 Anthropic 之间路由。支持机器人团队写了一个用来挂载他们的 Prompt 注册表。平台团队有一个半成品代理，处理鉴权但不处理限流。增长团队有一个 Lambda，在数据发出时进行 PII 脱敏。数据科学团队直接调用供应商 SDK，而且没人告诉他们停止这样做。没有共享网关。只有七个共同的问题，每个都被孤立且拙劣地解决了，而首席财务官 (CFO) 正准备询问为什么 AI 账单环比增长了 40%，却没有任何明确的负责人。

这与行业在 2016 年和 2017 年遇到微服务时的架构节奏完全相同。成千上万的外部依赖，每个团队都有相同的共同关注点——鉴权、重试、可观测性、策略——以及在“解决一次”或“随处重新发明”之间做出选择。当时的答案是服务网格 (Service Mesh)。现在的答案是内部 LLM 网关，而大多数公司仍处于“随处重新发明”的阶段。

调出你公司的数据分类政策。公开、内部、机密、受限——四个整齐的层级，每一个都映射到一组访问控制和一份批准的存储位置清单。现在问一个该政策从未准备回答的问题：这些层级中，哪些允许以发送给第三方模型 API 的 Token 序列的形式离开公司边界？

答案几乎总是沉默。这并非因为政策本身有误，而是因为它是不完整的。当今使用的每种分类方案都是为一种访问向量设计的，即询问“该员工是否被允许读取这一行？”Prompt 层引入了一个完全不同的向量：一个获得授权的服务读取了该行，将其转换为 Prompt，并将其跨网络传输给一个供应商，而该供应商可能会记录它、在其上进行训练，或将其以明文形式保存三十天。这些都不属于读取权限范畴。这些都不在覆盖范围内。

这就是缺失的一列。在你添加这一列之前，你的数据分类文档只是在自信地宣称一种你实际上并不具备的控制态势。

你的安全团队拥有公司信用卡上每一项 SaaS 订阅的完整清单、每一个获得管理员授权的 OAuth 应用，以及连接到公司 Wi-Fi 的每一台设备。然而，对于你的高级工程师笔记本电脑上当前绑定到 127.0.0.1 的七个进程，他们却完全视而不见——一个带有长期 Staging API 令牌的“部署助手”，一个订阅了包含客户数据的 Slack 频道的“工单分类器”，以及一个拥有生产分析数据仓库读取权限的“发布说明生成器”。这些都不在供应商名单上。它们不会出现在 SSO 日志中。所有这些都在利用工程师现有的凭据运行，执行着从未经过审批的操作。

这就是影子 MCP（Shadow MCP），它是企业中增长最快的未管理授权面。模型上下文协议（Model Context Protocol）使得将任何工具接入任何 LLM 的成本变得极低，而工程师们——天性使然——首先接入了那些最显而易见的工具。Saviynt 的 CISO AI 风险报告指出，75% 的 CISO 已经发现其生产环境中运行着未经授权的 AI 工具。GitHub MCP 服务器在 2026 年初的周安装量突破了 200 万次。Postgres MCP 服务器允许 LLM 对开发者能接触到的任何数据库执行 SQL 提示词，其周安装量已超过 80 万次。这些数字中没有一个代表企业的 IT 决策。

对共享系统提示词的第一次修改感觉就像是优秀的工程实践。三个团队都在各自智能体的顶部粘贴了相同的 18 行安全前导指令，有人注意到了这一点，内部平台团队说了一个显而易见的提议：让我们把它中心化吧。于是 prompts.common.safety_preamble@v1 出现在了注册仓库中。由于这是阻力最小的路径，加上安全团队很高兴能由一个团队统一负责措辞，30 个团队在短短一个季度内就采用了它。在接下来的两个季度里，这看起来就像是一个完美的 DRY (Don't Repeat Yourself) 胜利。

随后，安全团队需要对措辞进行微调。可能是新的合规条例收紧了助手可以主动提供的用户信息范围，也可能是红队发现需要向拒绝条款中增加一句话。平台团队完成了修改，发布了 v2 版本。不到一天，支持队列就充满了消费团队的消息：我们的评估 (eval) 下降了、我们的格式崩了、我们的工具调用率减半了、我们的语气变了、延迟增加了（因为模型开始进行更多推理）。每个团队都希望回退修改。而安全团队需要发布它。没有人能在不进行重新评估的情况下升级，但又没有人负责重新评估。欢迎来到共享提示词的“旗帜日 (flag day)”。

当你的 AI 账单月额度首次突破七位数时，预算会议的形式就会发生变化。在那之前，问题是“我们能否负担得起”。在那之后，问题变成了“谁能分到多少”——而大多数工程团队会实时发现，他们根本没有应对这一问题的政策框架。那个发布了最响亮演示的团队会意外地获得最高配额。财务部门则在推行扁平的人均上限，这让那些从事最高杠杆工作的团队陷入困境。安全部门则完全被排除在对话之外，直到有人发现评估团队过去六个月一直在通过个人 Token 额度拉取生产流量。

这种对话之所以总是感觉像是在争论云成本，是因为它确实接近云成本，但不完全是。在云端，浪费的单位是一个被遗忘的 EC2 实例，最坏的情况是账单翻三倍。而对于 Token 配额，浪费的单位是一个失控的 Agent 循环，而准入的单位则是面向用户的功能：谁掌握了预算，谁就能发布功能。后一种特性使得 Token 分配更接近基于能力的安全性（Capability-based security），而不是云 FinOps。配额不仅仅是一个支出上限。它是执行一类推理的权利。

“发送邮件”工具和“删除账号”工具被放在了同一个确认弹窗后面。你的用户今天已经点击了 40 次“批准”（Approve），没有一次点击涉及阅读 Diff，而下一次点击——即向生产数据库提交一个不可逆变更的操作——看起来和之前的 40 次完全一样。这就是二元工具审批的失效模式，也是当今几乎所有发布的 Agent 框架的默认设置。

问题的核心框架在于，“需要人工审批”被视为附加在工具上的单个布尔值，而实际上它是一个包含五到六个类别的分类法，取决于工具可能造成的破坏类型以及这种破坏的可恢复程度。那些能够交付安全 Agent 的团队不再询问“这个工具是否需要确认对话框”，而是开始询问“这个工具属于哪种风险类别，以及哪个门槛（gate）对应于该类别”。审批门槛的正确数量既不是一个，也不是很多。它是每个风险类别对应一个，你必须在构建门槛之前先列举这些类别。

一个用户打开聊天窗口，请求退款，得到“抱歉，此次购买不符合退款条件”的回复后，关闭了标签页，再也没有回来。在内部，智能体生成了一条完美的追踪记录：工具调用、中间推理过程、参考的政策包，以及运行的模型版本。每一个 span（追踪跨度）都进入了可观测性平台。但没有任何内容是用户可以触及的。这里没有标为“请求人工再次审核”的按钮，即使有，后面也没有相应的服务。这个决定在默认情况下就是终局，而非设计使然。

这就是“可争议性差距”（contestability gap），它是监管机构、律师和愤怒的用户接下来要撕开的口子。这也是一个最典型的例子：一个从外部看像是政策问题，而从内部看实际上是工程链路（plumbing）的问题。

在每月 50,000 美元的水平时，你基础设施账单上的“计算 + Token”这一项只是可以忽略不计的零头。但当每月达到 5,000,000 美元时，它就是一个 CFO 级别的问题。这两个阶段之间的转变并不是渐进的——它是组织讨论模型支出方式的一种“相变”，而大多数工程组织对于随之而来的社会和政治工作都准备不足。账单依然是那简单的一行；但围绕它的对话却不再简单。

改变的是谁有资格问“为什么”。当三个产品团队共享一个 API Key 和一个预留容量时，每一个配额争论的结构都是相同的：某人正以牺牲他人的利益为代价获胜，而没有中立方来主持公道。当一个团队的发布第一次因为另一个团队上线了一个“话痨”智能体（agent）而受到限制时，整个工程组织会立刻感受到治理机构缺失带来的痛苦。在压力之下召开会议并凭空发明流程，是设计流程最糟糕的时机。

打开你团队用来发布提示词（prompt）变更的配置仓库。看看最近的 30 个 commit。其中有多少个经过了代码审查（code review）？有多少个在 CI 中设置了评估门禁（eval gate）？有多少个你能——肯定地——归因为对看到它们的用户的生产环境行为产生了可衡量的变化？如果你的答案是“绝大多数”，那你是个例外。对于其他人来说，这些 commit 此刻正在生产环境中运行，而读取它们的系统所做的事情与特性标志（feature-flag）服务完全一致：热加载一个值，分发给用户，改变产品行为。区别在于，你的特性标志服务拥有审计日志、曝光追踪、熔断开关（kill switches）以及针对特定分群的定向投放。而你的提示词发布流水线只有 git push。

这并非隐喻。这是对你团队正在运行的生产系统的准确描述。提示词配置仓库、你的 worker 轮询的 S3 存储桶、数据库中的 “prompts” 集合、你的应用在启动时获取的 LangSmith/PromptLayer/Braintrust 资产——这些全都是特性标志服务。它们具有相同的运行时形态：一个存在于二进制文件之外的值，二进制文件在热路径（hot path）上读取它，更改该值即可在无需部署的情况下改变真实用户的行为。唯一缺少的，是你的 SRE 团队在批准“真正的”特性标志服务之前所要求的所有控制措施。