引言 随着人工智能技术的飞速发展，生成式AI（Generative AI）已成为当前最受关注的领域之一。Google AI Edge Gallery 正是谷歌在该领域的一次创新尝试，它以一款实验性应用的形式，旨在将尖端的生成式AI模型直接带到用户的移动设备上。这款应用目前已在 Android 平台推出，并计划很快支持 iOS，让用户无需互联网连接，即可在本地设备上体验、探索并评估AI模型的能力。 Google AI Edge Gallery 的核心理念是让AI触手可及。它打破了传统云计算AI服务的局限，允许用户在自己的设备上运行复杂的生成式AI模型。这意味着更快的响应速度、更强的数据隐私保护，以及即使在离线状态下也能持续享受AI服务的便利。通过这款应用，用户可以深入了解各种创新和实用的AI用例，从而更好地理解设备端机器学习（On-device Machine Learning）的巨大潜力。 核心功能一览 Google AI Edge Gallery 提供了一系列引人入胜的功能，旨在为用户提供全面且直观的生成式AI体验： 本地运行，完全离线 这是该应用最显著的特点之一。一旦模型加载完成，所有的AI处理都将在设备本地进行，无需依赖互联网连接。这不仅提供了极高的便利性，确保了数据安全和隐私，也让用户能够随时随地探索AI的无限可能。 模型选择与比较 用户可以轻松切换并比较来自 Hugging Face 等平台的不同AI模型。这一功能允许用户亲身感受不同模型在性能、输出质量和处理速度上的差异，为开发者和研究人员提供了一个评估和测试模型效果的理想环境。 图像问答 通过“询问图像”功能，用户可以上传图片并就图片内容提出问题。AI模型能够识别图片中的对象、描述场景、解决与图片相关的特定问题，甚至进行图像内容的深度分析。无论是想了解一张旅行照片的背景故事，还是需要识别某个物品，这项功能都能提供智能的解答。 音频转录与翻译 “音频记录”功能支持用户上传或录制音频片段，并将其转录为文本。更进一步，它还能将音频内容翻译成其他语言，极大地便利了跨语言交流和信息整理。无论是会议记录、语音备忘录还是学习外语，这项功能都展现出强大的实用性。 提示词实验室 在“提示词实验室”中，用户可以自由探索各种大型语言模型（LLM）的单轮用例。这包括但不限于文本摘要、内容重写、代码生成，以及各种自由形式的提示词实验。它为用户提供了一个创意空间，激发他们发现AI在文本处理方面的多样化应用。 AI 对话 “AI 聊天”功能支持多轮对话，让用户能够与AI进行更自然、更深入的交流。通过持续的互动，AI能够更好地理解用户意图，提供更连贯、更相关的回答，模拟真实的人际对话体验。 性能洞察 对于对技术细节感兴趣的用户，“性能洞察”提供了模型的实时基准测试数据，包括首次生成时间（TTFT）、解码速度（decode speed）和延迟（latency）。这些数据有助于用户了解模型在设备上的运行效率，为进一步优化和开发提供参考。 自带模型支持 开发者和高级用户可以利用“自带模型”功能，测试自己的 LiteRT .litermlm 模型。这一开放性使得应用不仅仅是消费者的工具，更是开发者验证和迭代设备端AI模型的平台。 开发者资源 应用内提供了模型卡片和源代码的快速链接，方便开发者获取详细信息和进行深入研究。这体现了谷歌鼓励社区参与和开放创新的精神。 技术亮点解析 Google AI Edge Gallery 背后凝聚了多项前沿技术，共同实现了其强大的设备端AI能力： Google AI Edge 作为核心平台，Google AI Edge 提供了一整套用于设备端机器学习的API和工具。它为Gallery应用提供了基础架构支持，确保AI模型能够在各种移动设备上高效稳定运行。 LiteRT LiteRT 是一种轻量级运行时环境，专为优化模型执行而设计。它能够最大程度地减少资源消耗，提升AI模型在移动设备上的运行效率和速度，是实现设备端AI的关键技术之一。 LLM Inference API 大型语言模型推理API是驱动设备端大型语言模型功能的核心。它使得复杂的LLM能够在资源受限的移动设备上进行高效推理，从而实现丰富的文本生成和理解能力。 ...

苏黎世联邦理工学院洛桑分校（EPFL）的机器学习课程（CS-433）一直以其深入的教学内容和实践性强的学习体验而闻名。2025年秋季学期的课程将继续为学生和机器学习爱好者提供前沿知识与丰富资源。本篇文章旨在详细介绍该课程及其在GitHub上提供的宝贵学习材料，帮助学习者更好地理解和利用这些资源。 课程概览 EPFL的机器学习课程（CS-433）是一门面向深入理解和实践机器学习核心概念的课程。它涵盖了从基础理论到高级算法的广泛主题，旨在培养学生解决复杂机器学习问题的能力。课程的官方网站提供了详细的教学大纲、课程信息以及其他重要通知。通过这些官方渠道，学生可以获取最新的课程安排、评估标准和重要日期等信息。 GitHub课程仓库内容解析 该课程的核心学习资源托管在GitHub上的epfml/ML_course仓库中，这使得所有材料都公开透明且易于访问。这个仓库是学生获取所有学习资料的一站式平台，具体包含以下几个关键部分： 讲义（lectures） 所有课程的讲义都以系统化的方式组织在这个文件夹中。这些讲义是理解课堂内容的基石，通常包含理论解释、关键概念和图示，为学生提供了学习和复习的全面文本资料。 实验（labs） “实验”部分包含了实践练习和代码模板，旨在帮助学生将理论知识应用于实际问题。这些实验通常涉及编程任务，让学生能够亲手实现机器学习算法，并通过实际操作加深理解。同时，仓库中也提供了实验的解决方案，方便学生核对和学习。 考试（exam） 该部分可能包含模拟考试、往年试题或与考试相关的其他资源。这对于学生准备期中和期末考试至关重要，帮助他们熟悉考试形式和题型，从而更好地评估自己的学习进度和知识掌握程度。 除了上述主要内容，仓库还包含.gitignore等配置类文件和README.md文件，后者提供了对仓库内容的简要介绍和快速导航。 丰富的多媒体学习资源 除了GitHub仓库中的文本和代码资源，EPFL还为该课程提供了丰富的多媒体内容。所有课程的讲座视频都将在课后发布到EPFL的Mediaspace频道。值得一提的是，该频道不仅包含最新一年的视频，还收录了2024年和2023年的课程视频，这为学生提供了宝贵的历史学习资料，有助于回顾和深入理解不同年份的教学内容和方法。 互动与支持渠道 EPFL鼓励学生积极参与课程互动并寻求帮助。学生可以通过以下渠道与课程团队取得联系： 讨论论坛：对于EPFL的在校学生，课程专门设立了讨论论坛。这是一个提问、讨论和互相学习的平台，学生可以在这里交流学习心得、解决遇到的问题。 邮件联系：学生也可以直接通过电子邮件联系助教或授课教师，进行个性化的问题咨询或寻求指导。 GitHub问题与拉取请求：该GitHub仓库也作为一个开放的平台，学生和贡献者可以通过提交Issue（问题）来报告错误、提出建议或寻求帮助，也可以通过Pull Request（拉取请求）来贡献自己的代码改进或文档修正。 技术栈与社区贡献 该GitHub仓库主要使用Jupyter Notebook（91.9%）、Python（4.2%）和TeX（3.9%）等技术。Jupyter Notebook广泛应用于数据科学和机器学习领域，提供了交互式的编程环境，非常适合教学和实验。Python是机器学习领域最流行的编程语言之一，而TeX则常用于生成高质量的学术文档和讲义。 这个仓库不仅是课程资料的存储地，也是一个活跃的社区。它已经获得了超过1.7千次的Star和972次的Fork，并拥有27位贡献者，这体现了其在机器学习学习者中的广泛认可度和影响力。社区的活跃度也为课程的持续改进和发展提供了动力。 结语 EPFL 2025年秋季机器学习课程通过其官方网站、GitHub仓库和多媒体平台，为学习者构建了一个全面且互动性强的学习生态系统。无论您是EPFL的在校学生，还是对机器学习充满热情的自学者，这些丰富的资源都将为您提供宝贵的学习支持和实践机会。建议所有感兴趣的学习者充分利用这些资源，深入探索机器学习的奥秘。 查看更多详情

