让我们想象一下昨晚各公司运维老哥的一晚⬇️ 你是一名运维。 你司的边缘节点跑着NGINX 1.23.0，后面挂着PHP-FPM 7.3的源站。这个7.3，是你刚花了几周时间，从5.6一点点升上来的。 企业新官网刚用Next.js 16.0.7的App Router翻新，旧官网还挂在WordPress上。业务说有几个历史页面还要用，暂时不能下，所以新旧两套都归你管。数据库则是前段时间刚花大价钱采购的TiDB，领导对这次基础设施升级很满意。 Node.js 24 LTS的服务开着Brotli压缩，Go写的网络沙箱负责控制对外访问，公司维护的Rust服务里还嵌着Wasmtime，用Cranelift编译执行WASM模块。所有服务器的Linux内核，刚好还没合入c6e50df8。 公司前几年赶上区块链热潮，还留着一套Vyper写的智能合约。合约在链上，配套后端跑在Docker 29＋Kubernetes上，入口交给Traefik，配了mTLS，偏偏踩着配置冲突时fail-open的坑。宿主机上还顺手跑着ASP.NET Core管理面板和几个.NET本地服务。 网站的HTTPS用的是前段时间刚买的低价Sectigo DV证书，ACME自动签发还在排期。公司软件的代码签名、外发机密文件的文档签名，用的都是emSign。几套系统的证书校验和信任根，又分别涉及Go crypto/x509、Rust webpki-roots和Python certifi。 当然，公司也没有错过这一轮AI大跃进！ 你们用Python＋LiteLLM搭了一套企业内部Harness。为了让大家及时用上最新能力，CI昨晚刚从PyPI拉了新包，把LiteLLM更新到了1.107.0，随后一路推到生产环境。 全公司电脑都装上了，部署覆盖率100%，一个都没漏。 昨晚，你值班摸鱼到一半听到钉钉响了，你打开了安全群，发现里面有个小小的公告。 你很平静的看完了公告，去翻资产清单，一边想：行，先排优先级，能补一个是一个。 结果刚准备拉补丁，GitHub又双502了。 你决定先走公司自建的GitLab，把应急变更推上CI。点进去才发现，国内某个未成年脚本小子，拿着ARTEX和OpenCode里免费的DeepSeek V4.1 Flash，顺着PVE 7.4的漏洞一路横向移动，已经把你们的GitLab也打穿了。 你下意识想打开公司的AI工具，让它帮忙整理一下排查步骤。 手放到鼠标上，又想起了刚才那个公告里好像有LiteLLM的名字。 这时候，老板发来一条消息： “辛苦一下，明早九点要给客户演示。尽量别停业务。” 而你，是这家公司的唯一的on-call运维。

真的草台班子，小米运动算法被网友用DeepSeek发现一个低级bug😅 这位V2EX用户最近在减肥，觉得运动量差不多，热量数据却忽高忽低，于是让DeepSeek帮忙查了查。 按他的测试，正常走54步，记录2.16卡；边走边下拉刷新，走40步却记成了8.28卡。按他分析出的公式，40步本应记1.6卡。 他贴出的数据恰好符合一种情况：同一分钟内，每次更新都把当前累计热量再加一遍，前面走过的步数被反复计算。 也就是说走路时反复刷新，记录的卡路里会越算越多。 很明显小米的研发们没考虑到这个场景下刷新的需求..... 看起来是数据更新逻辑出了问题，用户只是多刷新了几次，App就给他多记了几笔热量消耗。

连5.6Sol都可以找到这个漏洞（

完蛋了，全球56%的互联网今晚可能会被打穿…. 刚看到群里在传PHP2Shell的消息，PHP发出严重漏洞预警，计划于今晚22点发布安全更新。 查了一下，PHP官方确实已经发了预告：这次将修复两个CVSS v4.0评分均为9.2的严重漏洞，提醒所有PHP用户提前做好升级准备。 公开预警列出的漏洞编号sCVE-2026-109618和CVE-2026-109619。根据CERT-EU的公告，漏洞可能导致远程代码执行，潜在影响范围覆盖PHP5及以后的版本。 具体哪些版本、哪些部署条件受影响，还要等官方公布完整细节。 更麻烦的是旧系统。目前PHP官方支持的稳定分支是8.2、8.3、8.4和8.5，8.1及以下版本已经结束官方支持。还在维护这些系统的团队，需要尽快确认自己的修复渠道和升级方案。 有PHP业务的朋友，建议现在就确认运行版本和更新渠道，准备在修复发布后尽快部署。 对于暂时无法修复的对外服务，CERT-EU建议考虑先隔离公网访问。

