多AI集成架构设计与实现：统一接口与协议适配

1. 多AI集成架构的设计初衷

在开发HagiCode平台时，我们遇到了一个典型的工程难题：如何优雅地支持多种AI工具的集成。最初的做法是为每个AI提供者编写独立的对接代码，但随着支持的AI工具数量增加，这种方案很快暴露出几个关键问题：

• 代码耦合度高：业务逻辑中充斥着针对特定AI工具的if-else判断
• 维护成本大：每次新增或修改AI工具都需要改动多处代码
• 扩展性差：新工具接入需要重复实现相似逻辑

提示：在设计多服务集成架构时，过早的差异化处理往往是技术债务的主要来源。我们通过后期重构发现，前期节省的设计时间最终都以更高的维护成本偿还了。

2. 核心架构设计解析

2.1 统一接口抽象

我们定义了IAIProvider接口作为所有AI提供者的契约，其设计遵循了几个关键原则：

csharp复制public interface IAIProvider
{
    // 提供者标识
    string Name { get; }
    
    // 是否支持流式响应
    bool SupportsStreaming { get; }
    
    // 能力描述
    ProviderCapabilities Capabilities { get; }

    // 核心方法
    Task<AIResponse> ExecuteAsync(AIRequest request, CancellationToken cancellationToken = default);
    IAsyncEnumerable<AIStreamingChunk> StreamAsync(AIRequest request, CancellationToken cancellationToken = default);
    Task<ProviderTestResult> PingAsync(CancellationToken cancellationToken = default);
    IAsyncEnumerable<AIStreamingChunk> SendMessageAsync(AIRequest request, string? embeddedCommandPrompt = null, CancellationToken cancellationToken = default);
}

这个设计的精妙之处在于：

1. 能力描述与实现分离：通过Capabilities属性声明提供者的功能特性，调用方无需关心具体实现
2. 同步/异步统一：同时提供一次性执行(ExecuteAsync)和流式响应(StreamAsync)两种模式
3. 扩展点预留：嵌入式命令支持通过SendMessageAsync的可选参数实现

2.2 通信协议适配层

针对不同AI工具的通信协议差异，我们设计了专门的适配层：

WebSocket实现(IFlowCliProvider)

mermaid复制graph TD
    A[IFlowCliProvider] --> B[ACPSessionManager]
    B --> C[WebSocketAcpTransport]
    C -->