Agent系列教程01-什么是Agent？当今为什么这么重要？

理解 AI Agent 的演变、架构和未来

Agent（智能体）是一个能够基于数据自主完成任务或做出决策的程序。它与 AI模型对话，以使用工具和资源执行基于目标的操作。

传统 AI 模型和 Agent 之间的区别是微妙但意义深远的。当我们与 AI 模型（例如 Gemini、o1、Sonnet 或类似的大型语言模型）交互时，本质上是在进行一系列一次性的互动：我们提供输入，模型处理输入，然后返回输出。虽然这些互动可能很复杂，但它们从根本上来说是被动的、无状态的。每个响应都孤立存在，没有真正的连续性，也无法采取独立行动。

相比之下，AI Agent 是自主系统，旨在感知环境、做出决策并采取行动以实现特定目标 —— 所有这些都同时保持上下文，并根据结果调整其方法。

这听起来可能只是一个细微的区别，但它代表了 AI 系统运作方式和它们能够实现的目标的根本性转变。

想想我们今天有多少人使用 AI聊天界面。你可能会要求 ChatGPT 从头到尾写一篇文章，并得到一个一次性的回应。你可能需要自己做一些工作来迭代它。而 Agent 版本则更加细致入微 —— Agent 可能会先写一个大纲，然后确定是否需要研究，接着撰写草稿，评估是否需要修改并自行修订。 让我们看一些 Agent 在实际应用中的例子。

当你要求 AI 模型帮助你分析一些数据时，它可以提出方法甚至编写代码，但它实际上无法执行该代码或直接与你的数据交互。另一方面，AI Agent可以主动处理你的数据：加载文件、运行分析、生成可视化效果，甚至可以根据结果建议和实施改进。

在 Agent 对 Agent 的工作流程中，这种能力变得更加强大。考虑一个多个 Agent 协作的数据分析项目：一个数据准备 Agent 可能会清理和标准化你的原始数据，然后将其传递给分析 Agent，后者应用统计方法并识别模式。然后，这个 Agent 可能会与可视化 Agent 协作，以创建引人注目的调查结果展示，同时文档 Agent 记录方法和结果。最后，一个审查 Agent 可能会验证整个工作流程，并提出改进或额外分析的建议。

在这个工作流程中，每个 Agent 都保持着自己的上下文和专业知识，同时通过结构化的协议与其他 Agent 协调。

它们可以动态地处理边缘情况 —— 例如，如果分析 Agent 发现数据质量问题，它可以要求准备 Agent 进行特定的清理，或者如果可视化 Agent 识别出有趣的模式，它可以建议进行额外的分析以进一步探索。这不再仅仅是拥有一个可以提供建议的顾问与拥有一个可以帮助完成工作的同事之间的区别 —— 这就像拥有一个由专家组成的完整团队，代表你无缝地协同工作。

回到一次性 Prompt 与 Agent 的对比：当我们谈论用于代码生成的 AI 时，我们大多数人已经习惯了“Prompt 和响应”的方法。你给 AI 一个 Prompt，例如“为我编写代码 X”，它会返回一些代码作为响应。

Agent 采取的方法更加细致入微。它可以规划逻辑、检查代码、运行测试、检测错误，然后在出现问题时重新思考并修复它们。这种迭代过程模仿了工程师解决问题的方式，并且能够交付更好的结果。AI 变成了一个协作者，而不仅仅是纯粹的输出生成器。

这种自主性和采取行动的能力使 Agent 从最复杂的语言模型中脱颖而出。这种转变使得“长尾”任务的自动化成为可能，而这些任务以前不值得构建传统的自动化系统 —— 从跨多个系统组织文件，到监控数据源以查找特定模式，再到协调跨多个应用程序的复杂工作流程，一切皆有可能。

为什么我个人对 Agent 感到兴奋？

