No. 35: 我把悟空推倒重来，少即是多

13 天前，我还写了一篇《我给悟空补了一个后台，才发现 Agent 最难的不是回答》。那时候，Dashboard 让运行状态、权限、恢复和投递终于变得可见，我确实认为它是悟空走向可用的重要一步。

现在，我把它删了。

一起被删掉的，还有 MongoDB、Chroma、独立 Knowledge、Workflow、Worker、多 Agent 组织、OpenTelemetry 和服务器部署路径。这些能力都有各自合理的设计逻辑，其中不少还经过了测试和真实运行。但当我重新回到悟空的产品目标，最该问的已经不是「它们能不能工作」，而是「它们是不是必须存在」。

复杂度往往来自没有发生的未来

悟空在多轮迭代里逐渐拥有了很多「生产级 Agent 应该有的东西」：后台管理、多层记忆、向量投影、工作流、子代理、权限治理、可观测性和多条恢复路径。

每一次增加都有理由。任务变长，就需要 Dashboard；记忆变多，就需要向量检索；能力变复杂，就需要 Workflow 和 Worker；状态变多，就需要更完整的观测与治理。

问题是，这条逻辑可以永远延伸下去。系统会越来越像一个能服务任意组织、任意角色和任意场景的 Agent 平台，但悟空的真实用户从头到尾只有我一个。我真正反复使用的场景，也很集中：从 Telegram 发出需求，让它查资料、核对信息、形成判断，再把结果送回来。

当系统的主要成本已经用来支撑还没有发生的未来，「架构完整」就可能只是另一种过度设计。

我用五个「一」重新定义悟空

这次重构开始时，我先停止讨论模块，只问五个问题：谁在使用，从哪里进入，核心任务是什么，哪份数据算真，什么时候才算交付完成。

最后得到的边界很小：一个主人、一台 Mac、一个 Telegram 入口、一个 Agent Loop、一个 SQLite 事实源。

Telegram 继续是日常入口，因为它解决了随时发起任务和接收结果的问题。Dashboard 被删除，本机运维收回到少量 CLI 命令和受控日志。系统不再因为一个人的个人 Agent，额外常驻一套 Web 服务器和管理面。

MongoDB 和 Chroma 被 SQLite 取代。运行、Session、记忆、定时任务、Artifact 和 Delivery 共享一个事实源，不再需要处理主库与向量投影之间的漂移。个人长期事实使用带来源的 Claim 和 SQLite 全文索引回查，网页、工具结果和模型推测不能自动变成我的当前画像。

场景策略也从内核里移了出来。内核只处理 Trigger、上下文、模型调用、工具边界、持久状态和交付；「如何做研究」放进 Research Skill。以后增加能力，优先增加可以被渐进加载的 Skill 和受控 Tool，而不是让内核重新长出一套编排系统。

删掉功能，不等于删掉能力

如果这次重构只是把目录和页面删少，它并不会让悟空更可靠。真正需要保留的，是那些由真实失败证明过价值的契约。

悟空仍然会在第一次模型调用前创建 Run，用 Step 和 Attempt 记录执行证据，所有 Tool 走同一个 Gateway。模型返回文字不等于任务完成；Telegram 取得外部 message ID，结果才算真正交付。如果进程中断，系统从 SQLite 恢复；如果某次操作的结果无法确认，它会停在 result_unknown，不会为了看起来顺畅而盲目重发。

长文可以分片送达，本地文件在校验哈希和路径后才能作为 Artifact 交付。Poe 是主 Provider，DeepSeek 只能在 Run 尚未固定时备用，不会在中途换一个模型猜测上一个模型做了什么。

这些契约没有让系统在功能列表上变得更长，却决定了我敢不敢真的把任务交给它。

少是一种可以验证的产品边界

「少即是多」很容易变成一句设计口号。对系统重构来说，它应该有更严格的含义：少一个事实源，就少一类数据漂移；少一条执行路径，就少一套恢复语义；少一个入口，就少一个权限与运维面；少一个没有真实用户的模块，就多一点时间去修正真正会失败的链路。

它也一定有代价。新悟空不再提供 Dashboard，不做多 Agent 协作，不是通用工作流平台，也不用向量数据库承诺「什么都能记住」。这些不是等待补齐的缺口，而是当前产品主动选择的边界。

我不再用系统里有多少模块判断悟空是否成长，而是看它能否稳定闭合一条真实链路：我发出任务，它在已授权边界内行动，用可回查的来源形成结果，失败时保留状态，最后把结果送到我手里。

系统的强大不应该由它能够容纳多少可能性来证明，而应该由它能够排除多少不必要的不确定性来证明。

少即是多，不是少做一些事，而是让每一件留下的事，都对最终交付负责。

项目：Wukong

← Writing