从一个聊天入口到业务助手：贾维斯的平台架构怎样分工？

第一次看 AI 助手，最容易注意到的是聊天窗口。真正开始建设时，问题很快会变多：模型在哪里配置？资料怎样进入回答？工具由谁执行？已有系统还需要承担哪些工作？

这些问题决定了 AI 能否融入日常应用，也决定了团队应该把开发精力放在哪里。

项速科技的贾维斯 AI 助手，围绕 Vue 3 组件、门户和 Spring Boot 服务端组织产品能力。理解它们的分工，有助于技术负责人评估接入范围，也能让业务负责人知道，一个场景需要准备哪些资源。

先看三个项目分别承担什么
jarvis-assistant-vue 是用户接触助手的组件层，承载会话及相关管理交互，并提供身份、请求和路由等适配接口。

jarvis-assistant-portal 是配套门户，组织产品与管理入口，同时也是组件接入的参考应用。

jarvis-assistant-server 提供服务端能力，以 Spring Boot 为基础，包含认证、会话、模型供应商、Agent、知识库和 MCP 等模块。

三者配合时，组件与门户负责让人能够使用和管理能力，服务端组织模型与资源调用；已有业务系统则继续提供可靠的数据和业务规则。

一次问题，会用到哪些模块？
假设团队希望增加“产品答疑助手”。作为建设方案，可以先准备有效的产品资料，配置一个职责明确的 Agent，再让用户从业务应用里的组件入口发起提问。

请求进入服务端后，需要经过身份识别。会话模块组织问题，Agent 配置决定使用的模型及关联资源。涉及知识问答时，知识模块提供相关片段；涉及实时状态时，则需要可用的 MCP 工具连接外部系统。

模块 在场景中承担的工作
认证 判断请求怎样进入平台服务
会话 组织消息与流式响应
模型供应商 管理模型连接相关配置
Agent 关联职责、模型及任务资源
知识库 管理文档并提供检索内容
MCP 管理服务连接与工具调用
这张表也可以用来拆分团队工作。前端人员处理入口和交互，服务端人员处理连接与认证，业务人员确认资料和任务边界，系统负责人提供接口与授权。

知识和业务数据，在架构里各有位置
文档能够说明规则，却无法天然提供当前订单状态；订单接口能够提供实时记录，却未必能完整解释服务政策。

贾维斯通过 Agent 将知识库与 MCP 服务关联起来，让两类资源有机会在同一项任务中配合。对于接入团队，这种分工意味着可以独立维护资料与业务接口：文档由内容负责人更新，接口由业务系统负责人维护，再共同验证助手的输出。

架构能帮你复用什么，又需要准备什么？
贾维斯提供了助手入口、Agent 资源组织、知识管理和工具连接等实现基础。对于已有系统，接入工作可以围绕宿主身份、服务地址、模型、资料和业务接口展开。

具体部署仍需准备数据库、缓存、模型连接，以及知识处理和工具运行需要的依赖。能够正常运行某个模块，不等于所有业务能力已经同时启用，应该按实际场景逐项验证。

评估交付范围时，还要区分基础构建和扩展能力。当前后端文档将计费、订阅及租户管理列为独立 Pro 扩展，不能把它们当作基础构建默认包含的全部功能。

从一个可验证的场景开始
对技术团队，架构图可以帮助确定接入点；对业务团队，更有效的起点是选定一个问题。例如先做产品资料答疑，再评估是否需要查询库存或订单。

把需要的模块、资料、接口和负责人对应起来，项目范围就会清楚：哪些可以复用，哪些要适配，哪些还需要补充验证。

如果你正在为已有应用寻找 AI 助手的建设基础，可以访问贾维斯 AI 助手官网（ https://jarvis.speedproject.cn/ ），结合这张分工图评估组件接入与服务端集成方式。