• 它们具有弹性能力来处理组织以前无力解决的工作 —— 而不是取代现有系统或人员。
• Agent 将范式从软件作为工具转变为软件作为工作者。这可能是企业与其技术堆栈之间一种全新的关系。
• Agent 可能会使软件价值与最终用户数量脱钩。你不再受限于你的团队能够完成多少工作。
• Agent 的用例，例如“深度研究”和 Agent 驱动的编码，已经为我节省了_大量_时间。这让我能够抽出时间专注于 AI 无法做到的事情。

AI Agent 互操作性的标准化协议的出现

AI Agent 自主和协作运行的能力，需要开发和采用标准化的通信协议，以确保无缝的互操作性，并创建复杂的多 Agent 系统。 缺乏此类标准可能会导致生态系统的碎片化，阻碍复杂任务自动化和跨平台协作的潜力。 在这方面，有两个值得关注的关键进展。

• 模型上下文协议 (MCP): 由 Anthropic 推出，MCP 是一种开放标准，旨在将 AI 模型连接到外部工具和数据源（它是“用于 AI 集成的 USB-C”）。 它使 AI 助手能够直接访问各种数据集并与之交互，从而增强其信息检索和任务执行能力。 例如，MCP允许 AI 助手直接连接到 GitHub 等平台，以高效地创建存储库和管理 Pull Request。 欲了解更多关于 MCP 的信息以及大量的实际示例，请参阅 MCP：它是什么以及为什么重要。
• Agent2Agent 协议 (A2A): Google 最近宣布推出的 A2A是一种开放标准，旨在促进来自不同供应商和框架的 AI Agent 之间的无缝通信和协作。 它允许 Agent 在各种企业平台之间安全地交换信息和协调行动，从而促进互操作性和增强的自动化。

以下是通过 Google 的 Agentspace 运行的 A2A 示例：

为了简化理解：MCP 将 Agent 连接到工具（可以理解为 Agent 到 API 的连接），而 A2A 则使 Agent 能够与其他 Agent 对话。

超越简单自动化：理解 Agent 的能力

AI Agent 的能力远远超出简单的自动化脚本或聊天机器人。它们可以：

1. 在多次交互中保持持久的上下文和记忆，使其能够从经验中学习并随着时间的推移调整其方法。
2. 使用工具并与外部系统交互，无论是通过 API、Web 浏览器还是直接的系统交互。
3. 将复杂的目标分解为可管理的子任务，并以逻辑顺序执行它们。
4. 监控自身的进度 并根据结果调整策略。
5. 与其他 Agent 协作，每个 Agent 专注于大型任务的不同方面。

这些能力的结合使 Agent 能够处理复杂的、多步骤的任务，而这些任务对于传统的 AI 系统来说是困难或不可能完成的。

这种程度的自主性和持续的、目标导向的行动能力代表了 AI 系统在协助处理复杂任务方面的一个根本性进步。

Agent Recipes 是一个学习 Agent/工作流方案的网站，其中包含代码示例，你可以轻松地复制粘贴到你自己的 AI 应用程序中。

Agent模式和架构：自主系统的构建模块

AI Agent 的出现催生了几种不同的架构模式，每种模式都解决了自主决策和行动挑战的不同方面。理解这些模式对于理解 Agent 系统当前的能力和局限性，以及它们未来的潜在演变至关重要。

工具的使用和集成

Agent 架构中最基本的模式是工具的使用 —— 即与外部系统和 API 交互以完成任务的能力。 这关乎理解何时以及如何有效地使用不同的工具。 现代 Agent 可以与从数据库系统到开发环境的一切事物进行交互，但特别有趣的是它们如何选择使用哪些工具以及何时使用。

例如，当 Agent 的任务是分析销售数据时，它可能需要：

• 使用文件系统 API 访问原始数据
• 使用数据处理库进行分析
• 利用可视化工具创建报告
• 使用通信 API 共享结果

其复杂性不在于单独的工具交互，而在于 Agent 将这些工具连贯地朝着目标进行编排的能力。 这反映了人类的认知过程 —— 我们不仅知道如何使用工具，还理解何时使用哪种工具是合适的，以及如何有效地组合它们。

