Multi-Agent Architecture Evolution Blueprint: In-Depth Comparison of CoPaw and Crush

Forum topic · ✨步子哥 · 2026-04-12

Summary

This forum post presents a detailed architectural comparison between CoPaw, a personal AI assistant built on the AgentScope ecosystem, and Crush, a terminal AI coding assistant by Charmbracelet, to identify how Crush's multi-agent architecture can evolve. Through a seven-dimension capability matrix, the author finds the largest gaps in multi-agent management, agent collaboration mechanisms, and lifecycle management (hot reload, zero-downtime updates), while memory, skills, security, and extensibility are relatively close. CoPaw uses a Multi-Workspace model with lazy loading, atomic instance replacement, a ServiceManager for shared resources, and a Skills Hub with manifest-based routing. Crush currently relies on a Coordinator-Subagent pattern with a Deer-Flow style goroutine worker pool, plus a Team service that only manages metadata and a workflow engine not fully wired into the main flow. The post proposes a four-phase evolution plan for Crush: (1) a true Workspace runtime with isolated SQLite/filesystem/config resources, (2) upgrading Team into a collaboration runtime with leader-follower, round-robin, and broadcast modes, (3) an inter-agent message router supporting point-to-point, broadcast, and request-response, and (4) a shared service manager with reference counting for LSP/MCP connections, plus zero-downtime reload via atomic swap. It includes Go code sketches, a 2026 Q2–Q4 roadmap, milestones M1–M5, risk mitigations, and a terminology mapping table.

This is a Chinese forum post presenting a v1.0 architecture analysis and evolution blueprint (dated 2026-04-12) based on source-level review of CoPaw v1.0.2 and Crush (main@2026-04-12).

Key points

Gap matrix (CoPaw vs Crush): largest gaps are in multi-agent management (Workspace + MultiAgentManager vs basic Team service), agent collaboration (message routing + skill sharing vs basic subagents), and lifecycle management (hot reload / zero-downtime updates vs basic fork management). Memory, skills, security, and extensibility gaps are rated small.
CoPaw architecture: layered design with a Channel Layer (DingTalk/Feishu/Discord/Telegram/Console), a MultiAgentManager holding Workspace containers, a shared ServiceManager, a message Router, a global Skills Hub (builtin/imported skills + manifest.json, SHA256 signatures, channel-based routing), and a security stack (ToolGuardMixin, SkillScanner, approval service).
CoPaw Workspace model: lazy creation on first get_agent() request, zero-downtime reload (create new instance → atomic replace → graceful stop of old instance), asyncio.Lock concurrency safety, and cross-workspace service reuse.
Crush architecture: Bubble Tea TUI over an AgentCoordinator with a SessionAgent, a Deer-Flow style SubagentExecutor (goroutine worker pool, max_workers=3, registry, middleware for loop detection/token usage/timeout), built-in subagent types (general-purpose, bash, code-reviewer, research), plus Team, Task, and Workflow services, SQLite+sqlc storage, Permission v2 rule engine, skills with hot reload, hooks, plugins, and MCP.
Crush's current limits: Team is metadata-only (IDs, no runtime agent references); Workflow engine exists but may not be fully wired; no true independent multi-agent parallelism; no agent-to-agent communication.
What CoPaw can learn from Crush: subagent execution engine with middleware, Permission v2 (conditions, time windows, rate limits, audit logs), Git Worktree isolation with auto commit/rollback, and polished TUI experience.

Proposed evolution plan for Crush (Go code sketches in original)

1. P0 — Workspace runtime (internal/agent/workspace/): a Workspace struct with its own SessionAgent, isolated services (session/messages/history/memory on separate SQLite connections), lazy load, timeout release, and lifecycle (Start/Stop/Reload); Manager extension on the Coordinator (GetWorkspace, CreateWorkspace, ReloadWorkspace, etc.). 2. P0–P1 — Team runtime: extend the Team service into a TeamRuntime binding agent IDs to live Workspaces, with a MessageRouter and SharedContext; collaboration modes: independent, leader-follower, round-robin, broadcast. 3. P1 — Message routing: a Router with local route tables, per-agent buffered channels, and dispatch goroutines supporting point-to-point send, team broadcast, and request-response. 4. P1 — Shared services: a SharedServiceManager with reference counting for LSP connection pools, MCP clients, and skill caches; a Sharable interface (Acquire/Release/RefCount). 5. P1 — Zero-downtime reload: create new workspace lock-free → atomic map swap under sync.RWMutex → graceful stop of old instance in background (60s timeout). 6. P2 — Skills and security: global skill pool with signatures/versioning, channel routing, ToolGuard-style interception, static skill code scanning, sensitive-data detection.

Roadmap and milestones

2026 Q2: Workspace core framework, resource isolation (SQLite/filesystem/config), Coordinator integration.
2026 Q3: Team runtime, message routing, shared services, hot reload.
2026 Q4: collaboration modes, UI integration, performance, docs/examples.
Milestones: M1 Workspace MVP (2026-05-15), M2 3+ agents in parallel (2026-06-30), M3 Team runtime (2026-07-31), M4 hot reload (2026-08-31), M5 full ecosystem (2026-10-31).
Risks: high resource usage (cap workspace count, timeout release), state-sync complexity (strict isolation boundaries), backward compatibility (incremental refactor), test coverage (mandatory per phase).

Appendix highlights

The post includes full Go reference implementations for workspace creation (isolated SQLite per workspace, builder-based agent construction, router registration) and hot reload (clone config with version bump, create agentID+"-new", atomic swap, background graceful stop), plus a terminology table mapping Crush ↔ CoPaw concepts (SessionAgent ↔ CoPawAgent, Subagent, Workspace, Team, Skill, Hook, MCP).