管理 AWS 资源不一定要反复打开控制台。AWS CLI 可以在终端里调用几乎所有 AWS 服务，既适合临时查询，也适合编写自动化脚本。

本文以 AWS CLI v2 为基础，从安装、认证和 Profile 管理开始，逐步介绍 S3、EC2、输出过滤、分页与排错。读完后，你将能够建立一套安全、可复用的 AWS 命令行工作流。

当 Codex 里安装的 skill 越来越多时，我遇到了下面这个告警：

⚠ Skill descriptions were shortened to fit the 2% skills context budget. Codex can still see every skill, but some descriptions are shorter. Disable unused skills or plugins to leave more room for the rest.

它不会让 Codex 直接停止工作，但暴露了一个很实际的问题：skill 数量太多、描述太长时，Codex 为 skill 元数据预留的上下文不够用了。部分 description 被截短后，虽然 skill 仍然可见，隐式触发的准确性却可能下降。

如果只看表面，mem9 很像是在给 AI Agent 的 memory 加一层向量检索。

但我把 mem9 仓库当前实现的写入链路、召回链路和数据模型真正看下来以后，越来越确定一件事：它的变化并不是“从关键词搜索换成 embedding”这么简单，而是把记忆从本地文件升级成一套可抽取、可去重、可重塑、可共享的服务端系统。

2026 年 4 月 16 日，Anthropic 正式发布了 Claude Opus 4.7。和每次大模型发布一样，最先刷屏的往往不是参数表，而是一张 benchmark 成绩图。

这次也一样。很多人第一眼看到的，是几个醒目的分数：SWE-bench Pro 64.3%、SWE-Bench Verified 87.6%、Terminal-Bench 2.0 69.4%、OSWorld-Verified 78.0%。但真正有信息量的，不是“哪个数字最大”，而是这些 benchmark 名字本身。

最近在用 Codex 的时候，我碰到一个很现实的问题：现在官方更提倡用 skill 来承载工作流能力，但不像以前那样可以直接依赖 slash command 作为调用入口。

这带来的变化是，skill 解决的是“怎么做”，却没有顺手解决“我怎么快速把这个意图发出去”。如果每次都手写 prompt，不仅麻烦，还很容易出现同一个动作每次描述都不一样的问题。于是我开始找一个更轻量的办法，把这些高频 prompt 固化下来，最后选了 espanso。

如果你想把 OpenClaw 放到云端，且希望配置尽量少、可恢复、可持续维护，那么 openclaw-hf 是目前非常省心的一套方案。

仓库地址：https://github.com/tenfyzhong/openclaw-hf

本文已按该仓库最新 README.md（2026-03-27 更新）同步整理为中文部署指南。

最近我单独做了一个仓库：tenfyzhong/openclaw-docker。

这篇文章主要说两件事：为什么要做它，以及你怎么最快把 OpenClaw 跑起来。

为什么我要做这个仓库

我一开始也是按官方方式折腾 Docker 运行 OpenClaw，但实际体验里有几个明显门槛：

最近在做一个高并发的 API 服务，JSON 序列化成了性能瓶颈。标准库虽然稳定可靠，但在压测时 CPU 占用居高不下。于是我决定做一次彻底的 JSON 库性能对比，看看市面上这些号称"高性能"的库到底有多少真本事。

您是否正在寻找一种免费、可自托管且功能强大的工作流自动化工具？n8n 是一个绝佳的选择，它允许您连接各种应用程序和服务，创建复杂的自动化流程。而现在，借助 Hugging Face 和 Supabase 的免费资源，您可以轻松拥有一个能够自动更新的 n8n 实例，无需花费一分钱。

您是否拥有一个域名，但又不想为了一个自定义的邮箱地址（例如 info@yourdomain.com）而支付额外的企业邮箱费用？Cloudflare 的电子邮件路由（Email Routing）功能为您提供了一个完美且免费的解决方案。它允许您创建任意数量的自定义域名邮箱地址，并将收到的邮件无缝转发到您现有的个人邮箱（如 Gmail、Outlook 等）。