OpenAI 的 Agent 开放之路：加入 Agentic AI Foundation 背后的技术考量

OpenAI 加入 Agentic AI Foundation，这件事本身就值得玩味。一个以”闭源模型 + 开放 API”著称的公司，选择把自己绑进一个开放治理的框架里。这背后有技术考量，也有商业博弈。

OpenAI 的 Agent 技术栈

在讨论 AAIF 之前，先理清 OpenAI 在 Agent 领域的技术布局：

OpenAI Agent 技术栈
├── 模型层：GPT-4o / o3 / o4-mini
├── API 层：Responses API + Structured Outputs
├── 工具层：Function Calling（原生）
├── 框架层：Agents SDK（Swarm 的正式版）
└── 协议层：逐步拥抱 MCP

OpenAI 最早走的是 Function Calling 路线——每个 LLM 提供商定义自己的工具调用格式。这种方式简单直接，但有明显的生态碎片化问题：

// OpenAI Function Calling
const response = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [{ role: 'user', content: '查一下今天的天气' }],
  tools: [{
    type: 'function',
    function: {
      name: 'get_weather',
      description: '获取指定城市的天气',
      parameters: {
        type: 'object',
        properties: {
          city: { type: 'string', description: '城市名称' },
        },
      },
    },
  }],
});

// Claude Tool Use（类似的，但格式不同）
const response = await anthropic.messages.create({
  model: 'claude-sonnet-4-20250514',
  messages: [{ role: 'user', content: '查一下今天的天气' }],
  tools: [{
    name: 'get_weather',
    description: '获取指定城市的天气',
    input_schema: {
      type: 'object',
      properties: {
        city: { type: 'string', description: '城市名称' },
      },
    },
  }],
});

功能上几乎一样，但 JSON Schema 的写法、请求格式、响应结构都有差异。对开发者来说，每接一个 LLM 就要适配一套工具调用格式，这不叫生态，叫碎片化。

Function Calling vs MCP

OpenAI 从 Function Calling 转向拥抱 MCP，这个转变有技术必然性：

维度	Function Calling	MCP
工具定义	内嵌在每次请求中	Server 端声明，客户端发现
跨模型复用	需要重新适配	统一协议，一次开发多处使用
能力发现	静态配置	动态协商
安全模型	应用层自定义	协议层内置权限控制
生态	各厂商独立	统一的 Server 生态

Function Calling 是”把工具描述塞进 prompt”的思路，MCP 是”建立标准化的工具服务”的思路。当 Agent 需要的工具从 3 个增长到 30 个，前者就撑不住了。

OpenAI Agents SDK 的演进

OpenAI 在 2025 年发布了 Agents SDK（Swarm 的正式版），内置了 MCP 支持：

import { Agent, run } from '@openai/agents';
import { MCPServerStdio } from '@openai/agents/mcp';

// 通过 MCP 连接外部工具
const mcpServer = new MCPServerStdio({
  command: 'npx',
  args: ['-y', '@modelcontextprotocol/server-filesystem', '/tmp'],
});

const agent = new Agent({
  name: 'file-assistant',
  instructions: '你是一个文件管理助手，可以读写文件。',
  mcpServers: [mcpServer],
});

// Agent 自动发现 MCP Server 提供的工具
const result = await run(agent, '在 /tmp 目录创建一个 hello.txt');

这比之前的 Function Calling 模式进步了很多。开发者不用再手动定义每个工具的 Schema，MCP Server 会自动暴露能力。

加入 AAIF 的技术动因

OpenAI 加入 AAIF，有几个具体的技术动因：

1. MCP 的事实标准地位不可逆

当 Cursor、VS Code、JetBrains、Xcode 都支持 MCP，当 500+ Server 实现覆盖了主流开发工具，OpenAI 再搞自己的工具协议就没有意义了。加入 AAIF，参与 MCP 标准的演进，比自己单干更务实。

2. A2A 协议的互补关系

