设计一个极简资源占用的个人助理智能体

在资源受限的环境（例如 512MB 内存、1 个共享 vCPU 的 VPS）中部署 AI 智能体，最大的挑战不是模型推理能力，而是常驻进程的内存占用与不可控的运行开销。

本文分享一套极简智能体方案，核心设计目标是：空闲时接近零开销，按需拉起重组件。

一、 核心设计原则

1. 架构：单一常驻进程 + 按需子进程。
2. 推理：本地不跑模型，所有推理走远程 API。
3. 存储：大部分数据存储在 SQLite 和普通文件中，不依赖复杂的中间件。
4. 按需拉起：重型任务（如浏览器自动化）运行时加载，任务结束立即释放。

二、 架构实现方案

1. 网关与路由

• 网关：采用 Telegram 等单一渠道，利用 httpx 实现长轮询，不引入庞大的 bot 框架，不开 Webhook 服务端口。
• 零 AI 路由：在进入 LLM 之前，先进行命令前缀和规则匹配。命中确定性技能则直接执行，不调用 LLM。这层路由通常能过滤大部分低价值请求，节省 API Token 和运行资源。

2. 调度与状态机

• 状态机：手写简单的 asyncio 状态机（约 150 行），限制最多 3 到 4 步。通过结构化的 action_type（tool_call, clarify, cannot_proceed, done）解决智能体"只计划不执行"的问题。
• 调度：弃用复杂的 APScheduler，使用 SQLite 任务表结合一个"睡到下一个到期任务"的协程进行调度。若要求极致，可利用 systemd timer 在需要时唤醒进程。

3. 记忆与工具管理

• 记忆：核心数据采用 SQLite + FTS5 全文检索，避免部署笨重的向量数据库。夜间通过远程任务进行压缩和去重。仅在确实需要语义检索时，配合远程 embedding 和 sqlite-vec 按需启用。
• 工具：实施风险分级注册表。高风险动作需走 pending_confirmation 闸门。MCP 服务以 stdio 子进程方式懒启动，用完即退。浏览器自动化是最大内存开销项，强制单实例，任务结束立即 Kill。

4. 安全与可观测性

• 安全：凭证与 Agent 核心进程分离，由工具层独立持有，Agent 仅发起请求。
• 可观测性：使用 SQLite 表记录日志并配合日志轮转，不本地部署 Langfuse，需要可视化时利用云端免费版。

三、 资源预算表（估算）

硬限制方案：写入 systemd 配置（MemoryMax=400M, CPUQuota, TasksMax），并配少量 zram。超限时由 systemd 杀掉子进程，确保主进程稳健。

四、 框架取舍

• 避开臃肿依赖：建议弃用 LangGraph / LangChain。其依赖链带来的常驻开销往往在百兆量级，在小内存机器上性价比极低。
• 极简依赖列表：仅保留 httpx (通信)、sqlite3 (存储)、pydantic (输出校验)。
• 性能极限优化：如仍需进一步压缩，可考虑将网关层迁移至 Go 或 Rust，将常驻内存降至十几 MB，但这会增加开发复杂度。

总结：最容易超预算的三处

1. Chromium 浏览器进程：必须严格生命周期管理。
2. MCP 子进程遗留：确保用完即退。
3. 记忆注入内容：Prompt 越积越长，需严格设置 Token 预算上限。

本文基于 Hermes-Lite 自动化运维经验整理。