01 - 背景与目标

1.1 Agent 技术发展现状与趋势

1.1.1 从 LLM 到 Agent 的演进

大语言模型（LLM）在 2023-2024 年经历了从”对话工具”到”执行引擎”的关键转变。根据 Anthropic 2024 年报告，Claude 3.5 Sonnet 在代码任务上的准确率达到 92.0%，相比 2023 年初的 GPT-3.5（48.1%）提升了近一倍。这一技术进步使得 LLM 具备了可靠的工具调用能力。

timeline
    title LLM to Agent 演进历程
    2022 : ChatGPT 发布
         : 纯对话能力
    2023 : GPT-4 Function Calling
         : 工具调用雏形
    2024 : Claude 3.5 + MCP
         : 标准化 Agent 协议
    2025 : Multi-Agent 协作
         : ACI 生态成熟

关键数据点：

2024 年 GitHub 上 “AI Agent” 相关项目增长 340%（Source: GitHub Octoverse 2024）
Gartner 预测到 2026 年，80% 的企业将使用 AI Agent 自动化至少一项业务流程
LangChain 月活开发者从 2023 年初的 5 万增长到 2024 年底的 50 万+

1.1.2 Agent 的核心能力需求

现代 AI Agent 需要具备以下关键能力，这些能力直接影响了接口设计范式：

能力	传统 API 支持度	ACI 支持度	说明
意图理解	❌ 低	✅ 高	将模糊输入映射到具体操作
上下文维护	❌ 无	✅ 有	跨调用保持状态
错误恢复	⚠️ 有限	✅ 强	对话式澄清与重试
多步推理	❌ 不支持	✅ 原生	链式工具调用
人类介入	❌ 无	✅ 支持	人机协作界面

1.2 传统 API 在 Agent 场景的局限性

1.2.1 精确性 vs 模糊性的冲突

传统 API 设计的核心是精确参数匹配。以 REST API 为例：

POST /api/orders
{
  "product_id": "string",      // 必须精确
  "quantity": "integer",       // 范围限制
  "shipping_address": {...}    // 嵌套校验
}

然而，Agent 的输入具有自然语言的不确定性：

用户说：“帮我订一杯大杯拿铁，送到公司”

Agent 需要：

识别意图：下单咖啡
提取参数：产品=拿铁，规格=大杯，地址=公司（需解析为具体地址）
处理缺失：用户没说糖分、温度偏好 → 需要询问或假设

根本矛盾：API 要求精确，Agent 输出必然模糊。

1.2.2 状态管理的复杂性

传统 API 采用无状态设计（Stateless），每次调用携带完整上下文（Token/Session）。而 Agent 场景需要有状态对话：

sequenceDiagram
    participant A as Agent
    participant T as Tool
    
    A->>T: 查询明天北京天气
    T-->>A: 25°C, 晴
    A->>T: 那上海呢？（隐含上下文）
    Note over T: 传统 API 无法理解"那"指什么
    T-->>A: 错误：缺少 location 参数

案例研究：OpenAI 2024 年报告显示，67% 的 Agent 工具调用失败源于上下文丢失，而非意图识别错误。

1.2.3 错误处理模式不匹配

错误类型	传统 API 处理	Agent 场景需求
参数缺失	返回 400 Bad Request	主动询问补充
参数歧义	返回 422 Unprocessable	请求澄清
执行失败	返回 500 + 错误码	解释原因 + 建议替代方案
权限不足	返回 403 Forbidden	指导如何获取权限

传统 API 的错误响应是机器可读的（JSON + 状态码），而 Agent 需要人类可读 + 可操作的响应。

1.3 ACI 概念提出背景与核心目标

1.3.1 ACI 的定义与起源

Agent-Computer Interface (ACI) 一词由 Anthropic 团队在 2024 年正式提出，用于描述专门为 AI Agent 设计的计算机交互协议。其核心理念是：

“ACI 是 Agent 与外部环境（工具、数据、人类）交互的抽象层，它理解自然语言意图，管理上下文状态，并支持双向对话式交互。”

ACI 并非要取代传统 API，而是在 API 之上构建语义理解层：

flowchart TB
    subgraph "传统架构"
        A[Client] -->|HTTP/JSON| B[REST API]
        B --> C[Service]
    end
    
    subgraph "ACI 架构"
        D[Agent] -->|自然语言| E[ACI Layer]
        E -->|语义理解| F[Tool Selector]
        F -->|精确调用| G[API Wrapper]
        G --> H[Underlying Service]
    end

1.3.2 ACI 的核心设计目标

语义化输入处理
- 接受自然语言或半结构化输入
- 自动提取参数并处理歧义
- 支持渐进式参数收集（多轮对话）
上下文感知能力
- 维护跨调用会话状态
- 理解指代消解（代词、省略）
- 支持长程依赖（跨多轮的信息关联）
双向交互模式
- 工具可主动向 Agent 询问
- 支持执行确认与撤销
- 人机协作接口（HITL - Human-in-the-loop）
可解释性输出
- 返回操作结果 + 执行理由
- 提供替代方案建议
- 可视化执行轨迹

1.3.3 ACI 解决的关键问题

问题	传统方案痛点	ACI 解决方案
意图到执行的映射	需要硬编码映射规则	基于 LLM 的动态语义解析
参数歧义处理	直接报错	对话式澄清
工具发现	依赖文档阅读	语义化工具描述
执行链编排	人工编写工作流	Agent 自主规划
错误恢复	中断执行	智能重试与替代

1.3.4 行业实践验证

Anthropic MCP (Model Context Protocol) 作为 ACI 的标准化实现，在 2024 年获得了广泛采用：

Cursor：2024 年 11 月宣布支持 MCP，开发者可自建工具
Claude Desktop：原生集成 MCP，支持本地工具发现
Vercel：推出 AI SDK 3.0，支持 MCP 协议
Sourcegraph：Cody 助手基于 MCP 构建工具生态

数据支撑：截至 2025 年 3 月，GitHub 上 MCP 相关项目超过 2,500 个，涵盖数据库查询、文件操作、浏览器自动化等场景。

1.4 本章小结

ACI 的兴起是 Agent 技术发展的必然结果。传统 API 的精确性假设与 Agent 输出的不确定性之间存在根本矛盾。ACI 通过引入语义理解层、上下文管理和双向交互模式，为 Agent 与计算机系统的协作提供了更自然的接口。

下一章将深入分析 ACI 的技术架构，对比其与传统协议在通信模型、交互模式和错误处理等方面的本质差异。

本章引用：

Anthropic. “Model Context Protocol Specification.” 2024. https://modelcontextprotocol.io
OpenAI. “Function Calling API Documentation.” 2024. https://platform.openai.com/docs/guides/function-calling
GitHub. “Octoverse 2024 Report.” https://github.com/octoverse
Gartner. “AI Agent Market Trends 2024-2026.”