Supabase是一个革命性的Postgres开发平台，致力于利用企业级开源工具，为开发者提供一套功能丰富且易于使用的后端服务。它的目标是提供类似于Firebase的开发体验，但全部基于开放源代码技术栈，从而赋予开发者更大的灵活性、控制力与透明度。无论是构建Web、移动还是AI应用程序，Supabase都提供了一整套强大的工具来加速开发过程。 Supabase核心功能概览 Supabase将一系列关键的后端服务整合到一个统一的平台中，极大地简化了应用开发的复杂性。其主要功能包括： 托管的Postgres数据库: 作为整个平台的核心，Supabase提供稳定、可靠且高度可扩展的Postgres数据库服务。开发者可以享受到Postgres久经考验的强大功能、数据完整性和灵活性，无需担心数据库的运维管理。 用户认证与授权: Supabase内置了强大的身份认证和授权系统。它支持多种认证方式（如电子邮件/密码、OAuth等），并能轻松管理用户、会话和访问控制，确保应用程序的安全性。 自动生成API: REST API: Supabase能够从您的Postgres数据库自动生成功能完备的RESTful API，允许开发者通过HTTP请求与数据库进行交互，省去了手动编写API接口的繁琐工作。 GraphQL API: 通过内置的pg_graphql扩展，Supabase还支持GraphQL API，为数据查询和操作提供了更灵活、高效的方案，允许客户端精确请求所需数据。 实时订阅: 利用WebSocket技术，Supabase的实时功能允许应用程序监听数据库的插入、更新和删除事件，并即时接收变更通知，这对于构建实时聊天、通知系统或协同编辑应用至关重要。 函数服务: 数据库函数 (Postgres Functions): 开发者可以直接在Postgres数据库中编写和执行存储过程和函数，用于处理复杂的业务逻辑或数据转换，将计算能力下推到数据层。 边缘函数 (Edge Functions): Supabase还提供了基于Deno的边缘函数服务。这些函数部署在全球各地的边缘节点，可以实现低延迟的代码执行，非常适合处理API路由、数据转换或身份验证逻辑。 文件存储: 提供安全高效的对象存储服务，兼容S3。开发者可以轻松地存储和管理用户上传的图片、视频、文档等文件，并通过Postgres强大的权限管理系统来精确控制访问权限。 AI与向量/嵌入工具包: 随着AI技术的发展，Supabase集成了对AI应用的支持，包括向量存储和嵌入工具。这使得开发者可以方便地构建语义搜索、推荐系统等智能应用。 直观的仪表盘: Supabase提供了一个美观且功能丰富的Web仪表盘，让开发者能够直观地管理数据库、用户、存储桶、API密钥等所有项目资源，极大地提升了开发效率和管理便利性。 Supabase的架构哲学与组件 Supabase的核心理念是“用开源替代开源”。这意味着如果存在符合MIT、Apache 2或同等开放许可的优秀开源工具，Supabase就会采纳并支持它。如果某个功能没有合适的开源工具，Supabase就会自行构建并将其开源。这种哲学构建了一个透明、可信赖且社区驱动的生态系统。 Supabase的平台是由以下关键开源组件共同构建而成： Postgres: 作为后端服务的基石，提供了强大的关系型数据库功能。 Realtime: 一个基于Elixir的服务器，通过WebSocket将PostgreSQL数据库的变更实时广播给授权客户端。 PostgREST: 一个Web服务器，能够将PostgreSQL数据库直接转换为一个即时可用的RESTful API。 GoTrue: 一个基于JWT（JSON Web Token）的认证API，负责处理用户注册、登录和会话管理。 Storage: 一个RESTful API，用于管理S3兼容的文件存储，并由Postgres处理权限。 pg_graphql: 一个PostgreSQL扩展，用于直接从数据库暴露一个GraphQL API。 postgres-meta: 一个RESTful API，用于管理Postgres数据库本身，例如获取表信息、添加角色和运行查询等。 Kong: 一个云原生的API网关，负责API流量的路由、管理和安全。 这些组件的协同工作使得Supabase既能提供高性能的服务，又保持了高度的灵活性和可定制性。此外，Supabase不仅提供方便的托管服务，还支持开发者进行自托管和本地开发，满足不同场景的需求。 多语言客户端库支持 为了方便广大开发者，Supabase采取了模块化的客户端库设计。每个子库都为特定的外部系统提供独立的实现，这使得开发者可以根据自己的技术栈选择最合适的工具。 Supabase提供了以下官方客户端库： JavaScript (TypeScript): supabase-js Flutter: supabase-flutter Swift: supabase-swift Python: supabase-py 除了官方库，Supabase社区也贡献了大量优秀的客户端库，支持C#、Go、Java、Kotlin、Ruby、Rust、Godot Engine (GDScript)等多种编程语言和平台，进一步扩大了Supabase的生态覆盖。 ...

在构建 n8n 自动化工作流时，我们常常会遇到一些重复使用、且不常变动的数据，例如 API 密钥、基础 URL、固定文本或特定的数值。将这些数据定义为“常量”并加以管理，可以极大地提升工作流的灵活性、可维护性和安全性。本文将深入探讨在 n8n 中设置和使用常量的多种方法及其最佳实践。 什么是常量？为何在 n8n 中需要它们？ 在编程或自动化领域，“常量”是指在程序执行过程中其值不会改变的数据项。与“变量”不同，常量一旦定义，其值就固定下来。 在 n8n 工作流中使用常量，主要有以下几个核心优势： 提高可维护性： 当某个值需要更新时（例如，API 地址变更），您只需在一个地方修改常量定义，而无需遍历整个工作流寻找并替换所有出现该值的地方。 增强可读性： 使用有意义的常量名称（如 API_KEY 而非一长串字符）可以使工作流的意图更加清晰，便于理解和调试。 减少错误： 集中管理常量可以避免因手动输入多次而产生的拼写错误或值不一致的问题。 提升安全性： 特别是对于敏感信息，如 API 密钥，可以通过环境变量的方式安全地管理，避免硬编码在工作流中。 支持多环境配置： 通过常量，可以轻松地为开发、测试和生产环境配置不同的参数。 n8n 中设置常量的主要方法 n8n 提供了多种灵活的方式来定义和使用常量，您可以根据具体场景选择最适合的方法。 方法一：使用 Set 节点 (Set Node) Set 节点是 n8n 中最直观、最常用的数据处理节点之一，非常适合在工作流内部定义和传递常量。 如何配置： 在工作流中添加一个 Set 节点。通常，您可以将它放在工作流的起始位置，紧跟在触发器之后。 在 Set 节点的配置面板中，点击“Add Value”（添加值）。 在“Name”（名称）字段中输入您希望定义的常量名称，例如 BASE_API_URL。 在“Value”（值）字段中输入该常量对应的值，例如 https://api.example.com/v1。 您可以选择“Keep Only Set”来只保留此节点设置的值，或者“Merge With Existing”来将新值合并到现有数据中。对于常量，通常选择“Merge With Existing”更常见，以便将常量添加到后续节点可访问的数据中。 引用方式： 在后续节点中，您可以通过表达式 {{ $json.BASE_API_URL }} 来引用这个常量。 示例： 假设您的工作流需要多次调用一个 REST API，其基础 URL 是固定的。 ...

Azure SDK for Python 是一个专为 Python 开发者设计，用于与 Azure 服务进行交互的软件开发工具包。它支持开发者在 Python 环境中构建、部署和管理 Azure 上的各类资源。本文旨在为希望深入了解或使用 Azure SDK for Python 的开发者提供全面的信息和指导。 简介 Azure SDK for Python 的 GitHub 仓库 (Azure/azure-sdk-for-python) 是其活跃开发的主阵地。对于希望使用此 SDK 的开发者，官方建议访问公开的开发者文档或带版本号的开发者文档。这些文档提供了详细的入门指南、API 参考和使用示例，帮助开发者快速上手。 开始使用 Azure SDK for Python 采用模块化设计，每个 Azure 服务都有独立的库。这意味着开发者可以根据实际需求选择性地引入所需的库，而非一个庞大的整体包。要开始使用特定的库，开发者可以查阅位于 /sdk 目录下的相应库项目文件夹中的 README.md 或 README.rst 文件。 先决条件 Azure 客户端库目前支持 Python 3.9 或更高版本。有关详细的版本支持策略，请参阅 Azure SDK for Python 的版本支持政策页面。 软件包分类 Azure SDK for Python 提供的软件包主要分为以下几类，以满足不同场景和需求的开发者： 客户端库：最新发布 这部分是 Azure SDK 的新一代发布，包括已通用可用（GA）和处于预览阶段的库。这些库主要用于与现有 Azure 资源进行交互和数据操作，例如上传 Blob 文件。它们共享一系列核心功能，如重试机制、日志记录、传输协议和身份验证协议等，这些功能统一由 azure-core 库提供。这些新库严格遵循 Azure SDK Python 设计指南，确保了一致的开发体验。 ...

这是一个经过专业整理的n8n工作流集合，包含2053个工作流，并配备了一套闪电般快速的文档系统。该系统提供即时搜索、分析和浏览功能，极大地提升了工作流的管理与发现体验。 ⚠️ 重要通知 (2025年8月14日): 由于DMCA合规要求，此仓库的历史记录已被重写。如果您有此仓库的分支或本地克隆副本，请参阅问题页面获取同步副本的说明。 支持项目 如果您希望对我的工作表示感谢，可以考虑请我喝杯咖啡。您的支持将帮助我持续改进这个项目！ 全新：高性能文档系统 体验比传统文档系统快100倍的性能提升！ 快速上手：高速文档系统 要启动高速文档系统，请遵循以下步骤： pip install -r requirements.txt python run.py http://localhost:8000 主要功能: ⚡ 亚100毫秒响应时间: 利用SQLite FTS5实现快速搜索。 🔍 即时全文搜索: 支持高级筛选功能。 📱 响应式设计: 在移动设备上也能完美运行。 🌙 深色/浅色主题: 根据系统偏好自动检测。 📊 实时统计: 包含365个独特集成，共计29,445个节点。 🎯 智能分类: 根据触发器类型和复杂度进行分类。 🎯 用例分类: 根据服务名称映射到不同类别。 📄 按需JSON查看与下载: 方便地查看和获取工作流JSON文件。 🔗 Mermaid图表生成: 用于工作流可视化。 🔄 实时工作流命名: 采用智能格式化。 性能对比 以下是新旧系统之间的性能对比： 指标 旧系统 新系统 文件大小 71MB HTML <100KB 加载时间 10+ 秒 <1 秒 搜索 仅客户端搜索 FTS5全文搜索 内存使用 约2GB RAM <50MB RAM 移动支持 差 优秀 仓库组织结构 工作流集合 2,053个工作流: 具有有意义、可搜索的名称。 365个独特集成: 涵盖各种流行平台。 29,445个总节点: 经过专业分类。 质量保证: 所有工作流均经过分析和分类。 高级命名系统 ✨ 我们的智能命名系统能将技术性的文件名转换为易于阅读的标题： ...

