分类目录归档:技术

工程师如何把多个 Coding Agent 真正带起来:一套比“开更多聊天窗口”更像工程流程的方法

随着 Agent 的时代的到来和 AI Coding 工具的兴起,被 AI 冲击的最狠的软件工程领域也迎来一轮一轮变化;我也在这个过程中一轮轮迭代,使用不同的 Agent 的工具,来帮助我自己提升自己的工作效率。而随着我的 Coding Agent 的使用越来越多,我的问题不再是「有没有 Agent」、「有没有用好 Agent」,而是 —— 「在保证工程质量的基础上,如何把多个 Agent 同时安排出去,把结果收回来」。

现在的问题是 「如何 Scale UP 你的 Agent 」

虽然目前 AI Coding 的覆盖率依然有待提升,但是,对于不少逛少数派的工程师来说,大家大多已经会用 Claude Code、Codex、OpenCode 一类工具。大家所面临的问题不再是将 AI 引入自己的工作流,而是

  1. 你已经在使用 AI 了,但你手头有 100 个任务都需要推进,每个都是 P0 任务。
  2. 你其实也知道每个任务怎么做,但终究只有一个你;
  3. 你的精力足以支撑你一个个盯这些任务,你可能会考虑多屏幕开始干活,但终究还是只能同时看 3-4 个,就很难再更大规模的扩容。

真正卡住你的不是代码能力,而是并发调度能力

为什么 Codex / Claude 的 Terminal UI 不够?

Terminal UI 从体验上来看,还是一个 Chat Bot ,你给他安排工作,让他把事情做完,这个还是单个线程的工作流;如果你有多个任务、多条分支、多种不同风格的 Agent,不可避免的要用上 Terminal 自带的多 Tab、多窗口,抑或是使用 tmux 来帮助你复用窗口,开发者本人会成为任务调度的瓶颈。

而在这个过程中, Terminal UI 的限制也有贡献,让我们集中在小范围的核心信息中把工作完成。

而这个过程中,我认为最接近当下我眼中最优解的便是 —— Vibe Kanban。

vibekanban

Vibe Kanban 在解决什么问题

如果你认真用过一段时间 coding agent,就会发现单 agent chat 界面有几个很明显的问题。

  1. 它天然更适合顺序执行。你可以让它完成一个明确任务,但一旦任务开始变多,吞吐量很快就会被人类自己卡住。
  2. 上下文很容易混。你本来只是想修一个 bug,结果顺手又让它改了另一个功能,再过一会儿,你已经忘了这段对话到底是为了解决哪个问题。
  3. 计划和执行是黏在一起的。很多时候不是 agent 不会写,而是你还没把任务定义清楚,它就已经开始跑了。
  4. review 成本越来越高。你开了更多 agent,并不自动等于你获得了更高的工程效率,很多时候只是获得了更多需要你亲自收拾的 diff。

围绕着上面的这些问题,Vibe Kanban 做了一些优化,它不是新的 coding agent,而是一个把 planning、workspace、review、preview、PR 流程连起来的管理层。

这让软件工程任务从 Agent Chat 窗口中的单线程流转变成了我们更熟悉的 Kanban 机制,有了状态、有了任务,每个任务还有单独的 workspace ,我们可以使用我们熟悉的工作流,来优化完整的 Agent 落地行为。

  • 先拆 issue
  • 再明确计划
  • 再开 workspace
  • 再让不同 agent 去执行
  • 再 review diff
  • 再决定是否收敛、合并

我自己的 Vibe Kanban 的工作流

目前我是一个 VibeKanban 的重度依赖者;我会把我平时看到的一些任务直接添加到 Vibe Kanban 上。

Vibekanban.png

在完成任务细节的补充后,直接创建一个新的任务工作区,选择 Agent,并让 Agent 强制开启 Plan Mode,通过 Plan Mode 消除任务中的歧义。

H8P1JaMQIe.png

最终汇总形成完整的设计方案后,批量让其执行起来;

任务

