在资源受限的环境（例如 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 杀掉子进程，确保主进程稳健。

给本地 Agent 造一块看板（四）：极简单机派——一个二进制、一条命令

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 rgracey/kanban-mcp、nerkoman/agent-kanban、mintopia/cocopilot、AdamManuel-dev/task-kanban-mcp、SimonBlancoE/kanban-mcp。 元数据于 2026-10-08 经 GitHub API 一手核验。

一、这一派的共同追求：把"部署"这件事消灭掉

前两派都在解决"看板该放在哪"（仓库里 / 依赖图里）。这一派不关心这个，它的目标极其单纯：让一个人在一台机器上、用一条命令，把看板立起来。

于是它们的形态高度一致：

一个进程、一个 SQLite 文件、一个 HTTP 面（外加可选一个 MCP 面）。没有 Docker、没有外部数据库、没有鉴权体系。

这个追求是合理的——本系列的目标场景就是"单人单机"。但这一派的表现也最参差：它的能力上限不低（有的做到了相当完整的自动派单），可它的存活率是全系列最差的。

先把项目摆出来。

二、五个项目逐个看

2.1 rgracey/kanban-mcp（2★，无许可证，Go）—— 部署轻量度的满分答案

它是"单二进制"这个形态的教科书。

一个 Go 二进制里，SQLite + Web UI + MCP server 全部内嵌，零外部依赖，Web UI 在 :8080。功能上也有几个亮点：