Hyperswitch：基于Rust的模块化开源支付交换平台 在当今瞬息万变的数字商务环境中，企业对支付基础设施的需求日益增长，不仅要求处理速度快、可靠性高，更要具备成本效益和高度灵活性。由Juspay推出的开源支付交换平台Hyperswitch，正是为满足这些核心需求而生。它以Rust语言编写，旨在为全球企业提供一个可组合、可控且高性能的支付解决方案，赋能企业自主管理和优化其支付流程。 Hyperswitch 的核心价值与能力 Hyperswitch 的设计理念是提供一个模块化的支付基础设施，允许企业根据自身需求灵活选择并集成所需的功能模块，从而避免不必要的复杂性或供应商锁定。其核心优势在于能够集成到现有支付栈之上，或者作为一套完整的支付解决方案使用。 主要功能模块包括： 1. 成本可见性 (Cost Observability) Hyperswitch 提供先进的监控工具，帮助企业审计、跟踪和优化支付成本。通过自助式仪表盘和可操作的洞察，用户可以轻松检测隐藏费用、降级罚款以及其他不必要的开支，从而实现透明化管理和成本优化。 2. 收入恢复 (Revenue Recovery) 针对被动流失问题，Hyperswitch 引入了智能重试策略。这些策略可根据卡BIN、地区、支付方式等多种维度进行调整，为企业提供精细化的控制，以最大限度地提高交易成功率，挽回潜在收入。 3. 支付金库 (Vault) 为了确保支付数据的安全性和合规性，Hyperswitch 提供了一项符合PCI标准的金库服务。它能够安全存储银行卡、令牌、电子钱包和银行凭证等信息，为客户关联的支付方式提供一个统一、安全且可复用的存储库。 4. 智能路由 (Intelligent Routing) 此模块是 Hyperswitch 的一大亮点，它能够将每笔交易智能路由到预测授权率最高的支付服务提供商 (PSP)。这有助于减少重试次数，避免系统停机，最小化延迟，并最大限度地提高首次尝试的成功率，确保支付流程的顺畅。 5. 对账 (Reconciliation) Hyperswitch 自动化了双向和三向对账流程，支持回溯功能，可错开安排，并提供可定制的输出报告。这显著减少了人工操作工作量，并大大增强了审计的信心和准确性。 6. 替代支付方式 (Alternate Payment Methods) 为了最大化转化率，Hyperswitch 提供了即插即用的组件，支持集成PayPal、Apple Pay、Google Pay、Samsung Pay、银行转账以及Klarna等先买后付（BNPL）服务。这些无缝的一键结账体验有助于提升用户满意度和交易效率。 为何选择 Hyperswitch？ Hyperswitch 不仅仅是一个支付平台，它更是一种理念的体现——即“支付领域的Linux”。它的目标是让企业能够真正拥有和控制自己的支付栈。 极致的性能与可靠性：采用Rust语言构建，Hyperswitch天生具备高性能和高并发处理能力，确保支付系统的稳定运行。 高度模块化的架构：其设计让企业可以按需选择所需的模块，实现灵活的集成和扩展，避免了传统一体化解决方案带来的笨重和冗余。 消除供应商锁定：开放的架构和开源的本质，使企业不再受制于单一支付服务商，可以自由切换和组合，以获得最佳的支付体验和费率。 开发者友好的生态：Hyperswitch 注重开发者体验，提供清晰的文档和友好的开发环境，让开发者能够快速上手和集成。 社区驱动与企业级验证：作为一个开源项目，Hyperswitch 的发展路线图由社区反馈和实际使用案例共同塑造。同时，它由为全球400多家领先企业提供支付基础设施的Juspay团队维护，这为项目的稳定性和可靠性提供了企业级的保障。 Hyperswitch 坚信： 拥抱支付多样性：创新源于对支付方式、处理器和流程选择的赋能。 默认开源：透明度是建立信任和更好的可复用软件的基础。 社区驱动开发：其路线图由真实世界的使用案例和贡献者塑造。 系统级工程：对可靠性、安全性与性能有高标准要求。 最大化价值创造：为开发者、客户和合作伙伴带来最大价值。 快速上手与部署 Hyperswitch 提供了多种便捷的部署和体验方式，以适应不同用户的需求： 1. 本地Docker部署 通过简单的脚本，用户可以一键在本地设置 Hyperswitch。该脚本支持Docker/Podman，并提供多种部署配置文件，包括标准、完整或最小化配置，让开发者可以快速搭建本地开发环境进行测试和集成。 ...

Daft 是一个由 Eventual-Inc 开发的分布式查询引擎，旨在为任何模态和规模的数据提供简单可靠的处理方案。它支持用户通过 Python 或 SQL 进行大规模数据处理，其核心实现基于 Rust 语言。Daft 致力于在数据分析、工程以及机器学习/人工智能领域提供统一且高效的解决方案。 Daft 的核心特性 Daft 引擎融合了多项强大功能，使其在数据处理领域脱颖而出： 熟悉的交互式 API：Daft 提供了一套用户友好的 API，包括用于快速交互式迭代的延迟执行 Python Dataframe，以及用于分析查询的 SQL 接口。这使得不同背景的用户都能轻松上手。 关注“做什么”：Daft 内置了强大的查询优化器，能够自动重写查询，使其执行效率达到最高。用户只需定义他们想要实现的目标，Daft 就会负责优化执行路径。 数据目录集成：它与 Apache Iceberg 等主流数据目录实现了全面集成，方便用户管理和查询其数据资产。 丰富的多模态类型系统：Daft 不仅仅处理传统的字符串、数字和日期等数据类型。其基于 Apache Arrow 的内存表示能够高效支持图像、URL、张量等复杂或嵌套的多模态数据类型。这使得多模态数据的摄取和基本转换变得极其简单且高性能。 无缝数据交换：Daft 构建在 Apache Arrow 内存格式之上，确保了与其他数据处理工具之间的高效数据交换和互操作性。 为云而生：Daft 针对云环境进行了优化，与 S3 等云存储服务集成时，展现出卓越的 I/O 性能。 Daft 的设计理念 Daft 在设计时，遵循了以下三大核心原则： 1. 任意数据 (Any Data) Daft 超越了传统数据处理引擎的限制，不仅能够处理常见的结构化数据，还能高效地处理各种复杂和非结构化数据。无论是图像、嵌入向量，还是定制的 Python 对象，Daft 的基于 Arrow 的内存表示都能以高性能的方式进行存储和操作。这极大地简化了多模态数据的摄取和转换过程，为机器学习和人工智能应用提供了坚实的基础。 2. 交互式计算 (Interactive Computing) 为了提供卓越的开发者体验，Daft 专注于交互式计算场景，如 Jupyter Notebooks 或 REPLs。通过智能缓存和查询优化，Daft 显著加快了实验和数据探索的速度，让开发者能够更快速地迭代和验证想法。 ...

引言：拥抱您的个人媒体图书馆 在数字化时代，照片和视频已成为我们生活不可或缺的一部分，记录着珍贵的回忆。然而，随着媒体文件数量的激增，如何高效、安全地管理这些宝贵的数字资产成为了一个普遍的挑战。Immich 正是为了解决这一痛点而生：它是一个高性能的自托管照片和视频管理解决方案，旨在为用户提供完全的数据控制权，同时兼具现代云服务的功能性。 与许多依赖第三方云存储的解决方案不同，Immich 赋予用户将所有媒体文件存储在自己服务器上的能力。这意味着您的数据始终在您的掌控之中，极大地提升了隐私和安全性。作为一个活跃的开源项目，Immich 不仅提供了丰富的功能集，还拥有一个充满活力的社区，持续推动其发展和完善。 自托管的优势：掌控您的数字回忆 选择 Immich 这样的自托管解决方案，其核心优势在于对数据的主权和隐私保护。在当今数据泄露和隐私侵犯日益增多的环境下，将个人照片和视频托管在自己的服务器上，避免了将敏感信息托付给大型科技公司的风险。 此外，自托管还带来了更大的灵活性和可定制性。用户可以根据自己的硬件条件和网络环境，优化存储结构和访问速度。无论是家庭用户搭建私人媒体库，还是小型团队共享工作素材，Immich 都能提供一个高效且可控的平台。 核心功能：Immich 的强大之处 Immich 的设计目标是提供与主流照片管理服务相媲美的用户体验，同时融入自托管的优势。其功能涵盖了从基本的上传浏览到高级的智能管理。以下是一些 Immich 的主要亮点： 全面的媒体支持：Immich 支持照片和视频的上传与浏览，用户可以在移动应用和网页界面上无缝访问。 智能自动备份：移动应用程序具备在开启时自动备份功能，确保您的新媒体内容能够及时同步到服务器，有效防止数据丢失。 重复资产检测：系统能够智能识别并防止重复上传，帮助用户保持媒体库的整洁和高效。 精细化备份控制：用户可以选择性地备份特定相册，而非一股脑地同步所有内容，提供了更高的灵活性。 本地下载功能：无论身处何地，用户都可以方便地将照片和视频下载到本地设备，实现离线访问或本地编辑。 多用户支持：Immich 支持多用户账户，每个用户拥有独立的媒体库，但也可通过共享相册进行协作。 直观的交互体验：提供可拖动的滚动条，便于用户快速浏览大量媒体文件。 RAW 格式兼容：对于摄影爱好者而言，Immich 对 RAW 格式的支持意味着可以更好地管理和查看高质量的原始图像文件。 丰富的元数据视图：能够显示照片的 EXIF 信息和地理位置（地图），帮助用户了解媒体的详细信息和拍摄地点。 高级搜索功能：强大的搜索功能允许用户通过元数据、识别出的物体、人脸以及 CLIP（对比语言-图像预训练）模型进行搜索，快速定位所需内容。 管理功能：网页界面提供用户管理等行政功能，方便管理员对整个系统进行配置和维护。 后台备份（移动端）：移动应用支持后台备份，即使应用未处于前台，也能持续同步您的媒体文件。 虚拟滚动：无论是移动端还是网页端，Immich 都采用了虚拟滚动技术，确保在加载大量媒体时依然保持流畅的性能。 OAuth 认证支持：支持 OAuth 认证，提升了用户登录的便捷性和安全性。 API 密钥管理（网页端）：网页界面允许生成和管理 API 密钥，方便与其他服务或自动化脚本集成。 LivePhoto/MotionPhoto 兼容：支持备份和播放 LivePhoto 和 MotionPhoto，保留动态照片的完整体验。 360 度图像显示（网页端）：网页界面能够正确显示 360 度全景图像。 用户自定义存储结构：用户可以根据自己的偏好定义媒体文件的存储路径和组织方式。 公共分享功能：支持创建公共分享链接，方便与家人朋友分享照片和视频。 归档与收藏：提供归档和收藏功能，帮助用户管理不常查看但希望保留的媒体，或快速访问最喜爱的照片。 全球地图视图：集成全球地图功能，直观展示照片的地理分布。 伙伴分享：支持与特定伙伴分享媒体库，实现更紧密的协作。 面部识别与聚类：利用先进的机器学习技术进行面部识别和聚类，自动整理照片中的人物。 “X 年前的今天”回忆功能：自动生成“X 年前的今天”的回忆，重温往日时光。 离线支持（移动端）：移动应用提供有限的离线支持，允许在无网络连接时查看部分已缓存的媒体。 只读画廊：可以创建只读画廊，安全分享媒体而无需担心被修改。 堆叠照片：支持将相似或连续拍摄的照片堆叠在一起，优化视图空间。 标签管理（网页端）：通过网页界面为媒体添加标签，进一步增强搜索和分类能力。 文件夹视图：支持传统的文件夹视图，满足习惯文件系统管理的用户需求。 重要提示与备份策略 Immich 作为一个正在非常活跃开发中的项目，用户应预期存在错误和潜在的重大变更。项目团队也明确指出：**请勿将 Immich 作为存储照片和视频的唯一方式。**对于您珍贵的数字回忆，务必遵循 3-2-1 备份策略： ...

