企业官网建设流程全解析

1. 为什么我要自己动手做一个工作台

1.1 从一次崩溃说起

去年冬天的一个深夜，我正在赶一个跨端项目的收尾工作。浏览器里开着十几个标签页，终端里跑着三个服务，IDE 里还有两个窗口在切换。就在我准备把最后一段逻辑跑通的时候，整个工作台卡死了——不是某一个工具崩了，而是我拼凑起来的这套“工作流”整体崩了。那一刻我盯着屏幕，脑子里只有一个念头：我到底是在用工具，还是在被工具用？

这不是我第一次有这种感受。过去两年，我陆续试过市面上几乎所有主流的协作工作台产品，包括那个被很多人奉为标杆的 workbuddy。它们确实好用，界面漂亮，功能齐全，团队协作也顺畅。但问题在于，当你的工作流稍微偏离它预设的轨道时，你就只能迁就它。你想接一个自己的脚本？得写插件。你想让 AI 帮你处理一段私有数据？得看它支不支持。你想把工作台搬到自己的服务器上？对不起，那是企业版才有的待遇。

所以我决定自己做一个。这个项目我给它起名叫“魔力工作台”，定位很明确：一个开源的、可自托管的、以 Agent 为核心的工作台替代方案。它不是要做一个大而全的协作平台，而是要做一个真正属于使用者自己的工作台——你可以把它跑在自己的机器上，接自己的模型，写自己的 Agent，数据完全留在自己手里。

1.2 这个工作台到底解决什么问题

说得直白一点，魔力工作台要解决的是三个层面的问题。

第一个层面是数据主权。你用别人的工作台，你的笔记、你的任务、你的对话记录，全都存在别人的服务器上。这不是说别人一定会拿你的数据做什么，而是你根本没有选择权。魔力工作台从第一天起就把“可自托管”作为核心设计原则，所有数据默认存在本地，你可以用 SQLite，也可以换成 Postgres，完全由你决定。

第二个层面是工作流的可编程性。传统工作台的工作流是产品经理设计好的，你只能在这个框架里操作。魔力工作台把工作流抽象成 Agent 和 MCP 工具的组合，你可以用配置文件定义一个新的 Agent，给它挂上几个 MCP 工具，它就能帮你处理特定类型的任务。比如你可以做一个专门处理周报的 Agent，挂上文件读取和邮件发送两个工具，每周五下午自动跑一遍。

第三个层面是AI 能力的可替换性。现在几乎所有工作台都在往 AI 上靠，但大多数产品只支持自家或少数几家模型。魔力工作台把模型层做了抽象，你可以接 OpenAI 兼容的接口，也可以接本地跑的模型，甚至可以同时配置多个模型让不同的 Agent 使用不同的后端。这一点对于有数据合规要求的团队来说尤其重要。

1.3 适合谁来用

这个项目不是给所有人准备的。如果你只是想要一个开箱即用的笔记软件，那市面上有太多比它成熟的选择。魔力工作台适合的是这样几类人：

• 有自托管需求的开发者或小团队：你希望数据留在自己的服务器上，但又不想从零搭建一套工作流系统。
• 想深入理解 Agent 和 MCP 机制的技术人：这个项目的代码结构相对清晰，适合作为学习 Agent 架构的参考实现。
• 需要定制化工作流的重度用户：你受够了在别人的框架里将就，想要一个能按自己想法改造的工作台。
• 对 AI 工作流有探索兴趣的爱好者：你想试试把不同模型、不同工具组合起来能做出什么效果。

如果你属于以上任何一类，那接下来的内容应该会对你有帮助。我会从整体设计思路讲起，然后拆解核心模块的实现细节，再给出完整的部署和配置步骤，最后分享一些我在开发和实际使用中踩过的坑。

2. 整体架构设计与技术选型思路

2.1 为什么选择前后端分离加 Agent 层的三层结构

魔力工作台的整体架构可以概括为三层：前端界面层、后端服务层、Agent 执行层。这个结构不是拍脑袋定的，而是经过了几轮推倒重来之后才确定下来的。

