内容归档
按栏目浏览往期内容，用关键词、分类和日期找到需要的信息。
哈佛大学最近调查了 718 家公司，借助 Jellyfish 分析平台的数据，想看 AI 编程助手和智能体到底能不能帮上忙。结果发现，这些工具确实让写出的代码变多了，但真正完成的工作量并没有跟着涨。原因之一是 AI 生成的代码给开发后段添了麻烦，尤其是代码审查环节负担加重——写得多不等于交付得多，前面的速度被后面的检查卡住了。对普通开发团队来说，这说明光靠 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 的代码属于源码和二进制不兼容变更，需要重新编译。
一个算法团队参考 Karpathy 开源的 AutoResearch 原型，把「让 AI 自己改训练代码、跑实验、看指标、决定下一步」的循环搬进企业云端训练平台。最初的单线程循环有三个毛病：规则靠自然语言提示不可靠、与企业云环境不匹配、同一时间只能试一条路。他们三个月重构三次，最终改成「图探索」：主 Agent 把大问题拆成几个互不重叠的假设，交给子 Agent 并行各自训练、互不干扰，再由主 Agent 汇总对比做决策，并用状态文件和冻结的评估代码保证无人值守时可信、可回溯。在结构完全不同的两个业务建模项目中，单任务耗时比人工基线分别减少约 85% 和 83%，其中一个方案已推全上线并有收益，另一个在全部 12 个预估目标上超过人工基线。
LangChain 推出了 LangSmith LLM Gateway，目前处于公开测试阶段。它解决的是生产环境智能体的一个麻烦：智能体调用模型时可能因重试失控产生高额账单，或遇到模型服务商宕机就报错。这个网关夹在智能体和模型之间，统一执行花费上限、速率限制、模型回退和敏感信息（如个人隐私、密钥）脱敏，不用在每个智能体里各写一遍，也不必绑定某一家供应商。工程师可以在组织、工作区、API 密钥、用户四个层级设限额；敏感信息脱敏功能目前只对 Enterprise 套餐开放。
Trail of Bits 发布了两款插件：patching-bugs 负责复现报告的缺陷、开发修复并测试；regression-hunt 负责检查改动是否破坏了原本正常且受支持的行为。起因是他们此前与 OpenAI 合作的 Patch the Planet 项目在合并的 130 多个补丁中确认引入了 21 个回归（16 个功能、1 个性能、4 个构建/测试），虽然没破坏安全防护，但说明只靠智能体打补丁不够稳。两款插件通过固定流程、严格输入输出格式，并要求每条结论都用真实运行环境的「概念验证」复现来减少误报；初步评测中 regression-hunt 的误报比一个被要求「审查回归」的 Codex 基线智能体少 25%。对工程师和开源维护者来说，这提供了一种更可控、可复核的方式把补丁开发和回归检查交给智能体，同时保留人工审核和项目自身的安全规则。目前是刚发布的插件，评测为初步结果。
安全公司 Snyk 在旧金山 AISS 大会前一天办了一场圆桌讨论，请来 OpenAI、Google 威胁情报团队、风投机构和 Snyk 的四位安全负责人聊 AI 安全。原来大家早就积累了不少安全隐患，只是以前攻击成本高、没被利用；现在 AI 让攻击变得又便宜又快，等于把这些旧账一次性催收。讨论指出，找漏洞越来越容易，真正卡住人的是修复速度，所以防守方需要让机器承担大部分修复工作，并配合身份、权限和意图管控。文章还提到一个案例：有人用开源 AI 渗透测试工具攻击了至少九家韩国银行；另有研究发现，扫描的 3,984 个智能体技能中至少 36.82% 存在安全缺陷。这些是会上讨论的观点和案例，不代表已有现成方案落地。
安全公司 Snyk 扫描了上千个企业环境中的 AI 模型，发现近一半环境引用了可能在某种攻击下得分达到严重级别的模型。但作者强调，光看模型分数不够：同一个模型，如果只用来总结会议记录，和用来查询客户数据、触发业务流程，出事的后果完全不同。所以团队应先确认模型是否真的在运行、它能访问哪些数据和工具，再针对具体风险选择换模型或加访问限制、人工审批等控制措施。这项研究来自 Snyk 报告，其中模型分数基于模拟攻击测试，并不代表真实入侵已经发生。
提供的材料未提及具体可用工具。
英伟达在柏林 GTC 大会上推出 DSX POD：一种集装箱式参考设计，合作伙伴在工厂里就把 Vera Rubin 机架（每箱 7 个 NVL72 机架、504 块 Rubin GPU）、网络和液冷装好并测试，运到数据中心后只需落位、接线、跑最后的烤机测试。过去在传统数据中心装 rack 和布线要几个月，现在只要现场电力、散热和网络条件具备，最快 14 天就能开始产出 token。系统采用无水冷却，靠干冷器即可，2 吉瓦部署每天可省约 5400 万升水。Armada、Dell、HPE 等 17 家合作伙伴将参与制造，计划 2027 年初开始全球交付，目前尚未可用。
英伟达在 GTC 柏林大会上把一组开源组件加入 Agent Toolkit，组成了 Agent Knowledge Foundation。它包含 Nemotron Retriever 检索模型、Auto-Ontology 本体库、处理表格数据的 Kumo 模型系列和 CUDA-X 数据处理库。问题在于：企业把智能体接上 Snowflake、邮箱或知识库后，模型仍难以理解跨系统的整体业务背景，面对多标签页的表格也容易找错数据。这次的做法是让数据留在原处、沿用企业已有的访问规则，用更好的检索和知识图谱补上下文——英伟达称其检索模型在 OpenSearch 测试中相关性提升 65%。对读者的意义是：企业多了一种不替换现有数据平台、自建智能体数据层的新选择，但相关组件刚发布，实际效果还需验证。英伟达表示只做模型、不与 Snowflake、Databricks 等数据平台竞争，权限控制仍交给合作伙伴；文中未说明各组件的具体可用时间和价格。
卡内基梅隆大学研究了采用 Cursor 的公开代码仓库，发现头一个月新增代码行数涨了 3 到 5 倍，但大约两个月后涨幅就消失了；同时静态分析警告多了 30%，代码复杂度上升 41%。也就是说，写代码变快了，但检查代码仍然主要靠人工评审，速度没跟上，评审反而成了瓶颈，技术债也在增加。Sonar 提出用自动化验证补上这一环：在智能体写代码时、CI 合并前、以及上线后的维护阶段都持续检查，让问题更早、更便宜地暴露，而不是让模型自己给自己的作业打分。对团队来说，这意味着在享受 AI 提速的同时，仍能守住代码质量和安全标准。
一家名为 Vijil 的公司提出了一套管理 AI 智能体的方法。问题是：企业想把能自主决策的 AI 智能体投入生产，却担心它闯祸——比如环境变化后行为失常、被恶意提示诱导、或者多个智能体各自合规但合起来违规。他们的做法是借鉴信用卡风控：上线前先测试并给出“信任分”，上线后按分数限制权限，持续监控每次关键操作，发现问题就修复、重测、再上线，循环不停。对读者来说，这意味着未来企业部署 AI 智能体时，会更强调“先证明可信、再逐步放权”，文章还提到 Vijil 客户把获得信任的时间缩短了 4 倍，但具体评测细节文章未完整说明，且相关服务处于推广/试用阶段，尚未给出广泛可用的结论。
Anthropic 在 2026 年 2 月就做出了 Mythos 级模型，但 CEO Dario Amodei 说，他们把更广泛开放的时间推迟到 6 月，用来加强网络安全防护。他承认，这个决定可能让公司损失了原本能保持数月的模型领先优势；如果更早发布，各组织准备应对更强 AI 网络攻击的时间就会更少。Anthropic 表示，这符合其“负责任扩展政策”的承诺：必须能强有力地论证灾难性风险已被控制，否则就继续推迟。这对读者的意义是：AI 公司如何在安全和商业竞争之间取舍，会直接影响强大模型何时、以什么限制向公众开放。
安全公司 Wiz 等机构借助前沿 AI 模型，在 PHP 核心引擎中发现两个严重漏洞（名为 PHP2Shell，严重度评分 9.2），可让攻击者在未登录情况下在 WordPress、Drupal、Joomla 等站点上执行代码。这些问题存在了至少十年：老代码里对已释放内存的引用会被后续请求误当成有效数据，以往要挖出并串联利用条件非常费力；Wiz 称用 AI 后一名研究员约一周就完成了过去团队数月的工作。漏洞于 8 月下旬被报告，PHP 官方在 9 月下旬确认并联合各方修复，补丁在公开披露当天发布，但细节提前外泄，Cloudflare 在正式公告前约九小时已默认拦截攻击流量。对读者的提醒：防火墙规则只能挡攻击、不能替代补丁，运行 PHP 的站点应尽快升级到已修复版本，而 OpenAI 也借此提出了一套应对 AI 发现漏洞的五阶段协作框架，仍需社区完善。原文未说明各漏洞在具体版本中的详尽影响范围。
PHP 官方在 2026 年 10 月 21 日紧急修复了两个严重漏洞，统称 php2shell（CVE-2026-109618 和 CVE-2026-109619，严重程度均为 9.2 分）。问题出在 PHP 本身：当请求耗尽内存等致命错误发生时，PHP 会中途跳出、跳过清理步骤，留下半完成的内存状态；攻击者可以用特制上传和后续请求利用这块烂摊子，读取内存片段甚至执行任意命令。Harness 推出了 WAF 虚拟补丁规则，先以监控模式观察、确认后切到拦截，还可在 API 安全扫描发现暴露端点时一键生成补丁，帮你在逐个服务器更新重启之前挡住攻击。普通读者要明白：约七成已知服务器软件的网站跑在 PHP 上，受影响面很大，虚拟补丁只是临时桥梁，最终仍需把每台 PHP 装好补丁并重启。
Harness 为自托管的 MCP 服务器新增了 OAuth 代理模式。以前企业自建 MCP 服务器时，只能把 Harness 的个人访问令牌（PAT）或服务账号令牌放在服务器或开发者电脑上，这种令牌长期有效、容易被复制和共享，泄露后照样能用，审计日志也分不清是谁在操作。新模式下，MCP 服务器充当中间人：开发者先用公司自己的身份提供商登录，服务器再在后台换成短期有效的 HarnessID 令牌并加密保存，开发者机器上不再出现 Harness 凭证。这样，受到严格监管、只信任内部身份系统的企业也能把 Harness 接入自己的 AI 开发平台，同时每次操作都能对应到具体的人。该功能已随文章发布，具体开通条件和限制原文未说明。
GitHub 把 99.99999% 的仓库复制到了 Azure，但最繁忙的那一小部分仓库因为跨区域往返一次约 25 毫秒而搬不过去。原来的写入会锁住整个仓库，一次只能处理一个写入，最慢的副本拖慢了所有写入。现在 GitHub 把锁的范围从整个仓库缩小到单个引用（如分支），不同分支的写入可以同时进行，内部测试中写入吞吐提升了 3 到 4 倍。接下来，等数据都存进 Azure Blob Storage，读取就能和写入分开扩容，读者日常拉取代码时有望更快、高峰期也不容易被写入挤占。这一改动是已公布的架构演进，具体全面上线时间文中未说明。
提供的材料未提及具体可用工具。
作者 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 场景。
提供的材料未提及具体可用工具。