因为 Agent 执行是需要周期的,所以我可以同步开启 N 个 Issue ,让 Agent 并行处理,并在 Agent 需要我介入的时候,参与到任务当中。

并行描述.png

通过这样的方式,我快速且稳定的交付了大量的高质量的需求。

我所看中的 Vibe Kanban 的几个设计细节

1. Kanban 机制

当你 Scale 的 Agent 足够多的时候,你会发现,真正限制你的不是 Agent 的数量(这个很好突破,是钱的问题),真正限制的是你的认知带宽、你的管幅。一个你更熟悉的方式,会帮助你减少 Landing 和理解的成本。

Kanban 简单的 TODO、Doing、DONE 机制,让任务本身一目了然,我们可以轻松的把任务的当前状态、Next Action讲清楚、想清楚,也可以收敛每个任务的上下文。

2. 强制开启 Plan Mode

大部分人类在给 AI / Peer 安排任务的时候,其实是很差的,我们并没有说清楚需要做什么。这是因为我们脑海中有远超我们所表达的上下文。但如果我们没有安排出清楚的上下文时,不管是 AI 还是我们的 Peer ,其实都很难做好这些事。如果想要更好的让 AI / Peer 把事情做好,就需要把上下文交代的清楚。

既然人类不习惯,那不妨让 AI 来主动追问,通过 Plan Mode 来强制让 AI 主动发现任务细节中的歧义,并主动对话来消除歧义。

3. Agent 并发接入 & 自动的 Workspace 接入;

想要最大化你的时间和精力,一个比较好的办法是让你的下属 AI 能够并发进行处理任务,并充分的利用你的精力去做重要的决策。那么就需要同时启动多个 Agent,他们并行做计划、并行推进,从而打满你,让你可以始终处在决策、确认、检查、休息的环节,而不是无所事事。

Vibe Kanban 和 Git Worktree 做了非常好的集成,当你开始一个工作区的时候,他会自动为你创建一个新的 Worktree,并可以在你的任务完成后, Merge 进入你的 Main 分支当中,非常的方便。不仅如此,当你的变更和上游发生了冲突的时候,它还提供了 AI 解决冲突的能力,从而将复杂的分支管理给简化了。

4. 一丝丝幽默感

Vibe Kanban 是支持完成任务通知你的,而通知的方式也颇为幽默。他们提供了很多种音频来提醒你,比如 —— 牛的哞哞叫。是的,我的提醒音频就是牛叫,提醒我,我的 AI 牛马把活干完了,需要我去看了。

很好玩。

Vibe Kanban 适合谁?

从我自己的时候来看, Vibe Kanban 非常适合所有的「软件工程师」,他们的问题是虽然知道每一个任务应该怎么做,但没有足够的上下文带宽来并行,Vibe Kanban 提供了串行转并行的能力,帮助你更加快速的将自己 Scale 起来。

Vibe Kanban 真的像 —— 你将自己复制了 100 份,去分别执行不同的任务。你觉得自己分身乏术?这个就是那个分身之术。

但同样的,Vibe Kanban 也不是银弹,它不适合:

  1. 不适合还不会拆任务的人
  2. 不适合把 AI 当自动许愿机的人
  3. 不适合只想偶尔用一下 agent 的轻量用户
  4. 不适合还没有 review 能力的人

遗憾的是, Vibe Kanban 终将 Sunset

虽然 Vibe Kanban 我说的很好,但不得不说,就如标题一般 —— Vibe Kanban 终将 Sunset。这也是促使我来写这篇文章的重要原因,即将转向的 Vibe Kanban 值得你尽早体验。

VibeKanban 的方向是明确的,它代表了一种易于理解、易于拆解方案的 Agent Scale 实现。作为一种工作方式和实现,他无疑是成功的,但作为一个商业化产品来说,他可能又是失败的。 Vibe Kanban 的母公司 Bloop AI 已经宣布 Shutdown ,Vibe Kanban 项目也将专项 Open Source & community maintained。

