在人工智能的浪潮之巅，“智能体”（Agent）无疑是最引人遐想的词汇之一。它承诺了一个未来：AI不再仅仅是被动回答问题的工具，而是能够独立思考、规划并执行复杂任务的自主伙伴。然而，当我们与数十个来自各行各业、致力于构建这些未来伙伴的团队深入合作后，一个出人意料的发现浮出水面：最成功的智能体系统，并非诞生于那些层层叠叠、错综复杂的框架或专用库，而是源自于一些简单、可组合的朴素模式。这篇长文，将是我们在实践中披荆斩棘后提炼出的经验与智慧。我们将共同探索，如何从最基础的构建单元出发，一步步搭建出既强大又可靠的智能体系统。这不仅是一份写给开发者的实用指南，更是一次对当前AI技术边界的深度思考。 ### 🧐 **开宗明义：到底什么是“智能体”？** 在我们启程之前，必须先校准我们的罗盘。在AI的世界里，“智能体”这个词的定义可谓是“一千个读者有一千个哈姆雷特”。有些团队将其定义为能够长期自主运行、调用多种工具完成宏大任务的“全自动系统”；而另一些团队则用它来描述那些遵循预设工作流程、更具规范性的“半自动助手”。在Anthropic，我们倾向于将这些统称为**智能体系统（agentic systems）**，但我们在此之上画出了一条至关重要的架构分界线，以此区分两种核心形态：**工作流（Workflows）**与**智能体（Agents）**。 * **工作流（Workflows）**：可以将其想象成一个精心编排的舞台剧。大型语言模型（LLM）和各种工具是演员，但它们的每一步行动、每一句台词，都由预先编写好的代码路径（剧本）严格规定。它的优点是结果高度可预测且稳定。 * **智能体（Agents）**：这更像是一场即兴戏剧。LLM是那位拥有绝对主导权的即兴表演大师，它动态地决定整个流程、选择合适的工具，并掌控着完成任务的方式。它的核心在于灵活性和模型驱动的决策能力。 > **注解：** 简单来说，“工作流”是“你告诉AI一步步该做什么”，而“智能体”是“你告诉AI目标是什么，它自己决定怎么做”。前者是优秀的执行者，后者是初级的思考者。在接下来的篇章中，我们将深入探索这两种系统的构建模式。同时，我们也会在文末的附录中，通过两个真实的商业场景，一窥这些系统在实践中创造的巨大价值。 ### 🧭 **导航复杂性：何时以及为何需要智能体？** 在投身于构建智能体系统的热潮之前，我们必须牢记工程师的第一信条：**如无必要，勿增实体**。我们强烈建议，永远先寻找最简单的解决方案，只有在必要时才增加系统的复杂性。构建智能体系统，本质上是一场用**延迟和成本**换取**更优任务性能**的交易。在很多场景下，这种交易并不划算。对于许多应用而言，通过精巧的提示词工程、结合检索增强生成（RAG）技术以及提供几个上下文示例，优化单次的LLM调用，已经足以解决问题。那么，什么时候这笔交易是值得的呢？当任务的复杂性确实需要多步骤处理时： * 如果任务可以被清晰地分解为固定的子任务，那么**工作流**是你的不二之选，它能提供可预测的、一致的高质量输出。 * 如果任务充满不确定性，需要根据实时情况灵活决策，那么**智能体**将是更合适的选择，它能在大规模应用中展现出模型驱动决策的威力。 #### **关于框架的迷思** 市面上不乏让智能体系统实现起来更容易的框架，例如LangChain的`LangGraph`、亚马逊Bedrock的`AI Agent`框架，以及像`Rivet`和`Vellum`这样的可视化工作流构建工具。它们极大地简化了诸如调用LLM、定义和解析工具、链接调用等底层任务，让新手也能快速上手。然而，便利的背后也隐藏着陷阱。这些框架往往会创造出额外的抽象层，像一层毛玻璃，模糊了底层的提示和模型响应，使得调试变得异常困难。它们还会诱使开发者在不需要的地方过度设计，堆砌复杂性，最终构建出一个脆弱而难以维护的“空中楼阁”。我们的建议是：**从直接调用LLM API开始**。你会惊讶地发现，许多强大的模式，用几行代码就能实现。如果你确实需要使用框架，请务必深入理解其底层代码的运作方式。无数次的客户案例告诉我们，对“黑箱”内部运作的错误假设，是导致项目失败的常见根源。 ### 🧱 **万丈高楼平地起：智能体的基本构件** 现在，让我们正式开始搭建工作。我们将从最基础的构件——“增强型LLM”——开始，逐步增加复杂性，从简单的组合式工作流，一直走向完全自主的智能体。 #### **核心构件：增强型LLM（The Augmented LLM）** 所有智能体系统的基石，都是一个被赋予了超能力的LLM。我们称之为**增强型LLM**。它的核心能力不再局限于文本生成，而是通过三种关键的“增强件”得到了极大的扩展：**检索（retrieval）**、**工具（tools）**和**记忆（memory）**。我们当前最先进的模型，已经能够主动地运用这些能力——自己生成搜索查询、自主选择合适的工具、并决定哪些信息需要被记住。在实现这一构件时，我们建议将焦点放在两个关键方面： 1. **量体裁衣**：根据你的具体用例，定制化这些增强能力。 2. **清晰接口**：为你的LLM提供一个简单、文档齐全的接口来调用这些能力。 > **注解：** Anthropic最近发布的**模型上下文协议（Model Context Protocol）**正是为此而生，它允许开发者通过一个简单的客户端实现，与一个不断增长的第三方工具生态系统无缝集成。在本文的后续部分，我们将默认每一次LLM调用，都具备了这些增强能力。 ### 📜 **预设的剧本：五种强大的工作流模式** 基于“增强型LLM”这个基本构件，我们可以组合出多种高效的工作流。这些模式通过预设的逻辑路径来编排LLM和工具，以应对不同类型的复杂任务。 #### ⛓️ **环环相扣：提示链（Prompt Chaining）的艺术** 这是最直接的多步工作流。**提示链**将一个大任务分解为一系列连续的小步骤，其中每个LLM调用的输出，都成为下一个LLM调用的输入。你可以把它想象成一条工厂流水线，每个工位（LLM调用）只负责一道简单的工序。 **适用场景**：当任务可以被轻松、干净地分解为固定的子任务时，提示链是理想的选择。其主要目标是通过将一个复杂的任务分解为多个简单的任务，来牺牲一定的延迟以换取更高的准确性。 **应用实例**： * 先生成一篇营销文案，然后将其翻译成另一种语言。 * 先撰写一份文档大纲，然后由程序检查大纲是否满足特定标准（如包含某些关键词），最后再根据合格的大纲生成完整的文档内容。 #### 🚦 **智能分流：路由（Routing）模式的抉择** **路由**工作流就像一个智能交通警察。它首先对输入进行分类，然后将其引导至一个专门处理该类任务的下游流程。这种模式实现了“关注点分离”，让你可以为不同类型的输入构建高度优化的专属提示和工具集，而不用担心优化一个分支会损害另一个分支的性能。 **适用场景**：适用于那些可以明确划分为几个不同类别的复杂任务，并且分类本身可以被LLM或传统的分类算法准确处理。 **应用实例**： * 在客户服务中，将不同类型的用户问询（如“一般问题”、“退款请求”、“技术支持”）分流到不同的处理流程、提示词和工具集。 * 为了优化成本和速度，将简单或常见的问题路由给更小、更快的模型（如Claude 3.5 Haiku），而将困难或罕见的问题交给能力更强的模型（如Claude 3.5 Sonnet）。 #### 👯♀️ **分身有术：并行化（Parallelization）模式的力量** 有时，让多个LLM同时处理一个任务的不同侧面，然后将它们的输出进行程序化聚合，会产生奇效。这就是**并行化**工作流，它主要有两种变体： 1. **分片（Sectioning）**：将一个任务分解为多个可以并行运行的、独立的子任务。 2. **投票（Voting）**：让多个LLM实例使用相同或不同的提示重复运行同一个任务，以获得多样化的输出或通过投票达成共识。 **适用场景**：当子任务可以被并行化以提高速度时，或者当需要多个视角或多次尝试来获得更高置信度的结果时，并行化非常有效。对于需要考虑多个方面的复杂任务，让每个LLM调用专注于一个特定方面，通常比让单个LLM同时处理所有方面表现得更好。 **应用实例**： * **分片**：实现安全护栏。一个模型实例负责处理用户查询并生成核心响应，而另一个实例则同时对用户输入进行筛选，检查是否存在不当内容或请求。这种“左右互搏”的方式通常比单个LLM“一心二用”效果更好。 * **投票**：审查一段代码是否存在安全漏洞。可以设计多个不同的提示，从不同角度（如注入风险、数据泄露、逻辑错误）来审查代码，只要有任何一个实例标记出问题，就触发警报。 #### 👑 **指挥家与演奏家：编排者-工作者（Orchestrator-Workers）模式** 在这个模式中，我们引入了一个“指挥家”LLM。这个**编排者（Orchestrator）**负责动态地将一个复杂任务分解，然后将这些子任务“委托”给多个“演奏家”——即**工作者（Worker）**LLM——去执行，最后再将它们的结果合成为一个统一的最终输出。 **适用场景**：非常适合那些你无法预先预测所需子任务的复杂场景。它与并行化模式在拓扑结构上相似，但关键区别在于其**灵活性**——子任务不是预先定义好的，而是由编排者根据具体输入动态决定的。 **应用实例**： * **代码生成产品**：当需要对一个代码库进行复杂的修改，可能涉及多个文件的增删改查时，编排者可以首先分析需求，确定需要修改哪些文件，然后为每个文件的修改创建一个工作者任务。 * **复杂信息搜集**：当需要从多个信息源搜集和分析信息以形成综合报告时，编排者可以决定需要查询哪些数据源，并为每个查询创建一个工作者。 #### 🧐 **自我审视：评估者-优化者（Evaluator-Optimizer）循环** 这是一个引入了“反思”机制的强大工作流。在**评估者-优化者**模式中，一个LLM调用（优化者）负责生成初始响应，而另一个LLM调用（评估者）则对其进行批判性的评估和反馈。这个过程可以循环进行，直到结果达到预设的质量标准。 **适用场景**：当任务有明确的评估标准，并且迭代优化能带来可衡量价值时，此模式特别有效。判断是否适用的两个信号是：第一，当人类提供反馈时，LLM的响应能否得到显著改善；第二，LLM本身能否提供这种高质量的反馈。这类似于一位人类作家在创作一篇精美文章时经历的反复修改和润色的过程。 **应用实例**： * **文学翻译**：翻译者LLM可能无法在初稿中捕捉到所有的文化和语言上的细微差别，但评估者LLM可以扮演一个经验丰富的编辑角色，提出有价值的批评和改进建议。 * **复杂的研究任务**：需要多轮搜索和分析才能收集全面的信息。优化者负责执行搜索和总结，而评估者则判断当前信息是否足够，或者是否需要进一步的搜索。 ### 🤖 **迈向自主：当智能体挣脱束缚** 当我们把上述工作流中的“预设路径”拿掉，让LLM在循环中根据环境反馈自由地使用工具时，我们就从“工作流”迈入了“智能体”的领域。随着LLM在理解复杂指令、进行推理规划、可靠使用工具以及从错误中恢复等关键能力上的成熟，真正的**自主智能体（Autonomous Agents）**正开始在生产环境中崭露头角。智能体的工作流程通常如下： 1. **启动**：通过人类用户的指令或互动式讨论来明确任务。 2. **规划与执行**：一旦任务明确，智能体便开始独立地规划和执行步骤。在每一步，它都会从环境中获取“**地面实况**”（Ground Truth）——例如工具调用的返回结果或代码执行的输出——来评估自己的进展。 3. **反馈与迭代**：智能体可以在预设的检查点或遇到障碍时暂停，向人类寻求进一步的信息或判断。 4. **终止**：任务完成后，流程终止。为了保持控制，通常也会设置一个“熔断机制”，如最大迭代次数，以防止无限循环。 **适用场景**：智能体适用于那些开放式的问题，这些问题的解决步骤难以或不可能预先预测，你无法硬编码一个固定的路径。在这种场景下，LLM可能会连续运行多轮，你必须对其决策能力有一定程度的信任。 **风险与挑战**：智能体的自主性也意味着更高的成本和潜在的**误差累积**风险。我们强烈建议在部署前，必须在**沙盒环境**中进行广泛的测试，并配备适当的**安全护栏**。 **应用实例**： * **编码智能体**：我们自己实现了一个编码智能体，它能够解决[SWE-bench]基准测试中的任务，这些任务通常需要根据一个任务描述，对多个文件进行复杂的编辑。 * **“计算机使用”参考实现**：我们还构建了一个参考实现，其中Claude模型可以像人一样操作计算机来完成任务。 ### 🛠️ **工欲善其事：为你的智能体打造神兵利器** 无论你构建的是哪种智能体系统，**工具（Tools）**都可能是其中至关重要的一环。工具是Claude与外部服务和API交互的桥梁。因此，工具的定义和说明书，应该得到与核心提示词同等级别的“提示工程”关注。我们不妨借鉴人机交互（HCI）领域的智慧，来思考如何打造优秀的**智能体-计算机接口（Agent-Computer Interface, ACI）**。以下是一些核心原则： 1. **换位思考，站在模型的角度**：根据这个工具的描述和参数，它是否显而易见、易于使用？还是需要仔细琢磨？如果人类开发者都觉得费劲，那么模型很可能也会感到困惑。一个好的工具定义通常包括用法示例、边界情况说明、输入格式要求以及与其他工具的清晰界限。 2. **让格式更自然**：思考一下，哪种格式更接近模型在互联网上自然学习到的文本？例如，在返回结构化数据时，相比于需要额外转义换行符和引号的JSON，将代码包裹在Markdown代码块中对模型来说可能更“自然”，更不容易出错。 3. **给予模型“思考”的空间**：在设计工具的输出格式时，避免让模型“走投无路”。例如，要求模型在生成新代码之前，先在块头中准确声明将要更改的行数，这是一个非常困难的任务。 4. **Poka-yoke你的工具**：这是一个源自日本制造业的术语，意为“**防错**”。通过巧妙地设计工具的参数，让模型更难犯错。 > **案例研究：绝对路径的胜利** > 在我们为SWE-bench构建编码智能体的过程中，我们发现，优化工具所花费的时间甚至超过了优化整体提示。例如，我们最初的工具使用相对文件路径。当智能体在文件目录中移动后，它就开始在路径处理上犯错。为了解决这个问题，我们将工具修改为**总是要求使用绝对文件路径**。这个小小的改动，让模型的使用变得完美无瑕。这就是一次成功的“防错”设计。 5. **反复测试和迭代**：在我们的工作台（Workbench）中，用大量的示例输入来测试模型如何使用你的工具，观察它会犯哪些错误，然后不断迭代你的工具设计。 ### 🌐 **理论照进现实：智能体的两大实战演练场** 我们与客户的合作揭示了两个尤为有前景的AI智能体应用领域，它们生动地展示了上述模式的实践价值。 #### 📞 **不再等待：重塑客户支持** 客户支持领域是智能体应用的天然沃土。它将我们熟悉的聊天机器人界面与通过工具集成实现的增强能力完美结合。 * **天然的对话流**：支持互动本身就是对话形式，同时又需要访问外部信息和执行操作。 * **强大的工具集成**：可以集成工具来拉取客户数据、订单历史、知识库文章。 * **可执行的操作**：可以程序化地处理诸如发起退款、更新工单等操作。 * **明确的成功标准**：可以通过用户是否确认问题被解决来清晰地衡量成功。一些公司已经通过“按成功解决次数收费”的商业模式证明了这种方法的可行性，这显示了他们对其智能体有效性的极大信心。 #### 💻 **代码世界的魔法师：编程智能体的崛起** 软件开发领域展现了LLM应用的巨大潜力，其能力已从简单的代码补全，进化到自主解决问题。智能体在此领域尤其有效，因为： * **可验证的解决方案**：代码方案可以通过自动化测试来验证其正确性。 * **反馈驱动的迭代**：智能体可以利用测试结果作为反馈，不断迭代和修复自己的解决方案。 * **结构化的问题空间**：编程任务通常具有良好定义和结构化的特点。 * **可量化的产出质量**：可以通过基准测试（如SWE-bench）客观地衡量产出质量。在我们的内部实现中，智能体现在已经能够仅凭一个GitHub拉取请求的描述，就解决[SWE-bench Verified]基准测试中的真实问题。然而，尽管自动化测试有助于验证功能，**人类的审查**对于确保解决方案符合更广泛的系统架构和设计要求，仍然至关重要。 ### **总结：简约之禅——构建高效智能体的终极法则** 在LLM领域取得成功，关键不在于构建最复杂的系统，而在于为你的需求构建**最合适的**系统。我们的核心理念可以总结为： **从简单的提示开始，通过全面的评估来优化它们，只有当更简单的解决方案力有不逮时，才引入多步骤的智能体系统。** 在实施智能体的过程中，我们努力遵循三个核心原则： 1. **简约性（Simplicity）**：保持你的智能体设计简洁明了。 2. **透明性（Transparency）**：通过明确展示智能体的规划步骤来优先考虑透明度。 3. **精心打磨的接口（ACI）**：通过详尽的工具文档和严格的测试，精心打造你的智能体-计算机接口。框架可以帮助你快速起步，但随着项目走向生产环境，请不要犹豫，剥离不必要的抽象层，用最基本的构件来搭建你的系统。通过遵循这些原则，你将能够创造出不仅功能强大，而且可靠、可维护、并最终能被用户所信赖的智能体。 --- **参考文献** 1. Schluntz, E., & Zhang, B. (2024). *Building effective agents*. Anthropic. [https://www.anthropic.com/engineering/building-effective-agents] 2. Vaswani, A., et al. (2017). *Attention is All You Need*. Advances in Neural Information Processing Systems 30 (NIPS 2017). 3. Yao, S., et al. (2022). *ReAct: Synergizing Reasoning and Acting in Language Models*. arXiv preprint arXiv:2210.03629. 4. Chase, H. (2022). *LangChain Documentation*. Retrieved from [https://python.langchain.com/docs/get_started/introduction] 5. Shneiderman, B. (1997). *Designing the User Interface: Strategies for Effective Human-Computer Interaction*. Addison-Wesley. (作为构建ACI思想的类比参考)

