AI Agent 的"穷鬼"部署指南：从 $20 技术栈学到的

发表于2026-04-15|更新于2026-04-29|视界AI研究

|浏览量:

上个月，加拿大开发者 Steve Hanov 在博客里讲了个挺扎心的故事。他去参加一场创投路演，连预赛都没过。不是产品不行，人家已经有用户、有收入、有 MRR 了。评委的反馈就一句：”你都这么省了，还融什么资？”

我当时看到这儿就愣住了。这简直就是当代独立开发者的魔幻现实主义剧本。别人在 PPT 里画大饼、烧 AWS 额度的时候，这家伙已经用每月 20 美元的成本，跑出了 6 个月入过万刀的 SaaS 产品。

他的技术栈简单到有点侮辱人。一台 $5 的 VPS、Go 写的后端、SQLite 当数据库、systemd 做进程守护，完事儿。没 Kubernetes，没 Docker Swarm，没 RDS，没 NAT Gateway。整套系统一个月的咖啡钱就能覆盖。

但这篇文章不是来吹 Steve 有多神的。我想聊的是另一件事。当我们正在热火朝天地搞 AI Agent、搞多 Agent 编排、搞 LangGraph 工作流的时候，这套”穷鬼”技术栈，能给我们什么启示？

一、先认识一下这套 $20 技术栈

Steve Hanov 不是无名小卒。websequencediagrams.com 很多人用过，eh-trade.ca 是他的另一个小众产品。这些产品的共同点是：用户真实付费、系统稳定运行、成本趋近于零。

他的部署方案可以用一句话概括：能用单机解决的，绝不加第二台机器。

1. 服务器：一台 $5 VPS

Steve 用的是 Linode 或 DigitalOcean 最便宜的机型，1GB 内存，每月 $5 到 $10。他说了一句特别狠的话：”1GB 内存在现代 Web 开发者听起来很恐怖，但如果你知道自己在干什么，完全够用。”

不够用怎么办？加 swapfile。就这么简单粗暴。

他特别看不上 AWS 的入门路径。”你 fire up AWS，provision 一个 EKS cluster，配一个 RDS，再搞个 NAT Gateway，一个用户还没来，一个月已经烧了 $300。”这话我越品越觉得对。AWS 的控制面板说到底就是一个迷宫，设计目标是让你不断点击”升级”。

2. 语言：Go 的单二进制魔法

在 1GB 内存的约束下，Python 和 Ruby 显得很奢侈。光启动解释器和 gunicorn workers 就能吃掉一半 RAM。Steve 的后端全用 Go 写。

Go 的好处他不厌其烦地列了几条：性能高、类型安全、LLM 容易理解和生成。但最重要的是部署体验。没有 pip install 地狱，没有虚拟环境，没有依赖冲突。你在笔记本上编译成一个静态链接的二进制文件，scp 到服务器上，直接运行。

他贴了一段”生产就绪”的 Go 代码，我看完沉默了：

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Hello, your MRR is safe here.")
    })
    http.ListenAndServe(":8080", nil)
}

就这几行。他说这能在一台”土豆服务器”上轻松扛住每秒几万请求。我起初不信，但后来想到 Go 的 net/http 确实是直接编译进标准库的，没有框架 overhead，也就释然了。

3. 数据库：SQLite，但不是你以为的 SQLite

这是全篇文章最有争议也最有意思的部分。Steve 说他的所有产品一开始都用 SQLite 做主数据库。

大多数人听到这个反应是：”单机文件数据库？并发怎么办？”

Steve 的回应是：打开 WAL 模式。

1 2	PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL;

就这么两行。Write-Ahead Logging 开启后，SQLite 的读写锁机制发生了质变。读者不再阻塞写者，写者也不再阻塞读者。配合 NVMe 硬盘，单个 .db 文件就能支撑数千并发用户。

这不是玄学。Django 官方在 2024 年开始正式支持 SQLite 作为生产数据库选项。Tailscale 的 control plane 也是 SQLite 支撑的。Fly.io 甚至专门写过一篇文章，教用户怎么用 SQLite 跑生产负载。

