Myosotis：AI原生工作空间控制台，统一团队AI工具配置与协作

1. 项目概述：一个为AI原生工作空间设计的“控制台”

如果你和我一样，最近几个月被各种AI Agent框架、MCP服务器和层出不穷的最佳实践搞得眼花缭乱，那你一定能理解这种“配置碎片化”的痛苦。每个新项目，每个新加入的团队成员，都需要重新经历一遍繁琐的Agent环境配置：安装Claude Code、配置OpenClaw、设置一堆MCP服务器、编写冗长的.claude或AGENTS.md文件。更头疼的是，团队内部的知识和最佳实践难以沉淀和同步，A同事调教好的高效“后端开发”技能，B同事可能完全不知道，又得从头摸索。

今天要聊的Myosotis，就是为了解决这个痛点而生的。它不是一个全新的Agent框架，也不是一个试图“套住”所有AI的“缰绳”。你可以把它理解为一个AI原生工作空间的“控制台”或“配置中心”。它的核心目标非常明确：统一团队的AI工具配置，实现一键式团队协作。它通过将所有的配置——MCP服务器列表、共享技能（Skills）、项目指令模板——都以纯文本文件的形式存放在一个Git仓库中，让团队里的每个开发者都能快速获得一套标准、强大且可同步的AI助手环境。

简单来说，Myosotis让你从一个“手工配置AI助手”的工匠，变成一个“管理并分发标准化AI生产力套件”的工程师。它解决的不是“如何让AI写代码”，而是“如何让团队里的每个人都用上同一套、不断进化的、最高效的AI写代码方式”。

2. 核心设计理念：为什么是“文件优先”和“控制台”？

在深入技术细节之前，理解Myosotis背后的两个核心设计理念至关重要。这能帮你判断它是否适合你的团队，以及如何最大化地利用它。

2.1 对抗配置碎片化：将“真理之源”归于文件

市面上很多内部工具或平台化的解决方案，喜欢把配置藏在数据库里，或者一个需要特殊权限才能访问的管理后台。这样做短期内看似整洁，长期却带来了新的问题：配置变成了黑盒，无法进行版本控制、难以Review、更别提Fork和独立修改了。当某个配置项导致AI行为异常时，排查起来异常困难。

Myosotis选择了截然不同的路径：文件优先。所有配置，无论是全局的MCP服务器定义，还是团队共享的“代码审查”技能，都以YAML、Markdown或JSON等纯文本格式，存放在项目的Git仓库里。这样做的好处是革命性的：

• 可版本控制：每一次对AI工作流的改进（比如优化了一个PR Review的提示词）都像代码提交一样，有清晰的提交历史、作者信息和变更内容。
• 可Review：团队成员可以通过Pull Request来讨论和审核对AI技能或配置的修改，确保变更的质量和安全性。
• 可复用与分叉：你可以轻松地将一套成熟的配置（例如，为React前端项目优化过的技能集）复制到新的项目仓库中，或者基于它创建适合不同技术栈的变体。
• 本地自治：开发者可以在本地直接编辑这些文件，立即测试效果，而不需要等待平台部署或申请权限。

我的实操心得：这种“配置即代码”的理念，极大地降低了心理负担。你不需要学习一个新的配置管理系统，你只需要用你熟悉的Git工作流去管理另一类“基础设施代码”。当你的skills/目录和mcp/配置被纳入CI/CD流程时，你甚至可以实现AI助手能力的自动化测试和部署。

2.2 控制台的价值：可视化管理与文件源头的桥梁

既然一切都用文件管理，为什么还需要一个Next.js开发的Web控制台？这不是多此一举吗？

恰恰相反，这个“控制台”是Myosotis设计中的点睛之笔。它扮演了一个双向适配器的角色：

1. 面向用户（可视化）：它为不习惯直接编辑YAML或复杂配置的团队成员（如项目经理、产品设计师）提供了一个直观的界面。他们可以通过UI查看团队有哪些可用的AI技能，将它们绑定到具体项目，或者调整一些基础参数，而无需理解底层文件结构。
2. 面向系统（同步与分发）：控制台的核心功能是读取仓库中的配置文件，并将其“同步”或“注入”到目标位置。例如，它可以确保每个项目的根目录下，都有一份根据模板生成的、最新的AGENTS.md和CLAUDE.md文件。它也可以将本地开发环境的配置与云端共享的团队配置进行比对和同步。

