Agent 行业调研（一）

2024 到 2026 年间，Agent 从研究圈术语快速变成 AI 产业最密集的关键词之一。这个变化背后，并不只是市场叙事的升级，而是 AI 系统的目标发生了偏移：行业正在从“让模型回答问题”转向“让系统完成任务”。这个转向使得模型能力开始与工具调用、环境交互、长程规划和执行反馈耦合起来，Agent 因而成为一个系统问题，而不再只是一个 prompt 问题。#S1 #S2

如果说 ChatGPT 让大众第一次大规模体验到“模型会说话”，那么 Agent 热潮真正追问的是另一件事：当模型不仅会说，还能读网页、调 API、写文件、执行工作流、操作界面并在失败后修正策略时，它会变成什么。今天讨论 Agent，本质上是在讨论 AI 与环境之间的新关系。#O1 #M1

传统 autonomous agent 的经典定义可以追溯到 Franklin 与 Graesser：一个位于环境中、感知环境并持续行动、以实现自身议程的系统。LLM Agent 实际上延续了这一条线，只是把早期相对局部的策略函数换成了以大语言模型为核心的 reasoning、tool use 与 orchestration 机制。#S1

判断一个系统是否接近完整意义上的 Agent，可以看它是否同时具备目标驱动、环境交互、多步闭环、状态保持和失败纠偏等能力。如果系统只能单轮生成文本，即便背后模型很强，它也更接近对话助手，而不是 Agent。#S2

Chatbot 的核心是“对话”，它主要解决的是信息响应问题。Agent 的核心是“任务闭环”，它要决定接下来做什么、调用什么、是否执行成功、失败后怎样修正。这个差异决定了两者的评测方式也不同：chatbot 更关注回答质量，Agent 则更关注任务完成率、路径稳定性和环境适应能力。#S2

Copilot 更像“人主导、AI辅助”的副驾驶模式。它通常默认用户始终在环，AI 负责草拟、补全、建议和检索。Agent 则更进一步，它尝试自己推进步骤，并只在权限、歧义或风险节点把控制权交还给人。OpenAI 的 Agents SDK 文档和 Microsoft 的 Copilot Studio 路线都把这一点表现得很清楚。#O1 #M1

Workflow 与 RPA 的优势是预定义、稳定和可审计，它们像工业流水线。Agent 的优势是面对开放环境时具备更强弹性，但代价是更难验证、更难预测。两者长期不会互相取代，更可能是共存关系：规则明确的任务继续由 workflow 和 RPA 占主导，开放世界中的复杂任务则更多交给 Agent。#M1 #S2

Agent 并不是大模型时代才突然出现的新概念。在更早的 AI 研究中，强化学习体、规划系统、多智能体系统和仿真环境中的自主体都属于更大的 autonomous systems 家族。它们的共同限制在于：环境通常较封闭，状态空间可定义，但现实知识与开放世界泛化能力不足。#S1 #S4

大语言模型的出现改变了这个前提。LLM 第一次为 Agent 提供了一个足够通用的认知核心：它带来大规模世界知识、自然语言接口、复杂指令理解和初步多步推理能力，使研究者能够把一个“通用大脑”接入不同环境，而不必为每一类任务从头训练专门策略。#S1

随后，研究与工程界逐步把 Agent 拆解为更稳定的模块。根据 Wang 等人的统一框架，LLM-based Agent 常见的核心部件包括 profiling、memory、planning 和 action。也正是在这个阶段，Agent 才从一个 prompt 技巧演化为一个系统工程对象。#S1

要理解今天的 Agent 系统，不能只看它用了哪个模型，而要看整个技术栈。一个成熟的 Agent 至少包含以下八个核心模块，它们共同决定 Agent 能做什么、做到多稳、以及能在多大程度上被信任。#S1 #S2

LLM Backbone：认知核心，但不是 Agent 的全部

几乎所有现代 Agent 都把大语言模型作为认知核心。它负责理解用户意图、解析任务目标、选择下一步动作、生成工具调用参数、并根据环境反馈持续推理。LLM 的能力上限直接决定了 Agent 能理解多复杂的指令、能处理多长的任务链、能在多大程度上避免语义误解。#S1

但这里有一个关键区分：LLM 是 Agent 的大脑，不是 Agent 本身。一个只有 LLM 的系统，只能做到“理解并生成语言”；要让它真正完成任务，必须把它接到工具层、记忆层、运行时和执行环境中。这也是为什么 OpenAI 的 Agents SDK 文档把 agent 定义为“能够计划、调用工具、跨 specialist 协作、并保持足够状态以完成多步工作的应用”，而不仅仅是一个模型调用。#O1

从工程角度看，LLM Backbone 的核心挑战已经从“能不能理解”转向“能不能在长链路中保持稳定”。一个模型可能在单轮问答中表现优秀，但当它需要在 15 步任务中持续保持目标一致性、避免中途偏航时，问题就会暴露。评测综述指出，即便最先进的模型，在长程规划任务上的表现仍然显著落后于短程任务。#S2

