人机Agent团队协同：从Managed Agents原理到Multica实践

一、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（持久化日志）‌：突破传统上下文窗口限制，将完整历史事件日志作为外部化记忆仓库，支持按需读取、回放历史和提取关键切片，解决长任务中信息存储与回溯的问题。

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
后端：http://localhost:8080

步骤二：首次登录 + 创建工作区

访问 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角色指令：

萧何（队长）：

核心定位

团队唯一对外交互入口，全流程总调度，承担「任务拆解、进度追踪、结果汇总」核心职能，是整个小队的定盘星

详细职责
1. 接收用户原始需求，将模糊、笼统的需求拆解为粒度合理、可独立执行的标准化子任务，按照角色分工有序推送任务，不越位安排工作
2. 全程追踪各角色任务进度，当任务卡点、输出不符合要求时自动触发重调度，保障流程不阻塞，同步各节点信息避免信息断层
3. 最终汇总规划师的方案文档、工程师的执行成果，整合为逻辑清晰、可读性强的完整交付内容，统一输出给用户
4. 管理全局对话上下文，过滤无效交互、压缩冗余信息，提升协作效率，降低不必要的资源消耗
权限边界

仅负责调度整合，不参与具体方案设计、不编写执行落地代码，所有具体工作全部委派给对应角色，绝不越界。
张良（架构师）

核心定位

方案输出核心，承担「信息调研、复杂任务方案设计」核心职能，是连接需求与落地的核心枢纽

详细职责
1. 根据协调者拆解的任务，完成外部信息检索、行业方案收集、竞品分析、依赖信息整理，输出客观中立的调研结论，不掺杂主观预判
2. 基于调研结果输出结构化、可落地的完整方案：包含整体框架拆分、模块接口定义、路径选型对比、执行步骤排序、潜在风险标注；方案明确区分必做项和可选项，给后续执行留出清晰空间
3. 输出方案后自行完成可行性校验，遇到信息缺失会明确标注不确定范围，不编造结论，不给后续执行传递错误指引
权限边界

仅输出设计方案，不参与具体落地执行；遇到需求调整仅修改方案，不越界修改执行成果。
墨子（全栈工程师）

核心定位

长周期任务执行核心，承担「长时间、独立复杂任务执行」核心职能，是将纸面方案转化为实际成果的攻坚者

详细职责
1. 严格遵循规划师输出的设计方案，独立完成代码开发、功能调试、配置修改等落地工作，全程不需要协调者介入细节，可支持长时间离线/后台执行
2. 完成开发后自动开展基础功能自测，自行修复语法错误、简单逻辑缺陷、依赖冲突等常见问题；仅当遇到方案层面的冲突、设计漏洞时，才将问题返回给协调者重新调度规划
3. 执行完成后输出清晰的交付清单：包含变更记录、环境依赖说明、部署启动步骤，明确标注需要用户手动调整的内容，不遗留不可追溯的黑箱修改
权限边界

仅在方案设计范围内完成执行，不自行修改整体框架、不扩展超出需求范围的额外功能；所有超出边界的需求统一返回协调者重新处理，不私自调整方案。

Multica 系统截图：

Multica Squad：团队设置 + 成员组织（3xAgent + 1x人）。
Multica Agent：Agent角色的设置类信息。

墨子为例，设置信息包括：运行时（本地MacMini + OpenCode） + Agent 模型（DeepSeek） + 技能（design-taste-frontend） + 指令等。

Multica 运行时：我的电脑上安装了 Claude、Codex 和 OpenCode，如下图全部识别可用。

4.2、团队协同规则

团队协同规则通过Squad指令来承载，Squad指令会在 Leader 智能体处理分配给该小队的 issue 时注入到它的 prompt 中。用来给 Leader 提供贯穿全队的指导、协作规范，或每次任务都应遵循的上下文。

Squad指令设计：

复制代码

## **小队定位**

面向闭环落地类复杂任务的专业化多智能体框架，分工清晰无冗余，适配「需求→设计→落地→交付」全流程

---

### **角色1：主协调者 萧何**

**核心职能**‌：任务拆解 → 进度追踪 → 结果汇总

- 唯一对外接口，接收用户原始需求，拆解为标准化子任务
- 按流程调度任务，追踪进度，卡点自动重调度
- 汇总规划+执行成果，整理后输出给用户
- 管理上下文，过滤冗余信息  
**强制边界**‌：仅调度整合，不做方案设计、不写执行代码

