谷歌研究团队开发了一个叫 AI-PPG-ACC-HTN 的 AI 系统，用普通智能手表上的光学和运动传感器被动检测高血压迹象，不需要用传统袖带做校准。高血压早期几乎没有症状，很多人不知道自己患病，而现有的无袖带设备通常要先用手臂袖带读数校准，只能看相对变化。新方法不直接估算某一时刻的血压数值，而是把多天的生理信号汇总，判断一个人是否长期处于高血压状态；它用 2109 名参与者的数据训练，并在 196 人的临床研究中与 24 小时动态血压监测这一金标准对比，初筛灵敏度 65.8%、特异度 90.0%，确认场景下灵敏度 78.4%、特异度 90.9%，与传统袖带流程相当。这些发现已用于 Google Health 应用中的血压趋势功能；不过文中摘要末尾被截断，该系统是否作为独立诊断工具开放、具体上线范围如何，材料没有说完，且明确表示并非用于替代诊断。
文中可用工具
- AI-PPG-ACC-HTN用智能手表传感器被动判断用户是否长期处于高血压状态的 AI 系统
- Google Health 应用提供血压趋势 Health Guardian 功能的健康应用
展开详情收起详情：利用可穿戴传感器检测高血压迹象⌄
Google Research Blog
原文发布：2026-11-06 00:01收录：2026-11-06
资产管理公司富兰克林邓普顿正在用 OpenAI 的技术搭建 AI 工作流程，帮投资经理做研究。原来投资经理要人工比对大量研究报告、梳理投资风险，费时费力；这次先从股票研究入手，让 AI 辅助对比不同研究观点、检查投资风险。对读者来说，这反映了金融机构把大模型用进投研一线的一个实际案例。目前只提到“正在开发”，尚未说明何时上线或开放使用。
文中可用工具
- OpenAI为投资研究提供 AI 能力，原文未说明具体产品或接口
展开详情收起详情：富兰克林邓普顿利用 OpenAI 支持投资研究⌄
OpenAI News
原文发布：2026-11-05 08:00收录：2026-11-06
Cult.fit 正在使用 OpenAI 的 Codex，让不同职能的团队都能自己动手做工具、加快工作速度，并改变做事方式。原文没有说明具体是哪些团队、做了哪些工具、效率提升了多少，也没有说明 Codex 是已全面可用还是试点阶段。对读者来说，这是一个企业把 AI 编程工具推广到非技术岗位的案例，但可参考的细节有限。
文中可用工具
- CodexOpenAI 的 AI 编程工具，帮助团队编写代码、构建内部工具
展开详情收起详情：Cult.fit 借助 Codex 构建运营能力⌄
OpenAI News
原文发布：2026-11-06 04:00收录：2026-11-06
澳大利亚多所大学正在扩大学生使用ChatGPT的渠道，并把AI融入课堂教学。此前学生难以在正规学习中接触和使用这类工具，这次通过开放访问、将AI纳入课程来填补这一空白。对读者来说，这意味着未来毕业生的AI使用能力可能更强，也为教育界如何应对AI提供参考。原文未说明具体是哪几所大学、覆盖多少学生、从何时开始，也未区分哪些措施已落地、哪些仍在计划中。
文中可用工具
- ChatGPT供学生和教师在学习教学中使用的AI对话工具
展开详情收起详情：澳大利亚高校正在培养AI原生毕业生⌄
OpenAI News
原文发布：2026-11-06 01:00收录：2026-11-06
Flipsnack 是一家把翻页电子书和在线杂志做出来分享的服务商，他们希望更多人试用产品。过去投放广告时，可能更关注曝光而不是实际注册。这次他们调整 ChatGPT 广告的投放重点，直接以“让人试用产品”为目标，结果注册量提升，同时每个注册的成本下降。对做营销的读者来说，这说明把广告目标对准真实转化动作，比单纯追求点击更划算。不过原文没有说明具体投放时间、预算规模、注册量或成本降幅，因此这些数字无法确认。
展开详情收起详情：Flipsnack 借助转化优化提升产品注册量⌄
OpenAI News
原文发布：2026-11-05 08:45收录：2026-11-06
Merge 是一家公司，它用 OpenAI 的 GPT-6 Astra、ChatGPT 和 Codex 来做两类事情：一是检查自己产品的代码，二是支持市场推广工作。它的团队还用 AI 来策划高管晚宴、准备销售更新材料。原文只提到这些用途，没有说明具体效果、发布时间或哪些已经能用。对读者的用处是了解一家企业如何把 AI 同时用在研发和日常业务上。
文中可用工具
- GPT-6 Astra用于审查产品代码等任务
- ChatGPT用于支持市场推广等日常工作
- Codex用于审查产品代码
展开详情收起详情：Merge 借助 OpenAI 技术打造产品与业务工具⌄
OpenAI News
原文发布：2026-11-05 16:00收录：2026-11-06
Dynatrace 发布了 10.26 版本更新，新增名为 SRE Agent 的 AI 助手，能在问题排查时先收集证据、给出根本原因和修复建议，但不会自动执行修复，需人工审核确认。同时改进了分布式追踪：从问题进入追踪时自动沿用时间范围和筛选条件，跨队列或 Serverless 边界的请求可自动关联上下游链路，不用手动查找。还加入了按位置和体验分数定位受影响用户、网络连接健康检查、Google Cloud 监控以及无需账号即可分享实时看板等功能。目前这些功能已在该版本中提供。
文中可用工具
- SRE Agent在 Workflows 中自动开展问题调查，收集证据并给出根本原因和修复建议
- Agentic Operations提供可配置的 AI 运维动作，用于工作流中的问题排查
- Dynatrace Assist在聊天中直接理解当前打开的页面内容并回答问题
- Distributed Tracing保留问题的时间范围和筛选条件，并自动关联跨队列的请求链路
- OneAgent Network Connection Monitoring采集主机间和进程间的网络连接数据
- Grail提供 Apdex 评分和拓扑数据的存储与查询
- Smartscape展示服务与资源的依赖拓扑
- OpenPipeline自定义前端事件的命名、分组和体验评分规则
- ActiveGate原文提到接入 Google Cloud 时无需用它做指标轮询
- Weather原文未说明用途
展开详情收起详情：Dynatrace 发布雷达 10.26⌄
Dynatrace Blog
原文发布：2026-11-05 20:25收录：2026-11-06
Dynatrace 发文指出，Kubernetes 集群默认允许任意 Pod 互相访问。若没有定义 NetworkPolicy 并由网络插件真正执行，一个只负责网页的 Pod 也能直连数据库，哪怕它根本不需要。文章用有漏洞的示例应用和开源工具 Kimera 演示：攻击者从被攻陷的前端 Pod 出发，能通过 DNS 发现全部 16 个服务，并连上数据库、缓存和 Kubernetes API。随后用 NetworkPolicy 阻断这些路径，验证策略是否真的生效。对读者的用处是：如果你在运行 Kubernetes，应先检查命名空间里有没有网络策略，而不是只加固单个容器，因为去掉全部权限的 Pod 照样能访问别的服务。
文中可用工具
- KimeraDynatrace 维护的开源 Kubernetes 安全测试工具，在授权演示环境中检查和验证网络策略等安全控制
- NetworkPolicyKubernetes 中用于限制 Pod 之间访问的对象，需由网络层实际执行
- Unguard application故意留有漏洞的微服务示例应用，用于演示攻击与修复
- CoreDNS为服务提供可预测名称的域名解析，演示中被用于发现服务
- Dynatrace Kubernetes Security Posture Management (KSPM)持续检查 Kubernetes 配置是否符合安全与合规要求，标出缺失的网络策略
- Smartscape展示应用中介攻击路径中涉及的服务调用
- MariaDB演示环境中的数据库实例，原本不该被前端访问却可达
- Redis演示环境中的缓存实例，演示中发现可从被攻陷的 Pod 连接
展开详情收起详情：Kubernetes 安全要点：网络配置错误——看不见的攻击面⌄
Dynatrace Blog
原文发布：2026-11-06 00:30收录：2026-11-06
Datadog 的产品营销经理回顾了在拉斯维加斯举办的 Oracle AI World 2026。会上 Oracle 宣布与 OpenAI 合作，推出 Oracle AI Workspace，让员工能在 ChatGPT 里完成 Oracle 各业务系统中的审批流程工作，还发布了 Fusion Companion 和 Fusion Agentic Home。Datadog 展示了如何监控 Oracle Fusion 应用、数据库和云基础设施：采集调度任务和审计日志指标，并自动模拟真实用户测试。此外，Oracle 计划在 2027 年为政府云的多云数据库服务申请 FedRAMP Class D 认证，具体时间因云和地区而异。对使用 Oracle 的团队来说，这些监控能力可以帮助他们放心引入 AI Agent，并用数据回答审计问题。
文中可用工具
- Oracle AI Workspace让员工在 ChatGPT 内完成 Oracle 业务系统里已批准的流程
- ChatGPT作为员工执行 Oracle 业务工作流的入口界面
- OpenAI Codex原文未说明具体用途
- Fusion Companion接受业务目标并交给 AI Agent 执行的应用
- Fusion Agentic Home接受业务目标并交给 AI Agent 执行的应用
- Oracle AI Database@AWS在 AWS 数据中心内运行的 Oracle 数据库服务
- Oracle AI Database@Azure在 Azure 数据中心内运行的 Oracle 数据库服务
- Oracle AI Database@Google Cloud在 Google Cloud 数据中心内运行的 Oracle 数据库服务
- Datadog跨云监控 Oracle 应用、数据库和基础设施的可观测性平台
- Oracle Fusion Cloud ApplicationsOracle 的企业业务应用套件，可用 Datadog 监控其调度任务和审计日志
- Oracle Cloud Infrastructure (OCI)Oracle 的云基础设施，可用 Datadog 监控
- Synthetic MonitoringDatadog 功能，自动从外部模拟真实用户测试 Oracle Fusion
展开详情收起详情：Oracle AI World 2026 亮点回顾⌄
Datadog Blog
原文发布：2026-11-05 08:00收录：2026-11-06
Datadog 的工程师发布了一个叫 DatadogInstrumentation 的 Kubernetes 自定义资源配置，把应用的指标检查、日志收集和调用链追踪（APM）配置统一放到一个 Kubernetes 资源里。过去这些设置分散在 Pod 注解和 Agent 配置文件里：改注解要重新部署应用，改 Agent 配置要找平台团队并可能重启 Agent。现在应用团队可以在自己的 GitOps 流程里改这份配置，运行时生效，不用重启应用或 Agent，平台团队仍管 Agent 部署。配置写错时 kubectl apply 会直接报错，还能通过状态条件（ChecksReady、LogsReady、APMReady）排查问题。
文中可用工具
- DatadogInstrumentationKubernetes 自定义资源，把单个工作负载的指标检查、日志和 APM 配置集中在一处管理
- Datadog Operator平台团队用来部署 Datadog Agent 的运维组件
- DatadogAgentOperator 的资源，用来维护 Agent 部署和 APM 目标规则
- Single Step Instrumentation自动给符合条件的应用 Pod 注入追踪 SDK
- Datadog Agent负责采集指标、日志和追踪数据的采集代理
- Cluster Agent在应用配置时校验资源，并把状态反馈到 Kubernetes
展开详情收起详情：使用 DatadogInstrumentation 管理 Kubernetes 可观测性⌄
Datadog Blog
原文发布：2026-11-05 08:00收录：2026-11-06
Datadog 的工程师为事件数据库 Husky 写了一份 TLA+ 形式化规范，用来描述系统哪些状态是合法的。问题是，规范只写一次，系统却一直在改，几年后放置逻辑变了，允许两个冲突的放置同时存在约一年，平时没事，但一旦放置数据丢失、系统回填时，两个冲突就足以让回填崩溃。他们做了 FETCh 工具，把 TLA+ 规范变成运行时的检查器，拿真实生产行为对照规范，于是发现了常规测试没抓到的这个 bug。对读者的意义是：形式化规范可以和线上系统持续对账，避免规范悄悄过期带来的虚假安全感；目前这是 Datadog 自建并用于 Husky 路由系统的实践。
文中可用工具
- FETCh把 TLA+ 形式化规范转成运行时监控器，持续拿生产行为对照规范
- TLA+用于描述分布式系统合法状态与状态转换的形式化规范语言
- PObserve用真实执行轨迹监控 P 规范的开源项目，文中作为对比提及
- HuskyDatadog 的第三代事件存储系统，FETCh 的验证对象
展开详情收起详情：我们如何在生产环境中持续验证形式化规范⌄
Datadog Blog
原文发布：2026-11-05 08:00收录：2026-11-06
安全工具公司 Semgrep 被 Forrester 写进了 2026 年第四季度的「智能体开发安全工具」评测报告。背景是 AI 写代码让代码量暴涨，有客户反馈漏洞数量增加了最多 20 倍，人工分诊跟不上。Semgrep 的解法是用 AI 结合企业自身上下文和历史决策来自动分诊，用户对自动分诊结论的接受率稳定在 96%，多数客户首次使用时待处理漏洞积压减少约 60%；它还用「规则检测加模型推理」来发现提示注入、敏感信息泄露、过度授权等 AI 应用问题，并能自动修复，平均每个问题省 30 分钟。对开发团队来说，这意味着 AI 生成代码的安全检查可以更省人力、少拖慢开发节奏。文中提到的 Multimodal、Guardian 等功能已发布，具体报告内容需访问原文查看；文章未说明报告是否给出评分或排名。
文中可用工具
- Semgrep代码安全扫描工具，可发现漏洞并自动修复
- Semgrep Multimodal把 AI 推理和规则分析结合，用于漏洞检测、分诊和修复
- Semgrep Guardian在 AI 生成代码写出的当下即扫描并修复问题
- Semgrep Agentic Workflows提供预置工作流，自动化大规模深度漏洞排查
- OpenAISemgrep 规则集覆盖的 AI 服务提供方之一
- AnthropicSemgrep 规则集覆盖的 AI 服务提供方之一
- BedrockSemgrep 规则集覆盖的 AI 服务提供方之一
- LangChainSemgrep 规则集覆盖的 AI 开发框架之一
- CursorSemgrep 规则集覆盖的 AI 编程工具之一
- Claude CodeSemgrep 规则集覆盖的 AI 编程工具之一
展开详情收起详情：Semgrep 入选 Forrester Wave™：2026 年第四季度智能体开发安全工具报告⌄
Semgrep Blog
原文发布：2026-11-05 08:00收录：2026-11-06
Dropbox 宣布计划以 3.5 亿美元收购做 AI 对象存储的初创公司 Tigris，并预告将推出 DBX Agent Cloud，先让开发者直接从 Dropbox 购买对象存储。Dropbox 多年前已把 90% 以上用户数据从亚马逊 S3 迁到自建系统 Magic Pocket，但面向外部客户卖存储是另一回事，所以买下有现成产品、团队和客户的 Tigris。Tigris 的存储兼容 S3，会自动把数据放在离计算近的地方，且转出数据不收流量费，可帮训练 AI 的开发者省钱、省时。收购还需监管批准，DBX Agent Cloud 未公布上线日期，技术整合细节也未说明；现有 Tigris 客户初期无需迁移。
文中可用工具
- AWS S3亚马逊的对象存储服务，Dropbox 曾把大部分用户数据放在上面，Tigris 的产品也与之兼容
- Magic PocketDropbox 自建的内部存储系统，用来替代亚马逊 S3
- TigrisDropbox 计划收购的 S3 兼容对象存储服务，面向 AI 应用，不收转出流量费
- DBX Agent CloudDropbox 计划推出的服务，让开发者直接从 Dropbox 购买对象存储，尚未公布上线日期
- DashDropbox 2023 年推出的 AI 搜索工具，可跨多个服务查找信息
展开详情收起详情：Dropbox 弃用 AWS S3 自建系统后，如今收购 Tigris 向 AI 开发者出售兼容 S3 的存储服务⌄
The New Stack
原文发布：2026-11-05 22:00收录：2026-11-06
企业级数据库公司 EnterpriseDB（EDB）收购了 ClickHouse 专业服务公司 Altinity，两家现在合到一张路线图上。原来开发者要同时用 Postgres 存订单等关键数据、用 ClickHouse 做快速分析，中间得自己搭复制、消息队列、去重和监控这一长串管道，半夜告警常来自这里；AI 智能体若读到二十分钟前的旧数据，还可能以机器速度反复做错决定。新计划的核心是用 Iceberg 这类开放表格式做共享层，让三种引擎读同一批表，并朝统一目录、统一权限和统一控制台努力，同时由 Altinity 的 Kubernetes 运维经验来管理 ClickHouse。不过共享目录和统一治理目前仍是规划，尚未说明何时可下载使用；今天能用的只是各引擎通过 Iceberg 互读，以及 Postgres 侧对智能体的用途限定访问。
文中可用工具
- Postgres保存订单、账户等不能出错的核心业务数据
- ClickHouse对海量事件做高速分析查询
- WarehousePGEDB 的大规模并行数据仓库引擎，可与前两者读同一批表
- Apache Iceberg开放表格式，充当几种引擎共享数据的中间层
- EDB Postgres AI把多模型数据层、智能体运行时和治理放在一起的产品
- Altinity Kubernetes Operator在 Kubernetes 上部署和运维 ClickHouse
- Altinity Stable Builds提供三年安全与缺陷修复支持的 ClickHouse 稳定版本
- Altinity.CloudAltinity 的托管 ClickHouse 云服务
- CloudNativePGEDB 创建并捐给社区、现属 CNCF 的 Postgres Kubernetes 运维工具
展开详情收起详情：Postgres 与 ClickHouse 可共享表，EnterpriseDB 想用一套规则统一治理⌄
The New Stack
原文发布：2026-11-05 22:00收录：2026-11-06
AI智能体从回答问题转向执行行动，需要实时了解业务状态。但传统数据架构多为批量分析设计，难以支持亚秒级查询。为此，Confluent、Aiven、StreamNative和Ververica等公司共同定义了“streamhouse”架构——一种持续提供实时业务状态的数据模式，旨在满足智能体对实时、生产级和去中心化数据的需求。该架构已发布开放定义，可基于Kafka、Flink、Iceberg等开源技术构建。对读者而言，这意味着未来AI智能体可能更及时、更准确地执行任务，同时降低模型调用成本；但该架构尚处推广阶段，实际部署效果未说明。
文中可用工具
- Apache Kafka分布式流处理平台，用于实时捕获和传输数据事件
- Apache Flink流处理框架，用于实时处理和分析数据流
- Apache Iceberg开放表格式，用于管理大规模分析表，支持流式与批量统一
- Confluent提供基于Kafka的商业化流数据平台
- Aiven提供托管开源数据基础设施服务，可能包括Kafka等
- StreamNative提供基于Apache Pulsar的流数据平台服务
- Ververica提供基于Apache Flink的企业级流处理平台
展开详情收起详情：新的streamhouse架构如何解决Agentic AI的数据难题⌄
The New Stack
原文发布：2026-11-05 22:30收录：2026-11-06
Docusign 做了一个 MCP Server（可以把 MCP 理解成 AI 助手连接外部软件的一套通用插头标准），让 ChatGPT、Claude、Copilot 等 AI 助手能直接查找合同、查看状态、准备签署，而用户不用切换到 Docusign 里操作。这个服务 2026 年 5 月开放测试，9 月 30 日全球正式可用。测试中他们发现，真正的难点不是把 AI 接上企业软件，而是让它在用户权限范围内找到正确信息、完成正确任务，于是补充了本地文件上传、账户级开关等能力，并用 OAuth 2.0 保证 Agent 不能做用户本人做不到的事；最终审批仍由人负责。对普通用户来说，以后可以让常用 AI 助手代查代办合同事务，但第三方 AI 平台如何存储数据仍需用户自己评估。
文中可用工具
- Docusign MCP Server让兼容的 AI 助手和 Agent 直接访问 Docusign 的合同创建、查找、状态查询和签署准备等能力
- Model Context Protocol (MCP)开放标准，让 AI 应用连接外部数据和工具并调用其能力
- Intelligent Agreement Management (IAM)Docusign 的协议管理平台，MCP 服务器把其中的部分能力开放给 AI 工具
- Contract Lifecycle Management (CLM)Docusign 面向复杂合同生命周期需求的高级合同管理软件
- MCP Apps在支持的客户端中提供本地文件上传等交互界面
- OAuth 2.0用于身份认证，确保每次工具调用都具备所需授权范围并限制在用户权限内
- Anthropic ClaudeDocusign 支持的 AI 客户端环境之一
- OpenAI ChatGPTDocusign 支持的 AI 客户端环境之一
- Google Gemini EnterpriseDocusign 支持的 AI 客户端环境之一
- Microsoft Copilot StudioDocusign 支持的 AI 客户端环境之一
- SlackbotDocusign 支持的 AI 客户端环境之一
- Salesforce AgentforceDocusign 支持的 AI 客户端环境之一
展开详情收起详情：从开放测试到全球正式发布：Docusign 将合同 AI 工作流接入 Agent 的经验⌄
The New Stack
原文发布：2026-11-05 22:50收录：2026-11-06
作者在 2024 年 9 月用同一套 20 个客服任务测试两个 Claude 模型，两者都拿到 20/20 满分。但他在其中加入两个“不该批准”的退款陷阱（一张未收款发票的退款、一张金额翻倍的退款）后发现，小模型 Claude Haiku 4.5 在三种权限配置下都违规批准了全部六笔退款，而 Claude Sonnet 5 一笔都没批——成功率看起来一模一样，真正的风险行为却完全不同。10 月他重跑时，小模型突然全部拒绝了，起初以为是任务排队顺序起了作用，后来查执行记录才发现：同一个模型别名在 9 月指向 claude-haiku-4-5，10 月已被悄悄换成 claude-haiku-5-5，而他原有的成功率指标完全没报警。于是他换了个思路：故意制造八种常见故障（换弱模型、压缩上下文、撤销权限、读旧数据、注入网络错误等），看哪些指标能真正抓到问题。结果是：工具调用次数和“权限范围漂移”各抓到四个故障，任务成功率只抓到两个，token 成本只抓到一个，退款陷阱抓到零个。对读者的提醒是：只看“有没有成功”并不足以说明 Agent 在生产环境里安全可靠，得同时监控行为层面的指标；这次模型被静默升级是好事，但监控缺口本身仍然是真问题。
文中可用工具
- Claude Haiku 4.59 月测试中会用的小模型；在退款陷阱里全部违规放款
- Claude Sonnet 59 月测试中的对比模型；退款陷阱一笔都没批
- Claude Haiku 5.510 月别名悄悄指向的新小模型版本；未授权退款全部拒绝
- Claude Sonnet 5.5建立基线的模型，拥有完整管理权限，用于三次重复基准测试
- mock enterprise API模拟企业 API，覆盖票据、用户、账单等 30 个受限操作，所有调用写入审计日志
展开详情收起详情：我用七种方式搞坏了一个正常运行的 Agent，而我盯的那个指标只抓住了其中两个⌄
The New Stack
原文发布：2026-11-05 23:00收录：2026-11-06
这篇文章讲的是企业用开源模型和 Kubernetes 来搭建智能体（能自己写代码、跑测试的 AI）的学习闭环。原来的问题是：跑模型推理、微调模型、运行智能体这三种任务对平台的要求完全不同，团队常常各建一套基础设施，结果这边 GPU 闲着、那边任务排队，而且智能体要执行自己刚写的代码，安全和密度很难兼顾。文章提出的解法是把这些当成普通云原生问题，用统一控制面分三层管理：模型层用 KServe、llm-d、KAITO 等把部署和微调变成声明式配置，Kueue、KubeRay 负责排队和分布式训练；执行层用 Kata Containers、gVisor、agent-sandbox 等做隔离，Agent Substrate 把大量空闲智能体挂起以节省成本；算力层负责把分散的 GPU 拉进集群。另外斯坦福 AI Index 2026 数据显示，截至 2026 年 3 月，最强闭源模型对最强开源模型的领先只有 3.3%。对读者来说，这意味着在很多场景下开源模型已够用，可以自己微调并持续改进。文中这些项目大多已开源，具体可用状态未逐一说明。
文中可用工具
- Qwen开源模型系列，发布在模型仓库上，可下载使用
- GLM-5开源模型，发布在模型仓库上
- Hugging Face模型仓库，用于发布和获取开源模型
- vLLM开源模型推理服务引擎，可加载下载的模型
- SGLang开源模型推理服务引擎
- KServe模型服务与调优相关的开源项目
- llm-d模型层开源项目，原文未细说具体用途
- KAITOKubernetes AI 工具链操作器，把模型及 GPU 需求声明为资源并自动调和
- Kueue负责任务排队和 gang 调度
- KubeRay编排分布式训练任务
- TauGrid微软开源的打包方案，一次 Helm 安装包含训练组件、GPU 健康监控和可观测性
- Run:ai Model Streamer把权重直接从对象存储读入 GPU 显存，加快新副本启动
展开详情收起详情：来自明天的明信片：用开源驱动智能体时代⌄
The New Stack
原文发布：2026-11-06 00:00收录：2026-11-06
企业正把 AI 和自主 Agent 引入数字运维与事件管理。和传统软件不同，这类 AI 出错时往往不会明显崩溃报警，而是幻觉、偏离事实或模型漂移等小错误在多个服务间层层放大，尤其在多 Agent 系统里更难发现。文章建议从四方面应对：给 Agent 设护栏，行为偏离时能停下、上报或交还人工；用监控 Agent 观察其他 AI 的异常并触发响应；用任务成功率、事实依据程度、时延、成本、人工升级率等指标衡量表现；持续评估，模型更新或正常运行时行为都可能变差，需实时告警加事后复盘。作者还建议先从分诊、诊断等低风险场景做起再逐步扩大。文中未说明这些做法来自哪家公司或是否有可用的具体产品。
展开详情收起详情：AI 故障威胁事件管理：四条规避之道⌄
The New Stack
原文发布：2026-11-06 01:00收录：2026-11-06
Groundcover 公司推出了一项名为 Autonomous Infrastructure 的测试版功能，用来自动调整 Kubernetes 上各个应用该申请多少 CPU 和内存。过去这些数值靠工程师在部署时估算，之后再没人回头看，结果常常要么申请太多白花钱，要么申请太少导致卡顿甚至崩溃。这个测试版用公司已有的 eBPF 传感器收集的生产数据，持续观察实际用量并给出调整建议，同时把改动对成本和性能的影响展示给工程师，边界仍由人来定。对读者来说，如果所在团队管理大量 K8s 工作负载，这可能减少手工核算资源的时间，但该功能目前是测试版，节省金额只是按标价估算，实际账单能降多少还取决于其他因素，文中也未说明正式发布时间。
文中可用工具
- Autonomous Infrastructuregroundcover 新推出的测试版功能，根据生产数据持续调整 K8s 应用的 CPU 和内存申请量
- Wandgroundcover 收购的 K8s 资源优化平台，新功能基于其技术构建
- eBPF sensorgroundcover 已有的传感器，收集应用和基础设施的运行数据用于决策
- Karpenter节点自动扩缩器，根据工作负载申请的资源增减节点
展开详情收起详情：Groundcover 自动调整 Kubernetes 资源规格，工程师设定边界⌄
The New Stack
原文发布：2026-11-06 01:14收录：2026-11-06