Tool Use：从会说到会做的关键门槛

工具调用是 Agent 从封闭语言系统转向开放执行系统的分水岭。只要系统开始调用搜索引擎、数据库、shell、代码解释器、浏览器、文件系统、API 或企业 SaaS，它就不再是单纯的文本生成器，而开始真正作用于外部世界。#S2

工具调用的真正难度不只是“模型能不能输出函数调用格式”，而是一个四步连续判断链。第一步是判断当前是否需要工具：有些任务模型可以独立回答，有些则必须调用外部能力。第二步是选择正确的工具：当可用工具数量增加到几十甚至上百个时，选择本身就变成了一个检索和推理问题。第三步是构造正确的参数：这要求模型理解工具的 schema、约束条件和上下文依赖。第四步是正确利用返回结果：模型需要把工具输出整合进后续推理，而不是简单地把它拼接到上下文中。#S2

评测领域的一个重要趋势是，工具调用 benchmark 正在从单步、预定义参数的简单场景，向多轮、多工具、跨步骤依赖的真实场景演进。Scale 的 MCP Atlas 和 Tool-Decathlon 等新基准代表了这个方向。#S2

Anthropic 发布的 MCP 协议正在改变工具接入的底层结构。在 MCP 之前，每个数据源都需要定制集成；MCP 提供了一个通用的双向连接标准，让开发者可以“构建一次，到处连接”。这不只是技术便利，更是生态基础设施的变革。#A1

Planning：决定 Agent 能处理多复杂的任务

规划能力是 Agent 处理长链路任务的基础。一个典型的 Agent 任务可能包含十几个甚至几十个步骤，涉及多个工具调用、多次环境交互、以及中间状态的持续跟踪。Planning 模块的任务，就是把这些步骤组织成一个可执行、可修正的路径。#S1

Planning 的核心难点在于三个层面。第一是子任务分解：把一个模糊的高层目标拆成具体的可执行步骤，这本身就需要对任务结构有深入理解。第二是依赖管理：步骤之间往往存在顺序依赖、数据依赖和条件分支，错误的执行顺序会导致后续全部失败。第三是动态重规划：当某一步失败或环境发生变化时，Agent 需要能够回退、调整策略并重新规划后续路径，而不是机械地继续执行原计划。#S2

PlanBench 等专用 benchmark 的评测结果显示，即便是最先进的模型，在需要长程规划和复杂约束满足的任务上仍然表现不稳定。#S2 这说明规划能力很可能是当前 Agent 系统最被低估的瓶颈之一。很多 demo 看起来很强，是因为任务短、步骤少；一旦任务变长、依赖变复杂，Agent 的可靠性就会显著下降。

Memory：不只是把上下文窗口开大

Agent 的记忆机制不能简单等同于大模型的上下文窗口。上下文窗口解决的是“当前能看到多少信息”，而 Agent memory 解决的是“跨越步骤、跨越会话、跨越任务，它能记住什么”。#S2

研究界通常把 Agent 的记忆分为三类。第一类是 episodic memory，也就是过去发生了什么——Agent 在上一轮任务中做了什么、遇到了什么错误、得到了什么结果。第二类是 semantic memory，也就是长期知识——关于用户偏好、领域规则、组织结构的持久化信息。第三类是 procedural memory，也就是操作经验——某类任务应该怎么做、哪些工具组合更有效、哪些路径更容易失败。#S2

记忆机制的核心挑战是检索质量与长期一致性。当 Agent 积累了大量历史信息后，如何在每一步快速检索到最相关的内容，而不是被无关信息淹没，变成了一个关键问题。记忆机制的评测基准正在快速发展，但标准化程度仍然不足。#S2

Anthropic 的 Managed Agents 工程博客对记忆问题有一个重要的架构洞察：session log 应该独立于 agent harness 和 sandbox 存储，这样即便 harness 崩溃或 sandbox 重建，上下文也不会丢失。这种“可恢复上下文”的设计，是把 Agent 从一次性玩具变成可长期运行系统的关键。#A2

Reflection：让 Agent 学会自我修正

真实任务中，失败是默认状态而非异常。工具可能返回错误，网页可能加载失败，API 可能超时，用户的指令可能本身就有歧义。因此，Agent 必须具备某种形式的反思和自我修正能力：检查结果是否与目标一致、发现异常后重新检索、识别工具失败并换路、承认信息不足并请求人类确认。#S2

Reflection 是 Agent 与静态生成式模型的重要分水岭。模型生成一个答案就结束了；Agent 则需要在执行过程中不断校验与调整。OpenAI 在描述 Operator 时就明确提到它具备“self-correct”能力：当操作卡住时会回退并尝试其他方法，实在无法解决时才把控制权交还用户。#O3

