内容浏览
搜索中文标题、仓库名或关键词，再用分类、来源和日期缩小范围。
AI 让软件开发变快，也让漏洞被找到和利用的速度变快。过去安全团队靠一张表格记录漏洞、按严重程度打分再排优先级，但现在漏洞太多，这种方法很难跟上。文章提出换个问法：不要只问“我们有多少个漏洞”，而要先问“哪些漏洞真的会给我们带来风险”。做法包括：用更干净的基础镜像和代码扫描减少漏洞进入系统，同时持续扫描真正在生产环境里运行的软件，并结合网络可达性判断风险。这样能帮团队少做“表面功夫”，把精力放在真正危险的地方。
提供的材料未提及具体可用工具。
开源安全领域一直有个惯例：发现漏洞后先保密一段时间，等补丁做好再公开，防止被人利用。但作者 Anil Madhavapeddy 指出，现在 AI agent 能大幅缩短这个过程——它们可以根据公开的蛛丝马迹自动拼出可用的攻击代码，让“保密期”形同虚设。因此开源项目必须加快打补丁和发版的速度，因为从漏洞公开到被利用的窗口正在迅速缩小。对普通用户来说，这意味着开源软件的安全更新会来得更快，但漏洞被利用的风险也更紧迫。
提供的材料未提及具体可用工具。
Istio 是一个管理服务之间通信的开源工具。在 1.31 版本中，它新增了 agentgateway waypoints 功能，让 ambient 模式下的流量管理更灵活，1.31.1 又修了一个金丝雀发布的配置问题。同时，官方不再把镜像和 Helm 图表发布到 Google Cloud，用户需要迁移到新的仓库。如果你在用 Istio 并校验镜像签名，还要提前更新签名密钥，因为 10 月 13 日会做一次停服测试。
DoorDash 的两位工程师 Swaroop Chitlur 和 Sidd Kodwani 分享了公司内部搭建生成式 AI 平台的过程。最初他们主要依赖外部厂商的模型，后来逐步转向开源权重模型，并搭建了统一的 LLM 和 Agent 网关来管理调用。平台要同时兼顾准确度、响应速度和成本，目前服务超过 5000 名内部用户。对读者来说，这是一个大型公司如何把生成式 AI 落地到内部、并控制成本和性能的真实案例。
提供的材料未提及具体可用工具。
Anthropic 承诺投入 1 亿美元推出 Claude Frontier Academy，目标是在 2027 年底前培训 1 万名“前沿部署工程师（FDE）”。企业想用 AI，但真正能把 AI 落到业务里的人很难找，所以这个学院像医生培养那样：先上课、在模拟的企业项目里练手，通过考核后拿徽章，再用 12 周时间在本公司做一个真实的 Claude 项目，最后再考一次才能拿到正式称号。首批学员来自埃森哲、贝恩、凯捷、澳大利亚联邦银行、德勤、麦肯锡、摩根士丹利和诺和诺德等公司，目前需由公司提名，个人不能直接报名。
提供的材料未提及具体可用工具。
Dynatrace 推出了一款叫 MCP Server 的工具，能把 AI 编程助手直接连到 Dynatrace 的实时监控数据上。以前开发者用 AI 写代码时，AI 只能看到代码本身，看不到代码在生产环境里跑得怎么样，所以排查性能问题很费劲。现在开发者可以用大白话向 AI 提问，AI 会去查真实的运行数据并给出具体到代码行的修复建议。文章演示了一个案例：数据库 CPU 被一个低效查询占满，AI 找到了问题，只加两行索引就解决了，响应时间大幅下降。对开发者的好处是排查更快，但文中的演示和截图来自未来日期，实际可用状态原文未明确说明。
一位安全负责人（CISO）在一次模拟的勒索软件攻击推演中，展示了企业被勒索后最初72小时要面对的决策。问题在于：很多公司以为把服务器从备份恢复好就万事大吉，但实际上恢复系统只是让技术重新运转，业务恢复还要花更长时间——验证数据、重连依赖、处理积压订单、应对法律和客户影响。文章建议提前定好谁能断网、找好取证伙伴、准备声明模板，并借助AI辅助调查更早发现攻击。原文没有给出可直接使用的具体工具名称，具体产品细节也未说明。
提供的材料未提及具体可用工具。
Datadog 发布官方介绍，讲如何把 Databricks 上的分析、数据工程和 AI/ML 工作负载接入 Datadog 统一监控。原来用户只能分别看 Databricks 自带指标和下游基础设施，成本和数据质量难以串起来。这次通过三条数据采集路径（集群上的 Agent 抓 Spark 指标与日志、轮询 Databricks API 拿任务运行状态、查系统表获取成本与血缘），把作业健康、花费、数据质量和日志汇总到一个界面。读者可以据此设置作业失败告警、查看 Spark 查询瓶颈、获得集群规格优化建议，并配合云厂商集成定位底层问题；相关功能已可用，但文中未说明具体版本或价格限制。
Databricks 官方发了一篇指南，讲怎么收集 Databricks 和它底层 Spark 的运行数据（比如性能、成本、用量）。之前这些数据分散在各处，用户不容易统一查看和排查问题。这次介绍的方法主要是用系统表来查询日志、成本和性能指标，再配合 Spark UI、作业通知和 REST API，就能做分析和告警。不过要注意，系统表的数据不是实时的，延迟随 schema 不同，所以不能拿它做秒级告警；实时监控得靠作业通知和 API。
Databricks 的技术写作者 Aaron Kaplan 和产品经理 Ryan Warrier 写了一篇文章，教大家怎么监控 Databricks 平台上的数据工程、分析和模型服务任务是否健康、跑得快不快、花销有没有失控。原来很多团队用 Databricks 跑批处理、流式管道和 SQL 查询，但任务失败或变慢往往发现太晚，账单也容易悄悄涨上去。他们建议盯住几类关键指标，比如任务运行结果是成功、失败还是超时，任务跑了多长时间，有多少子任务出错，以及管道里有没有数据质量报错；这些指标来自 Databricks 自带的系统表。文章只是系列博客的第一篇，讲了平台架构和指标清单，没有给出具体告警阈值或现成仪表盘，系统表也标注为 Beta 状态，读者需要自己根据这些指标搭监控。
提供的材料未提及具体可用工具。
标准 Kubernetes（K8s，一个管理容器化应用的开源平台）功能强大，但运维负担重：搭建一套生产集群要配置控制面、网络、存储、安全、可观测性等多个组件，还要持续维护。K3s 是 Rancher Labs（现属 SUSE）推出的轻量发行版，把控制面和许多组件打包成一个不到 100 MB 的单一二进制文件，默认用 SQLite 存储，最低只需 512 MB 内存和 1 个 CPU 核心即可运行；而标准 K8s 通常至少要 4 GB 内存和 2 个 CPU 核心。因此 K3s 更适合边缘计算、物联网设备（如树莓派、零售终端、工业电脑）等资源受限场景，标准 K8s 则适合需要最大灵活性的复杂集群。需要注意的是，文章只给出了选型思路，没有提供两者性能或成本的对照数据。
提供的材料未提及具体可用工具。
Anthropic 给 Claude Code 加了一套叫 mods 的新功能：mods 就是一些用 JavaScript 或 TypeScript 写的小函数，可以挂到 Claude Code 内部的事件上，用来改提示词、拦截或改写工具调用、处理权限请求、替换界面部件，甚至加新功能。以前开发者只能通过设置、CLAUDE.md、hooks 和 MCP 服务器调整 Claude 的行为，但没法改变 Claude Code 自身的界面和功能。现在 mods 已随 Claude Code 2.1.287 及之后版本默认启用，还能打包成插件分享给别人装，不过 mod 代码在本机运行，Anthropic 建议只装可信来源的。
Stacklok 创始人 Craig McLuckie 在 CNCF 博客上提出，目前多数 AI agent harness（即围绕 AI agent 的上下文、文件系统、子 agent、权限等支撑层）太“本地”，只适合单个开发者在笔记本上跑，难以支撑数百个会话，会话容易中断，体验也无法在不同客户端或设备间迁移。他认为应当把 agent harness 当作云原生分布式应用：把 agent 循环与底层基础设施和服务分开，就像 Kubernetes 教会业界“容器里的单体仍是单体”一样。对读者来说，这预示未来 AI agent 的支撑层可能像云服务一样可扩展、可迁移，而不只是本地玩具。目前这只是观点和倡议，尚未说明具体落地产品。
提供的材料未提及具体可用工具。
GitHub 周四公测了 Copilot 的“computer use”功能：Copilot CLI 和桌面应用现在能像人一样操作 macOS 和 Windows 上的软件，能读屏幕内容，也能点击、打字、滚动和拖拽，连那些没有接口、只能靠图形界面操作的老软件也能用。但 GitHub 自己建议：如果任务能用 API、MCP 服务器、终端命令或专门浏览器工具完成，就优先用它们，因为那样结果更可靠。这项功能目前在公测阶段，需要手动开启，macOS 上还要单独授予辅助功能和屏幕录制权限；敏感窗口内容可能被智能体读到，企业管理员也可用策略限制。
Harness 发布博客文章，解释工程师为什么常常忽略云成本：传统 FinOps 工具把成本数据放在独立的财务仪表盘里，开发者得中断写代码去查，而且反馈往往要等 30 天才来，和日常交付节奏脱节。文章提出的做法是把成本信息“左移”进 CI/CD 和 IaC 流程：在合并请求合并前就评估这次改动是不是申请了没批准的实例类型、会不会超预算，超了就自动拦截或交给负责人审批；同时用 Harness Cost Management Agent 在服务级别做实时成本可见性。对平台团队来说，意义在于不用牺牲开发速度也能让开发者对云支出负责。目前文中提到的产品能力和模式来自厂商博客，具体发布时间和可用范围原文未说明。
GitHub 博客发表了一篇文章，讲的是 AI 正在改变开发者的干活方式，光会写代码已经不够了。文章建议开发者重点练三件事：一是学会“指挥”AI 智能体，把问题说清楚、给对上下文，而不是自己一行行写；二是不轻信 AI 的第一版答案，可以让另一个 AI 模型来挑毛病，再自己拍板；三是把省下的时间用来想更大的问题，比如判断用户需求、权衡架构方案、定义成功标准。对读者来说，这说明以后的核心竞争力可能不是你写代码有多快，而是你能不能判断 AI 写得好不好、该不该上线。文章只给了方向性建议，没有给出具体数据或发布日期。
DigitalOcean 最近上线了 DigitalOcean Managed Agents，目前处于公开预览阶段。过去要让 AI 智能体在云端跑起来，往往得自己搭服务器、管权限、配推理环境，比较麻烦；这次它把这些打包成托管服务，用隔离的微虚拟机运行智能体，对工具访问做统一管控，并提供免运维的 AI 推理。对开发者来说，可以少操心底层设施，把精力放在智能体本身的功能上。
作者 Daniel Curtis 提出，AI 代码生成正在改变前端组件复用的经济账。过去团队要花钱维护一套共享的 UI 组件包，现在只要把设计系统、设计令牌、规范和测试准备好，让模型按需生成标准界面即可，维护整套组件库的必要性因此下降。他的建议是别丢掉设计系统和测试这些真正保证一致性的核心，而是把组件从“预先做好反复用”转向“按需再生成”。文章只是观点文章，没有给出具体工具、数据或落地案例。
提供的材料未提及具体可用工具。
InfoQ 的编辑 Artenisa Chatziou 发布消息：QCon 旧金山 2026 大会将邀请 Airbnb、OpenAI、Netflix、Honeycomb 等公司的工程实践者，分享他们如何在 AI 智能体承担越来越多工作的情况下，构建、运维和演进自己的生产系统。目前这只是一则预告，具体议题、日程和举办时间等细节原文未说明，因此还无法确认哪些内容会公开或开放观看。对读者来说，这提供了一个了解大公司真实工程经验的机会，但暂时没有可以直接上手使用的工具或方案。
提供的材料未提及具体可用工具。
Ian Cooper 做了一场演讲，讲的是当系统靠“消息”互相通知、而且规模很大时，怎么管好这些异步接口。他把消息机制拆成三个基础点：地址（消息往哪送）、绑定（用什么方式送）、契约（消息长什么样）。原来的问题是消息散落各处、难以发现和统一管理；他介绍用 AsyncAPI、CloudEvents、schema 注册表，加上自动化 CI/CD 流水线来解决发现、治理和开通的问题。这些做法来自 Just Eat Takeaway 的真实工程实践，对需要维护事件驱动系统的团队有参考价值。