这个控制台本身并不存储“真理”，它只是“真理”（即Git仓库中的文件）的一个实时、友好的视图和操作界面。所有在UI上的操作，最终都会映射为对底层配置文件的修改（或生成基于这些文件的应用层配置）。这种设计保证了系统的简洁性和可维护性。

3. 项目结构深度解析：每个目录都在做什么？

拿到Myosotis的仓库，你会发现它的结构非常清晰，每个目录都有明确的职责。理解这个结构，是进行定制和扩展的基础。

myosotis/ ├── web/ # 核心：Next.js 控制台应用 ├── compose/ # 核心：Docker Compose 部署套件 ├── infra/terraform/aws/ # 核心：AWS云基础设施代码 ├── templates/ # 配置：全局及项目级指令模板 ├── mcp/ # 配置：MCP服务器配置文件模板 ├── skills/ # 配置：团队共享技能库 ├── bootstrap/ # 工具：本地环境同步与初始化脚本 ├── checks/ # 工具：环境与配置验证脚本 └── docs/ # 文档：架构、指南等

3.1 配置核心 (templates/,mcp/,skills/)

这是Myosotis的“弹药库”，存放所有可共享的AI资产。

• templates/：这里存放的是各种Markdown指令模板。例如，project-claude.md.j2可能是一个Jinja2模板，用于为每个项目生成定制的CLAUDE.md文件。模板中可以变量，比如{{ project_name }}、{{ tech_stack }}，在同步时由控制台或脚本填充。global-instructions.md则可能包含适用于所有项目和AI助手的通用行为准则。
• mcp/：这里定义了团队标准化的MCP服务器配置。MCP是Model Context Protocol的缩写，它让AI模型可以安全地调用外部工具（如读取文件系统、执行命令、查询数据库）。在这个目录下，你可能会看到serge.yaml、filesystem.yaml等配置文件，它们指明了使用哪些MCP服务器、如何连接它们（如本地socket或远程URL）。Myosotis的价值在于统一这些配置，确保团队每个成员本地运行的Claude Code都连接了相同的一套工具。
• skills/：这是知识沉淀的关键。每个子目录（如skills/backend/,skills/frontend/,skills/pr-review/）代表一个“技能”。一个技能通常包含：
  • README.md: 技能描述和使用场景。
  • instructions.md: 核心提示词，定义了AI在执行此任务时应遵循的步骤、规则和输出格式。
  • examples/: 输入输出示例，用于Few-shot Learning。
  • config.yaml: 可能关联的MCP工具或特定参数。 团队可以共同维护和优化这些技能，新人入职后直接继承整个团队的“集体智慧”。

3.2 运行时与部署核心 (web/,compose/,infra/)

这是让“弹药库”发挥作用的“发射平台”。

• web/：基于Next.js 16构建的控制台前端。它通过读取环境变量CONFIG_ROOT（默认指向仓库根目录）来获取上述配置，并提供UI。它的构建和运行方式与标准Next.js应用无异。
• compose/：这是最推荐的自托管方式。它通过Docker Compose定义了一个完整的运行时环境，通常包括：
  • app服务：运行打包好的Next.js应用。
  • database服务：如PostgreSQL，用于存储UI相关的用户状态、项目绑定关系等（注意：核心配置仍在Git中）。
  • proxy服务：如Nginx/Caddy，处理反向代理和HTTPS。
  • deploy.sh脚本：自动化部署流程。 这种方式将依赖全部容器化，极大简化了部署复杂度。
• infra/terraform/aws/：为需要云端共享工作流的团队提供。有些AI工作流可能是长时间运行的后台任务（如定时分析代码库），需要一台始终在线的服务器。这个Terraform模块可以一键创建包含EC2（运行Docker Compose）、RDS（数据库）、Secrets Manager（管理密钥）的AWS环境。它提供了从零到有的云基础设施代码。

3.3 工具脚本 (bootstrap/,checks/)

这些是提升体验的“润滑剂”。

