Redis 队列：在你的 AI 代理任务之间的粘合剂

发布: 1天前 (2026年3月19日 GMT+8 18:01)

5 分钟阅读

Source: Dev.to

The Problem: AI Tasks Need a Handoff Layer

When you are building autonomous pipelines — not toy demos, but systems that actually run unsupervised — the hardest part is not the AI. It is the plumbing between tasks.

Prospect discovery — 发现潜在客户 — 查找拥有过时网站的本地企业
Site builder — 站点构建器 — 在 GitHub Pages 上生成现代化重新设计的预览
Outreach — 外联 — 发送包含预览链接的短信或电子邮件
Follow‑up — 跟进 — 检查跟踪像素，重新接触有意向的潜在客户

Each step produces output the next step needs. A database works, but it is heavy. Flat files work, but they do not signal. What I needed was a queue — something that says “here is work, go do it.”

为什么 Redis 合适

Redis 为 AI 代理协作提供了三件重要的东西：

列表作为队列

LPUSH 入队，RPOP 出队。极其简单。你的潜在客户查找器将业务对象推入列表。你的站点构建器弹出它们。无需轮询数据库，也不需要文件监视器。

# Prospect finder adds work
redis-cli LPUSH prospect:queue '{"name": "Acme Auto", "url": "acmeauto.com", "phone": "555-0123"}'

# Site builder grabs next job
redis-cli RPOP prospect:queue

集合用于去重

当你的潜在客户查找器每隔几小时运行时，它会重新发现相同的企业。入队前，检查集合：

redis-cli SISMEMBER prospect:seen "acmeauto.com"
# Returns 0 (new) or 1 (already processed)

这就是我跟踪饱和度的方式。当 SISMEMBER 返回 1 的次数多于 0 时，就该扩大搜索半径或切换类别了。

TTL 用于临时状态

有些数据不应永久保存。跟踪像素点击、速率限制计数器、会话令牌——给它们设置 TTL，省去清理工作：

redis-cli SET outreach:ratelimit:sms 15 EX 3600

我的实际设置

我在单个 VPS 上的 Docker 容器中运行 Redis，和其他所有服务一起。配置非常简洁：

redis:
  image: redis:7-alpine
  volumes:
    - redis-data:/data
  command: redis-server --appendonly yes --maxmemory 256mb --maxmemory-policy allkeys-lru

使用追加文件（AOF）进行持久化，内存上限 256 MB 并采用 LRU 驱逐策略。对于每天可能处理 50–100 条潜在客户的单人开发流水线来说，这简直是极度浪费——这正是重点所在。你根本不会去在意它。

AI 代理通过简单的 CLI 调用或轻量级的 Node 脚本访问 Redis。没有 ORM，也没有客户端库的繁琐。redis-cli 已安装在宿主机上，在容器内部，Redis 只需通过 redis:6379 访问即可。

出现的模式

分阶段模式

Instead of going straight from discovery to outreach, I queue into prospect:staged. A separate review step (sometimes human, sometimes AI) moves approved prospects to prospect:ready. This gives me a kill switch without touching code.

死信队列

When outreach fails — bad phone number, bounced email — the prospect goes to prospect:failed instead of disappearing. I review these weekly. Sometimes the data just needs cleaning.

计数器模式

I track daily stats with expiring keys:

redis-cli INCR stats:prospects:2026-03-19
redis-cli EXPIRE stats:prospects:2026-03-19 604800  # 7 days

我不会用 Redis 的场景

需要复杂查询的任何情况。如果你想要“显示所有在迈阿密的潜在客户，这些客户在 7 天前被联系且尚未回复”——请使用 Postgres。Redis 用于流控制，而不是分析。
需要跨多种数据类型的事务的任何情况。Redis 虽然有事务功能，但并不适合作为业务逻辑的事务处理。
需要长期存储以满足合规要求的记录。Redis 只是一个缓冲区，而不是归档存储。

要点

如果你在构建包含多个步骤的 AI 自动化流程，就需要一个协调层。Redis 是我找到的摩擦最小的选项。只用了 10 分钟就把它加入到我的 Docker Compose 中，并且立刻简化了三个不同的流水线。

AI 是炫目的部分。队列才是让它在你睡觉时也能运行的关键。