Anthropic 宣布，其 AI 协作平台 **Claude Cowork** 将于本周二首次登陆移动端和网页版。此前，Cowork 仅通过 macOS 和 Windows 的桌面应用提供，现在 iOS 和 Android 用户也能使用。不过，Anthropic 表示，桌面版仍提供“完整体验”，包括本地文件访问等功能。 此次扩展首先面向 **Max 订阅者** 开放，其他计划的用户将在“未来几周”内获得访问权限。Cowork 会话现在默认在云端运行，这意味着用户可以在不同设备之间无缝切换，甚至合上笔记本电脑后，任务仍可在后台继续执行。桌面应用仍保留本地处理选项，用户可自由切换云端与本地模式。 此外，**定时任务** 现在即使没有任何设备在线也能运行。Claude 还可在任务完成或需要审核时，向手机发送 **Cowork 通知**。 伴随此次发布，Anthropic 还将 **双倍 Cowork 使用限制** 延长至 8 月 5 日。此举进一步巩固了 Claude 在多设备协作领域的竞争力，尤其在远程办公和跨平台工作流日益普及的背景下。
微软正在预览一项名为 **Cloud rebuild**（云端重建）的全新恢复工具，旨在解决 Windows 11 系统因严重故障而无法启动的问题。该功能目前处于预览阶段，允许用户通过云端下载干净的 Windows 镜像和最新驱动，将系统恢复到出厂般的纯净状态，同时自动集成 Windows Update 的最新安全补丁，无需手动更新。 与现有的“重置此电脑”选项不同，Cloud rebuild 不依赖本地系统健康状态或 USB 介质，而是直接从 Windows Update 获取目标镜像和设备驱动，确保恢复后的系统功能完整且更新至最新。但需注意，此过程会清除所有个人文件、自定义设置和已安装应用，用户需提前备份数据。 这一功能极大降低了系统崩溃时的恢复门槛，尤其适合那些因驱动冲突、文件损坏或恶意软件导致无法进入系统的场景。微软表示，Cloud rebuild 的目标是让用户无需技术背景也能轻松应对系统级故障。目前该功能仅在预览版中可用，正式版发布时间尚未公布。
智能家居设备越来越多，但每件设备都用各自的App控制，反而让生活变得碎片化。本文将介绍如何利用 **Home Assistant OS** 将闲置PC变成统一的开源智能家居中枢，实现跨品牌设备联动，且完全免费。 ## 为什么需要智能家居中枢？ 智能音箱、智能灯泡、智能插座……每个设备都有独立App，控制起来手忙脚乱。**Home Assistant OS** 提供了一个统一控制面板，让你在一个界面管理所有设备，还能设置自动化场景，比如“离家模式”自动关灯、关空调。 ## Home Assistant OS 是什么？ Home Assistant 是一款开源的家庭自动化平台，支持超过2000种品牌和协议。**Home Assistant OS** 是其官方操作系统版本，专为树莓派、旧PC等设备优化，开箱即用，无需手动安装依赖。 ## 如何将闲置PC变成智能家居中枢？ ### 准备工作 - 一台闲置PC（建议至少2GB内存、16GB存储） - 一个U盘（用于安装系统） - 网线或WiFi连接 ### 安装步骤 1. **下载 Home Assistant OS 镜像**：前往 [home-assistant.io](https://www.home-assistant.io/installation/) 选择对应PC架构的镜像（如x86-64）。 2. **制作启动盘**：使用 Rufus 或 Balena Etcher 将镜像写入U盘。 3. **从U盘启动**：在BIOS中设置U盘优先启动，进入安装程序。 4. **完成安装**：系统会自动安装到硬盘，重启后即可通过 `http://homeassistant.local:8123` 访问。 ### 配置设备 - 首次访问会引导创建账户和初始化。 - 集成设备：在“配置-集成”中搜索你的设备品牌，按提示授权即可。 - 创建自动化：在“自动化”页面设置条件与动作，例如“当门磁传感器打开时，开启客厅灯”。 ## 优势与注意事项 **优势**： - 完全本地化，数据不出家门，隐私安全。 - 支持离线自动化，断网也能用。 - 社区活跃，插件丰富，可扩展性强。 **注意事项**： - 需要一定动手能力，但官方文档详尽。 - 部分设备可能需要通过HACS（Home Assistant Community Store）安装第三方集成。 - 建议使用有线网络，稳定性更好。 ## 结语 将闲置PC改造成智能家居中枢，不仅环保，还能让你真正掌控家中的智能设备。Home Assistant OS 免费、开源、功能强大，是打造个性化智能家居的理想选择。如果你有一台吃灰的旧电脑，不妨试试这个方案。
Amazon QuickSight 近期推出了一项重要更新——**数据集增强（Dataset Enrichment）**，允许用户将业务上下文（如列描述、同义词、计算字段、自定义指令和业务规则）直接嵌入数据集本身。这一变化标志着从传统 Topics 到语义数据集的架构迁移，解决了以往 Topics 与数据集需同步维护、权限分离、版本混乱等痛点。 ## 为什么需要迁移？ 在旧架构中，**Topics** 作为独立于数据集的对象存在，负责存储列同义词、计算字段、命名实体、过滤器和自定义指令。这种设计导致两个资产必须始终保持同步——任何一方的变更都可能引发“静默断裂”，例如数据集中重命名一列，而 Topics 中的同义词未更新，查询结果便会失真。此外，权限、血缘和版本管理分散在两处，增加了治理复杂度。 新的 **数据集增强** 将业务上下文直接“烘焙”进数据集。从此，权限、语义、AI 上下文都随数据流动，自动被基于数据集构建的所有资产继承。**一个资产、一个事实来源、一个管理点**，从根本上简化了治理。 ## Topics 的新定位：跨数据集语义与推理层 值得注意的是，Amazon QuickSight 并未废弃 Topics，而是重新定义了其角色。**Topics 现在成为多数据集语义与推理层**——用于组合多个数据集、定义关系、编写业务指标以及映射业务术语。原本属于数据集内部的语义下沉到数据集层，而 Topics 则专注于跨数据集的关系、度量和术语管理。 这一架构变化不是表面调整，而是建立了**清晰的前瞻性架构**：既支持确定性 BI 工作流，也为 AI 驱动的灵活分析提供了共享语义基础。同时，它为后续目录集成奠定了基础。 ## 三种迁移场景与分步指南 Amazon QuickSight 提供了三种迁移场景，帮助用户平滑过渡： 1. **简单替换**：当 Topics 仅包含单数据集语义（如同义词、计算字段）时，可直接将这些信息迁移至数据集增强中，然后删除旧 Topics。 2. **功能拆分**：如果 Topics 既包含数据集内语义，又包含跨数据集关系，则需将数据集内语义迁至数据集增强，跨数据集关系保留在重构后的 Topics 中。 3. **渐进迁移**：对于复杂环境，可逐个数据集迁移，同时保持旧 Topics 运行，直至所有数据集完成转换。 每类场景都附有详细步骤，包括如何在新的数据准备体验中编辑数据集、添加列描述与同义词、迁移计算字段，以及验证迁移后的查询结果。 ## 对 BI 与 AI 工作流的深远影响 此次更新对 Amazon QuickSight 用户意义重大。对于 BI 分析师，不再需要维护两套资产，减少了出错概率；对于 AI 驱动的分析（如 Q 的自然语言查询），嵌入数据集中的业务上下文（同义词、自定义指令）能显著提升查询准确性和用户体验。 长远来看，这一架构为**统一语义层**铺平了道路——所有数据产品（仪表板、报表、AI 问答）共享同一套业务定义，无论是人工分析还是机器推理，都能基于一致的理解进行。 ## 小结 从传统 Topics 到数据集增强的迁移，不仅是功能升级，更是 Amazon QuickSight 在语义层架构上的重要演进。它降低了治理成本，提升了数据一致性，并为 AI 原生分析奠定了基础。对于正在使用 QuickSight 的组织，尽早规划迁移路径，将有助于释放数据的全部业务价值。
## 从预连接表到运行时关联：QuickSight 数据建模的范式转变 商业智能分析师在启动每个分析项目时，几乎都会遇到同样的困境：回答一个业务问题所需的数据分散在多个表中。销售交易、客户人口统计、产品属性、退货、预测和运营指标各自占据不同的数据源。以往，在 Amazon QuickSight 中组合这些表需要在分析开始前将所有数据预连接成宽表、反范式化的数据集。这种做法虽然可行，但迫使数据建模决策前置，导致不同粒度的度量重复、维护开销增加，并且通常需要为几乎每个报表场景准备不同的数据集。 今天，Amazon QuickSight 正式推出**多数据集关系**功能。这项新能力允许用户在 QuickSight 数据集之间定义逻辑关系，并在查询时执行运行时连接。您不再需要提前扁平化表，而是将每个表保留为独立的 QuickSight 数据集，然后在 QuickSight Topic 中声明这些数据集之间的关联关系。QuickSight 会根据可视化、计算字段、筛选器或自然语言问答的需求，动态构建所需的连接。 ### 核心优势 - **更少的前期数据准备**：关系只需定义一次，QuickSight 在分析时仅连接相关表。 - **保留原始粒度**：每个数据集维持自身的细节级别，避免跨粒度重复度量。 - **跨分析复用**：一个包含已定义关系的 Topic 可服务于多个分析场景，无需重建数据集。 - **简化治理**：在单个数据集级别管理权限、转换和业务逻辑。 - **独立刷新调度**：根据数据变动频率，按不同节奏（小时、天、月）分别摄取数据。 - **运行时行级安全**：行级安全（RLS）规则在运行时连接时执行，确保数据访问策略跨数据集一致。 ## 数据建模最佳实践 为了充分发挥多数据集关系的价值，建议遵循以下设计原则： 1. **以主题域划分数据集**：将业务实体（如客户、产品、销售）分别建模为独立数据集，以保持逻辑清晰和复用性。 2. **明确关系类型**：根据业务逻辑使用一对多、多对一或多对多关系。例如，一个客户可以有多个订单（一对多），一个订单属于一个客户（多对一）。 3. **避免循环依赖**：在定义关系时确保无闭环，防止查询歧义或性能问题。 4. **优先使用星型模式**：事实表（如销售）与维度表（如时间、客户）建立关系，这是分析型查询的最优模式。 5. **处理粒度和聚合**：当数据集粒度不同时，在计算字段中明确聚合逻辑，例如使用 SUM 或 AVERAGE 处理事实表度量。 ### 支持的模式 QuickSight 多数据集关系支持以下常见模式： - **星型模式**：一个事实表关联多个维度表。 - **雪花模式**：维度表进一步关联子维度表。 - **多事实表**：多个事实表共享维度，例如销售和退货表都关联时间维度。 ## 结语 Amazon QuickSight 的多数据集关系功能标志着 BI 工具在数据建模灵活性上的重要进步。通过将连接逻辑从 ETL 阶段转移到查询运行时，分析师可以更敏捷地响应业务需求，同时保持数据治理的简洁性。对于希望减少数据准备时间、提升分析复用性的团队来说，这是一个值得投入的方向。 关于每种模式的具体实现和高级技巧，可以参考本系列的第二篇文章：《Amazon QuickSight 多数据集关系的数据建模模式》。
## 从概念到实践：Amazon QuickSight 多数据集关系的建模模式 在上一篇文章中，我们介绍了 Amazon QuickSight 多数据集关系的基础概念和维度建模最佳实践。本文则聚焦于**具体模式**，为每种数据模型提供表结构、用例、实现步骤和示例 SQL 查询，帮助你在实际工作中快速应用。 ### 前置说明 当前版本中，所有多数据集关系均使用**内连接**，只有键匹配的行才会出现在查询结果中。设计数据模型时需充分考虑这一点。 ## 七种原生支持的建模模式 ### 场景 1：简单星型模式 这是最常用且推荐的模式：一个中心事实表关联多个维度表。 **表结构示例**： - `SALES_FACT`：事实表，包含 `sale_id`（主键）、`customer_id`、`product_id`、`time_id`、`store_id`（外键）以及 `quantity`、`revenue`、`cost` 等度量。 - `CUSTOMER_DIM`：维度表，包含 `customer_id`（主键）、`name`、`email`、`city`、`state` 等。 - `PRODUCT_DIM`、`TIME_DIM`、`STORE_DIM` 类似。 **适用场景**：按客户细分和区域统计总销售额、按产品类别查看月度收入趋势、按平均订单价值排名前 10 的门店。 **实现方式**：为每个表创建独立数据集，通过外键建立关系（如 `SALES_FACT.customer_id → CUSTOMER_DIM.customer_id`）。所有连接均为单跳（事实到维度），无需链式连接。 **示例 SQL**： ```sql SELECT c.segment, s.region, SUM(f.revenue) AS total_revenue FROM SALES_FACT f JOIN CUSTOMER_DIM c ON f.customer_id = c.customer_id JOIN STORE_DIM s ON f.store_id = s.store_id GROUP BY c.segment, s.region; ``` ### 其他场景简介 除星型模式外，QuickSight 还支持： - **雪花模式**：维度表进一步规范化，需多跳连接。 - **多事实表共享维度**：多个事实表可复用同一维度表。 - **自引用关系**：如员工表包含经理 ID。 - **多对多关系**：通过桥接表实现。 - **时间序列与快照表**：处理累计快照和周期快照。 - **聚合与明细混合**：预聚合表与明细表共存。 每种模式都配有详细的表结构、适用场景和实现步骤，帮助用户根据业务需求灵活选择。 ## 高级场景与变通方法 对于需要额外建模步骤的复杂场景，文章也提供了变通方案，例如使用 SQL 自定义查询创建中间数据集，或利用计算字段处理非标准关联。 ## 当前限制总结 - 仅支持内连接，不支持外连接。 - 数据集关系基于键值匹配，无法直接使用复杂条件（如范围连接）。 - 链式连接（维度→维度）需谨慎，可能影响性能。 ## 小结 掌握这七种建模模式，你就能应对大部分业务分析需求。建议从简单的星型模式入手，再逐步尝试更复杂的结构。QuickSight 的多数据集关系功能为构建灵活、可扩展的分析报表提供了坚实基础。
## 概述：从预连接数据集到 AI 动态生成 SQL 在实际业务分析中，大多数问题都需要跨多个表查询。例如，零售商要分析**按产品类别的净收入**，就需要同时访问销售事实表、退货事实表和产品维度表。传统做法要求数据工程师预先将这些表连接成一个数据集，然后才能提供给 Amazon Quick Sight 进行分析。 Amazon Quick Sight 的**多数据集主题**（Multi-Dataset Topics）改变了这一模式。它允许分析团队通过两种方式将多个数据集整合到同一个主题中：一是定义显式的关系键（详见另一篇博文），二是为生成式 AI 引擎提供足够的语义上下文，让其自行编写 SQL。本文聚焦于第二种路径：**基于聊天的 AI 生成 SQL**。 ## 核心机制：语义引导栈 当您为聊天（Chat）配置主题时，无需预先定义关系。相反，您需要构建一个语义层，包括数据集级自定义指令、主题级指令、字段同义词和字段描述。AI 在查询时利用这些上下文生成感知上下文的 SQL。这使得**外连接、联合、子查询、自连接、跨粒度比较和条件连接逻辑**都变得可行，且不受关系图的结构约束。 本文为数据架构师、BI 工程师和分析工程师提供了一套实用的最佳实践框架，称为**语义引导栈**（Semantic Guidance Stack），用于结构化组织所有指导 AI 的元数据。 ## 八大最佳实践 1. **编写清晰的主题级指令**：在主题设置中提供全局上下文，例如“本主题用于零售销售分析，包含销售、退货和产品数据”。 2. **为每个数据集添加自定义指令**：明确数据集的用途、粒度（例如“每行代表一次交易”）和关键约束。 3. **定义字段同义词**：为业务常用术语提供多个别名，例如“收入”也可称为“销售额”、“营收”。 4. **提供详细的字段描述**：说明字段的计算逻辑、数据来源和业务含义，例如“净收入 = 销售额 - 退货额”。 5. **使用示例问题引导**：在主题中预设常见问题示例，帮助 AI 理解用户意图。 6. **处理多对多关系**：通过语义描述说明关系类型，例如“一个产品属于多个类别，一个类别包含多个产品”。 7. **处理角色扮演维度**：当同一维度表被多次使用时（如订单日期和发货日期），为每个角色赋予不同的别名和描述。 8. **处理跨粒度比较**：描述不同数据集之间的粒度差异，例如“销售表按订单行记录，退货表按退货单记录”。 ## 复杂模式处理 - **外连接**：在指令中说明需要包含所有记录，即使没有匹配项。 - **递归层级**：对于组织架构等层级数据，提供层级深度和路径描述。 - **条件连接逻辑**：描述连接条件，例如“根据订单状态选择不同的连接字段”。 ## 决策框架：选择何种方式 - **显式关系键**：适合关系稳定、性能要求高的场景。 - **纯语义引导**：适合关系复杂、频繁变化的场景，或需要快速原型验证。 - **混合方法**：结合两者，对核心关系使用显式键，对边缘查询使用语义引导。 ## 总结 多数据集主题与 AI 生成 SQL 的结合，大幅降低了数据准备的门槛，让分析师能够更专注于业务问题。通过精心设计的语义层，团队可以在几分钟内实现原本需要数天的跨表分析。本文提供的实践框架将帮助您最大化这一新能力的价值。
Amazon Quick 近日宣布其 BI 服务 Quick Sight 推出 **多数据集主题（Multi-dataset Topics）** 的公开预览版，允许用户在一个主题内关联最多 12 个数据集，并通过自然语言查询跨数据集获得统一答案。这一更新打破了此前“一个主题绑定一个数据集”的限制，使企业能够在不破坏数据规范化结构的前提下，构建更灵活的语义层。 ## 从“单表扁平化”到“多表智能关联” 传统上，Quick Sight 将数据集表示为单一扁平化表格。当数据源包含多个表时，用户需通过数据准备阶段将表连接为一张大宽表（denormalized table），这虽然避免了运行时连接、提升了查询性能，但也带来了数据冗余、维护成本高、灵活性差等问题。随着企业数据模型日趋复杂，这种“一刀切”的方式逐渐成为瓶颈。 多数据集主题改变了这一模式。用户现在可以在一个主题中添加多个数据集，并明确定义它们之间的关系（如一对多、多对多等）。当业务用户通过自然语言提问时，Quick 的 AI 引擎会自动解析意图，识别涉及的数据集，根据预定义关系构造合适的 SQL 连接，最终返回跨数据集的统一答案。整个过程对用户透明——他们无需了解底层 schema，即可获得更丰富的洞察。 ## 零售分析场景实战演示 文章以零售分析为例，展示了多数据集主题的端到端实现。假设企业拥有“订单”和“产品”两个独立数据集，传统做法需预先合并它们。现在，只需在主题中分别添加两个数据集，并定义“订单.产品ID”与“产品.产品ID”的关系。当用户提问“上月销量最高的产品类别是什么？”时，AI 引擎会自动跨表关联，返回准确结果。 更关键的是，**同一个多数据集主题既可以用于构建可视化分析，也可以用于问答对话**，实现了语义层的一体化复用。这大大降低了 IT 部门维护多个主题的负担，同时让业务用户获得更一致的数据体验。 ## 行业意义与展望 多数据集主题的推出，反映了 BI 工具向 **语义层智能化** 演进的趋势。随着数据湖、数据网格等架构普及，企业数据往往分散在多个系统中。传统 BI 工具要求用户提前完成数据整合，而 AI 驱动的语义层则能够在查询时动态关联，既保持了数据源的原始粒度，又提供了统一的业务视角。 对于 Quick Sight 用户而言，这一功能尤其适用于以下场景： - **零售分析**：订单、库存、客户数据分属不同表，却需要统一分析。 - **财务报告**：预算、实际支出、预测数据来自不同系统。 - **运营监控**：设备日志、告警、工单数据跨库关联。 目前该功能处于公开预览阶段，用户可在 Quick Sight 控制台中启用。Amazon 表示，后续将根据反馈优化性能，并可能增加更多数据集数量上限。
扫地机器人市场在2026年迎来新一轮升级，各家品牌在导航、避障、吸力及自清洁能力上持续突破。ZDNET 专家团队通过实验室标准化测试与真实家庭环境实测，对 Ecovacs、Roborock、Mova 等主流品牌的多款旗舰产品进行了横向对比。本文基于实测数据与使用体验，为不同需求的用户提供选购参考。 ## 评测方法：实验室 + 家庭双场景 我们不仅在产品测试实验室中对机器人进行吸力、覆盖率、噪音等标准化测试，还让每台机器人在不同户型（硬木地板、地毯、宠物家庭）中连续运行一周，记录其日常清洁表现、避障能力、地图构建准确性以及自维护便利性。 ## 核心发现 - **旗舰级全能选手**：Roborock S8 MaxV Ultra 在吸力（5500Pa）和自清洁基站功能上表现均衡，支持自动集尘、拖布自清洁、自动补水与基站自清洁，适合对清洁效果与便利性都有高要求的用户。 - **专业拖地性能**：Ecovacs Deebot X2 Omni 采用方形机身设计，边角清洁效果优于同类产品，其热风烘干拖布与自动添加清洁液功能为深度拖地需求用户提供了贴心方案。 - **性价比之选**：Mova L600 在 4000Pa 吸力基础上保留了完整自清洁基站，价格仅为旗舰机型的一半，适合预算有限但希望获得全自动体验的用户。 - **宠物家庭推荐**：Roborock Q Revo MaxV 配备宠物毛发防缠绕滚刷与增强型传感器，可有效识别宠物粪便并规避，减少人工干预。 ## 选购建议 | 需求场景 | 推荐型号 | 核心优势 | |---------|---------|---------| | 全能旗舰 | Roborock S8 MaxV Ultra | 综合性能最强，基站功能最全 | | 深度拖地 | Ecovacs Deebot X2 Omni | 方形机身无死角，热风烘干 | | 高性价比 | Mova L600 | 旗舰级基站，价格亲民 | | 宠物家庭 | Roborock Q Revo MaxV | 防缠绕+避障，省心省力 | ## 总结 2026年的扫地机器人已从“能扫”进化到“懂扫”，导航算法与自清洁技术成为差异化关键。建议消费者根据家庭地面类型、宠物情况、预算以及对自动化程度的期待进行选择。如需查看完整评测数据与价格走势，可访问 ZDNET 原文。
本文介绍如何使用 Amazon Bedrock AgentCore 构建一个无服务器图像编辑器，用户上传照片并用自然语言描述编辑需求，即可在数秒内得到结果。智能体运行在 AgentCore 编排层上，无需自定义编排代码。整个方案包括身份认证、加密存储、三个图像编辑工具和 React 前端，通过一条部署命令即可完成部署，基础设施由 AWS CDK 定义。 ## 核心能力：配置驱动，无需编排代码 传统 AI 智能体的构建需要开发者自行处理**任务编排循环、工具路由、记忆管理**以及运行环境。AgentCore 将这一切封装为配置参数：开发者只需声明智能体的行为，编排层便会在一个有状态、隔离的微虚拟机中运行它，内置记忆、工具路由和可观测性。 该图像编辑器接受类似“把车颜色改成蓝色”或“向右扩展 200 像素”的提示词。由 **Claude Sonnet 4.6** 驱动的智能体将需求拆解为多个步骤，并编排调用不同的 **Stability AI 模型**（每个模型对应一个工具）。编辑完成后，通过微虚拟机上的 shell 命令添加水印（无 token 开销），最后返回结果。 ## 五大亮点功能 1. **配置驱动的智能体创建**：完全通过 API 参数定义智能体，无需 Python 编排代码、无需框架、无需容器。 2. **每次调用可切换模型**：前端将基础对话路由到 Claude Haiku 4.5，图像编辑任务路由到 Claude Sonnet 4.6，智能体会在模型切换时保持对话上下文。 3. **每次调用可覆盖角色提示**：用户可选择行业角色（房地产、零售、汽车），这些角色会注入领域特定的系统提示，而无需重新部署。 4. **30 天会话记忆**：AgentCore 服务会存储对话历史 30 天，智能体在同一会话内可跨轮次保持上下文，无需前端重复发送历史。示例将会话 ID 存储在 localStorage 中，因此刷新浏览器后对话仍能继续。清除浏览器数据会在前端启动新会话，但历史记录仍可通过 ListEvents API 获取。 5. **MCP 网关支持**：三个由 Lambda 支持的工具通过 **Model Context Protocol (MCP)** 暴露给智能体。 ## 架构与部署 整个应用包括： - **身份认证**：确保用户安全访问。 - **加密存储**：保护用户上传的图片。 - **三个图像编辑工具**：分别对应不同的 Stability AI 模型，实现多种编辑能力。 - **React 前端**：提供直观的用户界面。 所有基础设施通过 **AWS CDK** 定义，一条命令即可完成部署。 ## 应用场景与价值 该示例展示了 AgentCore 在**图像编辑**领域的落地潜力。对于需要快速构建 AI 编辑工具的开发团队，AgentCore 大幅降低了编排层的工作量，让开发者可以专注于工具逻辑和前端体验。此外，**行业角色切换**功能使得同一套系统可以服务于不同垂直领域，如房地产（调整房屋照片）、零售（更换商品颜色）、汽车（修改车型外观）等。 ## 总结 Amazon Bedrock AgentCore 为构建无服务器 AI 智能体提供了一条**配置驱动、零编排代码**的路径。通过将图像编辑的复杂流程封装为可配置的智能体，开发者能够快速交付面向用户的生产级应用，同时保持灵活性和可扩展性。
机器学习模型的准确性在训练完成后几乎立即开始下降。消费者行为变化、新产品发布、传感器技术升级以及经济政治环境的变迁，都会改变模型在训练时学到的数据模式与概率分布。主动监控生产环境中的模型，及时发现准确率与基线统计的偏差，才能在问题恶化前进行干预。本文聚焦于**判别式机器学习模型**（分类与回归场景），并展示如何结合开源工具 **Evidently**、**Amazon SageMaker AI** 与 **MLflow**，构建一个可扩展的监控方案，涵盖报告生成、结果对比、管道编排以及漂移告警触发。 ## 为何需要监控？ 导致判别式模型质量下降的因素主要分为两类： - **数据漂移**：输入数据的统计属性发生变化。可能是上游数据源意外变更（如整型列变为浮点型），也可能是全新产品线上市这类复杂情况。通过计算训练数据集的基线统计量，并与生产环境实时数据统计量对比，可以量化数据漂移。 - **模型漂移**：模型学到的概率模式不再匹配新数据，导致预测准确率下降。例如，经济好转引起消费者行为改变，使得历史模式失效。通过收集真实标签（ground truth）并对比训练时的模型质量指标，可以检测模型漂移。 ## 解决方案架构 文中提出的监控方案整合了以下组件： - **Evidently**：开源库，提供丰富的统计检验和可视化报告，用于检测数据漂移和模型性能变化。 - **Amazon SageMaker AI**：全托管机器学习平台，负责模型部署、推理端点管理以及管道编排。 - **MLflow**：开源实验跟踪和模型管理平台，用于组织和比较不同时间点的监控报告，记录漂移指标。 具体工作流程如下： 1. **定义基线**：使用训练数据集计算特征统计量（如均值、方差、分布分位数）以及模型质量指标（如准确率、F1分数）。 2. **定期评估**：通过 SageMaker 管道定期从生产端点收集推理数据，并调用 Evidently 计算与基线的偏差。 3. **记录与对比**：将每次评估的结果（包括漂移分数、统计检验 p 值、质量指标变化）记录到 MLflow 中，形成时间序列，便于回溯与比较。 4. **告警触发**：当漂移指标超过预设阈值时，通过 SageMaker 的告警机制（如 Amazon CloudWatch）发送通知，触发模型重训练或回滚。 ## 优势与适用场景 相比 SageMaker 内置的监控功能，该方案提供了更高的**定制灵活性**： - **成本可控**：用户可根据需求选择评估频率和计算资源，避免全托管方案可能带来的不必要开销。 - **开放生态**：Evidently 支持多种统计检验（如 KS 检验、卡方检验），MLflow 的开放接口便于与现有 MLOps 工具链集成。 - **可扩展性**：通过 SageMaker Pipelines 编排，可以轻松扩展到数百个模型端点的监控。 对于**生成式 AI 模型**（如 LLM），SageMaker 也提供了专用实时监控方案，详见官方文档。 ## 小结 模型监控是 MLOps 中不可或缺的一环，尤其在生产环境复杂多变的情况下。通过将 Evidently、SageMaker AI 和 MLflow 相结合，团队能够以较低成本实现从数据漂移到模型漂移的全面监控，并在问题影响业务前及时干预。如果你正在寻找一种既保留开源灵活性又能利用云平台托管能力的方式，这套方案值得尝试。
## 从多工具切换到单一对话：AWS 支持助手的 AI 进化 管理 AWS 基础设施时，工程师常常需要在多个控制台、文档和社区之间来回切换。针对每一次事件，工程师需要打开 AWS 管理控制台、检查 CloudWatch 日志、搜索文档、查看 re:Post 社区帖子，再手动创建支持案例。这种上下文切换每次调查平均耗时 **30–45 分钟**，之后才能开始真正的修复工作。 ### 为什么需要 AI 支持助手？ 传统调查流程存在明显的瓶颈：每个步骤依赖不同的工具和界面，信息无法自动流转。AWS 支持与运维团队每天重复着“打开控制台 → 检查日志 → 搜索文档 → 浏览社区 → 创建案例”的循环，效率低下且容易遗漏关键信息。 ### 解决方案：基于 Bedrock AgentCore 的对话式代理 现在，我们可以通过 **Amazon Bedrock AgentCore** 构建一个 **AWS Support Companion**，将上述所有步骤整合到一个对话式界面中。AgentCore 负责处理生产级 AI 代理的运营复杂性——包括会话隔离、自动扩缩、安全性和可观测性——让开发者专注于“代理做什么”，而非“代理怎么跑”。 该代理的核心架构包括： - **代理运行时**：基于 **Strands Agents** 框架的 Python 应用，打包为 Docker 容器并部署到 AgentCore 运行时。代理通过 **Amazon Bedrock** 调用基础模型（如 **Amazon Nova Pro**），并根据用户输入编排工具调用。你可以切换到其他支持的模型，无需修改代理代码。 - **MCP 服务器**：通过 **模型上下文协议（MCP）**，代理连接三个 MCP 服务器，分别访问 **AWS 文档**、**CloudWatch 日志** 和 **AWS re:Post 社区知识**。 - **部署与前端**：整个解决方案通过单个 **AWS CloudFormation** 脚本部署，并包含一个基于 **AWS Amplify** 的 Web 前端，方便用户与代理交互。 ### 代理能做什么？ 在对话界面中，你可以直接要求代理： - 分析 CloudWatch 日志中的错误模式 - 搜索 AWS 文档获取相关故障排除指南 - 查询 AWS re:Post 上类似问题的社区讨论 - 自动创建支持案例，并附上调查证据和上下文 所有这些操作都在同一个会话中进行，上下文信息无缝传递，无需手动复制粘贴。 ### 行业背景与价值 AI 驱动的支持助手是 **AI 运维（AIOps）** 领域的典型应用。通过将大语言模型与结构化工具（MCP 服务器）结合，代理不仅能理解自然语言，还能执行实际操作——这比单纯的聊天机器人更进一步。AWS 通过 Bedrock AgentCore 提供了托管运行时，降低了构建此类代理的运维门槛。 对于团队而言，最大的价值在于 **减少上下文切换时间**。原本需要 30–45 分钟的调查流程，现在可能缩短到几分钟内完成。更重要的是，代理可以保持调查过程的完整记录，便于事后审计和知识沉淀。 ### 小结 AWS Support Companion 展示了如何利用 **Bedrock AgentCore**、**Strands Agents** 和 **MCP 协议** 构建一个实用的 AI 助手。它不是一个概念验证，而是一个可部署的解决方案，能够直接融入现有运维流程。如果你正在寻找提升 AWS 支持效率的方法，这个架构值得参考。
对于 Linux 新手来说，选择一个合适的发行版往往是最关键的第一步。长期以来，**Linux Mint** 凭借其易用性、稳定性和友好的社区，一直被视为新手首选。然而，新晋发行版 **RefreshOS** 的出现，正在挑战这一地位。我最近对这两款发行版进行了深度对比，结论是：**两者都是优秀的选择，但最终胜负取决于桌面体验的差异。** ## 为何 Linux Mint 是经典之选？ Linux Mint 的成功并非偶然。它基于 Ubuntu，拥有庞大的软件仓库和成熟的生态。其默认的 **Cinnamon 桌面环境** 遵循传统的桌面隐喻——底部面板、开始菜单、系统托盘和可点击的图标——让从 Windows 迁移过来的用户几乎零学习成本。Mint 的社区以友好著称，遇到问题时很容易找到帮助。此外，它的稳定性极高，经过多年打磨，几乎不会出现意外崩溃。 > 我的同事 Steven Vaughan-Nichols 曾评价最新版 Mint 是“抛光与生活质量修复的大师级课程”，这足以说明它的成熟度。 ## RefreshOS 的差异化路线 RefreshOS 则走了一条不同的路。它同样注重易用性，但更强调现代化设计和开箱即用的体验。它的桌面环境经过精心定制，界面更接近 macOS 或 ChromeOS，对完全的新手可能更直观。RefreshOS 在预装应用的选择上也更为精简，避免了新手被过多选项困扰。 ## 核心对决：桌面环境分胜负 经过数周的使用，我发现两款发行版在底层性能上差异不大——都基于 Ubuntu，都稳定可靠。真正的区别在于桌面交互。 - **Linux Mint (Cinnamon)**：如果你希望迁移后立即感到熟悉，Cinnamon 是最佳选择。它的自定义程度高，但默认配置已经足够好用。 - **RefreshOS**：如果你希望有一个更现代、更简洁的界面，并且不介意学习一些新概念，RefreshOS 的定制桌面会更吸引人。 ## 最终结论：谁更适合新手？ **对于大多数新手，我仍然推荐 Linux Mint。** 它的社区支持更强大，文档更丰富，出现问题时更容易找到解决方案。Cinnamon 桌面的成熟度和稳定性也无可挑剔。 **但如果你追求更现代的美学，并且不介意较小的社区，RefreshOS 是一个值得尝试的替代选择。** 它的开箱体验非常流畅，尤其适合那些被 Windows 或 macOS 界面审美疲劳的用户。 总之，两款发行版都证明了 Linux 可以既强大又亲民。选择哪一款，最终取决于你对桌面风格的偏好。
Anthropic 的通用知识工作智能体 Claude Cowork 正式登陆移动端和网页端。该产品最初于 1 月作为桌面应用推出，从周二起，Max 订阅用户可在手机和浏览器上使用它。用户可以在办公桌前启动任务，在手机上查看状态更新，稍后再取回完成的结果——即使笔记本电脑合上盖子也没关系。 这一产品扩展表明 Anthropic 希望 Cowork 不再只是“傻瓜式编码工具”，而是更像一个真正的行政同事：能在后台工作、跨设备随行，并在需要人类决策时及时请求输入。换句话说，编码智能体之战正蔓延到办公室的各个角落。 此举正值 AI 公司试图将其产品从聊天机器人推向实际工作发生的日常场景。OpenAI 也做出了类似动作，其 Codex 最初是软件开发工具，但越来越多地被非开发者用于报告、电子表格、演示、研究、数据分析等。对于两家实验室而言，成功将不再取决于谁拥有最好的聊天机器人，而是谁占据了完成工作的空间。 这种扩展也延伸至其他应用。Anthropic 最近推出了 Claude Tag，一个常驻 Slack 的始终在线 AI 队友。除了特定界面的优势外，多平台 Cowork 意味着智能体可以在设备离线时继续在后台运行任务。Anthropic 举了一个例子：“将周一的客户准备设在早上 6 点：Claude 处理邮件线程、会议记录和最新新闻，构建简报文档，并留下已起草但未发送的跟进邮件。你可以在喝咖啡时审阅。” 桌面应用仍将是深度工作的场所，Claude 可以访问本地文件和浏览器。但将 Cowork 带到网页和移动端意味着未安装应用的人也能使用。Anthropic 表示，聊天和 Cowork 将在网页和桌面端统一，项目与工件将跨平台共存。 Anthropic 还发布了早期 Cowork 数据，表明该工具最清晰的用例是维持公司运转的“工作之外的工作”——处理那些涵盖广泛职位但很少是个人核心职责的任务。该研究抽样了 120 万个匿名任务，揭示了 AI 智能体如何承担起琐碎但必要的行政负担。
面对日益收紧的美国出口管制，中国AI初创公司DeepSeek正计划自研芯片，以减少对Nvidia和华为的依赖。尽管该计划尚处于早期阶段，但已引发行业关注。 ## 背景：出口管制下的中国AI产业 自2022年以来，美国多次升级对华半导体出口管制，限制Nvidia A100/H100等高端AI芯片的对华销售，并进一步将H800、L40S等降级版芯片纳入管控范围。这迫使中国AI企业寻求替代方案，华为昇腾（Ascend）系列芯片成为主要国产选择之一。然而，华为芯片在性能和生态上仍与Nvidia存在差距，且自身也面临美国制裁。 ## DeepSeek的应对策略 DeepSeek作为一家专注大模型研发的AI公司，此前已推出DeepSeek-V2和DeepSeek-R1等模型，其训练和推理高度依赖高性能芯片。面对供应不确定性，自研芯片成为其长期战略选择。据悉，DeepSeek已开始组建芯片设计团队，并计划从专用AI加速器入手，逐步降低对外部供应商的依赖。 ## 挑战与前景 自研芯片并非易事。芯片设计需要巨额资金投入、顶尖人才和长期积累，而中国在EDA工具、先进制程制造等方面仍受制于人。即便设计成功，流片和量产也面临台积电等代工厂的合规风险。不过，DeepSeek的尝试可能推动中国AI芯片生态的多元化发展。 ## 行业影响 若DeepSeek自研芯片取得进展，不仅将增强其自身供应链安全，还可能为其他中国AI公司提供参考路径。同时，这也将加剧与华为昇腾的竞争，并促使Nvidia调整其对中国市场的策略。然而，短期内，中国AI企业仍需依赖现有可获取的芯片资源。
## 不只是聊天：Rowboat 想重新定义 AI 工作台 Claude 桌面版以出色的对话体验赢得了众多用户，但对于日常深度工作而言，它始终更像一个聊天工具，而非真正的工作平台。**Rowboat** 正是为此而生——一个**开源、本地优先**的 AI 客户端，旨在让 AI 成为融入工作流的“工作应用”，而非简单的问答窗口。 ### 核心差异：从对话到工作流 传统 AI 聊天应用（包括 Claude Desktop）通常遵循“输入问题→获取回答”的单轮对话模式，而 Rowboat 的设计思路更接近**可定制的工作台**。用户可以在 Rowboat 中构建自己的“工作表面”（work surfaces），例如： - **代码审查面板**：直接粘贴代码片段，获得逐行评审意见 - **文档写作台**：结合上下文长文档，边写边获得实时建议 - **数据分析看板**：上传 CSV 后，通过自然语言生成图表摘要 这些工作表面并非预设模板，而是**用户自定义的交互界面**，可保存为独立会话，并随时复用。这种模式让 AI 从“一次性问答”转变为“持续协作伙伴”。 ### 本地优先与开源承诺 Rowboat 强调**本地优先**（local-first），这意味着大多数计算和数据处理在用户设备上完成，减少对云端的依赖，从而提升隐私保护和离线可用性。项目完全开源（GitHub 仓库已公开），允许开发者自行审计代码、贡献插件或修改界面。 对于关注数据安全的企业用户而言，本地优先架构意味着敏感信息无需上传至第三方服务器；而对于开发者社区，开源许可则提供了二次创新的自由。 ### 与 Claude Desktop 的对比 | 特性 | Claude Desktop | Rowboat | |------|----------------|---------| | 对话模式 | 单轮/多轮聊天 | 可定制工作表面 | | 数据存储 | 云端为主 | 本地优先 | | 开源性 | 闭源 | 开源（MIT 协议） | | 自定义能力 | 有限提示词设置 | 自由构建工作流 | | 离线支持 | 部分功能离线 | 核心功能离线可用 | ### 适用场景与潜在局限 Rowboat 更适合**需要深度、重复性 AI 协作的用户**，如开发者、数据分析师、内容创作者。其自定义工作表面能显著提升特定任务的效率，但学习曲线也高于普通聊天应用。 目前项目处于早期阶段，功能完整性可能不及 Claude Desktop 成熟。例如，多模态支持、高级模型切换等特性仍在开发中。社区贡献将是推动其快速迭代的关键。 ### 结语 Rowboat 的出现反映了 AI 工具演进的一个新方向：**从通用聊天界面走向专业化工作台**。它并非要完全取代 Claude Desktop，而是提供另一种选择——对于希望深度掌控 AI 交互流程的用户来说，Rowboat 的开源、本地优先理念无疑具有吸引力。 项目已在 GitHub 上开源，感兴趣的用户可以自行部署体验，或参与功能讨论。
ZDNET 联合 CNET 集团旗下多家科技媒体，再次开启“猜猜看”有奖竞猜活动。本次第二轮竞猜聚焦苹果即将发布的新品，特别是 iPhone 18 Pro Max 等旗舰设备的潜在升级。参与者只需在每轮五个问题中答对一题，即可获得一次抽奖资格，最终大奖是今年的新款 Apple Watch。 活动面向美国 50 州及哥伦比亚特区年满 18 岁的合法居民，无需购买即可参与。第二轮从 2026 年 7 月 7 日持续至 7 月 21 日。苹果素来对产品发布守口如瓶，但今年传闻中的可折叠 iPhone 和触摸屏 MacBook 等产品有望成真。无论你是资深果粉还是科技爱好者，这都是一个检验自己预测能力的好机会。 注意：苹果公司并非本次活动的赞助商、关联方或背书人。Apple Watch 是苹果公司的注册商标。
Anthropic 宣布将其 AI 助手 Claude Cowork 扩展至网页和移动端，同时发布的数据显示，该工具的使用场景已远超编程和软件开发。 ## 从桌面到云端：Cowork 的进化 Anthropic 近日宣布，其面向 Claude 用户的代理型助手 **Claude Cowork** 将正式登陆网页和移动设备。此前，Cowork 主要运行于桌面端，用户需要保持电脑开机才能完成任务。如今，用户可以在办公室启动任务，在手机上查看进度，并在任何浏览器中获取最终结果——即使笔记本电脑已关闭，任务仍会在云端继续执行。 Anthropic 将这种模式描述为“围绕工作的工作”（the work around the work），意指那些虽非核心职责却消耗大量时间的行政琐事，例如整理邮件、合并电子表格、组织文件等。Cowork 的目标正是将这些“非核心工作”自动化，释放专业人员的精力。 ## 数据揭示：编程并非主要用途 在宣布移动端升级的同时，Anthropic 还分享了基于 **120 万次 Cowork 会话** 的分析结果。令人意外的是，**90% 的会话并非用于编程**。这一数据挑战了人们对 AI 助手主要用于代码生成的固有印象。 实际用例涵盖广泛：从漏洞检测、数据分析到文档管理和信息检索。例如，作者曾使用 Cowork 对网站进行漏洞扫描，整个过程无需依赖本地计算资源。这表明 Cowork 正在向更通用的办公助手方向演进。 ## 安全性与替代性：能否取代 OpenClaw？ 随着 Cowork 向云端迁移，用户自然关心其安全性与可靠性。Anthropic 强调，云端运行并不意味着数据泄露风险增加——任务在云端执行，用户可通过任何设备访问结果，但敏感数据仍受保护。目前，桌面版仍提供最完整的 Cowork 体验，但网页和移动版的加入显著提升了灵活性。 至于能否“安全地替代 OpenClaw”，答案尚不明确。OpenClaw 作为另一款知名 AI 工具，在特定场景下仍有优势。Cowork 的强项在于其“代理”能力——它可以独立完成多步骤任务，而无需用户实时干预。这种“放手运行”的模式尤其适合需要长时间后台处理的任务。 ## 行业影响与展望 Cowork 的云端化标志着 AI 助手从“辅助工具”向“自主代理”的转变。当任务不再依赖本地设备，AI 的可用性和连续性大幅提升。对于企业用户而言，这意味着更高效的资源利用和更灵活的工作流。 Anthropic 的数据还揭示了 AI 应用场景的多元化：编程仅占 10%，其余 90% 来自金融、医疗、法律等领域的非技术用户。这一趋势可能促使更多行业探索 AI 代理在行政、合规、研究等环节的落地。 未来，随着 Cowork 在移动端和云端的迭代，它或许会重新定义“工作”的边界——让人类专注于创造与决策，而将繁琐的“围绕工作的工作”交给 AI。
Anthropic 今日宣布，其 AI 智能代理 Claude Cowork 迎来重大更新：用户不再需要保持笔记本电脑开启即可让代理持续运行任务。这意味着，即使合上电脑，Cowork 也能在后台执行诸如整理邮件、生成文档等操作，甚至支持夜间定时任务。此前，Cowork 仅能在桌面端活跃会话期间工作，用户常需保持设备唤醒。新版本允许用户通过 Claude 手机应用或网页浏览器与代理交互，无需依赖桌面连接。 ## 从桌面到云端：Cowork 的进化 Cowork 最初于今年 1 月发布，定位为“替你完成数字任务的 AI 代理”。笔者曾亲身体验，其能高效整理截图文件、管理日历事件，虽存在提示注入等安全风险，但已显著改变人机交互模式。此次更新最核心的变化在于：**任务执行不再依赖桌面会话**。Anthropic 在演示视频中展示了典型场景——用户要求 Cowork 为次日商业谈判准备资料，代理自动从邮件、Slack、会议记录及网络信息中整合数据，生成参考文档和草拟邮件，整个过程在用户下班后后台完成。 ## 手机控制的“半自主”代理 这并非 Claude 首次登陆移动端。此前通过“Dispatch”功能，用户已可从手机发送任务请求，但前提是电脑必须唤醒且应用处于打开状态。新版本彻底解除了这一限制，使得 Cowork 成为真正意义上的“随时在线”代理。这一动向与硅谷近期趋势高度吻合：科技巨头正竞相开发可通过短信控制的、持续运行的半自主 AI 代理。Anthropic 此举不仅提升了产品实用性，更在竞争激烈的 AI 代理赛道中抢占先机。 ## 安全与场景展望 尽管能力增强，Cowork 仍面临安全挑战——提示注入等攻击向量依然存在。不过，对于需要处理跨平台信息、执行多步骤任务的用户（如商务人士、内容创作者），Cowork 的“后台运行”能力将大幅提升效率。未来，随着更多设备集成和任务自动化程度加深，AI 代理或将从“辅助工具”进化为“数字员工”。
安全研究人员发现了一种名为 **JadePuffer** 的新型勒索软件攻击，这可能是首个完全由 AI 自主驱动的勒索攻击案例。该攻击由大型语言模型（LLM）全程操控，从漏洞利用到数据窃取、加密勒索，无需人工干预。 ## 攻击链：AI 代理的“自主狩猎” JadePuffer 的攻击起点是 **Langflow**（一个开源的 AI 应用构建平台）中的未认证远程代码执行漏洞（CVE-2025-3248）。攻击者利用 LLM 代理自动扫描并利用该漏洞，获得初始访问权限后，AI 代理会自主进行内网侦察、凭据窃取，包括 LLM API 密钥、云服务凭证、加密货币钱包信息等。 在建立持久化后，AI 代理将攻击转向真正的目标——运行 **阿里云 Nacos** 配置服务的生产服务器。它部署勒索软件加密文件，并留下比特币赎金通知。整个过程由 LLM 实时决策，根据遇到的防御措施动态调整战术。 ## 关键特征：自述代码与自适应能力 Sysdig 公司指出，JadePuffer 最令人担忧的特性是 **自述代码**——AI 代理为每个攻击步骤添加了注释，解释每一步的目的和决策逻辑。这相当于攻击者获得了透明的“攻击日志”，便于优化和改进。此外，AI 能够根据环境反馈自适应调整，例如在遇到防火墙时尝试绕过，在检测到沙箱时延迟执行。 ## 行业影响与防御对策 JadePuffer 的出现标志着网络攻击进入 **Agentic AI** 时代。传统防御手段基于已知签名和固定模式，但 AI 驱动的攻击可以实时变异，使检测更加困难。安全专家建议企业采取以下措施： - **强化 AI 供应链安全**：对 Langflow 等 AI 开发工具进行严格漏洞管理 - **实施零信任架构**：限制 AI 代理的横向移动能力 - **部署行为分析系统**：关注异常 API 调用和自述代码行为 - **加密关键数据**：即使攻击者窃取凭据，也无法解密 ## 小结 JadePuffer 并非科幻小说，而是真实发生的攻击。它证明 AI 不仅能辅助攻击，还能完全自主执行复杂的多阶段勒索流程。安全行业需要重新思考防御策略，从“对抗已知威胁”转向“对抗自适应智能”。