我们经常听到 2025 年将是 AI Agents之年，但这到底意味着什么？

实际上， AI Agents已经存在了几十年。只是最近，大型语言模型（LLMs）消除了创建代理系统的最大障碍之一：编写自定义算法和从零训练模型。现在，复杂的推理只需一个 API 调用即可实现。

然而，在追随这一技术热潮之前，我们应该了解整个背景： AI Agents是什么、它们为何出现、如何工作，以及——最重要的——它们能做什么，不能做什么。

AI Agents的定义

AI Agents是一种软件系统，能够在极少的人为干预下运行，主要具备以下能力：

• 感知并影响其所处的动态环境
• 评估环境并决定采取的行动
• 自主执行最佳决策
• 在循环过程中持续运行，并记忆其观察和执行的内容

例如，一个持续监测 Web 应用性能、识别问题并向相关团队报告的系统，不仅仅是一个简单的功能调用。它能够循环运行、处理不断变化的数据，并基于数据做出决策。

为什么需要 AI Agents？

AI Agents解决了四大人类难以规模化处理的问题：

1. 碎片化系统：代理能够连接原本孤立的数据流或工具（如安全团队手动交叉比对防火墙、入侵检测系统（IDS）和安全信息管理系统（SIEM）日志）。
2. 无尽的决策：代理可以全天候处理重复性的决策，而不会疲劳（如自动回滚失败的部署）。
3. 指数级复杂度：代理可以处理变量过多、人类难以掌握的场景（如在电网负荷紧张时智能调度能源）。
4. 实时自适应：代理可以在事件之间的毫秒级时间内调整规则（如在金融交易之间实时更新欺诈检测策略）。

虽然 AI Agents的概念由来已久，但支撑其规模化运行的基础设施才刚刚成熟。如今的 AI Agents不再是死板的规则集合，而是更灵活的推理系统，未来可能会变得更加智能。

AI Agents的演进

AI Agents并非新兴趋势，早在 20 世纪 50 年代，就已经有出色的智能系统出现：

1956：逻辑理论家（The Logic Theorist）
1970s：医学诊断系统 MYCIN
1980s：专家系统 XCON
1990s：国际象棋 AI Deep Thought
2010s：Jeopardy! 冠军 Watson、围棋 AI AlphaGo
2020s：GPT-3、2024 年 PharmaAI 药物研究 AI

过去 70 年，我们主要通过手工编写规则和数据来构建 AI Agents。然而，自 2020 年以来，LLMs 让我们能够创建更智能的 AI Agents，而无需：

• 硬编码所有规则（如 Deep Thought 的国际象棋逻辑）
• 严格筛选训练数据（如 Watson 备战 Jeopardy!）
• 手动特征工程（如 AlphaGo 的围棋招法预测）

如今，只需 API 调用，开发者就能构建能够推理新场景的 AI Agents，而过去这需要博士团队数月的努力。

我的观点？即使不再推出新的 LLMs，我们也尚未见证 AI Agents的最佳表现——并非因为 LLMs 不够智能，而是我们尚未像优化传统 AI Agents那样，充分优化其基础设施、规则和数据。

AI Agents的工作原理（以及它们与 AI 模型的区别）

虽然 LLMs 提升了 AI Agents的推理能力，但 AI Agents的核心不在于是否使用 LLM。相较于单纯的 AI 模型， AI Agents还具备以下特点：

• 自主性：代理能够持续运行，几乎无需人为干预，而模型仅执行一次任务。例如，Web 监控代理可以自主触发警报，而普通 AI 模型仅在收到查询时才会响应。
• 输入处理：代理能够主动感知环境并更新自身状态，而模型每次调用都需要完整的上下文。例如，智能客服 AI 可以保持对话记忆，而普通语言模型则需要在每次 API 调用时提供完整对话记录。
• 适应性：代理可以实时调整行为，而模型仅处理静态输入。例如，动态推荐系统会根据用户点击不断调整推荐，而静态模型则需要额外输入才能更新结果。

简单来说，** AI Agents = AI 模型 + 用于循环运行的粘合代码（Glue Code）**。

