02 - ACI 技术原理核心

2.1 ACI 协议架构与通信模型

2.1.1 分层架构设计

ACI 采用三层架构设计，在传统的客户端-服务端模型之间引入语义中间层：

flowchart TB
    subgraph "Presentation Layer"
        A[Agent / LLM]
    end
    
    subgraph "ACI Semantic Layer"
        B[Intent Parser<br/>意图解析器]
        C[Context Manager<br/>上下文管理器]
        D[Tool Orchestrator<br/>工具编排器]
        E[Response Formatter<br/>响应格式化器]
    end
    
    subgraph "Tool Execution Layer"
        F[Tool A Adapter]
        G[Tool B Adapter]
        H[Tool C Adapter]
    end
    
    subgraph "Service Layer"
        I[Database]
        J[APIs]
        K[File System]
    end
    
    A -->|Natural Language| B
    B --> C
    C --> D
    D --> F
    D --> G
    D --> H
    F --> I
    G --> J
    H --> K
    E --> A
    F --> E
    G --> E
    H --> E

各层职责：

层级	组件	核心职责
表示层	Agent/LLM	生成自然语言意图，理解响应
语义层	Intent Parser	将模糊输入解析为结构化意图
	Context Manager	维护会话状态，处理指代消解
	Tool Orchestrator	选择工具，编排执行链
	Response Formatter	将工具输出转换为自然语言
执行层	Tool Adapters	将 ACI 调用转换为底层 API 调用
服务层	Services	实际业务逻辑执行

2.1.2 通信模型：请求-协商-执行

与传统 API 的请求-响应模型不同，ACI 采用请求-协商-执行（Request-Negotiate-Execute）模型：

sequenceDiagram
    participant A as Agent
    participant AC as ACI Layer
    participant T as Tool
    
    A->>AC: 请求（可能不完整）
    
    alt 参数完整
        AC->>T: 直接执行
        T-->>AC: 结果
        AC-->>A: 响应
    else 参数缺失
        AC-->>A: 询问补充
        A->>AC: 提供补充
        AC->>T: 执行
        T-->>AC: 结果
        AC-->>A: 响应
    else 参数歧义
        AC-->>A: 请求澄清
        A->>AC: 确认意图
        AC->>T: 执行
        T-->>AC: 结果
        AC-->>A: 响应
    end

关键差异：ACI 允许多轮交互以达成共识，而非一次性精确调用。

2.1.3 MCP 协议实例分析

Model Context Protocol (MCP) 是 ACI 的标准化实现，其通信流程如下：

// 1. 工具发现
{
  "jsonrpc": "2.0",
  "method": "tools/list",
  "id": 1
}

// 2. 工具描述（ACI Schema）
{
  "tools": [{
    "name": "query_database",
    "description": "查询数据库获取数据",
    "inputSchema": {
      "type": "object",
      "properties": {
        "sql": {
          "type": "string",
          "description": "SQL 查询语句"
        }
      },
      "required": ["sql"]
    }
  }]
}

// 3. 工具调用（支持自然语言参数）
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "sql": "SELECT * FROM orders WHERE date > '2024-01-01'"
    }
  },
  "id": 2
}

2.2 与传统 API/REST/GraphQL 的本质区别

2.2.1 协议设计哲学对比

维度	REST API	GraphQL	gRPC	ACI
设计目标	资源操作	数据查询	高效 RPC	意图执行
接口契约	URL + HTTP Method	Schema	Protobuf	语义描述
输入方式	精确参数	精确查询	精确消息	自然语言
错误处理	状态码	错误扩展	状态码	对话式澄清
状态管理	无状态	无状态	可流式	有状态会话
版本管理	URL 版本	Schema 演进	协议版本	向后兼容语义

2.2.2 接口描述方式演进

传统 OpenAPI (REST)：

paths:
  /orders:
    post:
      summary: 创建订单
      parameters:
        - name: product_id
          required: true
          schema:
            type: string
        - name: quantity
          required: true
          schema:
            type: integer
            minimum: 1

特点：

精确类型定义
严格校验规则
机器优先阅读

ACI Schema (MCP)：

{
  "name": "create_order",
  "description": "为用户创建新订单。支持自然语言描述，如'一杯大杯拿铁'或'两份三明治'。",
  "examples": [
    {
      "input": "一杯大杯拿铁，送到公司",
      "output": {"product": "latte", "size": "large", "address": "company"}
    }
  ],
  "inputSchema": {
    "type": "object",
    "properties": {
      "description": {
        "type": "string",
        "description": "订单的自然语言描述"
      }
    }
  }
}

特点：

语义化描述
提供示例引导
支持模糊输入
人类和 Agent 均可理解

2.2.3 调用复杂度对比

场景：查询”张三最近的 3 个订单”

REST API 调用：

