TREK：一个野心超出“旅行 App“本身的自托管协作规划平台

TREK一个野心超出旅行 App本身的自托管协作规划平台核心定位这不是 Wanderlog 的简单替代TREK 的定位需要放在两条坐标轴上来理解。横轴是功能成熟度自托管旅行规划工具这个赛道历史上都是功能残缺品——要么有地图没预算要么能协作没离线。TREK 用拖拽行程、WebSocket 实时协作、多货币账单、打包清单、旅行日记、PWA 离线覆盖了整个旅行生命周期这本身就是一次渐进整合不是范式突破。纵轴是架构理念真正让 TREK 区别于同类项目的是它把AI 当成另一个客户端而非特殊功能来处理——内置的 MCPModel Context Protocol服务器采用与人类用户完全一致的 OAuth 2.1 27 个细粒度 scope 速率限制体系。这是 2025 年之后 AI 原生应用的正确姿态值得单独展开。截至 2026 年 7 月项目已有10,100 GitHub Stars最新版本 v3.2.11338 次提交不是玩具项目。最关键的机制MCP 作为AI 权限边界的参考实现TREK 的 MCP 集成是整个项目最值得深思的设计点。大多数应用集成 AI 的方式是暴露一个粗粒度的 API key或者让 AI 直接读数据库——要么太宽松要么需要重新建一套权限体系。TREK 的做法是MCP 服务器与人类用户走同一套 OAuth 2.1 授权流150 tools 和 30 个 resource 都挂在 27 个 scope 下分属 13 个权限组。AI 助手比如 Claude、Cursor访问你的行程数据时它的权限边界和你授权给任何第三方应用是完全等价的而不是管理员级别的后门。这解决了一个真实痛点当你把旅行数据放在自己服务器上又想用 AI 帮你做规划时不应该让 AI 拥有比你信任它的程度更多的权限。TREK 的方案是目前开源项目中少数把这个问题想清楚的。Addon 架构是另一个聪明设计——MCP 的工具列表会根据哪些 Addon 被管理员启用而动态调整。这意味着关掉 Atlas访问国家地图后MCP 就自动失去对应工具权限边界是实时收缩的而不是靠约定。技术栈选择不赶时髦每个选择对应具体需求选择理由NestJS 11 Node.js 22module/controller/service/guard 分层适合多模块多权限的复杂业务SQLitebetter-sqlite3单文件零运维自托管场景无需单独数据库进程支持 at-rest 加密WebSocketws 库直接用 Node.js 原生库不引入 Socket.io 复杂度Zustand 代替 Redux中小型前端项目够用的轻量 state 管理Leaflet 优先Mapbox 可选默认开源免费高端 3D 地图按需付费React 19 Vite TypeScript占代码库 98.3% 是 TypeScript工程严格性高这套栈在 2026 年没有任何前沿感——这恰恰是它值得信任的原因。成熟栈意味着更好的社区支持、更容易招人维护、更少的踩坑风险。快速部署30 秒启动最简单方式单命令ENCRYPTION_KEY$(openssl rand -hex 32) docker run -d -p 3000:3000 \ -e ENCRYPTION_KEY$ENCRYPTION_KEY \ -v ./data:/app/data -v ./uploads:/app/uploads mauriceboe/trek访问http://localhost:3000首次启动自动初始化管理员账号密码打印到容器日志。生产环境 Docker Compose含安全加固services: app: image: mauriceboe/trek:latest container_name: trek read_only: true # 根文件系统只读 security_opt: - no-new-privileges:true cap_drop: - ALL # 丢弃所有 Linux Capabilities cap_add: - CHOWN - SETUID - SETGID tmpfs: - /tmp:noexec,nosuid,size64m ports: - 3000:3000 environment: - NODE_ENVproduction - ENCRYPTION_KEY${ENCRYPTION_KEY:-} # openssl rand -hex 32 - APP_URL${APP_URL:-} # OIDC 邮件链接必填 # - FORCE_HTTPStrue # 仅在 TLS 代理后面使用 # - TRUST_PROXY1 volumes: - ./data:/app/data - ./uploads:/app/uploads restart: unless-stopped healthcheck: test: [CMD, wget, -qO-, http://localhost:3000/api/health] interval: 30s⚠️关键陷阱绝不要挂载-v ./app:/app。这会遮盖镜像内的应用代码导致Cannot find module tsconfig-paths/register崩溃。只挂载./data和./uploads两个目录。Kubernetes/Helmhelm repo add trek https://chart.liketrek.com helm repo update helm install trek trek/trek安装为 PWA无需应用商店iOSSafari → 分享 → 添加到主屏幕AndroidChrome 菜单 → 安装应用功能全景模块核心能力 行程规划拖拽日程、Leaflet/Mapbox 交互地图、3D 地形、路线优化、16 天天气预报 旅行管理航班/住宿/餐厅预订追踪、多货币费用分摊类 Splitwise、打包清单、PDF 导出 协作WebSocket 实时同步、角色权限、SSOOIDC、2FA、PasskeysWebAuthn 移动/PWAiOS/Android 可安装、离线缓存Workbox、全屏原生体验 AI/MCP内置 MCP 服务器、150 工具、OAuth 2.1 授权、27 个权限范围⚙️ 管理后台20 种语言、Addon 开关、SMTP 通知、定时自动备份、用户管理Addon 扩展模块管理员可按需开启Atlas访问国家地图、心愿单、旅行统计、连续旅行天数追踪Journey杂志风格旅行日记支持 Immich/Synology 照片集成Vacay个人假期日历内置 100 国家节假日AirTrail连接自托管 AirTrail 实例同步航班数据Collab群聊、共享笔记、投票、每日打卡交叉验证以下两个独立信源对 TREK 的评价与原文基本吻合但各有补充① Text Matrixtxtmix.com2026年6月25日对 TREK 做了系统性工程评估总结为自托管优先 实时协作 AI 原生集成的完美三角并指出 TREK 是2026 年自托管工具的新高度与原文观点高度一致。该文章特别强调了 AGPL-3.0 协议对商业用途的约束——这是原文 GitHub README 没有显著突出的风险点——如果企业修改 TREK 后以 SaaS 方式对外提供服务必须公开修改后的源代码这对商业化场景是实质性障碍。② pyshine.com2026年7月11日的技术分析补充了一些具体运维细节MCP 服务器的速率限制是 300 请求/用户/分钟、最多 20 个并发会话反向代理需要将 WebSocket 超时配置为 86400s否则实时同步会断连备份恢复接口要求反向代理允许最大 500MB 的请求体。这些细节在 README 中散落各处该文章做了系统整理对实际部署有直接参考价值。两个信源均未发现与原文的实质性反驳主要是补充了协议风险和运维细节这些是 README 语境下被淡化的部分。边界被过度包装的部分与真实局限TREK 是一个优秀的自托管工具但以下几点需要清醒认识SQLite 的天花板单文件数据库对家庭/小团队场景足够但如果你想做多租户平台或支撑数百名同时在线的用户SQLite 的并发写性能会成为瓶颈。官方没有提供 PostgreSQL 迁移路径。它不是推荐引擎也不是 OTATREK 不会告诉你这个城市什么景点值得去不会帮你比价机票不会和航空公司/酒店 PMS 直接对接。它的定位是规划和记录工具数据来源仍然依赖你自己的输入或 Google Places/OSM。运维不是零成本WebSocket 需要反向代理正确配置 upgrade 头PWA 强制需要 HTTPSENCRYPTION_KEY 必须妥善备份密钥丢失 加密数据无法解密更新时需要注意卷挂载路径。对完全没有 Linux/Docker 经验的用户30秒启动承诺更接近理想状态。1-2 人的简单旅行用 TREK 管理两个人的周末短途是典型的过度设计Google Maps 的保存列表就够了。个人启发该如何应用对于个人开发者/极客用户如果你已经在跑 Nextcloud 或 ImmichTREK 是非常自然的补充。Journey 模块可以和 Immich 照片直接集成Atlas 的访问国家统计功能对重度旅行者有实际记录价值。建议先跑 Demodemo.liketrek.com体验 15 分钟再决定是否自部署。对于多人出行的组织者实时协作 费用分摊Splitwise-style 打包清单分配这三个功能合在一起解决了团队出行最高频的协调痛点。这比在微信群里拼 Excel 表格要专业得多。对于 AI 工具重度用户MCP 集成是值得认真探索的功能。把 TREK 暴露给 Claude/Cursor让 AI 帮你从邮件 PDF 导入预订信息、自动建行程框架是真实可用的工作流而不是演示噱头。对于有商业化想法的开发者注意 AGPL-3.0 协议。如果你想基于 TREK 构建 SaaS 产品对外收费法务层面需要认真评估或者联系作者获取商业许可。延伸思考SQLite 是自托管工具的正确默认选择吗TREK 的 SQLite 方案降低了部署门槛但也锁死了水平扩展能力。随着自托管工具功能越来越复杂单文件数据库 vs 轻量级 PostgreSQL的选择将成为这类项目的重要分叉点——Forgejo、Gitea 的多数据库支持模式是否值得 TREK 参考MCP 作为权限标准会如何演化TREK 把 150 工具挂在 27 个 OAuth scope 下的设计本质上是在探索AI 代理的最小权限原则应该如何实现。如果这种模式在更多开源项目中被采用它可能发展成一个事实标准——反过来Anthropic 的 MCP 规范本身是否足够稳定会不会因为规范变更让这些投入打水漂自托管与隐私的悖论是否被高估了TREK 的核心卖点之一是数据留在自己服务器但大多数用户的出行数据目的地、时间本身并非高度敏感而自托管服务器的安全运维能力往往弱于 Google/Apple 的专业团队。自托管 更安全这个等式在实际场景中究竟在哪些维度成立、在哪些维度是一种安慰剂效应值得更理性地评估。 参考来源GitHub - liketrek/TREK: A self-hosted travel/trip planner with real-time collaboration, interactive maps, PWA support, SSO, budgets, packing lists, and more. · GitHub