最开始我尝试的是单体架构，前端后端揉在一起，Agent 逻辑直接写在后端服务里。这样做的好处是开发快，一个进程跑起来就完事。但很快问题就暴露了：Agent 的执行往往是耗时的、不确定的，一个 Agent 任务可能跑几十秒甚至几分钟，如果它和后端服务在同一个进程里，一个卡住的 Agent 就会拖垮整个服务。而且 Agent 的执行环境往往需要不同的依赖，比如有的 Agent 需要 Playwright 来操作浏览器，有的需要访问文件系统，把这些都塞进后端服务里会让依赖变得极其臃肿。

所以后来我改成了现在这个结构。前端是一个独立的 SPA 应用，负责界面渲染和用户交互；后端是一个 API 服务，负责数据持久化、任务调度和状态管理；Agent 执行层是一个独立的运行时，负责实际执行 Agent 逻辑和调用 MCP 工具。三层之间通过明确定义的接口通信，Agent 层可以水平扩展，也可以单独重启而不影响其他层。

这个设计还有一个好处是部署灵活性。你可以把三层都跑在同一台机器上，适合个人使用；也可以把 Agent 层单独部署到一台性能更强的机器上，适合团队使用。对于资源受限的环境，甚至可以只跑后端和前端，Agent 功能按需启用。

2.2 后端为什么选 Spring Boot 而不是 Node 或 Go

这是一个我被问得最多的问题。说实话，在项目启动的时候我认真考虑过 Node.js 和 Go。Node 的生态和前端统一，Go 的并发模型和部署便利性都很吸引人。但最终我选了 Spring Boot，原因有几个。

第一是生态成熟度。工作台这类应用涉及的东西很杂：用户认证、权限控制、数据库访问、定时任务、文件存储、消息队列。Spring Boot 在这些方面都有经过大规模验证的解决方案，我不需要自己去拼装和调试。特别是 Spring Security 和 Spring Data 这两块，能省下大量时间。

第二是团队协作的考虑。虽然这个项目目前主要是我在维护，但我希望它能吸引更多贡献者。Java 开发者群体庞大，Spring Boot 又是 Java 后端的事实标准，降低贡献门槛这一点很重要。

第三是与现有系统的集成。很多企业内部的系统是 Java 写的，用 Spring Boot 做后端，未来如果要和这些系统对接会方便很多。这一点在我后来接一个内部项目时就体现出了价值。

当然，选 Spring Boot 也有代价。启动慢、内存占用高，这些是客观存在的。我的应对方式是把 Agent 执行层独立出去，用更轻量的运行时来实现，这样后端服务的压力就小了很多。对于个人使用场景，我建议至少给后端分配 512MB 内存，团队使用建议 1GB 以上。

2.3 Agent 运行时为什么用 Rust 重写

Agent 执行层最初是用 Python 写的，因为 Python 的 AI 生态最丰富，接各种模型和工具都方便。但用了一段时间后，我发现了几个问题。

首先是分发问题。Python 的依赖管理在跨平台分发时是个噩梦，用户需要装 Python、装虚拟环境、装一堆包，稍微有点版本冲突就跑不起来。这对于一个希望降低使用门槛的开源项目来说是不可接受的。

其次是资源占用。Python 的运行时内存占用不小，而且 GIL 的存在让并发处理变得复杂。Agent 执行层需要同时处理多个 Agent 任务，还要管理 MCP 连接，Python 在这方面确实吃力。

最后是启动速度。Agent 执行层需要频繁启停（比如按需拉起一个 Agent 任务），Python 的启动开销在这个场景下很明显。

所以后来我用 Rust 重写了 Agent 运行时。Rust 的编译产物是单个二进制文件，用户下载下来就能跑，不需要任何运行时依赖。内存占用小，启动速度快，并发模型也适合 Agent 这种 IO 密集型的场景。代价是开发效率确实比 Python 低，特别是接一些只有 Python SDK 的服务时需要自己写 HTTP 客户端。但考虑到最终用户的体验，这个代价是值得的。

2.4 MCP 作为工具接入标准的考量