在今天,如果你还困惑于如何 Scale Up 自己,最大化发挥出 Agent 的潜力,我觉得 Vibe Kanban 是一个你的必经之路。未来或许会有更好的解决方案,但 Vibe Kanban 的 Sunset 也浇灌出了新的可能性。

写在最后

Vibe Kanban 不仅仅是一个工具,他更代表着 —— 让软件工程师更加「软件工程」,我们更关心软件工程架构,而不是写代码。每一个软件工程师都可以依靠自己的经验管理一组 Coding Agent ,去做计划、去做执行。

Vibe Kanban 未必适合所有人,但如果你已经不满足于每次只用一个 Agent Chat 窗口,那么 Vibe Kanban 非常适合你试一试。

使用腾讯云云迁移服务将 R2 存储中的文件迁移到腾讯云 COS 中

最近把这个域名重新备案了一下,就可以利用起我在腾讯云上的闲置服务器。既然要迁移服务器,不妨将图床一并迁移,这样后续使用起来也方便,国内的读者加载起来速度也快。

不过,这些年大量使用,我的文件还是挺多的….足足有 13GB 的文件,手动一个个搬迁可就累死了;于是乎,我决定试试腾讯云的迁移服务,来帮助我把 R2 上的文件迁移过来。

image

获取配置信息

想要使用腾讯云提供的云迁移(CMG)服务,则需要获取一些配置信息,具体包括:

  • Cloudflare R2 的 Access ID 和 Secret Key
  • 腾讯云的 Access ID 和 Access Key,创建好的 Bucket(要迁移的目标)

R2 的相关配置可以在 CloudFlare R2的配置页面找到;如果没有的话,你就创建一个新的。

image

腾讯云的则可以在腾讯云密钥管理中获取,建议创建一个新的用户,并授予 QcloudMSPFullAccessQcloudCOSAccessForMSPRole 策略,点击子账号可以看到如下图的两个权限。

image

配置云迁移

完成账号的确认后,接下来就是配置云迁移。打开云迁移中的「对象存储迁移」,或者直接打开这个链接,就直接进入云迁移的页面。

image

源站配置

接下来配置云迁移的具体配置,点击新建人数,在新的页面中,输入你的 CloudFlare 配置信息,具体可以参考下面的截图:

image
  • AK/SK: 你从 Cloudflare 获取的相关参数;
  • 桶名称:你的 R2 Bucket 的名称;
  • 空间域名:你的 R2 的域名,是 uid.r2.cloudflarestoage.com,比如我的是 https://24071135c3ad9d9196e7e45e33948d28.r2.cloudflarestorage.com
  • 桶的所在地:比如我的是亚洲,就选 apac

源站中的其他选项可以根据需要选择,如果你是完整迁移,和我保持一致即可。

目标站点配置

接下来是配置迁移目标,这里指标支持迁移到腾讯云自家的 COS 上;填入你的 Secret ID 和 Secret Key,然后可以直接在下面输入具体的 Bucket 名称,或者填完后点击下拉框右侧的刷新按钮后,选择合适的。

image

其他的选项,如果你和我一样是整个 Bucket 迁移,则可以保持相同的配置,直接整个迁移。

配置完成后,点击最下方的新建并启动,就会启动搬迁。接下来就回到任务列表等刷新即可,等待他自己搬迁完即可。实测搬迁速度很快,13G 的文件,8 分钟就搬迁完成了(还是我限制了搬迁的带宽),如果是不限制,估计 2 分钟就能搬迁完成。

image

如果你需要和我一样,从外部的 S3 将文件搬迁到腾讯云的 COS 上,不妨试试看这个方法~

django-storages 配置使用 S3 Provider 支持 Aliyun OSS 使用

阿里云 OSS 提供了 S3 的兼容,所以如果你在 Django 应用当中,希望使用 OSS 作为文件存储的话,可以参考下方的说明,来使用。

安装

首先,你需要执行如下命令安装 django-storages 的 S3 兼容

# uv
uv add django-storages[s3]
# pip
pip install django-storages[s3]
Code language: CSS (css)

配置

接下来,就是在你的项目文件夹中的 settings.py 中添加如下配置

