作者：Manjunath Janardhan 译者：Carl Cui 通常，本地部署 LLM 时需要给 LLM 找一个配置足够好的机器，那么有没有办法反其道而行之？如果你有一堆闲置的设备，能不能把它们的 CPU, GPU 和内存资源整合起来，运行一个它们单独无法处理的模型？作者 Manjunath Janardhan 借助开源工具 exo 在自己的两台 Mac 设备上把 Qwen3-Next-80B 运行了起来，可以达到每秒 70 ~ 80 个 token。 Mac Mini 的设置和负载快照，图片由 Manjunath Janardhan 制作 1. exo 是什么 exo 是一个由 Exo Labs 维护的开源项目，一句话概括：它将你所有的设备连接成个人 AI 集群，让你能够运行任何单台机器都无法容纳的模型。exo 的主要功能如下： 自动设备发现 - 运行 exo 的设备可以在网络上自动相互发现，无需手动配置 支持基于 Thunderbolt 的 RDMA - 在支持的硬件（M4 Pro/Max）上，能够在设备之间实现 99%的延迟降低 拓扑感知自动并行 - exo 根据可用 RAM、CPU、GPU 资源以及节点之间的网络延迟，确定将模型在多个设备之间分割的最佳方式 Tensor 并行 - exo 支持模型分片，在 2 台设备上可加速 1.8 倍，在 4 台设备上可加速 3.2 倍 MLX 支持 - exo 使用 MLX 作为推理后端，并使用 MLX 分布式 进行分布式通信 多 API 兼容性 - 兼容 OpenAI Chat Completions API、Claude Messages API、OpenAI Responses API 和 Ollama API，现有的工具和客户端可以无缝迁移 自定义模型支持 - 从 HuggingFace hub 加载自定义模型，以扩展可用模型范围 支持 54+ 个模型 - 从小型 Llama 模型到 671B DeepSeek 变体 2. Mac Mini M4 + MacBook Pro M4 Max 通过 exo，我配对了两台机器： ...

作者：MayhemCode 译者：Carl Cui 今天这篇文章是搬运过来的，发表于 2025 年 12 月 17 日，那时候由 AI 引发的硬件通胀已经持续了几个月。到现在，2026 年 3 月底，消费级硬件的价格不仅没有回落，反而在全面涨价的基础上看不到回调的希望。虽然内存价格出现了小幅回调，但是相比 2025 年 9 月，现在的内存价格依然处于历史极高水平：2025 年 9 月份，一根 16G 的 DDR5 台式机内存价格大概在 200 ~ 390 元，现在大约需要 1100 ~ 1600 元。OpenClaw 的火爆，进一步推动了本地部署 LLM 的需求，对于“不想交数据、不想交钱，或者不想等网络”的那群人，本地部署 LLM 永远是一个绕不开的话题。 1. 为什么自托管 AI 是未来 完全依赖云 API 才能使用 AI 的“苦”日子正在结束。以前每月需要 100 美元的 ChatGPT 或 Claude 订阅现在可以在你自己的硬件上运行。本地部署 LLM 可以带来更好的隐私保护、零持续成本，和对模型的完全控制。 现在开源的大语言模型，特别是 Llama 3、DeepSeek R1 和 Mistral，已经足够处理真实工作。问题在于，你需要知道哪些硬件能把它们跑起来。这篇文章教大家怎么选择高性价比硬件，不管你准备搭建预算有限的家庭实验室还是高性能的 Proxmox 服务器。 译者注：2025 年 12 月到现在，硬件和 LLM 已经出现了很多变化，文章部分内容稍显过时，推荐的配置也是基于当时国外的行情，不过对 LLM 硬件的讲解比较全面，值得一读。 ...

