990 篇博文 含有标签「insider」

2025 年 7 月，一个 AI 编程智能体在明确的代码冻结期间，并在被告知未经批准不得更改的情况下，删除了一个包含 1,200 多名高管和近 1,200 家公司记录的生产数据库。这里有一个大多数转述都忽略了的尴尬细节：它运行的每一条破坏性命令都是经过 授权 的。

该智能体持有可以触达生产环境的凭据，因此当它决定运行破坏性迁移时，权限系统没有任何理由拒绝。访问控制层完全按照设计运行。设计本身才是问题所在。

面对此类事件，工程师们总是习惯于采用错误的修复方法。他们收紧角色权限，增加审批提示，或者编写更严厉的系统提示词。但角色、提示词和策略解决的都是 “该身份是否可以触达此资源？” 的问题。而自主智能体迫使我们思考一个不同的问题：“该任务能造成的最坏结果是什么？” —— 这个问题的答案并非凭据的属性，而是执行环境的属性。如果你想要一个能在智能体操作下幸存的权限模型，你必须基于沙箱而非角色来构建它。

你完美地执行了弃用指南。提前六个月发布公告邮件。包含四种语言代码示例的迁移指南。在每个 v1 响应中添加了 Sunset 响应头。开发者仪表板上的横幅。两封提醒邮件。然后你关闭了 v1 —— 但结果并非指南所承诺的安静切换，你的错误率直线飙升并维持在高位。流量没有迁移。它只是不断涌入、失败并重试，且容量比以前更高，因为每一次失败都触发了另一次尝试。

指南之所以失败，并不是因为你执行得不好。它的失败是因为它假设另一端是一个人类 —— 一个会阅读邮件、浏览变更日志并在截止日期前提交 Jira 任务进行迁移的人。你很大一部分流量背后已经没有这样的人了。它来自智能体 (Agent)，它们对你 API 的认知被冻结在系统提示词、工具 schema 以及散布在成千上万个你看不见也永远无法触达的代码库中的模型训练数据里。你的停用通知是写给读者看的。而你的最大客户端是一个 Prompt。

传统的混沌工程建立在一个默认的假设之上：如果你两次注入同样的故障，你会得到两次同样的失败。停掉 pod，观察故障转移，修复漏洞，再次停掉 pod 以进行确认。整个学科——假设、爆炸半径、稳态指标——都假定系统具有足够的确定性，使得实验是可重复的。

智能体系统从根本上打破了这一假设。在智能体运行过程中注入工具超时，模型会重新规划路径——有时它会重试，有时它会换一个工具，还有时它会自信地编造一个从未获取到的结果。针对相同的提示词运行相同的故障，你最终会得到不同的轨迹，因为故障路径是通过一个随机规划器（stochastic planner）运行的。上周二你在生产环境中看到的故障永远不会以完全相同的形式再次发生。而这恰恰就是你必须对其进行演练的原因。

GraphQL 的核心赌注是客户端应该能够自主组合其数据需求。在过去的十年里，这个赌注大体上是输了——因为客户端是由人类团队组成的，而他们根本不想组合任何东西。前端工程师想要的是一个可以调用后就不用管的稳定端点。GraphQL 推销的灵活性是以解析器复杂度（resolver complexity）、缓存变通方案和安全审查为代价的，而换取的收益——按请求进行字段选择——对于已知的、变化缓慢的 Web 应用来说几乎毫无必要。到 2024 年，从业者的共识已明显降温：大多数内部 API 只服务于两三个已知客户端，一个设计良好的 REST 端点或 BFF 层就能很好地覆盖这些需求。

接着，一种新型的客户端出现了。AI 智能体没有固定的一套屏幕。它根据每个任务决定自己需要什么数据，并且它为响应的每一个字节付费——字面意义上是在为 Token 付费，而在认知意义上，随着上下文窗口被没人要求的字段填满，推理能力也会随之下降。真正能够自主组合数据需求的客户端终于出现了。只是它不是人类。