AWS_S3_ACCESS_KEY_ID = env("AWS_S3_ACCESS_KEY_ID") # 你在阿里云拿到的 ACCESS_KEY
AWS_S3_SECRET_ACCESS_KEY = env("AWS_S3_SECRET_ACCESS_KEY") # 你在阿里云拿到的 Secret Key
AWS_STORAGE_BUCKET_NAME = env("AWS_STORAGE_BUCKET_NAME")# 你在阿里云拿到的 Bucket Name
AWS_LOCATION = env("AWS_LOCATION") # 你的文件上传路径,比如  uploads/,你的所有文件都会上传到这个路径下
AWS_S3_REGION_NAME = env("AWS_S3_REGION_NAME") # 你的 OSS 的可用区,比如 oss-cn-beijing
AWS_S3_CUSTOM_DOMAIN = env("AWS_S3_CUSTOM_DOMAIN") # 你自己的自定义域名,以便于后续访问的时候使用。如果不知道的话,可以填 bucket 的默认域名。
AWS_S3_ENDPOINT_URL = env("AWS_S3_ENDPOINT_URL") #  你的阿里云 Endpoint URL,比如 https://oss-cn-beijing.aliyuncs.com

AWS_S3_ADDRESSING_STYLE = "virtual" # 阿里云只支持二级域名的形式
AWS_S3_SIGNATURE_VERSION = "s3" # 阿里云只支持 v2 版的签名逻辑

# 配置默认使用 S3 Storage,即使用 OSS 的 URL
STORAGES = {
    "default": {
        "BACKEND": "storages.backends.s3.S3Storage", # 使用 S3  Storage
    },
}

Code language: PHP (php)

参考上方的配置,添加配置项后,保存,并重启服务器,即可在代码中进行测试。

测试代码

你可以执行 python manage.py shell 并执行如下代码,如果无报错,且可以在 OSS 控制台看到文件,则说明你的配置成功了。


from django.core.files.storage import default_storage
from django.core.files.base import ContentFile
content = ContentFile(b"Hello World!")
path = default_storage.save('test_file2.txt', content)
print(f"文件保存路径: {path}")
# 测试文件读取
if default_storage.exists(path):
    with default_storage.open(path, 'r') as f:
        content = f.read()
        print(f"文件内容: {content}")
# 测试文件URL生成
url = default_storage.url(path)
print(f"文件URL: {url}")
# 测试文件删除
default_storage.delete(path)
print(f"文件是否存在: {default_storage.exists(path)}")

Code language: PHP (php)

一些我自己用的还不错的 Chrome 插件

英语/日语翻译:沉浸式翻译

我的日常要看到很多英文文章和网站,因此,可以借助沉浸式翻译,帮助我快速翻译多种语言为中文,从而降低我在阅读不同语言内容的障碍。

1743588697 image

快速搜索:超级搜索

超级搜索支持我快速的选中词汇并进行搜索,对于一些特定的场景下,会非常有帮助。比如我在浏览网页的时候,发现了一部电影,想快速在豆瓣电影中找到并标记,就可以借助超级搜索,配置一个搜索关键词来实现。

1743588684 image

SEO 检查器:AITDK

AI TDK 是我用来检查自己的网页是否完成了一些基本的 SEO 设置的工具。当我上线了一个新的网站后,就会打开 AITDK,然后查看哪里的信息还不完整,需要补充的。就可以继续去补充相应的内容。

1743588868 image

JSON 查看:JSON Viewer

在开发的时候,经常会有要查看服务端返回的 JSON 的情况, 借助 JSON Viewer 可以将不容易看明白的 JSON 给格式化了,方便你快速定位要看的 JSON。

1743589100 image

广告拦截:AdGuard

广告拦截我选择了 AdGuard,有了它,我看 Youtube 再也没有广告了。。。

1743589301 image

复制为 Markdown:Copy as Markdown

因为经常要将部分内容复制为 Markdown,方便在我的其他工具中使用,所以我安装了这个 Copy as Markdown 插件,方便自己随意复制。

