我的 Agent 系统已经跑了一段时间。内容流水线跑通了、多 Agent 协作验证了、安全引擎上线了。看起来进展不错。
但我知道一个事实：当前的架构撑不过三个月。
问题一：Agent 跑在我的笔记本电脑上。 关机就断，出差就断。内容产出的越多，数据越值钱，本地跑的风险越大。
问题二：子 Agent 依赖父进程。 我用 delegate_task 派研究 Agent 去干活，如果我这边中断了，研究的成果就丢了。父进程崩溃，子任务静默死亡。
问题三：所有 Agent 共享一套配置和记忆。 总控节点随时可以越权去抢执行者的活——不是制度问题，是架构问题。
问题四：没有质量门。 每篇文章的质量标准全在我脑子里。没有系统级保障。
问题五：知识沉淀靠手动。 每次踩坑记一条记忆，但记忆只是一条文本。不能检索，不能跨 Agent 共享，不能自动提炼为 Skill。
| 维度 | 作坊模式 | 工厂模式 |
|---|---|---|
| 运行 | 本地电脑，关机就停 | 云端 7x24 |
| 任务 | 进程内，父崩子亡 | SQLite 持久化看板，崩溃后接管 |
| 角色 | 一个 Agent 什么都能干 | 专业 Profile，工具隔离 |
| 质量 | 靠人审 | 系统级三道质量门 |
| 知识 | 手动记一条文本 | 自动分析执行轨迹，提炼 Skill |
| 安全 | 靠 Agent 自觉 | 物理工具白名单，想越权也没工具 |
这不是"更好的做法"，是"不同量级的做法"。 作坊做到 10 篇文章没问题，做到 100 篇就会出问题。工厂从第一天就是为 1000 篇设计的。
我不可能一夜之间从作坊变成工厂。四个阶段，每个独立交付。
Hermes 从本地搬到云服务器，systemd 守护，Docker 隔离。7x24 在线，关电脑也不断。
引入 Hermes 内置的 Kanban 看板（SQLite 持久化，无需开发）。创建研究员/写手/审计员/发布员 4 个 Profile，每个只有自己需要的工具。总控只保留 kanban 工具，物理上没法越权。
你发消息 → 总控 kanban_create 四个任务（带依赖）
├── 研究员（只有搜索+阅读工具）
├── 写手（只有文件读写工具）
├── 审计员（只有只读工具）
└── 发布员（只有构建部署工具）
↓ 调度器依次拉起 → 完成 → 通知你进程崩溃任务不丢，每个 Agent 各司其职，总控想抢活也没工具。
三道质量门：L1 自验证（输出检查）→ L2 证据验证（哈希校验）→ L3 交叉评审（独立评分）。
Kanban 执行轨迹 → 自动分析高频模式 → 生成 Skill 候选 → 你审批 → 注册。越用越强。
| 先做 | 原因 |
|---|---|
| 上云 | 信任问题。系统关个电脑就没了，你敢放心用吗？ |
| Kanban | 可靠性问题。进程崩溃任务丢失，产出越多损失越大 |
| 质量 | 规模问题。10 篇文章可以手审，100 篇审不过来 |
| 进化 | 效率问题。手动维护 Skill 是当前最轻的负担 |
第一阶段做完解决"信任问题"。 有了信任，才能放心地把更多事交给系统。
1. 诊断你的架构在哪个阶段。 你的 Agent 跑在哪？任务崩溃了会丢吗？如果答案是"本地"和"会丢"，你也在作坊阶段。知道自己在哪才能知道往哪走。
2. 从"上云"开始。 别从"多 Agent"或"质量门"开始。先让系统 7x24 在线，再加功能。顺序错了，功能越多风险越大。
3. 了解你手上的工具已经有什么能力。 我要承认一个错误：我写方案的时候以为 Kanban 是要自己开发的。后来才发现它已经在我的 Hermes Agent 里装好了，连数据库都已经存在。少走弯路最快的方式，是先搞清楚工具已经给了你什么。
打开你的终端，运行 hermes kanban stats —— 看看你的 Agent 是否已经支持持久化任务看板。你可能会发现，你离工厂只差一个配置的距离。
💬 评论