# 需要 3 次调用
# 1. 查询用户 ID
GET /users?name=张三
# 2. 查询订单列表
GET /orders?user_id=xxx&sort=date_desc&limit=3
# 3. 获取订单详情（如需要）
GET /orders/{id}

ACI 调用：

Agent -> ACI: "查询张三最近的 3 个订单"
ACI -> Tool: 自动执行上述 3 步
Tool -> ACI: 返回聚合结果
ACI -> Agent: "张三最近 3 个订单：1) 咖啡 (3天前) 2) 书籍 (1周前)..."

效率提升：ACI 将编排复杂度从客户端转移到协议层，Agent 只需表达意图。

2.3 面向 Agent 的交互模式设计

2.3.1 意图解析机制

ACI 的核心能力是将模糊意图映射到精确操作：

flowchart LR
    A[自然语言输入] --> B{意图分类}
    B -->|查询| C[Query Intent]
    B -->|操作| D[Action Intent]
    B -->|创建| E[Creation Intent]
    
    C --> F[参数提取]
    D --> F
    E --> F
    
    F --> G[实体识别]
    G --> H[槽位填充]
    H --> I[工具选择]

技术实现：

Few-shot Prompting：通过示例教会 LLM 意图映射
Function Calling：OpenAI/Anthropic 原生支持的工具调用格式
ReAct Pattern：推理（Reasoning）+ 行动（Acting）交替执行

2.3.2 上下文管理机制

ACI 需要维护多层级上下文：

上下文类型	范围	示例
会话级	单次对话	用户偏好、历史指令
任务级	当前任务	多步操作的状态
工具级	特定工具	数据库连接、缓存
全局级	跨会话	用户画像、权限

MCP 上下文传递示例：

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "query_orders",
    "arguments": {
      "query": "最近的"  // 模糊，依赖上下文
    },
    "context": {
      "user_id": "user_123",
      "last_query": "查看我的订单",
      "timezone": "Asia/Shanghai"
    }
  }
}

2.3.3 渐进式确认模式

对于高风险操作（支付、删除），ACI 采用渐进式确认：

sequenceDiagram
    participant A as Agent
    participant AC as ACI
    participant T as Tool
    
    A->>AC: "删除所有草稿"
    AC-->>A: "将删除 15 个草稿文件，确认吗？"
    A->>AC: "确认"
    AC->>T: 执行删除
    T-->>AC: "已删除 15 个文件"
    AC-->>A: "已完成，删除：file1.txt, file2.txt..."

优势：

减少误操作
提供操作预览
支持撤销（在超时窗口内）

2.4 语义理解与意图识别机制

2.4.1 语义 Schema 设计原则

ACI 的 Schema 不仅是类型定义，更是语义引导：

原则	说明	示例
描述优先	用自然语言说明用途	”查询用户最近的订单”
示例驱动	提供典型输入输出	3-5 个示例
约束表达	用描述而非硬规则	”日期格式为 YYYY-MM-DD”
歧义处理	说明如何澄清	”如未指定时间，询问用户”

2.4.2 工具选择算法

当多个工具可能匹配时，ACI 使用相关性评分：

def score_tool_match(intent, tool):
    score = 0
    
    # 1. 名称相似度（语义嵌入）
    score += semantic_similarity(intent, tool.name) * 0.3
    
    # 2. 描述匹配度
    score += semantic_similarity(intent, tool.description) * 0.4
    
    # 3. 示例匹配度
    for example in tool.examples:
        score += similarity(intent, example.input) * 0.2
    
    # 4. 历史成功率
    score += tool.success_rate * 0.1
    
    return score

阈值策略：

score > 0.8：直接执行
0.5 < score < 0.8：请求确认
score < 0.5：拒绝或询问

2.4.3 多语言与跨文化支持

ACI 需要处理不同语言的意图表达：

语言	表达方式	ACI 处理
英文	”Book a table for 2 at 7pm”	直接解析
中文	”晚上7点订个两人桌”	时区转换
日文	”今夜7時に2名で予約”	敬语处理
口语	”帮我整个明天下午3点的会议室”	口语化映射

2.5 本章小结

ACI 的技术架构在三个维度实现了对传统协议的突破：

通信模型：从请求-响应演进为请求-协商-执行，支持多轮对话达成共识
接口描述：从精确类型定义转向语义化描述 + 示例驱动
交互模式：引入意图解析、上下文管理和渐进式确认

这些技术特性使得 ACI 更适合 Agent 的不确定性和对话特性。下一章将通过对比矩阵，系统性分析 ACI 与传统 API 的差异。

本章引用：

Anthropic. “Model Context Protocol Specification.” 2024.
OpenAI. “Function Calling Best Practices.” 2024.
LangChain. “Tool Design Patterns Documentation.” 2024.
ReAct Paper: “ReAct: Synergizing Reasoning and Acting in Language Models.” 2023.