MCP 是这个项目里一个关键的技术选择。简单来说，MCP 是一套让 AI 模型能够调用外部工具的协议标准。你可以把它理解成 AI 世界的 USB 接口——只要工具实现了 MCP 协议，任何支持 MCP 的 Agent 都能调用它。

我选择 MCP 作为工具接入标准，核心原因是解耦。在没有 MCP 之前，每接一个工具都要写一套适配代码，工具和 Agent 是强耦合的。有了 MCP，工具的实现和 Agent 的实现可以完全独立，工具开发者只需要关心怎么把功能暴露成 MCP 服务，Agent 开发者只需要关心怎么调用 MCP 工具。这大大降低了扩展成本。

魔力工作台内置了几个常用的 MCP 工具，比如文件操作、HTTP 请求、数据库查询、浏览器自动化（基于 Playwright）。同时它也支持接入外部的 MCP 服务，你可以在配置文件里声明一个 MCP 服务的地址和启动方式，工作台会自动拉起并管理这个服务。

这里有个细节值得说一下：MCP 服务有两种运行模式，一种是 stdio 模式，服务作为一个子进程运行，通过标准输入输出通信；另一种是 SSE 模式，服务作为一个 HTTP 服务运行，通过 Server-Sent Events 通信。魔力工作台两种模式都支持，stdio 模式适合本地工具，SSE 模式适合远程工具或需要独立部署的工具。

3. 核心模块的实操要点与实现细节

3.1 工作台前端的关键交互设计

前端这块我踩的坑最多，因为工作台这类应用的交互复杂度远超普通的管理后台。它需要同时处理多种类型的内容：文档、任务、对话、文件、Agent 执行状态。这些内容之间还有复杂的关联关系，比如一个任务可能关联一个文档，一个对话可能触发一个 Agent 任务。

我最终采用的方案是三栏布局加浮动面板。左侧是导航栏，放工作区切换和主要功能入口；中间是主内容区，根据当前选中的内容类型渲染不同的视图；右侧是上下文面板，显示与当前内容相关的信息，比如关联的任务、最近的对话、Agent 执行日志。浮动面板用于处理临时性的内容，比如快速笔记、命令面板、Agent 执行结果预览。

这个布局的核心思路是保持上下文可见。传统的工作台往往是在不同页面之间跳转，跳转之后之前的上下文就丢了。三栏布局让用户在处理一个任务时，能同时看到相关的文档和对话，不需要来回切换。

命令面板是我个人最喜欢的一个功能。按下快捷键（默认是 Ctrl/Cmd + K）会弹出一个搜索框，可以快速跳转到任何工作区、文档、任务，也可以直接执行命令，比如“新建任务”“运行 Agent”“切换主题”。这个功能看起来简单，但实际使用中能极大提升效率。实现上它就是一个带模糊搜索的下拉列表，但背后的索引和搜索逻辑需要仔细设计，否则内容一多就会卡。

3.2 后端任务调度与状态管理

后端最核心的模块是任务调度和状态管理。工作台里的很多操作都是异步的：Agent 执行、文件处理、数据同步。这些操作不能阻塞用户请求，需要有一套可靠的调度机制。

我用的是基于数据库的轻量级任务队列，而不是引入 Redis 或 RabbitMQ 这类外部依赖。原因很简单：对于工作台这个量级的应用，引入外部消息队列会增加部署复杂度，而收益有限。基于数据库的队列虽然性能上限低一些，但对于个人和小团队使用完全够用，而且部署简单，一个数据库就搞定。

任务表的设计大概是这样的：每个任务有状态（pending、running、completed、failed）、优先级、重试次数、执行结果、错误信息。调度器是一个定时任务，每隔几秒扫描一次待执行的任务，按优先级取出并分配给执行器。执行器执行完任务后更新状态。如果任务失败且重试次数未用完，就重新入队。

这里有个细节需要注意：任务执行的幂等性。因为任务可能会重试，所以执行逻辑必须保证多次执行的结果一致。比如一个“发送通知”的任务，如果第一次执行成功了但状态更新失败，重试时就会重复发送。我的做法是在任务执行前先检查一个幂等键，如果这个键已经处理过就直接跳过。这个幂等键通常是任务 ID 加操作类型的组合。

