内容浏览
搜索中文标题、仓库名或关键词，再用分类、来源和日期缩小范围。
移动应用安全测试（MAST）是在 App 发布前检查应用代码、内置 SDK 和运行时行为中漏洞的做法。已发布的应用相当于任何人都能下载分析的二进制文件，硬编码的密钥等于公开。MAST 把静态分析（SAST）、第三方依赖检查（SCA）和动态分析（DAST）结合起来，贯穿每次构建，而不是上线前只做一次渗透测试；OWASP MASVS 是参考标准，OWASP Mobile Top 10（2024 年更新）是常见的风险清单。文章还列出评估测试工具的五个标准，如覆盖二进制与依赖、按可达性排优先级、融入 CI/CD、跨扫描器结果去重、提供含预编译 SDK 的 SBOM。需注意文中未点名具体工具产品，也主要引用了一项 2026 年调查称 86% 的工程负责人希望安全检查更自动化。
提供的材料未提及具体可用工具。
ReadyOn 公司说明了他们的 Harmony 平台在 Amazon EKS（亚马逊的托管 Kubernetes 服务）上如何把不同客户的数据和计算资源隔开。原来多租户环境里，客户之间可能互相访问或横向渗透，这次用四层防护来解决：Kubernetes 命名空间、专用 Karpenter 节点池、VPC 安全组，以及每个租户独立的 Aurora 数据库。他们还用一个分 10 个阶段的多租户威胁模型来检验这些控制措施，重点看跨租户访问和横向移动。目前文章只讲了架构设计，没有说明是否已上线或开放使用。
OpenTofu 是一个开源的、用代码描述和管理云资源的工具（类似 Terraform）。以前执行“计划”时，有些值要等真正部署才知道，导致很多表达式算不出来、计划结果不够完整。1.13 版新增 convert 和 assume 等函数，让模块作者提前告诉计划器这些未知值是什么类型、大概是什么值，于是更多表达式能在计划阶段算出来。如果这些“假设”到实际部署时不成立，OpenTofu 会报错提醒。这样读者能在部署前看到更完整的计划、更早发现问题；不过这些函数的具体用法文中没有说明。
这是一期 Spring 官方播客的节目介绍，主持人 Dan Vega 和 DaShaun Carter 邀请 Java 冠军 Pratik Patel 聊 Java 开发者怎么用 Hugging Face。Hugging Face 上有超过一百万个开放模型，但大多数 Java 开发者从没用过，节目里讲了它到底是什么、怎么挑一个值得用的模型、现在从 Java 里运行开放模型有哪些办法，以及什么情况下开放模型比付费 API 更划算。对 Java 开发者来说，这期节目能帮你弄清楚要不要以及怎么在自己的项目里用上开源模型，而不是只能依赖付费服务。节目有直播可以提问，也能在播客平台听回放，但节目本身没有给出技术细节，具体怎么选、怎么跑要看正片。
Google Research 和斯坦福学习加速器推出了 AI Quests 系列的第三个教学项目“Polar Peaks”，面向 11 至 14 岁学生，让他们扮演 Google 研究员，通过扫描和绘制大脑神经元来理解游戏角色的记忆丧失，并完成数据清洗、模型测试等任务，从而学习 AI 需要人工监督和批判性思考。这个项目受 Google 十多年连接组学研究启发，该研究最近完成了迄今神经元数量最多的完整果蝇大脑图谱。系列已有超 40 万次任务完成、支持 10 种语言；同时新推出教师培训模块，前两个任务的模块已可用，第三个的模块将于下月发布。学生可以借此了解 AI 如何加速科学研究。
Fanatics 是一家体育周边商品零售商，它借助 OpenAI 的技术推出了一个叫“Shop the Look”的功能，帮球迷把比赛日穿搭搭配完整。此前球迷可能要在大量商品里自己挑选搭配，现在系统能直接给出整套造型建议。他们用大约 3 万件 MLB（美国职棒大联盟）商品做了测试，结果显示用户参与度提高了 10%。对普通球迷来说，挑衣服搭配更省事了，但目前只提到测试阶段的数字，正式上线范围等细节原文没有说明。
这篇文章讲的是在 Kubernetes 上跑 AI 任务的团队，常看到 GPU 全被占满、批处理队列越排越长，第一反应就是加 GPU。但作者提醒，GPU 被分配、在忙、和真正产出有价值的结果是三件不同的事，队列变长也可能是时机、服务容量或模型和硬件选型的问题。解决思路是先想清楚每个任务的截止时间和产出标准，再用错峰排队把现有四块 GPU 在两小时内跑完原本需要八块的四个任务，同时用接近真实负载的压测摸清可持续吞吐，并把 OpenCost 的成本数据和实际产出对上，算出每个合格结果花多少钱。这样读者能在花钱扩容之前，先确认现有容量是否已用足、瓶颈到底在哪。Kueue、vLLM、DistServe、OpenCost 等工具文中都有提到，具体接入方式原文未详细说明。
AWS 周四正式开放了名为 Continuum 的 AI 安全服务。它会自动在你的代码仓库里查找漏洞、复现问题，对照 AWS 环境验证，然后提交带修复方案的 PR。AWS 自己发布的测试显示，在 920 个 C/C++ 内存安全漏洞任务中，Continuum 有 89% 能找出并修好漏洞且不破坏原有测试，远超此前公开最高分 65.9%。不过这个分数是 AWS 自己跑的，还没第三方复现；而且只有 37.8% 的修复同时命中了测试指定的那个历史漏洞——因为智能体并不知道要找哪个洞。测试也只覆盖 C/C++ 一类问题。对开发团队来说，它可能帮忙快速发现并修掉真实漏洞，但具体修的是不是你要的那个，还需人工确认。
Dynatrace 推出了一个叫「漏洞风险暴露」的新仪表板，把漏洞到底影响哪些主机、进程和 Kubernetes 环境集中到一张图里看。原来只看漏洞数量，既不知道哪些进程受影响、漏洞扩散有多广，也看不出是不是所有该扫描的进程都扫了。这个仪表板把暴露情况、受影响对象和扫描覆盖率放在一起，还支持按团队、集群、命名空间筛选，让团队先修影响面最大的漏洞，并发现没被扫描到的盲区。该功能随文章发布，原文未说明具体开放时间或付费情况。
AWS 最近推出了 Lambda Web Functions。以前，想把用 Express、Hono 这类常见 Node.js 框架写的网页应用放到 Lambda 上运行，需要额外做不少适配工作；现在可以直接运行，并且支持同时处理多个请求和流式返回响应。对于用这些框架开发应用的开发者来说，迁移到 Lambda 会更省事。目前原文只说是“推出”，没有说明是否已正式可用、有哪些限制或价格细节。
Spring Cloud 社区正式发布了 2025.1.4 版本（代号 Northfields），这是一个面向 Java 开发者的微服务工具集。该版本基于 Spring Boot 4.0.9 构建，同时兼容 Spring Boot 4.1.2，主要修复了各个子项目中的若干 bug，并未提及新增功能。开发者现在可以通过 Maven Central 获取，并在 Maven 或 Gradle 中引入对应的依赖管理组件来升级。本次更新涵盖 Gateway、Config、Netflix、Stream 等十余个模块，完整修复清单可查阅 GitHub 项目页面。
Spring Boot 团队发布了 4.2.0-RC1 候选版本，已可从 Maven Central 下载。这个版本包含 113 项改进、文档更新、依赖升级和错误修复。主要变化有三点：默认的 Buildpacks 构建器换成了基于 Ubuntu 26.04 的 paketobuildpacks/ubuntu-resolute-builder；spring-boot-properties-migrator 现在可以在发现错误或警告时让应用直接启动失败；启动性能也有提升，可执行 jar 中的类和资源查找更快。这是候选版而非正式版，想尝鲜或提前排查升级问题的 Java 开发者可以试用，详细升级说明见发布说明。
Spring AI 团队发布了两个新版本：2.1.0-RC1（候选发布版，尚未正式定稿）和 2.0.2，都已在 Maven Central 上可下载。以前只有 OpenAI 的一种接入方式能原生处理结构化"消息片段"，现在 OpenAI、Anthropic、Google GenAI、Amazon Bedrock、Ollama、Mistral AI、DeepSeek 等主流模型接入也都能做到，并保持推理过程、工具调用的原有顺序。新版本还内置了"会话记忆"：把对话保存成只追加的事件日志，历史太长时按轮次压缩或摘要，且不会把工具调用和结果拆开，数据可存 PostgreSQL、MySQL 等数据库；原来基于 ChatMemory 的方案被标记为弃用，计划在 3.0.0 移除。另外新增工具调用确认机制，比如订机票、删文件前可先让应用批准；还支持用查询向量检索预先算好的嵌入。需要注意这只是候选版和补丁版，部分旧存储（Cassandra、Redis 等）的会话替代方案官方称将在 3.0.0 前补齐。
Dynatrace 宣布成为“SpaceX 超级智能合作伙伴网络”的启动伙伴，并推出一个已通过验证的官方插件，上架 Cursor 插件市场。原来开发者用 Cursor 这类 AI 编程工具写代码虽然更快，但代码编辑器和线上生产环境是割裂的：线上出故障时，开发者得先切到别的监控门户拼凑线索，才能弄清发生了什么、为什么发生。这次的做法是把 Dynatrace 的生产环境数据（由 Grail、Smartscape 和确定性因果根因分析提供）通过插件接进 Cursor，让 AI 代理和开发者直接在写代码的地方查看线上服务状态、依赖关系和根因。对使用 Cursor 的团队来说，排查线上故障、判断某个漏洞在真实运行环境中是否有影响、分析性能瓶颈，都可以不用离开编辑器，平台团队也能通过 Cursor 的团队市场分发插件并保留管理权限。目前该插件已作为受支持的集成可用，具体配置（平台令牌、MCP 服务器、Dynatrace skills 和 dtctl）需参考配套技术博客。
Datadog 推出 Agent Observability 的新功能，帮企业搞清楚 AI 智能体的钱花在了哪里。原来云厂商账单只按 API 密钥和模型统计，看不出是哪个应用、哪一步工作流在烧钱，所以成本一涨就很难查原因——可能是流量变大、换了更贵的模型，也可能是缓存没用上、对话历史每轮都重发。现在这个工具把估算的 AI 成本直接挂到具体应用和请求链路上，打开 Cost 页面就能按应用对比花费和效率（比如每次请求成本、缓存命中率），还能钻取到单次最贵的调用，看它的执行链路。它还会自动指出可省钱的点，比如未被缓存的提示词前缀，估算能省多少并给出修改建议。对读者来说，这意味着 AI 成本问题能更快定位到技术原因，而不是对着账单猜。目前材料只说明这是 Datadog 的产品能力介绍，未说明具体定价和正式上线时间。
Snyk 推出了 Evo Remediation Agent 的开放预览版，它能自动处理开源依赖漏洞：按团队设定的仓库范围和严重级别，智能体在托管沙箱里制定升级方案、修改代码，并用构建、测试和重新扫描验证结果，然后给开发者开拉取请求，由开发者决定是否合并。这解决的是漏洞修不完、和开发日常工作抢时间的问题。官方在 307 个依赖升级任务上测试，该工具四项检查全部通过的比率为 90.2%，而配合 Snyk 发现结果的 Claude Code 为 77.5%，单用 Claude Code 为 59.6%。目前只是开放预览，需申请租户权限，有每日修复额度限制，且仅支持开源漏洞，智能体不会自动合并。
在 2026 年北美 PyTorch 大会上，Google 开源了 TorchTPU，让 PyTorch 代码能直接跑在 Google 的 TPU 芯片上，已在 GitHub 发布；AWS 则推出 TorchNeuron 公开测试版，让 PyTorch 模型能跑在其 Trainium 芯片上。过去 PyTorch 开发者基本绑定 Nvidia 的 CUDA 生态，换芯片往往要大量改代码，这两个项目把迁移简化到改几行代码甚至只改一个配置。不过官方也说明，想达到最高性能仍需针对新芯片专门调优，例如 TorchTPU 默认分布式方案可能比优化方案慢约 30–40%。对开发者来说，这多了可选的硬件路线，但现阶段迁移容易、跑出极致性能仍不简单。
一位开发者用 Claude Opus 5.5 做出了七个 Adobe 应用的开源替代品，并在 Reddit 上宣传，声称大约一个月内就能达到接近 100% 的功能对齐。但随后他在 Hacker News 上承认，这个项目“远未准备好”。项目自己的路线图显示，它目前只有 45% 能满足实际工作需求，要达到完全对齐还需 2300 到 4100 个智能体小时。也就是说，这些工具目前仍处于早期阶段，暂时还不能当作 Adobe 的可靠替代品使用。
作者 Peihao Yuan 介绍了一套用于灾难恢复分析的工作流：AI 智能体只负责生成受限的 SQL 或 Python 代码，真正的计算交给嵌入式数据库 DuckDB，从 Parquet 文件中算出可复现的结果，再由智能体解读这些结果。文章的核心观点是：AI 改变的是人和数据打交道的方式（接口层），而不是负责算数的查询引擎本身。文中还讲了如何把“生成”和“计算”分开以保证结果可重放，并给出四个判断信号，帮读者决定什么时候用嵌入式引擎就够、什么时候值得上托管的湖仓方案。
Spring Batch 团队发布了两个版本：6.1.0-RC1（候选发布版，尚非最终正式版）和 6.0.6，均已可从 Maven Central 获取。6.1.0-RC1 带来一批新特性：新增 @JobParameter 注解，用来替代容易写错的 SpEL 表达式来注入作业参数；新增类型安全的 PageableItemReader，取代原来按方法名字符串反射调用仓库方法的做法；JsonLineMapper 不再绑定 Jackson，可配合 Jackson 或 Gson 读取任意类型的 JSON Lines 数据，并新增对应的写入端 JsonLineAggregator；还有 RemoteChunkingManagerBuilder、DefaultChunkProcessor、JDBC DAO 迁移到 JdbcClient，以及性能改进。一些旧类被标记弃用，计划在 7.0 移除。对使用 Spring Batch 做批处理的开发者来说，升级后配置更简洁、类型更安全，但涉及 JsonLineMapper 的代码属于源码和二进制不兼容变更，需要重新编译。