Tutorial

译者：Carl Cui 听着，我懂。在 2024 年，每个人都在购买云端 API token，好像它们即将过时一样。“哦，直接调用 API 就行！”他们说。“太方便了！”他们说。好吧，如果你在 2026 年还在按 token 付费，恭喜你，你很可能在为不拥有自己的 AI 技术栈而支付溢价。 让我告诉你一件事：本地 AI 不再是奢侈品，而是生存策略。读完这篇文章，你会确切知道该构建什么样的机器，既不会超出预算，也不会让你发疯。 第一部分：为什么选择本地 AI？ 在谈论 token 之前……先谈谈隐私 这里很少有人问的问题：你真的愿意把你的密码和信用卡信息交给某个第三方 API 吗？ 想想看。每次你通过云端调用 LLM 时，你都在信任： 你的数据会发送给陌生人（AI 公司） 你的提示词可能被保存为“机密” 你的 agent 记忆存储在你不控制的服务器上 最要命的是：你自己的 agent 记忆是关键。 当你运行本地 AI 时，你的 agent 会随着时间的推移构建上下文——它会记住你在意什么、你之前问过什么、什么对你重要。使用云端 API 时，除非你明确告诉它们要记住，否则这些历史记录通常分散在不同的服务中。 使用本地 AI： 你的记忆保持属于你（不是租来的） 不需要每个月“重置”你的 agent 上下文 敏感数据不会泄露，因为……嗯，它根本不会泄露到任何地方！它就在那里，在你的机器里 现在让我们谈谈实际成本。因为是的，隐私很重要——但钱也很重要。 这是 2024–2025 年没人告诉你的：按 token 定价是个陷阱。 而且从那以后情况变得更糟。 问题不仅仅是模型说得更多（它们确实如此——现代 agent 喜欢滔滔不绝）。而是 你既要为输入 token 付费，又要为输出 token 单独付费。 这意味着： ...

进入 2026 年，AI Agent 越来越频繁地出现在我们的视野里，那到底什么是 AI Agent？ 举个例子，3 月份爆火的 OpenClaw “小龙虾”，本质上是一个 AI Agent；开发人员最常用的 AI 辅助编程工具 Claude Code 和 Codex，本质上也是 AI Agent。OpenClaw 和 Claude Code 功能全面，代码量也庞大。这篇文章，我们会一步一步构建一个最小版本的编码 Agent，以此建立对 AI Agent 的直观感受。 1. 四步构建法 文章按照下面 4 个步骤来构建 agent： 接入 LLM； 添加工具； 构建 agent 循环； 构建对话循环； 不论实现的 agent 执行什么任务，都可以采用这样的 4 个步骤来构建。 2. 实现编码 Agent Agent 可以使用我们熟悉的任何语言来实现，例如 TypeScript，Python，Rust 等等，只要它接入 LLM 方便，可以调用 shell 命令工具就行。这里我们选择 Python。 完整的示例代码已经上传到 GitHub，链接在文章后面 2.0 项目设置 # 如果没有安装 uv，先安装它 pip install uv # 初始化 uv 环境 uv init 2.1 接入 LLM LLM 选择了 Kimi，Kimi 开放平台 注册的账号在完成个人认证后会收到 15¥ 赠送额度，拿来演示够用了。Kimi 开放平台兼容 OpenAI 协议，可以直接使用 OpenAI SDK 接入。 ...

作者：Bibek Poudel 译者：Carl Cui 如果你写的 skill 没有触发，问题基本上都出在元数据的 description 部分，而不在 skill 内容本身。 不少人都有类似的经历：写了一个 SKILL.md，将其放在正确的文件夹中，要求 agent 使用它，但是啥反应也没有。修改了 skill 内容，仍然没有效果。问题从来不是 skill 本身的内容，而是 agent 用来决定是否激活它开头的那两行。 在本指南中，我先讲解 Agent Skills 工作原理，指出为什么大多数人会写错，然后从简单到复杂构建四个 skill：一个 README 编写器、一个 git 提交消息生成器、一个代码审查器和一个完整的 MCP 驱动的冲刺规划器。 什么是 Agent Skill？ Skill 不是插件，也不是访问 API 的脚本。我们可以把它当作为团队新成员编写的入职指南。与其在每次跟 agent 对话时重新解释你的工作流程和偏好，不如将它们打包起来丢给 agent，让它根据你的请求自动加载。 本质上，skill 以一个文件夹的形式存在： your-skill-name/ ├── SKILL.md # 必需：指令 + 元数据 ├── scripts/ # 可选：agent 运行的可执行代码 ├── references/ # 可选：仅在需要时加载的文档 └── assets/ # 可选：模板、图片、字体 唯一必需的文件是 SKILL.md。其他所有内容都是可选的，但随着 skill 复杂度的增加而变得重要。 SKILL.md 格式是一个开放标准，由 Anthropic 于 2025 年 12 月在 agentskills.io 发布。它适用于 Claude Code、OpenAI Codex 和 OpenClaw。虽然格式是标准化的，但每个平台在发现和工具调用方面的实现略有不同。可以理解为同一编程语言，经过不同编译器编译后，结果不是完全相同的。在 Claude Code 上有效的 skill 很可能在 Codex 上也有效，但运行时行为（如 session snapshotting、工具权限和调用模式）在不同平台之间有所不同。 ...