AutoAgent：赋能自然语言驱动的LLM智能体开发 在快速发展的人工智能时代，大型语言模型（LLM）智能体正成为自动化复杂任务的关键力量。AutoAgent 是一个开创性的框架，旨在提供一个全自动化、零代码的LLM智能体开发环境，其核心特色在于其强大的自然语言定制能力。与传统智能体框架不同，AutoAgent 允许用户仅凭自然语言即可创建工具、智能体乃至复杂的智能体工作流。 核心功能概览 AutoAgent 提供两种主要模式，使用户能够通过对话式交互来构建智能体： 智能体编辑器（Agent Editor） 这是 AutoAgent 最具特色的功能之一。通过 agent editor 模式，用户无需编写任何代码，只需使用自然语言描述其需求，即可创建自定义的智能体。这种直观的交互方式大大降低了智能体开发的门槛，使得非技术用户也能轻松设计和部署智能体。 工作流编辑器（Workflow Editor） 除了创建单个智能体，AutoAgent 还支持通过 workflow editor 模式来构建智能体工作流。用户同样可以通过自然语言描述，将多个智能体或工具串联起来，形成一个解决复杂任务的自动化流程。需要注意的是，目前该模式暂时不支持工具的创建功能。 快速上手指南 要开始使用 AutoAgent，请遵循以下详细步骤： 安装 AutoAgent 首先，你需要克隆 AutoAgent 仓库并安装其依赖： git clone https://github.com/HKUDS/AutoAgent.git cd AutoAgent pip install -e . 安装 Docker AutoAgent 利用 Docker 来容器化智能体交互环境，因此请确保你已安装 Docker。你无需手动拉取预构建镜像，Auto-Deep-Research 会根据你的机器架构自动完成此操作。 API 密钥设置 创建一个 .env 文件（可参考 .env.template），并配置你希望使用的LLM提供商的API密钥。并非所有密钥都是必需的，只需设置你需要的服务即可。 GITHUB_AI_TOKEN= OPENAI_API_KEY= DEEPSEEK_API_KEY= ANTHROPIC_API_KEY= GEMINI_API_KEY= HUGGINGFACE_API_KEY= GROQ_API_KEY= XAI_API_KEY= MISTRAL_API_KEY= OPENROUTER_API_KEY= 通过 CLI 模式启动 AutoAgent 提供了易于使用的命令行界面（CLI）来启动。 你可以运行 auto main 来启动 AutoAgent 的完整功能，包括用户模式、智能体编辑器和工作流编辑器。此外，你也可以运行 auto deep-research 来启动更轻量级的用户模式，类似于 Auto-Deep-Research 项目。 ...

简介 Pathway AI Pipelines 是一个强大的平台，旨在帮助开发者快速将AI应用投入生产，尤其是在构建需要高精度RAG（检索增强生成）和大规模AI企业搜索的场景。该平台利用数据源中最新的知识，确保搜索结果和生成内容的准确性。它提供了开箱即用的LLM（大型语言模型）应用模板，支持在本地机器上进行测试，并可部署到云端（如GCP、AWS、Azure、Render等）或本地环境。 Pathway AI Pipelines 的核心优势在于其无缝的数据集成与同步能力。它能够连接并实时同步来自各种数据源的数据，包括文件系统、Google Drive、Sharepoint、S3、Kafka、PostgreSQL以及实时数据API。这意味着数据的任何新增、删除或更新都会即时反映在AI应用中。此外，这些应用无需额外的基础设施设置，因为它们内置了数据索引功能，支持向量搜索、混合搜索和全文搜索，所有操作都在内存中完成，并配备了缓存机制，极大简化了部署和维护的复杂性。 应用模板 Pathway AI Pipelines 提供的应用模板具有出色的可扩展性，能够处理数百万页的文档。部分模板针对简单性进行了优化，而另一些则追求卓越的准确性，用户可以根据自身需求选择最合适的模板。这些模板既可以直接使用，也可以轻松定制。例如，若需添加新的数据源，或将向量索引改为混合索引，通常只需修改一行代码即可完成。 以下是Pathway AI Pipelines提供的一些核心应用模板： 问答型RAG应用：一个端到端的基础RAG应用。它利用用户选择的GPT模型，根据实时连接的数据源（如文件、Google Drive、Sharepoint等）中的文档（PDF、DOCX等）回答查询。 实时文档索引（向量存储/检索器）：一个用于RAG的实时文档索引管道，可作为向量存储服务。它能对连接的数据源（文件、Google Drive、Sharepoint等）中的文档（PDF、DOCX等）进行实时索引。该服务可以与任何前端配合使用，也可作为Langchain或Llamaindex应用的检索后端进行集成。 基于GPT-4o的多模态RAG管道：利用GPT-4o在解析阶段处理PDF及其他文档，实现多模态RAG。它非常适合从文件夹中的非结构化财务文档（包括图表和表格）中提取信息，并随着文档的更改或新文档的到来实时更新结果。 非结构化数据到SQL管道及SQL问答：一个RAG示例，连接到非结构化财务数据源（如财务报告PDF），将数据结构化为SQL，并加载到PostgreSQL表中。它还能通过LLM将自然语言用户查询翻译成SQL，并对PostgreSQL表执行查询，从而回答有关这些财务文档的问题。 自适应RAG应用：一个采用Adaptive RAG技术的RAG应用，Pathway开发的这项技术能够在保持准确性的同时，将RAG的令牌成本降低多达4倍。 基于Mistral和Ollama的私有RAG应用：demo-question-answering RAG管道的完全私有（本地）版本，利用Pathway、Mistral和Ollama实现。 演示文稿AI搜索应用：一个用于检索幻灯片的索引管道。它对PowerPoint和PDF进行多模态处理，并维护幻灯片的实时索引。 Pathway AI 管道的工作原理 Pathway AI Pipelines 应用可以作为Docker容器运行，并提供HTTP API接口以连接前端。为了方便快速测试和演示，一些应用模板还包含一个可选的Streamlit UI，它连接到这些API。 这些应用的核心是Pathway Live Data框架，该框架负责数据源同步和API请求服务（Pathway是一个独立的Python库，内置Rust引擎）。它为后端、嵌入、检索和LLM技术栈带来了简单而统一的应用逻辑。这意味着开发者无需集成和维护单独的模块来构建其生成式AI应用，避免了传统上需要结合向量数据库（如Pinecone/Weaviate/Qdrant）、缓存（如Redis）和API框架（如Fast API）的复杂性。Pathway默认内置的向量索引基于闪电般快速的usearch库，而混合全文索引则利用Tantivy库。所有这些都开箱即用，极大地简化了开发流程。 如何开始 本仓库中的每个应用模板都包含一个README.md文件，提供了详细的运行说明。 您还可以在Pathway网站上找到更多即用型代码模板。 视觉亮点概览 Pathway AI Pipelines 提供了直观的功能展示，例如： 多模态RAG：能够实时轻松地从PDF、文档等中提取和组织表格及图表数据。这种能力使得处理非结构化信息变得前所未有的高效。 自动化实时知识挖掘和警报：通过自动化的流程，系统能够实时从连接的数据源中挖掘知识，并在关键信息发生变化时提供警报。 资源与社区 操作视频 一段关于使用Pathway构建LLM应用的入门介绍视频。 一个在11分钟内构建真实世界LLM应用的教程视频。 故障排除 如果您想提供反馈或报告错误，请在Pathway的问题追踪器上提交问题。 贡献 我们非常鼓励任何人对本项目做出贡献，无论是文档、功能、错误修复、代码清理、测试还是代码审查。如果您是首次参与GitHub项目，可以参考入门指南。 如果您希望进行更复杂的贡献，可以在Pathway Discord服务器的#get-help频道中提出您的计划。 支持与维护 本项目由Pathway团队提供支持和维护。Pathway还提供了一系列AI应用解决方案。 查看更多详情