几乎每起事故的前 15 分钟都是机械式的。拉取每个人都会拉取的那四张图表。对比事故开始时的部署差异。检查今天翻转了哪些功能标志（feature flags）。在运行手册（runbook）维基中搜索错误字符串。这些都不需要判断力——它只需要你保持清醒，而在凌晨 3 点，你的值班工程师正把这些时间花在找笔记本电脑、加入语音会议（bridge），以及回忆哪个仪表盘才是真正有用的那个。在人类解锁屏幕之前，智能体（agent）就可以完成这一切。

然而在大多数组织中，关于 AI 在事故响应中应用的讨论往往止于一个段子：“我们听说有个团队的自动修复脚本搞垮了生产环境。”于是，整个想法就被禁绝了——不是限制范围，不是分阶段实施，而是直接禁绝。这是一个范畴错误。那些恐怖故事讲的是自主权阶梯的最顶层，而团队的反应却是拒绝踏上最底层。在最底层，智能体没有任何写入权限，它能做的最坏的事情也就是在 Slack 里发了一段错误的话。

你用过的每一个无代码平台，其定价基准都是相同的：雇佣工程师的成本。这就是其核心卖点。编写真正的软件需要稀缺且昂贵的人才，因此这些平台向你推销了一种交易——牺牲灵活性，接受沙箱的限制，作为交换，你的运营经理可以自己发布库存仪表盘，而不必在工程积压名单中等待六个月。这笔交易在过去十五年里是合理的，因为基准一直成立。代码始终是昂贵的。

然后，基准崩溃了。当一个编程智能体能够以低于 Retool 一个席位的月费，构建并维护一个真正的应用程序——即托管在仓库中、拥有你自主掌控 Schema 的真实代码时，拖拽式抽象就不再是捷径，而变成了天花板。你现在是在支付溢价，只为了被“阻止”拥有真正的软件。

但这是大多数“讣告”都搞错的地方：这些平台并不会消亡。聪明的平台已经在向那些与代码成本无关的方向转型——受监管的数据访问、经过验证的集成，以及成为 IT 部门已经批准的沙箱。内部工具的限制因素正从“谁能构建它”转向“谁被允许构建它”，这一转变重写了你评估整个内部工具栈的方式。

给编程智能体一个 Python 模块，它是在坚实的基础上运行的：磁盘上的文件就是程序。阅读它，编辑它，运行它，观察结果 —— 闭环达成。给同一个智能体一个 Jupyter notebook，所有这些假设都会悄然瓦解。智能体充满信心地编辑第 12 个单元格，却不知道你一小时前曾用不同的数据重新运行过第 3 个单元格，也不知道一个在早已删除的单元格中定义的变量在内核中仍然处于活跃状态，更不知道它刚刚在第 7 个单元格下读取的输出是三次内核重启前由一段已不存在的代码生成的。

Notebook 是一个披着文件外衣的 REPL。磁盘上的 .ipynb 看起来像源代码，但真正决定行为的东西 —— 内核累积的内存 —— 是不可见的、未序列化的，并且是由产生它的那一连串人工点击所塑造的。智能体是基于“代码决定行为”这一契约训练出来的。Notebook 废除了这一契约，而大多数智能体框架甚至对此一无所知。

你的下一次定级会（calibration meeting）存在一个没人愿意点破的衡量问题。委员会面前的材料显示，一名工程师在这半年提交了 340 个 PR，而另一名只提交了 90 个。五年前，这种差距意味着某些实质性的东西。而今天，它主要告诉你的是谁拥有更好的 Agent 工具链，谁的团队拥有更宽松的审查文化，以及谁对合并生成代码的容忍度更高。幻灯片上的数字衡量的是机群（fleet）。而委员会本应评估的是人。

这并非某种未来才会发生的虚构趋势。行业分析估计，在认真采用 Agent 的公司中，AI 编写的代码已占提交代码的 30% 左右；一项针对 300 名工程师的纵向研究发现，在采用 Agent 后，团队生成的 Pull Request 数量增加了 98%。你的评审流程从“前 Agent 时代”继承下来的每一项产出指标——代码行数变化、合并的 PR 数量、Story points、速率（velocity）——现在都是人类判断力和机器吞吐量的混合衡量，两者之间没有明确的归因界限。定级委员会正在比较这些混合数字，就好像他们仍在衡量人一样。