AI智能体的构建艺术：从指令木偶到自主心灵的进化之路

步子哥

在人工智能的浪潮之巅，“智能体”（Agent）无疑是最引人遐想的词汇之一。它承诺了一个未来：AI不再仅仅是被动回答问题的工具，而是能够独立思考、规划并执行复杂任务的自主伙伴。然而，当我们与数十个来自各行各业、致力于构建这些未来伙伴的团队深入合作后，一个出人意料的发现浮出水面：最成功的智能体系统，并非诞生于那些层层叠叠、错综复杂的框架或专用库，而是源自于一些简单、可组合的朴素模式。

这篇长文，将是我们在实践中披荆斩棘后提炼出的经验与智慧。我们将共同探索，如何从最基础的构建单元出发，一步步搭建出既强大又可靠的智能体系统。这不仅是一份写给开发者的实用指南，更是一次对当前AI技术边界的深度思考。

🧐 开宗明义：到底什么是“智能体”？

在我们启程之前，必须先校准我们的罗盘。在AI的世界里，“智能体”这个词的定义可谓是“一千个读者有一千个哈姆雷特”。有些团队将其定义为能够长期自主运行、调用多种工具完成宏大任务的“全自动系统”；而另一些团队则用它来描述那些遵循预设工作流程、更具规范性的“半自动助手”。