• bootstrap/：包含像sync-local.sh这样的脚本。开发者新克隆项目后，可能只需要运行一条命令，这个脚本就会：
  1. 根据全局配置，在本地安装必要的MCP服务器（如mcp-server-filesystem）。
  2. 将团队共享的skills/目录链接或复制到本地AI助手（如Claude Desktop）的配置路径下。
  3. 为当前项目生成并放置.archon/、AGENTS.md等文件。 实现真正的“60秒 onboarding”。
• checks/：健康检查脚本。用于验证本地环境是否满足要求、项目配置是否完整、云端服务是否健康等。可以集成到CI或部署流程中。

4. 从零开始：本地开发与生产部署实操

了解了结构，我们来动手，看看如何把Myosotis用起来。我会分为本地开发调试和正式生产部署两个场景。

4.1 本地开发与体验

目的是在本地运行控制台，并连接到你现有的配置仓库进行体验和修改。

步骤1：获取代码并安装依赖

# 克隆仓库（这里以项目方仓库为例，你也可以Fork） git clone https://github.com/shiftbloom-studio/myosotis.git cd myosotis # 进入Web应用目录并安装依赖 cd web npm install # 或使用 pnpm/yarn

注意：确保你的Node.js版本符合package.json中的要求（通常>=18）。使用nvm等工具管理多版本是个好习惯。

步骤2：配置环境并运行Myosotis应用默认从环境变量CONFIG_ROOT指定的目录读取配置。在开发时，我们通常就让它读取仓库根目录。

# 在web目录下，启动开发服务器 npm run dev

启动后，打开浏览器访问http://localhost:3000。你应该能看到控制台界面，并且它已经加载了仓库中自带的示例配置（templates/,mcp/,skills/里的内容）。

步骤3：理解本地开发流程此时，你可以：

• 浏览配置：在UI中查看现有的技能和MCP配置。
• 实时编辑：直接用IDE打开并修改仓库根目录下的配置文件（如skills/frontend/instructions.md）。
• 热重载：由于Next.js的热重载特性，以及应用直接读取文件系统，你的修改通常会在保存后几秒内反映在UI上（可能需要手动刷新页面）。
• 测试同步：你可以运行bootstrap/sync-local.sh（可能需要根据你的AI助手路径稍作修改）来测试配置同步到本地的效果。

这个本地开发循环非常高效，你可以像开发普通Web应用一样，迭代Myosotis的控制台UI和背后的配置逻辑。

4.2 使用Docker Compose自托管（生产推荐）

对于小团队或想在内网部署的场景，Docker Compose是最简单、最可靠的方式。

步骤1：准备部署目录建议将部署相关的文件单独管理。你可以复制compose目录到你的服务器上，或者在一个新的目录中组织。

# 在你的服务器上 mkdir -p /opt/myosotis cd /opt/myosotis # 将Myosotis仓库中的compose目录内容复制过来 # 假设你已经将代码克隆到了服务器，或者通过scp上传 cp -r /path/to/myosotis/compose/* .

步骤2：配置环境变量Compose配置依赖环境变量文件。复制示例文件并进行修改：

cp .env.shared.example .env.shared vim .env.shared # 或使用nano等其他编辑器

关键配置项通常包括：

# 数据库配置 POSTGRES_DB=myosotis POSTGRES_USER=myosotis_user POSTGRES_PASSWORD=<生成一个强密码> DATABASE_URL=postgresql://myosotis_user:<密码>@db:5432/myosotis # Next.js 应用配置 NEXTAUTH_SECRET=<生成一个强随机字符串，用于加密会话> NEXTAUTH_URL=https://your-domain.com # 你的访问域名 CONFIG_ROOT=/app/config # 容器内配置挂载路径 # 其他可选配置，如OAuth登录密钥等

重要提示：NEXTAUTH_SECRET必须是一个足够复杂的随机字符串，可以使用openssl rand -base64 32命令生成。NEXTAUTH_URL必须与你最终访问应用的地址完全一致，否则身份验证会失败。

步骤3：准备配置数据你需要将你的配置仓库（即包含skills/、mcp/、templates/的那个Git仓库）放到服务器上，并挂载到容器中。有两种方式：

