夜雨聆风AI新闻深度解析｜2026年6月7日
今日挑选 2 条：① 一线工程师亲述 Claude Sonnet 4.5 升级翻车——LLM 系统的"无限爆炸半径"问题；② Asana 自爆数据：75% 员工用 AI、5% 拿到产出，症结在"共享记忆"断层。
1. Claude 一行升级，生产环境全员翻车：LLM 的"无限爆炸半径"问题
发生了什么
6 月 5 日 VentureBeat 上一篇由 Adopt AI 创始工程师 Vijay Sagar Gullapalli 和 Sherwin-Williams 高级工程师 Sarat Mahavratayajula 联合署名的工程复盘，在英文 AI 工程圈炸了锅。复盘的是一次真实的、未经任何夸张的生产事故。
Adopt AI 内部有一套文本到 API 的"自然语言报表系统"：用户用一句"给我 2026 年 1-3 月东北区按城市拆分的销售额"换出一个结构化 JSON，调度到内部接口，返回邮件 / Drive / 浏览器图表。2025 年中这套系统每月出几百份报表，成了分析师、运营、对外汇报的事实标准。
- 2025 年初跑在 Claude Sonnet 3.5 上，3.5 → 3.7 → 4.0 升级一路"无事件"（no incident）。作者原话："我们已经对 LLM 在解决这个看似简单问题上的稳定性和可预测性变得自满。"
- 4.5 一上线，两个新故障模式同时出现：
- 模型开始把
post_body字段的内容"折叠"进description字段，筛选参数传不到 API，后端要么返回"全部时间 / 全部区域"数据，要么直接 500。 - 4.5 "变得更谨慎"，遇到模糊请求时开始反问澄清问题。而这套系统是按"每次模型调用都对应一个 API 调用"假设设计的——没有 human-in-the-loop、没有部分完成的中间态。一旦模型回复"请问时间区间是？"下游全部连环崩。
- 紧急回滚到 4.0 也不轻松：4.0→4.5 之间接入的多个新 API 都是按 4.5 行为做的兼容性测试，回滚意味着时间压力下重新对每个 API 跑回归。
为什么重要
作者把这种故障模式命名为 "infinite blast radius"（无限爆炸半径）。这是过去三十年软件工程几乎没人认真讨论过的概念。
传统软件工程建立在一条默认假设上："组件的行为是可以被边界化的"。升级一个驱动，读 release notes；改一段代码，单元测试告诉你哪些路径可能受影响；部署前灰度、看监控。爆炸半径由设计决定——你写不出能访问任意内存的代码，写不出能控制任意指针的库。LLM 系统把这层边界一把撕掉：
- 你不能"diff"一个模型版本号。从 4.0 到 4.5 不是"行为等价"的功能升级，是对你依赖的功能的整体替换。
- 输入空间是自然语言，开放无边。
- 失败模式是"模型可能做的任何不同的事"，同样开放无边。
- 也就是：爆炸半径在构造上就是无限的。
更狠的是 post-mortem 给出的根因——bug 不在模型，在 prompt 的隐式假设。他们 3.5→4.0 三次无事件，已经把"3.x 系列会好心补全我没说清的约束"当成了系统的一部分写进肌肉记忆。4.5 推理能力变强后，"好心补全"的方向变了——它把 post_body 序列化成 description 写进去"更利于人读"，它"主动问"而不是"best-effort"——都是合理推理，只是和系统原先的隐式契约对不上。
作者由此得出这篇复盘最值钱的结论：
把 eval（评估集）当作系统的正式规范，把 prompt 当作规范的实现，把模型当作解释器。
具体三层： - prompt 是 spec 的实现（"告诉模型返回三字段 JSON，描述各字段用途"），不是 spec 本身。 - 模型是解释器（会按自己对规范的推断来填空白），不是 spec。 - eval 才是 spec——一组 (输入, 输出必须满足的属性, 评分函数) 的三元组。任何模型或 prompt 改动，必须先让这套三元组全绿才能合并。
他们给出了一个针对 4.5 翻车能拦住的具体 eval 例子：
def test_description_contains_no_serialized_payload(response):
desc = response["description"].lower()
forbidden = ["curl", "post_body", "{", "http://", "https://"]
assert not any(token in desc for token in forbidden), \
f"description leaked structured content: {response['description']}"
几百个这样的属性断言——手写的（覆盖已知重要不变量）、从真实生产流量生成的（覆盖回归）、LLM-as-judge 的（覆盖语气这种模糊属性）——组合成一道闸门。模型升级和 prompt 改动都要走 PR 流程，evals 跑通才允许合并。
但作者也坦白：evals 不是银弹。三件事让"评估门"本身很难搞： 1. evals 构建和维护很贵，会随产品漂移； 2. LLM-as-judge 的评分函数本身有方差； 3. 你只能拦截你想到过的失败模式——他们之所以没拦住 4.5，正是因为从没写过"description 字段不应该包含 curl 命令"这种断言，"因为没人会想到模型会把 curl 塞进去"。
这才是 2026-2028 年 AI 工程真正的核心难题：当 agent 接管写代码、转账、调度基础设施这些"自主行为"时，"模型通过了冒烟测试"和"我知道它上线后会干什么"之间的 gap，就是下一个十年最大的工程鸿沟。
值得关注的点
- 传统 CI/CD 体系 vs 概率性测试的兼容性：现在的 CI 是为"测试全过 / 测试失败"二元设计的，evals 是概率性的。Jenkins、GitHub Actions、Argo 这套流水线未来 18 个月会被迫改造——可能直接催生一批"eval-native CI"工具（已经能看到 Honeycomb、LangSmith、Braintrust 在做）。
- 结构化输出 / 工具调用 API 的边界：作者承认 structured output / tool-use API 能在 schema 层拦住 4.5 这种翻车，"我们没用是工程原因不在本文范围内"。但他们点出关键：schema 只能约束语法，约束不了语义——"系统没有澄清路径时 description 不应包含澄清问题"或"时间区间不应静默默认成全时段"这种语义约束，schema 写不出来。这是 Anthropic、OpenAI、DeepSeek 这些模型厂商未来 12 个月产品演进的核心战场。
- Anthropic 的版本节奏 vs 客户的爆炸半径控制：Anthropic 现在大约 4-5 个月一次主版本，每次都是"评估门"上的一次赌博。已经有客户开始冻结模型版本（OpenAI 这边 Azure 客户冻结 GPT-4 长达 18 个月）。未来"模型版本控制 + eval 套件 + 自动回滚"会像当年数据库 schema migration 一样变成必选项——能提供这层保险的中间层（OpenRouter、Portkey、自己的代理网关）会变成企业 IT 的硬预算。
- Adopt AI 这家公司的位置：它本来就是做"agent 生成 / 编排"平台的，这次复盘等于公开承认"我们自己的 agent 在自家 prompt 升级时也会翻车"——但也由此把"evals 是 spec"这条工程哲学公开化了。这等于在 agent 编排赛道里立了一个新标杆：能不能给客户交付一套 eval 套件 + 自动回归门 + 回滚策略，将成为客户选择 agent 平台时的核心采购指标。
2. 75% 员工用 AI，5% 公司看到产出：Asana 捅破企业代理的"共享记忆"断层
发生了什么
6 月 5 日 VentureBeat 另一篇直击企业 AI 落地的报道，引用了 Asana 自己的研究数据：75% 的知识工作者在工作中使用 AI，但只有 5% 的企业报告了生产力提升。 70 个百分点的落差，是当下企业 AI 落地最刺眼的一个数字。
Asana CPO Arnab Bose 给出的解释是：模型供应商在"推理 + 重试循环"上已经做得很好，但没人解决"企业工作上下文如何在人类能推理的形式下进入共享记忆"这件事。
具体故障画像是：团队里有人给 AI 代理更好的 prompt、更好的反馈、更好的上下文，这种改进在他同事打开同一个工具的瞬间就消失了。下一个同事从零开始。在多代理工作流里这个 gap 会被放大——团队期望代理之间能共享上下文和行为，没有共享记忆层，每个团队成员就等于在训练"同一个代理的不同版本"，这些版本永远不会同步。
Asana 自己的解法是"Agentic Work Management"平台 + Context Graph（上下文图谱）：任何团队成员对代理的更正会自动同步给团队其他人，等于把"对 prompt 工程的依赖"从单个员工身上剥离。Bose 直接说："共享记忆架构的重要性超出了 Asana 自家产品本身——这是任何多代理系统都需要做的设计决策。"
第三方观点同步放出： - Collate 联合创始人 / CTO Sriharsha Chintalapani：缺乏共享记忆是多代理工作流（特别是涉及一致性时）的主要障碍。"组织应该停止把共享记忆当作单纯的 prompt 工程问题，而是思考如何在每次会话中重复上下文的系统建设。" - Zeta Global 首席数据官 Neej Gore：共享上下文会变成"在企业范围内复利智能"的活记忆。
两家大厂路线已经在分叉：Microsoft Copilot 走"个人优先"路线——学习用户在组织中的角色、语气偏好、工作模式，作为"个人记忆"存起来跨 Microsoft 365 使用；Asana 走"团队优先"路线——把 prompt 修正 / 上下文校正当团队资产沉淀。
为什么重要
这条新闻看着像产品宣传文，但把它和今天第一条"无限爆炸半径"放在一起读，能拼出当下企业 AI 落地最清晰的一张图：模型层（推理 / 工具调用 / 多模态）已经不是瓶颈，记忆 / 上下文 / 评估这三层"非模型"基础设施才是真正的卡点。
具体看三件事：
第一层：75% vs 5% 的 gap 不是模型问题，是组织记忆问题。 75% 说明"员工用 AI"已经不是门槛——办公套件、IDE、CRM、客服系统里 AI 几乎无处不在。但 5% 看到产出，说明这些 AI 在彼此不连接、不学习、不沉淀。一个销售用 AI 写邮件时学到的"客户偏好分四类"的隐性知识，不会自动传导给同团队另一个销售；一个工程师用 Copilot 调试时踩过的"SonarLint 误报"经验，不会自动沉淀到团队共享的代码评审规则里。结果是"个人提速"≠"组织提速"——甚至可能因为经验没沉淀反而出现"组织减速"（人员流动后所有 prompt 工程知识归零）。
第二层：模型层厂商被夹在两个"非模型"层之间。 OpenAI / Anthropic / Google 在强化推理和工具调用，但企业 AI 采购的下一个决策点已经不在"用哪家的模型"，而在"哪家平台能把团队记忆 / 上下文图 / 评估门做到位"。Asana 和 Microsoft Copilot 的路线分叉，本质上是在抢"组织记忆底座"这个新赛道——谁先把"团队上下文图"做厚，谁就在下一轮 AI 平台战争中拿到 2-3 年的护城河。
第三层：和第一条的"无限爆炸半径"互为镜像。 第一条说的是"模型升级时，系统的哪些隐式契约可能崩"；这一条说的是"团队协作时，代理学到的哪些经验会丢"。两个问题的共同本质是"我们没有给 AI 系统一个稳定、可审计、可版本化的契约层"——第一条的契约层是 evals，第二条的契约层是 context graph。这两条新闻合起来等于在说：2026-2028 年企业 AI 真正的护城河是"契约工程"——把 prompt、eval、memory、context 全部当成一等公民来版本化、审计、回归。
值得关注的点
- Microsoft Copilot vs Asana 的路线对决：Copilot 押"个人 AI 助理"，Asana 押"团队 AI 协作平台"。未来 12 个月看哪边拿到 1-2 个年付费 1000 万美元以上的标杆客户——这个标杆会决定中型 SaaS 的采购风向。
- Context Graph 的标准化时机：现在每个厂商（Asana、Salesforce、Notion、Atlassian）都在做自己的 context graph，但没有一个跨厂商的开放标准。如果 MCP（Model Context Protocol）在 2026 年内能演化成"代理间共享上下文"的协议标准，先发者拿到的是平台级红利；否则就会重演 SSO 早期那种"五六个标准互不相通"的乱局。
- 个人记忆 vs 团队记忆的合规分歧：Copilot 走"个人优先"意味着个人数据归个人所有，员工离职带走；Asana 走"团队优先"意味着公司对所有 prompt 修正有所有权。这个分歧在欧洲 GDPR / 中国个保法 / 美国州法（特别是 CCPA）下会演变成法务问题——法务部会倒逼采购方选 Asana 这条路，因为企业无法承担"员工离职后 AI 经验归零"的合规风险。
- 5% 数字本身的解读空间：5% 是 Asana 自报，样本和定义都可能偏向对 Asana 路线有利的口径。但即便是 Gartner / IDC 给出的"AI 项目成功率 30% 以下"或麦肯锡的"AI 转型 80% 失败"的数字，量级也类似。真正关键的不是 5% 还是 30%，而是"剩下 70%-95% 的项目失败原因"——如果 80% 都是"记忆 / 上下文 / 评估"这三层没做好，2026-2027 的 AI 中间层市场会出现一批 10 亿美元估值的独角兽。
本日报由自动化流程生成 | VentureBeat | 2026年6月7日
