The Current State of Agentic AI

代理AI的现状 - MachineLearningMastery.com

代理AI的现状

By

Vinod Chugani

on

2026年7月21日

in

Start Machine Learning

3

Share

Post

在本文中，你将了解截至2026年中期代理AI架构的演变过程，包括从编排推理循环的转变、多代理群体的兴起，以及通过MCP（Model Context Protocol）实现的工具协议标准化。

我们将涵盖的主题包括：

• 为什么原生推理模型使复杂的外部编排框架变得越来越冗余。
• 如何使用通过交接工具连接的无状态专业代理设计多代理群体。
• 模型上下文协议（MCP）、持久化记忆图和新兴安全模式如何定义当前的生产环境。

我们不再浪费时间。

引言

回顾一年前我们构建AI代理的方式，当时占主导地位的范式是暴力编排。工程师们花费大量时间手工构建复杂的ReAct（推理与行动）循环，与脆弱的提示链作斗争，并试图强迫单一的大型语言模型同时处理规划、工具执行和上下文管理。

如今，在2026年中期，生态系统已经分化并专业化。单一全能代理的时代正在消退。

我们现在使用原生推理模型、标准化工具协议和多代理架构（通常称为“群体”）。随着基础模型将“系统2”思维直接集成到其架构中，AI工程师的角色已从提示代理转变为设计专用代理通信的基础设施。

本教程将分解当前代理AI架构的状态，涵盖定义当今生产系统的三大转变，并逐步讲解如何设计现代代理群体。

1. 远离编排循环的转变

让我们从变化最显著的层次开始：代理的实际思考方式。

此前，在《机器学习实践者指南：代理AI系统》中，我们探讨了Plan-and-Execute（计划与执行）和Reflexion（反思）等模式。这些是外部循环，我们使用代码强制模型逐步思考、批评自身输出并重试。

如今，基础模型能够原生处理测试时计算。模型现在生成隐藏的推理标记，探索多个解决方案分支，并在向用户输出单个词之前进行自我纠正。我们之前构建的用于模拟反思的框架正在变得冗余。

这对你的架构意味着：你不再需要构建复杂的编排框架来让代理进行规划。如果你仍在使用LangChain或LlamaIndex强制模型反思自身错误，可能会增加延迟和令牌开销，而模型现在能更自然地处理这些任务。

编排层应专注于路由、状态管理和环境执行。代理的认知循环由模型处理；你的任务是构建它运行的沙盒环境。

随着认知负担的减轻，我们可以将工程精力投入到更有价值的地方：在多个专用代理之间分解任务。

2. 构建代理群体（多代理微服务）

既然模型现在自行处理推理，问题就变成了：单个代理应负责什么？生产团队得出的结论是：尽可能少。

...

如《Beyond Giant Models: Why AI Orchestration Is the New Architecture》中所论证的，将50个工具连接到单一大型模型会形成瓶颈。越来越多的生产团队已转向“智能代理群”（agentic swarms）——由多个小型、高度专业化的代理组成，这些代理通过标准化协议进行通信。

与其使用一个拥有50个工具的代理，不如采用以下结构：

• 分诊代理（Triage Agent）：理解用户意图并路由请求。
• SQL代理（SQL Agent）：仅了解数据库模式，只有一个工具：execute_query。
• Python代理（Python Agent）：在隔离容器中运行，处理数据转换。

你可能会疑惑，将单块代理拆分为多个小型代理是否只是转移了复杂性而非减少它。关键洞察在于：复杂性并未消失，但如今它变得可管理、可测试且可替换，这是前所未有的。

构建基础代理群模式

以下为示例伪代码。该代码无法直接运行，不存在swarm_framework包。实际实现请参考OpenAI Agents SDK或LangGraph Swarm：

from swarm_framework import Agent, Swarm, TransferCommand

# 定义分诊入口点
triage_agent = Agent(
    name="Triage",
    system_prompt="将请求路由到正确的专业代理。",
    tools=[transfer_to_sql, transfer_to_analyst]
)

# 定义专业代理
sql_agent = Agent(
    name="Data Fetcher",
    system_prompt="你编写并执行只读PostgreSQL查询。",
    tools=[execute_read_query]
)

analysis_agent = Agent(
    name="Data Analyst",
    system_prompt="你使用Python pandas分析数据集并生成洞察。",
    tools=[run_python_sandbox]
)

# 定义交接路由逻辑
def transfer_to_analyst(context_variables):
    """当原始数据已获取并需要分析时调用此函数。"""
    return TransferCommand(target_agent=analysis_agent, context=context_variables)

sql_agent.add_tool(transfer_to_analyst)

# 初始化并运行代理群
enterprise_swarm = Swarm(
    starting_agent=triage_agent,
    agents=[triage_agent, sql_agent, analysis_agent]
)

response = enterprise_swarm.run(
    user_input="我们的Q2流失率与支持工单数量之间有何关联？"
)

