ling-stack
ling-stack-org/ling-stack加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一下：你在做一个项目，同时请了三个 AI 帮手——Claude 负责架构评审、GPT-4o 写代码、DeepSeek 查文档。一天下来，任务分散在三个不同的对话窗口里，工具审批请求散落在各处的弹窗中，最终结论要靠手动复制粘贴整合。这就是当前多模型协作的常态：模型越多，协作越碎片。
Ling Stack 解决的就是这个问题。它是一个本地优先的 AI teammate 工作区，把多个 AI 模型的对话、工具审批和产出结果汇聚到同一个项目空间里，让人类作为"主编"统一管理协作流程。数据保存在本地，不强制依赖云端，用什么模型、什么时候用、结果存哪里，全由用户自己决定。
多代理 AI 系统（Multi-Agent）在 2025-2026 年快速成熟，从最初的单一对话助手演化出分工协作能力。Anthropic 推出 MCP（Model Context Protocol）协议后，不同模型与外部工具之间的连接有了统一标准，降低了多系统整合的门槛。
但在实践层面，多模型协作面临两个核心问题：上下文割裂（每个模型有自己的对话历史）和工具审批分散（shell 操作、文件修改、API 调用分散在各个窗口）。Ling Stack 的出现正是对这两个痛点的直接回应——它提供了一个统一的本地工作区，把多模型协作的输入输出集中管理。
项目由 ling-stack-org 维护，GitHub 已有 547 颗星，采用 MIT 协议，完全开源。
Ling Stack 采用 TypeScript Monorepo 架构，用 pnpm workspace 组织代码，整体分为三个入口层和一组核心包：
三个入口：
核心包（packages/）：
| 包名 | 职责 |
|---|---|
core | 工作区、Channel、Task、AI teammate 的领域模型和状态机 |
daemon | 本地 API 服务层，三个入口都调用这个 API |
providers | 模型供应商适配层，统一封装不同模型的接口 |
runner-pi | Agent 执行引擎，负责调度工具和模型调用 |
plugin-sdk | 插件开发 SDK |
api-client | 供外部调用 daemon API 的客户端 |
conversation-ui-core / conversation-ui-react | 对话界面组件 |
ui-react | 通用 React UI 组件库 |
localization | 国际化支持（55 个语言/地区选项） |
后端架构（从架构文档整理）：
CLI / Web UI / Desktop
↓
Local Daemon API
↓
Core Workspace Engine
├── Channel Coordinator（多频道协调）
├── Policy & Approval Engine（策略与审批引擎）
├── Agent Runner（执行调度）
├── SQLite Metadata（结构化数据存储）
└── Session Logs & Artifacts（会话日志和产物）
↓
Tools: MCP / Shell / Git / Files
↓
Provider Broker
├── OpenAI GPT
├── Anthropic Claude
├── 火山引擎豆包 (Doubao)
├── DeepSeek
├── MiniMax
├── GLM
├── 即梦 (Jimeng) / _seedream (Seedream)
└── OpenAI-Compatible Relay
这个架构的核心设计思想是本地持久化 + 按需路由：工作区元数据（对话历史、任务状态、工具审批记录）通过 SQLite 存储在本地，只有模型推理请求才发往外部 API。用户可以完全控制数据流向，不必担心协作过程被第三方平台记录。
Ling Stack 对 MCP 的集成值得特别关注。MCP（Model Context Protocol）由 Anthropic 在 2024 年 11 月推出，旨在标准化 AI 模型与外部数据源、工具之间的连接方式。Ling Stack 的 Agent Runner 层通过 MCP 协议接入各类工具，packages/daemon 直接依赖 @modelcontextprotocol/sdk。
支持的能力路由包括：chat（对话）、tool_call（工具调用）、reasoning（推理）、vision（视觉）、web_search（网页搜索）、embedding（向量嵌入）、image_generate（图像生成）、image_edit（图像编辑）、video_generate（视频生成）、tts（语音合成）和 asr（语音识别）。
这意味着 Ling Stack 不仅仅是"聊天窗口"，更是一个可扩展的多模态 AI 工作台——理论上只要有人实现对应的 MCP server，任何工具都可以接入这个工作区。
目前 Ling Stack 推荐从源码启动 Web UI 作为入门方式，这是最容易复现的路径。需要的前提环境是 Node.js 22.22.1+ 和 pnpm 10+，没有 GPU 需求，普通开发机即可运行。
启动流程大致是：克隆仓库 → 安装依赖（pnpm install）→ 启动 daemon（pnpm --filter @ling-stack/daemon dev）→ 启动 Web UI（pnpm --filter @ling-stack/web dev）→ 浏览器打开本地端口即可使用。
Desktop 版本提供了 Electron 桌面应用体验，但官方明确标注为"source alpha"——即源码可用，签名安装包不可用。对于想快速体验的用户，建议先走 Web UI 路径。
值得注意的是，Ling Stack 的本地存储不代表离线推理。模型请求仍然发送到对应服务商的 API，但请求内容和审批记录本地保存，用户对数据流向有完全掌控权。
需要直说的几个现实问题：
1. 仍处于早期 alpha 阶段。官方文档明确写道："stable signed installers and a supported production release are not available yet"（稳定的签名安装包及受支持的生产版本尚未提供）。对于期待拿来就用的用户，这是最大障碍。
2. 无容器化支持。项目没有提供 Dockerfile 或 docker-compose.yml，无法通过 Docker 一键部署。对于习惯容器化运维的团队，需要自己编写 Dockerfile 来容器化这个 Node.js 应用。
3. 模型需要自备 API Key。Ling Stack 本身不提供模型服务，用户必须自己在各服务商处申请 API Key 并配置到工作区中。这是本地优先架构的代价——省了订阅费，但增加了配置成本。
4. 对 MCP server 质量有依赖。工具能力完全取决于所接入的 MCP server 实现，如果某个 MCP server 不稳定，整个工具链的可靠性都会受影响。
Ling Stack 代表了一种新兴的 AI 工具思路：不是做一个更强的单一模型，而是做一个多模型协作的调度层。这与 2025-2026 年迅速普及的 Agentic AI 趋势高度吻合——当企业开始部署多个专业化的 AI agent 时，如何让它们有效协同就成了刚需。
从技术选型看，项目选择 TypeScript + Electron + React 的组合，使前端开发者可以直接参与扩展开发，降低了贡献门槛。Monorepo 结构也便于维护多入口和多包之间的版本一致性。
GitHub 547 颗星对于一个 alpha 阶段的项目来说增长势头不错，多语言 README（支持 8 种语言）也显示出创始团队对国际化的重视。如果 Desktop 版本能稳定发布，Ling Stack 有潜力成为 AI 爱好者构建本地 AI 工作流的标配工具。
Ling Stack 是一个面向多模型 AI 协作的本地优先工作区，通过统一的本地 daemon 协调多个 AI teammate 的对话、工具审批和产物存储。它解决的问题真实存在（多模型协作碎片化），技术选型务实（TypeScript + Electron + MCP），但产品成熟度仍处于早期阶段。
适合想实验多模型协作、愿意从源码构建、对数据本地化有需求的开发者。不适合追求开箱即用或需要容器化部署的团队。