这一“粘合代码”才是关键所在，我们已经花费 70 年优化它，而 LLM 时代的 AI Agents仍处于早期阶段。优秀 AI Agents与普通 AI Agents的区别，主要取决于以下核心组件的整合：

• 个性化数据
• 实时记忆
• 感知—思考—行动的循环机制
• 工具调用能力

未来， AI Agents的突破将更多取决于这些基础能力的优化，而不仅仅是 LLM 的迭代。

1. 个性化数据：基础构建块

从无状态的通用 AI 到真正的自主 AI，关键在于让模型能够访问你的特定上下文。开发者通常通过以下方法实现个性化，按照影响力和投入程度从低到高排序：

检索增强生成（RAG）

RAG 使用向量数据库，让模型可以“回忆”来自外部来源的相关信息（例如你的 Slack 聊天记录或代码库）。

向量数据库会将数据转换为嵌入（高效的数值表示），然后将相关的文本片段注入到 AI 模型的提示词中。

然而，RAG 受限于隐式信息关联。例如，问 AI 关于你的蜥蜴时，它可能会提取你的宠物 Scaleb 的数据，但如果你问“我的好朋友是谁？”，除非数据库中明确注明“好朋友是一只爬行动物”，否则不会返回 Scaleb。

直接提示注入

最直接的方法是通过提示词提供个人化的上下文：直接告诉 AI。

相比 RAG，这种方法更可靠——模型处理的所有细节都来自提示词，而无需检索。但它存在上下文长度限制（即使是 Gemini Pro 也最多只能处理约 3000 页文本）。此外，每次调用时都需要提供新上下文，可能比设置 RAG 还麻烦。

用户还可以覆盖注入的上下文（如输入“忽略之前的指令……”），这对处理敏感规则来说是个风险。

直接提示注入适用于小型、临时数据集，准确性比规模更重要的场景。

系统提示工程

修改 AI 的系统提示，可以将核心规则写入模型的“操作系统”中，例如：

• 强调安全性规则（“始终引用来源”）
• 规范工具使用（“将单位转换为英尺”）

系统提示优先级高于用户提示（无法通过“忽略之前的指令”绕过），但数据过多可能导致模型忽略特殊情况。

平衡至关重要——定义“如何思考”（例如“使用 Markdown 标题结构化答案”），同时让 RAG 和用户请求决定“参考什么”（如代码库文件）。

这种方法适用于保持品牌语调或合规要求，而无需反复重新提示。

微调现有 LLM

微调比提示词或 RAG 复杂，但它能永久改变模型的行为，使其在收到提示之前就具备特定能力。例如，将通用的“LawyerLLM”调整为你的法律顾问。

对于 AI 不是核心业务但能增强业务的企业（如 H&M 的客服 AI），微调能极大提升其在特定领域的表现，而且不需要深入的机器学习专业知识。

微调使用监督学习，例如提供输入/输出对（如法律问题及律师事务所的标准回答），以调整模型的文本生成方式。

训练专门模型

这与从零构建自定义模型不同，更适用于关键、可重复的任务，而通用 LLM 在这些任务上表现不佳。

例如，在 Builder，我们训练了一个专门的模型，用于将设计转换为代码，它比通用 LLM 快 1000 倍、成本更低。这种方法允许不断优化，以超越现有大模型提供的通用解决方案。

自定义模型构建

这是终极选择：完全从头开始训练模型。

这通常需要 10 亿以上的特定领域数据（如 BloombergGPT 的 3630 亿金融文本）、PyTorch/TensorFlow 专业知识，以及普通初创公司难以承受的 GPU 计算成本（约 $100 万/月）。

尽管定制模型可以在特定领域表现出色，但它面临被淘汰的风险——今天的最先进技术可能明天就变成过时产品（如 Claude Sonnet 可能取代 GPT-4）。

因此，自定义模型适用于 AI 驱动型企业，例如 AlphaGo 之于强化学习。

2. 实时记忆： AI Agents如何学习

AI Agents可以利用记忆，根据预设目标自动改进，这通常被称为“评测”（evals）。例如，Builder 的 Micro Agent 生成测试（作为评测），然后不断尝试编写代码以通过测试。它会记住哪些方法失败了，并持续优化，直到所有测试通过。这是通过简单的提示注入到模型的上下文窗口中实现的。