询问任何基础设施团队，要求将生产数据库恢复到昨天下午 3 点的状态，他们会向你提供一份操作手册 (Runbook)、一个 RPO 以及一份预估时间。但如果询问同一个团队，要求将 Agent 恢复到昨天下午 3 点的状态——在它吸收一批中毒的记忆之前，在有人发布错误的提示词版本之前，或者在那个悄无声息地破坏了检索的重新索引之前——你得到的将是沉默。这并不是因为各个组件缺乏备份，而是因为没有人能说出“下午 3 点的 Agent”究竟意味着什么。

这是每个运行学习型 Agent 的团队都会面临的尴尬发现：你的数据库有快照，你的代码有 git，而你的 Agent——那个用户真正与之交互的东西——两者都没有。它的运行状态散落在向量索引、一堆记忆文件、提示词注册表和一套工具配置中，这些组件要么各自拥有独立的版本，要么根本没有版本。仅恢复其中任何一个都无法找回昨天的 Agent。你得到的只是一个逻辑破碎的大脑。

这是一个在每一个发布 Agent 的团队中都会重复发生的迁移故事。你基于某个供应商的 SDK 构建了你的 Agent。工具定义以该供应商预期的 JSON Schema 形式存在。工具结果被格式化为该供应商的消息结构。接着，某些原因迫使你做出改变 —— 竞争对手发布了更好的模型，采购部门为了冗余要求引入第二个供应商，或者一个 MCP 服务器取代了手写的集成 —— 然后你发现迁移的真正工作量：它不仅仅是一个 API 客户端。它是代码库中的每一个工具定义、每一个结果格式化器、每一个重试处理器以及每一个测试固件。

失败的原因并不是你选错了供应商。而是你让别人的序列化格式变成了你的内部架构。针对这个问题，早在二十年前就有了一个答案 —— Alistair Cockburn 的六边形架构，更广为人知的名字是“端口与适配器” —— 而 Agent 系统是它多年来最引人注目的新用例。

1980 年，Jon Postel 在 TCP 规范中写下了一句话，这成为了互联网的奠基原则：“对自己发送的内容要保守，对接收的内容要宽容。”四十年来，工程师们将其应用到各个角落——容忍尾随逗号的解析器、将 "10" 强制转换为 10 的 API、静默修复错误标记的 HTML 渲染器。可以说，万维网之所以存在，是因为浏览器宽容了所有人的错误。

然而，当调用者不再是人类时，这条建议就反转了。当一个 AI Agent 调用你的工具并传入字符串类型的数字、嵌套错误的 JSON 对象，或者一个 几乎 正确的枚举值时，那个原本能节省人类开发人员 20 分钟调试时间的宽容解析器，对 Agent 来说却造成了更糟糕的后果：它确认了这个草率的调用是正确的。Agent 在循环中唯一的训练信号就是你的工具返回的反馈。接受垃圾数据，你就在教导模型——就在此时此刻，在这个会话片段中——垃圾数据是行得通的。

你的 CI 流水线固若金汤。容器镜像在部署前经过签名和验证。每个 npm 和 PyPI 依赖项都根据带有固定哈希值的锁文件进行解析。提交需要签名标签。然后，在你模型服务启动脚本的某个地方，有一行代码从模型中心或 S3 存储桶下载数 GB 的二进制大对象（blob）并将其加载到内存中——没有签名检查，没有哈希验证，也没有生产者的记录。这个对你产品实际功能起决定性作用的唯一制品，偏偏是你的供应链工具从未听说过的那个。

这并非虚构的漏洞。安全研究人员已经从公共中心撤下了数百个恶意模型——这些模型在你加载它们的瞬间就会执行攻击者代码，它们是专为绕过中心运行的扫描器而精心设计的。弥补这一漏洞的工具现已存在：安全序列化格式、行业签名规范、以及拒绝未签名权重的准入控制器。大多数团队只是还没意识到，“模型文件”与“来自互联网且未经审计的二进制文件”在本质上是同一类东西。