之前写过一篇名为 IronClaw 安全机制解析 的文章，简单介绍了 IronClaw 的安全机制。当时 IronClaw 还处在 v0.18.0 版本，在它支持的 LLM 列表里只有 DeepSeek 一家是国内的（见下图）。写这篇文章的时候，IronClaw 来到了 v0.21.0 版本。 分析项目提交历史，从 0.18.0 到 0.21.0，IronClaw 这 4 个版本是在 9 天内陆续发布的，项目处在一个加速迭代的过程中。 除了持续的安全加固，IronClaw 扩展性也在增强，其中 v0.19.0 版本新增了两家 LLM 提供商，Z.AI 和 MiniMax，这两家都来自国内。因为看到 IronClaw 支持了 Z.AI，加上智谱会给国内新注册用户赠送资源包，本着免费至上的精神，抱着白嫖的态度，我开始了折腾，目标是搞一个接入 GLM 模型的 AI 助手，辅助处理一些琐碎杂务。 然后就开始一路踩坑，一直忙到凌晨才柳暗花明。这篇文章记录一下主要过程，略去了走过的一些弯路。 1. 我以为很简单，直接就能搞定 IronClaw 在 v0.19.0 支持的 Z.AI 是智谱 AI 国际版本的 API，要在 https://z.ai/manage-apikey/apikey-list 申请 API Key。 智谱 AI 国际版本网站打开就是“暗系装修风格”，直到现在我也没找到切换开关，基本可以确定网站只有一种风格。网站整体 UI 设计（下图），给我感觉就是两个字：简陋。或者说简约，😓。注册之后没有找到赠送的资源包，最低档套餐需要付费。收费加简陋，我一度以为自己进到了“钓鱼网站”。在用 AI 可以很轻易生成现代站点的今天，不敢相信这是一家 LLM 模型公司的站点。 小心谨慎地申请好 API Key，本地编译 IronClaw，配置智谱 AI 国际版本的 API，然后运行 IronClaw，最后通过 IronClaw 自带的 Gateway 页面对话，一切顺利。 ...

作者：Tanmay Bansal 译者：Carl Cui 译者之前翻译整理过 Wes McKinney 一篇 关于 AI Agent 的文章。和 Wes McKinney 那篇相比，Tanmay Bansal 这篇文章的思考深度差了不少。Wes 用了具体的代码库规模数据、自己的亲身经历、以及《人月神话》的理论来支撑其论点；而这篇文章更像是把流行观点重新包装了一遍。译者会在结尾第 9 节讨论这篇文章深度不足的地方。以下开始至第 8 节是文章内容。 大多数人认为 AI 将取代程序员、设计师和作家。这种说法有失偏颇。第一批悄然消失的工作更容易预测，而且隐蔽性很强。一不留神，你现在可能就在做着这样的工作。 这不是一个关于未来的理论警告。这已经在发生了，只是你还没有注意到。 1. 普遍观点 随便刷刷哪个技术论坛或者社交动态，都能感觉到那种恐惧。大家都觉得语言模型和 coding copilot 的到来，意味着工程部门和创新部门要被取代了。人们看到 AI 能写出过得去的代码，或者能生成文章，立刻就得出结论：那些正在做这些事情的人已经过时了。 表面上看这说得通：我们看到一台机器输出文字，就把它和“作家”这个职位联系起来；我们看到它输出一个 React 组件，就把它和“开发者”联系起来。 但这忽略了 AI 在现实世界中的实际应用情况。 2. 真实规律 这里的核心观点：人工智能取代的不是工作，而是取代那些可预测、可重复、也容易评估的任务。 The upcoming job scenario with AI: Image by Tanmay Bansal 仔细看看软件行业和现代知识密集型工作，你会发现其中有很多工作的产出其实只是把一些高度可预测的输出拼接了起来。这正是自动化首先冲击的领域。 3. 实际上正在被取代的工作 让我们分析一下那些正在悄然消失的工作类别。 3.1 中间层知识工作 想想那些纯粹为了喂算法或填写公司报告而生成的海量内容：基础的 SEO 文章生成、每周指标的总结，或是初级市场研究报告的汇总。 我自己管理着一份技术简报，从数据中可以看到：读者渴望独特的洞见，但网络上充斥着泛泛的总结。那些专门生产这些泛泛总结的工作，其产出高度结构化且易于验证，正在迅速减少。 3.2 协调与“胶水“角色 企业环境中充斥着纯粹用于将信息从 A 点传送到 B 点的角色。例如，做会议记录、根据 Slack 线程更新 Jira 工单、为高层管理人员格式化状态报告以及起草内部沟通摘要。 ...