状态管理这块，我用的是事件溯源加状态快照的混合模式。每次状态变更都会记录一条事件，同时定期生成状态快照。这样既能追溯完整的变更历史，又能在需要时快速恢复状态。对于工作台这种需要展示操作历史的场景，事件溯源特别合适。

3.3 Agent 执行引擎的工作机制

Agent 执行引擎是整个项目里最复杂的部分，也是我花时间最多的模块。它的核心职责是：接收一个 Agent 任务，加载 Agent 定义，准备上下文，调用模型，处理模型返回的工具调用请求，执行工具，把结果返回给模型，循环直到任务完成。

这个循环看起来简单，但实际实现中有很多细节要处理。首先是上下文管理。模型的上下文窗口是有限的，当对话轮次多了之后，历史消息会超出窗口。我的做法是维护一个滑动窗口，保留最近的消息，同时对更早的消息做摘要。摘要本身也是一次模型调用，所以需要控制摘要的频率，不能每轮都做。

其次是工具调用的错误处理。模型可能会调用一个不存在的工具，或者传入错误的参数，或者工具执行本身失败。这些情况都需要妥善处理，把错误信息返回给模型，让模型有机会纠正。我的做法是把工具调用的结果统一封装成一个结构，包含成功标志、结果数据、错误信息。模型看到错误信息后通常会调整策略。

第三是执行超时和中断。Agent 任务可能因为各种原因卡住，比如模型响应慢、工具执行超时。我设置了多级超时：单次模型调用超时、单次工具调用超时、整个任务超时。任何一级超时都会触发中断，把任务标记为失败并记录原因。同时支持用户手动中断正在执行的任务。

第四是执行日志的记录。Agent 执行过程中的每一步都需要记录，包括模型请求和响应、工具调用和结果、中间状态变更。这些日志对于调试和审计都很重要。我用的是结构化日志，每条日志是一个 JSON 对象，包含时间戳、任务 ID、步骤类型、详细内容。日志默认存在数据库里，也支持输出到文件。

3.4 MCP 工具的接入与管理

MCP 工具的接入是魔力工作台扩展性的关键。目前支持两种接入方式：内置工具和外部 MCP 服务。

内置工具是直接编译进 Agent 运行时的，包括文件读写、HTTP 请求、JSON 处理、文本处理、时间日期等基础功能。这些工具的特点是高频使用、无外部依赖、性能要求高，所以直接内置。

外部 MCP 服务通过配置文件声明。一个典型的配置大概是这样：

mcp_servers: - name: playwright mode: stdio command: npx args: ["-y", "@playwright/mcp@latest"] env: BROWSER: chromium - name: database mode: sse url: http://localhost:8081/mcp headers: Authorization: "Bearer ${DB_MCP_TOKEN}"

stdio 模式的服务由工作台负责拉起和生命周期管理，工作台启动时拉起服务，关闭时终止服务。SSE 模式的服务需要用户自己保证服务可用，工作台只负责连接。

工具的管理界面会列出所有可用的工具，包括内置和外部接入的，显示每个工具的名称、描述、参数 schema。用户可以在创建 Agent 时选择要挂载的工具。这里有个设计上的取舍：是让 Agent 自动发现所有工具，还是让用户手动选择？我选择了后者，因为工具太多会让模型的选择变得困难，而且有些工具涉及敏感操作，不应该默认暴露给所有 Agent。

4. 从零部署魔力工作台的完整流程

4.1 环境准备与依赖检查

部署魔力工作台之前，需要确认环境满足以下要求。我按最低配置和推荐配置分别列一下，你可以根据自己的场景选择。

除了硬件，还需要准备一个模型服务的访问凭证。魔力工作台支持任何 OpenAI 兼容的接口，所以你需要的是一组 base URL 和 API Key。如果你打算用本地模型，需要先部署好推理服务，比如用 Ollama 或 vLLM，然后拿到本地的接口地址。

