内容归档
按栏目浏览往期内容，用关键词、分类和日期找到需要的信息。
OpenTofu 是一个开源的、用代码描述和管理云资源的工具（类似 Terraform）。以前执行“计划”时，有些值要等真正部署才知道，导致很多表达式算不出来、计划结果不够完整。1.13 版新增 convert 和 assume 等函数，让模块作者提前告诉计划器这些未知值是什么类型、大概是什么值，于是更多表达式能在计划阶段算出来。如果这些“假设”到实际部署时不成立，OpenTofu 会报错提醒。这样读者能在部署前看到更完整的计划、更早发现问题；不过这些函数的具体用法文中没有说明。
数据库公司 PingCAP 确认其内部系统被未经授权访问，源代码和客户相关数据被盗。一个名为 FulcrumSec 的勒索团伙声称窃取了 10.6 TB 数据，包括 TiDB Cloud 的控制面记录、客户 SQL 语句、API 密钥、连接日志、账单信息、内部文档以及 413 个私有源代码仓库。这次事件意味着使用 TiDB Cloud 的客户可能面临密钥和业务数据外泄的风险。目前材料未说明泄露范围核实情况、修复措施和受影响客户数量。
PHP 发布了 8.5.12、8.4.27、8.3.36 和 8.2.35 四个版本，修复两个严重的远程代码执行漏洞（远程代码执行指攻击者无需登录就能在服务器上运行自己的代码）。亚马逊在这批补丁发布前四天就记录到了一次利用尝试，说明漏洞在修复前已被攻击。运维人员当天忙着确认自己是否运行 PHP、从哪里获取升级包，以及如何验证补丁已经生效。对读者的用处是：如果你或你的团队在用 PHP，应尽快升级到对应版本，并检查是否已被利用。文章未说明漏洞具体细节、受影响范围细节，也未说明各版本的发布时间差异。
提供的材料未提及具体可用工具。
Cloudflare 优化了其内部负载均衡服务中一致性哈希的 Rust 实现（pingora-ketama），把这项服务占用的内存减少了 100 TB 以上。原来的问题是：每个后端服务器要在哈希环上保存很多哈希条目，条目越多占用内存越大。这次的做法是压缩哈希环上的条目，并通过统计分析哈希分布和冲突率，把每个后端所需的哈希数量减少了约 90%。对读者来说，这说明大规模系统里看似不起眼的数据结构优化，也能省下巨量内存资源。
Google 把 Data Agent Kit 正式开放使用了。这是一套免费工具，包含 MCP 工具和 37 个开源技能，能让写代码的 AI 助手直接连接 Google 数据云的 15 种以上服务。它带了两道护栏，但作用不一样：一道是写在技能里的提示，让 AI 助手自己停下；另一道是 IAM 拒绝策略，在权限层面直接拦掉请求，AI 助手想绕也绕不过。对使用者来说，这意味着能连的服务变多，但需要分清两种护栏的强弱，不能把提示当成硬性限制。
Monzo 的工程师 Suhail Patel 分享了这个团队如何做到每天安全上线数百次。他们的做法是：把微服务封装成有明确规范的抽象层，按租户隔离搭建预发布环境，加入静态分析检查，并持续做性能剖析。这样一套强大的内部平台让工程师和 LLM 都能快速迭代，同时不牺牲可靠性。对读者来说，这提供了一个高频率发布同时守住稳定性的工程组织样本；不过这是演讲内容，文中没有说明具体落地效果或工具细节。
提供的材料未提及具体可用工具。
作者 Vivek Arora 写了一篇关于多云架构成本优化的文章。多云用起来灵活，但服务放在哪个云、服务之间怎么通信，会产生不少隐蔽的“出网费”（数据跨云传输要付的钱）。文章给出一个工程做法：用 FOCUS 标准把各云的费用统一看清楚，再考虑负载怎么摆放、数据怎么同步，并把成本检查加进 CI/CD 流程。作者还做了对照实验，发现改架构比单纯谈折扣省得多。读者可以据此判断：光砍单价不如先动架构。具体实验规模、FOCUS 版本和 CI/CD 集成细节原文未说明。
AWS 最近推出了 Lambda Web Functions。以前，想把用 Express、Hono 这类常见 Node.js 框架写的网页应用放到 Lambda 上运行，需要额外做不少适配工作；现在可以直接运行，并且支持同时处理多个请求和流式返回响应。对于用这些框架开发应用的开发者来说，迁移到 Lambda 会更省事。目前原文只说是“推出”，没有说明是否已正式可用、有哪些限制或价格细节。
澳大利亚科研机构 CSIRO 做了一个叫 Serverless Beacon 的系统，用来查询基因组变异。以前的难点是：要查变异数据，通常得先把体积庞大的 VCF 文件整个复制进一个中心数据库，费时费钱。新办法不搬数据，而是直接用 Amazon S3、Lambda、Athena 和 DynamoDB，配合元数据索引和对压缩文件的 HTTP 字节区间读取，只取需要的那一小段来查。测试中，查询 1 万个碱基对平均耗时 1.52 秒。对研究者来说，这意味着不必先复制整份数据就能更快检索变异信息；不过目前只是测试结果，是否已开放使用原文没说。
一位开发者用 Claude Opus 5.5 做出了七个 Adobe 应用的开源替代品，并在 Reddit 上宣传，声称大约一个月内就能达到接近 100% 的功能对齐。但随后他在 Hacker News 上承认，这个项目“远未准备好”。项目自己的路线图显示，它目前只有 45% 能满足实际工作需求，要达到完全对齐还需 2300 到 4100 个智能体小时。也就是说，这些工具目前仍处于早期阶段，暂时还不能当作 Adobe 的可靠替代品使用。
作者 Peihao Yuan 介绍了一套用于灾难恢复分析的工作流：AI 智能体只负责生成受限的 SQL 或 Python 代码，真正的计算交给嵌入式数据库 DuckDB，从 Parquet 文件中算出可复现的结果，再由智能体解读这些结果。文章的核心观点是：AI 改变的是人和数据打交道的方式（接口层），而不是负责算数的查询引擎本身。文中还讲了如何把“生成”和“计算”分开以保证结果可重放，并给出四个判断信号，帮读者决定什么时候用嵌入式引擎就够、什么时候值得上托管的湖仓方案。
Manju Rajashekhar 做了一场演讲，讲怎么用 Actor 模型解决生产环境中 AI 智能体运行时的麻烦。Actor 模型可以简单理解成：每个“小工人”（Actor）只管理自己的状态，彼此只靠发消息协作，谁出问题就单独处理。演讲把智能体看成分布式系统，围绕状态由谁持有、消息传递、写穿状态（状态一变就立刻写入持久存储）和监督边界（谁来发现并处理故障）来设计，从而应对失败、任务续接和可动态变化的执行图。这样智能体工作流就能从容易崩溃的演示，变成更稳定、可恢复的架构。目前只是演讲分享，材料没有说明有可用的代码或产品。
提供的材料未提及具体可用工具。
哈佛大学最近调查了 718 家公司，借助 Jellyfish 分析平台的数据，想看 AI 编程助手和智能体到底能不能帮上忙。结果发现，这些工具确实让写出的代码变多了，但真正完成的工作量并没有跟着涨。原因之一是 AI 生成的代码给开发后段添了麻烦，尤其是代码审查环节负担加重——写得多不等于交付得多，前面的速度被后面的检查卡住了。对普通开发团队来说，这说明光靠 AI 多写代码不够，还得关注审查和后续环节能不能跟上。
作者 Janardhan Reddy Chejarla 介绍了一种分布式 Spring Batch 分区方案：通常这类任务需要一个持久共享的作业仓库数据库，同时往往还要靠消息代理来协调各节点。这篇文章把那个数据库直接当作唯一的协调中心，不再使用消息代理。做法是根据当前在线节点数分配工作量，每个作业临时选出一个主节点而没有常驻协调者，用比较并设置的方式认领任务以避免重复执行，并用两阶段心跳实现故障转移。文章也说明了在什么情况下仍然应该使用消息代理。
InfoQ 正在推出一组由行业专家撰写的系列文章，提出把“智能体 AI 架构”当作一种新的软件架构来看待。过去大家谈 AI 应用，多是把模型当成一个功能嵌进系统里；这组文章想说明，当 AI 智能体能自己规划、调用工具、协作完成任务时，系统该怎么设计、有哪些要素和最新做法。文章认为这类架构可能在未来几年成为行业主流。读者可以借此了解一个新架构方向的全貌和趋势，但原文没有给出具体文章篇目、发布时间和落地案例，这些信息暂未说明。
提供的材料未提及具体可用工具。
Netflix 为跑在 Amazon EMR 上的 Apache Spark 任务做了一套“工作负载证明”机制。打个比方：过去托管计算任务要访问内部服务，得把内部凭证直接塞给任务，凭证容易泄露、也难管理。现在的做法是先确认这个任务的 AWS IAM 身份，再核对 Netflix 控制面签发的声明，两者都通过后，才发一张有效时间很短的内部 X.509 证书，任务用它去访问内部服务。这样托管计算任务不必直接携带凭证，就能安全地完成内部认证，凭证暴露的风险和分发负担都小了。这套机制目前应用在 Netflix 的 Spark/EMR 场景，其他场景是否适用文中未说明。
证书机构 eMudhra 的八张中间 CA 证书私钥被泄露了，这意味着攻击者可以伪造任意网站的证书，冒充网站身份。问题不是来自已知的黑客入侵，而是这些密钥本身的随机性太差（熵太低），容易被猜出来。浏览器通过吊销列表挡住了这些证书，但其他软件需要直接移除 emSign ECC G3 根证书才行；没有打补丁的系统仍然可能被伪造证书欺骗，包括客户端认证和 mTLS 场景。
提供的材料未提及具体可用工具。
开源项目 TornadoVM 发布了 7.0 版本，它是一个帮 Java 程序跑得更快的工具。以往 Java 代码想用 GPU 加速，往往要写复杂的底层代码；TornadoVM 会自动把 Java 程序分配到多核 CPU 和 GPU 上执行，并提供一套在 Java 里开发 GPU 程序的生态。它能配合 Temurin、Red Hat OpenJDK、Corretto、Oracle、GraalVM、Zulu 等主流 JDK 使用。对用 Java 做高性能计算的开发者来说，这有望在不换语言的情况下获得 GPU 加速；目前原文只提到版本已发布，具体性能提升和限制未说明。
两位工程师做了一场演讲，讲的是怎么把 AI Agent 从本地开发时用的 FastAPI 小原型，搬到 Kubernetes 上、用 Ray 撑起来的正式生产环境。他们分享了实际操作中的经验：Ray 集群怎么搭、有状态记忆怎么存、流量忽高忽低时怎么自动扩缩容，以及控制平面怎么设计得稳。另外还提到几道关键防线：安全护栏、多区域部署，还有让大模型当裁判来给 Agent 打分的评测流程。对做 AI 应用落地的团队来说，这些是从“能跑”到“撑得住”的参考经验。这只是一场演讲分享，相关工具和做法没有说明是否已经开源或可以直接拿来用。
文章讨论分布式系统从微服务走向智能体式 AI 架构的转变。过去微服务是把系统功能拆成小服务，各自负责一块；智能体式架构则是把“做决定”这件事拆开，交给多个能自主判断的 AI 智能体。作者指出，这种变化会让可观测性（看清系统内部发生了什么）、可靠性和整体设计都变得更复杂，因此需要更新原有的架构模式和实践。文章由 Mallika Rao 撰写，但目前只有摘要，具体方案和落地效果原文没有说明。
提供的材料未提及具体可用工具。