大型语言模型（LLM）的兴起正在重塑软件开发的格局。然而，要想充分利用AI代码代理的潜力，并不仅仅是将任务交给它们那么简单。围绕“用于规范LLM协作的软件开发方法论”的讨论揭示了一个核心观点：严谨的规划、测试和持续的人工监督是实现AI辅助开发高效率和可靠性的关键。 LLM 辅助开发的核心原则 要让AI代理在软件开发中发挥最大价值，需要一套系统化的方法。讨论中强调了以下几个核心原则： 1. 强调周密的规划阶段 在AI代理开始工作之前，必须有一个强大且深入的规划周期。这包括： 深度研究：全面收集与新功能相关的代码，利用LLM（如Gemini/GPT5）对整个代码库进行宏观理解。 讨论与细化：围绕如何解决问题进行讨论，最终产出一份极其详细的计划。这份计划应精确到文件级别，并勾勒出所需的具体变更。 自主规划流程：理想情况下，这个规划过程应该是高度自动化的。创建一个问题，触发规划器生成计划，计划完成后触发测试实现者，测试完成后再触发代码实现者。 这种详细的规划能够确保AI代理在正确的方向上持续工作数小时，避免因理解不足或指示不清而解决错误或简单的问题。 2. 强大的测试与验证机制 仅仅有计划是不够的，还需要结合强大的测试策略： 高测试覆盖率：维护良好的测试覆盖率是基础。 AI代理红队测试：利用AI代理主动对测试进行“红队”攻击，以确保其足够健壮，能够捕获潜在的边缘情况和错误。 变化集分析：通过强大的测试验证和变化集分析，及时发现AI代理因“受挫”或“未遵循指示”而产生的偏差。 3. 任务分解与上下文管理 面对复杂的任务，将工作分解成更小、更具体的步骤至关重要。为每个步骤提供详细的指示，并为每个“领域专家子代理”分配一个全新的、清晰的上下文，可以有效地避免大型语言模型经常出现的“上下文噩梦”——即在冗长或压缩的上下文中忽略或遗忘特定指令的问题。 挑战与局限性 尽管LLM辅助开发前景广阔，但社区也指出了其固有的挑战： 1. 模型行为的不可预测性 大型语言模型本质上是“概率性工具”，期望它们提供完全确定性的结果是不现实的。许多开发者反映，即使提供极其详细的规范，AI代理（如Claude）也可能经常做错事，忽略甚至忘记关键指示。这表明模型在理解和遵循复杂规则方面仍有局限性。 2. 上下文管理的困境 随着上下文的增长，模型更容易出现遗忘或混淆的情况。即使是“全新的上下文”也可能不足以阻止模型偏离规范，这让开发者不禁怀疑，无论设置多少“护栏”或规范有多详细，如果AI编码代理随机决定忽略它们，那一切都无济于事。 3. 对规划能力的质疑 有观点认为，AI代理本身在规划方面表现不佳，除非它们能够利用深度研究工具来获取全面的代码库信息。这意味着人类的介入和指导在规划初期仍然不可或缺。 对软件开发实践的影响 LLM的引入，正在对传统的软件开发实践带来深远影响，甚至在某种程度上强制性地改变着开发者的工作习惯： 1. 文档与规范的复兴 一个具有讽刺意味的现象是，LLM的出现迫使程序员采用超详细、规范化的实践。它们“哄骗”软件开发者去编写高质量的文档。这种对文档的重视，历史上在人类协作中往往被忽视，但在LLM面前却变得至关重要，因为LLM能够“始终如一地关注”并“奖励”这种努力。 2. 人机协作中的角色转变 大型语言模型正在推动软件开发中角色的分离，类似于早期业务计算时代系统分析师和程序员的分工：人类负责编写规范，AI代理负责编写代码。这种分工原则自柏拉图时代以来就已存在，如今以新的形式在人机协作中重新浮现。 3. 问责制与文化变革 AI辅助开发也带来了新的问责挑战。如果AI设置失败，责任往往直接归咎于个人，而在人类官僚体系中，责任可能被分散。这可能成为完全取代人类劳动的一个反作用力。此外，传统的“敏捷”实践往往没有为阅读、写作、反思或讨论预留时间，这与LLM所要求的严谨规划和文档编写形成了冲突，预示着一种文化层面的变革。 案例与效率提升 尽管存在挑战，但通过严格的方法论，AI辅助开发仍能带来显著的效率提升。 PhiCode Runtime 的经验 PhiCode Runtime项目便是一个力证。这个包含代码转换、性能优化和安全验证的完整编程语言运行时，仅用了14天便完成构建。其提交历史提供了可追踪的证据，表明相同功能的手动开发可能需要数月。这种“将自己从循环中移除”并辅以分析性“护栏”所带来的开发速度是惊人的。 速度与可维护性 PhiCode的经验表明，AI在生成代码方面比手动编码更快，而系统性的约束可以防止架构债务，从而避免后期昂贵的重构周期。通过将核心上下文（如主要入口点、配置、常量、基准测试）共享，而不是管理整个代码库，该方法可以实现可扩展性。这种“严格性”在既定约束下提供了灵活性，例如强制模块化（150行代码限制），使得每个组件都易于理解和测试，从而提升了项目的可维护性。 结论 大型语言模型无疑为软件开发带来了前所未有的机遇，但它们并非万能。它们需要一套高度纪律化、结构化的方法论来引导，这包括深入的规划、严格的测试、精细的任务分解以及清晰的上下文管理。虽然这可能意味着人类开发者需要投入更多精力在文档和规范上，但这种投入最终会以“疯狂的开发速度”和更健康的软件架构的形式获得回报。在大型语言模型时代，纪律性不再是可选项，而是解锁AI巨大潜能，实现人机高效协作的必由之路。

在现代电子游戏领域，逼真的视觉效果是提升玩家沉浸感的关键。其中，模糊效果扮演着不可或缺的角色，它不仅能够模拟景深、运动模糊等物理现象，还能作为构建更复杂图形效果（如发光、磨砂玻璃、热变形）的基础。一篇近期发布的博客文章深入探讨了电子游戏中的模糊技术，特别是“双川濑模糊”（Dual-Kawase Blur）的原理及其优势，引发了广泛讨论。 川濑模糊的起源与双川濑模糊的崛起 川濑模糊技术，由日本图形程序员川濑正树（Masaki Kawase）于2005年提出，是游戏图形领域的一项重要创新。最初，这项技术旨在优化当时GPU性能有限的环境下的模糊处理。博客文章的作者通过与川濑正树的交流，加深了对那个“冒险时期”（1999-2005年）日本游戏图形编程的理解，并从中获得了探索双川濑模糊的灵感。 双川濑模糊（Dual-Kawase Blur）作为川濑模糊的演进版本，在2015年左右主要针对移动图形设备开发。它以其卓越的性能和优化在资源受限的环境中脱颖而出。即使在当下性能强劲的显卡（如RTX 4090）上，一些未经优化的朴素高斯模糊实现仍然可能导致性能瓶颈，这主要源于纹理缓存的效率问题。因此，在如今高分辨率和移动设备的普及背景下，双川濑模糊这类智能且优化的算法依然至关重要，它确保了图形效果在保持视觉质量的同时，也能满足实时渲染的性能需求。 传统高斯模糊与现代散景模糊 在模糊效果家族中，高斯模糊无疑是最基础且广泛应用的一种。然而，它也存在一些局限性。随着图形技术的进步，散景模糊（Bokeh Blur）作为一种更自然、更具电影感的模糊效果开始受到青睐。 散景模糊模拟了真实相机中因光圈形状（通常是圆形）而产生的失焦效果，使得画面中的虚化部分呈现出圆盘状的光斑，而非高斯模糊常见的均匀模糊。2016年的《毁灭战士》（Doom）便是一个采用散景模糊的经典案例，其景深效果远比传统高斯模糊更为逼真。虽然川濑模糊与高斯模糊在某些方面相似，但作者强调，它们更多地被视为构建其他复杂效果的基石，而散景模糊则提供了更高层次的视觉真实感。 性能考量与未来挑战 图形编程的核心挑战之一，是如何在视觉质量和渲染性能之间找到最佳平衡。对于模糊算法而言，这一挑战尤为突出。 内存带宽与纹理缓存：即使是拥有强大算力的GPU，当面临高分辨率和复杂的模糊运算时，内存吞吐量和纹理缓存效率仍然是决定性能的关键因素。双川濑模糊之所以高效，正是因为它在设计上考虑了这些硬件特性，减少了不必要的内存访问。 计算着色器（Compute Shaders）的应用：对于希望在共享内存中直接处理图像数据、避免频繁读写显存的开发者来说，将模糊算法移植到计算着色器上是一个方向。然而，这并非易事。传统的川濑模糊依赖纹理的双线性采样，而计算着色器中的某些指令（如warp/wave/subgroup intrinsics）可能仅限于“偶数”位置采样，这与川濑模糊在“奇数”位置采样的需求形成冲突，需要更巧妙的算法设计来克服。 傅里叶变换与低通滤波：文章中还提及了傅里叶变换（FFT）在低通滤波中的应用。虽然图像空间中的卷积操作在傅里叶空间中表现为乘法，理论上可以通过傅里叶变换实现高斯模糊，但这并非总是最快的选择。这突显了在实际应用中，算法选择需要综合考虑计算效率和实现复杂度。 互动演示与视觉伪影 原博客文章中包含了一个“Animate”按钮，可以使场景移动，旨在揭示不同模糊算法在运动中可能出现的视觉伪影。例如，当采用多步下采样时，快速移动的图像可能会出现“沸腾”效应，尤其是在处理微小而明亮的光源时，这些光源可能在运动中反复出现和消失。这种动态演示对于理解算法的局限性及其在实时游戏中的表现至关重要。 尽管其教育意义显著，但一些读者反馈认为默认开启动画可能分散注意力，甚至感到“烦人”。这促使作者考虑是否应默认关闭此功能，以改善用户的初次体验。这种用户体验的考量，再次凸显了在设计技术演示时，如何在功能性和用户友好性之间取得平衡的重要性。 内容呈现与排版艺术 在图形技术讨论之外，文章的排版方式也引发了读者的热烈讨论。博客文章采用了两端对齐（justified）的文本格式，这使得版面看起来更规整、正式。然而，一些读者指出，两端对齐的文本在屏幕上可能比左对齐（ragged-right）更难阅读。 这场讨论揭示了排版规范在不同媒介间的演变： 传统印刷媒体：在印刷术兴盛的时代，书籍、报纸和杂志普遍采用两端对齐，这被视为正式且美观的标准。 网络媒介：在互联网时代，左对齐逐渐成为主流。部分原因在于早期的浏览器对连字符和精细字距调整支持不足，两端对齐容易导致词间距过大，形成“河流”效应，影响阅读。此外，对于患有阅读障碍的用户来说，左对齐的文本也可能更易于阅读。 虽然CSS现在已经提供了连字符功能，可以在一定程度上改善两端对齐的效果，但在网络环境下，左对齐仍被认为是更符合人体工程学和阅读习惯的选择。这场关于排版的讨论，不仅是对具体技术博客的建议，也反映了数字时代内容呈现方式的持续演进。 结语 从川濑模糊到现代的散景模糊，从CPU的简单计算到GPU的并行处理，电子游戏中的模糊技术一直在不断演进。它们不仅是提升画面表现力的工具，更是图形程序员在性能与视觉效果之间寻求平衡的智慧结晶。对这些底层技术的深入理解和持续优化，是推动游戏图形向前发展的关键动力。同时，如何以更清晰、更互动的方式呈现这些复杂的概念，以及在用户体验层面做出更友好的设计，也同样值得我们深思。