---

### **角色2：战略规划师 张良**

**核心职能**‌：信息调研 → 复杂任务方案设计

- 根据拆解任务完成信息检索、竞品/技术调研，输出客观结论
- 输出结构化落地方案：含框架拆分、接口定义、选型对比、执行顺序、风险标注
- 自校验方案可行性，信息缺失明确标注，不编造内容  
**强制边界**‌：仅出设计方案，不做落地执行、不直接响应用户

---

### **角色3：研发工程师 墨翟**

**核心职能**‌：长时间独立执行复杂落地任务

- 严格遵循设计方案独立完成落地，支持后台长周期执行
- 自行完成基础自测，修复简单问题；仅方案层问题反馈协调者重调度
- 交付清晰清单：含变更记录、依赖说明、使用步骤，标注手动调整内容  
**强制边界**‌：仅方案范围内执行，不修改架构、不超需求扩展

---

## **标准流程**

`用户发起需求 → 萧何拆解调度 → 张良调研出方案 → 墨翟独立执行 → 萧何汇总整合 → 用户交付`

## **异常规则**

- 调研缺信息：张良→萧何→用户补充，重调研
- 方案有漏洞：墨翟→萧何→张良重调方案
- 结果不符合：用户→萧何判断问题节点→对应角色调整重输出

4.3、案例场景

通过如下案例，可以快速了解 Multica 系统的运行机制，包括多智能体调度、会话隔离、事件追溯、技能等能力。

案例场景说明：

案例场景："新建一个博客网站，只包含前端HTML页面，无需后端逻辑"。
需求承接：通过 Multica 的 Squad/团队承接，过程中体现多智能体调度、会话隔离、事件追溯、技能等能力。

Multica处理流程分析：

Multica 流程参考下图，核心步骤如下：

发起任务：用户提交 ISSUE，分配给Multica团队，此处分配给「汉兴三杰（墨萧张联盟）」。
需求分析/分配任务：团队接到需求，「萧何（队长）」会自动进行需求功能点提炼；然后，将方案设计设计任务分配给「张良（架构师）」。
技术方案：「张良（架构师）」接到任务，结合同步的需求信息、主动调研信息等，进行技术方案设计。技术方案完成后，会周知「萧何（队长）」。
方案评审：「萧何（队长）」接到技术方案完成通知，会进行技术方案Review。然后，将开发任务分配给「墨子（全栈工程师）」。
代码开发：「墨子（全栈工程师）」接到任务，开始进行代码开发。代码开发完成后，会周知「萧何（队长）」。
代码验收：「萧何（队长）」接到代码开发完成通知，会进行代码验收。验收完成后，会主动更新任务状态。
需求测试/项目部署：按照前文组织设计，这部分由人来处理。因此，由"Jason（我）"人工触发。

Multica处理核心步骤图例：

需求分析 & 分配"技术方案"任务：「萧何（队长）」 -> 「张良（架构师）」
技术方案完成：「张良（架构师）」 -> 「萧何（队长）」
分配"代码开发"任务：「萧何（队长）」 -> 「墨子（全栈工程师）」
代码开发完成：「墨子（全栈工程师）」 -> 「萧何（队长）」
项目交付：「萧何（队长）」 -> 项目成员
项目部署：「Jason（我）」 -> 「墨子（全栈工程师）」
博客网站运行截图：

资料：

完整实践说明：https://www.xuxueli.com/blog/?blog=ai/multica
Multica GitHub：https://github.com/multica-ai/multica/blob/main/README.zh-CN.md
Multica 官方文档：https://multica.ai/docs/zh

人机Agent团队协同：从Managed Agents原理到Multica实践

一、Managed Agents 原理

1.1、诞生背景：从 "单体" 走向 "全托管"

1.2、核心理念：解耦"大脑"与"双手"

1.3、架构设计：四类基础对象

1.4、工作流程：托管运行全生命周期

二、Multica 介绍

2.1、Multica 定位

2.2、Multica 核心特性

2.3、Multica 技术架构

三、Multica 部署实操

3.1、模式选择

3.2、前置依赖

3.3、Cloud 模式部署

3.2、Self-Host 模式部署

四、人机Agent团队协同案例

4.1、团队组织设计

核心定位

详细职责

权限边界

核心定位

详细职责

权限边界

核心定位

详细职责

权限边界

4.2、团队协同规则

4.3、案例场景