🛰️ 新总专题 Managed Agents · Meta-Agent · Runtime / Daemon / Board

(Managed) Meta-Agent
学会去管理 agent，而不只是再开一个 agent

这条专题讨论的不是“哪个模型更聪明”，而是：当一个团队里同时跑多个 agent 时，谁来调度、谁来记忆、谁来隔离、谁来把结果回收到一个可管理的工作台里。
这也是为什么 `Claude Managed Agents` 一出来，开源社区立刻出现了 Cabinet 和 Multica 这样的回应路线。

先看结构对照 进入庖丁解牛入口

为什么现在应该把它单独立成大专题

过去很多人把 agent 理解成“一个终端里的一个会话”。但一旦你要同时让多个 agent 写代码、跑测试、监控服务、读文档、做 review，这个抽象就不够了。

不再只是单 Agent

问题不再是“Agent 会不会做”，而是“多个 agent 怎么不打架、怎么恢复、怎么并行”。

控制面开始成型

Board、daemon、runtime、container、session log、connector、skill library 开始成为正式层，而不是零散脚本。

LikeCode 也会走到这里

我们自己的 workspace、codex-loop、connector shell，本质上也正在从“单任务代理”走向“managed agents shell”。

Claude Managed Agents 到底讲清了什么

这条官方路线真正有价值的，不是“Anthropic 又发了新功能”，而是它把 agent 拆成了更清楚的三层：

大脑

模型 + 调度器，负责规划和决策。

手

一次性的 sandbox / container，负责执行；挂了就换，不和凭证直接耦合。

记忆

append-only session events，让 agent crash 后还能恢复。

这套拆法有个很强的启发：Managed Agents 不是更强的单个 agent，而是一个“谁来管 agent”的基础设施层。

官方锚点：Claude Managed Agents

这页关注的不是营销文案，而是它如何把 runtime、container、安全隔离和 event log 组合成正式运行时。

现在至少要区分三种路线

样本 更像什么 控制面在哪 持久状态在哪 最值得学什么
Claude Managed Agents 基础设施层 managed runtime + container + event log session events、sandbox state、vault 脑/手/记忆彻底解耦，agent 不再直接等于终端会话。
Cabinet knowledge-first startup OS 知识库、agent team、cron jobs、web terminal markdown on disk + git history 上下文工程怎样变成团队知识库，而不是会话临时上下文。
Multica managed agents project board board、Go backend、local daemon、workspace Postgres + runtime registry + skill compounding 怎么把多个 coding agents 变成“像同事一样被派单”的队友。
Superset orchestration shell host-service、workspace/worktree、panes terminal / worktree / pane state 如何在工作台外层调 inner agent，并维持可见工作位。
Managed / Meta-Agent 四条路线总图

庖丁解牛入口：不要只看概念，要看工程壳层

🗄️ Cabinet 解构

看它如何把 markdown knowledge base、Git history、AI team、scheduled jobs 与 web terminal 收成一个 AI-first startup OS。

进入 →

🧷 Multica 解构

看它如何把 board、workspace、local daemon、runtime 和 skill compounding 收成一个更接近 managed agents 的开源替代。

进入 →

🛰️ Superset 解构

看外层 orchestration shell 怎样调 inner agent，适合和 Managed Agents 路线做对照。

进入 →

用 GitHub 搜索 skill 补出来的相关候选

除了 `Cabinet` 和 `Multica`，这一轮还用仓库搜索技能补看了几类更大的 managed / orchestration 平台。

基础设施 / orchestration 大盘

agno、trigger.dev、symphony、swarm

更适合当“Managed Agents 更大背景”的候选，不一定都要单独开页。

更接近多 agent 指挥台

ruflo、mission-control、kiwiq、routa

这些更像 `Cabinet / Multica / Superset` 的同类或邻居样本，后面值得继续筛。

当前判断

这条专题下一步最值当的不是继续 clone 一堆仓库，而是先把 knowledge-first 与 runtime-first 两条主线写清楚。

这条专题最顺的展开路线

第一步：先固化总页

把 `Managed Agents / Cabinet / Multica / Superset` 放到同一张结构图里，先固定“谁更像基础设施、谁更像工作台”。

第二步：做 Cabinet / Multica 解构

把最有代表性的两个开源样本拆成庖丁解牛子页，而不是只在总页里挂几句摘要。

第三步：回写到 LikeCode

把 `workspace shell / connector shell / runtime-daemon-connector` 这些设计讨论回写到我们自己的工程里。

第四步：补更多邻居样本

等总页和两篇子页稳定后，再继续引入 `ruflo / mission-control / kiwiq` 等更像 managed control plane 的候选。

一句话收尾：Meta-Agent 专题的重点不是“再找一个更强 agent”，而是“谁来管理 agent，以及怎样把 agent 变成可运营的系统层”。