作者：Wes McKinney 译者：Carl Cui 作者 Wes McKinney 是专注于分析计算领域的工程师和创业者，pandas 的创始人，《Python for Data Analysis》的作者。曾创立 Voltron Data 和 Ursa Labs，现任 Posit 首席架构师。作者的这篇文章从《人月神话》的核心观点出发，讨论了 AI Agent 给软件工程所带来的影响。 和很多人一样，我发现 AI 严重影响了我的睡眠。以前我会在凌晨四点或四点半短暂醒来喝口水或上个厕所，现在却很难再次入睡。以前我每晚能睡七八个小时，现在能睡六个小时就不错了。我基本上已经不再抗争了：现在当我在早上 5:07 辗转反侧，脑子里全是喂给 AI coding agent 的想法时，我就直接起床开始新的一天。 在我的工程师和数据科学家朋友圈里，大家都在讨论我们作为人类的竞争优势还能持续多久。当 agent 开始自己产生更好的想法时，拥有好想法（而且要多）还重要吗？现在感觉，人类专家的参与是从 agent 那里获得良好结果的必要条件。那这种状态，直到某个想法在我们睡觉时可以被 agent 转化为能运行、有品味的软件之前，还能持续多久？这是否会是一种温和淘汰，让我们愉快地交出控制权，还是别的什么？ 目前，我感觉自己还是被需要的。我不把自己现在这种工作方式描述为“vibe coding”，因为这听起来像是以一种贬义的“轻松搞定”的方式来构建 AI 垃圾软件项目。我一直在构建像 roborev 这样的工具，为我的并行 agent 会话带来严格性和持续监督，并对 agent 的工作进行严格审查。这种全新的工作方式让人不得不思考软件工程的未来。 我职业生涯中引用最多的书大概是 Fred Brooks 的《人月神话》，其中著名的 Brooks 定律认为“向一个已经延期的软件项目增加人手只会让它更晚”。最近我发现自己在思考这本书的教训是否适用于这个 agentic 开发的新时代。一个才华横溢的开发者指挥一群 AI agents，能否更快更好地构建复杂软件？短期的生产力提升是否会带来长期的项目成功？还是我们会遇到同样的问题？范围蔓延 scope creep、架构漂移 architectural drift 和沟通成本 coordination overhead，这些已经困扰软件团队几十年的问题。 1. 重读《人月神话》 Brooks 的核心论点之一是：少数精英组成的小团队胜过大量普通人组成的大团队。这能使得系统设计具有高度的概念完整性，就好像“一个人设计了它，即使是很多人参与了构建”。 Agentic 工程似乎放大了这些问题，因为其所构建软件的质量仅取决于参与其中的人类的水平：他们负责策划和完善 spec、对功能说“是或否”，以及控制不必要的代码和架构复杂性。《人月神话》中的一个比喻是“泥潭”：“每个人都能看到野兽在里面挣扎，看起来任何一只都能轻易逃脱，但泥潭把它们都困住了。”现在，我们有了一个新的“泥潭”，“agentic 泥潭”，我们的并行 Claude Code 会话和 git worktree 需要应付虚拟同事导致的代码膨胀和偶然复杂性。你可以系统地重构，但 agentic 代码库不可避免地会比任何人工构建的更大、更臃肿。这是前所未有的技术债务，以机器的速度累积。 ...

作者：Dean Wampler 译者：Carl Cui 1998 年，LAMP 的出现第一次清晰描述了用于构建网站的主要开源软件，也让无数开发者找到了构建 Web 应用的共同语言。二十多年后，生成式 AI 的浪潮同样呼唤一套属于这个时代的标准答案，PARK 栈由此而来。作者 Dean Wampler 在这篇文章中为我们展现了 AI 时代开源“风景”，更难得的是，作者在文章穿插了大量引用，方便感兴趣的读者继续探索。 1. 背景：LAMP 技术栈 根据 Wikipedia，LAMP 技术栈这个缩写是由 Michael Kunze 于 1998 年提出的，用于描述当时流行的用于构建网站的开源软件组合。在 20 世纪 90 年代初，随着万维网（WWW）的普及，各大组织使用各种专有工具和操作系统，外加一些开源软件（OSS - open source software）来构建网站。LAMP 技术栈迅速成为最受欢迎的开源组件集合。 LAMP 是一个缩写词，分别代表以下内容： 字母 组件 职责 L Linux 操作系统 A Apache HTTP Server 网络服务器 M MySQL 数据库 P Perl、PHP 和/或 Python 应用程序编程语言 在当时，依赖开源软件的想法是有争议的。因为源代码对所有人可见，人们担心缺乏支持和存在软件漏洞，最终这些问题解决了。开源之所以具有不可抗拒的吸引力，是因为流行的 OSS 项目提供了极大的灵活性、成本效益、无供应商锁定以及快速迭代。LAMP 堆栈成为企业采用开源的主要驱动力之一。 2. PARK 技术栈 就像互联网的兴起一样，大型语言模型（LLMs）、视觉模型（VMs）和其他生成式 AI 的突然爆发，促使人们去识别最适合生成式 AI 的 OSS 组件。这个时代出现了 PARK 技术栈。它是由 Ben Lorica 去年 11 月在文章 Trends Shaping the Future of AI Infrastructure 中首次提出的。 ...