在Anthropic，我们倾向于将这些统称为智能体系统（agentic systems），但我们在此之上画出了一条至关重要的架构分界线，以此区分两种核心形态：工作流（Workflows）与智能体（Agents）。

工作流（Workflows）：可以将其想象成一个精心编排的舞台剧。大型语言模型（LLM）和各种工具是演员，但它们的每一步行动、每一句台词，都由预先编写好的代码路径（剧本）严格规定。它的优点是结果高度可预测且稳定。
智能体（Agents）：这更像是一场即兴戏剧。LLM是那位拥有绝对主导权的即兴表演大师，它动态地决定整个流程、选择合适的工具，并掌控着完成任务的方式。它的核心在于灵活性和模型驱动的决策能力。

注解： 简单来说，“工作流”是“你告诉AI一步步该做什么”，而“智能体”是“你告诉AI目标是什么，它自己决定怎么做”。前者是优秀的执行者，后者是初级的思考者。

在接下来的篇章中，我们将深入探索这两种系统的构建模式。同时，我们也会在文末的附录中，通过两个真实的商业场景，一窥这些系统在实践中创造的巨大价值。

🧭 导航复杂性：何时以及为何需要智能体？

在投身于构建智能体系统的热潮之前，我们必须牢记工程师的第一信条：如无必要，勿增实体。我们强烈建议，永远先寻找最简单的解决方案，只有在必要时才增加系统的复杂性。