1. 直接克隆：在服务器上克隆你的配置仓库到/opt/myosotis/data/config。
2. 子模块或挂载卷：更优雅的方式是将配置仓库作为compose目录的子模块（git submodule），这样配置和部署代码可以一起管理。

假设你采用方式1：

mkdir -p /opt/myosotis/data cd /opt/myosotis/data git clone <你的配置仓库Git地址> config

然后，你需要确保docker-compose.yml文件中的卷挂载配置正确指向这个路径。检查compose/docker-compose.yml中类似下面的部分：

services: app: ... volumes: - ./data/config:/app/config:ro # 将本地配置目录只读挂载到容器内 ...

步骤4：构建并启动

# 在/opt/myosotis目录下，运行部署脚本（如果提供了的话） bash deploy.sh # 或者直接使用docker-compose命令 docker-compose up -d --build

-d表示后台运行，--build会重新构建镜像。首次运行会花费一些时间下载基础镜像和构建Next.js应用。

步骤5：验证与访问使用docker-compose logs -f app查看应用日志，确认没有错误。如果一切正常，配置的反向代理（如compose中的Caddy）会处理HTTPS。现在你就可以通过配置的域名（如https://your-domain.com）访问你的Myosotis控制台了。

4.3 部署到AWS（可选，用于团队共享工作流）

如果你的团队需要运行一些长期在线的AI辅助服务（例如，一个监听GitHub webhook自动进行代码审查的Agent），那么将其部署到云端是必要的。Myosotis提供了Terraform脚本来搭建这个基础。

步骤1：准备Terraform环境确保服务器或本地机器上安装了Terraform和AWS CLI，并且AWS CLI已配置了具有足够权限的Access Key。

步骤2：初始化与配置

cd infra/terraform/aws cp terraform.tfvars.example terraform.tfvars

编辑terraform.tfvars文件，填入你的配置，如AWS区域、EC2实例类型、VPC ID、子网、域名等。

# terraform.tfvars 示例 region = "us-east-1" instance_type = "t3.medium" vpc_id = "vpc-xxxxxx" subnet_id = "subnet-xxxxxx" domain_name = "myosotis.yourcompany.com" ssh_key_name = "your-ec2-key-pair"

步骤3：规划与部署基础设施

terraform init # 初始化，下载AWS provider terraform plan # 查看执行计划，确认将要创建的资源 terraform apply # 执行创建，输入yes确认

执行成功后，Terraform会输出EC2实例的公网IP、RDS数据库端点等信息。

步骤4：在EC2上部署应用Terraform主要创建基础设施（网络、服务器、数据库），应用本身的部署还需要一步。你需要登录到新创建的EC2服务器，然后重复4.2节的Docker Compose部署步骤。

1. 通过SSH连接到EC2实例。
2. 在EC2上安装Docker和Docker Compose。
3. 将你的compose目录和配置数据上传或克隆到EC2。
4. 根据RDS的信息，修改compose/.env.shared中的DATABASE_URL。
5. 运行docker-compose up -d。

现在，你就拥有了一个在AWS上运行的、高可用的Myosotis共享工作流平台。团队成员可以通过这个统一的云端入口，访问和触发那些需要长时间运行或集中处理的AI任务。

5. 定制化进阶：打造属于自己团队的技能库

Myosotis开箱提供了一些示例技能和模板，但它的真正威力在于你和你团队的定制。下面我将以创建一个“数据库变更评审”技能为例，展示完整的定制流程。

5.1 定义技能结构与元数据

首先，在skills/目录下创建一个新的技能文件夹。

cd /path/to/your/config-repo mkdir -p skills/db-migration-review cd skills/db-migration-review

创建一个skill.yaml（或config.yaml）文件来定义技能元数据：

# skills/db-migration-review/skill.yaml name: Database Migration Reviewer description: | 审查数据库迁移脚本（如Liquibase, Flyway, Django Migrations, Alembic脚本）， 检查常见问题如缺少索引、数据回滚策略、性能隐患、与模型定义不一致等。 version: 1.0.0 author: Platform Engineering Team tags: - database - devops - code-review - sql inputs: - description: "数据库迁移SQL文件或脚本内容" type: "text" required: true outputs: - description: "结构化审查报告，包含风险等级、具体问题、修改建议" type: "markdown" dependencies: mcp_servers: - name: "sql-lint" # 假设有一个用于SQL静态分析的MCP服务器 - name: "git" # 用于获取上下文，如本次迁移关联的模型变更