记忆和上下文管理

也许 Agent 系统中最重大的架构挑战是管理记忆和上下文。 与无状态的 LLM 交互不同，Agent 需要随着时间的推移保持对其环境和先前行为的理解。 这催生了几种创新的方法：

1. 情节记忆（Episodic Memory）：Agent 维护过去交互及其结果的记录，使其能够从经验中学习并避免重复错误。 这不仅仅是存储对话历史；而是提取和组织相关信息以供将来使用。
2. 工作记忆（Working Memory）：类似于人类的短期记忆，这使得 Agent 能够保持关于其当前任务和最近操作的上下文。 这对于在复杂的、多步骤操作中保持连贯性至关重要。
3. 语义记忆（Semantic Memory）：长期存储 Agent 随着时间推移学习到的事实、模式和关系。 这有助于为未来的决策和策略提供信息。

分层规划和执行

在 Agent 架构中出现的最复杂的模式之一是分层规划。 这种方法将复杂的目标分解为可管理的子任务，从而在 Agent 系统内部创建类似于认知层次结构的东西。 这模仿了人类专家处理复杂问题的方式 —— 将它们分解成更小、更易于管理的部分。

该层次结构通常包括：

1. 战略规划（Strategic planning）：高层次的目标设定和策略制定
2. 战术规划（Tactical planning）：将战略分解为具体的、可操作的任务
3. 执行规划（Execution planning）：确定每个任务所需的具体步骤

4.行动执行（Action execution）：执行计划的步骤并监控结果

这使得 Agent 能够管理扁平式架构难以应对的复杂性。 例如，一个任务是“提高我们网站的性能”的 Agent 可能会：

• 在战略层面：决定专注于加载时间和用户体验
• 在战术层面：计划优化 JavaScript/长任务、压缩图像并改善服务器响应时间
• 在执行层面：详细说明每个优化的具体步骤
• 在行动层面：实际实施更改并衡量结果

多 Agent 系统和协作

也许在 Agent 架构中出现的最有趣的模式是多 Agent系统的发展。 这些系统将认知负荷分布在多个专门的 Agent 之间，每个 Agent 处理复杂任务的不同方面。 这种模式的出现是解决单 Agent 系统局限性的自然解决方案，就像人类组织通过专业化和协作来处理复杂任务一样。

微软的 AutoGen 和开源的 CrewAI框架是这种方法的例证，它们允许开发人员创建 Agent 团队，共同处理复杂的任务。 一个典型的多 Agent 系统可能包括：

• 一个协调 Agent，负责管理整体任务流程和委派
• 具有特定领域深入知识的专家 Agent
• 审查和验证工作的评论 Agent
• 处理其他 Agent 和外部系统之间通信的集成 Agent

这种方法的力量在于它能够将复杂的认知任务分解为可管理的部分，同时通过结构化的通信和协作协议保持连贯性。 例如，在软件开发环境中，你可能会有：

• 一个需求 Agent，负责与利益相关者沟通并维护项目目标
• 一个设计 Agent，负责创建技术规范
• 多个开发 Agent，负责处理不同的组件
• 测试 Agent，负责验证功能
• 文档 Agent，负责维护技术文档

图为 CrewAI，它允许你创建和管理 Agent 团队。

这些 Agent 之间的交互不仅仅是传递消息的问题；它涉及到用于协商、共识建立和冲突解决的复杂协议。 这反映了人类的组织结构，但具有完美的信息共享和一致执行既定协议的优势。

AI Agent 堆栈 分为三个关键层：Agent 托管/服务、Agent 框架以及 LLM 模型和存储。

浏览器Agent 生态系统：连接 AI 和 Web

浏览器端 AI Agent 的兴起（依我看来）是 Agent 生态系统中最重大的发展之一。 这些 Agent 可以像人类一样与 Web 界面交互 —— 导航页面、填写表单、提取信息以及执行复杂的工作流程。 这种能力从根本上改变了 Web 自动化和交互的格局，开辟了以前不切实际或不可能实现的可能性。