这种方法很有效，但大多数 AI Agents需要比无状态 LLM API 更高级的记忆机制。目前，大部分 LLM API 在每次请求时都会重新传输整个聊天记录，而有状态的记忆可以让代理在多个交互中动态进化。

** AI Agents的记忆存储方式包括：**

• 向量数据库：用于语义回忆（如“Scaleb 对某些食物过敏”→ 避免推荐面包虫）。
• 知识图谱：用于映射关系（如“用户的母亲”→“每周日都会打电话”）。
• 操作日志：用于重试策略（如“API 调用失败”→“每 5 分钟尝试新参数”）。

相比无状态系统，记忆系统带来的优势包括：

• 自适应学习：记录行为模式（如“用户拒绝面包虫推荐”→“自动隐藏爬行动物相关内容”）。
• 推理循环：通过递归工作流进行自我校正（如“API 失败”→“调整参数”→“成功”）。
• 用户连续性：避免重复提供上下文（如“仍然不吃面包虫吗？” vs. “再告诉我一次 Scaleb 的信息”）。

常见的记忆系统使用类似 RAG 的流程：

用户查询 → 检索记忆 → 判断是否相关

• 否 → 存储新记忆
• 是 → 增强提示
  → 生成响应

更复杂的系统还可以加入：

• 时间衰减（自动让记忆随时间过期）
• 命名空间隔离（支持多用户系统）
• 记忆验证（清理 LLM 生成的记忆，减少幻觉信息）

未来， AI Agents的进化不仅依赖于更强大的 LLM，更取决于个性化数据和记忆系统的优化。

3. “感知-思考-行动”循环

AI Agents的核心机制是“感知-思考-行动”循环——一个让静态 AI 调用变成动态、自我纠正工作流的闭环。

这不仅仅是理论概念，而是代理执行任务的实际方式。

感知（Sense）

在第一阶段， AI Agents会主动观察环境。

它不会等待所有必要信息一次性输入，而是持续监测更新，例如用户输入、个性化数据和记忆、外部 API 数据等。

思考（Think）

在获取最新上下文后，代理会进行深思熟虑，解析信息、权衡行动选项，并评估其上一次尝试是否达成目标。

这个“思考”步骤允许代理将自身输出与硬编码的评测标准或更灵活的抽象性能指标进行比较（这些评测可以由代理自身或另一个 LLM 进行）。在 OpenAI 的 o1 和 Deepseek 的 R1 这样的 LLM 中，你可以看到这种机制的实际应用。

行动（Act）

最终，代理执行最佳行动，这可能包括生成输出、调用外部工具，或触发另一个代理。

这个行为会改变代理的环境，生成新的数据进入“感知”阶段，形成循环。每一次迭代都为改进和稳定输出提供机会。

循环退出（Loop Exit）

代理循环会在满足明确的退出条件时停止——比如 CI/CD 流水线只有在通过所有测试后才会部署代码。

如果需要额外的退出方式，可以设置最大重试次数。例如，在 OpenAI 的 o3 模型中，低、中、高推理强度的区别只是重试次数的不同。

4. 工具调用：连接现有系统

AI Agents的另一个核心组件是工具调用。工具是任何外部编码函数，代理可以调用它们并获取结果，就像与用户聊天一样。

工具可以：

• 从外部 API 获取数据
• 调用任意编程语言编写的函数
• 调用专门的 AI Agents（通常比单个代理执行所有任务更高效）
• 读取或存储数据
• 其他操作

工具让 AI Agents能够与环境交互，具体能力取决于你为其提供的工具，例如任何 API 服务提供商。

示例：工具调用流程

一个 AI Agents的工具调用流程可能是这样的：

1. 用户输入 → 代理决定是否需要调用工具
2. 如果需要调用工具 → 代理调用 Notion、Gmail、Playwright、Slack、Postgres、Finder、GitHub 等外部服务
3. 工具返回数据 → 代理分析并决定是否需要更多调用
4. 如果不需要工具，直接生成最终答案
   
   
   例如，你可以设计一个小型代理工作流，扫描你的电子邮件并将旅行计划整理到文件夹中。这个代理需要访问两个 Gmail 工具：