注意架构设计：每个代理在单次调用中都是无状态的，协调依赖于交接工具。当SQL代理完成数据获取后，会调用工具将控制权和数据上下文传递给Analyst代理。这种设计使上下文窗口保持精简，允许使用更便宜、更快的模型（如Qwen3或当前一代小型语言模型）处理单个节点，而将大模型保留用于路由和合成任务。

这种模式——每个代理无状态但系统层面保持状态——在考虑工具连接方式时变得更加重要。这正是标准化真正产生影响的领域。

3. 代理标准化：模型上下文协议

构建一个群体是一回事，将其连接到用户关心的真实世界系统是另一回事。直到最近，这种集成工作一直是任务中最繁琐的部分。

如《精通大语言模型工具调用：连接模型与现实世界的完整框架》所述，之前集成API需要编写自定义模式、处理HTTP请求，并应对模型产生的任意JSON解析错误。每次新集成都意味着要重复发明轮子。

当前工具调用的状态越来越由模型上下文协议（MCP）定义。这个开源标准充当AI模型与本地或远程数据源之间的通用适配器。

旧范式（2025年前）

当前状态（2026年中）

将API密钥硬编码到代理环境中

代理连接到独立的MCP服务器

工程师为每个工具编写自定义JSON模式

MCP服务器自动暴露可用工具和资源

代理直接内联执行API调用

执行在MCP服务器上进行，实现职责分离

这种标准化意味着你可以直接将预构建的GitHub MCP服务器、Slack MCP服务器和PostgreSQL MCP服务器插入到群体中，而无需编写底层API包装器。实际实现仍需要在服务器端进行谨慎的凭证管理，但集成接口的复杂度大大降低。

4. 通过记忆图实现持续学习

《自主AI：自助学习路线图》中最显著的承诺之一是代理能够从自身执行历史中学习。这种能力正通过记忆图进入生产环境，其工作机制值得清晰理解。

需要区分的是单次调用的无状态性和系统级记忆。单个代理在每次调用时保持无状态，以保持上下文窗口的精简。然而，系统通过像Neo4j这样的图数据库或直接注入代理上下文管道的托管替代方案，实现持久记忆。

当群体执行任务时，一个专门的记忆代理会在后台异步运行。它的唯一职责是评估主群体的轨迹，提取持久事实并更新图谱。

实际运作方式如下：

• 用户提问："将这段代码部署到预发布环境。"

• 群体执行失败：部署代理尝试使用过时的AWS CLI命令。它搜索内部文档，找到新命令后成功执行。

• 记忆代理运行：它观察到失败，提取出有效命令，并在知识图谱中添加节点：[预发布环境] -> [需要] -> [命令X]。

• 下次执行：分诊代理查询图谱，将更新后的事实纳入系统提示，完全绕过失败。

这标志着我们从提示工程转向了上下文工程。系统会随着时间的推移不断改进，无需对基础模型进行微调。

5. 安全性：蜂群攻击面

通过通用协议连接的多智能体系统，攻击面已大幅扩大。在《面对AI劫持威胁》一文中，我曾警告过间接提示注入可能劫持自动化工作流的风险。如今这一威胁已成为企业采用智能体系统的主要顾虑，而蜂群架构在结构上比单体模型时代更具危险性。

原因如下：当智能体A（负责读取外部邮件）能够将上下文和控制权转移给智能体B（拥有数据库访问权限）时，嵌入在邮件中的恶意指令可通过蜂群横向扩散，复现传统网络入侵模式。使蜂群具备价值的交接机制，也正是其脆弱性的来源。

针对这一问题，三种新兴防御手段正在形成合力：

• 加密工具来源证明：工具需经过签名，智能体仅在确认请求源自已验证的内部状态（而非外部数据）时，才会执行工具调用。
• 语义防火墙：在蜂群智能体间部署轻量级快速模型，分析交接负载中的恶意指令，仅在确认安全后允许传输。
• 临时沙箱：智能体在单次使用的WebAssembly（Wasm）容器或微虚拟机中执行代码，每个任务完成后容器即被销毁。

这些方案尚未形成统一标准，但已构成当前智能体安全领域的前沿实践。任何今天将蜂群系统投入生产的团队，都应至少将其中一项方案作为基准要求。

前进方向

智能体AI已从研究奇观演变为具有真实约束条件的工程学科，每个层级都面临真实失效模式和真实设计决策。

基础原语——工具调用、路由和原生推理能力——正在快速成熟。剩余的优化空间在于系统层级：如何设计蜂群拓扑结构、如何构建记忆架构使系统随时间积累知识、以及如何划定安全边界以实现规模化安全运行。

当前领先团队的建设重点并非追求更聪明的单体智能体，而是构建更具韧性和专业性的蜂群系统。如果你正从零开始，可选择此处提到的某种模式，先在小规模实施并仔细监控。从三智能体蜂群中获得的架构直觉，可直接迁移至三十智能体规模的系统。

更多相关内容

• 如何为LSTM时间序列建模初始化状态…
• 使用LangGraph在Python中构建智能体工作流
• 智能体AI安全：防御提示注入攻击…
• 智能体AI系统中的上下文工程与记忆工程
• 智能体工作流与自主智能体：有何区别…
• 智能体编程：路线图