当前的格局

当前的浏览器 Agent 生态系统分为几种不同的方法，每种方法都有其自身的优势和权衡：

专有解决方案

谷歌的 Project Mariner 代表了频谱的一端 —— 一种紧密集成的解决方案，构建于 Chrome 之上，并由 Gemini 提供支持。 虽然仍处于实验阶段，但它展示了浏览器 Agent 成为我们 Web 体验原生组成部分的潜力。 我很幸运有机会与 Mariner 合作，将他们的愿景变为现实。

OpenAI 的 Operator 采取了不同的方法，专注于通过名为计算机使用 Agent (Computer-Using Agent, CUA) 的模型进行通用 Web 交互。 它尤其以其先进的视觉和推理能力而著称，使其能够理解和与复杂的 Web 界面交互。 与 GPT-4 的集成提供了复杂的决策能力，使其能够处理复杂的任务，例如预订旅行安排或管理电子商务交易。

视频：Rowan Cheung

开源替代方案

在频谱的另一端，像 Browser Use 和 Browserbase 的 Open Operator 这样的项目正在普及浏览器自动化能力。

Browser Use 是一个开源项目，旨在使 AI Agent 能够直接与 Web 浏览器交互，从而促进基于 Web 的复杂任务的自动化。 通过利用此工具，AI 模型可以通过用户友好的界面自主导航网站、执行数据提取和执行各种 Web 操作。 它可以识别 Web 元素并与之交互，而无需手动配置，并且与各种大型语言模型 (LLM) 兼容。

演示：“阅读我的简历并查找机器学习职位，将它们保存到一个文件中，然后在新标签页中开始申请，如果需要帮助，请告诉我。”

Browser Use 背后的团队现在也推出了 基于云的版本。

Browserbase 的 Open Operator 是一种开源工具，旨在通过自然语言命令自动化 Web 任务。 通过解释用户指令，它在无头浏览器环境中执行操作，从而简化了复杂的 Web 交互。 Open Operator 利用了 Browserbase 的云基础设施。

Skyvern 利用大型语言模型 (LLM) 和计算机视觉来自动化基于浏览器的工作流程。它能够适应各种网页，并通过简单的自然语言命令执行复杂的任务。他们一直在探索如何将更多第三方集成无缝地整合到代理工作流程中。

这些开源解决方案具有以下几个优点：

1. 透明度：用户可以检查和修改代码，准确了解代理如何做出决策
2. 定制：组织可以根据自己的特定需求调整工具
3. 成本控制：不依赖专有 API 定价
4. 社区发展：通过社区贡献快速迭代和改进

Browserbase 生态系统尤其因其 Stagehand 框架而备受关注，该框架为构建自定义浏览器代理提供了坚实的基础。它允许开发人员创建复杂的自动化工作流程，同时保持对整个堆栈的控制。

超越简单的自动化

浏览器代理（Browser Agents）真正让人兴奋的地方，是它们能做的不只是传统的网页自动化。正如 Aaron Levie 所说：

“AI 代理可以启动无限个云浏览器，它们不是用来做那些我们已经用 API 搞定得很好的事情的，而是去完成那些我们以前没空写 API 去处理的长尾任务。”

这句话说到了浏览器代理的核心价值。举几个例子就明白了：

复杂的研究任务： 代理可以自己浏览多个网站，交叉对比信息，提取相关数据，还能记住上下文，最后把结果整合成一份结构清晰的报告。整个过程完全不依赖什么特定的 API 或系统对接。

用户界面测试（UI 测试）： 代理可以系统地探索一个 Web 应用，发现使用上的问题，测试各种极端情况，还能记录 bug 和不一致的地方。关键是它理解“用户体验”是什么，而不是只机械地跑测试脚本。

内容管理： 代理能同时监控多个网站有没有变化，自动在各个平台上更新内容，确保品牌和信息保持一致。这些本来需要人力不停盯着改的琐碎事，它全搞定了。