构建智能体系统，本质上是一场用延迟和成本换取更优任务性能的交易。在很多场景下，这种交易并不划算。对于许多应用而言，通过精巧的提示词工程、结合检索增强生成（RAG）技术以及提供几个上下文示例，优化单次的LLM调用，已经足以解决问题。

那么，什么时候这笔交易是值得的呢？
当任务的复杂性确实需要多步骤处理时：

如果任务可以被清晰地分解为固定的子任务，那么工作流是你的不二之选，它能提供可预测的、一致的高质量输出。
如果任务充满不确定性，需要根据实时情况灵活决策，那么智能体将是更合适的选择，它能在大规模应用中展现出模型驱动决策的威力。

关于框架的迷思

市面上不乏让智能体系统实现起来更容易的框架，例如LangChain的LangGraph、亚马逊Bedrock的AI Agent框架，以及像Rivet和Vellum这样的可视化工作流构建工具。它们极大地简化了诸如调用LLM、定义和解析工具、链接调用等底层任务，让新手也能快速上手。

然而，便利的背后也隐藏着陷阱。这些框架往往会创造出额外的抽象层，像一层毛玻璃，模糊了底层的提示和模型响应，使得调试变得异常困难。它们还会诱使开发者在不需要的地方过度设计，堆砌复杂性，最终构建出一个脆弱而难以维护的“空中楼阁”。

我们的建议是：从直接调用LLM API开始。你会惊讶地发现，许多强大的模式，用几行代码就能实现。如果你确实需要使用框架，请务必深入理解其底层代码的运作方式。无数次的客户案例告诉我们，对“黑箱”内部运作的错误假设，是导致项目失败的常见根源。

🧱 万丈高楼平地起：智能体的基本构件

现在，让我们正式开始搭建工作。我们将从最基础的构件——“增强型LLM”——开始，逐步增加复杂性，从简单的组合式工作流，一直走向完全自主的智能体。

核心构件：增强型LLM（The Augmented LLM）

所有智能体系统的基石，都是一个被赋予了超能力的LLM。我们称之为增强型LLM。它的核心能力不再局限于文本生成，而是通过三种关键的“增强件”得到了极大的扩展：检索（retrieval）、工具（tools）和记忆（memory）。我们当前最先进的模型，已经能够主动地运用这些能力——自己生成搜索查询、自主选择合适的工具、并决定哪些信息需要被记住。

在实现这一构件时，我们建议将焦点放在两个关键方面：

量体裁衣：根据你的具体用例，定制化这些增强能力。
清晰接口：为你的LLM提供一个简单、文档齐全的接口来调用这些能力。

注解： Anthropic最近发布的模型上下文协议（Model Context Protocol）正是为此而生，它允许开发者通过一个简单的客户端实现，与一个不断增长的第三方工具生态系统无缝集成。

在本文的后续部分，我们将默认每一次LLM调用，都具备了这些增强能力。

📜 预设的剧本：五种强大的工作流模式

基于“增强型LLM”这个基本构件，我们可以组合出多种高效的工作流。这些模式通过预设的逻辑路径来编排LLM和工具，以应对不同类型的复杂任务。

⛓️ 环环相扣：提示链（Prompt Chaining）的艺术

这是最直接的多步工作流。提示链将一个大任务分解为一系列连续的小步骤，其中每个LLM调用的输出，都成为下一个LLM调用的输入。你可以把它想象成一条工厂流水线，每个工位（LLM调用）只负责一道简单的工序。

适用场景：当任务可以被轻松、干净地分解为固定的子任务时，提示链是理想的选择。其主要目标是通过将一个复杂的任务分解为多个简单的任务，来牺牲一定的延迟以换取更高的准确性。

应用实例：

先生成一篇营销文案，然后将其翻译成另一种语言。
先撰写一份文档大纲，然后由程序检查大纲是否满足特定标准（如包含某些关键词），最后再根据合格的大纲生成完整的文档内容。

🚦 智能分流：路由（Routing）模式的抉择

路由工作流就像一个智能交通警察。它首先对输入进行分类，然后将其引导至一个专门处理该类任务的下游流程。这种模式实现了“关注点分离”，让你可以为不同类型的输入构建高度优化的专属提示和工具集，而不用担心优化一个分支会损害另一个分支的性能。

适用场景：适用于那些可以明确划分为几个不同类别的复杂任务，并且分类本身可以被LLM或传统的分类算法准确处理。

应用实例：

在客户服务中，将不同类型的用户问询（如“一般问题”、“退款请求”、“技术支持”）分流到不同的处理流程、提示词和工具集。
为了优化成本和速度，将简单或常见的问题路由给更小、更快的模型（如Claude 3.5 Haiku），而将困难或罕见的问题交给能力更强的模型（如Claude 3.5 Sonnet）。