1743589434 image

页面增强:篡改猴

当我需要对一些网页做一些快速的改造,但同时又不想写成 Chrome 插件的时候,就会选择写成油猴脚本,然后放在篡改猴里来用,非常方便。

1743589508 image

灵感记录:Memos

我自己部署了一个 Memos ,用于记录自己的灵感和想法。因此,我使用了一个 Chrome 插件,来方便我记录。

1743589800 image

记一次发现小宇宙 iOS 版的跳转注入漏洞

漏洞风险:可以在其他应用借助小宇宙端内跳转任何网页。

此文章发布前,小宇宙已经修复了这个问题,所以你们可能不能复现这个问题了。

先看漏洞效果,这个漏洞的问题是你可以在小宇宙里跳转到任何网站,甚至是 PornHub。不过这个 Bug 不重要,重要的是发现 Bug 的过程

漏洞效果

0. 背景

在一天晚上,我在和朋友聊小宇宙的 URL Scheme,想要做个功能,可以实现一键打开小宇宙的节目页面。但卡在我面前的是,我不知道小宇宙的 URL Scheme 到底是什么。于是便开始了我的 Hack 之旅,也就找到了小宇宙的这个安全漏洞。

1. 找到小宇宙的 URL Scheme

由于 Scheme 是在 App 中定义的,所以当我想到要找 Scheme 之后,第一反应的是去拿 iOS App 的 Info.plist(因为 iOS 是将 Scheme 定义在 info.plist 当中)。

过去需要通过 IPA 备份、越狱等方式来获取到这个文件,不过得益于 M 系列支持在 macOS 上运行的原因,现在 IPA 的获得变得非常的简单。 先在 App Store 安装小宇宙,并在「应用程序」中找到小宇宙。

image

然后右键点击小宇宙,点击「显示包内容」

image

然后看到这样的内容,WrappedBundle 是一个假的应用程序,所以继续点击 Wrapper 往里跳转。

image

然后会发现里面还有一个 Podcast 应用,这个才是真正的小宇宙的 IPA 包。然后继续点击「显示包内容」

image

在包内容当中可以看到 info.plist 文件,使用 Xcode 或者 VSCode 打开 info.plist 文件。

image

info.plist 文件中,搜索 CFBundleURLSchemes ,找到了小宇宙的 URL Scheme(里面有很多个,但很多都是其他应用的,试一下就可以发现):cosmos://

image

2. 找到 URL Scheme 能够打开的页面

找到了 URL Scheme,只能通过 cosmos:// 打开应用首页,无法满足我的需求,于是开始继续寻找可能的 URL Scheme 。一般来说,这个时候就只能继续反编译 IPA 包或者 APK 包了。不过对于我来说,这些不是一个好的选项(成本太高)。

然后想到,小宇宙的网页似乎是提供了打开客户端的能力,所以可以从网页版找到突破口。通过简单的搜索,果然让我在网页前端找到了突破口。找到了 7 个 Scheme 。

image

当然,中间存在一些重复的 Scheme。所以最终梳理出来的 Scheme URL:

  • cosmos://page.cos/discover:打开发现页
  • cosmos://page.cos/shownotes/EPISODE_ID:打开节目的 Shownote 页面
  • cosmos://page.cos/episode/EPISODE_ID:打开节目的详情页
  • cosmos://page.cos/webView?url=:意义不明,看起来像是打开一个特定的 URL
  • cosmos://page.cos/web?url=:意义不明,看起来像是打开一个特定的 URL

3. 发现问题 URL Scheme

前面的三个很正常,但后面的两个带 URL 的引起我的注意 —— as a Hacker,你知道的,任何一个可能的输入框都可能成为我们的注入点,于是乎,我就构建了一个链接,来打开我的 Blog

cosmos://page.cos/web?url=https%3A%2F%2Fwww.ixiqin.com
Code language: JavaScript (javascript)

将这个链接使用 Safari 打开,就会自动唤起小宇宙,并打开我的播客。