4. AI：本地 GPU + OpenRouter

Steve 做 eh-trade.ca 的时候，需要对几千家上市公司做财报分析和摘要。最 naive 的做法是调用 OpenAI API，批量跑一遍可能花掉几百美金。如果 prompt 里有个逻辑 bug，还得重新跑一遍，再花几百。

他的解法：在 Facebook Marketplace 上花 $900 买了张二手 RTX 3090（24GB 显存），本地跑 vLLM。 upfront 投资一次性，之后批量处理再也不需要给 AI 厂商交过路费。

需要快速响应的聊天场景怎么办？他用 OpenRouter 统一接入 Claude、GPT 等模型。一个 OpenAI 兼容的 API 格式，换来无缝的 fallback 路由。Anthropic 的 API 周二下午挂掉？自动切到 OpenAI，用户无感知。

5. 开发工具：GitHub Copilot 的套利

Steve 的 AI 编程账单每月不到 $60。秘诀是买 GitHub Copilot，然后插在 VS Code 里用。他说微软的定价模型有个 bug：按请求收费，而不是按 token。一个”请求”就是你往 chat 框里输的一句话。哪怕 agent 接下来花 30 分钟遍历整个代码库、改几百个文件，你还是只付大约 $0.04。

他的策略是：写极详细的 prompt，附带严格的验收标准，然后对 agent 说”keep going until all errors are fixed”，按下回车，去泡杯咖啡，让 Satya Nadella 补贴你的算力成本。

二、这对 AI Agent 部署意味着啥

好了，前菜上完了。现在进入正题。当我们谈论 AI Agent 部署的时候，为什么要在意一个加拿大 indie hacker 的省钱绝活？

因为 Agent 系统有一个致命特点：它们很难在本地跑完整个生命周期。Agent 需要状态管理、需要长时记忆、需要多轮对话、需要工具调用、需要和其他 Agent 协作。这些东西天然地推着我们往”重基础设施”的方向走。

LangGraph 的 StateGraph 需要持久化。长期记忆要向量数据库。多 Agent 系统要消息队列。生产环境要容器编排、服务发现、负载均衡、监控告警。一层一层叠上去，成本就失控了。

但 Steve 的技术栈给我们提供了一个反向视角。在验证阶段和早期增长阶段，我们真的需要这些吗？

启示 1：Agent 的”状态”不一定需要分布式数据库

现在的 Agent 框架默认推荐 Redis 或 Postgres 做状态持久化。LangGraph 的 checkpointing 接口确实设计得很漂亮，但如果你只有一个 Agent 在跑，每天处理几百个会话，SQLite 完全能扛住。

想想看，一个典型的客服 Agent，每个 session 的 state 不过几 KB 到几十 KB。一天 1000 个会话，一年也不过几百 MB。SQLite 的文件锁在 WAL 模式下对读操作几乎无影响，写操作也是毫秒级完成。对于这种数据规模和访问模式，Redis 和 Postgres 是性能过剩，Redis 和 Postgres 的运维成本才是真实负担。

启示 2：静态二进制部署是 Agent 系统的理想形态

Agent 应用通常包含大量依赖：LangChain、LangGraph、各种 tool integrations、向量数据库客户端、HTTP 客户端。Python 的依赖管理在这个场景下是一场灾难。我见过太多”本地能跑、服务器挂掉”的案例，原因无非是某个 transitive dependency 版本不对。

Go 的单二进制部署模式，对 Agent 系统来说是一种解毒剂。整个应用就是一个文件，scp 到服务器上就能运行。回滚也简单：保留上一个版本的二进制文件，出问题瞬间切回去。

当然，这并不意味着所有 Agent 系统都必须用 Go 写。Python 生态的丰富性无可替代。但如果我们能在架构设计上往”可静态打包”的方向靠，部署复杂度会大幅下降。比如用 uv 或 PyOxidizer 把 Python 应用打包成单文件，或者把 Agent 的核心逻辑抽成 Go 微服务，Python 只做模型推理层。

启示 3：本地模型是批量 Agent 任务的终极降本方案

很多 Agent 系统的设计里，所有推理都在云端完成。这没问题，直到你开始跑批量任务。