再说一遍，二次元搞技术最狠了

🚨Anthropic上半年净亏损807亿美元。。。 据路透社10月20日援引其查阅的 @AnthropicAI 招股书草稿披露，这笔亏损中，约720亿美元来自可转股融资工具的公允价值上升。 随着公司估值上涨，相关融资工具重新计价产生的损失被计入报表，因此，807亿美元需要与公司实际经营中的现金消耗分开看。 收入端，Anthropic今年上半年营收达到163亿美元，去年同期为11亿美元。 同期，Anthropic在算力和基础设施上的支出接近90亿美元，已经超过去年全年约73亿美元的水平。 Anthropic在10月14日的投资者会上表示，第三季度营收达到168亿美元，环比增长约45%，并按调整后口径实现盈利。 更大的投入还在后面。《华尔街日报》报道称，Anthropic承诺的未来云计算和芯片使用等投入超过6000亿美元，另有约1500亿美元的潜在交易仍在洽谈。 这些金额涉及未来多年的安排，部分交易尚未落地。 据路透社报道，Anthropic计划于11月上市。随着收入环比增速放缓，部分投资者开始讨论约1.5万亿美元的估值，低于此前约2万亿美元的预期。 目前，这仍是部分投资者的讨论水平，发行估值尚未确定。

笑死我了，才发现DeepSeek在官方部署DeepInfer文档里，专门提醒了一件事：小心光纤被施工挖断🤣 原文讲到在V4.1 Flash的部署问答里，DeepSeek解释，由于KV缓存被大幅压缩，处理输入的Prefill和生成输出的Decode，在技术上可以分开放到不同的数据中心，建议每8张GPU预留约400Gbps的互联带宽。 讲到可靠性的时候，文档非常认真地举了个例子：数据中心之间的光纤容易被施工挖断。 后面还补充了一句，DeepSeek自己的推理节点，就部署在不同但相邻的数据中心里。 合理怀疑是不是之前DeepSeek遇到过这样的情况🤔

人类完蛋了。

哈，才发现 @OpenAI 更换了他们的Logo！

分享一个对做harness层的家人们很有价值的bench：GACC-Bench，目标自适应上下文压缩评测。 这个bench关注的问题是：Agent执行长任务时，积累的上下文越来越多，需要把其中的信息压缩下来。 但压缩的时候，我们通常只知道接下来要完成什么目标，还不知道具体会遇到哪些问题。 比如让Agent修一个bug，前面查过哪些文件、排除了哪些原因、用户强调过什么限制，都可能在后续步骤里用上。如果压缩时漏掉了这些信息，Agent就可能重新走一遍已经走过的弯路，或者把重要约束忘了。 GACC-Bench的设计就很贴近这个场景： 压缩时只给模型原始上下文、目标和token预算，隐藏后续问题。压缩完成后，再让固定的模型拿着同一份压缩结果，分别回答这个目标下的多个问题。 这样可以检查，压缩后留下的信息，能否支撑后续不同的需求。 目前基准覆盖7个来源、281份上下文、500个目标和2571个问题，包含文档、代码和Agent交互轨迹，所有样例均经过专家人工审核。 团队评测了10款模型，结果当token保留预算设为原文的10%时，表现最好的模型，也只有14.8%的目标能做到关联问题全部答对。使用完整上下文时，这个比例是96.8%。 需要说明的是这里统计的是一个目标下所有问题都答对的比例，对信息保留的完整性要求很高。 还有一个对harness设计很有启发的结果：在消融实验里，带着正确目标去压缩，效果持续优于不提供目标。给了不匹配的目标，表现反而更差。 压缩时传进去的目标，会直接影响模型选择保留哪些信息。 改压缩提示词、换压缩模型、调整记忆的组织方式之后，可以在相同预算下，具体比较这些改动有没有留下更多后续需要的信息。 Agent要持续工作，上下文管理就是harness里值得认真优化的一环。 这类bench给了我们一个更明确的评测入口。 数据、评测代码和提示词都已开源，做上下文压缩和Agent Memory的朋友可以看看。

这条推的笑点是⬇️