我个人最喜欢的用法之一就是“深度研究”（Deep Research）。OpenAI 的深度研究工具用起来很不错，Google 的现在也变得特别强大，推荐试试。

技术实现与挑战

实现浏览器代理并不简单，里面有不少独特的技术难点：

视觉理解： 代理要能看懂复杂的网页布局，理解页面上的各种按钮、输入框、菜单等，这不仅需要强大的计算机视觉能力，还得结合对网页语义的理解。

状态管理： 很多网页应用的状态非常复杂，内容是动态变化的。代理必须能跟踪这些状态变化，并搞清楚自己的每一步操作会带来什么影响。

错误处理： 网页本身就很不稳定，有时候按钮会变位置、突然消失，或者在不同情况下行为不一样。代理得有健壮的错误处理机制，遇到问题要能自我恢复，继续执行任务。

安全问题： 让代理自动操作网页，就必须处理账号、密码、敏感数据等，这就带来了不少安全挑战，尤其是凭证管理和隐私保护这块，需要非常谨慎。

经济与战略影响

浏览器代理的出现，对我们理解“网页应用”和“服务”的方式带来了重大变化。正如 Levie 说的：

“之前做这些事太麻烦了，到头来很多人还是选择手动完成。现在，你只要花几块钱，就可以快速试试一个流程能不能跑通，然后再决定要不要大规模上线。”

这种新的现实，可能会让我们重新思考以下几个方面：

API 的发展方向： 公司可能会更倾向于优先做“人能用”的网页界面，而不是先开发 API。 “API 优先”的开发模式，在某些场景下可能会让位于“浏览器优先”。 新的集成方式也可能出现，比如让代理直接与网页交互来实现整合。

服务设计： 网页界面未来可能会向“更适合代理使用”演进，同时又不牺牲人类用户体验。 说不定以后会有一套标准专门用来规范“代理怎么跟网页交互”。 服务提供商也可能会单独为代理开放特别的交互接口。

成本结构的变化： 自动化的成本模型可能会彻底改变。 按“代理使用量”计费的全新商业模式可能会出现。 很多过去“不值得自动化”的任务，现在可能因为代理而变得划算。

总之，浏览器代理不仅是技术升级，它还可能重塑整个网络服务的运作方式。

现实世界中的应用和影响

人工智能（AI）代理从理论构想到实际工具的过渡已经开始，多个领域中都出现了相关应用。虽然我们很容易被技术的潜力所吸引，但同样重要的是要批判性地审视当前的实现方式，理解它们的成功之处和局限性。

软件开发与工程

AI代理在软件开发中的影响，或许是最能体现其当前能力和局限性的领域。我们可能会看到，从简单的代码补全到“AI团队成员”，它们可以在整个开发生命周期中参与进来。

当前的应用实例：

代码生成与审查：

• AI代理现在能够根据自然语言描述生成完整的组件或服务。
• 它们可以审查拉取请求，识别潜在问题并提出改进建议。
• 更复杂的代理能够跨多个文件保持上下文，理解项目特定的规范。

测试与质量保证：

• 基于代码变更自动生成测试。
• 通过浏览器交互进行UI测试。
• 性能分析和优化建议。

文档和维护：

• 根据代码变更自动更新文档。
• API文档生成与维护。
• 根据使用模式提出代码重构建议。

特别值得注意的是，这些应用已经超越了简单的自动化。例如，AI代理可能会注意到开发人员如何处理某些边缘情况，并主动建议在整个代码库中统一处理方式。这种级别的上下文意识和主动帮助，代表着比传统开发工具更大的进步。

企业自动化与业务流程

在企业环境中，AI代理开始处理那些传统方法无法经济有效解决的“长尾”自动化任务。

当前应用实例：

文件管理：

• 自动化跨多个系统的文件组织。
• 内容分类与标签。
• 元数据管理与更新。
• 跨平台内容同步。

