Cabinet 解构 - (Managed) Meta-Agent 专题

01 · 为什么 Cabinet 值得单独拆

`Cabinet` 的关键，不在于“它也有 agent”，而在于它把上下文问题收成了一个产品原则：上下文不是聊天窗口里的临时附属，而是整个团队知识库本身。

从 README 看，它的核心口号不是执行引擎，而是 Your knowledge base. Your AI team.。也就是说，Cabinet 先假定：如果没有持久知识库，再好的 agent 也会不断忘记、不断重来。

阅读路径先看五层再看控制面重点读 Git memory 最后看 AI team

01Markdown Knowledge Base上下文可见、可改、可版本化

02Git-backed Historyauto-commit · diff viewer · rollback

03AI Team Templates角色、部门与任务语义

04Scheduled Missions让 agent 在知识库里持续工作

05Web Terminal / Internal ChatCLI 与知识库工作台接回同一壳层

层次	关键锚点	解决的问题
知识库层	markdown on disk、WYSIWYG + Markdown、embedded HTML apps	上下文从哪来，如何可见、可改、可版本化
历史层	Git-backed history、auto-commit、diff viewer	记忆如何有版本、能回退、能审计
团队层	20 个 AI team templates、departments	agent 不再只是孤立 worker，而是团队角色
调度层	scheduled jobs、missions & tasks	如何让 agent 在知识库里持续工作，而不只等待人工点一下
交互层	web terminal、internal chat	怎样把 CLI 与知识库工作台接回同一壳层

如果说 `Managed Agents` 更像“先把 runtime 和隔离壳搭好”，那 `Cabinet` 的主脑更像是 knowledge base + agent team + scheduled work 这组组合。

这条路线回答的是另一个问题：当 agent 真要长期工作时，它们吃的不是 prompt，而是 沉淀在知识库里的项目语义、页面、历史、任务板和团队角色。

Cabinet 这条线最值得我们学的，是它把 Git everything 直接写成原则。这里 Git 不是开发者工具，而是 agent memory 的历史系统。

这和我们做 `codex-loop` 的 `plan + evolution + task board` 很接近，只是 Cabinet 更激进：它把页面本体、HTML app、cron 任务、知识结构都尽量推回文件系统和 Git 历史里。

Markdown Knowledge Base + Rich Editor 页面、HTML app、项目语义和上下文都先落到文件系统

AI Team + Missions + Scheduled Jobs 角色、任务和定时工作让 agent 围绕知识库持续行动

CEO CTO Marketing Ops

Web Terminal + Internal Chat CLI 和协作消息不再游离在知识库之外

Git-backed History knowledge compounds over time：每次变化都有 diff、commit 和回滚点

它预置的不是单个 coder，而是一整套 CEO、CTO、Marketing、Analytics、Ops 等模板。这个动作很重要：它把 agent 从“工具调用器”抬成了“团队角色容器”。

这说明 Cabinet 不只是一个 CLI 代理面板，它更像是：让知识库、角色、定时任务和终端工作位合并成同一个 startup OS。

第一，上下文工程不要只停在 prompt engineering，要把 durable knowledge base 视为正式层。

第二，Git 不只服务代码，也可以服务 agent memory 的历史、回滚和审计。

第三，`AI team` 这个概念很适合给我们后面的 workspace / connector / task board 做更高层的人机叙事。

第四，Cabinet 更像 knowledge-first managed shell，不要误把它当成和 Multica 一样的 runtime-first 平台。