注意：如果你打算用 SQLite，请确保磁盘有足够的写入权限，并且不要放在网络文件系统上，SQLite 在网络文件系统上的表现很不稳定。

4.2 后端服务的配置与启动

后端服务的配置主要通过application.yml文件。我整理了一份最小可用配置，你可以直接抄：

server: port: 8080 servlet: context-path: /api spring: datasource: url: jdbc:sqlite:./data/magic-workbench.db driver-class-name: org.sqlite.JDBC jpa: hibernate: ddl-auto: update show-sql: false servlet: multipart: max-file-size: 50MB max-request-size: 100MB magic: agent: runtime-url: http://localhost:9090 default-timeout: 300s auth: jwt-secret: ${JWT_SECRET:please-change-this-in-production} token-expire: 7d storage: type: local local-path: ./data/files

几个关键配置说明一下。spring.datasource.url是数据库连接，用 SQLite 的话就是一个文件路径，用 Postgres 的话改成对应的 JDBC URL。magic.agent.runtime-url是 Agent 运行时的地址，如果 Agent 运行时和后端在同一台机器上，就是 localhost。magic.auth.jwt-secret是 JWT 签名密钥，生产环境一定要改，而且要通过环境变量注入，不要写在配置文件里。

启动命令很简单：

java -jar magic-workbench-server.jar --spring.config.location=./application.yml

第一次启动会自动建表，日志里会打印初始化信息。启动完成后访问http://localhost:8080/api/health应该返回{"status":"UP"}。

4.3 Agent 运行时的部署与模型接入

Agent 运行时的部署更简单，因为它是一个静态编译的二进制文件。下载对应平台的二进制，赋予执行权限，然后写一个配置文件：

[server] port = 9090 log_level = "info" [models] default = "gpt-4o" [models.providers.openai] base_url = "https://api.openai.com/v1" api_key = "${OPENAI_API_KEY}" models = ["gpt-4o", "gpt-4o-mini"] [models.providers.local] base_url = "http://localhost:11434/v1" api_key = "ollama" models = ["qwen2.5:14b", "llama3.1:8b"] [mcp] config_path = "./mcp-servers.yaml"

模型配置这块支持多个 provider，每个 provider 可以暴露多个模型。Agent 定义里可以指定用哪个模型，不指定就用 default。这样你可以让简单的任务用便宜的小模型，复杂的任务用大模型，控制成本。

启动 Agent 运行时：

./magic-agent-runtime --config ./agent-config.toml

启动后会监听 9090 端口，后端服务会自动发现并连接。你可以在工作台的设置页面看到 Agent 运行时的状态和可用模型列表。

4.4 第一个 Agent 的创建与测试

部署完成后，建议先创建一个简单的 Agent 来验证整条链路。我以“每日天气播报”为例，这个 Agent 的功能是每天早上查询指定城市的天气，然后生成一段播报文本。

首先在工作台的 Agent 管理页面点击新建，填写基本信息：

• 名称：每日天气播报
• 描述：每天早上查询天气并生成播报
• 模型：gpt-4o-mini（这个任务简单，用小模型就够）
• 系统提示词：你是一个天气播报助手，根据提供的天气数据生成一段简洁的播报文本，包含温度、天气状况和穿衣建议。

然后挂载工具。这个 Agent 需要一个 HTTP 请求工具来调用天气 API。魔力工作台内置了 HTTP 工具，直接勾选即可。工具的参数 schema 会自动注入到模型的上下文中。

接下来配置触发方式。我选择的是定时触发，cron 表达式设为0 0 7 * * ?，表示每天早上 7 点执行。执行时传入的参数是城市名称，这里我填的是“北京”。

保存后可以手动触发一次测试。在工作台的 Agent 详情页点击“立即执行”，观察执行日志。正常情况下你会看到：模型收到任务 -> 模型决定调用 HTTP 工具 -> 工具执行返回天气数据 -> 模型根据数据生成播报文本 -> 任务完成。整个过程大概几秒钟。