👯‍♀️ 分身有术：并行化（Parallelization）模式的力量

有时，让多个LLM同时处理一个任务的不同侧面，然后将它们的输出进行程序化聚合，会产生奇效。这就是并行化工作流，它主要有两种变体：

分片（Sectioning）：将一个任务分解为多个可以并行运行的、独立的子任务。
投票（Voting）：让多个LLM实例使用相同或不同的提示重复运行同一个任务，以获得多样化的输出或通过投票达成共识。

适用场景：当子任务可以被并行化以提高速度时，或者当需要多个视角或多次尝试来获得更高置信度的结果时，并行化非常有效。对于需要考虑多个方面的复杂任务，让每个LLM调用专注于一个特定方面，通常比让单个LLM同时处理所有方面表现得更好。

应用实例：

分片：实现安全护栏。一个模型实例负责处理用户查询并生成核心响应，而另一个实例则同时对用户输入进行筛选，检查是否存在不当内容或请求。这种“左右互搏”的方式通常比单个LLM“一心二用”效果更好。
投票：审查一段代码是否存在安全漏洞。可以设计多个不同的提示，从不同角度（如注入风险、数据泄露、逻辑错误）来审查代码，只要有任何一个实例标记出问题，就触发警报。

👑 指挥家与演奏家：编排者-工作者（Orchestrator-Workers）模式

在这个模式中，我们引入了一个“指挥家”LLM。这个编排者（Orchestrator）负责动态地将一个复杂任务分解，然后将这些子任务“委托”给多个“演奏家”——即工作者（Worker）LLM——去执行，最后再将它们的结果合成为一个统一的最终输出。

适用场景：非常适合那些你无法预先预测所需子任务的复杂场景。它与并行化模式在拓扑结构上相似，但关键区别在于其灵活性——子任务不是预先定义好的，而是由编排者根据具体输入动态决定的。

应用实例：

代码生成产品：当需要对一个代码库进行复杂的修改，可能涉及多个文件的增删改查时，编排者可以首先分析需求，确定需要修改哪些文件，然后为每个文件的修改创建一个工作者任务。
复杂信息搜集：当需要从多个信息源搜集和分析信息以形成综合报告时，编排者可以决定需要查询哪些数据源，并为每个查询创建一个工作者。

🧐 自我审视：评估者-优化者（Evaluator-Optimizer）循环

这是一个引入了“反思”机制的强大工作流。在评估者-优化者模式中，一个LLM调用（优化者）负责生成初始响应，而另一个LLM调用（评估者）则对其进行批判性的评估和反馈。这个过程可以循环进行，直到结果达到预设的质量标准。

适用场景：当任务有明确的评估标准，并且迭代优化能带来可衡量价值时，此模式特别有效。判断是否适用的两个信号是：第一，当人类提供反馈时，LLM的响应能否得到显著改善；第二，LLM本身能否提供这种高质量的反馈。这类似于一位人类作家在创作一篇精美文章时经历的反复修改和润色的过程。

应用实例：

文学翻译：翻译者LLM可能无法在初稿中捕捉到所有的文化和语言上的细微差别，但评估者LLM可以扮演一个经验丰富的编辑角色，提出有价值的批评和改进建议。
复杂的研究任务：需要多轮搜索和分析才能收集全面的信息。优化者负责执行搜索和总结，而评估者则判断当前信息是否足够，或者是否需要进一步的搜索。

🤖 迈向自主：当智能体挣脱束缚

当我们把上述工作流中的“预设路径”拿掉，让LLM在循环中根据环境反馈自由地使用工具时，我们就从“工作流”迈入了“智能体”的领域。

随着LLM在理解复杂指令、进行推理规划、可靠使用工具以及从错误中恢复等关键能力上的成熟，真正的自主智能体（Autonomous Agents）正开始在生产环境中崭露头角。

智能体的工作流程通常如下：

启动：通过人类用户的指令或互动式讨论来明确任务。
规划与执行：一旦任务明确，智能体便开始独立地规划和执行步骤。在每一步，它都会从环境中获取“地面实况”（Ground Truth）——例如工具调用的返回结果或代码执行的输出——来评估自己的进展。
反馈与迭代：智能体可以在预设的检查点或遇到障碍时暂停，向人类寻求进一步的信息或判断。
终止：任务完成后，流程终止。为了保持控制，通常也会设置一个“熔断机制”，如最大迭代次数，以防止无限循环。

适用场景：智能体适用于那些开放式的问题，这些问题的解决步骤难以或不可能预先预测，你无法硬编码一个固定的路径。在这种场景下，LLM可能会连续运行多轮，你必须对其决策能力有一定程度的信任。

风险与挑战：智能体的自主性也意味着更高的成本和潜在的误差累积风险。我们强烈建议在部署前，必须在沙盒环境中进行广泛的测试，并配备适当的安全护栏。

应用实例：

编码智能体：我们自己实现了一个编码智能体，它能够解决[SWE-bench]基准测试中的任务，这些任务通常需要根据一个任务描述，对多个文件进行复杂的编辑。
“计算机使用”参考实现：我们还构建了一个参考实现，其中Claude模型可以像人一样操作计算机来完成任务。

🛠️ 工欲善其事：为你的智能体打造神兵利器

无论你构建的是哪种智能体系统，工具（Tools）都可能是其中至关重要的一环。工具是Claude与外部服务和API交互的桥梁。因此，工具的定义和说明书，应该得到与核心提示词同等级别的“提示工程”关注。

我们不妨借鉴人机交互（HCI）领域的智慧，来思考如何打造优秀的智能体-计算机接口（Agent-Computer Interface, ACI）。以下是一些核心原则：

换位思考，站在模型的角度：根据这个工具的描述和参数，它是否显而易见、易于使用？还是需要仔细琢磨？如果人类开发者都觉得费劲，那么模型很可能也会感到困惑。一个好的工具定义通常包括用法示例、边界情况说明、输入格式要求以及与其他工具的清晰界限。
让格式更自然：思考一下，哪种格式更接近模型在互联网上自然学习到的文本？例如，在返回结构化数据时，相比于需要额外转义换行符和引号的JSON，将代码包裹在Markdown代码块中对模型来说可能更“自然”，更不容易出错。
给予模型“思考”的空间：在设计工具的输出格式时，避免让模型“走投无路”。例如，要求模型在生成新代码之前，先在块头中准确声明将要更改的行数，这是一个非常困难的任务。
Poka-yoke你的工具：这是一个源自日本制造业的术语，意为“防错”。通过巧妙地设计工具的参数，让模型更难犯错。