在去中心化应用日益普及的今天，区块链的透明性既是其优势，也带来了隐私方面的挑战。为了解决这一核心矛盾，Zama-ai 推出了 FHEVM——一个旨在将全同态加密（FHE）与区块链应用深度融合的全栈框架。FHEVM 不仅为 EVM 兼容区块链带来了革命性的隐私保护能力，更开创了保密智能合约的新范式，成为 Zama 保密区块链协议的核心支柱。 什么是 FHEVM？ FHEVM 是 Zama 保密区块链协议的核心框架，它通过利用全同态加密（FHE）技术，使得加密数据可以直接在链上进行处理。这意味着，数据在交易和状态更新的整个生命周期中都保持加密状态，即使在区块链网络中处理时也无法被窥探，从而确保了端到端的隐私保护。 FHEVM 在保障隐私的同时，也兼顾了可组合性和数据可用性，主要提供以下核心保证： 交易和状态的端到端加密：交易中包含的所有数据都经过加密，对任何人都不可见。这意味着用户可以放心地进行敏感操作，而无需担心数据泄露。 链上可组合性与数据可用性：即使在数据始终保持加密的情况下，链上状态也能进行更新和交互。这打破了传统隐私解决方案在可组合性上的限制，使得加密数据能够无缝地与现有区块链生态系统集成。 不影响现有去中心化应用（dApps）和状态：加密状态与公开状态可以并行存在，互不影响。这使得开发者能够在不破坏或修改现有应用逻辑的情况下，逐步引入隐私保护功能。 FHEVM 的目标是让开发者无需深厚的密码学知识，也能轻松构建具有高级隐私功能的去中心化应用。 项目架构概览 FHEVM 项目采用了模块化设计，其代码库结构清晰，主要分为以下几个核心部分： FHEVM 合约 gateway-contracts/：这些智能合约负责管理链上组件与链下组件之间的网关，确保加密数据和计算请求的顺畅流通。 host-contracts/：部署在宿主链上的智能合约，主要用于协调和编排 FHE 工作流，例如处理 FHE 操作的请求和结果。 FHEVM 计算引擎 coprocessor/：一个基于 Rust 实现的协处理器，专门负责执行复杂的全同态加密计算。这些计算通常计算密集型，通过协处理器进行异步处理，可以显著提高链上执行效率。 kms-connector/：用于与密钥管理服务（KMS）集成的接口，确保加密密钥的安全处理、存储和分发。它是 FHEVM 安全模型中的关键一环。 FHEVM 工具 charts/：包含了整个 FHEVM 堆栈的 Helm charts 和部署配置，方便开发者进行快速部署和管理。 golden-container-images/：为 Node.js 和 Rust 环境提供的 Docker 基础镜像，作为 FHEVM 堆栈中各个组件的基础运行环境。 test-suite/：集成了 Docker Compose 和全面的测试用例，用于验证 FHEVM 整个堆栈的端到端行为和功能正确性。 这种结构确保了 FHEVM 的可扩展性、可维护性和互操作性，为开发者提供了强大的工具集。 FHEVM 核心特性 FHEVM 框架集成了多项创新功能，旨在为区块链带来前所未有的隐私保护能力和开发体验： ...

引言 在日常工作和学习中，PDF文件处理是不可避免的需求。无论是合并多个文档、拆分大型报告，还是进行格式转换和安全加密，一款高效可靠的PDF工具都至关重要。Stirling-PDF，作为一款领先的本地部署网页版PDF应用，应运而生，旨在提供全面的PDF操作解决方案。它以其强大的功能、对用户隐私的承诺以及灵活的部署方式，迅速获得了用户的青睐。 Stirling-PDF 是一个基于 Docker 技术的本地托管网络应用程序，这意味着所有文件处理都在您自己的服务器上进行，极大地增强了数据安全性和隐私保护。它不仅是一个简单的PDF阅读器，更是一个功能丰富的工具集，能够满足您对PDF文件的各种复杂操作需求。 核心特点 Stirling-PDF 不仅仅是功能多样，更在用户体验和系统设计上独具匠心。其主要特点包括： 50+项PDF操作: 涵盖从基础的页面管理到高级的安全设置，功能之全面令人印象深刻。 并行文件处理与下载: 优化了处理效率，允许同时处理多个任务并提供自定义下载选项。 深色模式支持: 提供更舒适的视觉体验，尤其适合长时间使用。 自定义“管道”工作流: 用户可以创建自动化队列，将多个操作串联起来，实现一键式处理。 API接口: 方便与其他外部脚本或系统进行集成，实现自动化工作流。 可选的用户登录与认证: 提供更严格的访问控制，保障数据安全。 数据库备份与导入: 确保配置和历史数据不会丢失。 企业级功能: 如单点登录（SSO）支持，满足企业用户的特定需求。 详细功能概览 Stirling-PDF 的功能被精心组织为多个类别，以应对不同场景下的PDF处理需求。 页面操作 对于PDF文件的内部结构，Stirling-PDF提供了精细的控制： 查看与修改PDF: 利用PDF.js与Joxit等技术，支持多页PDF的自定义查看、排序和搜索，并提供页面上的批注、绘图、文本和图像添加等编辑功能。 交互式图形用户界面 (GUI): 提供直观的界面，用于合并、拆分、旋转和移动PDF及其页面。 合并PDF: 将多个PDF文件无缝合并成一个。 拆分PDF: 根据指定页码将PDF拆分为多个文件，或将所有页面提取为独立文件。 重排PDF页面: 自由调整PDF页面的顺序。 旋转PDF: 以90度为单位旋转PDF页面。 删除页面: 移除不需要的PDF页面。 多页布局: 将PDF页面格式化为多页排版。 缩放页面内容: 按设定的百分比调整页面内容大小。 调整对比度: 优化PDF页面的视觉效果。 裁剪PDF: 裁剪PDF页面的特定区域。 自动拆分PDF: 能够识别物理扫描的分页符并自动拆分PDF。 提取页面: 提取PDF中的特定页面。 将PDF转换为单页: 将多页PDF转换为仅包含一页的PDF。 PDF叠加: 将一个PDF叠加到另一个PDF之上。 按章节拆分PDF: 根据文档结构或自定义规则拆分PDF。 转换功能 Stirling-PDF 强大的转换能力使其成为处理各种文件格式的中心枢纽： PDF与图像互转: 支持PDF与JPG、PNG等图像格式之间的双向转换。 常见文件转PDF: 利用LibreOffice引擎，将Word、Excel、PowerPoint等常见文档格式转换为PDF。 PDF转Word/PowerPoint/其他: 同样通过LibreOffice，将PDF转换为可编辑的Office文档格式。 HTML转PDF: 将网页内容转换为PDF文件。 PDF转XML/CSV: 提取PDF内容并转换为结构化的数据格式。 URL转PDF: 直接将网页链接转换为PDF。 Markdown转PDF: 将Markdown格式的文本转换为PDF。 安全与权限 数据安全是Stirling-PDF关注的重点，提供多种安全措施： ...

近年来，随着机器学习（ML）和人工智能（AI）领域的飞速发展，关于“ML是否需要一门新的编程语言”的讨论日益激烈。由LLVM和Swift语言的创造者Chris Lattner主导开发的Mojo语言，正是在这一背景下应运而生，旨在解决Python在高性能计算方面的局限性。然而，Mojo的出现也引发了社区对现有Python生态系统、其他竞争语言（如Julia）以及新语言推广策略的广泛讨论。 Python的统治地位及其根源 当前，Python无疑是ML领域的主导语言。评论中普遍认为，Python的成功并非源于其原生性能，而是其无与伦比的生态系统和作为“胶水语言”的强大能力。一位评论者指出，现代ML应用并非独立存在，它们是复杂的系统，需要数据ETL、信号/图像处理、优化、分布式计算、可视化和GUI等多种功能。Python凭借其丰富的库（如NumPy、PyTorch、JAX等）和强大的C/C++ FFI（外部函数接口），能够将性能关键部分委托给底层C/C++/FORTRAN实现，同时提供易于使用的上层抽象，满足了几乎所有这些需求。 从历史角度看，Python的崛起并非偶然。大约在2007-2009年，Matlab是深度学习研究的首选工具，但其高昂的许可费和局限性促使研究者寻找替代品。Python凭借已有的NumPy、Matplotlib等库，提供了与Matlab相似的数值计算环境，且更具灵活性。Theano和PyTorch等早期自动微分框架的出现，更是巩固了Python在ML领域的地位。因此，Python的生态系统是经过十余年积累和演化而形成的，其根基深厚，难以撼动。 “双语言问题”的挑战 尽管Python在ML领域占据主导，但其作为解释型语言的性能瓶颈始终是痛点。为了实现高性能计算，开发者常常需要在Python（用于高级逻辑和数据处理）和C++/CUDA（用于底层优化和GPU内核编程）之间切换，这被称为“双语言问题”。Mojo的创始人Chris Lattner及其团队正是希望通过Mojo来解决这一问题，目标是创建一门既能像Python一样易于编写，又能直接表达GPU内核并达到C++/Rust级别性能的语言。 然而，“双语言问题”的持久性也引发了深思。一位评论者指出，自他25年前开始编程以来，人们就一直在尝试解决“双语言问题”，但双语言解决方案反而变得更加普遍，从游戏到Web应用、ML、加密货币等领域无处不在。这可能因为许多问题领域天然适合双语言方案：一小部分密集计算任务需要极致性能，而大部分配置和数据处理任务则需要快速开发和高度灵活性。设计一门同时满足这两个极端需求的语言极具挑战。 Mojo的愿景与争议 Mojo的愿景是宏大的：成为一门兼具Python的易用性和C++/Rust的高性能，专为ML/AI设计的语言。它利用了先进的编译器技术（如LLVM MLIR），旨在实现从Python语法到硬件层面的无缝高效映射。Chris Lattner凭借其在LLVM、Swift和MLIR方面的卓越成就，为Mojo带来了极高的关注度。 然而，Mojo在发展过程中也面临诸多质疑和挑战： “Python超集”承诺的回溯: 早期Mojo曾被宣传为Python的超集，这意味着Python代码可以直接在Mojo中运行。但随着项目推进，这一目标被证明过于雄心勃勃。Chris Lattner本人也承认，初始的解释存在“过于乐观”的成分，且互联网将长期目标误读为短期目标。这种目标的调整，让一些开发者对Mojo的诚意和可信度产生了怀疑。 成熟度与功能缺失: 目前Mojo仍处于测试阶段，其通用编程能力尚未完善，例如对类的完整支持仍是中长期目标。语言的快速演变也使得对其进行投资存在风险。 生态系统与采用率: 尽管Mojo发布已有一段时间，但其采用率远低于PyTorch或Julia。社区认为，缺乏Windows支持、非完全开源的现状（尽管Chris承诺未来会完全开源）以及一个强大的框架支持，都阻碍了Mojo的广泛采用。 许可证疑虑: Mojo由一家公司（Modular）控制，这引发了关于其未来许可证策略的担忧。一些评论者担心Mojo可能会重蹈Java被Oracle“劫持”的覆辙，或者在获得市场份额后改变许可证条款，从而损害开发者利益。虽然Chris Lattner解释说分阶段开源是为了在早期阶段更好地控制项目方向，但这种担忧依然存在。 与其他解决方案的竞争: Julia: Julia被认为是Mojo的有力竞争者，它能够直接编写GPU内核，具备JIT编译能力，在科学计算和定制化ML方面表现出色。虽然其生态系统仍在发展，且存在“1.5语言问题”（高性能Julia代码可能不像“标准”Julia代码），但其作为“高层接口的底层语言”的潜力不容小觑。 现有Python工具: PyTorch、JAX和TensorFlow等框架已经集成了复杂的编译器，可以将计算图优化为GPU代码。Triton等Python API甚至允许开发者用Python编写高性能GPU内核。这些现有工具已经足够强大，以至于Mojo是否能带来足以颠覆现有格局的性能提升，仍是未知数。 编程语言选择的深层思考 Mojo的案例也促使人们重新思考编程语言选择的更深层次问题。 新语言与库的权衡: 何时需要一门全新的语言，而不是通过改进现有库来解决问题？评论认为，当语义层面存在根本性差异，无法通过库来实现时，新语言才有其存在的价值（如Rust之于C++，Julia之于Python）。对于Mojo，一些人质疑其带来的新特性是否足以超越Python库的改进潜力。 社区与开放性: 社区规模、开放源码策略以及项目治理模式，对新语言的成功至关重要。一个由单一公司控制的语言，即使技术再创新，也可能因为缺乏社区信任而难以获得广泛采用。 Chris Lattner的过往经验: Chris Lattner在Swift项目中的经验也成为Mojo的考量因素。Swift虽然在Apple生态系统中取得了成功，但其编译速度慢、错误信息模糊等问题也让一些开发者望而却步。Chris表示Mojo从Swift的错误中吸取了教训，特别是在类型检查性能方面。 结论 机器学习领域对高性能计算的需求日益增长，Python在生态系统上的优势与性能上的劣势并存，“双语言问题”长期存在。Mojo作为Chris Lattner的最新尝试，旨在通过一门兼具Python易用性和底层性能的语言来解决这一痛点。 然而，Mojo的未来发展充满不确定性。它需要克服来自根深蒂固的Python生态、日益成熟的Julia以及现有高性能Python工具链的竞争。同时，Mojo还需要赢得开发者的信任，明确其开源路线图，并在语言特性和稳定性方面持续进步。 ML领域是否真的需要一门全新的编程语言？或者说，现有的语言生态系统能否通过持续的演进和创新来满足未来的需求？Mojo的旅程，无疑为我们提供了一个观察和思考这些问题的绝佳视角。