想象一个内容审核 Agent，需要对论坛里的每一篇帖子做分类和标签提取。如果论坛每天有 10 万条新帖子，每条帖子调用一次 GPT-4 mini，按 $0.15 / 1M tokens 算，一个月轻松烧掉几千美金。

但如果你本地有一张 24GB 显存的卡，跑 Qwen3-32B 或 Llama 3.3 70B（量化版），这些批量任务的边际成本就是电费。Steve 用 vLLM 的 PagedAttention 技术，把 16 个异步请求 batch 在一起处理，总耗时和单条差不多。这种吞吐量模式下，本地 GPU 的经济优势是碾压性的。

启示 4：OpenRouter 式的模型路由是 Agent 系统的必选项

Agent 系统对模型可用性的要求比普通应用高得多。一个客服 Agent 如果因为某个 API 挂了而停止响应，用户体验是灾难性的。

OpenRouter 的价值不只是比价，而是提供了一层”模型可用性保险”。Agent 系统应该设计成不绑定任何单一模型提供商，而是能根据响应时间、可用性、价格动态切换。这层抽象本身不复杂，但对生产环境的稳定性至关重要。

三、和”重编排”部署方式的硬核对比

为了让你更直观地理解差距，我做了一张对比表。

维度	Steve 的 $20 栈	主流企业级 Agent 部署
服务器	$5 VPS × 1	AWS EKS / AKS / GKE
月基础设施成本	$20	$500 ~ $5000+
数据库	SQLite (WAL)	Postgres + Redis + 向量库
部署方式	scp 单二进制	Docker + K8s + Helm + CI/CD
运维人力	几乎为零	0.5 ~ 2 个 DevOps
AI 推理	本地 GPU + OpenRouter	纯云端 API
启动到上线	分钟级	天级甚至周级
扩展路径	垂直升级 VPS	水平扩容集群

这些数字不是我瞎编的。AWS EKS 的控制平面费用是每月 $72 起步，这还只是 Kubernetes 的管理费。加上 worker nodes、负载均衡、NAT Gateway、CloudWatch，一个小型集群每月轻松过 $500。如果你还要上 GPU 实例做推理，A100 实例每小时 $2.75 ~ $3.26，一个月跑满就是 $2000+。

2025 年 markaicode 的一份企业 AI Agent 部署成本报告显示，在三大云平台上，单个 Agent 的平均月运行成本：AWS 约 $7850，Azure 约 $7200，GCP 约 $6750。这个数字包含了计算、存储、网络、支持和监控，但即便如此，也足够买 300 多台 Steve 的 VPS。

当然，企业部署有其合理性：SLA、合规、多区域、高可用、专职团队。但问题在于，很多 indie 开发者和早期创业团队，在没有这些需求的时候，就被”最佳实践”绑架了。

你明明只有 500 个日活用户，却已经搭了一套三可用区的 K8s 集群。你的 Agent 每天处理 200 个会话，却已经上了 Redis Cluster 和向量数据库。这不是未雨绸缪，这是提前自杀。

四、一套可执行的 Agent 部署降本方案

理论聊完了，下面是实操。我把 Steve 的思路和 AI Agent 的特点结合了一下，整理出一套分阶段的部署方案。

阶段 1：MVP 验证期（0 ~ 1000 用户）

目标让 Agent 跑起来，验证 PMF，成本控制在 $50 / 月以内。

服务器：一台 2GB 内存的 VPS（$5 ~ $10 / 月）
后端语言：优先 Go，或把 Python 核心逻辑打包成单文件部署
数据库：SQLite + WAL 模式，用一个 .db 文件存所有状态
Agent 框架：尽量轻量，能用原生 HTTP + SSE 就不用重量级框架
AI 模型：日常交互用 OpenRouter 接廉价模型（如 Gemini Flash、Qwen-Turbo），复杂推理按需切到 Claude/GPT
进程管理：systemd 或 supervisord，不需要容器

这个阶段的核心原则是：每一个新增的组件都必须有明确的理由。”以后可能会用到”不是理由。

