跳转到主要内容

​
副驾模式与枢纽

该架构支持两种集成方式： 副驾模式嵌入宿主系统的 UI 中。用户无需离开熟悉的界面，即可与 AI 交互。它可以使用多个连接器 (如宿主数据库 + 通知服务等) 。 枢纽是一个连接所有系统的独立门户。它不嵌入任何单一系统——而是系统与 AI 交汇的中央智能层。 相同的连接器架构，不同的交付方式。副驾模式与枢纽使用相同的 ConnectorToolAdapter。

​
核心原则

客户无需修改任何代码。 FIM Agent 会主动桥接到其系统中——读取其数据库、调用其 API，并向其消息总线推送数据。客户只需提供凭据和网络访问权限。

​
三层架构

各层各自承担明确的职责：
层级职责何时变更
Platform编排、多租户、UI平台发布新功能时
Connector Governance Layer企业治理策略安全/合规要求发生变化时
MCP Protocol传输、工具接口标准永不（开放标准）
Legacy System业务数据和逻辑永不（这正是其核心所在）

​
为什么选择 MCP 作为传输层

适配器以 MCP 服务器 的形式实现。这是一个有意为之的架构选择：
  • 复用：FIM Agent 已内置 MCP Client (v0.3) 。新增遗留系统适配器时，可复用与接入任何 MCP 工具相同的基础设施。
  • 标准协议：MCP 是开放标准。无需自行设计或维护专有协议。
  • 生态系统：第三方 MCP 服务器 (数据库、API、SaaS 工具) 可开箱即用。
  • 进程隔离：每个 MCP 服务器都以独立进程运行。即使某个适配器行为异常，也不会导致整个平台崩溃。

​
仅靠 MCP 还无法提供什么

连接器治理层 补充了原生 MCP 所不具备的企业级治理能力：
关注点MCP连接器治理层
只读约束否通过操作上的 read_only 标志控制；默认禁止写操作
审计日志否记录每一次工具调用 (时间戳、用户、工具、参数、结果)
认证透传否代理宿主系统认证；智能体以已登录用户身份执行操作
确认门否写操作需要人工批准 (SSE confirmation_required)
熔断机制否连接失败时会触发优雅降级
操作分类否操作标记为读/写/管理，并按级别应用策略

​
为什么不自创协议

协议本身已经是成熟的通用能力。真正的技术价值在于适配器本身 (领域知识、模式映射、边缘情况处理) 以及治理层 (审计、认证、安全) 。自创一种传输协议只会增加维护成本，而不会带来额外能力。Stripe 使用 HTTPS；Docker 使用 cgroups；FIM Agent 使用 MCP。

​
部署模型

所有组件均在单个 Docker Compose 部署中运行。客户无需安装任何软件。
均由 FIM Agent 提供。客户仅需提供：
  • 数据库凭据（建议使用只读账户）
  • API 端点和密钥（如有）
  • 网络白名单访问权限
访问层级：FIM Agent 可适配客户能够提供的各种访问方式：
客户具备的条件FIM Agent 的连接方式
有文档的 APIHTTP API 适配器（最佳情况）
无文档的 APIHTTP API 适配器 + 手动 schema 映射
仅有数据库访问数据库适配器（直接 SQL，默认只读）
数据库 + 消息总线数据库适配器 + 消息推送适配器

​
智能体-连接器解耦

智能体将连接器视作普通工具。它并不知道，也不在意某个工具究竟是内置工具、第三方 MCP 服务器，还是遗留系统连接器。 这意味着：
  • 新增 一个系统 = 新增一个连接器配置。智能体代码无需变更。
  • 移除 一个连接器 = 移除相应配置。无需修改代码。
  • 同一个智能体可以在单个任务中同时使用内置工具和连接器。

​
热插拔演进

版本如何添加新的连接器需要重启吗？
v0.6编写带有连接器治理层的 Python MCP 服务器，并添加到 docker-compose重新部署
v0.8编写 YAML/JSON 配置，由平台生成 MCP 服务器重启
v1.0上传 OpenAPI 规范，AI 自动生成配置无需重启 (热插拔)
企业部署通常是“实施一次，运行数月”——热插拔是 v1.0 提供的便利特性，不是 v0.6 的要求。

​
数据流示例

用户：“检查财务系统中所有已逾期的合同，并将摘要推送到 Lark。“ 
1. 用户通过门户 / API 发送消息

2. FIM Agent（ReAct 模式）：
   Think: 我需要查询财务数据库中的逾期合同，然后推送到 Lark。

3. Act: contract_query(status="overdue", days_past_due=">30")
   → Connector Governance：审计日志，read_only 检查（通过）
   → MCP 服务器：转换为 SQL
   → Client DB: SELECT * FROM contracts WHERE status='overdue' AND ...
   ← 返回 7 份逾期合同

4. Think: 找到 7 份逾期合同。我将汇总并推送。

5. Act: lark_push(message="7 overdue contracts found: ...")
   → Connector Governance：审计日志，写操作 → 确认门
   → 用户通过门户批准
   → MCP 服务器：POST 到 Lark webhook
   ← 推送成功

6. Answer: "已找到 7 份逾期合同。摘要已推送到 Lark 群组。"

​
连接器标准化级别

级别版本方式构建方
第 1 级v0.6带连接器治理的 Python MCP 服务器FIM Agent 开发者
第 2 级v0.8YAML/JSON 配置，由平台自动生成 MCP 服务器实施工程师 (无需 Python)
第 3 级v1.0上传 OpenAPI/Swagger 规范，AI 自动生成配置AI (经人工审核)

​
与现有 MCP 生态系统的关系

FIM Agent 的 MCP Client（随 v0.3 发布）已支持第三方 MCP 服务器。遗留系统适配器本质上只是借助连接器治理层构建的面向特定领域的 MCP 服务器，以满足企业级治理要求。 连接器治理层并不取代 MCP——而是在 MCP 的基础上扩展了企业遗留系统集成所需的治理层。