PHP 的 AI Agent 生态系统！从简单的 OpenAI 调用到多 Agent 平台

过去两年里，PHP 生态系统中围绕 AI 开发已经形成了一个完整的产业。

曾经，将 LLM 集成到项目中只是调用 OpenAI API 的几行代码；而如今，开发者正在构建功能完备的 Agent 系统：具备记忆、工具、工作流、可观测性，甚至是专业化 Agent 团队。

通常，当人们谈论 AI 开发时，首先想到的是 Python。这是有道理的——Python 生态中有 LangChain、LangGraph、CrewAI、AutoGen 等大量精彩项目，长期以来 excitement 主要集中在那里。

但与此同时，PHP 中也正在发生一个有趣的故事。这让我由衷地感到高兴。

就在几年前，PHP 开发者还必须在各个提供商的 SDK 之上手动拼凑一切。而如今，已经出现了一套完整的工具生态，从模型客户端一直到管理多 Agent 系统的平台，覆盖不同抽象层次。

让我们来看看当前的格局。

从单个模型请求到完整 Agent

历史上，一切都是从相同的方式开始的。几乎每个 AI 项目最初都是这样：

$response = $client->chat()->create([
    'model' => 'gpt-5',
    'messages' => [
        [
            'role' => 'user',
            'content' => 'Analyze the customer request'
        ]
    ]
]);

对于原型来说，这已经足够了。

但一旦系统开始产生真正的业务价值，就会出现更多需求：

• 支持多种模型
• 快速切换提供商
• 结构化输出
• 外部工具调用
• 记忆管理
• 上下文管理
• 请求追踪
• 多步处理编排

这时你会发现，围绕 LLM 的代码已经比业务逻辑本身占用了更多的空间。

这正是 PHP 中专业 AI 库开始出现的原因。

如果简化来看，现代生态可以分为三个层次：

• AI SDK
• Agent 框架
• Agent 平台

每一层都承担了更多的基础设施工作。

现代 PHP AI 开发生态大致可分为三个层次：SDK 解决模型交互问题，框架帮助构建 Agent，平台则管理整个 Agent 基础设施。

第一层：AI SDK

这是基础。AI SDK 只解决一个问题：方便地与模型交互。它们并不尝试管理 Agent 或编排工作流。它们的职责止于发送请求和接收响应。

OpenAI PHP

仓库：https://github.com/openai-php/client 状态： 活跃

OpenAI 官方的 PHP 客户端。

本质上，这是与 OpenAI 平台交互最直接的方式，没有额外抽象——一个低级 SDK。

它提供以下功能：

• Responses API
• Chat Completions
• Embeddings
• Audio API
• Image Generation
• Fine-Tuning
• Files API

典型用法非常直接：

$response = $client->responses()->create([
    'model' => 'gpt-5',
    'input' => 'Create a short summary of the customer request'
]);

echo $response->outputText;

这种方式的优势显而易见：完全控制。

缺点也同样明显——一旦需要支持多种模型或提供商，就必须自己构建所有必要的抽象。

Prism

仓库：https://github.com/prism-php/prism 状态： 活跃

OpenAI PHP 专注于单一平台，而 Prism 的目标不同：为多个提供商提供统一接口。

这是一个多提供商 AI SDK。

理念很简单：业务逻辑不应依赖于特定模型。

今天用 GPT，明天用 Claude，下个月用 Gemini——应用不应该感受到差异。

示例：

Prism::text()
    ->using('openai', 'gpt-5')
    ->withPrompt('Hello')
    ->generate();

切换模型只需一行代码：

Prism::text()
    ->using('anthropic', 'claude')
    ->withPrompt('Hello')
    ->generate();

Prism 的额外能力使其特别实用。

结构化输出

无需解析自由文本，可以提前定义期望的输出结构。

例如：

class SentimentResult
{
    public string $sentiment;
    public int $score;
}

模型会严格按照定义的格式返回数据。

对于生产系统，这比用正则表达式解析生成文本可靠得多。

工具调用

Prism 支持工具调用（Tool Calling）。

也就是说，模型可以自主决定何时需要查询 CRM、数据库或外部 API。

这正是从“聊天机器人”转向“Agent”的起点。

Embeddings

几乎每个现代 RAG 项目最终都会用到 Embeddings。

Prism 允许通过统一接口生成 Embeddings，无论选择哪个提供商。

Laravel AI

仓库：https://github.com/laravel/ai 状态： 活跃

这是最近几个月出现的最有趣的项目之一。

Laravel AI 试图为人工智能做 Laravel 曾经为数据库、队列和基础设施所做的事。

核心思想不是模型支持，而是让 AI 成为 Laravel 应用的自然组成部分。

代码感觉非常熟悉：

$response = AI::chat()
    ->model('gpt-5')
    ->prompt('Create a short summary of the customer request')
    ->send();

但真正的价值更深入。

Laravel AI 能自动与以下集成：

• 队列
• 事件
• 服务容器
• 日志
• 配置
• 调度器

结果是，LLM 感觉就像另一个基础设施依赖——和 Redis 或 PostgreSQL 处于同一级别。

第二层：Agent 框架

从这里开始，事情变得真正有趣起来。因为一个模型请求还不是 Agent。

想象一个客服系统。收到一条消息：

我已经第三次联系你们关于退款的问题了。没有人回复。

接下来会发生什么？实际系统中通常需要：

• 判断情感
• 评估紧急程度
• 获取客户信息
• 检查支持历史
• 准备回复
• 保存结果
• 记录所有操作