如果执行失败，日志里会有详细的错误信息。常见的失败原因包括：API Key 无效、网络不通、模型返回格式不符合预期。排查的时候先看日志里的模型请求和响应，大部分问题都能从这里找到线索。

5. 实际使用中踩过的坑与排查技巧

5.1 Agent 执行卡住不返回怎么办

这是我在实际使用中遇到最多的问题。Agent 执行卡住的表现是任务状态一直是 running，日志停在某一步不再更新。造成这个问题的原因通常有三类。

第一类是模型响应慢或超时。有些模型服务在高峰期响应很慢，如果超时设置得太长，任务就会一直卡着。我的做法是把单次模型调用的超时设为 60 秒，超过就中断并重试。重试两次还失败就标记任务失败。这个超时时间可以根据你用的模型服务调整，本地模型可以设短一点，云端模型设长一点。

第二类是工具执行阻塞。比如 HTTP 工具请求了一个不响应的地址，或者浏览器自动化工具卡在某个页面加载上。这类问题的排查方法是看工具调用的日志，如果日志显示工具开始执行但没有结束记录，那就是工具卡住了。解决方式是给每个工具调用设置独立的超时，并且支持强制中断。

第三类是死循环。模型可能会陷入反复调用同一个工具的循环，比如一直查询同一个数据。这种情况比较隐蔽，因为日志一直在更新，看起来像是在正常工作。我的应对方式是设置最大迭代次数，默认是 20 轮，超过就强制结束。同时在提示词里明确告诉模型不要重复调用相同的工具。

实操心得：我建议在 Agent 的配置里都显式设置超时和最大迭代次数，不要依赖默认值。不同任务的最优值差别很大，比如一个简单的查询任务 3 轮就够了，一个复杂的数据处理任务可能需要 15 轮。

5.2 MCP 服务连接失败的排查思路

MCP 服务连接失败是另一个高频问题。表现是 Agent 执行时报错“工具不可用”或“MCP 服务连接超时”。排查的时候按以下顺序来。

首先确认 MCP 服务本身是否正常运行。如果是 stdio 模式，检查启动命令和参数是否正确，可以手动在终端执行一遍看能不能跑起来。如果是 SSE 模式，用 curl 测试一下服务地址是否可达。

然后检查配置。stdio 模式的常见问题是命令路径不对，比如用了npx但环境变量里没有 Node.js 的路径。SSE 模式的常见问题是 URL 写错或者认证头缺失。我建议在配置里把日志级别调到 debug，这样能看到 MCP 通信的详细过程。

还有一个容易被忽略的问题是端口冲突。如果多个 MCP 服务用了同一个端口，后面的会启动失败。我建议给每个 SSE 模式的 MCP 服务分配独立的端口，并且在配置里显式指定。

下面这张表是我整理的常见 MCP 问题速查：

5.3 数据备份与迁移的注意事项

工作台用久了，数据就是最宝贵的资产。我在这上面吃过一次亏，有一次服务器磁盘故障，因为没有及时备份，丢了一周的对话记录。从那以后我把备份做成了自动化流程。

备份的核心是数据库和文件存储两块。数据库用 SQLite 的话，直接复制文件就行，但要注意在复制前先执行VACUUM INTO命令生成一个一致的快照，不要直接复制正在写入的文件。用 Postgres 的话，用pg_dump导出。文件存储就是数据目录，直接打包。

迁移的时候有个坑要注意：数据库里的文件路径是相对路径还是绝对路径。如果存的是绝对路径，迁移到新机器后路径就失效了。我的做法是统一存相对路径，相对于配置里的存储根目录。这样迁移时只需要保证存储根目录的结构一致就行。

还有一个细节是时区。数据库里存的时间戳统一用 UTC，展示的时候再转成本地时区。如果迁移前后服务器的时区设置不同，不做这个处理就会出现时间错乱。

5.4 性能优化的几个实用技巧

工作台用久了会变慢，这是正常的，因为数据在增长。我总结了几个实用的优化技巧。

第一个是数据库索引。默认的索引只覆盖了主键和几个外键，但实际查询中经常按时间范围、按状态、按用户过滤。给这些字段加上索引能显著提升查询速度。我用的是复合索引，比如(user_id, created_at)和(status, priority)。