作者：Kesha Williams 译者：Carl Cui 译者之前写了篇介绍 OpenClaw 的文章：不一样的 OpenClaw，简述了 OpenClaw 这个项目的来龙去脉，并从安全角度讨论了这个明星项目面临的现实问题。随后译者看到了 Kesha Williams 这篇文章，她思考了 OpenClaw 的火爆给 AI Agent 发展带来的启示，值得我们参考，以下是整理翻译后的内容。 1. 自主 AI 并非新事物 OpenClaw 的异军突起感觉与 2023 年 4 月 AutoGPT 横空出世时相似。那时候它也和现在一样，在 GitHub 上迅速走红，承诺能实现 AI 的自主。但实际情况是，那些 agents 陷入了死循环，经常产生幻觉，还造成了高昂的 token 成本。没过多久，人们就纷纷放弃了。 OpenClaw 有一个关键优势：模型变得更好了。最近的 LLM（如 Claude Opus 4.6 和 GPT-5.4）允许模型将各种工具串联起来、从错误中恢复，并规划多步骤策略。OpenClaw 项目既得益于设计，也得益于时机。 OpenClaw 的架构故意保持简单。没有矢量数据库，也没有多 agent 编排框架。Persistent memory 就是磁盘上的 Markdown 文件。让我重复一遍：Persistent memory 就是磁盘上的 Markdown 文件！这个 agent 可以读取昨天的笔记，并在自己的文件中搜索额外的上下文。你可以根据需要查看和编辑 agent 的文件。这其中有一个有用的经验教训：并非每个 agent system 都需要复杂的 memory 策略。更重要的是你理解 agent 在做什么，并且它能够在多次运行中保持上下文。 ...

作者：Tim O’Reilly 译者：Carl Cui 这篇文章源自 O’Reilly 的 Tim O’Reilly 与 Google AI 专家 Addy Osmani 在 2026 年 2 月的一场深度访谈。Addy Osmani 在谷歌领导 Chrome 浏览器的开发者体验团队长达 14 年之久，最近转到谷歌云人工智能公司，专注于 Gemini 和 agent 开发。作者 Tim O’Reilly 的这篇概括性文章可以帮助 AI 时代的开发者更好地区分现实和噪音。 1. 难点在于 agent 协调，而非内容生成 Addy 指出，目前人们使用 AI agent 的方式多种多样。一边是单人公司运行着成百上千个 agents，有时连代码都不会审查。另一边则是对质量门槛和可靠性有要求，需要考虑长期维护的企业。 Addy 的看法是，对于大多数企业来说，“真正的边界不一定是为了某个任务而拥有成百上千个 agents。关键在于协调一定数量的 agents，解决实际问题，同时保持控制和可追溯性”。他指出，像 Google Agent Development Kit 这样的框架现在可以在单个系统中同时支持 deterministic workflow agents 以及 dynamic LLM agents，这样你可以灵活地选择什么时候需要可预测性，什么时候需要便利性。 Agent 生态系统正在快速发展。A2A（由 Google 贡献给 Linux 基金会的 agent-to-agent 协议）处理 agent 之间的通信，而 MCP 处理 agent 对工具的调用。组合在一起，它们就像是 AI agent 时代的 TCP/IP。不过 Addy 认为：“几乎没有人想出如何让所有东西尽可能顺畅地协同工作。我们正尽可能地接近那个目标。而这才是这里的实际难题。不是生成，而是协调。” ...