这个YAML文件帮助控制台和其他工具理解这个技能的用途、输入输出格式以及依赖。

5.2 编写核心提示词

这是技能的灵魂。在instructions.md中，你需要用自然语言清晰地告诉AI如何扮演这个评审角色。

# 技能：数据库迁移评审专家 ## 你的角色 你是一个经验丰富的DBA和后台开发工程师，专门负责审查团队提交的数据库变更脚本，确保其安全性、性能、可回滚以及与应用程序代码的一致性。 ## 审查流程 请你按以下顺序对提供的迁移脚本进行审查： 1. **语法与基础检查**：检查SQL语法是否正确，是否符合项目使用的数据库方言（如PostgreSQL 14）。 2. **安全性检查**： - 是否有全表更新/删除操作（`UPDATE/DELETE` without `WHERE`）？必须标记为高危。 - 是否包含明文密码、密钥等敏感信息？ - 权限设置是否过于宽松（如`GRANT ALL`）？ 3. **性能与可扩展性检查**： - 新增的字段是否在频繁查询的`WHERE`或`ORDER BY`子句中使用？如果是，是否已添加索引？ - 新增的索引是否冗余？检查是否与现有索引重复或包含顺序不合理。 - 是否有潜在的表锁问题（如在大表上添加非空字段且无默认值）？ 4. **数据完整性检查**： - 外键约束是否定义正确？`ON DELETE`和`ON UPDATE`规则是否合适？ - 字段的`NULL/NOT NULL`约束是否与应用层模型一致？ - 默认值设置是否合理？ 5. **回滚策略检查**： - 是否提供了对应的`down`迁移或回滚脚本？ - 回滚脚本是否经过测试，能否真正将数据库恢复到之前的状态？ 6. **与业务逻辑一致性检查**（如果提供了相关模型代码）： - 迁移脚本中的字段类型、长度是否与ORM模型定义匹配？ - 枚举值的变更是否同步更新了应用层的枚举定义？ ## 输出格式 请以以下Markdown格式输出审查报告： ### 数据库迁移审查报告 **文件：** `[文件名]` **总体风险等级：** 🟢 低风险 / 🟡 中风险 / 🔴 高风险 #### 🔍 发现的问题 | 行号 | 风险等级 | 问题描述 | 建议修改 | | :--- | :--- | :--- | :--- | | 15 | 🟡 | 在`users`表上新增索引`idx_email`，但已存在`idx_user_email`，可能冗余。 | 确认业务查询模式，考虑合并或删除其中一个索引。 | | 28 | 🔴 | `DELETE FROM logs WHERE created_at < NOW() - INTERVAL '30 days'` 缺少索引，可能导致全表扫描和锁表。 | 建议在`created_at`字段上添加索引，或分批次删除。 | #### 💡 优化建议 1. 建议为`created_at`字段添加索引以加速删除操作。 2. 建议在部署前在预发环境执行一次回滚测试。 #### ✅ 通过检查项 - 语法正确。 - 提供了完整的回滚脚本。 - 外键约束定义合理。

这个提示词定义了详细的审查逻辑和结构化的输出要求，让AI的评审工作有章可循，输出结果也便于集成到CI/CD的评论中。

5.3 提供示例（Few-shot Learning）

为了让AI更好地理解你期望的输入输出，创建examples/目录并添加实例。

mkdir examples

在examples/下创建example1_input.sql和example1_output.md。

• example1_input.sql内容是一个有问题的迁移脚本。
• example1_output.md内容就是你期望AI生成的、符合上述格式的审查报告。

当在技能配置中引用这些示例后，AI在评审时会参考这些范例，使输出更稳定、更符合预期。

5.4 集成到工作流

技能创建好后，你需要让它被团队用起来。

