一、Managed Agents 原理
1.1、诞生背景：从 "单体" 走向 "全托管"
随着大模型工具调用与自主决策能力持续升级，AI Agent 已逐渐深入研发各落地场景。
但单体 Agent 普遍存在「架构耦合、运维成本高、无法团队协作、能力沉淀复用难」等痛点，分析原因为：
多数单体 Agent 将推理循环、凭据管理、沙箱执行、状态存储、异常重试等基础能力全部耦合在单体代码中，新建智能体时需反复编写基础设施代码，开发效率低下；
同时各类 Agent 分散部署在不同终端与 AI 工具（Claude Code、Codex、OpenCode 等）内，任务无法统一分发、运行进度难以集中监控，单体落地经验也无法转化为团队可复用的通用能力。
在此背景下，Managed Agents（托管式智能体）作为新一代 Agent 工程化标准范式诞生，核心思路是：
将智能体决策逻辑与底层运行基础设施解耦，由平台统一托管调度、运行时、会话、安全沙箱全链路，
开发者只需聚焦 Agent 业务目标与能力定义，底层调度、资源、运维交由托管层实现。
目前 Anthropic、OpenAI 等主流厂商已陆续推出 Managed Agents 服务，而开源项目 Multica 是 Managed Agents 落地工程化、团队化协作的标杆实践，打通了托管理论到研发落地的全链路，实现人机混合团队一体化管理。
1.2、核心理念：解耦"大脑"与"双手"
Managed Agents 定义：一套用于大规模构建、部署和运行AI Agent的全托管基础设施，核心设计原理围绕组件解耦与分层抽象，解决长周期AI Agent开发和生产部署的痛点。
Managed Agents 设计思路：将智能体的「决策能力」（模型作为"大脑"）、「执行能力」（工具/沙箱作为"双手"）和「记忆能力」（持久化会话作为记忆）完全分离；
借鉴操作系统分层思想重构 Agent 架构，各模块独立演进提升整体系统的稳定性。解决了传统Agent开发中Agent代码粘连、环境崩溃导致任务中断等问题。
Managed Agents 核心模块：
Harness（可替换控制循环）：作为隔离模型实现与系统功能的抽象控制层，负责调度模型和路由工具，允许模型随时升级不影响系统稳定性，让针对特定模型的补丁可独立演进。
Sandbox（隔离执行环境）：提供独立的代码/文件执行单元，执行环境与核心系统物理隔离，避免工具调用异常或容器崩溃导致整体任务失败，将错误转化为可处理的单纯异常。
Session（持久化日志）：突破传统上下文窗口限制，将完整历史事件日志作为外部化记忆仓库，支持按需读取、回放历史和提取关键切片，解决长任务中信息存储与回溯的问题。
image
1.3、架构设计：四类基础对象
标准化 Managed Agents 体系由 Agent、Environment、Session、Events 四个实体构成，是整个架构的基础：
Agent（智能体模板）：能力定义载体，提前配置模型选型、系统提示词、可用工具集，一次定义可被无数任务复用，对应岗位 / 角色（代码审查 Agent、部署 Agent）；
Environment（运行环境）：隔离运行空间，区分本地终端、云端服务器、容器集群，限定文件系统、网络、资源上限，不同环境间执行相互隔离；
Session（任务实例）：Agent 在指定 Environment 中启动的单次执行任务，绑定任务 ID、起止状态、归属看板，完整贯穿「排队 - 派发 - 执行 - 完结」全生命周期；
Events（事件流）：全链路操作日志，所有思考、命令执行、报错、人工干预都生成不可篡改事件，作为观测、复盘、技能沉淀的原始数据源。
1.4、工作流程：托管运行全生命周期
Managed Agents 任务运行流程：
任务下发：业务侧（人工 / 系统）绑定任务至指定 Agent，平台写入任务队列；
轮询拉取：远端 / 本地运行时 Daemon 定时轮询队列，拉取待执行任务，创建独立 Session；
隔离执行：运行时初始化沙箱环境、注入密钥，调用 Harness 启动推理循环，按需调用外部 AI 工具；
状态上报：执行中实时推送 Events 事件，阻塞、异常自动更新任务状态并留言告警；
收尾归档：任务完成 / 终止后全量事件落库，优质执行链路可提炼为标准化可复用技能
二、Multica 介绍
2.1、Multica 定位
Multica 是一个开源的 Managed Agents 平台，定位为遵循 Managed Agents 架构规范、厂商中立的开源 AI 智能体团队协作平台。
Multica 目标并非自建Agent，而是搭建跨 AI Agent 的托管调度层，将分散在本地、多终端、多厂商（Claude Code、Codex、OpenCode）的智能体收拢，把 AI Agent 转化为人机团队内和开发人员平权的正式成员，落地 Managed Agents 工程化、团队化实践。
Multica 核心为解决行业几类典型痛点：
多 AI 编程工具碎片化，切换繁琐、无法统一管控；
Agent 孤立运行，无任务看板、无进度可视化，人工持续盯盘；
Agent 单次优质执行经验无法沉淀，重复造轮子、团队能力无法复利增长。
2.2、Multica 核心特性
a、Agent 即团队成员（Agent 角色化托管）：
落地 Managed Agents 中 Agent 实体定义，每个智能体拥有独立档案、名称、身份标识，在项目看板、Issue 评论区与人类开发人员并列；人工可像指派员工任务一样，直接将看板 Issue 分配至对应 Agent，Agent 可自主评论、更新任务状态、标注阻塞原因，实现统一人员（人 + AI）管理。
b、本地 Daemon + 云端管控的双层 Runtime（Environment 落地）
遵循 Managed Agents 环境隔离规范：
云端控制：Web 看板、任务队列、技能库、事件存储，统一做任务分发与全链路观测；
本地守护进程（Multica Daemon）：部署在开发者本机 / 业务服务器，自动扫描本机已安装的各类 AI 编程 CLI，作为本地化 Environment；
Daemon 每 3 秒轮询云端任务、15 秒上报心跳，任务数据、密钥、源码全程留存在本地机器，云端不触碰任何敏感业务数据，兼顾托管管控与数据合规。
c、全链路任务生命周期托管（Session 全流程管控）
遵循 Managed Agents 的 Session 生命周期：任务入队→Agent 认领派发→本地沙箱启动执行→实时进度上报→阻塞 / 成功状态变更→执行归档；全流程 WebSocket 实时推送运行日志，开发者无需值守，仅在代码评审、异常阻塞节点介入处理。
d、技能库沉淀（Events 价值复用）
依托全量 Events 事件数据，将 Agent 成功落地的代码审查、数据库迁移、项目部署等执行链路提炼为可复用 Skill（技能模板），存入团队公共技能库；后续新建同类任务可直接挂载已有技能，一次调优、全团队复用，实现团队 AI 能力复利增长，是 Multica 区别于普通 Agent 调度工具的核心差异化能力。
2.3、Multica 技术架构
Multica 后端采用 Go 开发高并发调度服务，前端基于 Next.js 实现类 Linear 看板 UI，PostgreSQL+pgvector 支撑技能语义检索；
整体分层完全对齐 Managed Agents 架构：上层 Web 管控面对应编排调度层、中间 Daemon 对应运行时 Environment 层、数据库事件存储对应 Session&Events 持久层，是开源领域最贴合原生 Managed Agents 设计规范的落地项目。
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ Next.js │────>│ Go 后端 │────>│ PostgreSQL │
│ 前端 │<────│ (Chi + WS) │<────│ (pgvector) │
└──────────────┘ └──────┬───────┘ └──────────────────┘
│
┌──────┴───────┐
│ Agent Daemon │ 运行在你的机器上
└──────────────┘ （Claude Code、Codex、OpenCode、Pi、
GitHub Copilot CLI、OpenClaw、Hermes、
Gemini、Cursor Agent、Kimi、Kiro CLI）
整体来看，Managed Agents 通过「决策 - 运行时 - 记忆」三层解耦，完成Agent从单体到可生产、可运维、可规模化的系统级升级，定义了下一代 Agent 工程的底层标准；
Multica 以开源产品形态，将抽象的 Managed Agents 理论落地为可开箱即用的协作平台，打通「理论架构→本地部署→团队落地→能力沉淀」全链路。
三、Multica 部署实操
3.1、模式选择
Multica 官方支持两种标准使用模式：
Multica Cloud（云端 SaaS 模式）：Multica 官方提供的 SaaS 版本，基于云托管，提供开箱即用的托管服务，无需自己部署。
Multica Self-Host 自部署（私有化部署）：Multica 官方提供的私有化版本，基于本地部署，需要用户自行部署，提供完全控制权和数据隐私保障。
对比维度 Multica Cloud（云端 SaaS 模式） Self-Host 自托管（私有化部署）
管控服务归属 Multica 官方运维云端服务（前端 + Go 后端 + PostgreSQL 数据库），工作区、任务数据、事件日志存储在厂商云服务器multica.ai 全栈服务（Web / 后端 / PG+pgvector）部署在企业自有服务器 / 机房，全量数据 100% 自留，无第三方存储数据
部署主体 用户仅安装本地 CLI+Daemon，无需部署服务端 运维人员使用 Docker Compose 部署整套服务，团队成员单独安装 CLI 对接自建地址
部署耗时 5 分钟完成单机接入，开箱即用multica.ai 服务部署约 10min，团队多节点分批接入
数据安全 敏感业务数据（代码、密钥）本地留存；任务元数据、看板记录存 Multica 云端，适合非涉密项目 全链路数据不出企业内网，满足金融、政企代码合规、数据不出域要求
运维成本 官方负责服务升级、数据库备份、高可用、安全补丁，用户只维护本机 Daemon 和 AI 工具 企业自行承担服务器运维、版本升级、数据备份、故障排查
定制能力 平台配置固定，无法修改底层参数、数据库、域名、权限规则 支持自定义域名、内网访问、权限策略、数据库配置、对接企业 SSO、内部 Git/Webhook
适用场景 个人开发者、小型初创团队、快速验证 Managed Agents 落地、临时试验 Agent 协作流程 中大型企业、涉密研发团队、私有化合规项目、需要对接内部 CI/CD 体系场景
扩容方式 直接在 Web 端添加新成员 Runtime，无需改服务 新增开发机安装 CLI 指向自建服务地址即可横向扩容
两种模式执行层完全一致（本地 Daemon + 本机 AI 工具执行任务），仅管控服务（后端、看板、数据库、工作区）部署位置不同，完美契合 Managed Agents「管控层与运行时解耦」核心设计思想。
可以结合实际诉求进行选择：
选Cloud：人力不足无运维、短期项目、快速验证、不在意任务元数据上云；
选自托管：数据合规要求高、内部私有代码仓库、长期规模化落地、需要内部系统打通。
3.2、前置依赖
前置只有一个：你本地已经装了至少一款 AI 编程工具（Claude Code、Codex、OpenCode、PI...等）中的一款。守护进程启动时会自动探测它们，没装任何一个的话守护进程会直接拒绝启动。
我的电脑安装了"Claude Code、Codex、OpenCode"，后续示例以这三者为例讲解。
3.3、Cloud 模式部署
步骤一：注册Cloud账号
访问 https://multica.ai/ 注册账号，创建工作区并进入看板；
步骤二：安装 Agent Daemon（可选 CLI 或 客户端）
CLI方式：MAC系统建议使用 Homebrew 安装：
brew install multica-ai/tap/multica
客户端方式：访问 https://multica.ai/download 选择对应系统版本下载安装即可。
步骤三：启动 Daemon 连接控制端
若选择CLI：运行 multica daemon 启动本地守护进程，自动连接云端服务，完成环境注册。
若选择客户端：启动 Multica 客户端，会自动引导跳转绑定云端服务，完成环境注册。
3.2、Self-Host 模式部署
步骤一：拉取项目 + 一键启动后端
终端执行如下命令即可，将会执行：
如果没有 .env 文件，从 .env.example 自动生成一份并生成随机 JWT_SECRET
拉取官方 Docker 镜像（PostgreSQL、Multica backend、Multica frontend）
用 docker-compose.selfhost.yml 启动全部服务
等后端 /health 端点准备就绪
补充说明：生产环境使用，建议参考文档文档定制 安全配置、邮件、端口 等配置。
git clone https://github.com/multica-ai/multica.git
cd multica
make selfhost
启动完成后，访问以下服务地址：
步骤二：首次登录 + 创建工作区
访问 http://localhost:3000 ，执行如下操作：
输入你的邮箱
从你配置的邮件后端（Resend 或 SMTP relay）收到的邮件里拿验证码；两者都没配的话，从 server 容器的 stdout 里抄 DEV Verification code 这行
登录后创建第一个工作区
步骤三：启动 Daemon 连接控制端
步骤同 Cloud 模式 模式步骤三，此处略。
四、人机Agent团队协同案例
4.1、团队组织设计
针对人机Agent团队协同，首先需要结合业务场景，进行团队组织设计，确定团队角色及职责。此处以 "全栈项目迭代开发" 为业务场景，落地实践人机多角色 Agent 团队协作。
针对研发需求交付流程，一般覆盖 「需求分析、方案设计、代码开发、代码审核、需求测试、项目部署」等环节。
其中"需求分析、方案设计、代码开发"类工作长耗时且低风险低，适合 Agent 角色执行；其他工作风险性相对高，短期（本文案例）持续让 人 来负责，未来考虑过度给 Agent。
基于上述分工思路，团队具体组织设计如下：
团队名称：汉兴三杰（墨萧张联盟）
团队角色：由 3 个 Agent 角色（队长、架构师、全栈工程师） + 1 个 人 角色组成；
前者负责 「需求分析、方案设计、代码开发」类工作，后者负责「代码审核、需求测试、项目部署」类工作。
Agent角色明细：
角色 职责定位责 权限边界
萧何（队长） 团队唯一对外交互入口，全流程总调度，承担「任务拆解、进度追踪、结果汇总」核心职能，是整个小队的定盘星 仅负责调度整合，不参与具体方案设计、不编写执行落地代码，所有具体工作全部委派给对应角色，绝不越界。
张良（架构师） 方案输出核心，承担「信息调研、复杂任务方案设计」核心职能，是连接需求与落地的核心枢纽 仅输出设计方案，不参与具体落地执行；遇到需求调整仅修改方案，不越界修改执行成果。
墨子（全栈工程师） 长周期任务执行核心，承担「长时间、独立复杂任务执行」核心职能，是将纸面方案转化为实际成果的攻坚者 仅在方案设计范围内完成执行，不自行修改整体框架、不扩展超出需求范围的额外功能；所有超出边界的需求统一返回协调者重新处理，不私自调整方案。
Agent角色指令：
萧何（队长）：
核心定位
团队唯一对外交互入口，全流程总调度，承担「任务拆解、进度追踪、结果汇总」核心职能，是整个小队的定盘星
详细职责
- 接收用户原始需求，将模糊、笼统的需求拆解为粒度合理、可独立执行的标准化子任务，按照角色分工有序推送任务，不越位安排工作
- 全程追踪各角色任务进度，当任务卡点、输出不符合要求时自动触发重调度，保障流程不阻塞，同步各节点信息避免信息断层
- 最终汇总规划师的方案文档、工程师的执行成果，整合为逻辑清晰、可读性强的完整交付内容，统一输出给用户
- 管理全局对话上下文，过滤无效交互、压缩冗余信息，提升协作效率，降低不必要的资源消耗
权限边界
仅负责调度整合，不参与具体方案设计、不编写执行落地代码，所有具体工作全部委派给对应角色，绝不越界。
张良（架构师）
核心定位
方案输出核心，承担「信息调研、复杂任务方案设计」核心职能，是连接需求与落地的核心枢纽
详细职责
- 根据协调者拆解的任务，完成外部信息检索、行业方案收集、竞品分析、依赖信息整理，输出客观中立的调研结论，不掺杂主观预判
- 基于调研结果输出结构化、可落地的完整方案：包含整体框架拆分、模块接口定义、路径选型对比、执行步骤排序、潜在风险标注；方案明确区分必做项和可选项，给后续执行留出清晰空间
- 输出方案后自行完成可行性校验，遇到信息缺失会明确标注不确定范围，不编造结论，不给后续执行传递错误指引
权限边界
仅输出设计方案，不参与具体落地执行；遇到需求调整仅修改方案，不越界修改执行成果。
墨子（全栈工程师）
核心定位
长周期任务执行核心，承担「长时间、独立复杂任务执行」核心职能，是将纸面方案转化为实际成果的攻坚者
详细职责
- 严格遵循规划师输出的设计方案，独立完成代码开发、功能调试、配置修改等落地工作，全程不需要协调者介入细节，可支持长时间离线/后台执行
- 完成开发后自动开展基础功能自测，自行修复语法错误、简单逻辑缺陷、依赖冲突等常见问题；仅当遇到方案层面的冲突、设计漏洞时，才将问题返回给协调者重新调度规划
- 执行完成后输出清晰的交付清单：包含变更记录、环境依赖说明、部署启动步骤，明确标注需要用户手动调整的内容，不遗留不可追溯的黑箱修改
权限边界
仅在方案设计范围内完成执行，不自行修改整体框架、不扩展超出需求范围的额外功能；所有超出边界的需求统一返回协调者重新处理，不私自调整方案。
Multica 系统截图：
Multica Squad：团队设置 + 成员组织（3xAgent + 1x人）。
image
Multica Agent：Agent角色的设置类信息。
墨子为例，设置信息包括：运行时（本地MacMini + OpenCode） + Agent 模型（DeepSeek） + 技能（design-taste-frontend） + 指令等。
image
Multica 运行时：我的电脑上安装了 Claude、Codex 和 OpenCode，如下图全部识别可用。
image
4.2、团队协同规则
团队协同规则通过Squad指令来承载，Squad指令会在 Leader 智能体处理分配给该小队的 issue 时注入到它的 prompt 中。用来给 Leader 提供贯穿全队的指导、协作规范，或每次任务都应遵循的上下文。
Squad指令设计：
小队定位
面向闭环落地类复杂任务的专业化多智能体框架，分工清晰无冗余，适配「需求→设计→落地→交付」全流程
角色1：主协调者 萧何
核心职能：任务拆解 → 进度追踪 → 结果汇总
- 唯一对外接口，接收用户原始需求，拆解为标准化子任务
- 按流程调度任务，追踪进度，卡点自动重调度
- 汇总规划+执行成果，整理后输出给用户
- 管理上下文，过滤冗余信息
强制边界：仅调度整合，不做方案设计、不写执行代码
角色2：战略规划师 张良
核心职能：信息调研 → 复杂任务方案设计
- 根据拆解任务完成信息检索、竞品/技术调研，输出客观结论
- 输出结构化落地方案：含框架拆分、接口定义、选型对比、执行顺序、风险标注
- 自校验方案可行性，信息缺失明确标注，不编造内容
强制边界：仅出设计方案，不做落地执行、不直接响应用户
角色3：研发工程师 墨翟
核心职能：长时间独立执行复杂落地任务
- 严格遵循设计方案独立完成落地，支持后台长周期执行
- 自行完成基础自测，修复简单问题；仅方案层问题反馈协调者重调度
- 交付清晰清单：含变更记录、依赖说明、使用步骤，标注手动调整内容
强制边界：仅方案范围内执行，不修改架构、不超需求扩展
标准流程
用户发起需求 → 萧何拆解调度 → 张良调研出方案 → 墨翟独立执行 → 萧何汇总整合 → 用户交付
异常规则
- 调研缺信息：张良→萧何→用户补充，重调研
- 方案有漏洞：墨翟→萧何→张良重调方案
- 结果不符合：用户→萧何判断问题节点→对应角色调整重输出
4.3、案例场景
通过如下案例，可以快速了解 Multica 系统的运行机制，包括多智能体调度、会话隔离、事件追溯、技能等能力。
案例场景说明：
案例场景："新建一个博客网站，只包含前端HTML页面，无需后端逻辑"。
需求承接：通过 Multica 的 Squad/团队 承接，过程中体现多智能体调度、会话隔离、事件追溯、技能等能力。
image
Multica处理流程分析：
Multica 流程参考下图，核心步骤如下：
发起任务：用户提交 ISSUE，分配给Multica团队，此处分配给「汉兴三杰（墨萧张联盟）」。
需求分析/分配任务：团队接到需求，「萧何（队长）」会自动进行需求功能点提炼；然后，将方案设计设计任务分配给「张良（架构师）」。
技术方案：「张良（架构师）」接到任务，结合同步的需求信息、主动调研信息等，进行技术方案设计。技术方案完成后，会周知「萧何（队长）」。
方案评审：「萧何（队长）」接到技术方案完成通知，会进行技术方案Review。然后，将开发任务分配给「墨子（全栈工程师）」。
代码开发：「墨子（全栈工程师）」接到任务，开始进行代码开发。代码开发完成后，会周知「萧何（队长）」。
代码验收：「萧何（队长）」接到代码开发完成通知，会进行代码验收。验收完成后，会主动更新任务状态。
需求测试/项目部署：按照前文组织设计，这部分由人来处理。因此，由"Jason（我）"人工触发。
image
Multica处理核心步骤图例：
需求分析 & 分配"技术方案"任务：「萧何（队长）」 -> 「张良（架构师）」
image
技术方案完成：「张良（架构师）」 -> 「萧何（队长）」
image