第二个是日志清理。Agent 执行日志增长很快，一个活跃的 Agent 一天能产生几千条日志。我设置了一个保留策略，默认保留 30 天，超过的自动归档到冷存储或直接删除。归档的话可以导出成压缩文件，需要的时候再导入。

第三个是前端虚拟滚动。工作台里的列表可能很长，比如任务列表、日志列表。一次性渲染所有项会卡顿，用虚拟滚动只渲染可视区域内的项，性能提升很明显。我用的是成熟的虚拟滚动库，不需要自己实现。

第四个是模型调用缓存。有些 Agent 任务的结果是可以缓存的，比如查询类任务，同样的输入在短时间内结果不会变。我给模型调用加了一层缓存，key 是模型加提示词加参数的哈希，value 是响应。缓存有效期默认 5 分钟，可以在配置里调整。这个优化对于高频重复查询的场景效果很好。

6. 这个项目后续可以怎么扩展

6.1 多用户与权限体系的完善

目前魔力工作台主要面向个人和小团队，多用户支持还比较基础。下一步我打算完善权限体系，引入工作区和角色的概念。一个工作区可以有多个成员，每个成员有不同的角色，比如管理员、编辑者、只读用户。不同角色对工作区内的资源有不同的操作权限。

这个功能的实现难点在于权限的粒度。是工作区级别的权限，还是资源级别的权限？我倾向于先做工作区级别，因为实现简单，能满足大部分场景。资源级别的权限留到后面按需添加。权限的存储用经典的 RBAC 模型，用户关联角色，角色关联权限，权限用字符串表示，比如workspace:read、agent:execute。

6.2 Agent 市场的构想

现在创建 Agent 需要用户自己写提示词、选工具、配参数，对非技术用户来说门槛还是有点高。我想做一个 Agent 市场，让用户可以分享和获取别人做好的 Agent。市场里的 Agent 以配置文件的形式存在，包含提示词、工具列表、参数默认值。用户一键导入就能用，也可以基于别人的 Agent 做二次修改。

市场的实现涉及几个问题：Agent 的版本管理、依赖声明、安全审核。版本管理用语义化版本号，依赖声明列出需要的 MCP 工具和模型能力，安全审核主要是检查提示词里有没有恶意内容。这些都需要一套完整的机制来支撑。

6.3 移动端适配与离线能力

现在的工作台主要是桌面端体验，移动端只是简单适配，用起来不太顺手。我打算做一个专门的移动端界面，针对触屏操作优化。核心场景是查看任务状态、审批 Agent 执行结果、快速记录想法。

离线能力是另一个方向。工作台的核心数据可以缓存在本地，离线时也能查看和编辑，联网后自动同步。这个功能的实现比较复杂，涉及冲突解决、增量同步、本地存储管理。我打算用 CRDT 来做冲突解决，这样多端同时编辑也不会丢数据。

6.4 与更多外部系统的集成

工作台的价值很大程度上取决于它能连接多少外部系统。目前已经支持了文件系统、HTTP、数据库、浏览器这几类。后续我打算增加更多集成，比如日历、邮件、即时通讯、代码仓库。这些集成大部分可以通过 MCP 工具来实现，不需要改动核心代码。

集成的关键是认证和授权。每个外部系统都有自己的认证方式，OAuth、API Key、Token 各不相同。我打算做一个统一的凭证管理模块，用户在一个地方配置凭证，各个工具引用凭证的别名。这样既方便管理，也避免了凭证散落在各个配置里。

我在实际开发和使用的这段时间里，最大的体会是：做一个工作台，技术上的难点其实都能克服，真正难的是想清楚它到底为谁解决什么问题。魔力工作台不是要做一个比 workbuddy 更好的产品，而是要做一个不同的选择——一个把控制权交还给使用者的选择。这个定位决定了它的功能取舍、技术选型和演进方向。如果你也认同这个方向，欢迎来项目里看看，提 issue、提 PR 都行。踩过的坑我都写在文档里了，希望能帮你少走点弯路。