内容浏览
搜索中文标题、仓库名或关键词，再用分类、来源和日期缩小范围。
今天暂时没有新上架内容，你可以继续浏览历史归档。
InfoQ 将在十一月推出三个在线认证课程批次，主题分别是生产环境中的 AI 系统、检索与智能体设计，以及工程团队的流程、AI 角色与效果衡量。课程由 Adi Polak、Lan Chu 和 Olimpiu Pop 三位讲师带领。原文只是课程预告，没有说明具体开课时间、价格、报名方式或课程是否已开放，这些信息都缺失。对读者来说，这只能帮你了解有哪些主题的培训即将推出，并不能据此判断课程质量或是否值得参加。
提供的材料未提及具体可用工具。
OpenTofu 是一个开源的、用代码描述和管理云资源的工具（类似 Terraform）。以前执行“计划”时，有些值要等真正部署才知道，导致很多表达式算不出来、计划结果不够完整。1.13 版新增 convert 和 assume 等函数，让模块作者提前告诉计划器这些未知值是什么类型、大概是什么值，于是更多表达式能在计划阶段算出来。如果这些“假设”到实际部署时不成立，OpenTofu 会报错提醒。这样读者能在部署前看到更完整的计划、更早发现问题；不过这些函数的具体用法文中没有说明。
这是一期 Spring 官方播客的节目介绍，主持人 Dan Vega 和 DaShaun Carter 邀请 Java 冠军 Pratik Patel 聊 Java 开发者怎么用 Hugging Face。Hugging Face 上有超过一百万个开放模型，但大多数 Java 开发者从没用过，节目里讲了它到底是什么、怎么挑一个值得用的模型、现在从 Java 里运行开放模型有哪些办法，以及什么情况下开放模型比付费 API 更划算。对 Java 开发者来说，这期节目能帮你弄清楚要不要以及怎么在自己的项目里用上开源模型，而不是只能依赖付费服务。节目有直播可以提问，也能在播客平台听回放，但节目本身没有给出技术细节，具体怎么选、怎么跑要看正片。
Cursor 发布了 Agent SDK，这是他们用来构建自家 Bugbot、安全审查智能体和 Rollouts 等托管智能体的框架，现在对外开放。此前，团队想做一个贴合自己工作方式的智能体，要么直接用别人设计好的产品，要么从零开始写。现在可以用代码定义智能体：提示词写成 Markdown，工具写成 TypeScript 函数，和普通软件项目一样走版本控制和审查，还能用内置的评估和事件回放来测试。做好后运行 `agent-sdk deploy` 就能部署到 Cursor 的基础设施上，也可以打包成容器跑在自己的服务器上。目前已正式发布，可阅读文档开始使用。文中还举例：Cursor 内部团队约一天就做出了 kb-reviewer，在每个 PR 上对照团队经验知识库检查不一致。
Google Research 和斯坦福学习加速器推出了 AI Quests 系列的第三个教学项目“Polar Peaks”，面向 11 至 14 岁学生，让他们扮演 Google 研究员，通过扫描和绘制大脑神经元来理解游戏角色的记忆丧失，并完成数据清洗、模型测试等任务，从而学习 AI 需要人工监督和批判性思考。这个项目受 Google 十多年连接组学研究启发，该研究最近完成了迄今神经元数量最多的完整果蝇大脑图谱。系列已有超 40 万次任务完成、支持 10 种语言；同时新推出教师培训模块，前两个任务的模块已可用，第三个的模块将于下月发布。学生可以借此了解 AI 如何加速科学研究。
开发 Claude 模型的 Anthropic 公司今天向美国证券交易委员会（SEC）提交了一份 S-1 注册文件，这是公司上市前要走的第一步正式手续。它计划在纳斯达克全球精选市场上市，股票代码为“ANT”。但目前发行多少股、每股定价多少都还没确定，注册文件也尚未生效，所以股票还不能出售，也不能接受购买要约。对普通读者来说，这意味着 Anthropic 迈出了成为上市公司的第一步，但离真正挂牌交易还有一段路要走，具体时间和价格目前都没有公布。
提供的材料未提及具体可用工具。
OpenAI 发布了名为 GPT-6.1 Terra 的新模型，官方将其定位为让所有人都能用上快速、能干的计算机操作能力。不过，现有材料只有一句宣传语，没有说明这个模型具体怎么用、性能指标如何、与之前版本相比改进了什么，也没有交代价格、开放范围和发布时间——是已经可用、仅做演示，还是未来计划，原文都没有交代。因此现阶段只能确认这是一款主打“计算机使用”的新模型发布，具体能力还需要等官方说明或实测。
OpenAI 的工程师使用一个叫 Codex Ultrafast 的工具来调查系统事故。以前排查一次事故要花好几个小时，现在只要几分钟。它除了查事故，还能用来做安全分析和重构代码，已经融入了工程师的日常工作流程。不过这篇材料只有一段简介，具体怎么做到的、有哪些限制、对普通用户是否开放，都没有说明。
Fanatics 是一家体育周边商品零售商，它借助 OpenAI 的技术推出了一个叫“Shop the Look”的功能，帮球迷把比赛日穿搭搭配完整。此前球迷可能要在大量商品里自己挑选搭配，现在系统能直接给出整套造型建议。他们用大约 3 万件 MLB（美国职棒大联盟）商品做了测试，结果显示用户参与度提高了 10%。对普通球迷来说，挑衣服搭配更省事了，但目前只提到测试阶段的数字，正式上线范围等细节原文没有说明。
OpenAI 发布了一份名为 OpenAI Signals 的数据，覆盖近 100 个国家、165 种工作活动，用来观察人们如何在工作里使用 ChatGPT、以及用法随时间怎么变。简单说，这是把不同国家、不同岗位的实际使用情况汇总起来看趋势，而不是只看某一次调查。原文没有说明数据怎么采集、样本多大、具体统计口径，也没有给出可下载入口或具体结论。对读者来说，这提供了一个了解 ChatGPT 职场用途的观察角度，但具体怎么用、有哪些变化，原文没有展开。
提供的材料未提及具体可用工具。
CodeRabbit 使用一个名叫 GPT-6.1 Sol 的模型，去检查复杂代码库里可能存在的安全风险。它的安全助手会帮开发者查看发现的问题和修复建议，方便人来做判断。材料只有两句话，没有说明这个模型具体是什么、由谁发布、是否已开放使用，也没说 CodeRabbit 这项功能何时上线或面向哪些用户。对读者来说，如果这项功能可用，看代码安全问题会多一个自动检查的帮手。
OpenAI 公开了其模型在三个数学与物理难题上的结果：Kakeya 猜想、指数时间假设（ETHz，计算复杂度理论中一个关于某些问题无法被高效求解的假设）和量子色动力学（描述夸克与胶子相互作用的物理理论）。此前，这类前沿科学问题通常只有少数专家能深入参与。这次 OpenAI 强调与学术社区合作，并说明研究者可以如何核验这些结果、在其基础上继续推进。对普通读者来说，这意味着 AI 开始被用来协助攻克基础科学难题，而且结果可以被独立检验；不过原文没有说明具体做了哪些验证、结果是否已经发表或可公开使用，这些信息尚不明确。
提供的材料未提及具体可用工具。
Greptile 原本主要做代码审查，现在想检测更多缺陷。它用 GPT-6 Astra 来测试用户工作流，用 Daybreak 加强安全，用 Codex 减少返工。简单说，就像不光检查零件，还模拟用户怎么用、提前发现漏洞。不过材料没说明这些功能是否已上线、具体怎么用、效果如何。
传统上，Kubernetes 假设软件只会做开发者写好的事，但 AI 智能体能自己思考、选方案、调用工具、持续朝目标推进，这让它在生产环境中的运行方式与传统应用很不一样。问题是：AI 行为是概率性的，无法精确预测它会用到哪些资源，安全沙箱和监控就成了大难题；同时智能体可能只存活几秒，启动却要等好几秒，传统调度方式不够快。社区正在推动把沙箱作为约束智能体的架构元素，但开源 Kubernetes 功能尚未齐全，企业目前可借助已带沙箱能力的商业发行版；还有人提出“智能体底座”方案，让智能体在热池中休眠，实现毫秒级唤醒，而非秒级冷启动。对读者来说，这意味着想在 Kubernetes 上跑 AI 智能体还需额外注意安全隔离、监控和启动延迟，不能直接照搬普通应用的部署方式。
数据库公司 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，应尽快升级到对应版本，并检查是否已被利用。文章未说明漏洞具体细节、受影响范围细节，也未说明各版本的发布时间差异。
提供的材料未提及具体可用工具。
LangChain 公司为市场、销售和工程团队搭建了内部智能体，并说这些智能体已经明显改变了团队的工作方式。他们遇到的核心问题是：智能体该在哪儿跟人交互、代表谁的身份去操作、记住哪些信息、在哪里安全执行代码，以及如何定时自动运行。他们的做法是让智能体住在员工日常用的 Slack 里，区分“代表提问者本人”和“用固定身份”两种权限，把记忆分成全员共享和按用户两层，代码放到隔离沙箱里执行，并让很多任务由定时或事件触发而非人工唤起。这些智能体都基于 Managed Deep Agents 构建，官方称现在就可以按快速上手文档试用；但文章也承认记忆这块探索最少、还有很多工作要做。
这篇文章讲的是在 Kubernetes 上跑 AI 任务的团队，常看到 GPU 全被占满、批处理队列越排越长，第一反应就是加 GPU。但作者提醒，GPU 被分配、在忙、和真正产出有价值的结果是三件不同的事，队列变长也可能是时机、服务容量或模型和硬件选型的问题。解决思路是先想清楚每个任务的截止时间和产出标准，再用错峰排队把现有四块 GPU 在两小时内跑完原本需要八块的四个任务，同时用接近真实负载的压测摸清可持续吞吐，并把 OpenCost 的成本数据和实际产出对上，算出每个合格结果花多少钱。这样读者能在花钱扩容之前，先确认现有容量是否已用足、瓶颈到底在哪。Kueue、vLLM、DistServe、OpenCost 等工具文中都有提到，具体接入方式原文未详细说明。
Kubernetes 里管“该开几个副本”和“每个副本该给多少 CPU/内存”的其实是好几套独立工具：HPA 按 CPU 百分比增减副本，VPA 按历史用量调整资源申请，KEDA 按 Kafka 队列积压决定副本数，Karpenter 按声明资源申请新机器。问题是它们各自跑各自的循环，看到的都是局部信息，还同时改同一批配置字段。比如 VPA 把 CPU 申请调小，HPA 的分母就跟着变小，同样的流量会被算成利用率超高，于是猛加副本，结果副本越来越多、每个越来越小，互相把对方越推越远；KEDA 加副本、HPA 又按低 CPU 减回来；GitOps 看到副本数和 Git 不一致还会把它改回去。作者认为水平和垂直扩缩本来就是一道联立方程，应该由一个统一控制面同时看 CPU、队列、延迟、节点价格和 Git 配置，一起给出副本数和资源申请。文中也提到生产集群 CPU 平均利用率只有约 8%，但这些方案的落地细节和可用性文中没有说明。
这篇文章讨论的是：当 AI 编程智能体让代码提交量暴增时，团队的交付系统会卡在哪里。作者提到 Anthropic 的代码合并量从 5 月每天约 2500 个涨到 9 月每天超过 3 万个，写代码不再是瓶颈，瓶颈变成了为人类速度设计的开发基础设施。文章用控制回路打比方：意图是目标值，智能体是控制器，验证就是传感器；控制器再快，如果传感器跟不上，它只会拿着过时信息反复重试，把本该被拦下的问题发布出去。作者提出传感器要具备三个特性：延迟（多久能出结果）、保真度（多接近真实系统）、带宽（能同时验证多少个改动），并用 StrongDM 的数字孪生宇宙举例说明保真度为什么最贵。对读者的用处是：如果你在规划智能体编程流水线，这篇文章提醒你先投资验证能力，而不是只堆智能体数量。文章是观点分析，未说明具体产品发布时间或可用状态。