• 一个工具用于接收新邮件并触发代理工作流
• 另一个工具用于判断邮件是否与旅行相关，如果是，则存入“旅行”文件夹

工具调用的挑战

不幸的是，每个 AI Agents要使用的工具，都需要手动教会它如何使用——代理必须构造结构化请求（如 JSON）并填入正确的函数参数。

代理如何决定何时使用工具？这依赖于初始编程（提示词或微调）以及当前输入的分析。代理通常会被训练识别特定关键词、模式或情境，以决定是否调用某个工具。

然而，工具调用存在一些问题：

• 占用模型上下文窗口：每个工具的调用逻辑都需要存储在上下文中，增加了 AI Agents的负担。
• 接入多个工具较复杂：为代理连接多个工具可能变得非常麻烦。
• 工具调用失败时需重试：如果模型难以正确调用工具，你可能需要实现重试机制或对返回的 JSON 进行验证。

模型上下文协议（MCP）如何改进工具调用

为了解决这个问题，Anthropic 推出了模型上下文协议（MCP），它是一种开放标准，允许模型学习“统一的 MCP 工具调用”规则，而不是为每个 API 单独编写调用逻辑。

MCP 的优势：

• 只要有开发者维护某个服务（如 Notion 或 Slack）的 MCP 服务器，你的 AI Agents就可以无缝访问这些服务。
• 你可以查看最新的 MCP 服务器列表，看看有哪些工具可用。

但要注意，MCP 仍然处于发展阶段，并非所有模型或服务都完全支持它。此外，MCP 工具调用会将数据发送到外部服务器，存在安全隐患，所以要谨慎处理敏感信息。

代理 vs. 传统 AI 模型：权衡考量

到目前为止，我们已经介绍了个性化数据、实时记忆、自主循环、工具调用，它们共同让 AI Agents比无状态 LLM 更强大。

然而，在全面自动化之前，我们需要考虑一些现实问题：

1. 错误传播 🚨
   AI 容易产生幻觉，如果代理在循环中没有自我修正机制，错误会被放大。例如，在第一轮错误的假设，可能在第三轮变成“既定事实”。

2. 搭建成本 💰
   代理的构建需要时间，一旦建成，它们往往缺乏灵活性，无法轻松扩展到其他用途。因此，可能需要多个代理来处理不同任务。

3. 复杂性 🧩
   代理的高度灵活性也带来了决策困难，比如：

   • 该用哪个模型？
   • 每个提示词的温度参数如何调整？
   • 如何最佳地编写提示词？
     这些问题的学习曲线陡峭，而且输出结果的不可预测性可能让开发者感到“不公平”。

4. 成本波动 📈
   传统的 LLM 任务可以通过匹配模型大小和任务复杂度来优化成本，但 AI Agents的 API 调用次数远高于单次请求，导致费用激增。

5. 维护负担 🔄
   LLM 版本迭代快，更便宜、更强的模型不断出现。要构建可持续的 AI Agents系统，必须采用抽象架构，避免模型依赖性过强。

6. 安全性 🔒
   代理和工具调用 API 时，需要谨慎管理共享数据。由于非确定性系统很难完全清理数据，所以要控制代理访问的上下文，避免泄露敏感信息。

7. 数据依赖 📊
   AI Agents的表现取决于数据质量和规则定义（无论是训练、微调还是提示词）。如果提供的数据不相关，代理也无法提供有价值的输出。

未来：更依赖 AI Agents？

那么，我们会进入“ AI Agents元年”吗？

关键并不在于模型是否变得更聪明，而是我们如何用更自适应的系统替代 70 年来的僵硬规则。

真正的 AI Agents应该：
✅ 能跨环境推理
✅ 在工作中不断改进
✅ 注重实际应用，而非科幻幻想

谨慎扩展代理，每个 API 集成和反馈循环都会增加维护成本。今天成功的 AI Agents，往往专注于人类不擅长的任务——例如服务器监控、欺诈检测——而不是假装自己是“全知全能的 AI 天才”。

LLM 并没有发明代理，但它让代理从“实验室展品”变成了“工作坊工具”。
我们不是要打造 HAL 9000，而是让现有系统更智能，一次优化一个闭环。