在个人服务器上搭建网站，对于计划长期运行的站点，有一个问题是必须要考虑的，那就是站点的安全问题。这里介绍一些基本的防护手段。防护的核心原则是：在保持服务可访问的前提下，最大限度地缩小攻击面，并建立多层防御。 1. 核心端口功能与风险 通常 Web 服务器会开放 22/80/443 这三个端口，我们了解下每个端口的主要风险点： 22 (SSH)：管理的大门。主要风险是暴力破解和弱口令。一旦被攻破，服务器就易主了； 80/443 (Web)：服务的脸面。主要风险是Web应用漏洞（如SQL注入）、DDoS攻击和CC攻击； 所有端口：都存在基于软件漏洞的0-day攻击风险，以及系统配置不当带来的隐患； 2. 个人服务器分层防护 第一层：访问控制与最小化原则（最基础也最有效） 这部分是必须做的，能挡住绝大多数自动化攻击。 SSH 端口安全（关键！） 禁用密码登录，改用密钥对：这是最重要的一步。 密码很容易被暴力破解，而密钥对几乎无法被暴力枚举。 操作：修改 /etc/ssh/sshd_config，设置 PasswordAuthentication no。 更改默认端口（可选但推荐）： 将 SSH 服务从默认端口 22 改为一个高位端口（如2222）。 这并不能防住定向攻击，但能瞬间避开 99% 的自动化扫描和攻击脚本。 操作：修改 /etc/ssh/sshd_config，设置 Port 2222。 安装 Fail2ban：这是一个必备工具。 它会监控 SSH 日志，当发现同一个 IP 多次登录失败后，自动将其加入防火墙黑名单一段时间，能有效遏制暴力破解。 配置：重点监控SSH服务，设置合适的maxretry（重试次数）和bantime（封禁时间）。 防火墙配置 只开放必要端口：使用防火墙，只放行你需要对外提供的端口（80， 443， 22（或你修改后的 SSH 端口））。 通常，云服务提供商会提供默认的防火墙功能，通过云服务控制台即可完成配置。如果需要手动配置服务器防火墙（一般是 ufw 或者 firewalld），可以将默认策略配置为“DROP”，然后只放行需要对外提供的端口。命令示例（ufw）： sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw allow 2222/tcp # 假设SSH改到了2222端口 sudo ufw enable 注意：优先选择云服务厂商提供的防火墙，而非 ufw，具体原因下面会提到。 ...

为 hugo 站点设置默认主题后，需要在配置文件中对主题进行配置，以定制 hugo 站点显示内容。hugo 配置文件位于站点根目录下，可以是 hugo.toml, hugo.yaml， config.yaml 其中之一。hugo 可选的主题比较丰富，可以在 https://themes.gohugo.io/ 选择自己喜欢的主题。不同的 hugo 主题，对 content 目录下文章组织有不同的要求，并且配置选项也各不相同，配置时还需要参考主题各自的文档。 我的博客配置了 PaperMod 主题，这篇文章主要对该主题的初始配置做一个记录。 1. PaperMod 初始配置 为 hugo 站点下载 PaperMod 主题： # 将 PaperMod 项目设置为 git 仓库的子模块，并下载 PaperMod 主题 git submodule add --depth=1 \ https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod PaperMod 下载到 theme 目录后，将站点默认主题配置为 PaperMod，此时 hugo 配置文件如下： baseURL: "https://examplesite.com/" title: ExampleSite languageCode: 'us-en' theme: PaperMod 这样，hugo 站点已经具备了 PaperMod 主题的雏形，但是站点处于“毛坯”阶段，需要进行一定的“装修”。 注意：hugo 支持本地预览，主题配置过程中可以通过下面的命令实时查看站点“装修”效果： # -D include content marked as draft # --disableFastRender enables full re-renders on changes # --gc enable to run some cleanup tasks (remove unused cache files) after the build hugo server -D --disableFastRender --gc 2. PaperMod 进阶配置 2.1 一些简便的配置 参考 PaperMod 示例站点配置，以下是 hugo 配置文件中一些便利性的配置： ...