Wazuh是一个免费且开源的安全平台，旨在提供全面的威胁预防、检测和响应能力。它能够为各种环境中的工作负载提供统一的扩展检测与响应（XDR）和安全信息与事件管理（SIEM）保护，涵盖本地部署、虚拟化、容器化以及云端环境。 Wazuh解决方案的核心由两部分组成：部署在受监控系统上的终端安全代理（Agent）和负责收集及分析代理所获取数据的管理服务器。此外，Wazuh与Elastic Stack进行了深度集成，提供了一个强大的搜索引擎和数据可视化工具，使用户能够方便地浏览和分析其安全警报。 Wazuh核心功能 Wazuh解决方案提供了多项关键功能，以应对当前复杂的网络安全挑战： 入侵检测 Wazuh代理会扫描受监控系统，以查找恶意软件、Rootkit和可疑异常，例如隐藏文件、伪装进程或未注册的网络监听器，以及系统调用响应中的不一致性。 除了代理的能力外，服务器组件还采用基于签名的入侵检测方法，利用其正则表达式引擎分析收集到的日志数据，以识别潜在的入侵指标。 日志数据分析 Wazuh代理负责读取操作系统和应用程序的日志，并将其安全地转发到一个中央管理服务器进行基于规则的分析和存储。在没有部署代理的情况下，服务器也能通过Syslog从网络设备或应用程序接收数据。 Wazuh的规则有助于用户及时了解应用程序或系统错误、配置错误、尝试或成功的恶意活动、策略违规以及各种其他安全和操作问题。 文件完整性监控 Wazuh持续监控文件系统，识别用户需要关注的文件在内容、权限、所有权和属性上的变化。此外，它还能本地识别用于创建或修改文件的用户和应用程序。 文件完整性监控功能可以与威胁情报结合使用，以识别威胁或受损主机。同时，多项法规遵从标准，如PCI DSS，都要求具备此功能。 漏洞检测 Wazuh代理收集软件清单数据，并将这些信息发送到服务器。服务器随后将这些数据与持续更新的通用漏洞披露（CVE）数据库进行关联，从而识别已知的易受攻击软件。 自动化的漏洞评估有助于用户发现关键资产中的薄弱环节，并在攻击者利用这些漏洞破坏业务或窃取机密数据之前采取纠正措施。 配置评估 Wazuh监控系统和应用程序的配置设置，以确保它们符合您的安全策略、标准和/或加固指南。代理会执行定期扫描，以检测已知易受攻击、未打补丁或配置不安全的应用程序。 此外，配置检查可以进行定制，以更好地与组织对齐。警报中包含改进配置的建议、参考资料以及与法规遵从的映射。 事件响应 Wazuh提供开箱即用的主动响应功能，能够在满足特定条件时执行各种应对措施，例如阻止威胁源访问系统。 Wazuh还可用于远程运行命令或系统查询，识别入侵指标（IOC），并协助执行其他实时取证或事件响应任务。 合规性管理 Wazuh提供了成为符合行业标准和法规所需的部分安全控制。这些功能，结合其可扩展性和多平台支持，帮助组织满足技术合规性要求。 Wazuh被支付处理公司和金融机构广泛使用，以满足PCI DSS（支付卡行业数据安全标准）的要求。其Web用户界面提供报告和仪表板，可以帮助满足PCI DSS以及其他法规（例如GPG13或GDPR）的要求。 云安全 Wazuh通过集成模块在API层面监控云基础设施，这些模块能够从知名的云提供商（如亚马逊AWS、Azure或谷歌云）拉取安全数据。此外，Wazuh还提供规则来评估云环境的配置，轻松发现弱点。 Wazuh轻量级、多平台的代理也常用于在实例层面监控云环境。 容器安全 Wazuh为Docker主机和容器提供安全可见性，监控它们的行为并检测威胁、漏洞和异常。Wazuh代理与Docker引擎原生集成，允许用户监控镜像、卷、网络设置和运行中的容器。 Wazuh持续收集和分析详细的运行时信息，例如对以特权模式运行的容器、易受攻击的应用程序、容器中运行的Shell、持久卷或镜像的变化以及其他可能的威胁发出警报。 Wazuh 用户界面 (WUI) Wazuh的用户界面（WUI）提供了一个强大的可视化工具，用于数据呈现和深入分析。此界面还可用于管理Wazuh的各项配置并监控其运行状态。通过直观的仪表板和报告，用户可以全面掌握安全态势，快速响应潜在威胁。 自动化与编排 为了简化Wazuh的部署和管理，Wazuh团队提供了一系列自动化工具。这些工具支持与主流的云平台、容器化技术以及配置管理系统集成，帮助用户实现基础设施即代码，从而提高部署效率和管理一致性。 社区与参与 Wazuh拥有一个活跃且不断壮大的社区。用户可以通过加入Wazuh社区与其他用户交流经验、参与讨论，并与开发人员直接沟通，共同为项目贡献力量。 如果您希望为Wazuh项目做出贡献，我们欢迎您提交拉取请求、报告问题或发送提交。我们将会审阅您的所有反馈和问题。您还可以加入我们的Slack社区频道或邮件列表，与其他成员交流并保持对Wazuh最新动态、版本发布和技术文章的关注。 Wazuh项目版权归Wazuh Inc.所有，并基于Daniel Cid启动的OSSEC项目开发。 查看更多详情

FinGPT：革新金融领域的开源大语言模型 在人工智能飞速发展的今天，大型语言模型（LLMs）正逐步渗透到各行各业。金融科技（FinTech）领域也不例外，对能够理解和处理复杂金融数据的LLMs有着巨大需求。然而，华尔街的机构通常不会开源其专有的大语言模型或开放API，这使得中小企业和研究机构难以接触到顶级的金融AI能力。正是在这样的背景下，FinGPT项目应运而生，旨在通过开源的方式，彻底改变金融大语言模型的格局。 FinGPT是一个致力于开发开源金融大语言模型的项目，它不仅发布了经过训练的模型在HuggingFace上，还提供了一整套解决方案，以实现金融领域的人工智能民主化。 FinGPT为何脱颖而出？ FinGPT的出现并非偶然，它精准地解决了当前金融AI领域的几个核心痛点： 动态金融环境下的高效适应性：金融市场瞬息万变，数据更新速度极快。像BloombergGPT这样的大模型，训练一次耗资约300万美元，耗时约53天。每月或每周重新训练这样的模型是极其昂贵的。FinGPT采用轻量级适应策略，能够迅速整合新数据进行微调，将每次微调的成本显著降低至300美元以下，这使得模型能够及时响应市场变化。 互联网级金融数据的普惠化：BloombergGPT拥有特权数据访问和API，而FinGPT则致力于使互联网规模的金融数据更易获取。通过自动化数据整理管道，FinGPT实现了模型的及时更新（例如每月或每周更新），利用最优秀的开源LLMs提供了一个更具可访问性的替代方案。 融入RLHF，实现个性化服务：BloombergGPT缺乏“人类反馈强化学习”（RLHF）技术，而这正是ChatGPT和GPT-4成功的“秘密武器”。RLHF使LLM模型能够学习个人偏好，如风险承受能力、投资习惯等，从而提供个性化的智能投顾服务。FinGPT将RLHF纳入其核心技术，为实现高度定制化的金融咨询服务奠定了基础。 最新进展速览 FinGPT项目自发布以来，持续取得显著进展，不断丰富其功能和生态系统： FinGPT-Forecaster发布：2023年11月，FinGPT-Forecaster正式推出，这是AI智能投顾发展的重要里程碑。用户可以在HuggingFace Spaces上体验其演示，获取个股分析和未来一周股价预测。 多项研究论文被顶会接受：FinGPT在2023年10月和7月有多篇关于指令微调、数据民主化和检索增强型LLMs的论文被NeurIPS和IJCAI FinLLM等顶级会议和研讨会接受，证明了其研究的领先性。 多任务金融LLMs和情感分析模型发布：FinGPT持续在HuggingFace上发布经过微调的金融多任务LLMs和专门的金融情感分析模型，为开发者和研究人员提供强大的工具。 FinGPT核心演示与性能 FinGPT提供了一系列强大的功能演示，尤其在金融情感分析领域表现卓越： 金融情感分析的领先表现 FinGPT V3系列模型通过使用LoRA方法对新闻和推文情感分析数据集进行微调，在单张RTX 3090显卡上即可实现最佳可训练和可推理的性能。其在多个金融情感分析数据集上的表现甚至超越了GPT-4和ChatGPT微调模型，同时成本极低。 加权F1分数 FPB FiQA-SA TFNS NWGI 设备 时间 成本 FinGPT v3.3 0.882 0.874 0.903 0.643 1 × RTX 3090 17.25小时 $17.25 OpenAI Fine-tune 0.878 0.887 0.883 - - - - GPT-4 0.833 0.630 0.808 - - - - BloombergGPT 0.511 0.751 - - 512 × A100 53天 $2.67百万 成本效益：FinGPT的微调成本远低于商业模型。例如，BloombergGPT的估计成本高达267万美元，而FinGPT V3.3在RTX 3090上的训练成本仅为17.25美元，展现了无与伦比的成本优势。 ...