你可以手动编写几十个服务。或者使用 Agent 框架。

在实际系统中，Agent 很少单独工作。通常会出现一个协调器，将任务分配给专业 Agent，然后将它们的结果组合成单一响应。

Neuron AI

仓库：https://github.com/neuron-core/neuron-ai 状态： 活跃

这是目前 PHP 中最成熟的 Agent 框架之一。其方法完全不同。开发者不是描述一个请求，而是描述一个 Agent：

$agent = Agent::make()
    ->name('SupportAgent')
    ->instructions('You are a customer support specialist');

然后让 Agent 执行任务：

$result = $agent->run(
    'Analyze the customer email'
);

表面上看很简单。但底层会出现完整的基础设施：

• 记忆
• 工作流
• 工具
• RAG
• 多 Agent 系统
• 可观测性
• 等等

从哲学上讲，该项目与 Python 世界的 LangGraph 非常相似。

为什么记忆变得至关重要

传统 LLM 的工作方式是：

请求 → 响应

Agent 的工作方式则是：

请求
  ↓
记忆
  ↓
工具
  ↓
LLM
  ↓
结果

记忆让 Agent 能够考虑先前的操作和积累的上下文。没有它，长期业务流程是不可能的。

多 Agent 系统

最近几个月的另一个趋势是放弃通用 Agent。

越来越多的团队采用专业化角色：

协调器
   |
   +-- CRM Agent
   |
   +-- 情感分析 Agent
   |
   +-- 回复 Agent

这种方法非常类似于真实团队的结构。每个 Agent 负责自己的领域。

LarAgent

仓库：https://github.com/maestroerror/laragent 状态： 活跃

如果说 Neuron AI 旨在成为通用 Agent 框架，那么 LarAgent 则主要面向 Laravel 开发者。

你能立刻感受到 Laravel 熟悉的哲学：

class SupportAgent extends Agent
{
    protected string $instructions =
        'You are a support specialist';
}

基础设施代码最少，Laravel 集成度最高。

对许多团队来说，这可能是开始使用 Agent 最快的方式。

PapiAI

仓库：https://github.com/papi-ai/papi-core 状态： 活跃

这是一个相对年轻的项目，强调强类型和提供商独立性。从架构上看，PapiAI 试图将现代 PHP 开发实践带入 AI 领域。其重点包括：

• 类型
• 契约
• 中间件
• 工具
• 结构化响应

看到 AI 工具逐渐继承传统 PHP 框架的架构原则，是一件很有趣的事。

Atlas

仓库：https://github.com/atlas-php/atlas 状态： 活跃

另一个新一代 Agent 解决方案。该项目基于现代需求构建：

• 语音接口
• 多模态
• Agent
• 工具
• 追踪
• 监控

Atlas 还不能称为成熟的市场玩家，但它清楚地展示了生态系统的发展方向。

第三层：Agent 平台

当规模达到一定程度时，会出现新的问题。挑战不再是构建单个 Agent，而是管理数十个 Agent。会出现以下问题：

• 谁负责任务路由？
• 如何追踪响应质量？
• 如何测试变更？
• 如何管理记忆？
• 如何理解失败的根本原因？

这就是 Agent 平台发挥作用的地方。

PromptlyAgent

仓库：https://github.com/promptlyagentai/promptlyagent 状态： 活跃

该项目专注于构建复杂的 Agent 生态系统。其主要重点是：

• 可视化编排
• 多 Agent 工作流
• 工具集成
• Agent 管理

本质上，它代表着从编程单个组件转向管理整个 AI 基础设施的转变。

Vizra ADK

仓库：https://github.com/vizra-ai/vizra-adk 状态： 活跃

来自 Laravel 生态的另一个有趣项目。

它几乎覆盖了整个 Agent 生命周期：

• 开发
• 测试
• 记忆
• 工作流
• 可观测性
• 子 Agent 交互

从行业趋势来看，此类解决方案正逐渐成为下一层抽象。

市场的发展方向

有趣的是，PHP 现在几乎完全遵循了 Python 几年前走过的道路。

演进路径如下：

几乎每个 AI 项目都会经历相似的演化。从简单的模型调用开始，然后添加工具和结构化输出，最终成长为相互交互的 Agent 网络。

每个人都从简单的模型请求开始。

Prism::text()
    ->using('anthropic', 'claude')
    ->withPrompt('你好')
    ->generate();

然后是工具。

然后是记忆。

然后是工作流。

之后，专业化 Agent 就不可避免了。

最终会意识到，所有这些基础设施都需要被妥善管理。

这就是为什么编排和 Agent 管理平台目前的发展速度快于 SDK 本身。

总结

几年前，关于 PHP 中 AI 的讨论通常止步于“应该用哪个 HTTP 客户端调用 OpenAI”。

如今，情况已经完全不同。

生态系统中已经包含了几乎所有复杂度级别的解决方案：

• 模型交互：OpenAI PHP、Prism
• 深度 Laravel 集成：Laravel AI
• 构建 Agent：Neuron AI、LarAgent、PapiAI、Atlas
• 管理复杂 Agent 系统：PromptlyAgent、Vizra ADK

而这似乎只是开始。如果说开发者曾经设计 API、服务和队列，那么未来几年，他们将越来越多地设计 Agent、它们的记忆、工具以及它们之间的交互方式。

已经越来越清楚：单个模型调用正在逐渐成为新的“函数”，而 Agent 正在成为新的“服务”。

因此，了解 PHP AI 生态系统的能力，正在成为任何计划构建下一代 AI 产品的后端工程师的必备技能。