IronClaw 在 0.25.0 版本解决了一系列与 OAuth 有关的 bug，配置好 Gmail 工具后，不会出现 OAuth 认证频繁失效的问题了。这篇文章记录为 IronClaw 配置 Gmail 工具的完整过程。 1. 背后的考量 1.1 为什么选择 IronClaw IronClaw 从设计之初对安全考虑的比较充分，采用了基于 wasm 组件的隔离机制（参考之前写过的名为 IronClaw 安全机制解析 的文章）。并且 IronClaw 采用 Rust 实现，Rust 是我个人长期关注的编程语言，尽管它的学习曲线陡峭是公认的，但在 debug 过各种“奇葩问题”，并且见过一些所谓资深程序员堆的“屎山”后，我才觉得 Rust 未来大有可为：不是因为人们津津乐道的“内存安全”，而是因为它在软件工程学方面向前迈了一大步。 AI 生成代码日益成熟，淡化了 Rust 在软件工程学方面的优势，不过同样地，学习曲线也不再成为采用 Rust 的主要障碍。 1.2 为什么接入 Gmail 而不是国内邮件厂商 对于经常混迹国外计算机技术网站、论坛的开发人员，Gmail 邮箱应该是必备的：基本所有网站，比如 Reddit、ChatGPT 都可以直接用 Gmail 账号登入；另外用国外邮箱接收国外各类技术订阅邮件也会很方便。 1.3 如何在接入 AI 助手的同时，保护个人信息 到目前为止，我个人常用的 Gmail 邮箱中除了越来越多的技术订阅邮件，还有个人信息混杂其中。我想让 AI 助手帮忙整理分析技术订阅邮件，又不想让它接触含个人信息，怎么办？ 我的做法是：新建一个 Gmail 邮箱，在常用 Gmail 邮箱中添加邮件过滤规则，将满足规则的邮件转发给新建的 Gmail 邮箱，把新建的 Gmail 邮箱丢给 IronClaw。只要规则设置得当，就不用担心 IronClaw 背后的 LLM 触及个人敏感信息。 ...

IronClaw 采用 wasm 沙箱隔离作为其安全机制，IronClaw 宿主和沙箱之间的交互接口是在 .wit 文件中定义的，例如 channel.wit of IronClaw。 这篇文章回答一个问题：如何基于定义好的 wit 文件生成 rust 代码？ wit-bindgen 是 Bytecode Alliance 开发的官方工具，它能将 .wit 文件中定义的接口转换为 Rust 代码。它主要有两种使用方式： 在 build.rs 构建脚本中使用命令行工具 或在代码中使用 wit-bindgen 库的宏 方法一：在 build.rs 中使用 CLI 工具（wit-bindgen-cli） 这种方式在构建时生成一次绑定文件（例如 bindings.rs），之后可以作为常规 Rust 模块引入。 1. 添加依赖 在 Cargo.toml 中，将 wit-bindgen-cli 添加到 build-dependencies，并把生成的 bindings.rs 包含在 lib.rs 中： # Cargo.toml [package] # ... build = "build.rs" [lib] # 声明生成的 bindings 模块 path = "src/lib.rs" [build-dependencies] wit-bindgen-cli = "0.28.0" // src/lib.rs // 声明由 build.rs 生成的 bindings 模块 mod bindings; pub use bindings::*; 2. 编写构建脚本 (build.rs) 在项目根目录下创建 build.rs，使用 wit_bindgen_cli::generate! 宏处理 .wit 文件。 ...