阶段 2：早期增长期（1000 ~ 10000 用户）

目标在用户体验不下降的前提下，成本控制在 $200 / 月以内。

服务器：升级 VPS 到 4GB 或 8GB 内存（$20 ~ $40 / 月），或者增加一台专门的推理服务器
数据库：如果 SQLite 的写并发确实成为瓶颈，考虑迁移到单节点 Postgres。向量搜索先用 pgvector 插件，不要急着上专门的向量数据库
缓存：用本地 Redis 实例（不需要 Cluster），缓存常见的 Agent 响应
AI 模型：批量任务逐步迁移到本地 GPU。$1000 左右买一张二手 RTX 3090 或 4090，跑 vLLM 或 Ollama
部署：如果团队有 Docker 经验，可以容器化，但不需要 Kubernetes。Docker Compose 就够了

阶段 3：规模化期（10000+ 用户）

目标根据实际负载决定是否需要”企业级”架构。

到了这个阶段，你已经有真实的监控数据和用户反馈了。如果单台 VPS 确实扛不住了，再考虑：

是否需要 K8s？（通常答案是：除非有专职 DevOps，否则不需要）
是否需要专门的向量数据库？（看查询延迟是否真实影响了用户体验）
是否需要多云部署？（看你的用户是否分布在全球）

很多产品其实 never 需要走到这一步。Basecamp 的用户量够大了吧？他们直到很后期才上复杂架构。SQLite 之父 D. Richard Hipp 的公司，核心产品一直跑在单机上。

五、几个具体的技术选择建议

1. 为什么 SQLite 可以扛住

很多人对 SQLite 的并发能力有误解。在 WAL 模式下：

读操作完全不会阻塞其他读操作
读操作不会阻塞写操作
写操作会短暂阻塞其他写操作，但一次写操作通常只需几毫秒

对于 Agent 系统来说，state 的写入频率其实不高。一个多轮对话的 Agent，state 只在每轮对话结束时写一次 checkpoint。即使是 1000 并发用户，写冲突的概率也极低。

如果你还是担心，可以用连接池 + 写队列进一步平滑写入压力。或者更简单地，把读频繁的表和写频繁的表拆成两个 SQLite 文件。

2. Go 在 Agent 领域的适用性

Go 不是 ML 语言，但它在 Agent 系统的”非推理部分”表现出色：

HTTP API 和 SSE：Go 的标准库就能写出高性能的服务端推送
并发模型：goroutine + channel 非常适合多 Agent 的协作和消息传递
静态链接：部署简单到令人发指
LLM 友好：Go 的语法简洁明确，Claude 和 GPT-4 生成 Go 代码的准确率很高

我的建议是：把 Agent 的编排层、状态管理层、工具调用层用 Go 写，把模型推理层交给 Python（本地 vLLM 或远程 API）。这种分层架构既有 Go 的部署优势，又不牺牲 Python 的模型生态。

3. 本地 GPU 的投入产出比

以 RTX 3090（24GB 显存，二手约 $900）为例：

跑 Qwen3-32B（awq 量化），并发 4 ~ 8，每秒能输出 40 ~ 80 tokens
跑 Llama 3.1 70B（4-bit 量化），并发 1 ~ 2，适合重推理任务
跑 embedding 模型（如 bge-m3），批量处理速度远超云端 API

假设你每天处理 5000 条批量任务，每条任务在云端用 GPT-4 mini 花费 $0.001，一年就是 $1825。本地 GPU 一年半就回本，之后全是利润。而且批量任务对延迟不敏感，本地 GPU 的速度劣势完全可以接受。

4. OpenRouter 的替代方案

如果你不想依赖第三方聚合商，可以自己搭一层路由：

type LLMRouter struct {
    providers []Provider
}

func (r *LLMRouter) Chat(ctx context.Context, req ChatRequest) (ChatResponse, error) {
    for _, p := range r.providers {
        resp, err := p.Chat(ctx, req)
        if err == nil {
            return resp, nil
        }
        log.Printf("provider %s failed: %v, trying next", p.Name, err)
    }
    return ChatResponse{}, errors.New("all providers failed")
}