将认知负荷卸载给大型语言模型（LLMs）所带来的即时舒适感，从长远来看，可能对我们并非全然是好事。认知负荷本应存在，如果过度削减，甚至停止思考，我们实际上可能会逐渐丧失独立思考和解决问题的能力。 这种情况在日常生活中屡见不鲜。例如，那些总是选择捷径、抄袭作业的学生，最终往往会对学校所学一无所知。又如，一个习惯将所有账单和银行事务交给配偶处理的人，有朝一日可能连简单的支付都无法独立完成。而一个从不费心记住街道名称或路线的人，一旦手机没电，便会感到迷失，甚至不知如何回家。 这与纳西姆·塔勒布（Nassim Taleb）在其富有洞见的著作《反脆弱》（Antifragile）中探讨的“顺应性”（hormesis）理论不谋而合。该理论的核心思想是，适量的压力或不适，反而能使我们变得更强大、更有韧性。 肌肉通过举重训练而增长。 免疫力通过适度暴露于病原体而建立。 自信通过承担风险而增强。 技能通过反复练习而磨砺。 创造力通过解决难题而拓展。 心智的运作机制亦是如此。思考过程中遇到的摩擦，寻找恰当词语时的笨拙挣扎，这正是我们进行“精神举重”的方式。这种认知努力对于大脑的成长和维持至关重要。 或许可以引入一个稍有不同但精神内核相似的例子——“破窗理论”。该理论指出，可见的混乱迹象，如涂鸦、垃圾或破损的窗户，会传递出一种被忽视和容忍的信号，从而削弱非正式的社会控制，并进一步诱发不当行为乃至严重的犯罪。换言之，小裂缝若不及时修补，最终可能演变为巨大的断层。对大型语言模型的持续依赖，有可能将我们推向更深的深渊，直到我们把所有的思考都外包出去，最终沦为徒有其表的生物傀儡。 近期的一项研究为此提供了实证支持。在这项实验中，参与者被分为三组： 纯脑力组：不借助任何辅助，独立撰写文章。 搜索引擎组：使用谷歌搜索引擎辅助写作。 大型语言模型（LLM）组：完全依赖ChatGPT撰写文章。 研究结果引人深思： 在LLM组中，高达83%的参与者在写作后不久无法引用自己文章中的任何内容，而其他两组的参与者几乎都能做到这一点，显示出记忆保持能力的显著差异。 那些从LLM辅助写作转向独立写作的参与者，其大脑的神经活动显著减少，并持续处于低度参与状态，表明长期依赖可能改变大脑的工作模式。 相比之下，从纯脑力组转向使用LLM的参与者，却保持了强大的记忆回溯能力，并表现出与搜索引擎组相似的神经激活模式，这暗示着先前的独立思考习惯对认知功能有保护作用。 研究者们为此创造了“认知负债”（cognitive debt）一词来描述这种权衡：人工智能辅助带来的即时便利，可能以牺牲长期认知能力为代价，例如批判性思维、记忆力和创造性自主权。这就像你从机器借用了精神能量，但需要支付利息——当你的自身思考能力削弱时，这种代价就会在日后悄然显现。 我常常告诫我的孩子们：大型语言模型固然是强大的工具，但务必明智使用。不要让它直接为你解决数学问题；相反，先给出你自己的解决方案，然后让它解释你可能出错的地方。从独立思考开始，再结合人工智能进行验证和完善，将更有益于认知发展。这就像核能一样——你可以将其用于大规模杀伤，也可以作为清洁的动力来源。关键在于如何运用。 持续依赖AI工具可能会削弱我们的学习、记忆和创造力。不适感绝非仅仅是烦恼，它更是一个磨砺心智、提升能力的训练场。 因此，我们应当主动寻求不适，拥抱挑战，并鼓励自己在面对认知摩擦时坚持下去。

在容器化技术日益普及的今天，Docker无疑是行业的先行者，其“一次构建，随处运行”的理念深刻改变了应用开发与部署方式。然而，随着时间的推移和对系统架构更深入的理解，许多开发者开始重新审视Docker的核心设计，特别是其常驻的dockerd守护进程。本文将探讨从Docker转向Podman的原因、Podman的独特优势，以及如何无缝完成这一转换。 早期容器化体验与思考 许多资深开发者都曾经历过Vagrant带来的便利，它承诺统一开发环境，解决了语言版本和操作系统差异带来的调试难题。随后，Docker的出现更是引发了革命性的变革。Docker不仅仅是一个工具，它从根本上改变了我们对应用程序开发和部署的看法。拥有一个可重复、与本地系统隔离的环境，令人耳目一新，仿佛获得了超能力。“只需Docker化”一度成为解决各种问题的万能方案。 然而，随着容器技术的发展和安全意识的提升，人们开始质疑“习以为常”的模式。Docker在后台以root权限运行的常驻守护进程，逐渐从一个“舒适的常数”变成了一个潜在的“定时炸弹”。近年来，一系列安全漏洞浮出水面，进一步加剧了这种担忧： 2019-02-11 - CVE-2019-5736 (runC容器逃逸)：允许容器中的进程覆盖主机的runC二进制文件，一旦被利用，可能导致整个主机被攻陷。 2022-03-07 - CVE-2022-0847 “Dirty Pipe” (Linux内核)：Linux内核中的只读文件覆盖漏洞，Docker/Sysdig记录了实际的容器到主机滥用场景。 2022-03-07 - CVE-2022-0492 (cgroups v1 release_agent)：通过cgroups v1进行特权升级/容器逃逸；可通过seccomp/AppArmor/SELinux进行缓解。 2024-01-31 - CVE-2024-21626 (runC “Leaky Vessels”)：fd泄漏 + process.cwd问题，可能导致主机文件系统访问和潜在的逃逸；已在runC 1.1.12 (Docker Engine ≥ 25.0.2)中修复。 2024-02-01 - CVE-2024-23651/23652/23653 (BuildKit, “Leaky Vessels”)：构建时问题，可能影响主机文件；已在BuildKit 0.12.5中修复。 2024-09-23 - 野外加密劫持活动：攻击者利用暴露的Docker API和微服务进行攻击。 2024-10-01 - Docker API swarm僵尸网络活动：通过暴露的Docker Engine API进行加密劫持。 面对这些安全挑战，许多人开始寻找替代方案，Podman便是在这样的背景下进入了大众视野。 守护进程：Docker与Podman的根本区别 Docker的核心架构围绕着一个持久的后台服务——dockerd守护进程。用户执行的每一个docker命令，实际上都是与这个守护进程进行通信，由它来完成容器的创建、运行和管理等繁重工作。 然而，这个守护进程总是以root权限运行。这意味着，一旦守护进程出现问题（无论是无意的bug、崩溃，还是最糟糕的安全漏洞），整个容器生态系统甚至主机系统都可能面临被完全攻陷的风险。 Podman则彻底摒弃了这种模型。它没有守护进程，后台也没有常驻进程。当您运行podman run my-app时，容器直接成为您命令的子进程，并以您的用户权限运行。这种看似简单的架构改变，却带来了巨大的影响： 更合理的安全性 还记得那些关于Docker守护进程漏洞的深夜安全通告吗（例如，当dockerd被错误配置为在没有TLS的情况下监听TCP:2375时，攻击者可以远程启动特权容器）？使用Podman，即使攻击者设法在容器内部将权限提升到root级别，他们在实际主机上仍然只是一个非特权用户。这显著减小了攻击面。 不再存在单点故障 通常情况下，Docker守护进程运行良好。但一旦出现故障，它可能会导致多个容器同时停止运行。Podman则不同，当一个容器崩溃时，其他容器会像什么都没发生一样继续运行。这符合密封化（hermetization）的理念，使得系统更加健壮。 更轻的资源占用 没有常驻守护进程意味着更少的内存使用。Docker守护进程有时会消耗相当的系统资源，导致笔记本电脑等设备在闲置时发热。虽然Podman在某些平台（如MacBook M2 Pro结合Rosetta）上的容器运行可能仍需优化，但其整体资源足迹通常更轻量化。 Podman的亮点特性 除了守护进程的优势，Podman还提供了一些巧妙的功能，让日常容器工作更加便捷： 出色的Systemd集成：对于在Linux服务器上工作的用户而言，Podman能够生成符合标准的systemd单元文件。这意味着您的容器可以作为Linux服务生态系统中的一等公民，享受启动依赖、自动重启、资源限制等功能。您可以使用podman generate systemd --name my-app生成服务文件，然后通过标准的systemctl命令进行启用、启动、停止和监控，无需依赖第三方进程管理器。 ...