但标准化的反思能力评测目前仍然不足。#S2 大多数 benchmark 评测的是任务最终成功率，很少系统性地测量 Agent 在中间失败后恢复的能力。这意味着我们对 Agent 的反思能力，目前更多是定性感知，而非定量评估。

Environment Grounding：真正把 Agent 接进世界

Agent 之所以难，不是因为文本推理有多难，而是因为它必须接触真实环境。这些环境可能包括浏览器、操作系统、文件系统、企业应用、API 网络、数据库、GUI 界面甚至物理设备。环境 grounding 决定 Agent 不是“在脑中模拟做事”，而是真正地在系统中推动任务发生。#S1 #M1

2025 年之后，browser use 和 computer use 成为最受关注的技术方向之一，原因很直接：现实世界中大量软件没有完备的 API，用户界面就是唯一的入口。Microsoft Copilot Studio 把 computer use 正式产品化，支持网站和桌面应用；Google 把 Project Mariner 的浏览器控制能力引入 Gemini API；OpenAI 的 Operator 和后续 ChatGPT Agent 路线也围绕浏览器和虚拟计算机展开。#M1 #G1 #G2 #O3

环境 grounding 的核心挑战是权限、安全和执行鲁棒性。Agent 需要读写文件、访问网络、操作界面，但这些操作都可能带来风险。如何在保持执行能力的同时控制风险边界，是所有 Agent 平台都在面对的核心设计问题。#M1 #A2

Runtime / Orchestration：Agent 的操作系统层

当 Agent 从 demo 进入生产环境，问题迅速从“模型能不能做”转向“系统能不能管”。Runtime 和 Orchestration 层负责的是：agent loop 的状态管理、多 agent 之间的 handoff、工具调用的审批与追踪、sandbox 的生命周期管理、以及异常恢复和超时控制。#O1 #M2

OpenAI 的 Agents SDK 把这一层拆成了多个明确模块：agent definitions、orchestration and handoffs、guardrails and human review、results and state、sandboxes、integrations and observability。这说明工程界已经认识到，Agent 不是一个 prompt 模板，而是一个需要完整运行时支撑的系统。#O1

Anthropic 的 Managed Agents 更进一步，用操作系统隐喻来描述这一层：session 是 append-only log，harness 是调用 Claude 并路由工具调用的循环，sandbox 是执行环境。这三者被明确解耦，各自可以独立失败和恢复。这种架构使得 Agent 系统具备了传统分布式系统的韧性特征。#A2

Microsoft 在 Build 2025 则从企业运维角度补了另一个关键维度：agent identity、access control、observability 和 governance。当一个组织内部有成百上千个 agent 在运行时，“agent sprawl”会成为真实的安全和管理风险，因此需要专门的身份和权限体系。#M2

Evaluation / Safety：决定 Agent 能否被信任

Agent 能力不是只看 benchmark 分数。企业真正关心的是：任务成功率、可预测性、失败恢复能力、延迟与成本、权限安全、审批与追踪。评测综述指出，Agent 评测正在从静态输出转向动态环境任务，同时把成本、安全、鲁棒性与长程任务成功率纳入更核心的位置。#S2

安全问题随着 Agent 能力的增强而迅速放大。当 Agent 能访问浏览器、文件系统、企业数据和凭据时，prompt injection、凭据泄露、越权操作、有害自动化等风险都会成为现实威胁。Microsoft Copilot Studio 的 computer use 文档把机器选择、凭据存储、人类监督和访问控制都列为一级配置项，正是在应对这些风险。#M1

Anthropic 的 Managed Agents 博客则从架构层面提出了一个关键原则：凭据永远不应该暴露给 sandbox 中运行的代码。Agent 通过专门的 proxy 调用外部服务，proxy 负责从 vault 获取凭据，agent 本身永远不接触 token。这种结构性的安全设计，比靠模型拒绝有害请求要可靠得多。#A2

在这套完整的技术栈里，LLM 只是认知核心，不是 Agent 的全部。真正决定 Agent 上限的，是它能否稳定地把推理、工具、记忆和运行时整合进一个多步闭环。OpenAI Agents SDK、Anthropic 的 Managed Agents、Google 的 Agent 平台和 Microsoft 的 Agent Service，本质上都在补这层能力。#O1 #A2 #G3 #M2

多模态 Agent 的出现几乎是必然的，因为真实环境从来不只是文本。网页包含图像与表单，操作系统包含 GUI，视频和音频则承载大量时序信息。Large Multimodal Agents 综述强调，多模态 Agent 的关键不只是“会看图”，而是能把多模态感知接入决策和行动闭环。#S3

多 Agent 则是一种横向扩张方案。单 Agent 在复杂任务中容易面临上下文压力、角色冲突和长链路不稳定，于是研究界开始通过角色分工、辩论、审校、集中编排与分布式协同来拆解复杂任务。多 Agent 的价值不在“人多”，而在结构化协作能否真正提高可靠性。#S4