人工智能AI Agent多智能体Agent 编排Agent 工作流MCP 服务【免费下载链接】ClawTeamClawTeam: Agent Swarm Intelligence (One Command → Full Automation)项目地址https://gitcode.com/gh_mirrors/cl/ClawTeam点击查看免费下载ClawTeamAgent Swarm Intelligence是一个框架无关的多 Agent 协作编排工具其 ROADMAP.md 记录了项目从 v0.2 单机文件系统阶段走向分布式协作的完整演进路径Phase 1 Transport 抽象层、Phase 2 Redis Transport、Phase 3 共享状态层、Phase 4 多用户协作与 Phase 5 Web UI。本文以路线图为骨架结合仓库内实际源码clawteam/transport/、clawteam/store/、clawteam/team/mailbox.py、clawteam/cli/commands.py等逐层拆解每一阶段的设计动机、架构变化、具体任务与验收标准帮助读者理解 ClawTeam 的通信层如何一步步做到消息可插拔、状态可共享、团队可跨机并掌握与之对应的环境变量与 CLI 实操。现状 (v0.2)单机文件系统的能跑版本路线图首先划定了 v0.2 的基线能力边界用一句话概括就是单用户 → 单机 → 文件系统 → CLI 驱动这一阶段有三个明确约束所有数据在~/.clawteam/团队配置、任务、消息所有 agent 必须在同一台机器纯文件 I/O零依赖。从源码看这一纯文件 I/O的基线在仓库中至今仍被完整保留。团队配置以config.json形式存于{data_dir}/teams/{team}/见 clawteam/team/manager.py消息则被序列化为{data_dir}/teams/{team}/inboxes/{agent}/msg-{ts}-{uid}.json的单文件见 clawteam/transport/file.py任务存放于{data_dir}/tasks/{team}/task-{id}.json见 clawteam/store/file.py。数据目录本身由CLAWTEAM_DATA_DIR环境变量或~/.clawteam决定见 clawteam/team/models.py。需要说明的是路线图中标注为现在v0.3的总览段落显示Config 系统、多用户协作、Web UI、SSHFS 跨机器方案在当前仓库中已经完成详见下文总览一节因此 v0.2 描述的是架构演进的逻辑起点而 v0.3 是当前版本的实际能力基线。Phase 1Transport 抽象层 (v0.3)——让消息通信层可插拔目标让消息通信层可插拔不改上层接口。这是整个路线图的第一块基石如果连发消息这件事都被抽象出来后续 Redis、P2P 乃至任意自定义通道都可以无缝替换而MailboxManager及其上层 CLI 完全无感知。架构变化路线图给出的架构变化如下现在: MailboxManager → 直接读写文件 Phase 1: MailboxManager → Transport(接口) ├── FileTransport (默认当前行为) └── (未来: RedisTransport, ...)对照当前仓库这一目标已经落地。Transport是一个 ABC 抽象基类clawteam/transport/base.py定义了四个抽象方法与一个默认空实现的close()方法语义deliver(recipient, data)向收件人 inbox 投递消息字节fetch(agent_name, limit, consume)从 transport 特定的 inbox 取回不透明消息字节count(agent_name)返回待处理消息数list_recipients()列出所有已知收件人供 broadcast 使用值得强调的设计细节在fetch()的 docstring 中写得很清楚Transport 只搬运原始字节opaque message bytes不做消息解析。把字节解析成TeamMessage、以及是否将畸形载荷隔离quarantine的责任交给MailboxManager这类上层调用者见 clawteam/transport/base.py。这保证了抽象层极薄、极通用。接口上还有一个可选的扩展点transport 可以额外实现claim_messages()返回ClaimedMessageack / quarantine 回调从而支持先认领、后确认/隔离的消费语义见 clawteam/transport/claimed.py。MailboxManager.receive()会优先使用该扩展点否则退回fetch(consumeTrue)路径见 clawteam/team/mailbox.py。FileTransport当前行为FileTransport把mailbox.py原有的文件操作完整承接为独立类clawteam/transport/file.py每条消息一个文件{data_dir}/teams/{team}/inboxes/{agent}/msg-{ts}-{uid}.json采用临时文件写入 os.replace原子改名的方式避免半写被读到deliver中先写.tmp-{uid}.json再原子替换读取时借助 OS 级文件锁Unix 用fcntl.flockWindows 用msvcrt实现并发安全并将已认领消息改名.consumed后缀防止重复消费解析失败的载荷会被移入{data_dir}/teams/{team}/dead_letters/{agent}/死信目录并附带.meta.json元信息源文件名、错误、隔离时间戳避免坏消息卡死队列。这些细节在 tests/test_mailbox.py 中都有对应验证例如test_send_and_receive_single验证发送与接收闭环、test_receive_consumes_messages验证消费后二次 receive 为空。工厂与选择机制transport 的实例化统一走 clawteam/transport/init.py 中的get_transport(name, team_name)工厂并维护一个_TRANSPORT_REGISTRY注册表允许插件通过register_transport()注册自定义 backend——这正是路线图可插拔诉求的落地形式。默认 transport 的解析逻辑在MailboxManager._default_transport()见 clawteam/team/mailbox.py优先读环境变量CLAWTEAM_TRANSPORT未设置时读配置文件中的transport字段二者皆空则回落到file。这与路线图 Phase 1 的验收标准CLAWTEAM_TRANSPORTfile为默认值完全一致。CLI 层面同样提供了--transport全局选项file或p2p见 clawteam/cli/commands.py设置后注入CLAWTEAM_TRANSPORT环境变量。TaskStore 抽象路线图要求TaskStore 抽象同样抽出FileTaskStore预留接口。仓库中的实现为 clawteam/store/base.py 的BaseTaskStore与 clawteam/store/file.py 的FileTaskStore。BaseTaskStore的接口设计create/get/update/list_tasks/release_stale_locks/get_stats预留了并发控制责任实现必须自行处理与其存储介质匹配的并发控制文件锁、Redis 事务等见 clawteam/store/base.py。FileTaskStore的_write_lock同样用fcntl/msvcrt序列化写操作并实现了任务依赖环检测_validate_blocked_by_unlocked用 DFS 防环与任务锁的force覆盖语义_acquire_lock。配置字段task_store默认file在 clawteam/config.py 中明确注释为extensible for redis/sql later与路线图的预留接口呼应。交付物结构路线图要求的目录结构在仓库中均已就位clawteam/transport/ ├── __init__.py # Transport 注册表 get_transport 工厂 ├── base.py # Transport 抽象基类 ├── claimed.py # ClaimedMessageack/quarantine ├── file.py # FileTransport默认 └── p2p.py # P2PTransport见下文扩展 clawteam/store/ ├── __init__.py ├── base.py # BaseTaskStore 抽象基类 └── file.py # FileTaskStore验收所有现有命令行为不变CLAWTEAM_TRANSPORTfile为默认值——该验收已通过且被 tests/conftest.py 用临时CLAWTEAM_DATA_DIR隔离的测试套件持续保障。跨机器消息通信的两种已实现路径路线图的 Phase 2 规划的是 Redis Transport但仓库当前实际落地的是另一条轻量路径ZeroMQ P2P Transportclawteam/transport/p2p.py与 Redis 发布/订阅唤醒层clawteam/team/redis_wakeup.py。这两者与 Phase 2 目标一致——支持跨机器消息通信——但依赖更轻、零外部基础设施也能跑。P2PTransportZeroMQ PUSH/PULL 文件兜底clawteam/transport/p2p.py 的实现要点PULL socket 监听bind_agent设置时绑定随机 TCP 端口并在共享文件系统写入peers/{agent}.json含 host、port、pid、心跳与租约元数据通过心跳线程每 1 秒刷新_peer_heartbeat_interval_s 1.0租约 5 秒PUSH socket 发送deliver()先查peers/{recipient}.json若 peer 存活同机校验 PID、异机校验租约新鲜度则直接 ZMQ 发送发送失败自动降级走FileTransport兜底关闭清理close()停止心跳、注销 peer 文件、关闭所有 socket 并ctx.term()。同机 peer 用 PID 存活判断异机 peer 依赖leaseExpiresAtMs租约元数据——这段同机/异机差异化判定逻辑见 clawteam/transport/p2p.py恰好弥补了文件系统 peer 注册表在跨机器场景下的陈旧 peer 问题。Redis 唤醒层可选的高频实时通道clawteam/team/redis_wakeup.py 的resolve_wakeup()支持三种模式off显式关闭redis://...使用显式 URL对应路线图的CLAWTEAM_REDIS_URLauto优先用环境变量/状态文件中的 URL都没有且本机存在redis-server时自动拉起一个本地 Redis 实例写入teams/{team}/redis.json状态。消息发送与任务变更都会以 best-effort 方式向clawteam:{team}:agent:{name}与clawteam:{team}:tasks等频道PUBLISH唤醒事件见 clawteam/team/redis_wakeup.py失败静默忽略绝不阻塞主流程。这与路线图 Phase 2 消息通信 → Redis高频实时的方向一致且被设计为可选项而非强依赖。路线图 Phase 2 的原始规划与验收示例路线图的 Phase 2 规划本身依然值得完整保留因为它是理解为什么需要 Redis Transport的说明书架构变化机器A (leader) ─── RedisTransport ──┐ ├── Redis Server 机器B (worker) ─── RedisTransport ──┘ 团队配置 / 任务 → 仍然用文件或共享文件系统 消息通信 → Redis (高频实时)具体任务RedisTransport 实现LPUSH/RPOP实现 send/receive、连接管理URL 配置、连接池、断线重连、配置方式CLAWTEAM_TRANSPORTredisCLAWTEAM_REDIS_URLredis://...、broadcast 实现依赖 TeamManager 获取团队成员列表、混合模式消息走 Redis、配置/任务走文件、两台机器或两个 container的集成测试。新增依赖redispypi可选安装pip install clawteam[redis]。验收示例原样继承# 机器 A export CLAWTEAM_TRANSPORTredis export CLAWTEAM_REDIS_URLredis://192.168.1.100:6379 clawteam team spawn-team dev-team -n leader clawteam spawn tmux claude --team dev-team -n worker1 --task ... # 机器 B export CLAWTEAM_TRANSPORTredis export CLAWTEAM_REDIS_URLredis://192.168.1.100:6379 clawteam inbox receive dev-team --agent worker1 # 收到消息 ✅其中clawteam team spawn-team的-n/--agent-name参数在 clawteam/cli/commands.py 中实现clawteam inbox receive的--agent参数在 clawteam/cli/commands.py 中实现均可对照查阅。Phase 3共享状态层 (v0.5)——团队配置与任务也跨机器Phase 2 只解决了消息跨机器但团队配置config.json和任务task-*.json仍在本地文件。Phase 3 的目标是让它们也共享路线图给出两条路线路线 ANFS / 共享文件系统# 所有机器挂载同一个 NFS export CLAWTEAM_DATA_DIR/mnt/shared/clawteam # 零代码改动直接可用零代码改动的根本原因所有路径都经过get_data_dir()clawteam/team/models.py这一唯一入口——它读取CLAWTEAM_DATA_DIR环境变量、配置或默认~/.clawteam因此只要把共享目录挂载到各机器并设置同一环境变量团队配置、任务、inbox 消息自然落在同一份数据上。路线图总览中的 v0.3 也确认跨机器方案SSHFS/云盘 CLAWTEAM_DATA_DIR零代码改动已经完成。路线 BRedis 统一存储消息 → Redis (Phase 2 已做) 配置 → Redis Hash 任务 → Redis Hash 所有状态都在 Redis文件系统只做本地缓存具体任务RedisTeamStore团队配置存 Redis Hash、RedisTaskStore任务存 Redis Hash、数据迁移工具clawteam migrate file-to-redis、统一配置CLAWTEAM_BACKENDredis一个变量搞定所有。验收两台机器共享同一个团队、同一个任务板、同一个消息队列。从当前源码结构看BaseTaskStore/Transport的抽象已为路线 B 预留了全部接缝存储实现与消息实现都只需实现各自的抽象基类task_store配置字段注释也明确extensible for redis/sql laterclawteam/config.py但RedisTeamStore/RedisTaskStore与迁移工具尚属未来规划应视为路线图承诺而非已实现能力。Phase 4多用户协作 (v0.6)——不同人的 agent 组成一个团队目标不同人的 agent 组成一个团队。路线图列出的新增能力能力描述用户身份区分谁的 agent不只是 agent name权限模型谁能创建团队、谁能加入、谁能看任务命名空间user1/worker1vsuser2/worker1Token 认证连接 Redis 时验证身份用户 A 的 Claude Code ──┐ ├── Redis ── Team: project-x 用户 B 的 Claude Code ──┘ 用户 A 的 agent 和用户 B 的 agent 在同一个团队里协作值得注意的是路线图总览中 v0.3 已完成内容已包含多用户协作CLAWTEAM_USER/clawteam config set user(user, name) 复合唯一性。对照源码用户身份来源AgentIdentity.from_env()依次读取CLAWTEAM_USER→ 兼容的OH_USER→ 配置文件user字段clawteam/identity.py(user, name) 复合唯一性TeamManager.add_member()校验同名且同 user 的成员不可重复加入clawteam/team/manager.py命名空间落盘inbox_name_for()将带 user 的成员映射为{user}_{name}作为 inbox 目录名clawteam/team/manager.py与路线图的user1/worker1命名空间设计一一对应resolve_inbox()则负责把逻辑名解析为实际的 on-disk inboxclawteam/team/manager.py。测试侧也有覆盖tests/test_cli_commands.py中大量用例同时设置CLAWTEAM_DATA_DIR与CLAWTEAM_USERalice如 tests/test_cli_commands.py验证多用户场景下的命令行为。权限模型与 Token 认证在当前仓库中未见实现属未来规划范畴。Phase 5Web UI (v1.0)——浏览器看板替代终端 Rich 渲染目标浏览器看板替代终端 Rich 渲染。规划命令为clawteam board serve --port 8080规划能力实时看板WebSocket 推送、多团队概览、任务拖拽、消息历史。对照源码clawteam board serve已经实现clawteam/cli/commands.py支持--port默认 8080、--host默认 127.0.0.1、--intervalSSE 推送间隔默认 2 秒与可选默认团队参数。其实现是 clawteam/board/server.py基于标准库ThreadingHTTPServer的轻量 HTTP 服务零第三方依赖路由/与/index.html提供静态页面/api/overview返回多团队概览/api/team/{team}返回单团队快照/api/events/{team}以SSEtext/event-stream实时推送团队状态/api/proxy提供受限的 GitHub 内容代理仅允许api.github.com、github.com、raw.githubusercontent.com并拦截内网/回环地址防止 SSRFTeamSnapshotCache用 TTL 缓存团队快照SSE 每interval秒推送一次do_POST支持POST /api/team/{team}/task创建任务。值得注意的两点规划写的是WebSocket 推送实际实现为SSEServer-Sent Events——路线图总览 v0.3 已完成内容明确记录Web UIclawteam board serveSSE 实时推送深色主题看板以源码与总览为准终端侧的 Rich 渲染看板依然保留clawteam board show单团队看板、clawteam board overview多团队概览、clawteam board live每--interval秒刷新见 clawteam/cli/commands.py另有board attachtmux 平铺聚合所有 agent 窗口与board gourceGource 动画可视化团队活动。任务拖拽属规划项静态页面 clawteam/board/static/index.html 中未见拖拽交互需谨慎表述为路线图规划能力。总览版本路线与当前进度路线图总览给出的版本编排v0.2 → 单机文件系统能用 v0.3 (现在) → Config 系统 多用户协作 Web UI (已完成跨机器用 SSHFS) v0.4 → 可选: Transport 抽象层 / Redis (如需超出 SSHFS 的场景)v0.3 已完成内容当前仓库实际状态Config 系统clawteam config show/set/get/health。实现见 clawteam/config.py 与 clawteam/cli/commands.py。配置优先级为环境变量 配置文件 默认值get_effective()见 clawteam/config.py关键标量键包括键环境变量默认值说明data_dirCLAWTEAM_DATA_DIR空回落~/.clawteam数据目录userCLAWTEAM_USER空多用户身份transportCLAWTEAM_TRANSPORTfile消息 backendfile / p2ptask_storeCLAWTEAM_TASK_STOREfile任务 backend预留 redis/sqldefault_backendCLAWTEAM_DEFAULT_BACKENDtmuxspawn 后端tmux / subprocessworkspaceCLAWTEAM_WORKSPACEauto工作区策略auto / always / never多用户协作CLAWTEAM_USER/clawteam config set user(user, name) 复合唯一性Web UIclawteam board serveSSE 实时推送深色主题看板跨机器方案SSHFS/云盘 CLAWTEAM_DATA_DIR零代码改动。此外clawteam config health已作为子命令存在对应 CLI 参考文档 docs/skills/clawteam/references/cli-reference.md 与 skills/clawteam/references/cli-reference.md 中的完整命令清单可对照查阅全部子命令。协作建议两人并行的分工模式路线图末尾给出了两人并行开发的最佳分工模式核心思路是接口先行、存储与传输并行Phase 1: 人员 A — Transport 抽象 FileTransport 人员 B — Store 抽象 FileTaskStore 测试 Phase 2: 人员 A — RedisTransport 核心实现 人员 B — 配置系统 broadcast 集成测试 Phase 3: 人员 A — RedisTeamStore 人员 B — RedisTaskStore 迁移工具其关键方法论是接口定义Phase 1要先一起对齐后面就可以各做各的。 这与仓库中Transportclawteam/transport/base.py与BaseTaskStoreclawteam/store/base.py的抽象设计完全吻合——两个纯抽象接口将消息 I/O与任务存储解耦为独立的替换单元后续任何 backend 都可以在不动上层的前提下并行开发。总结路线图与源码的对照结论路线图阶段规划状态当前仓库实际状态主要证据Phase 1 Transport 抽象层规划已完成clawteam/transport/base.py、clawteam/transport/file.py、CLAWTEAM_TRANSPORT默认filePhase 1 TaskStore 抽象规划已完成clawteam/store/base.py、clawteam/store/file.pyPhase 2 Redis Transport规划部分替代落地P2PTransport Redis wakeupclawteam/transport/p2p.py、clawteam/team/redis_wakeup.pyPhase 3 共享状态层规划路线 ANFS/SSHFS CLAWTEAM_DATA_DIR可用路线 B 未实现clawteam/team/models.pyPhase 4 多用户协作规划用户身份与 (user,name) 命名空间已完成权限/Token 未实现clawteam/identity.py、clawteam/team/manager.pyPhase 5 Web UI规划已完成SSE 实时推送非 WebSocketclawteam/board/server.py、clawteam/cli/commands.pyClawTeam 的演进路线给分布式多 Agent 协作工具提供了一个清晰的工程范式先定义薄抽象接口再以文件系统实现兜底行为最后按需替换为 Redis/ZMQ 等高性能通道。对于想要在局域网、容器或云盘环境下搭建多机 Agent 团队的开发者当前版本已经可以通过CLAWTEAM_DATA_DIR共享文件系统与CLAWTEAM_TRANSPORTfile/p2p 可选 Redis 唤醒层拼出一套消息实时、配置共享、零强依赖的协作底座而当场景超出 SSHFS 的能力边界时Phase 2/3 的 Redis 规划路线正是下一步的自然延伸。赞分享人工智能AI Agent多智能体Agent 编排Agent 工作流MCP 服务【免费下载链接】ClawTeamClawTeam: Agent Swarm Intelligence (One Command → Full Automation)项目地址https://gitcode.com/gh_mirrors/cl/ClawTeam点击查看免费下载相关推荐GetQzonehistory免费导出QQ空间历史说说老动态连同图片一起搬回本地GetQzonehistory免费导出QQ空间历史说说老动态连同图片一起搬回本地 六年前在QQ空间写下的那条动态你翻了一晚上也没翻到——它不是消失了只是沉网页爬虫数据分析Trae Agent 路线图深度解读从 SDK、沙箱到多智能体协作的演进蓝图Trae Agent 路线图深度解读从 SDK、沙箱到多智能体协作的演进蓝图 Trae Agent 是一个面向通用软件工程任务的 LLM 智能体平台其官方路人工智能大模型AI AgentAgent 框架代码智能体CLI工具调用2025 CAMEL技术路线图从多智能体协作到百万级Agent生态系统的进化之路2025 CAMEL技术路线图从多智能体协作到百万级Agent生态系统的进化之路 你是否曾因多智能体系统难以扩展而头疼还在为AI agent协作效率低下而困人工智能大模型AI AgentAgent 框架多智能体工具调用MCP ClientsRAG模型评测数据生成上一篇用 OpenEvolve 进化圆填充算法从几何构造到 SLSQP 数学优化复现 AlphaEvolve n26 的结果下一篇微信聊天记录永久保存指南让珍贵对话不再丢失的完整方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考