1. 什么是 NotebookLM NotebookLM 是谷歌推出的一款基于用户资料的 AI 辅助研究/学习工具。它不能像通用聊天机器人那样直接回答所有问题，而是需要用户先上传自己的资料，例如 PDF、网站、视频、音频、文档等等，然后它基于这些资料快速总结、整理笔记，变身成为用户最关注领域的个性化 AI 专家。这一切是基于 Gemini 的多模态理解能力实现的。 与其他 AI 辅助的记事应用不同，NotebookLM 的优势在于以来源为依据。用户可以放心地使用 NotebookLM 的回答，因为它会严格参考上传的来源，从而降低 AI 生成不实信息的风险。 除用户控制来源外，NotebookLM 还有下面这些优势： 信息整合效率：NotebookLM 可理解、整合海量文字，并显著加快从中挖掘分析洞见的过程 个性化学习：NotebookLM 会根据用户的具体需求和内容，为用户营造高度个性化的学习和研究环境 并且，NotebookLM 还能根据上传的资料生成不同内容，例如播客风格的音频概览、幻灯片等等，激发用户的灵感，辅助打造创意项目。 2. 如何使用 NotebookLM 安卓和苹果用户可以下载 NotebookLM 应用： 电脑用户目前需要通过浏览器使用 NotebookLM： NotebookLM 目前支持 4 种使用方案，免费的试用版本即可满足大部分人的需求。 Plus、Pro 和 Ultra 版本会限制地区，国内用户肯定是受到限制的。 3. NoteBookLM 使用场景 在日常工作中，用户可以这样使用 NotebookLM： 开工前的文档审核助理 - 开始工作前，上传会议记录、报告等资料，让 NotebookLM 帮助分析并为全天工作做好准备 促进高效研究的得力助手 - NotebookLM 不仅能节省“搜索答案”的时间，还能根据来源帮助厘清概念、辅助撰写邮件、准备提案，并汇总相关分析洞见 助力学习和规划的智能伙伴 - 关键概念、定义和事实会自动转化为抽认卡，NotebookLM 也会根据上传的资料生成测验，完成测验后生成动态报告，辅助用户应对会议或考试 进行每日复盘和规划的贴心管家 - NotebookLM 可梳理当日笔记要点，并生成待办事项清单等材料 ...

在个人服务器上搭建网站，对于计划长期运行的站点，有一个问题是必须要考虑的，那就是站点的安全问题。这里介绍一些基本的防护手段。防护的核心原则是：在保持服务可访问的前提下，最大限度地缩小攻击面，并建立多层防御。 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 配置文件中一些便利性的配置： ...

基于 hugo 生成的个人静态网站，有多种上线方式可以选择（参考 Host and deploy with hugo）。如果你和我一样，打算将个人博客部署在自己的 VPS 服务器上，那么 VPS 服务器需要运行 HTTP 服务，可以是 nginx，也可以是 caddy。这里我选择 caddy，因为它的文档完整，安装配置简单。 1. 安装 caddy caddy 支持多种安装方式，可以直接下载 caddy 二进制文件： from releases on GitHub (expand “Assets”) Refer to Verifying Asset Signatures for how to verify the asset signature from our download page by building from source (either with go or xcaddy) 也可以通过操作系统各自的包管理器进行安装，通常这种方式会为 caddy 自动创建用户和用户组，还会为 caddy 配置 systemd service。 生产环境下，十分建议将 caddy 配置为 systemd service。 Debian, Ubuntu, Raspbian # Debian, Ubuntu, Raspbian sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg chmod o+r /etc/apt/sources.list.d/caddy-stable.list sudo apt update sudo apt install caddy Installing this package automatically starts and runs Caddy as a systemd service named caddy. It also comes with an optional caddy-api service which is not enabled by default, but should be used if you primarily configure Caddy via its API instead of config files. ...

这篇文章介绍一种将博客自动更新到 HTTP 服务器的方式。 假设你有一个 VPS 服务器，并且上面已经运行 HTTP 服务器（可以是 nginx，也可以是 caddy）。那么将 Hugo 站点提交到 GitHub 后，可以借助 GitHub Actions 将站点自动部署到 VPS 服务器，核心思路是：在 GitHub 的虚拟环境中安装 Hugo、生成静态文件，然后通过 SSH 将public目录的内容同步到你的 VPS 上。 整个过程配置一次，之后你只要git push，网站都会自动更新。 下面是一个经过实践检验的自动化部署方案，包含配置步骤和完整的 YAML 代码。 1. 配置 GitHub Actions 第一步：准备工作——在 GitHub 仓库中配置密钥 为了让 GitHub Actions 能安全地登录你的 VPS，你需要将 VPS 的登录凭证存储在 GitHub 仓库的“Secrets”中。 在你的 GitHub 仓库页面，点击 Settings → Secrets and variables → Actions。 点击 New repository secret，添加以下两个密钥： SERVER_IP：你的VPS公网IP地址（或者可解析的网址亦可）。 SSH_PRIVATE_KEY：你的VPS登录私钥。 如果你没有密钥对，可以在本地通过ssh-keygen -t rsa -b 4096 -f ${private_key_path}生成： ...