至此,我发现了小宇宙这个跳转注入漏洞,并快速将其反馈给小宇宙官方同学。

复盘:如何规避这样的问题

在这个 Case 当中,小宇宙因为没有设置 URL 跳转的白名单,导致实际上出现了跳转恶意网站的风险。理论上,作为应用提供商,出于安全合规的视角,最好是控制 URL 跳转的域名和空间,避免被恶意滥用。

或者也可以参考我们现在见到的很多网站,在外部跳转时加一个风险提醒

如果在这个 Case 当中,小宇宙在一开始就限制了可以打开有限域名,那也不会出现如今我这次的漏洞问题。

这个问题风险大么?

取决于如何定义和如何使用。如果只是跳转一些常规网站,自然是风险不大的。但如果不受限制的,比如跳转到一些诈骗网站,可能风险就是大的。

如何快速清空七牛的存储空间中的所有文件,并删除存储空间

如果你和我一样,有很多历史的文件存储在七牛上,但如今已经不再需要使用,那么就可以考虑删除七牛的存储空间,来节省费用。

但七牛为了保证安全,所以要求必须删除所有的文件后才能删除空间,以避免误删除,所以需要一个个删除所有的文件。为了快速删除七牛存储空间的文件,我写了个简单的脚本,帮助你快速删除七牛空间下的所有文件。

具体操作可参考如下脚本,你只需要

  1. 在本地安装七牛 SDK :pip install qiniu
  2. 创建一个新文件 run.py 并复制下方的代码,修改其中的访问密钥和存储空间名称
  3. 执行 python run.py 就可以了。
# -*- coding: utf-8 -*-
# 导入七牛云 SDK 所需的模块
from qiniu import Auth
from qiniu import BucketManager, build_batch_delete
# 七牛云账号的访问密钥
access_key = '你的 ACCESS Key'
secret_key = '你的 Secret Key'
# 要清理的存储空间名称
bucket_name = '你要清空的空间名称'


# 使用 AK、SK 初始化授权对象
q = Auth(access_key, secret_key)
# 初始化存储空间管理器
bucket = BucketManager(q)

# 设置每次列举的最大条目数
limit = 1000

# 循环列举并删除存储空间中的文件
while True:
    # 列举存储空间中的文件
    # ret: 包含文件信息的字典
    # eof: 是否已列举完所有文件
    # info: 请求的状态信息
    ret, eof, info = bucket.list(bucket=bucket_name)
    # 从返回结果中提取文件名列表
    keys = [item['key'] for item in ret['items']]
    # 构建批量删除操作
    ops = build_batch_delete(bucket_name, keys)
    # 执行批量删除操作
    ret, info = bucket.batch(ops)
    # 检查删除操作是否成功
    if info.status_code == 200:
        print(f"success delete {len(keys)} files!")
    
    # 判断是否已经列举完所有文件
    if eof:
        break
    else:
        continue
# 输出清理完成的提示信息
print(f"delete all files in {bucket_name}")
Code language: Python (python)

执行成功后,你会看到如下面这样的命令,接下来等他自动执行即可,你就不用做任何事情了。

image

当工具提示你 delete all files in 你的 kodo 名时,你就可以回到七牛控制台,删除掉空的 kodo 了。

image

使用 Cloudflare 配置 301 转发

我的 newsletter 一部分使用 Ghost.js 进行托管,还有的在使用 Quail 来进行托管,而对应的域名则放在 Cloudflare 上进行解析。最近给 Quail 的 newsletter 绑定了域名,因为其只支持绑定一个域名,所以我就在 Cloudflare 上配置了 301 转发,来确保我的 @ 和 www 域名都访问同一部分内容。

这里我设定是 www 域名是真实绑定了 Quail 的后台,并通过 Cloudflare 完成相应的 CNAME 配置,确保网页可以正常访问,并要实现在 Cloudflare 上配置 301 转发,能够将根域名转发到 www 域名上。

image

在 Cloudflare 上配置域名解析,并开启代理模式

