# Composer：macOS原生控制面板，以看板工作流编排代码智能体

> Swift开发的macOS原生应用，提供Symphony风格的智能体编排控制平面，支持本地优先的看板工作流管理，兼容多种代码智能体。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-28T19:44:56.000Z
- 最近活动: 2026-04-28T19:53:56.772Z
- 热度: 159.8
- 关键词: macOS, Swift, 智能体编排, 看板, 本地优先, Claude Code, Codex, 开发者工具
- 页面链接: https://www.zingnex.cn/forum/thread/composer-macos
- Canonical: https://www.zingnex.cn/forum/thread/composer-macos
- Markdown 来源: ingested_event

---

## 智能体编排的控制平面需求

随着Claude Code、Codex、OpenCode等AI编程智能体的普及，开发者面临一个新的管理挑战：如何在多个项目、多个智能体之间协调工作？现有的解决方案要么完全依赖命令行，要么将数据存储在云端，缺乏一个本地优先、可视化的控制界面。

Composer正是为解决这一问题而生。它是一个原生macOS应用，为Symphony风格的智能体编排提供了图形化控制平面。

## 架构设计：分层解耦

Composer采用了清晰的分层架构，确保核心逻辑与具体实现解耦：

**SymphonyCore（核心领域模型）**

定义了与提供商无关的领域模型，包括项目（Project）、工作项（Work Item）、运行记录（Run）、智能体（Agent）和运行时事件（Runtime Event）。这层完全抽象，不依赖任何具体存储或智能体实现。

**SymphonyInterfaces（协议边界）**

定义了存储、追踪器、工作流加载器、工作空间、智能体运行器、同步和事件接收器的协议接口。这些接口构成了系统的扩展点，允许不同的后端实现接入。

**SymphonyLocalStore（本地存储实现）**

初始版本采用JSON文件作为本地存储后端。由于存储层通过协议接口与上层交互，未来可以无缝替换为SQLite或其他数据库，而无需修改上层代码。

**SymphonyRuntime（编排状态机）**

核心编排逻辑的状态机骨架。它只依赖接口，不依赖具体的存储实现或智能体类型，确保业务逻辑的纯粹性。

**ComposerApp（SwiftUI界面）**

原生macOS看板界面和检查器视图，为上述各层提供用户交互入口。

## 本地优先的看板工作流

Composer的核心交互模式是看板（Kanban）工作流。用户可以：

- 创建项目并关联代码仓库
- 为每个项目指定首选智能体（如Codex、Claude Code等）
- 在看板上创建、移动、管理工作项
- 跟踪每个工作项的状态流转（就绪→进行中→人工审核→完成）

所有数据默认存储在本地，开发者对自己的数据拥有完全控制权。这种本地优先的设计既保护了代码隐私，也确保了离线可用性。

## 命令行工具：composerctl

除了图形界面，Composer还提供了功能完整的命令行工具`composerctl`，支持：

```
composerctl project add --name Composer --repo /path/to/repo --agent codex
composerctl task add --project Composer --title "Add workflow loader" --state ready --priority high
composerctl task list --project Composer
composerctl task move --task LOCAL-1 --state human-review --project Composer
```

CLI与GUI共享相同的底层存储和协议，用户可以根据场景灵活选择交互方式。

## 多智能体兼容性

Composer的设计目标是不绑定任何单一智能体。通过SymphonyInterfaces定义的协议边界，理论上可以接入：

- **Codex**：OpenAI的代码智能体
- **Claude Code**：Anthropic的终端智能体
- **OpenCode**：开源替代方案
- **未来智能体**：任何符合协议的智能体实现

这种开放性确保Composer不会随着某个特定智能体的兴衰而变得过时。

## 技术栈与构建

Composer使用Swift和SwiftUI开发，充分利用了macOS的原生能力。项目采用现代Swift包管理器（SPM）构建，支持以下命令：

**运行测试**
```bash
env CLANG_MODULE_CACHE_PATH="$PWD/.build/clang-module-cache" \
  swift test --disable-sandbox --cache-path "$PWD/.build/swiftpm-cache"
```

**运行应用**
```bash
env CLANG_MODULE_CACHE_PATH="$PWD/.build/clang-module-cache" \
  swift run --disable-sandbox --cache-path "$PWD/.build/swiftpm-cache" Composer
```

## 与现有工具的对比

| 特性 | Composer | 纯CLI工具 | 云端IDE |
|------|----------|----------|--------|
| 本地优先 | ✅ | ✅ | ❌ |
| 可视化看板 | ✅ | ❌ | 部分 |
| 多智能体支持 | ✅ | 有限 | 有限 |
| 数据隐私 | 完全控制 | 完全控制 | 依赖服务商 |
| 离线可用 | ✅ | ✅ | ❌ |

## 适用用户与场景

Composer特别适合以下用户群体：

- **多项目开发者**：同时在多个代码库上工作，需要统一的管理界面
- **智能体尝鲜者**：尝试不同的AI编程工具，希望有一个中立的协调层
- **隐私敏感用户**：不愿将代码上传到云端，坚持本地优先原则
- **团队技术负责人**：需要为团队评估和引入AI编程工具，希望先本地试用
- **自动化爱好者**：喜欢通过CLI脚本与看板系统结合，实现工作流自动化

## 未来展望

Composer的架构设计为未来发展留下了充足空间：

- **协作功能**：在保持本地优先的前提下，探索点对点或自托管的协作模式
- **插件系统**：开放插件接口，允许社区扩展智能体适配器和存储后端
- **跨平台**：核心Symphony层使用Swift编写，理论上可移植到Linux/Windows
- **AI辅助规划**：利用LLM分析项目状态，智能推荐下一步工作项

Composer代表了AI辅助编程工具从单一智能体向编排平台演进的趋势。随着代码智能体能力的不断增强，如何有效管理和协调这些智能体将成为开发者工具链的下一个关键战场。