P99 CONF 是一个线上会议，专门讨论高性能、低延迟的应用，2026 年的大会在 10 月 21 日至 22 日举办。本文从 60 多场演讲中挑选了五场来介绍，主题都是数据库在不同设计之间如何取舍。比如，读写和存储空间往往此消彼长：让写入变快，读起来可能更费劲。还有团队把数据放到对象存储上并加缓存，用便宜的大容量存储换取稍慢的冷读取；也有团队改用内存索引，让读取更快、几乎不出现长尾延迟，代价是占用更多内存、写入更重。这些结果都针对演讲中特定的测试负载，并非通用性能保证；演讲录像需注册后可在 p99conf.io 点播观看。
文中可用工具
- SlateDB开源库，让开发者在 S3 等对象存储上直接搭建键值数据系统，不用自己实现 LSM
- LogstorScyllaDB 中可选开启的存储引擎，面向读多写少的键值负载，用内存索引加快单点查询
- Valkey内存数据库，文中通过多线程网络 I/O 和槽位迁移来提升吞吐和横向扩展速度
- turbopuffer向量搜索引擎，在对象存储上支撑千亿级向量的低延迟检索
- RaBitQ二进制量化方法，把向量的影子索引压缩到每维一位，用来先缩小候选范围
展开详情收起详情：五场 P99 CONF 演讲揭示了数据库的哪些权衡取舍⌄
原文发布：2026-10-30 21:00 · 首次收录：2026-10-31
OpenAI 在 10 月 26 日发布了 GPT-6.1 Terra，把它定位成便宜、快速、适合大量日常任务的模型，价格只有旗舰 GPT-6 Astra 的十分之一：输入每百万 token 1 美元、输出 5 美元，而 Astra 是 10 美元和 50 美元。作者用三项自己造的测试对比两者：SQL 推理、数据校验和故障日志排查，推理强度都设为 high。结果是 Astra 更准，例如 SQL 测试 48/50 对 26/50，数据校验 50 对 45；Terra 更快更便宜，SQL 测试约 0.08 美元、133 秒，Astra 约 1.65 美元、320 秒。作者指出，Terra 会把需要累加的任务交回给用户自己跑查询，还会自信地给出错误计数，使用时需要挑选场景。这些只是单次合成测试结果，文章没有说明正式可用范围等更多信息。
文中可用工具
- GPT-6.1 TerraOpenAI 发布的低价快速模型，用于高量日常任务
- GPT-6 AstraOpenAI 的旗舰模型，价格更高但测试中更准确
- GPT-5 Mini文中用作较弱对照模型，用于校准难题测试
- OpenAI API作者用来运行三项测试的接口
展开详情收起详情：GPT-6.1 Terra 对比 GPT-6 Astra：高推理强度下，一个以准确率换低成本与高速度⌄
原文发布：2026-10-30 22:59 · 首次收录：2026-10-31
Kubernetes 社区在 10 月 27 日宣布成立一个专门的工作组，要为「工作负载在 Kubernetes 上运行时的行为」制定统一标准。此前虽有测试能判断一个集群能不能跑 AI/机器学习任务，但对于具体工作负载本身没有类似标准，团队只能靠变通办法、手动摸索，或者盯着节点被清空、权限报错这类迹象来排查问题。新工作组希望补上这块空白，让不同工作负载在集群里的运行表现有一致、可检验的规范。对跑 AI 工作负载的团队来说，这意味着未来判断平台是否适合自己的任务会更有依据；不过目前只是宣布成立并征集社区意见，标准尚未发布。同期还有：TNS 与 HPE 合作发布一本关于在 Kubernetes 上运行 AI 工作负载的电子书，可立即下载；OpenTelemetry 转换语言 OTTL 达到 v1，对 traces、metrics、logs 稳定，包含在 Collector Contrib v0.164.0 及之后版本，并承诺语法和标准函数保持向后兼容。另有 AWS 架构师预告将在 KubeCon 展示用 agent 流水线实时分析工作负载并在 GPU 上共置多个模型的方案，属于演示预告，原文未说明可用时间。
文中可用工具
- Kubernetes容器编排平台，文章讨论其上新成立的工作负载一致性工作组
- Kubernetes AI Conformance已有测试，用于判断集群能否运行 AI 或机器学习工作负载
- OpenTelemetry Transformation Language (OTTL)OpenTelemetry 的配置语言，可在收集器层修改、过滤和丰富遥测数据
- Collector ContribOpenTelemetry 收集器贡献版，v0.164.0 起包含 OTTL v1
- VPC Flow LogsGoogle Kubernetes Engine 内置功能，记录 IP、端口和协议之间的连接，帮助排查临时 Pod 的问题
展开详情收起详情：Kubernetes 成立工作负载一致性工作组，为何对 AI 团队意义重大⌄
原文发布：2026-10-31 01:29 · 首次收录：2026-10-31
前 GitHub CEO Thomas Dohmke 创办了新公司 Entire，本周推出一个 GitHub 替代品，用 AI 代理审查代码改动的 Trails 系统取代传统 pull request，开发者负责把关。他在采访中表示，最担心的是人们以为不再需要学编程，认为每个孩子除了数学、生物、地理，也应懂计算机科学基础。文中还提到其他几位业内人士的看法：有人担忧速度快但理解不足、出现低质量代码，也有人担忧 AI 代理的信任与安全机制跟不上，以及工具价格把人挡在未来之外。
文中可用工具
- TrailsEntire 推出的代码审查系统，用 AI 代理评估代码改动，开发者负责监督
- GitHub原文中作为被替代的传统代码托管与 pull request 平台被提及
展开详情收起详情：Entire 联合创始人 Thomas Dohmke 最担心科技未来的什么？⌄
原文发布：2026-10-31 03:37 · 首次收录：2026-10-31
HPE 的三位产品负责人（Marius Bogoevici、Mahesh Ramachandran、Karthik Subramanian）在一篇赞助文章中讲了怎么发现 AI 服务“机器很忙但用户体验差”的问题。原来大家常看 GPU 利用率，但它只说明显卡在干活，不代表回答够快、够准——首字快可能后面生成很慢，整体快也可能答错。他们建议上线前先用有代表性的提问和流量做一次“基准测试”，记下首字时间、每字生成速度、吞吐量和答案质量，上线后再拿实时表现跟基准对比，并把请求数据和 GPU、网络、数据库、向量库等底层指标对齐，才能分清是需求涨了还是哪里卡住了。读者可以据此建立更靠谱的监控和扩容依据；报道没有给出具体测试数字，相关方法和电子书属于推荐做法，HPE Morpheus 与 OpsRamp 是厂商产品介绍，并非已公开的独立评测结果。
文中可用工具
- HPE Morpheus Software在混合环境中统一开通和管理虚拟机与 Kubernetes 集群的平台
- HPE Kubernetes Service (HKS)Morpheus 高级版和企业版中包含的 Kubernetes 服务
- HPE OpsRamp Software跨多云混合基础设施的全栈可观测与监控工具
- Horizontal Pod AutoscalerKubernetes 自带的按指标自动扩缩容组件
展开详情收起详情：GPU 繁忙会掩盖 Kubernetes 上缓慢的 AI 推理⌄
原文发布：2026-10-31 03:56 · 首次收录：2026-10-31
Anthropic 把每月 200 美元的套餐改名为 Ultra（原来叫 Max 20x），并取消了这个套餐中 Claude Code 的“滚动五小时用量上限”。以前用户即使本周还有剩余额度，也可能在调试或大重构做到一半时被这个五小时上限卡住，只能等重置。现在只要账号通过验证、且本周额度没用完，就不会再被五小时窗口打断；验证按账号和付款记录自动进行，无法申请加速，通过后会收到邮件通知。注意周用量上限仍然存在，网页、桌面和手机上的 Claude 聊天与 Claude Code 共用同一份额度，用完后可按 API 标准价格购买额外用量。对经常撞上五小时限制但周额度还有剩的人，Ultra 可能值得比 Max 多付 100 美元；如果每周额度本来就早早用完，取消五小时限制并不会增加可用量。另外 Max 5x 改名为 Max，两个套餐价格仍为每月 100 和 200 美元，老用户无需操作。
文中可用工具
- Claude CodeAnthropic 的命令行 AI 编程工具，此次取消了 200 美元套餐的五小时用量上限
- ClaudeAnthropic 的聊天助手，其网页、桌面和手机端用量与 Claude Code 共用每周额度
- Claude Platform API供开发者调用 Claude 的接口，套餐附带等额月度 API 额度
展开详情收起详情：Anthropic 取消 Claude 一项重要用量限制，但并非人人适用⌄
原文发布：2026-10-31 04:14 · 首次收录：2026-10-31
Anthropic 推出后台助理 Claude Duet，会自动查看你已连接的应用，主动判断哪些事需要你处理。问题是“什么算紧急”本身很主观，而且它由 Claude Opus 5.5 驱动，可能误读对话或判断错优先级。为此 Anthropic 用员工日常工作校准了一套内部评分器，离线检查它排优先级的对错，同时另设一个独立于执行模型之外的自动检查器，看每个动作是否符合你的意图，以降低网页里藏指令骗它的风险。目前 Duet 只对美国 Pro 和 Max 订阅者开放且有等待名单；后台检查每几小时一次并计入用量额度，官方未说明评分的准确率，也还不能让你实时查看或接管它在云端浏览器里的每一步。
文中可用工具
- Claude Duet自动监控已连接应用并在后台处理任务的 AI 助理
- Claude Opus 5.5驱动 Claude Duet 的模型
- Claude Code其自动模式分类器被扩展用于 Duet 的独立动作检查
展开详情收起详情：“紧迫性本质上是主观判断”：Anthropic 向 TNS 介绍如何评估 Claude Duet⌄
原文发布：2026-10-29 19:00 · 首次收录：2026-10-30
云原生社区在讨论如何让 AI Agent 跑代码时更安全。原来，Agent 自主运行时会执行没人检查过的代码，可能装包、跑脚本、反复改到测试通过，在笔记本上风险有限，但在公司共享的 Kubernetes 集群上，一个被允许的系统调用就可能利用内核漏洞影响整台节点。文章把防护拆成五层：选择隔离方式（普通容器、gVisor 限制系统调用、Kata 轻量虚拟机）、配置对应节点、收紧网络与凭证等访问权限、通过 RuntimeClass 让 Agent 单独选用更隔离的运行环境，以及为额外资源开销做计量。读者能了解各方案的取舍，比如 Kata 隔离更强但要维护客户机内核、打两份补丁。文章未说明这些方案当前是已可用还是仅演示。
文中可用工具
- runc普通容器运行时，共享主机内核，性能最好但隔离最弱
- gVisor在用户态处理系统调用，限制内核接口，适合需要一定隔离又看重启动速度的场景
- Kata Containers让每个 Pod 跑在轻量虚拟机里，提供完整虚拟机级隔离
- Kubernetes承载 Agent 工作负载的集群平台
- RuntimeClass让指定 Pod 选择更隔离的运行环境，不影响其他工作负载
- NetworkPolicy限制 Agent 的网络出口，默认拒绝只放行必要目标
- containerd节点上集成并配置 runc 或 gVisor 运行时的容器引擎
- KVMKata 场景下提供硬件虚拟化支持
- MCP servers作为沙箱外的远程工具，需要单独授权
展开详情收起详情：Kubernetes 上 AI Agent 沙箱的五个关键层次⌄
原文发布：2026-10-29 20:00 · 首次收录：2026-10-30
很多平台团队每年都会自己写 Kubernetes 控制器，用来自动创建 Deployment、Service、ConfigMap 之类的一堆对象，并在它们之间传递字段。Kubernetes 本身已经提供了 CRD、控制器、Server-side apply、CEL、OpenAPI 这些零件，却没有说明“几个资源算一个整体、谁先谁后、某个值要从另一个资源的状态里取”的说明书，所以 Helm、Argo CD、Crossplane、Operator 等每个工具都各自补这一块，成千上万的组织在重复造同一个轮子。kro（Kube Resource Orchestrator）把这段“接线”写成数据，叫 ResourceGraphDefinition：由 CEL 表达式里的引用来推断依赖顺序，并在实例创建前做类型检查，一个控制器就能解释所有定义，应用团队照样用 kubectl、RBAC 和 GitOps。它还在 2025 年 9 月进入 Kubernetes SIG Cloud Provider，定位成别人可以搭建的底层原语；0.10 版本新增的 Graph 只保留组合部分、不需要 CRD 和实例，适合“给打了标签的 Service 自动生成 Ingress”这类一次性场景。读者可以少写一堆粘合控制器，但要意识到 API 一旦发布就是承诺，成本从“写”变成“长期维护”。
文中可用工具
- Kubernetes容器编排平台，提供 CRD、控制器、RBAC 等基础能力
- Kubebuilder帮助开发者快速搭建 Kubernetes 控制器的框架
- Helm在渲染阶段管理一组资源，Helm 4 增加了服务端应用和等待资源状态
- Argo CDGitOps 工具，用同步波次、钩子和健康检查补足清单里缺失的顺序与就绪信息
- Crossplane用组合和函数管理资源，v2 可直接组合原生 Kubernetes 资源
- kro（Kube Resource Orchestrator）把资源接线写成数据，由单个控制器解释，0.10 的 Graph 用于无需对外 API 的场景
- CEL在集群内求值的表达式语言，kro 用它表达资源间引用并推断依赖顺序
- OpenAPI为字段提供类型定义，kro 在实例创建前据此做类型检查
- Server-side apply跟踪每个字段由谁拥有，避免多方写入冲突
展开详情收起详情：Kubernetes 平台为何反复重建本可共享的编排层⌄
原文发布：2026-10-29 21:00 · 首次收录：2026-10-30
在旧金山举行的 Universe ’26 大会上，GitHub 管理层回应了平台稳定性问题。他们表示已经增加 400 万核 CPU 和 160 PB 存储，并彻底重构后端基础设施。原因是 AI Agent 的访问方式和人类开发者差别很大，一些原本运行正常的服务出现了意外故障，因此不只是扩容，还要重写核心服务。对于前 CEO Thomas Dohmke 新创办的 GitHub 替代品 Entire，GitHub COO Kyle Daigle 说“世界不需要一个新的 GitHub”，开发者可能只是需要不同的工具。Dohmke 则回应称开发者显然需要新选择。这些投资和调整目前已经公布，但文章没有说明具体上线时间。
文中可用工具
- GitHub代码托管平台，文章讨论其稳定性和面向 Agent 时代的演进
- Entire前 GitHub CEO 创办的 GitHub 替代平台，定位为开源、可扩展、多区域部署的开发者社区新家
展开详情收起详情：“我认为世界不需要一个新的 GitHub”：GitHub 高层如何看新竞争对手⌄
原文发布：2026-10-29 21:30 · 首次收录：2026-10-30
AWS 发文介绍 Elastic Beanstalk 面向受监管行业工作负载的定位。过去这类托管平台主要比拼“多快能把代码跑起来”，但医疗、金融、政府等受监管组织的应用往往要运行多年，期间要打补丁、应对运行时停止支持、满足不断变化的安全与审计要求。原文认为中型组织缺少大企业那样的平台工程、安全和合规专岗，却要承担 HIPAA、PCI DSS、SOX、FedRAMP 等义务，应用组合一多就容易出现配置“漂移”，审计风险随之上升。文章强调该平台能直接部署已有的 Java JAR、.NET/IIS、PHP、Python 等应用而无需先容器化，并用统一方式管理整个应用组合。目前原文只是介绍性内容，未说明具体发布时间、可用状态或价格。
文中可用工具
- AWS Elastic BeanstalkAWS 的托管应用平台，用于部署和管理应用，原文称其适合受监管工作负载长期运行
展开详情收起详情：AWS Elastic Beanstalk 面向受监管工作负载：为下一个十年而建，而不只是首次部署⌄
原文发布：2026-10-29 22:00 · 首次收录：2026-10-30
法国 AI 公司 Mistral 周四在 Hugging Face 上发布了前沿开放权重模型 Mistral Large 4（ML4）的权重。ML4 三周前才开放预览，公司称经过强化学习和客户、伙伴测试后提升明显：在 Terminal-Bench 4.0 智能体编程测试中得 41%，仅比 GLM-5.3 的 40% 高 1 分，并称每任务平均少用 47% 的 token；网络安全测试 CyberGym 得 79%，GLM-5.3 为 29%。Mistral 强调开放权重是为了让模型能跑在自己的基础设施上，不被别人随时关掉，并把 ML4 称为通往下一代模型的“垫脚石”，还预告未来几个月会推出可在笔记本上运行的小型号。读者可留意：这是可下载权重的模型，但各项对比分数均来自 Mistral 自己的测试，成本优势的说法也未提供第三方验证。
文中可用工具
- Mistral Large 4 (ML4)Mistral 发布的前沿开放权重模型，主打智能体编程和网络安全能力，权重已可在 Hugging Face 下载
- Hugging Face模型权重发布与获取的平台
- Terminal-Bench 4.0用于评测智能体编程能力的基准测试
- CyberGym E2E测试防御性网络安全能力的评测项目
- GLM-5.3文中作为对比对象的竞品模型
- GLM-5.3 Flash文中作为对比对象的较小竞品模型
- Kimi K3文中作为编程基准对比的模型
- Muse Spark Open文中作为编程基准对比的模型
- DeepSeek v4.1 Flash 1017文中作为网络安全基准对比的模型
- MiMo-V2.6-Pro文中作为网络安全基准对比的模型
展开详情收起详情：Mistral Large 4 开放权重发布，编程能力以 1 分优势领先 GLM-5.3：“竞争对手能做的事，这个模型都能做”⌄
原文发布：2026-10-29 22:49 · 首次收录：2026-10-30
AWS 的开发者倡导者 James Ward 提出，很多 MCP 服务器目前只是被动地返回数据，就像一个只负责查数据的接口。他建议服务器在返回数据时顺便告诉 Agent 刚做了什么、接下来可以做什么、去哪里找更多信息，相当于让服务器成为对话中的另一个参与者。他还指出 MCP 默认无法追踪调用链路，AWS 的做法是给工具加会话 ID 参数，让多次调用串成完整旅程，再加一个参数记录用户目标，方便团队复现问题、做评测并改进工具。对使用 MCP 的团队来说，这意味着要同时观察人和 Agent 协作的路径，检验工具改动是否真的帮用户完成任务。文中提到 AWS 已于 5 月向所有人开放其 MCP Server，并在 9 月加入 Lambda 诊断功能；这些做法本身并不新奇，重点在于能否持续观测和衡量。
文中可用工具
- MCP ServerAWS 提供的 MCP 服务器，现已向所有人开放，并加入了 Lambda 诊断功能
- Lambda diagnostics用于 Lambda 的诊断能力，帮助排查问题
- CLIAWS 提供的命令行工具，可在不同 AWS 用户配置之间切换
- skills原文未说明具体用途
展开详情收起详情：为什么 MCP 服务器应当告诉 Agent 下一步做什么⌄
原文发布：2026-10-29 23:55 · 首次收录：2026-10-30
微软把 GitHub Copilot 背后的 Agent 调度框架通过 Microsoft Foundry 开放给外部开发者，作为托管服务提供。它自带沙箱、可复用的技能包、MCP 集成和对子 Agent 的支持，开发者只需选模型、写指令和配工具，运行环境由微软负责。目前是公开预览，到 2026 年 12 月 1 日前免费使用，之后按 CPU 和内存计费，模型推理等费用另算。好处是搭建 Agent 省事，但限制也明显：创建时选定的 harness 之后不能更改，CPU、内存和空闲时长由微软控制，也不能自带模型，更适合愿意接受这套约束的团队。
文中可用工具
- Microsoft Foundry微软的托管服务平台，用来构建和部署 Agent
- Foundry Agent Service提供 Copilot harness 的托管 Agent 服务
- GitHub Copilot微软的 AI 编程助手，也使用同一套 harness
- Copilot Studio微软用于构建 Copilot 产品的工具，同样基于该 harness
- VS Code代码编辑器，支持该 harness
- Azure Developer CLI用来部署和调用 Agent 的命令行工具
- MCP工具集成协议，接入时需要认证和审批
- azure.yaml配置文件，定义模型部署、工具、指令和 harness
展开详情收起详情：微软新 Copilot harness 让 Agent 搭建变简单，但想换就难了⌄
原文发布：2026-10-30 04:54 · 首次收录：2026-10-30
AWS 的 Hydro 团队正在开发一个开源 Rust 框架，用来编写分布式系统（即同时跑在多台机器上的软件）。现在他们的大部分代码由 AI 编程智能体生成，人力主要负责把关，于是出现了长达约 5000 行、难以拆分的改动，人工审查跟不上。更麻烦的是，智能体常同时写代码和单元测试，测试未必可信。他们的做法是在智能体的“信任范围”之外加入由编译器执行的共享正确性检查，像 Rust 借用检查器那样在运行前就发现问题，让智能体立刻得到反馈。Hydro 目前是早期版本，适合对延迟和吞吐有要求的团队，但还不完善、需要学习；相关工具 Hydro 和 Infinity 已开源，由 AWS 与加州大学伯克利分校联合开发。
文中可用工具
- Hydro开源 Rust 分布式系统框架，可在编译阶段检查多类错误并给智能体即时反馈
- Infinity开源智能体运行时，等待工具调用或 CI 任务时暂停智能体以节省资源
- RustHydro 使用的编程语言，其借用检查器可在运行前发现竞态条件
展开详情收起详情：AWS Hydro团队希望让编译器捕捉编程智能体的错误⌄
原文发布：2026-10-30 05:53 · 首次收录：2026-10-30
OpenAI 的 CEO Sam Altman 在一档播客里说，公司曾考虑对下一代模型不再按 token 计费，改成开发者提交一个提示词、OpenAI 直接给出一个总价，像 AWS 那样“用完给你账单”。但试问客户时反馈非常负面：大家说“我得知道自己在为什么付钱”，否则成本没法估算。还有人表示宁可单价提高、也要保留按 token 的明细，因为“知道背后有真实的东西”。所以这个想法被放弃了，目前 token 定价仍在用。Altman 自己也承认 token 是“一种假单位”，不是衡量 AI 用量的好单位，但暂时没有更好的替代方案。对开发者来说，现阶段计费方式不变；事件中涉及的模型和时间表均未说明。
展开详情收起详情：Sam Altman 差点取消 Token 定价，为什么又放弃了？⌄
原文发布：2026-10-30 06:19 · 首次收录：2026-10-30
OpenAI 在 DevDay 宣布 ChatGPT 周活跃用户突破 12 亿，约相当于全球人口的 15%。这么多人和越来越多的 AI 智能体同时发起请求，每次聊天、API 调用和模型调用都得先验证身份和权限，传统集中式身份系统在高并发下容易成为瓶颈。OpenAI 采用 Ory 的解耦认证引擎和 OAuth2/OIDC 基础设施，让令牌校验在边缘以无状态方式完成，减少反复回查中心数据库。文章还比较了自托管可组合 IAM 与传统身份 SaaS 在数据主权、成本和扩展方式上的差异，并提到让智能体先“观察模式”运行、再收紧权限的思路。对读者的价值是：了解面向超大规模和智能体负载设计身份鉴权时的关键取舍。
文中可用工具
- Ory提供解耦的认证引擎和 OAuth2/OIDC 身份基础设施，供 OpenAI 这类超大规模场景使用
- Ory Kratos处理身份生命周期、凭证哈希和会话管理的微服务
- Ory Hydra高性能 OAuth2/OIDC 服务器，负责签发访问令牌和管理授权流程
- Ory Keto基于 Google Zanzibar 模型的细粒度权限控制引擎，评估关系元组
- ChatGPTOpenAI 的聊天产品，文中称其周活跃用户已超 12 亿
- Codex原文仅提及名称，未说明具体用途
- CockroachDB分布式 SQL 数据库，用于跨区域复制身份验证状态
- Spanner原文仅提及名称，未说明具体用途
- Postgres原文仅提及名称，未说明具体用途
- Auth0文中作为传统多租户身份 SaaS 的例子出现
- Okta文中作为传统多租户身份 SaaS 的例子出现
- Ping Identity文中作为传统多租户身份 SaaS 的例子出现
展开详情收起详情：从人类点击到智能体速度：OpenAI 12 亿用户规模对你的鉴权意味着什么⌄
原文发布：2026-10-28 20:00 · 首次收录：2026-10-29
这篇文章讲的是：当负责处理退款的 AI Agent 中途崩溃时，如何让接替它的新 Agent 安全接手，而不会重复退款。原来问题在于，Agent 会自己推理、临时决定，崩溃后新 Agent 可能重新想一套方案，甚至再退一次款，导致用户被退两次钱。作者的做法是：在发起退款前，先把这笔操作的金额、授权、幂等键和状态写进数据库（相当于先立一张可查的“操作底账”），新 Agent 只能继承这张底账，不能自己改写；支付接口前还有一层校验，只放行记录里已授权的操作。这样即使崩溃，也能靠同一个幂等键和操作编号查清到底发生了什么，避免重复退款。对读者的用处是：如果你在生产环境跑 Agent 处理支付、订单等有副作用的操作，可以用“持久操作记录+幂等键+边界校验”的思路提升可靠性。文中提到的 LangGraph、Temporal 能恢复执行，但不能判断外部是否已成功；Langfuse 和 ClickStack 可用于追溯，但都只是辅助证据，最终以支付方记录为准。
文中可用工具
- ClickHouse Managed Postgres存放业务数据和权威操作记录
- ClickStack查询应用遥测和日志
- Langfuse查看 Agent 调用链和工具调用记录
- LangGraph持久化执行进度并在失败后恢复
- Temporal持久化执行进度并在失败后恢复
- Langfuse MCP server让 Agent 按操作 ID 查询此前的调用链
- ClickStack MCP server让 Agent 检索同一时间窗口内的服务事件
展开详情收起详情：AI Agent 需要可替换——同时不丢失工作成果⌄
原文发布：2026-10-28 21:00 · 首次收录：2026-10-29
文章用一个虚构例子说事：云平台上有一个叫 research-agent-2 的账号，它的访问密钥是 14 个月前创建的，最后一次使用是 11 个月前，但至今仍然有效。问题出在：人离职会触发账号回收流程，但一个干完活的 AI 助手（agent）往往只是关掉页面就走，没人回头清理它的权限；而 AWS IAM 的访问密钥不会自动过期，于是这把旧钥匙一直能开门。文章引用 OWASP 2025 年非人类身份风险榜单，把“下线条目没处理好”排在第一位，并提到 2026 年 9 月 GreyNoise 记录的一次攻击：从零到在真实目标上实现远程代码执行不到 4 小时，26 秒内攻陷至少 11 家机构，说明拖慢清理很危险。解决办法分三步：用 CloudQuery 把 AWS 凭证报告同步进数据库，再用给出的 SQL 查询找出“创建超过 90 天且 90 天以上没用过”的有效密钥，然后由指定负责人复核，配合策略和定时任务处理。注意 90 天只是复查门槛，不是判死刑；查询不包含 root 账号密钥，那需要单独紧急审计。文章提供的是自查方法和查询语句，属于已给出的操作指导，不是新发布的工具。
文中可用工具
- CloudQuery把 AWS IAM 凭证报告同步到数据库，方便用 SQL 查询长期未用的密钥
- AWS IAM管理用户访问密钥，其密钥不会自动过期
- ClickHouseCloudQuery Platform 使用的查询数据库方言
- PostgreSQL另一种可运行文中查询语句的数据库
展开详情收起详情：Agent 早已消失，它的访问密钥却还活着，会发生什么？⌄
原文发布：2026-10-28 22:00 · 首次收录：2026-10-29
Nvidia 发布了 Nemotron 3.5 Transcribe，这是一个开源权重的多语言转录模型。以前的转录模型只能按音频原样转写，出错了也不好纠正；这次的新模型支持在开始前给它提示，比如告诉它这是英语医学讨论、附上专业术语表，还能要求标注说话人、指定逐字或整理后的格式。它可以处理 40 种语言、最长一小时的录音，但不支持实时直播。Nvidia 称它在 Hugging Face 英语开源语音识别榜上以 5.33% 的平均词错率排第一，在部分基准上还优于参数量大得多的 Voxtral。开发者可以用 vLLM 部署，或用 NeMo-Speech.cpp 在本地单 GPU 上运行，也能用 NeMo 工具微调以进一步降低错误率。模型已经发布，属于开源权重，采用 OpenMDW-1.1 许可。
文中可用工具
- Nemotron 3.5 TranscribeNvidia 新发布的可提示多语言转录模型，支持说话人标注和翻译
- VoxtralMistral 的可提示语音转文字模型，文中用作对比
- Universal 3 ProAssemblyAI 的可提示语音转文字模型，文中提及
- vLLM用于部署该模型的推理服务框架
- NeMo-Speech.cpp用于在本地运行该转录模型的工具，项目已开源在 GitHub
- NeMo Speech提供微调工具，可帮助降低模型错误率
- NeMo Curator用于构建 Granary v2 数据整理流水线
- Granary v2可复用的数据整理流水线，附带公开清单，用于准备自定义训练数据
展开详情收起详情：Nvidia 发布可提示的转录模型⌄
原文发布：2026-10-28 23:00 · 首次收录：2026-10-29