案例研究：绝对路径的胜利
在我们为SWE-bench构建编码智能体的过程中，我们发现，优化工具所花费的时间甚至超过了优化整体提示。例如，我们最初的工具使用相对文件路径。当智能体在文件目录中移动后，它就开始在路径处理上犯错。为了解决这个问题，我们将工具修改为总是要求使用绝对文件路径。这个小小的改动，让模型的使用变得完美无瑕。这就是一次成功的“防错”设计。

反复测试和迭代：在我们的工作台（Workbench）中，用大量的示例输入来测试模型如何使用你的工具，观察它会犯哪些错误，然后不断迭代你的工具设计。

🌐 理论照进现实：智能体的两大实战演练场

我们与客户的合作揭示了两个尤为有前景的AI智能体应用领域，它们生动地展示了上述模式的实践价值。

📞 不再等待：重塑客户支持

客户支持领域是智能体应用的天然沃土。它将我们熟悉的聊天机器人界面与通过工具集成实现的增强能力完美结合。

天然的对话流：支持互动本身就是对话形式，同时又需要访问外部信息和执行操作。
强大的工具集成：可以集成工具来拉取客户数据、订单历史、知识库文章。
可执行的操作：可以程序化地处理诸如发起退款、更新工单等操作。
明确的成功标准：可以通过用户是否确认问题被解决来清晰地衡量成功。

一些公司已经通过“按成功解决次数收费”的商业模式证明了这种方法的可行性，这显示了他们对其智能体有效性的极大信心。

💻 代码世界的魔法师：编程智能体的崛起

软件开发领域展现了LLM应用的巨大潜力，其能力已从简单的代码补全，进化到自主解决问题。智能体在此领域尤其有效，因为：

可验证的解决方案：代码方案可以通过自动化测试来验证其正确性。
反馈驱动的迭代：智能体可以利用测试结果作为反馈，不断迭代和修复自己的解决方案。
结构化的问题空间：编程任务通常具有良好定义和结构化的特点。
可量化的产出质量：可以通过基准测试（如SWE-bench）客观地衡量产出质量。

在我们的内部实现中，智能体现在已经能够仅凭一个GitHub拉取请求的描述，就解决[SWE-bench Verified]基准测试中的真实问题。然而，尽管自动化测试有助于验证功能，人类的审查对于确保解决方案符合更广泛的系统架构和设计要求，仍然至关重要。

总结：简约之禅——构建高效智能体的终极法则

在LLM领域取得成功，关键不在于构建最复杂的系统，而在于为你的需求构建最合适的系统。我们的核心理念可以总结为：

从简单的提示开始，通过全面的评估来优化它们，只有当更简单的解决方案力有不逮时，才引入多步骤的智能体系统。

在实施智能体的过程中，我们努力遵循三个核心原则：

简约性（Simplicity）：保持你的智能体设计简洁明了。
透明性（Transparency）：通过明确展示智能体的规划步骤来优先考虑透明度。
精心打磨的接口（ACI）：通过详尽的工具文档和严格的测试，精心打造你的智能体-计算机接口。

框架可以帮助你快速起步，但随着项目走向生产环境，请不要犹豫，剥离不必要的抽象层，用最基本的构件来搭建你的系统。通过遵循这些原则，你将能够创造出不仅功能强大，而且可靠、可维护、并最终能被用户所信赖的智能体。

参考文献

