一台 Ubuntu，9 个 AI，和一堆想砸键盘的瞬间

我干电商运营。不做开发，但每天要处理的事情横跨数据、内容、合规、策略——一个人不可能全懂。用 AI 辅助早就是日常，但问题也来了。

开着聊天窗口来回切，每次换任务上下文全断。更烦的是重任务——比如一次全平台竞品分析——一个对话根本跑不完，等着它慢慢吐结果，什么也干不了。

所以搭了这套 Agent 系统。不是我有什么技术野心，纯粹是被逼的。

20→9：合并不是因为多，是因为乱

7 月底我把 Agent 从 20 个砍到了 9 个。

20 个的时候看着挺唬人。分工细，名字多，截图发群里能装一波。实际用起来呢？任务拆太碎，Agent 之间传话比干活还费时间，有一半 Agent 一个月用不了三次。

合并原则很简单：同一个能力域、同一种模型类型，捏在一起。别搞什么"专人专岗"，那是公司病。

现在 9 个：

小智 —— 调度中枢。它不干活，只管接需求、拆任务、分派、汇总。信条就一条："沉默 > 废话"。能不说话绝不多嘴，说了必须有信息增量。所有 Agent 的输出都经它汇总再给我，像一道闸门。

策略顾问 —— 原来三个角色：苏格拉底推演方案、摩根做商业分析、产品经理出需求。现在合并到一个，反正都是"先想清楚再动手"的事。

全栈开发 —— 原来有全栈工程师、提示词工程师、编排工程师三个。合并后所有代码相关都归它：写、改、重构、技术方案。

代码审查 —— 唯一没合并的角色。代码不能又当运动员又当裁判。

情报采集 —— 信息雷达+市场调研。web 搜索、数据抓取、竞品监控、行业动向，全包。

电商运营 —— 电商客服+营销策略+视频优化。千川投放、蝉妈妈数据、内容策略，带货相关的全在这。

内容创作 —— AI 写作官+小敏。文案、博客、社交媒体，文字出品的都归它。（这篇博客也是它帮我写的，我在旁边改。）

合规顾问 —— 法律顾问+税务顾问。合规审查、风险评估。

虾米 —— 单独留着。虾米有自己性格，塞不进任何分类。它自己就是一个分类。

看板：不靠刷新，靠流转

这套系统真正管用的地方，不是 Agent 本身，是任务怎么跑的。

早期小智直接 spawn 子代理干活。问题是——所有工具调用全堆在主对话里，一个 30 分钟的代码重构跑起来，我只能盯着屏幕发呆。不光发呆，还不知道它在干嘛。在执行还是在卡死？没人告诉我。

后来全改成 Workboard 看板模式。

任务进来 → 小智拆成子任务 → 创建卡片（标题、描述、优先级、指派谁）→ Agent 自己认领 → todo → running → review → done。每一步流转，我在飞书群都能看到实时状态。

每个 Agent 跑自己的通道，互不干扰。一个在重构代码，另一个同时在抓竞品数据，第三个在审合同。我等它们跑完看汇总就行。

模型也分三六九等

9 个 Agent 共用一套上下文数据库（OpenViking），但跑推理用的模型不一样。

glm-5.2：小智、全栈开发、代码审查用。逻辑和代码是强项。

deepseek-v4-pro：策略顾问、内容创作、合规顾问、虾米用。分析和创作强。

deepseek-v4-flash：情报采集、电商运营用。快就行，便宜更重要。

主模型挂了自己切备用。不用我操心，出问题了它比我先知道。

基础设施：简单到不能再简单

一台家里的 Ubuntu 服务器。对外通过火山引擎云服务器做 frp 隧道 + Caddy 反向代理，9 个子域名跑在 qzscloud.com 底下，全线 HTTPS。

不算 OpenClaw 框架本身和 Ollama 本地模型，整个系统就多跑了一个 Docker 容器——OpenViking。别的全是框架自带能力。没有微服务，没有 K8s，没有消息队列。

一个人用的系统，简单才是最大的可靠性。加东西之前先问自己：不加这个会死吗？不会就不加。

踩坑实录：修 bug 的时间比写代码长

上面写得挺顺，但搭的过程远没有这么体面。有些坑卡了我一两个小时，有些甚至影响到了日常——比如听歌。

Caddy reload ≠ restart

改了个路由规则，caddy reload 热重载。然后 9 个子域名全线挂了。不是 500，是 HTTP 000——连错误码都不给你。搜了半天，才搞明白：Caddy 会把运行状态写进 autosave.json 缓存文件，reload 只读缓存、不读配置文件。我改了配置但它看不到，两个版本冲突了。

正确操作：rm autosave.json && systemctl restart caddy。

reload 和 restart，两个字不一样，区别是你接下来半小时在干嘛。

131072 ≠ 128000

主模型突然持续 fallback 到备用，所有 Agent 回答质量肉眼可见下降。查日志、看配额、改配置，折腾了一个多小时。

最后发现 maxTokens 写成了 131072。128×1024，2 的幂次，程序员肌肉记忆。但火山引擎 API 硬限是 128000。差了 3072 个 token，API 直接不接。两个数看着差不多，天差地别。

2 的幂次是本能，但现实世界不讲这个。

模型加载 → swap 爆炸 → 歌卡了

最离谱的连锁反应。Ollama 加载 bge-m3 嵌入模型到显存，物理内存瞬间吃紧。8GB swap 被打满，系统 OOM 开始杀进程。然后 PipeWire 音频缓冲被挤出——我戴着耳机听歌，声音开始断断续续，卡成电报。

根因链条：加载模型 → 内存耗尽 → swap 爆炸 → OOM → 音频设备报错 → 歌卡了。

我搭一个 AI Agent 系统，最后的故障表现形式是"音乐卡了"。扩容到 16GB swap 才消停。

全栈运维教会我一件事：问题永远不出在你正在改的地方。它出在你以为没关系的那个角落，然后绕一个大弯来提醒你。

7 月跑了这些

回头看，这套东西这个月处理了不少活：

• Edge Gestures Xposed 手势模块全链路审查修复（20 个代码问题 → 修复 → 编译 → 单测 → 模拟器集成测试）
• MTA 转录系统 V2→V3 重构（后端 37 个源文件 + 9 张数据表）
• 云服务器全栈部署（frp + Caddy + DDNS + iptables + fail2ban 安全加固，就是前面踩坑那套）
• 20→9 Agent 大合并（workspace 重建、配置迁移、模型路由重配）
• OpenViking 全量数据迁移（三阶段导入：用户画像 + 经验 + 项目决策）
• 丘丘门户后台管理系统重构

全是后端工程。小智负责拆任务、派活、收结果。专业 Agent 负责干。我负责最后看一眼，拍板。

没有一件是小智自己从头干到尾的——这正是我要的。我不盯执行细节，只盯方向和决策。

还没想好下一步

现在这套框架的瓶颈不在机制，在模型能力。Agent 的行为还是靠静态规则驱动——AGENTS.md、SOUL.md，改规则靠我手动修。真正的"学习"和"自我改进"还很初级。

但够用了。我不急着加功能。先用着，等新的痛点自己长出来再说。

加功能容易，减功能难。暂时不做加法。