在 Cloudflare 上新增一个 CNAME 域名配置,配置你要转发的域名,目标可以选择你的 www 域名,或者是你的 www 域名的对应的 cname 域名。然后再打开代理

image

配置规则

在 Cloudflare 左侧侧边栏找到「规则」,进入规则页面,以配置规则。

image

在规则页面,创建一个新的规则,这里模板你可以选择「从 www 重定向到根」(如果你和我相反,是先建设好的根域名,将 www 转发过来,那直接使用这个规则就行。)

image

在弹出的规则配置页面设置你的转发规则,比如下图这样的设置就行。

image

这样当你的规则生效后,如果用户访问 AIStarter.dev/xxx,就会自动转发到 www.aistarte.dev/xxx。从而帮助你完成相关的配置能力。配置完成后,保存稍等片刻就可以生效了。这个时候你就可以使用 curl -I xxxx.xxx 来看你的域名转发情况,是否能正常返回 301 response。

image

如何修改 Advanced Media Offloader 使其可以批量将历史文件上传至对象存储?

Advanced Media Offloader 提供了 Bulk Offload 功能,可以实现将历史的文件上传到对象存储中,从而降低本地的存储压力,使得站点自身变得无状态。

但其默认的 Bulk Offload 功能每次只能加载 50 个图片,如果附件太多,则需要点击 N 次,十分麻烦。

image 6


不过,可以通过简单的修改,来实现一次上传,将多个图片进行 Offload。

在 WordPress 后台的插件管理器中,找到 Advanced Media Offloader 插件,并将includes/BulkOffloadHandler.php文件打开,找到其中的 get_unoffloaded_attachments 函数,修改函数定义中的 $batch_size = 50 为你想要的大小即可使其一次批量加载多个文件了。

image 8
修改位置

修改后效果:

image 7

WordPress 使用 Caddy 完成静态化缓存

使用 Caddy 处理 WordPress 当中,我提到在用 Caddy 处理 WordPress,且为了性能做了很多优化。

我的博客经历了三重优化:最基础的 PHP OpCache + Redis 数据查询缓存 + 静态化缓存。

其中一个比较有效的,便是在整个站点上加入静态化缓存,绝大多数游客看到的其实是预先生成好的静态页面,从而减少了数据库加载、渲染、计算的成本。

而想要实现静态化,则需要借助于 Cache Enabler 插件和 Caddy 配置来完成。

安装插件并启用

安装 Cache Enabler 插件,并启用插件,启用后,在后台设置中,配置过期时间和对应的清除策略,并保存。这个时候,Cache Enabler 就会自动帮你去生成不同的页面了。

image 5

配置 Caddy 路由转发

首先,你应该在你的 php_fastcgi unix//run/php/php-fpm.sock 前面加入缓存的代码并重启 Caddy,具体如下

image 4

缓存配置如下

     @cache {
		not header_regexp Cookie "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in"
		not path_regexp "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(index)?.xml|[a-z0-9-]+-sitemap([0-9]+)?.xml)"
		not method POST
		not expression {query} != ''
    }

    route @cache {
        try_files /wp-content/cache/cache-enabler/{host}{uri}/https-index.html /wp-content/cache/cache-enabler/{host}{uri}/index.html {path} {path}/index.php?{query}
    }
       
Code language: JavaScript (javascript)

这部分配置先定义了一个 @cache 块,用于后续判断,并在其中加入了多种条件判断,说明了不使用缓存的情况:

  • 如果用户有以下 Cookie,就不使用缓存:
    • comment_author(评论作者)
    • wordpress_[a-f0-9]+ (WordPress 的会话 Cookie)
    • wp-postpass(密码保护文章的 Cookie)
    • wordpress_logged_in(登录状态的 Cookie)
  • 如果当前请求命中了以下路径则不缓存
    • /wp-admin/(后台管理页面)
    • /xmlrpc.php(XML-RPC 接口)
    • 所有 wp-*.php 文件(WordPress 系统文件)
    • /feed/(RSS 订阅)
    • sitemap 相关文件
  • POST 请求不缓存(比如评论)
  • 带查询参数的缓存不请求。