Google 提出的 A2A 协议解决的是 Agent 之间的互操作，这和 OpenAI 的 Agents SDK 的多 Agent 编排能力有天然的契合：

// 理想的多 Agent 架构：MCP + A2A
const researchAgent = new Agent({
  name: 'researcher',
  tools: await mcp.connect(['web-search', 'knowledge-base']),
});

const codingAgent = new Agent({
  name: 'coder',
  tools: await mcp.connect(['github', 'filesystem']),
});

// 通过 A2A 协议协调多个 Agent
const orchestrator = new Agent({
  name: 'orchestrator',
  subAgents: [researchAgent, codingAgent],
  // A2A 自动处理 Agent 间的任务委托和结果收集
});

在 AAIF 的框架下，OpenAI 可以同时影响 MCP 和 A2A 两个协议的演进方向。

3. 企业市场的信任背书

企业客户最担心的是”厂商锁定”。当 OpenAI 的 Agent 技术栈基于 AAIF 治理下的开放协议，企业在采购决策时会少一层顾虑。

协议治理中的博弈

加入 AAIF 不代表 OpenAI 会放弃自己的技术路线。在协议委员会里，每个成员都在争取对自己有利的标准方向：

工具描述格式

OpenAI 的 Function Calling 用的是 JSON Schema 的超集，MCP 用的是更严格的 JSON Schema。两者在描述复杂参数类型时有差异。OpenAI 会在委员会里推动 MCP 支持更灵活的参数描述。

认证和授权

MCP 目前的认证模型相对简单。OpenAI 在企业级 API 管理方面有丰富经验，会推动 MCP 采用更完善的 OAuth 2.0 流程。

性能和延迟

对于实时 Agent 应用（如代码补全、对话助手），MCP 调用的延迟是关键指标。OpenAI 会推动协议层面的性能优化，比如批量调用、连接复用等。

开发者视角：这对你意味着什么？

短期影响

如果你已经在用 OpenAI 的 Agents SDK，加入 AAIF 不会改变现有的 API。SDK 会继续支持 Function Calling，同时 MCP 支持会更加完善。

中期影响

当 MCP 和 A2A 都在 AAIF 治理下，开发者可以放心地基于这些协议构建长期的技术栈。不用担心协议分裂或被某个厂商废弃。

长期影响

Agent 开发会越来越像 Web 开发：协议层标准化，框架层竞争。你选择 React 还是 Vue，不影响你的应用跑在 HTTP 上。同样，你选择 OpenAI Agents SDK 还是 LangChain，不影响你的 Agent 通过 MCP 调用工具。

冷思考

OpenAI 加入 AAIF 是务实的选择，但也有隐忧：

1. “拥抱、扩展、消灭”的阴影

微软当年对 Java、对 HTTP 都用过这招。OpenAI 会不会在 AAIF 的框架内推动对自己有利的标准，然后通过市场地位让竞争对手被动跟随？这需要 AAIF 的治理机制来制衡。

2. 开放治理的效率

20 个成员的委员会，要对协议演进达成共识，速度一定比单一公司慢。在 AI 这个快速迭代的领域，“慢慢来”可能意味着”错过窗口期”。

3. 技术标准 vs 市场选择

HTTP/2 标准委员会花了很多年制定规范，但最终是 CDN 厂商和浏览器厂商的实际部署推动了普及。AAIF 能制定标准，但标准能否被市场接受，取决于实际的技术价值。

总结

OpenAI 加入 AAIF，标志着 Agent 协议标准化进入新阶段。对开发者来说，最直接的好处是：不管用哪个 LLM，工具调用的协议是统一的。

但开放治理不是万能药。标准的质量取决于技术委员会的专业性，标准的生命力取决于市场的接受度。OpenAI 的加入增加了 AAIF 的分量，但最终结果还需要时间检验。

---

参考资料：

• OpenAI 对 AAIF 的说明
• Linux Foundation AAIF 公告