客户服务：

• 多步骤问题解决。
• 主动识别问题。
• 跨系统信息收集。
• 上下文响应生成。

工作流自动化：

• 复杂的审批流程。
• 多系统数据对账。
• 合规监控与报告。
• 资源分配与调度。

与传统自动化的关键区别在于，AI代理能够处理例外和边缘情况。例如，在组织文件时，代理能够识别同一实体在不同系统中使用不同名称时，并做出智能的分类决策。

挑战与局限：现实检验

虽然AI代理的潜力巨大，但理解它们当前的局限性和挑战同样至关重要。这不仅仅是技术上的问题，更是技术要实现其全部潜力之前必须解决的根本问题。

技术挑战

可靠性与一致性

AI代理面临的最紧迫挑战是可靠性。

与遵循确定性规则的传统软件不同，代理在面对新情况时可能会表现出不可预测的行为，具体表现为：

• 幻觉与错误自信：
  • 代理可能会对环境做出错误假设。
  • 它们可能会基于误解的上下文执行操作。
  • 通常没有内建机制来识别何时操作超出了自己的能力范围。
• 错误传播：
  • 在多步骤任务中，小错误可能会累积。
  • 从中途失败恢复仍然是一个重大挑战。
  • 长时间运行的任务尤其容易出现连锁反应。
• 上下文管理：
  • 在长时间序列操作中维持准确的状态。
  • 处理中断并恢复任务。
  • 可靠地管理多个并发操作。

正如Levie所指出的：

“我们如何确保结果的准确性，而不是在每一步都出现渐进的幻觉或错误？”

这仍然是代理开发中的核心挑战。

安全与隐私问题

代理的自主性引发了显著的安全和隐私问题：

• 访问控制：
  • 代理通常需要广泛的系统访问权限才能有效工作。
  • 传统的安全模型并未针对自主操作体设计。
  • 安全地管理凭证委托是复杂的。
• 数据隐私：
  • 代理可能会在多个系统中处理敏感信息。
  • 在复杂工作流中，隐私边界可能不明确。
  • 数据保留与处置政策需要重新考虑。
• 审计与问责：
  • 跟踪代理行为以确保合规。
  • 确立代理决策的责任。
  • 管理自动化过程中的责任问题。

经济与实际局限

AI代理的经济性也提出了一些挑战：

• 计算成本：
  • 运行复杂的AI代理需要大量的计算资源。
  • 每次操作的成本可能比传统自动化高。
  • 扩展经济性尚未明确理解。
• 集成开销：
  • 适应现有系统与代理的交互。
  • 培训和维护成本。
  • 开发适合代理的接口。
• 技能要求：
  • 有效部署代理仍然需要大量专业知识。
  • 理解代理的局限性和能力。
  • 管理和监控代理的操作。

结论：前进的道路

AI代理代表了我们与技术互动方式的根本转变。虽然当前的应用存在局限性，但我们显然正朝着一个未来迈进，AI代理将成为我们工作、创造和解决问题的重要组成部分。

成功的关键在于理解这些系统的潜力与局限性。如Levie所言：

“未来十年将由我们与AI的合作方式来定义——而不仅仅是它有多聪明。”

这表明，成功不仅依赖于技术进步，还依赖于开发适当的部署与集成框架，释放出“未被消费”的领域价值，在这些领域中原本没有任何工作正在进行。

对于开发者、商业领袖和技术人员来说，重要的是要深思熟虑地与这项技术互动。理解它的能力与局限，同时也要扩展思维，超越仅仅是自动化现有工作流程的范围，去想象以前不可能实现的东西。当技术的价值不再受限于人类的处理能力时，创新的机会将爆发。

AI代理的时代正在展开。

问题不在于它们是否会改变我们与技术的互动方式，而在于我们如何塑造这种变革。在我们应对这一转型的过程中，我们既需要意识到挑战，也需要有勇气重新构想当软件成为自主伙伴而不仅仅是工具时，可能带来的无限可能。