随后,通过 route @cache 定义了命中缓存部分的查找顺序:

  1. 先找 HTTPS 版本的缓存:/wp-content/cache/cache-enabler/{host}{uri}/https-index.html
  2. 再找普通缓存:/wp-content/cache/cache-enabler/{host}{uri}/index.html
  3. 如果找不到缓存,就尝试原始路径:{path}
  4. 最后尝试 PHP 文件:{path}/index.php?{query}

查看效果

打开一个无痕窗口,访问你的网站,如果在 html 底部看到 <!-- Cache Enabler by KeyCDN @ Sat, 04 Jan 2025 03:05:34 GMT (https-index.html) --> ,则说明你已经成功启用静态化缓存了!

参考资料

silver mercedes benz emblem on blue surface

使用 Caddy 处理 WordPress

在用了很久的 Docker 托管 WordPress 后, 近期我把 Blog 迁移到了腾讯云的香港轻量云主机上,以获得更快的访问体验。在这次迁移后,出于 Hack 方便的目的,我将 Nginx 替换成了 Caddy。你目前访问的站点便是一个基于 Caddy 托管的 WordPress 站点。

安装 Caddy

安装 Caddy 的过程不需要太过赘述,遵循 Caddy 官方安装文档当中的指南安装即可。

安装 PHP

完成了 Caddy 的安装后,则是安装 PHP,这里我使用的是 ondrej 维护的仓库

sudo add-apt-repository ppa:ondrej/php
sudo apt update
Code language: Bash (bash)

执行上述命令安装 PPA 仓库,就可以继续执行 apt install php 来安装 php & 对应的版本。此外,记得安装相关的依赖包

apt-get install php-fpm php-mysql php-curl php-gd php-mbstring php-common php-xml php-xmlrpc -y
Code language: Bash (bash)

配置 Caddy

完成安装后,就可以正常来配置 Caddy 。得益于社区的集成和 Caddy 官方的支持,Caddy 配置 WordPress 的支持非常简单,可以直接使用 Caddyfile 格式来撰写。

example.ixiqin.com { # 这个配置是给 example.ixiqin.com

    root * /data/caddy/example.ixiqin.com # 我的网站文件都放在 /data/caddy/xxx 下,/data 是我挂载的数据盘

    log { #日志配置
        output file /var/log/caddy/example.ixiqin.com.log  # 日志路径
        format console # 日志格式
    }

    request_body { # 请求体大小
        max_size 20MB # 最大 20MB
    }

    encode zstd gzip # 支持 gzip 和 zstd 压缩
    file_server # 直接提供静态文件(比如图片啥的)
    php_fastcgi unix//run/php/php-fpm.sock # 使用 php_fastcgi 调用 php-fpm 来处理动态 php 文件。
}
Code language: PHP (php)

只需要这样的配置,你就可以完成一个最基础的 WordPress 的站点的配置。

其他配置

对静态文件提供单独的 404 返回

按照上面的配置,其实所有的请求都会转发给 php-fpm 来处理,从而造成额外的 PHP 资源浪费。因此,可以在配置当中加入如下代码,来让 Caddy 直接返回,从而避免对 PHP 性能的浪费。

@static_404 {  
  path_regexp \.(jpg|jpeg|png|webp|gif|avif|ico|svg|css|js|gz|eot|ttf|otf|woff|woff2|pdf)$  
  not file  
}  

respond @static_404 "Not Found" 404 {  
  close  
}

Code language: JavaScript (javascript)

配置缓存头

除了静态文件的 404 处理,你还可以在 Caddy 当中配置静态文件的缓存,从而让浏览器更多的应用缓存,减少服务器的流量,提升加载速度。

@static {  
  path_regexp \.(jpg|jpeg|png|webp|gif|avif|ico|svg|css|js|gz|eot|ttf|otf|woff|woff2|pdf)$  
}  
header @static Cache-Control "max-age=31536000,public,immutable"

Code language: JavaScript (javascript)