Schluntz, E., & Zhang, B. (2024). Building effective agents. Anthropic. [https://www.anthropic.com/engineering/building-effective-agents]
Vaswani, A., et al. (2017). Attention is All You Need. Advances in Neural Information Processing Systems 30 (NIPS 2017).
Yao, S., et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv preprint arXiv:2210.03629.
Chase, H. (2022). LangChain Documentation. Retrieved from [https://python.langchain.com/docs/get_started/introduction]
Shneiderman, B. (1997). Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison-Wesley. (作为构建ACI思想的类比参考)

步子哥

当AI智能体只是一行SQL查询：流处理引擎的奇幻漂流

在软件工程的浩瀚星空中，我们时常惊叹于那些颠覆传统的思想火花。不久前，Seth Wiesman 在一次演讲中提出了一个振聋发聩的观点：“那个微服务，它本应是一行SQL查询”。这个想法如同一颗投入平静湖面的石子，激起了层层涟漪。它主张使用流处理器上的SQL查询来实现微服务，以求更快的上市时间、更高的一致性和可扩展性。这不禁让我陷入沉思：既然微服务可以，那么，我们这个时代最炙手可热的概念——AI智能体（AI Agent），是否也能被“降维”成一行流式SQL查询呢？

这听起来或许有些天马行空，像是在用一把瑞士军刀去建造一艘航空母舰。但请稍安勿躁，让我们一起踏上这场思想的奇幻漂流，探索如何利用 Apache Flink 这样的流处理平台，将AI智能体的构建带入一个全新的维度。

什么是AI智能体？
我们可以借用谷歌那简洁而不失精准的定义：AI智能体是利用人工智能代表用户追求目标、完成任务的软件系统。它们展现出推理、规划和记忆能力，并拥有一定程度的自主性来做出决策、学习和适应。
更接地气的理解是，可以将它们看作是“打了AI激素”的微服务：接收输入，利用大语言模型（LLM）进行处理，然后输出结果。目前，大多数落地的AI智能体并非科幻电影里那种拥有无限权限的“天网”，而更多是定义明确的“AI辅助工作流”，例如在客户服务、医疗文档处理、自动化销售等领域大放异彩。

🌊 当数据之河倒流：流式SQL的“推”与“拉”

要理解这个看似疯狂的想法，我们首先需要厘清传统数据库查询与流式查询的根本区别。在传统世界里，你向数据库发出一条SQL查询，这是一个“拉”（pull）的动作。数据库会扫描表、查询索引，然后将整个结果集一次性返回给你。这就像你去图书馆借书，告诉管理员你要什么，然后抱着一摞书回家。

而流式查询系统则彻底颠覆了这个模式，它采用的是“推”（push）的方式。查询会持续不断地运行，像一个永不疲倦的哨兵，时刻监控着数据的流动。一旦有新的数据（事件）流入，查询会立即对这部分增量数据进行计算，并将结果的“变化量”推送给下游。这更像是你订阅了一份杂志，每当新的一期出版，邮递员就会主动把它送到你的信箱，你无需每次都去报刊亭询问。

Apache Flink 正是这样一个为事件驱动和数据密集型应用而生的平台，它天生就具备高性能、高可扩展性和高鲁棒性的基因。这些特性，恰好也是构建一个可靠AI智能体所必需的基石。更妙的是，通过SQL，我们不仅为应用程序开发者打开了新世界的大门，也让广大的数据工程师们能够轻松地参与到这场AI的盛宴中来。

🤖 为智能体注入灵魂：当SQL遇见LLM

无论我们如何定义AI智能体，有一点是毋庸置疑的：它们必须与大语言模型（LLM）互动。这标志着一种范式的转变——我们不再是编写固定的规则来处理数据，而是将结构化或非结构化的数据，连同对话历史等上下文信息，以自然语言的形式“喂”给LLM，由它来生成响应。

那么，Flink SQL是如何实现与LLM的“联姻”的呢？答案藏在一个名为 FLIP-437 的提案中，它的目标是“在Flink SQL中支持机器学习模型”，让模型成为流处理应用中的“一等公民”。通过全新的 CREATE MODEL 语句，开发者可以直接在SQL中注册来自OpenAI、Google AI、AWS Bedrock等供应商的AI模型。

让我们来看一个生动的例子。假设我们希望追踪数据库和数据流领域顶级会议（如VLDB）的最新研究论文。阅读所有论文无疑是一项耗时巨大的工程。现在，我们可以构建一个AI智能体来自动为我们总结论文摘要。整个流程在像 Confluent Cloud 这样的全托管流处理平台上可以这样实现：

新论文的PDF文件被上传到S3存储桶，通过工具（如Apache Tika）提取纯文本。
S3源连接器捕获这些文本文件，并将它们作为事件发送到Kafka主题中。
我们的AI智能体——一个流式SQL查询——消费这些事件，并调用OpenAI模型为每篇论文生成摘要。
结果被写入另一个Kafka主题，最终可以推送到Slack频道，让团队成员即时获取最新研究动态。

首先，我们需要像定义一张表一样，定义我们的AI模型：

CREATE MODEL summarization_model
INPUT (
    text STRING
)
OUTPUT (
    title STRING,
    authors STRING,
    year_of_publication INT,
    summary STRING
)
COMMENT 'Research paper summarization model'
WITH (
    'provider' = 'openai',
    'task' = 'text_generation',
    'openai.connection' = 'openai-connection',
    'openai.model_version' = 'gpt-4.1-mini',
    'openai.output_format' = 'json',
    'openai.system_prompt' = 'This is a text extract of a research paper in PDF format. 
      Provide its title, authors, year of publication, and a summary 
      of 200 to 400 words. Reply with a JSON structure with the fields 
      "title", "authors", "year_of_publication", "summary". Return 
      only the JSON itself, no Markdown mark-up.'
);

请注意，这个模型定义中甚至包含了我们将要使用的系统提示（system prompt），它精确地指导了LLM如何工作以及返回何种格式的数据。模型创建后，我们就可以通过 ML_PREDICT() 函数来调用它，就像调用任何一个普通的SQL函数一样：

INSERT INTO papers_summarized
SELECT
    fulltext,
    p.title,
    p.authors,
    p.year_of_publication,
    p.summary
FROM
    research_papers,
    LATERAL TABLE(ML_PREDICT('summarization_model', fulltext)) AS p;

一旦这个查询开始运行，每当一篇新论文的文本被推送到 research_papers 主题，papers_summarized 主题就会立刻收到一份结构化的摘要，如下表所示：

fulltext	title	authors	year_of_publication	summary
Styx: Transactional Stateful Functions on ...	Styx: Transactional ...	Kyriakos Psarakis, George Christodoulou,...	2025	This paper introduces Styx, a novel runtime ...
...	...	...	...	...

这个例子仅仅是冰山一角。同样的方法可以应用于情感分析、数据分类、垃圾邮件检测、文本翻译等等，想象空间巨大。

⚡️ 永不眠的哨兵：事件驱动的自主智能

当我们谈论AI智能体时，脑海中浮现的第一个画面往往是基于同步请求-响应模式的对话机器人，比如ChatGPT。然而，在企业环境中，那些默默无闻、由事件驱动的自主智能体往往更具价值。它们基于实时数据流（如网店的用户点击、风力涡轮机的传感器数据、数据库的变更日志）自主采取行动，无需人类干预。

这正是Flink SQL的“甜蜜区”。它拥有庞大的连接器生态系统，可以与几乎所有可以想象到的数据源和目标系统无缝对接。无论是来自Kafka的点击流，还是来自数据库的CDC（Change Data Capture）数据，亦或是通过MQTT传输的传感器读数，Flink都能轻松应对。

将Flink与像Apache Kafka这样的事件流平台结合，更能创造出一个强大的“数字神经网络”。我们可以构建一个由多个专业化、松散耦合的智能体组成的网络。每个智能体完成一项特定任务，其输出可以成为其他智能体的输入，而彼此之间无需关心对方的具体实现细节。Kafka连接并解锁了公司内部的系统、团队和数据库，为智能体提供了做出明智决策所需的所有上下文。

此外，这种架构还有助于克服LLM的一个固有缺陷：知识的“保质期”。LLM的知识受限于其训练数据的截止日期。而通过事件驱动的架构，我们可以实时地将最新的信息注入到后续将要讨论的RAG系统中，从而让智能体的决策总是基于最新、最准确的数据。

什么是事件驱动架构？
这是一种软件设计范式，系统的组件之间通过生产和消费异步的“事件”来进行通信。一个组件（生产者）发布一个事件（例如，“用户下了一个订单”），而其他感兴趣的组件（消费者）会订阅并响应该事件（例如，库存服务减少库存，通知服务发送确认邮件）。这种松散耦合的模式使得系统更具弹性、可扩展性和灵活性。

🧠 赋予智能体记忆与知识：RAG的魔法与SQL的炼金术

通用LLM虽然知识渊博，但它们对你公司内部的“秘密”一无所知。要让AI智能体在企业场景中真正发挥作用，就必须为它们提供访问内部数据、工具和服务的“特权”。这在Flink SQL中如何实现呢？

对于结构化数据，比如存储在外部数据库中的客户信息，SQL是当之无愧的王者。Flink SQL允许你使用强大的 JOIN 语义来丰富发送给LLM的数据。你可以连接来自不同数据源的流，或者使用“查找连接”（look-up joins）来查询那些不经常变化的参考数据（如CRM系统中的客户详情）。Flink会自动处理缓存，以最高效的方式获取数据。

而对于非结构化数据——如内部文档、Wiki页面、客户合同等——检索增强生成（Retrieval-Augmented Generation, RAG）是目前公认的最佳实践。

什么是RAG？
检索增强生成（RAG）是一种将预训练的大语言模型与外部知识库相结合的技术。当需要回答一个问题或生成一段文本时，系统首先从知识库（通常是向量数据库）中检索出最相关的信息片段，然后将这些信息作为额外的上下文，连同原始问题一起提供给LLM。这极大地提高了模型回答的准确性和时效性，因为它能够利用模型训练时未曾见过的最新或专有知识。

让我们回到之前的论文摘要例子，并把它变得更复杂一些。假设我们公司内部也有一个研究Wiki，记录了我们自己的研究成果。我们希望当一篇新的外部论文进来时，智能体不仅能生成摘要，还能识别出它与我们内部研究的关联，从而为未来的研究提供新的视角。

这个任务可以通过一个由两个流式SQL作业组成的智能体系统来完成：

作业一：知识库的实时同步
这个作业负责将我们内部Wiki的知识转化为LLM可以理解的格式。

每当内部Wiki页面发生变化，通过CDC或Webhook等机制捕获变更事件。
使用 ML_PREDICT() 函数和一个嵌入模型（如OpenAI的 text-embedding-3-small），将变更的文本内容转换成向量嵌入（A1）。
将这些新生成的或更新的向量嵌入存储到一个向量数据库（如Pinecone或Elasticsearch）中，确保知识库始终与原始数据保持同步（A2）。

作业二：智能分析代理
这个作业是真正的分析核心。

当一篇新的外部研究论文进入系统，首先像之前一样，使用 ML_PREDICT() 生成其摘要（B1）。
接着，再次使用 ML_PREDICT() 和同一个嵌入模型，为这篇论文的摘要创建一个向量表示（B2）。
使用这个新生成的向量去查询向量数据库，通过余弦相似度等算法，找出与我们内部研究最相关的文档（B3）。这一步目前需要通过自定义函数（UDF）来实现，比如在Confluent Cloud上有一个现成的 VECTOR_SEARCH() 函数。
最后，将检索到的内部研究信息作为增强上下文，连同论文摘要一起，再次调用 ML_PREDICT()，让LLM分析并阐述外部论文与我们内部研究之间的关系（B4）。

到目前为止，我们讨论的还主要停留在“工作流”的范畴。要构建一个真正的“智能体”，可能需要让LLM自己决定在特定情境下调用哪些工具或数据源。Anthropic的MCP（模型上下文协议）标准正为此而生。虽然Flink SQL目前尚未原生支持，但我们可以通过编写自定义函数（UDF），特别是 Flink 2.1 中引入的一种新型UDF——过程表函数（Process Table Functions, PTF）来弥合这一差距。

💾 状态的艺术：为智能体打造可扩展的记忆宫殿

最后，我们来谈谈“记忆”。一个有用的智能体必须能够记住之前的交互。在我们的例子中，这可能是同一作者之前的论文；在推荐场景中，这可能是某位顾客过去所有的购买记录。

虽然Flink SQL能够为窗口聚合或连接等操作管理状态，但SQL本身无法提供构建AI智能体记忆所需的那种细粒度状态访问。然而，前面提到的过程表函数（PTF）再次成为了破局的关键。当我们将PTF应用于一个分区输入流时（例如，按conversation_id或customer_id分区），我们就可以在每个分区的上下文中管理任意的自定义状态。

你可以将与某个特定工作流实例相关的所有事件、消息，甚至之前的LLM响应，都存储在Flink管理的状态中。在构建下一次LLM提示时，再从状态存储中将它们取出。从这个角度看，一个由Flink状态支持的PTF可以被视为一种“持久化执行”（durable execution）的形式，它以一种可恢复、可扩展的方式，追踪着一个长期运行操作的进度。更棒的是，Flink会自动负责在集群中分布和管理这些状态，让你的有状态AI智能体能够轻松扩展到任意数量的计算节点。

🧗‍♀️ 当SQL遇到极限：超越声明式的智能

那么，我们是否应该用Flink SQL来构建所有的AI智能体呢？当然不是。当我们手中的工具是SQL这把“万能锤”时，确实要警惕把所有问题都看成钉子的风险。

对于智能体消费和产生的结构化数据的预处理和后处理——如过滤、转换、连接、聚合——Flink SQL无疑是最佳选择。但当我们需要构建一个拥有更高“自主性”的智能体时，单纯基于SQL的实现可能会变得力不从心。

社区显然也意识到了这一点。最近宣布的 Flink Agents 子项目 (FLIP-531)，一个由Confluent和阿里巴巴的工程师合作提出的项目，旨在为AI智能体创建一个基于Flink的专用运行时。其核心思想是复用Flink久经考验的低延迟连续数据处理基础，并在此之上构建一个易于使用、将AI智能体作为一等公民的框架。该框架计划支持Python，从而让开发者能够利用庞大的Python AI库生态。这不禁让人想起Flink旗下另一个曾经的项目：Stateful Functions (StateFun)，或许它将在AI智能体的浪潮中以新的形式迎来复兴。

结语：一场美丽的邂逅

Apache Flink，凭借其强大的流处理能力和不断演进的AI集成，正成为构建事件驱动智能体系统的一个极具吸引力的多功能平台。尽管在通往真正自主AI智能体的道路上还有一些工作要做（例如原生集成MCP），但它已经为我们提供了连接实时事件流、集成LLM、管理上下文和状态所需的核心工具。

对我而言，使用SQL以声明方式构建智能体系统的最大魅力在于其“民主化”的理念。有了正确的构建块（比如预置好的用于调用工具的UDF），任何熟悉SQL的人——而不仅仅是专业的AI工程师——都能够构建、部署并分享自己的AI解决方案。

所以，回到最初的问题：这个AI智能体，它真的应该是一行SQL查询吗？答案是：不总是，但在很多情况下，这绝对是一个值得认真考虑的、坚实可靠的起点。

参考文献

Morling, G. (2025). This AI Agent Should Have Been a SQL Query. Retrieved from https://www.morling.dev/blog/this-ai-agent-should-have-been-sql-query/
Carbone, P., et al. (2015). Apache Flink: Stream and Batch Processing in a Single Engine. Bulletin of the IEEE Computer Society Technical Committee on Data Engineering.
Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems, 33, 9459-9474.
The Apache Flink Community. FLIP-531: Flink Agents. Apache Software Foundation. Retrieved from the Flink Improvement Proposals archive.
Anthropic. (2024). Building effective agents. Retrieved from Anthropic's official documentation.