1. 提交到配置仓库：将skills/db-migration-review/目录推送到团队的Git配置仓库。
2. 在控制台中启用：在Myosotis控制台的技能管理页面，应该能看到这个新技能。你可以将其分配给特定的项目或项目组。
3. 同步到本地：团队成员运行bootstrap/sync-local.sh后，这个新技能会被同步到他们本地的AI助手配置中。
4. 在CI/CD中调用（进阶）：你可以编写一个GitHub Actions或GitLab CI脚本，在收到包含.sql文件的Pull Request时，自动调用配置了此技能的AI服务（例如通过Anthropic的API或自托管的Claude实例）进行评审，并将报告以评论形式贴到PR中。

通过这样的流程，一个原本依赖于个别专家经验的“数据库迁移评审”知识，就变成了团队可共享、可迭代、可自动化的标准资产。

6. 常见问题与故障排查实录

在实际部署和使用Myosotis的过程中，你可能会遇到一些典型问题。以下是我在实践和社区交流中总结的一些常见情况及其解决方法。

6.1 本地开发环境问题

问题1：运行npm run dev后，控制台页面空白或报错“无法读取配置”。

• 可能原因A：CONFIG_ROOT环境变量未正确指向包含配置的目录。
  • 排查：检查Next.js启动日志，确认CONFIG_ROOT的值。在web目录下，默认会读取上级目录。你可以显式设置：CONFIG_ROOT=../ npm run dev。
• 可能原因B：配置文件格式错误（如YAML语法错误）。
  • 排查：Next.js服务端可能在解析配置文件时崩溃。查看终端是否有YAML解析错误。使用yamllint等工具检查你的YAML文件。
• 可能原因C：文件权限问题（主要在Linux/macOS）。
  • 排查：确保Node.js进程有权限读取CONFIG_ROOT目录及其下的所有文件。

问题2：修改了skills/下的Markdown文件，但UI没有实时更新。

• 可能原因：Next.js的Fast Refresh对非pages/或app/目录下的文件监听可能不敏感。
  • 解决：手动刷新浏览器页面。如果问题持续，可以尝试重启开发服务器。这是一种已知的折衷方案，因为配置文件的变更频率通常远低于前端代码。

6.2 Docker Compose部署问题

问题1：运行docker-compose up -d后，应用容器不断重启。

• 排查步骤：
  1. 查看日志：docker-compose logs -f app查看应用容器的具体错误。
  2. 常见错误A - 数据库连接失败：日志中可能出现“Connection refused”或“database does not exist”。检查compose/.env.shared中的DATABASE_URL是否正确，特别是密码和数据库名。确保db服务（PostgreSQL）先于app服务健康启动。Docker Compose的depends_on只能控制启动顺序，不能保证数据库就绪。可以考虑在app的启动命令中添加等待数据库的脚本。
  3. 常见错误B - 缺少NEXTAUTH_SECRET：NextAuth.js需要这个密钥。确保.env.shared中设置了NEXTAUTH_SECRET，并且值是一个强随机字符串。
  4. 常见错误C - 配置路径挂载失败：检查docker-compose.yml中的volumes挂载，确保本地./data/config目录存在且有正确内容。

问题2：访问应用时，提示“Invalid OAuth callback”或身份验证失败。

• 可能原因：NEXTAUTH_URL环境变量设置错误。这个值必须与你浏览器中访问应用的地址完全一致，包括http还是https。
  • 解决：如果你通过http://localhost:3000访问，NEXTAUTH_URL必须是http://localhost:3000。如果你通过反向代理（如Caddy）使用HTTPS访问https://myosotis.example.com，那么NEXTAUTH_URL必须是https://myosotis.example.com。修改.env.shared并重启应用。

6.3 配置与同步问题

问题1：bootstrap/sync-local.sh脚本执行失败，无法链接文件到本地AI助手目录。

• 可能原因：脚本中的目标路径与你的AI助手（如Claude Desktop）的实际配置路径不匹配。
  • 解决：打开bootstrap/sync-local.sh脚本，找到设置目标路径（如CLAUDE_DESKTOP_CONFIG_DIR）的部分。根据你的操作系统和Claude Desktop的安装位置修改这个路径。通常路径可能是：
    • macOS:~/Library/Application Support/Claude
    • Windows:%APPDATA%\Claude
    • Linux:~/.config/Claude
  • 我的心得：我建议在脚本开头添加一个路径检测和提示的逻辑，或者让用户通过环境变量来覆盖目标路径，使脚本更具可移植性。

问题2：在控制台为项目添加了技能，但本地同步后，AI助手似乎没有调用该技能。

• 排查步骤：
  1. 检查技能文件：确认技能目录下的instructions.md等文件内容正确，并且已成功同步到本地AI助手的配置目录。
  2. 检查AI助手配置：确认你的AI助手（如Claude Desktop）已正确配置并启用了MCP服务器，且MCP服务器指向了Myosotis同步过来的配置。有时需要重启AI助手客户端才能加载新的配置。
  3. 检查技能调用方式：不同的AI助手调用技能的方式不同。在Claude Desktop中，你可能需要在对话中通过@技能名的方式来触发。确保你使用了正确的调用方式。
  4. 查看AI助手日志：Claude Desktop等工具通常有调试日志，查看日志中是否有关于加载技能或MCP服务器的错误信息。

6.4 性能与扩展性问题

问题：当技能库和MCP配置非常多时，控制台页面加载变慢。

• 分析：Next.js应用在启动或访问页面时，需要读取并解析文件系统中所有的YAML和Markdown文件。如果文件数量巨大（例如上千个技能），可能会导致服务器响应缓慢。
• 优化建议：
  1. 实现缓存：在Next.js的API路由或服务端组件中，对文件读取和解析结果进行缓存（例如使用node-cache或lru-cache）。可以设置一个合理的TTL（如30秒），在文件变更后通过Webhook或文件监听来主动清除缓存。
  2. 分页与懒加载：在控制台UI中，对技能和项目列表实现分页或虚拟滚动，不要一次性加载所有数据。
  3. 索引文件：可以创建一个index.json或manifest.yaml文件，在配置变更时由CI/CD流水线或一个后台进程生成。这个索引文件只包含技能/配置的元数据（名称、描述、标签等），控制台优先加载这个轻量级的索引文件，详情页再按需加载具体内容。
  4. 数据库存储元数据：对于非常大规模的使用，可以考虑将技能的元数据（非内容）存入数据库，文件系统只作为内容的“源”，这样列表查询会快很多。但这增加了系统复杂度，背离了“文件优先”的简洁性，需权衡。

7. 总结与未来演进思考

Myosotis代表了一种非常务实的工程化思路：不追求创造一个无所不能的超级AI框架，而是专注于解决AI工具在团队协作中遇到的最实际、最痛的问题——配置管理和知识沉淀。它的“文件优先”哲学和“控制台”设计，在灵活性和易用性之间找到了一个很好的平衡点。

从我个人的使用体验来看，最大的收益在于团队认知负荷的降低。新同事入职，不再需要口口相传或者翻阅零散的文档去配置AI环境；一个团队成员发现了优化Prompt的技巧，可以通过一个Pull Request立刻分享给所有人；团队在特定领域（如性能调优、安全审计）积累的AI使用经验，可以固化成一个可复用的“技能”，持续产生价值。

当然，它目前更像一个精心设计的“起点”和“模式”。围绕它，还有大量的演进可能性：

• 更强大的技能市场与发现机制：未来或许可以有一个公共的技能注册中心，团队可以像使用npm包一样，引入其他团队开源的高质量技能。
• 技能效果评估与A/B测试：为技能添加测试用例和评估指标，通过历史对话数据来量化一个技能的有效性，并支持A/B测试不同的提示词版本。
• 与CI/CD的深度集成：不仅仅是PR评论，技能可以作为CI流水线中的一个标准检查步骤，例如自动进行代码风格检查、依赖漏洞扫描、甚至生成单元测试。
• 多模型支持：目前它主要围绕Claude设计，但其架构是模型无关的。可以扩展其配置，使其能同时管理针对GPT、Gemini等其他模型的优化提示和工具配置。

如果你正在为团队中AI工具使用的混乱而烦恼，Myosotis提供了一个极具参考价值的解决方案范本。即使不完全采用它，其“配置即代码”和“控制台作为视图”的设计思想，也值得你在构建自己的AI基础设施时深思。