AI-工程师必须构建的-30-个智能体-在医疗-金融等领域将大语言模型转化为自主决策垂直领域智能体-一-

AI 工程师必须构建的 30 个智能体：在医疗、金融等领域将大语言模型转化为自主决策垂直领域智能体（一）

原文：30 Agents Every AI Engineer Must Build： Transform LLMs into autonomous decision-making vertical agents in healthcare, finance, and beyond

译者：飞龙

协议：CC BY-NC-SA 4.0

AI 工程师必须构建的 30 个智能体：在医疗、金融等领域将大语言模型转化为自主决策垂直领域智能体

欢迎来到 Packt 早期访问（Early Access）。我们在书籍正式发售前为您提供独家预览。写一本书可能需要几个月，但我们的作者今天就有可以与您分享的前沿信息。早期访问通过提供章节草稿，让您洞察最新进展。目前的章节内容可能略显粗糙，但作者将随时间推移对其进行更新。您可以翻阅这本书，也可以从头到尾阅读；早期访问的设计旨在保持灵活。我们希望您喜欢了解更多编写 Packt 书籍的过程。

1. 第 1 章：Agent 工程基础

2. 第 2 章：Agent 工程师的工具包

3. 第 3 章：Agent 提示词艺术

4. 第 4 章：Agent 部署与负责任开发

5. 第 5 章：基础认知架构

6. 第 6 章：信息检索与知识 Agent

7. 第 7 章：工具操控与编排 Agent

8. 第 8 章：数据分析与推理 Agent

9. 第 9 章：软件开发 Agent

10. 第 10 章：对话与内容创作 Agent

11. 第 11 章：多模态感知 Agent

12. 第 12 章：伦理与可解释 Agent

13. 第 13 章：医疗与科学 Agent

14. 第 14 章：金融与法律领域 Agent

15. 第 15 章：教育与知识 Agent

16. 第 16 章：实体与物理世界 Agent

1 Agent 工程基础

开始之前：加入我们 Discord 上的 GenAI & LLM 社区

在我们的 Discord 服务器上向作者提供反馈，并与其他早期读者聊天。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file0.png

packt.link/4Bbd9

未来属于那些能够利用人工智能的组织，不是将其作为人类智能的替代，而是作为其增强。

— 吴恩达（Andrew Ng），AI 研究员，Coursera 联合创始人

人工智能（AI）正处于一个变革性的边缘，这是由于自主 Agent的出现。它们代表了自从过程化转向面向对象编程以来，计算领域最重要的架构进步——对数字系统运行及其与其环境交互方式的根本性重构。这些 Agent 不仅仅是增强的算法，而是能够感知周围、维持持久状态、对复杂目标进行战略性推理并根据经验调整其行为的认知实体。这种演变的影响远超技术实现细节，它挑战了我们对人类意图与计算行为之间关系的根本观念。

本章为理解 Agent 工程 奠定了概念性基础，将其既视为一门理论学科，也视为一个实战框架。我们探索了从简单的反应式系统到复杂的认知架构的演变轨迹，研究了实现自主行为的结构性组件，并引入了桥接理论原理与生产实现的开发方法论。通过这种探索，我们旨在为您提供一个概念化 Agent 系统的全面框架，并为有效设计、开发和部署它们提供实践见解——无论您是构建自主工作流的软件工程师，还是将智能助手集成到旧系统中的企业架构师，或是探索基于 Agent 的平台如何提供可扩展的客户支持或合规自动化的产品领导者。

这里概述的原则不仅仅是学术的——它们代表了寻求利用基于 Agent 的系统的变革潜力的组织的关键知识。无论是自动化复杂工作流、增强人类能力，还是实现全新类别的应用程序，自主 Agent 正日益成为数字版图中不可或缺的。然而，实现它们的全部潜力通常涉及应对复杂的集成挑战，例如稳健的工具编排、安全的数据隐私和伦理对齐。理解它们的本质和架构要求，为成功实施提供了基础，并通过这些基础可以有效解决这些挑战。

在本章中，我们将涵盖以下主题：

• 介绍 Agent

• Agent 架构

• 互操作性协议

• Agent 开发生命周期

• Agent 交互范式的演进

• Agent AI 演进框架（Agentic AI Progression Framework）

• 现实世界的业务影响

介绍 Agent

我们正处于计算史上的一个关键转折点。从传统软件系统到自主 Agent 的转变代表了场根本性的范式转移，改变了数字系统运行及其与其环境交互的方式。传统程序在显式指令定义的预测路径内运行，而基于 Agent 的系统表现出以目标为引导的行为，维持持久状态，并根据环境反馈调整其策略。这种转变挑战了既有的软件工程原则，并为概念化计算系统的智能引入了新的框架。

传统软件与基于 Agent 的方法之间的区别不仅是语义上的，更是架构上的。传统系统处理离散输入以生成可预测输出，而 Agent 在动态环境中持续运行，形成内部表示，在不确定下做出决策并从经验中学习。对于接受过确定性编程模型训练的从业人员来说，这种转变不仅需要新的技能，还需要对智能系统如何运作和演进进行重新概念。

区分智能 Agent 与传统软件的关键特征包括：

• 自主性（Autonomy）：无需持续人类指导即可运行的能力。

• 持久性（Persistence）：跨交互维持状态和记忆。

• 反应性（Reactivity）：实时响应环境的变化。

• 主动性（Proactiveness）：根据内部目标发起行动，而不仅仅是由于外部触发。

• 适应性（Adaptability）：从经验中学习并相应修改行为。

• 目标导向（Goal-orientation）：在不确定下通过规划和推理追求目标。

在常用用法中，Agent 是采取行动或施加力量的（Merriam-Webster）。在 AI 领域，这个定义演变为一个更技术的构造：AI Agent 是一种感知环境、处理内部状态并采取行动以实现定义目标的计算系统。这些系统表现出自主性、适应性和反应性——这些是区别于传统软件程序的关键属性。Agent 的运行不仅是对输入做出反应，而是通过维持上下文、管理目标并根据反馈调整策略。这种动态行为源于情境人工智能（situated AI）范式，智能源于与环境的持续交互。Franklin 和 Graesser (1997) 概括了这一概念：

自主 Agent 是一个位于环境中并成为环境一部分的系统，它随时间对环境进行感知并采取行动，以追求自己的议程。

这一定义为整合感知、规划、行动和学习的架构奠定了基础。在企业应用中，代理（agents）越来越多地部署为数字员工——处理客户入职、处理发票、管理工作流——每个代理都具有持久状态、内存和反馈机制。AI 代理的发展史可以分为不同的技术时代：

• 1970s–1980s：基于规则的专家系统，例如MYCIN（斯坦福大学开发的一种用于诊断血液感染和推荐抗生素的系统），使用基于逻辑的推理引擎来解决定义狭义的问题。尽管具有确定性的精度，但这些系统是脆弱且缺乏灵活性的。

• 1990s：决策树和SVMs等经典机器学习方法引入了模式识别能力。虽然比规则系统更具适应性，但它们仍然是特定任务的且无状态的。

• 2010s：深度学习彻底改变了数据感知。语音识别、图像分析和翻译达到了人类水平。然而，这些模型在很大程度上是响应式的，设计用于输入输出预测，而非自主行为。

• 2020s 及以后：大语言模型（LLMs——在海量文本数据集上训练以理解和生成人类语言的 AI 系统）以及transformers（擅长处理顺序数据的神经网络架构）的出现，引入了涌现推理、自然语言生成和少样本学习。然而，早期的LLMs受限于上下文大小、缺乏内存和工具集成。

虽然 AI 领域的许多最新进展——例如检索增强生成（RAG）、外部工具使用、API 编排和内存系统——其本身具有至关重要的作用，但它们也是构建更强大的自主代理的关键赋能者。诸如LangGraph、CrewAI和AutoGen等框架支持规划、决策和实时交互，使代理能够在开放式环境中完成多步目标。例如，在客户支持领域，这种演变是巨大的：

• 2010：静态 FAQ 脚本为常见问题提供预定义的答复，任何偏离都需要人工干预。

• 2018：基于机器学习的工单路由系统可以分类并将支持请求分配给相应部门，但仍需人工解决。

• 2025：先进的多代理系统现在在生产部署中已显示出 70-85% 的解决率（基于 Zendesk、Intercom 和 ServiceNow 等公司的实现），集成了用于自然对话的LLMs、用于个性化上下文的账户系统以及当前信息的实时知识库。

这种演进轨迹（图 1.1 所示）强调了传统 AI 应用与真正的自主代理系统之间根本的架构和哲学区别——这些差异远超技术实现，延伸到这些系统运行、学习以及与环境交互的方式。这些架构转变不仅是学术上的——它们转化为可衡量的业务成果，如降低支持成本、提高首次接触解决率、更快的入职以及跨客户触点的扩展扩展性。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file1.png

图 1.1 – AI 代理技术的演进

在追踪了 AI 代理从基于规则系统到今天复杂的自主实体的历史演变后，我们现在转向研究这种智能行为的结构基础。理解代理是如何构建的——认知循环、通信模式以及将计算系统转换为目标导向实体的设计选择——对于构建有效的代理解决方案至关重要。

代理的架构

智能代理的架构设计标志着从过程化逻辑向认知驱动计算的根本转变。与响应定义输入而执行静态指令的传统软件系统不同，代理在动态环境中持续运行，做出实时决策，维持持久内存并随着时间调整其策略。核心在于，代理的架构必须将关键认知功能——感知、推理、规划、行动和学习集成到一个模块化的、有状态的框架中，该框架同时支持响应和深思。这通常从已有的 AI 范式中汲取灵感：例如BDI（信念-愿望-意图）等模型为代理管理其对世界的信念、愿望（目标）和意图（选定的计划）提供了一个框架。同样，将符号推理（处理显式知识和逻辑规则，通常用于规划和决策）与神经网络（擅长模式识别和从数据中学习）相结合的混合方法，使代理形成稳健的内部表示，对复杂目标进行有效推理，并在追求长期目标的过程中协调复杂的工具使用。在实践中，这意味着设计分离关注点的系统：感知模块与传感器或 API 接口；规划引擎分解目标；内存子系统管理历史和语义上下文；执行层与工具、服务或其他代理接口。诸如LangGraph和CrewAI等框架通过提供可组合的运行时环境实现了这些原则，代理可以在这些环境中跨会话维护状态、使用图编排工作流并自主运行。这种架构的凝聚力是将代理从响应式机器人转变为能够应对开放现实世界复杂的智能系统的关键。为了理解这种架构愿景如何转化为实际实现，我们检查了三个基础要素：驱动代理决策的认知循环、实现组件间无缝交互的通信模式，以及决定代理如何将感知转化为行动的设计模式。

认知循环

智能代理的认知架构定义了感知如何通过结构化、可重复的过程转化为有目的的行动。这种设计的内核是认知循环（cognitive loop）——感知、推理、规划、行动和学习的持续循环——它使代理能够在动态环境中运行。正如图 1.2 所示，这个循环形成了智能代理行为的骨干，提供了做出决策、执行行动以及随时间积累知识的支架。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file2.png

图 1.2 – 智能代理的认知架构

为了理解这种架构在实践中如何运作，让我们详细探索认知循环的每个阶段——从感知开始，这是塑造后续所有步骤的关键第一步：

1. 感知通过从环境中捕获数据（无论是通过用户输入、API、传感器还是外部系统）并将其转换为适合处理的结构化格式启动循环。这些原始输入形成了后续认知步骤的基础，并决定了代理情境感知范围。

## Example：客户服务代理中的感知
def perceive_input(user_message, context):
    return {
        "message": user_message,
        "timestamp": datetime.now(),
        "user_id": context.get("user_id"),
        "session_state": context.get("session"),
        "sentiment": analyze_sentiment(user_message)
    }

1. 推理

Reasoning 随后通过对感知到的信息进行上下文化，应用模式识别、推理引擎或统计模型来提取含义和相关性。这一阶段将信号转化为洞察，使代理不仅能够理解发生了什么，还能理解其重要性。

# Example: Reasoning about customer intent
def reason_about_intent(perception_data):
    intent = classify_intent(perception_data["message"])
    priority = determine_priority(
        intent,
        perception_data["sentiment"],
        user_history=get_user_history(perception_data["user_id"])
    )
    return {"intent": intent, "priority": priority, "context": perception_data}

2. 规划

Planning 将这些洞察协调成连贯的操作序列。无论是使用确定性规则链还是概率模型，代理都会将目标分解为任务，评估选项，并根据预定义的目标和环境条件对步骤进行排序。

## Example: Planning response strategy
def create_action_plan(reasoning_result):
    if reasoning_result["intent"] == "billing_issue":
        return [
            "fetch_account_details",
            "analyze_billing_history",
            "generate_explanation",
            "offer_resolution"
        ]
    elif reasoning_result["priority"] == "urgent":
        return ["escalate_to_human", "log_urgent_case"]

3. 行动

Action 随后执行选定的步骤，与外部工具、API、数据库或系统接口，以使代理的决策落地。这一阶段通常使用函数调用框架或工具编排层来实现，如在LangChain或LangGraph中发现的层。

## Example: Action execution
def execute_action(action_plan, context):
    results = []
    for action in action_plan:
        if action == "fetch_account_details":
            result = billing_api.get_account(context["user_id"])
        elif action == "generate_explanation":
            result = llm.generate_response(context, results)
        results.append(result)
    return results

4. 学习

Learning 通过分析结果、衡量操作的成功率以及更新内部模型或存储器来完成闭环。这种反馈机制允许代理随着时间的推移完善其行为，根据成功和失败改进性能。

## Example: Learning from interaction
def learn_from_outcome(interaction_data, user_feedback):
    success_score = calculate_success(user_feedback)
    update_user_preferences(interaction_data["user_id"], success_score)
    if success_score < 0.7:
        flag_for_model_improvement(interaction_data)

如图 1.2所示，这些阶段形成了一个反馈驱动的系统，而不是线性流水线。每个组件相互影响并受彼此影响，使代理能够适应新数据、不可预见的情况和不断演的目标。在实践中，这种架构支持广泛的应用，从根据先前的交互定制响应的客户参与代理，到根据不断变化的约束持续调整运营的供应链代理。这种模块化但相互依赖的结构——感知导致理解，规划导致执行，学习完成闭环——是让代理从自动化脚本提升为智能自适应系统的关键。理解这种架构对于设计能够处理长周期目标、上下文决策和现实世界自主性的代理至关重要。

组件之间的通信模式

一个智能代理的定义不仅取决于其推理引擎的复杂性或输出的准确性，还取决于绑定其内部组件的通信路径的完整性。这些路径（在图 1.3中所示）构成了认的神经系统，将分散的子系统转化为统一的、自适应智能。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file3.png

图 1.3 – 代理认知架构中的通信模式

该架构的核心是认知核心（Cognition Core），它是执行协调器，负责综合来自其他模块的输入、解决冲突、协调操作并维护代理状态的一致性。每个主要功能——推理、规划、内存和交互都通过这个核心进行调节，它的作用与其说是一个中央命令，不如说是一个任务相关的动态经纪人。

在现实部署中，这种中心角色可能会引发单点故障的担忧。健壮的实现通常通过冗余、分布式协调层和健康检查机制来解决这些问题，确保Cognition Core能够从崩溃、负载或组件退化中恢复。某些框架实现了备用节点、心跳信号或云原生编排，以保证生产环境中的可用性和响应速度。

核心周围环绕着五个基础通信层，每层代表一个不同的功能角色：

• 画像/人设（Profile/Persona）：这一层定义了代理的性格——其语气、行为约束以及与用户意图的系统级对齐。在实现方面，这可能以系统提示词或角色模板的形式存在，作为初始化边界，告知代理如何解释歧义、执行护栏以及与用户通信。值得注意的是，这一层不是静态的；它会响应不断变化的上下文，并可以在运行时更新以反映受众、任务或伦理参数的变化。

• 工具使用/操作接口（Tool Use/Action Interface）：将代理的内部思考与外部世界连接起来。推理意图在此转化为工具调用、API 调用或系统命令。该通道处理操作的分发和结果的解释，将执行反馈回认知循环。在生产系统中，这通常是对延迟最敏感的组件，需要健壮的错误处理、重试逻辑和可观测性流水线。

• 规划/反馈（Planning/Feedback）：该模块提供前瞻性策略和回顾性修正。目标被分解为任务图，根据约束进行优先级排序，并监控成功或失败。当结果偏离预期时（例如，预订失败或 API 超时），此层会触发重新规划。这种反馈循环对于长周期自主性至关重要，通常使用LangGraph等框架进行编排。

• 知识/内存（Knowledge/Memory）：这一层是代理的时间基质。它包含短期工作内存、长期知识存储和情节回溯系统。这些组件允许代理基于历史落实行为、召回之前的任务、复用上下文约束，并随时间提供连贯的行为。在架构上，内存是异步访问的，使代理在后台检索深度上下文的同时保持实时响应能力。为了最小化延迟并确保一致的实时响应，生产级代理通常对频繁访问的知识（例如用户配置文件或近期交互）采用缓存策略，以及向量索引预取或近似最近邻（ANN）搜索技术。此外，内存系统可能会实施生存时间（TTL）缓存、请求批处理和分层内存（例如短期与长期），以平衡上下文检索的深度与速度。

• 推理/评估：这些组件在策略性地分布在Figure 1.3的边缘，以提供多个验证检查点和专业的评估能力。许多系统并不依赖单一的推理引擎，而是将评估分布在多个专门的验证器上——例如，安全检查器、事实准确性审计器或领域特定评审员。这种分布式方法通过多层验证确保了鲁棒性，并允许对不同的推理任务进行并行处理。这些推理模块与认知核心交换结构化消息，支持如自反思、置信度评分和迭代输出优化等机制。

总体来看，这些通信层不仅仅是一个功能性方案——它们代表了一种模块化、可组合的哲学。Figure 1.3中的双向流和虚线回调强调了认知不是线性的，而是循环的、反射的且反馈驱动的。随着条件的改变，记忆影响规划，评估重定向行动，而人格塑造了理解。这种网络化的相互依赖确保了智能体能够适应复杂的动态环境，而不会丢失连贯性或目标对齐。健壮的通信设计还支持工程优先事项：模块化允许团队并行构建组件；可观测性有助于调试和信任，通常在智能体生态系统中使用Prometheus、Grafana或LangSmith等工具跟踪智能体状态、操作成功率、延迟和错误事件；关注点分离则促进了扩展性和可测试性。此外，通过将推理与执行分离、将状态与策略分离，智能体系统获得了应对不确定性和部分故障的韧性——使其适用于企业自动化、自适应学习、客户服务等真实世界的部署。最终，定义智能体智能的不仅是它知道什么或做了什么，而是其内部系统之间交流得有多好。组件之间的通信是认知成型的地方——它不是逻辑的独白，而是目的的对话。

选择智能体大脑：从感知到行动的模式

决定智能体如何将感知转化为行动的架构定义其智能的核心。这种perception-to-action循环——无论是反射的还是推理的——决定了智能体如何与环境交互、处理不确定性，并平衡时效与策略。与遵循固定逻辑路径的传统软件系统不同，自主智能体需要支持灵活、上下文感知决策的认知支架。选择“智能体大脑”——其推理模式——不仅仅是一个实现细节，而是一种塑造长期性能、适应性和系统行为的结构性承诺。

智能体设计模式可以分为三种主流范式，每种范式代表了建模智能行为的不同方法：反应式、思考性和混合式。这些模式并不是相互排斥的；它们为开发者提供了一个设计调色板，将认知结构与特定任务的需求、用户预期和操作环境对齐。理解这些模式对于构建在现实条件下能够可靠运行的系统至关重要。部署在面向客户的工作流中的智能体可能依赖反应模型进行低延迟交互，而知识密集型系统则需要深思考以确保上下文的准确性和合规性。在两者都需要领域（例如企业自动化或医疗诊断），混合模型提供了一条极具韧性的中间路径。接下来的章节将深入探讨每种模式，根据架构权衡、环境复杂性和智能体目标提供何时以及如何应用它们的指导。

反应式智能体：反射性响应

反应式智能体代表了最简单、最直接的智能系统。这些智能体通过直接的刺激-响应机制运行，将环境输入映射到预定义的动作，而不维护内部状态或参与高阶推理。它们的设计灵感来自反射行为的概念——快速、自动的响应，为了效率和可预测性而跳过思考。

为了理解反应行为的本质，考虑恒温器。当温度下降到阈值以下时，它会立即激活加热系统。它不会评估趋势、考虑外部天气数据，或为了能源效率进行优化。相反，它根据单一规则运行：如果温度低，就打开加热。这种感知与动作的直接耦合是管理反应式智能体的核心原理。

这些智能体无状态且无记忆。每个决策都完全基于当前的感官输入，不参考过去的观察或积累的知识。这种内部状态的缺失使得反应式智能体极其快速且计算高效，使其能够在延迟不可接受的环境中实现实时响应。如车辆中的防抱锁制动机制或火灾报警器系统说明了即时性的价值——对环境中的关键变化毫不犹豫地做出反应。

在实现方面，反应式智能体依赖于简单的条件-动作规则。这些规则被持续评估，当满足特定的环境条件时，就会触发相应的动作：

IF stimulus_1 detected THEN execute action_1
IF stimulus_2 detected THEN execute action_2

这种极简的架构导致了高度确定性的行为，这在需要在严格的操作限制下保持稳健性能的场景中是一个巨大的优势。当然，反应式智能体的简单性是有代价的。它们缺乏记忆、学习或预见能力。它们无法在规则集之外进行泛化，也无法在复杂的部分观测环境中进行提前规划。当遇到不符合其预定义条件的未知情况时，它们的性能会下降，且在没有外部修改的情况下无法适应。例如，反应式灭火系统可能会由于烹饪产生的蒸汽而反复激活，在没有额外上下文或学习机制的情况下无法区分火灾和虚假报警。

尽管有这些局限性，反应式智能体在各行业中得到了广泛应用。在机器人领域，简单的碰撞传感器允许移动智能体在不需要映射或定位的情况下避开障碍。在智能家居系统中，恒温器、运动感应灯和烟雾检测器等设备依赖于反应原理。在游戏中，非玩家角色通常采用简单的基于规则的行为来创造智能幻觉，同时保持性能效率。应急系统也经常采用反应式逻辑，在突破关键阈值时执行快速关闭或警报。

尽管如此，它们的确定性本质使其在条件定义良好且延迟成本高的场景中异常可靠。虽然反应式智能体处于智能架构层级结构的最底层，但它们是构建更高级智能体模型的基础基石。在许多实际应用中，它们的速度、简单性和稳健性不仅是够用的，而且是最优的。

思考型智能体：战略思考者

审慎代理体体现了一种根植于远见、规划和结构化推理的智能行为模型。与对刺激做出即时反应的反应代理不同，审慎代理体在决定行动方案之前会停顿、分析环境并预测潜在结果。它们的架构遵循Sense–Model–Plan–Act（SMPA）范式，使其能够进行策略性操作而非冲动行为。

审慎代理体设计的核心是使用内部世界模型——一种对环境和目标动态更新的表示。这种内部状态允许代理体不仅对当前刺激做出反应，还能对未来的可能性进行推理并相应制定计划。如Figure 1.4所示，这种范式通过 AI 驱动的旅行助手示例得到了展示。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file4.png

图 1.4 – 审慎代理体

审慎决策循环

过程始于感知，代理体感知其环境或接收输入。在图中，该输入以自然语言指令的形式出现：“我想下个月去东京。”这标志着一个复杂的决策循环的起点。代理体并没有立即反应，而是过渡到建模阶段，将用户输入解析为结构化数据。如目的地（“东京”）和时间范围（next month）等关键元素被提取并存储。某些偏好被标记为未知或待定，表明代理体必须在该领域寻求澄清或推断默认值。

接下来，代理体进入规划阶段。根据其内部状态和用户意图，它将高级目标分解为可执行的步骤。如图所示，代理体识别出搜索航班、验证签证要求以及建议酒店选项的需求。每个子任务都构建在一个更大的策略框架内，允许代理体评估各种路径，并选择既满足约束又符合目标的最佳行动序列。

最后，代理体执行操作。这一执行步骤并非盲目触发，而是审慎计算的结果。代理体查询 API——例如，通过 Skyscanner 获取航班选项、检查签证政策并提供个性化的酒店建议。这些行动是推理过程的结晶，而不仅仅是对提示的反应。

生产与安全

在生产环境中，这些输出通常受监控和验证流水线的约束，以确保它们是准确、合规且安全的。通常会采用输出过滤、事后验证模型和护栏（guardrails）等技术，在结果呈现给用户或下游系统之前检测幻觉或违反策略的行为。

优势与局限性

这种策略架构提供了许多优势。审慎代理体可以处理时间推理、模拟未来状态，并通过生成新的解决方案而非依赖预定义的规则来适应新情况。因此，它们在需要复杂多步决策的领域具有极高价值。应用包括车辆自动导航、财务规划工具、智能个人助手以及协调复杂组装序列的制造机器人。

在现实部署中，这些代理体通常配备了回退策略——例如默认的规则程序、到人工操作员的升级协议或简单的决策树——以处理规划失败或环境中的不确定性。这些安全措施确保了即使在策略计算崩溃时也能实现降级运行和持续的服务。

然而，这些能力引入了某些局限性。维护和更新内部模型需要大量的计算资源，规划阶段会引入延迟。如果代理体的内部模型准确不完整，其决策可能会下降；在某些边缘情况下，当面对超出其训练或假设的未知场景时，它可能会完全失败。

尽管如此，在决策质量高于即时性的背景下，审慎代理体的表现始终优于简单的架构。Figure 1.4中的示例说明了这些代理体如何整合感知、记忆、推理和执行，以跨多个子系统提供协调的响应。这使得审慎代理体在任何需要智能、自适应且目标一致的行为之处都是不可或缺的。

混合代理体：行动的分层智能

混合代理体代表了一类智能系统，它们将反应行为的快速响应能力与审慎推理的策略远见相结合。混合代理体不依赖于单一决策模型，而是采用分层架构，不同的子系统专门负责快速且独立上下文的响应或较慢的以目标为导向的规划。Figure 1.5显示了一个典型的混合架构，输入刺激同时通过反应和审慎处理层。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file5.png

图 1.5 – 混合代理体

输入最初通过优先级分类机制进行处理和紧急性评估，该机制会评估时间限制、安全影响和任务关键性等因素。时间敏感型事件被直接路由到橙色所示的反应层，该层通过预定义的刺激-响应映射执行动作。这能够实现诸如避障、安全关或告警处理等即时行为。

在工程实践中，这种路由逻辑通常使用异步模式实现，事件总线（如Kafka、NATS）或消息队列（如RabbitMQ、AWS SQS），这允许代理将输入分类与响应执行解耦，同时在负载下确保可靠的交付和优先级排序。

与此同时，表现为蓝色的深思层从战略角度监控环境。它维护了关于目标、状态信息和资源限制的内部模型。该层负责高阶推理任务，如路径规划、多步执行、未来状态预测以及跨时间范围的优化。它可以通过调整阈值、修改程序或根据持续评估引入新目标，来影响或覆盖反应层的行为。

至关重要的是，这些层之间的通信是双向的。考虑一个正在导航投送包裹的仓库机器人：当机器人遇到意外障碍物（如掉落的箱子）时，其反应层会停止移动并启动避障动作。同时，这种障碍检测会触发到深思层的中断，深思层重新评估最佳投送路线，更新其内部地图，并在障碍物代表持续阻塞时可能决定请求人工协助。在此期间，深思层持续更新上下文信息——例如投送优先级或电池电量——这些信息会告知反应系统的参数，可能会根据紧急程度或剩余电量调整移动速度。Figure 1.5通过反馈箭头和在此类动态情境下激活的虚线路径强调了这些相互作用。

这种架构支持一种协调的输出机制，平衡了快速决策与长期目标之间的关系。最终动作作为一种协商的结果产生，通常根据当前的运行上下文从两个层综合得出。仓库机器人的示例展示了反应性避障如何与深思性路由优化并行运行，创建既安全又高效的无缝导航。

存在不同的实现模型来实现混合行为。基于抑制的系统可能将反应控制置于核心，并由战略规划层增强。其他设计使用仲裁机制，多个子系统提出动作，由控制模块根据优先级和环境条件选择最合适的动作。黑板架构（一种不同推理组件向公共工作空间贡献知识的共享内存系统）通过使用共享内存存储库进一步支持混合化，每个层都为集体决策空间做出贡献。

混合代理在需要灵活性的复杂环境中特别有效。在工业机器人领域，它们协调了即时停止机制与生产调度。在自动驾驶车辆中，它们在进行导航规划的同时管理避障。在网络安全中，新兴的混合代理模型旨在阻止实时威胁的同时评估更长期系统完整性——尽管大多数目前的实现侧重于基于规则的检测，自适应协调有限。混合方法代表了迈向动态、自我调节防御的下一步。智能助手也受益于这种模型，在提供即时用户响应的同时，保持上下文的连续性和任务记忆。

在这些场景中，性能限制通常是不可逾越的：机器人和自动驾驶车辆中，响应延迟必须保持在100 ms以内以避免安全风险，而网络安全代理必须在毫秒内检测并处理威胁以防止被利用。即使是智能助手也面临各种限制，例如在内存限制下维持会话一致性，以及在实时对话中平衡准确性与速度。

混合架构的模块化本质也支持维护性和可扩展性。每一层都可以独立地设计、测试和更新。然而，这种灵活性也引入了复杂性。层之间的协调需要仔细的资源分配、冲突解决协议和大量的测试，以确保在各种运行条件下行为稳定。调试混合系统可能具有挑战性，因为问题可能源于层交互而非单个组件。此外，维护多个推理系统的开销可能会影响性能并增加计算成本。

如Figure 1.5所示，混合代理代表了反应效率与深思深度的平衡。分层结构使系统在不牺牲结构化推理能力的情况下迅速行动——这是现代 AI 部署中的一项基本能力。在探索了使单个代理感知、推理和行动的基础架构后，我们现在转向使这些智能系统协同工作并与现有企业基础设施无缝集成的关键挑战。

互操作性协议

随着代理系统从孤立工具演变为分布式生态系统，它们与外部服务以及同类代理互操作的能力变得至关重要。Interoperability protocols通过为通信、委托和协调提供清晰的、合约驱动的接口，成为可扩展、模块化代理架构的基础。这些协议将代理与特定工具的逻辑解耦，支持异步编排，并允许分布式组件之间进行协作决策——即使这些组件是独立开发或维护的。

本节探讨了支撑代理互操作的两个基础协议类别：

• Model Context Protocol (MCP)：标准化了代理与工具、API 和数据源的交互。与其将特定工具的逻辑硬编码到每个代理中，MCP定义了一个通用接口层，允许代理动态地发现、评估和调用外部服务。工具通过元数据和能力定义进行注册，代理使用这些定义在运行时查询可用操作。这种抽象使得在不修改代理逻辑的情况下更换或升级工具成为可能。

• Agent-to-Agent (A2A) Protocols：定义了去中心系统中协作代理之间的消息传递接口。这些协议规定了代理如何通信意图、共享状态、交换角色以及同步任务进度。A2A 协议在多代理环境中特别重要，在这些环境中协调必须在没有中央控制的情况下进行。

这些协议共同构建了动态、可插拔且具韧性的系统，能够在跨能力和组织边界进行扩展。在真实的生产系统中，versioning and schema management对于确保长期稳定性至关重要。MCP和A2A等协议通常依赖于contract-based designs，使用OpenAPI规范、Protocol Buffers或JSON Schema等技术来定义消息格式和服务能力。对这些契约进行显式版本控制允许系统保持向后兼容，在代理与服务之间协商能力，并优雅地处理更新引起的不匹配。这确保了新版本的代理可以与旧组件及外部 API 安全地交互——这对于随着时间推移维护健壮且演化的系统至关重要。

模型上下文协议（MCP）

MCP定义了一个通用框架，代理通过该框架发现、评估并调用外部能力。如图 1.6 所示，MCP引入了一个universal interface layer来抽象外部服务，通过三个关键操作将其暴露：

• 能力描述：每个工具都以机器可读的格式注册其功能和元数据（输入、输出、约束）。例如，一个简单的JSON schema可以定义天气检索工具的能力：

工具发现与调用

代理通过查询通用层，根据当前任务需求和能力元数据来识别合适的工具。具体流程包括：

• 发现：代理查询通用层，根据当前任务需求和能力元数据识别合适的工具。

• 调用：一旦选定工具，代理通过标准化协议调用它，而无需特定工具的集成。

{
  "name": "SearchFlights",
  "description": "Retrieve available flight options based on input parameters",
  "input_schema": {
    "type": "object",
    "properties": {
      "origin": { "type": "string" },
      "destination": { "type": "string" },
      "departure_date": { "type": "string", "format": "date" }
    },
    "required": ["origin", "destination", "departure_date"]
  },
  "output_schema": {
    "type": "array",
    "items": {
      "type": "object",
      "properties": {
        "airline": { "type": "string" },
        "price": { "type": "number" },
        "duration": { "type": "string" }
      }
    }
  }
}

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file6.png

Figure 1.6 – 模型上下文协议

这种架构使得代理能够独立于硬编码的服务逻辑运行，实现了即插即用的集成。可以动态引入新工具，并在不影响代理核心逻辑的情况下更新旧工具。例如，执行产品研究的代理可以查询市场数据 API、评估情感分析器或调用摘要引擎——所有操作都通过同一种接口模式实现。MCP 还促进了跨代理的工具复用，确保工具注册不会在代理网络中重复。这创建了全组织范围的能力注册表，促进了标准化、治理和更快的集成周期。

代理到代理 (A2A) 协议

虽然 MCP 管理的是代理与服务之间的垂直交互，但 A2A 协议促进了对等之间的协作。这些协议格式化了在共享环境中运行的代理之间的消息交换，它们能够共享状态、分配角色并异步协调任务。在设计此类系统时，考虑各种一致性模型（例如强一致性、最终一致性）至关重要，以确保共享状态在代理之间得到适当同步，平衡数据完整性与性能需求。如图 1.7 所示，代理使用包含以下内容的结构化消息包进行通信：

• 状态 (State)：包含代理共享的上下文数据和中间结果，以维持团队的情境感知。

• 角色 (Role)：包含功能性定义和职责，定义了每个代理在协作工作流中的位置和能力。

• 状态 (Status)：包含生命周期更新，包括成功、失败或就绪指示，让所有代理了解任务进度和系统健康。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file7.png

Figure 1.7 – 代理到代理协议

这种架构允许代理团队：

• 分配专门任务（例如研究、验证、质量保证）。

• 在保持协调的同时进行异步操作。

• 通过动态向备份代理分配角色来从故障中恢复。

例如，在客户服务自动化流水线中，分拣代理可能会将订单传递给账单专家，后者随后将案件转发给合规性验证器。这些交互在没有中心化编排的情况下发生——代理使用共享协议规则做出局部决策，促进了容错性、并行性和自愈工作流。诸如 CrewAI 和 LangGraph 等框架提供了对 A2A 模式的原支持，通过基于 Actor 模型、状态通道和发布/订阅消息实现结构化交互。流行的开源系统如 NATS、RabbitMQ 和 Apache Kafka 通常用于实现这些消息层，实现分布式代理之间可靠且可扩展的通信。在建立了对代理架构和通信协议的稳固理解后，我们现在检查通过结构化开发方法论将这些智能系统从概念推向生产的实际过程。

代理开发生命周期

自主代理的发展遵循一个结构化的迭代生命周期，这作为一个路线图——但它从根本上区别于传统的软件工程实践。与依赖静态逻辑和预定义行为的过程系统不同，智能代理必须在动态、不确定的环境中运行。它们解释模糊的输入，在不确定的情况下做出决策，调用外部工具并通过反馈不断完善其行为。这些演化的、目标导向的行为需要不仅是迭代的，而且是深度适应的生命周期模型——支持推理、学习、记忆和编排。代理开发生命周期（ADL）的设计是为了满足这一需求，提供了一个镜像现代基于代理系统操作复杂性的灵活框架。本节概述了 ADL——一个从早期概念化到部署后完善的实用框架。它为开发者和组织构建健壮、目标导向且随时间不断改进的代理系统提供了路线图。

接下来的子章节将详细探讨该生命周期的每个阶段，研究代理开发与传统软件工程方法不同的独特考虑和最佳实践。

概念化与需求分析

智能体（Agent）开发始于定义问题空间并在上下文中阐述智能体的目标。这不仅仅是需求收集——它是一种对认知负荷的建模练习，意味着智能体为了智能运行而必须模拟或管理的心理过程。这包括跟踪用户意图、解释环境信号、选择合适的策略以及根据反馈更新计划——这些功能在传统上与人类认知相关。开发者必须分析特定领域，理解用户意图，并评估智能体有效运行所需的能力。与静态应用程序不同，智能体的目标可能会发生演变，并且必须具有足够的灵活性，以适应环境变化和新出现的需求。

在这一阶段，开发者会识别运行环境，将目标映射为可实现的子目标，并确定伦理、技术和操作边界。例如，一个协助合规的智能体可能需要对行为进行显式约束，这些约束既被编码到规则中，又在执行期间受到监控。重要的是，此阶段还包括评估成功指标——性能、对齐和用户信任——所有这些指标都指导未来架构和实施的决策。总而言之，概念化阶段的关键活动包括：

• 定义清晰的高层级智能体目标。

• 将这些目标映射为可实现的子目标或任务。

• 设定可衡量的成功指标（例如：性能、对齐、用户信任）以指导开发和评估。

架构与设计

一旦目标界定清楚范围，就会设计智能体的内部架构来支持这些目标。正如在 Architecture of agents 部分讨论的，这包括在认知模型之间进行选择——例如 ReAct、plan-and-execute 或 BDI——并指定负责感知、计划、行动和学习的组件。架构必须在模块化、自主性和扩展性之间取得平衡。在此阶段，智能体设计师定义内存策略（短期、长期、事件性）、内部通信流以及与外部系统的交互点。同样重要的是，他们确保智能体能够通过既定协议进行互操作，并在会话之间持久化状态。安全和防护机制从一开始就被集成，而不是事后考虑。这一设计阶段形成了整个系统的概念和技术骨干。为了确保可追溯性和信息化迭代，许多团队采用架构决策记录（ADRs）来记录关键设计决策——例如选择特定内存模型、编排策略或协议框架的原因。这有助于未来的贡献者理解权衡，重新审视过去的假设，并在不丢失组织知识的情况下演进智能体架构。

实现与集成

实现阶段使用 LangChain、CrewAI 或 LangGraph 等开发框架使架构恢复活力。开发者构建用于推理、感知、计划和内存的模块，并通过工作流图或事件驱动引擎将它们绑定。函数调用 API、内存数据库和编排层通过开源工具链缝合在一起。这里的重点是内聚性和正确性——模块必须以可预测的方式交互，智能体的行为必须符合定义的目标。开发者运行本地模拟或分阶段部署，以测试负载下认知组件的交互。正是在此时，真实世界的约束开始显现——延迟、上下文限制、token 使用率——并需要工程权衡来平衡能力与成本。为了支持稳健迭代，团队通常将智能体行为测试集成到 CI/CD 流水线中。这些流水线使用自动化测试框架、合成提示词和模拟失败案例来验证认知工作流（例如推理链、工具调用、内存使用），确保跨部署的稳定性并尽早发现回归。

评估与优化

在测试或受控环境中部署后，必须对智能体进行严格评估。与传统系统不同，成功并非总是二元的。性能指标包括任务完成率、决策质量和在模糊情况下的稳健性。评估可能涉及合成环境或生产影子，并配有完善的日志记录和遥测管道。来自内部反思机制的反馈（如信心评分或批判循环）与用户满意度和工具性能等外部信号相结合。这些见解反馈回架构，实现自适应更改。此阶段的优化可能包括完善计划深度、调整上下文窗口策略或提高内存相关性评分。典型的优化指标包括任务成功率、平均响应时间、用户满意度评分、工具调用延迟和回退频率（智能体延迟或失败的频率）。跟踪这些指标允许团队根据性能和用户信任信号迭代改进智能体质量。

治理与生命周期管理

部署不是智能体开发的结束，而是持续改进循环的开始。生命周期管理包括主动监控、日志审计、模型更新和故障恢复。治理还涵盖了安全补丁、合规审计和伦理监督——确保智能体保持可靠、透明并符合人类意图。此阶段涵盖监控和迭代改进过程。大规模部署的智能体必须支持可观测性和应急响应。诸如 LangSmith 或 Prometheus 等工具提供了对智能体性能和健康的实时洞察。此外，模型重训、版本控制和回滚策略确保系统更改是经过深思熟虑且可恢复的。基于性能数据、用户反馈和不断变化的需求持续迭代，确保了智能体在其运行生命周期内演进和改进。这对于金融、法律或医疗等任务关键领域至关重要，意外的行为可能会产生严重后果。例如，LangSmith 或 Prometheus 的日志可能会显示工具调用成功率下降或幻觉输出增加。这可以触发告警、启动人工审查，并导致提示词设计、微调甚至底层模型重训的调整。纳入这种循环——从可观测性到审计到重训——对于构建生产环境中韧性的智能体至关重要。

交互范式的演进

随着 AI 系统日益融入我们的日常生活和企业工作流，理解智能体交互的级别对于设计稳健、可扩展且智能的架构变得至关重要。这些级别代表了智能体能力的演进——从基础的提示响应交互到协作的分布式智能体网络。五级交互范式框架为沿三个关键维度分析智能体设计提供了一种结构化方法：操作自主性、上下文感知和决策权限。它帮助系统架构师、开发者和利益相关者就哪种智能体架构最适合其用例做出明智决策。以下五个模型说明了这种演进，每个模型都基于一个代表性图形，并由其交互模式、处理能力和架构复杂度定义。为了帮助系统设计师快速评估和比较不同层级的智能体复杂度，下表在自主性、上下文感知和决策权限等关键维度上总结了五种智能体交互范式。

| 级别 | 代理类型 | 操作自主性 | 上下文感知 | 决策权限 | 典型用例 |

| :--- | :--- | :--- | :--- | :--- | :--- |

| 1 | 直接 LLM 交互 | 无状态 / 无 | 无 | 人类主导 | 一次性问答、创意生成 |

| 2 | 代理代理 (Proxy Agent) | 低 | 轻量级上下文化 | 基于指令 | API 参数化、语义翻译 |

| 3 | 助手系统 | 中等 | 基于会话 | 用户引导 | 数字化助手、工具增强型聊天 |

| 4 | 自主代理 | 高 | 持久化内存 | 部分自主 | 任务规划、研究助手 |

| 5 | 多代理系统 (MAS) | 极高 | 共享 + 分布式 | 分布式自主性 | 供应链、编排、仿真 |

表 1.1 – 跨关键架构维度的智能体交互范式对比

直接 LLM 交互：无状态的对话者

这一基础层代表了代理参与的最基本形式，用户通过自然语言提示直接与 LLM 交互。这些交互是无状态的，没有对之前输入的记忆，且跨轮对话没有持久上下文。如 Figure 1.9 所示，用户输入类似“加拿大的首都是？”的查询，LLM 立即回答“渥特华”。图表通过禁止图标强调了内存的缺失，表明模型孤立地处理每个提示。它没有内部上下文跟踪，没有任务历史，也没有对话线程。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file9.png

图 1.9 – 直接 LLM 交互

这种方法在事实性问答、创意内容生成或一次性辅助等轻量级场景中表现出色。然而，它管理多步交互、维护用户状态或完成目标驱动的工作流方面存在局限性。缺乏内存或自适应反馈机制意味着这些系统无法构建长期上下文或参与真正的对话行为。典型的无状态 LLM 交互看起来是单个提示产生一次性响应，且对之前的查询没有记忆：

from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create( model="gpt-3.5-turbo", messages=[ {"role": "user", "content": "What is the capital of Canada?" ] )
print(response.choices[0].message.content)

直接 LLM 交互的现实示例包括：

• 基于聊天的问答系统：例如零售网站上回答事实问题的聊天机器人——“你们的营业时间是什么？”或“我的订单在哪里？”。

• 创意写作工具：如 Jasper 或 Sudowrite 等应用程序，它们根据提示生成单段落或想法。

• 教育闪卡助手：回答离散学术问题的系统，例如“解释牛顿第一定律”，用于快速学习参考。

代理代理 (Proxy agent)：智能中介

代理代理代表了智能系统架构中一种基础但往往被低估的模式。与维护状态或调用外部工具的自主或多轮代理不同，代理代理关注一个更窄但至关重要的责任：将非结构化的用户输入转换为适用于后端系统的结构化可执行格式。其核心，代理代理充当了语义中介。当用户提交如“寻找我附近的餐厅”之类的请求时，代理代理不会立即将其转发到服务端点。相反，它充当翻译器——注入额外的上下文、消除模糊术语、清理输入，并将查询重新格式化为结构化表示。这种设计不仅提高了精确性和可靠性，还保护了依赖于严格模式或预定义参数集的下游系统。

代理代理遵循定义良好的处理流程。首先，它捕获用户输入。这些输入通常是自由格式的自然语言，本质上具有模糊性或不完整。然后代理将此输入集成到结构化的提示模板中。该模板包含了对底层语言模型的指令以及动态数据（如用户查询或上下文元数据）的占位符。完成提示后，代理调用语言模型（例如 OpenAI 的 GPT 或 Anthropic 的 Claude），并接收结构化响应——通常是 JSON 或 SQL 格式。最后，将此结构化结果转发到目标服务或执行层。为了更好地理解其工作原理，请考虑以下示例场景：用户问道：“寻找我附近正在营业的餐厅。”

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file10.png

图 1.10 – 代理代理

代理代理不会直接将此消息传递给餐厅发现 API。相反，它通过结构化转换流水线处理请求，将自然语言转换为机器可读的格式。

实现示例

以下代码演示了代理代理如何实现从自然语言到结构化数据的转换：

from langchain.prompts import PromptTemplate
from langchain.chains import LLMChain
template = """
You are a proxy agent responsible for translating natural language into structured queries.
User input: "{query}"
Return a JSON object with the following fields:
- intent: 要执行的操作。
- location: 推断或陈述的位置。
- time_filter: 指明查询是否包含时间限制。
- format: 响应格式（例如，'list'）。
仅用 JSON 回答。
"""
prompt = PromptTemplate(input_variables=["query"], template=template)
chain = LLMChain(prompt=prompt, llm=openai_chat)
response = chain.run({"query": "Find restaurants near me that are open now"})

结构化输出

执行时，该实现产生一个干净、结构化的响应，下游系统可以可靠地处理：

{
    "intent": "search_restaurants",
    "location": "current_user_location",
    "time_filter": "open_now",
    "format": "list"
}

此结果现在是干净、上下文丰富且完全结构化的——非常适合调用 API 或传递给下游规划器。模板确保了一致性，而语言模型提供了语义推理，以推断缺失的信息（如位置元数据或时间过滤器“正在营业”）。对于生产环境，其他考虑因素至关重要：

• 输入清理：实施稳健的输入清理，以防止提示注入攻击或恶意/格式错误的用户输入导致意外模型行为。

• 日志记录：提示、响应和执行时间的详细记录对于调试、审计和理解代理在现实场景中的行为至关重要。

• 监控提示响应时间：持续监控 LLM 调用的延迟，以确保代理符合性能 SLA 并提供响应的用户体验。

代理系统

代理代理（proxy agents）能够在自然用户意图与硬性系统需求之间充当控制层，这使得它们在安全关键或受模式限制（schema-bound）系统中成为理想选择。例如，它们被广泛应用于金融服务平台以验证和转换客户端指令，应用于医疗系统将患者查询处理为结构化的分诊协议，并在客户服务工具中执行后端操作之前对请求进行清洗。重要的是，代理代理还能缓解与提示词注入（prompt injection）或指令操控相关的风险。由于提示词模板定义了清晰的结构并将用户内容与系统指令隔离开，开发者可以对模型解释和处理每个输入的方式实施严格边界限制。虽然代理代理不管理内存或启动长期计划，但它们作为输入优化器的角色对于构建稳健、可信且达到生产级的 AI 系统至关重要。在任何后端服务期望严格输入但用户以自然方式通信的架构中，代理代理都能以清晰的控制力弥补这其中的差距。

代理代理充当翻译员的角色，将自然语言输入转换为后端执行的结构化数据。它们的现实应用场景包括：

• 语音转命令处理：如Google Assistant等虚拟助手，将“播放我的健身歌列表”转换为指向音乐服务的结构化 API 调用。

• 表单填写与处理机器人：医疗机器人接收患者的自由文本症状，并将其重新格式化为医生提供的结构化分诊报告。

助手系统：工具增强型帮手

助手系统代表了智能系统的一次重大进步，它结合了会话级内存、工具调用和用户引导的自主性。这些代理不仅能够解释用户请求，还可以访问外部工具或服务，并调用它们来完成任务。在Figure 1.11中，用户请求“预订去巴黎的机票”。助手系统解释此指令并调用相应的服务——如机票 API、预订数据库或日历工具——来执行任务。图中显示助手作为一个task orchestrator，能够通过工具调用路径与外部系统交互。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file11.png

图 1.11 – 助手系统

助手在多个回合之间维持会话状态，实现了对话的连续性、澄清处理和结果总结。然而，它通常在“用户参与（user-in-the-loop）”的批准模式下运行，在采取完成预订或启动交易等影响性行动之前寻求确认。例如，如果用户先说“我想下周五飞往巴黎”，随后补充说“再订一个埃菲尔铁塔附近的酒店”，助手在处理新命令时会保留早的机票请求和目的地上下文。这种跨回合跟踪和应用会话变量（如目的地和日期）的能力允许助手以连续且精确的方式完成多步任务。这种模型对于企业级数字助手、智能客服机器人以及需要受控自主和操作透明的个人生产力代理非常理想。助手系统将自然语言理解与工具调用及有限会话内存相结合。它们在实践中的示例包括：

• 企业级数字助手：如Microsoft Cortana for Business，它可以帮助跨不同的企业系统安排会议、管理电子邮件并获取文档。

• 客户服务机器人：银行中的智能虚拟助手，可以访问用户账户数据，处理简单交易（如余额查询、资金转账），并在需要时升级人工人工服务。

• Notion AI 及类似的生产力代理：这些工具可以搜索数据库、总结项目笔记或创建结构化内容模板，超越了单次交互限制以支持真正的生产力。

自主代理：独立的问题解决者

自主代理标志着智能系统设计中的关键演变。自主代理超越了依赖分步用户输入的响应式工具或助手式界面，它们具备独立行动的能力——解释目标、对策略进行推理、调用工具并根据变化动态调整行为。这种独立性使它们能够以类似于人类认知解决问题的方式执行复杂的、长期的任务。然而，自主性的增加也引入了风险——在缺乏足够监督运行的代理可能会误解目标、追求意料之外的策略或触发不良操作。因此，此类策略约束、人工参与（human-in-the-loop）检查点或行为监控机制对于确保敏感领域的可靠性至关重要。

它们架构的核心是SMPA loop——这是一个镜像智能决策过程的概念框架。在这个循环中，代理首先感知其环境，这可能包括用户输入、内部状态变化或外部 API 响应。这些信息馈入一个维护上下文内存、跟踪历史操作并表示代理对任务空间理解的模型中。随后，代理通过将高级目标分解为可操作的步骤来制定计划，并根据依赖关系和约束进行排序。最后，它通过执行这些步骤、与外部系统、API 或工具交互并根据需要调整方法来采取行动。

考虑用户发出指令“规划我的巴黎之行”的情景。传统的助手可能会回复一个静态的机票列表或酒店选项，而自主代理会将此请求解释为多阶段目标。它启动一个包含行程生成、酒店选择、签证资格评估和旅游保险购买在内的过程。该代理不是孤立地处理每项任务，而是构建一个连贯的计划，识别依赖关系——例如，在确定机票订单之前确定签证要求——并端到端执行工作流。

在整个过程中，代理维持着持久的内部内存。它记住了用户的偏好（例如偏好的航空公司或住宿类型），并利用这些知识来完善决策。如果首选酒店已满，它会搜索符合相似标准的替代住宿。如果签证申请过程出现意外延迟，代理将相应地重新安排行程中的相关元素。这些调整并非硬编码的，而是源于评估成败并实时修订策略的反馈循环。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file12.png

图 1.12 – 自主代理

从技术角度来说，这类智能体在使用LangGraph、LangChain和CrewAI等现代框架构建。LangGraph允许开发者将智能体的推理结构化为有向图，并带有状态转换和上下文保留。LangChain提供了抽象，将语言模型与工具连接起来，使智能体能够搜索网络、调用 API 或与数据库交互。CrewAI则促进了专门智能体之间的协作——一个处理物流，另一个专注于合规性，还有另一个负责管理通信。这些框架共同支持了异步执行、健壮的错误处理以及现实世界中的扩展性。

在实践中，自主智能体正越来越多地部署在广泛的领域。在研究领域，它们实现了文献综述的自动化、实验方案的生成并将发现合成报告。在业务领域，它们协调多步工作流、管理入职流程或执行营销活动。在自适应学习环境中，它们制定个性化学习计划、监控进度，并根据学习者的表现调整节奏。它们持久上下文和自主改进行动的能力，使其在那些需要持续关注、动态响应和以结果为导向的执行的系统中特别有价值。

因此，自主智能体不仅仅是能力更强的助手——它们是独立的解决者。凭借在长时间跨度并在极少监督下进行计划、推理、行动和适应的能力，它们代表了向不仅遵循指令而且理解目标的系统迈出的一步。随着这种能力的成熟，自主智能体正准备重塑数字工作的格局，改变我们处理各行业复杂问题的方式。

自主智能体在长的工作流中独立地创建计划、做出决策并执行任务。它们的能力涵盖了目标设定、工具调用、内存管理和自适应行为。在现实世界，我们越来越多看到这些智能体部署在不同的领域。一些显著示例包括：

• 研究助手：能够自主进行文献综述、总结关键发现并生成详细报告的 AI 系统——释放研究人员从事更高层次的分析。这些智能体减少了人工开销，并能够跨数千篇论文或来源扩展研究合成。

• 客户支持机器人：对入入的用户请求进行分类，访问数据库或 CRM 系统检索答案，并在必要时将未解决的问题升级。这些机器人在帮助减轻人类工作负载的同时，提高了首次响应的效率。

• 金融分析师：自主智能体收集市场数据，应用基于规则的模型或机器学习预测，并准备投资摘要或警报——支持时间敏感环境中的决策支持。

• IT 运维智能体：部署在 DevOps 环境中，这些智能体监控系统指标、检测异常，并根据预设的阈值和模式启动修复操作（例如重启服务或扩展基础设施）。

为了评估这些智能体在生产环境中的有效性，使用了几个关键性能指标（KPIs）：

• 任务完成率：在无人工干预的情况下完成的任务的百分比。

• 平均响应时间：完成任务或响应请求所需的时间。

• 事实准确性/一致性：在研究和数据密集型领域尤为重要。

• 升级率：需要人工兜底的任务百分比。

• 用户满意度评分：基于调查、星级评分或重复使用等行为信号。

这些指标不仅有助于衡量成功，还为优化周期和信任校准提供信息——确保自主性不仅强大，而且是可靠、负责任且符合用户需求的。

智能体系统：协作智能

智能体交互的顶点是多智能体系统 (MAS)——这是一个分布式框架，其中多个自主或半自主智能体协作以实现复杂目标。这些系统将认知责任分配给专门的智能体，每个智能体都具有特定领域的角色、能力和通信协议。

在图 1.13中，用户提交了一个任务——分析数据，该任务被分配到智能体网络中：Agent A（数据检索）、Agent B（数据清洗）和Agent C（数据可视化）。中心显示了一个共享状态存储，允许智能体进行通信、交换结果并维护整个系统的一致性：

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file13.png

图 1.3 – 多智能体系统

这种协作模型实现了并行、冗余和领域专门化。MAS 架构通常依赖发布-订阅消息系统（智能体向感兴趣的订阅者广播更新）、共享内存模型（所有智能体可访问的中心化数据存储）或任务调度协议（将工作分配给可用智能体的系统方法）来管理交互。根据系统设计目标，智能体可能由中央主管协调，或作为完全去中心化的节点运行。

为了确保健壮性，这些架构通常包含容错机制，例如智能体健康检查、看门计时器，或在智能体崩溃或无响应时重新分配任务。某些系统在关键角色上采用冗余智能体或兜底智能体，以确保长时间工作流的连续性。这种弹性在现实世界的部署中至关重要，因为硬件、网络或软件故障可能会意外地发生。

多智能体系统是企业编排、科学研究平台、智能供应链网络和分布式 AI 基础设施的理想选择，在这些领域模块化、扩展性和健壮性关键。多智能体系统的特点是专门智能体团队协作处理单一智能体无法处理的广泛或动态的复杂任务。示例包括：

• 自动驾驶汽车：如 Waymo 车队中的系统，感知（检测障碍物）、导航（寻找路线）和安全（避免碰撞）智能体协同工作。

• 金融交易平台：如Citadel等对冲基金使用协调的 AI 智能体——市场分析、风险管理、情感分析——每秒执行数千次交易。

• 智能家居编排：AI 统一控制恒控器、灯光和安全——根据温度变化或安全状态调整灯光。

• 医疗诊断：IBM Watson for Oncology，多个 AI 智能体分析患者数据、建议治疗方案并标记可能的药物相互作用。

智能体成熟度

这种演进模型使技术人员和业务负责人能够评估当前的实施情况，识别能力差距，并规划向日益复杂的智能体系统迈进的战略。该框架建立了五个不同的智能体成熟度级别，每个级别都代表了智能系统运行方式及其交付价值的质变。

级别 0：手动操作 — 非智能体系统

在这一基础阶段，系统内部不存在任何智能或自动化。所有操作都需要人类直接启动、执行和监督。上下文解释、决策和执行完全取决于人类的认知努力，数字系统仅作为工具，而不是工作流中的活跃参与者。示例：财务分析师手动准备月报、人力资源人员手动输入新员工数据，以及客服代表逐一回复每封邮件。

级别 1：响应式智能体 — 基于规则的自动化

响应式智能体引入了由简单条件逻辑管理的预定义确定性行为。这些系统根据特定触发通过预设动作做出响应，以无状态、无上下文的方式运行。虽然对于参数明确的常规任务有效，但响应式智能体缺乏对新情况的适应能力，或从经验中学习的能力。示例：发送模板回复的自动邮件响应器、提取数据并输入表单的机器人流程自动化（RPA）机器人，以及根据语音命令控制智能家居的基本语音助手（如 Amazon Echo）。

级别 2：工具型智能体 — 增强执行

在此级别，智能体变成了半智能协调器，能够与外部服务接口并调用专用工具。这些系统可以解析自然语言指令，根据上下文选择合适的工具，并链联多个操作以完成定义的目标。虽然仍限于基于会话的上下文和明确指令，但它们通过工具组合展示了涌现能力。示例：从扫描 PDF 中提取信息并上传到数据库的文档处理系统、从多个源汇总数据的自动报告生成器，以及从广泛知识库中提取答案的智能帮助台系统。

级别 3：规划型智能体 — 上下文与目标导向

规划型智能体引入了复杂的推理能力和目标驱动行为。这些系统将高级目标分解为结构化的任务序列，结合中间步骤的反，遇到障碍时调整计划，并在长时间的操作中保持持续感知。这一级别代表了自主决策和战略思维的重大进步。示例：动态预订机票、酒店和活动的自主旅行规划智能体；为新员工协调文档提交和培训计划的数字入职助理；以及根据团队可用性和进度调整时间表的智能项目管理系统。

级别 4：学习型智能体 — 自适应与进化

学习型智能体代表了演进框架中最高级别的别。这些系统不仅执行复杂计划，还通过经验随时间进化其能力。它们整合过去的交互反馈，为个人用户或场景开发个性化模型，适应环境变化，并根据观察结果和明确指导不断完善策略。

该演进框架为组织提供了一种结构化方法，用于评估当前的智能体能力，识别战略开发优先级，并规划符合业务目标的能力路线图。通过了解系统在成熟度模型中的位置，领导者可以对技术投资、开发优先级和智能体 AI 的实施策略做出明智决策。示例：学习用户偏好并随时间不断改进的个性化推荐引擎；随攻击模式变化而进化的高级欺诈检测系统；以及设计并进行科学实验、根据实验结果完善其假设和方法的自主研究智能体。

该框架为理解智能体演变提供了概念基础，并为实施提供了战术蓝图。对于研究人员来说，它与响应式系统、分层规划和强化学习等范式保持一致。对于从业者来说，它提供了清晰的示例和部署考虑，阐明了从手动流程向智能自适应系统过渡的路线图。通过了解系统在成熟度模型中的位置，领导者可以对技术投资、开发优先级和智能体 AI 的实施策略做出明智决策。

在建立了智能体工程的理论基础和评估智能体成熟度的框架后，我们现在检查这些概念如何转化为切实的业务价值。以下真实世界的案例研究表明，自主智能体不是未来的可能，而是当今的收入驱动力，从根本上改变了组织在各自市场中运营和竞争的方式。同时，伦理护栏——如透明性、问责制、公平安全——必须引导此类智能体的部署。随着自主性的增加，意外行为、偏差传播或违反法规的风险随之增加。将这些原则整合到设计和治理中，可以确保智能体不仅产生影响，而且以符合组织价值观和社会预期的方式来实现。

现实世界的业务影响

忘记理论抽象吧——自主智能体正在重塑各行业，为早期采用者带来可衡量的回报和竞争优势。这些不是实验性原型或学术奇事，而是产生收入的系统，正在改变业务运营、服务客户以及将其能力扩展到传统限制之外的方式。

Quandri：自动化保险革命

保险处理曾意味着大量人员在纸质森林中挣扎。Quandri 通过部署自主智能体网络打破了这一范式，该每天处理数千份保单。以前需要数小时熟练劳动力的工作现在在 15 分钟内解决，系统保持着惊人的 99.9% 准确率。这不是渐进式的改进——而是规模化的转型，每月产生超过 30,000 美元的经常收入，而竞争对手仍陷入劳动力密集型的工作流中。配备智能体技术的精简团队现在系统性地优于其规模数倍的传统运营，从根本上重写了保险处理的经济学。

My AskAI：30 支持奇迹

金融服务支持通常意味着令人沮丧的等待、不一致的答案和升级地狱。My AskAI 的智能体架构通过将专用组件（文档分析、合规验证和实时数据检索）协调为一个统一的认知系统，在 30 秒内解决复杂的查询。这不仅仅是更快的服务；这是一种不同类别的体验，驱动了每月 25,000 美元的经常收入和超过 99% 的客户满意度评分。系统的战略智能确切知道何时自主处理问题，以及何时升级给人类专家，为习惯于传统服务模式的用户创造了感觉超自然的无缝支持体验。

企业机器人通过多智能体协作从根本上重新定义了销售运营。它们不再仅仅自动化孤立的任务，而是部署了专业的智能体团队来处理整个销售周期——从线索富化和筛选到个性化触达和会议协调。结果极具说服力：合格线索的生成增加了三倍，而获取成本下降了 50%，推动年度经常性收入超过 200 万美元。这不仅仅是自动化；这是能力的倍增，让人类销售人员能够完全专注于高价值的关系建立，而他们的数字孪生则全天候、有条理地追求机会。正如这些案例所示，智能体技术不是未来的考虑因素，而是当下的竞争决定因素。利用复杂的智能体系统的组织与依赖传统自动化的组织之间的差距不断扩大，这形成了一种市场动态：传统方法无论执行质量如何，都无法与智能体驱动的方案在经济效益、速度和扩展性上竞争。信息很明确：这关非渐进式的改进，而是现代业务运营可能性的根本性转变。

总结

本章确定了现代智能体工程的基础概念。我们探索了 AI 智能体如何从简单的响应式系统演变为能够感知、推理、规划、行动和学习的复杂自主实体。通过对智能体架构的审查，我们看到了模块化组件如何协作创建出能够有效导航并响应复杂环境的系统。我们介绍智能体开发周期提供了一种设计、实现和持续改进的结构化方法，而我们对智能体能力的探索阐明了实现目标导向行为的认知功能。我们引入了根据交互水平和开发成熟度对智能体分类分类框架，为理解和推进智能体技术提供了路线图。通过研究设计模式、机器教学方法和现实业务应用，我们将理论原理与实际实现联系起来。我们概述的智能体类型分类法——从响应型到学习型智能体——展示了智能体架构的多样方法，并突显了基于智能体的解决方案的灵活性。随着我们的推进，这些基础将成为后续章节中讨论的更高级概念和实现的重要基石。智能系统的未来将越来越具有智能体化（agentic），自主 AI 准备改变我们在人类活动几乎每一个领域中工作、创造和解决复杂问题的方式。在建立了智能体工程的概念基础后，我们将转向使这些概念变为现实的实用工具、框架和模型。第 2 章将探索快速发展的智能体开发技术生态系统，提供为您的特定智能体实现需求选择和利用正确组件的全面指南。从LangChain和AutoGPT等开发框架，到语言模型选择策略和基础基础设施组件，接下来的章节提供了一个将智能体理论转化为工作系统的实用工具包。

第 2 章智能体工程师的工具箱

在开始之前：加入我们 Discord 上的 GenAI & LLM 社区

向作者本人提供反馈，并在我们的 Discord 服务器上与其他早期读者聊天。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/30-agents-every-ai-engineer-must-build-transform-llms-into-a/img/file15.png

packt.link/4Bbd9

在智能体中，智能表现为目标导向的、自主的行为

智能体工程：核心框架与工具

— Andrej Karpathy，前特斯拉 AI 总监 (2024)

在智能体领域，tooling 定义了能力。随着智能体从响应式脚本转向目标导向的自主系统，开发者必须掌握不断扩展的框架、模型和基础设施生态系统。本章对智能体工程领域中可用的工具进行了结构化探索——为读者提供实用的见解和对比分析，以便在整个技术栈上做出明智决策。想象一个智能体能够自主研究市场趋势、合成数据并起草战略报告——一切实时完成。这就是正确工具包所释放的力量。选择合适的工具和框架是智能体开发过程中的一个关键决策点——它不仅会影响开发时间和运营成本（例如，考虑LLM推理成本，根据模型和提供者的不同，每百万 token 的成本可能从几分到几美元不等），还会影响你最终系统的基本能力。作为一名智能体工程师，你的工具箱定义了你的智能体可以感知的边界、如何推理，以及它们在世界上可以采取什么行动。虽然LLMs为现代智能体提供了认知引擎，但仅凭原始模型不足以构建实用的系统。当你将这些模型与设计良好的工具箱相结合时，智能体开发的真正威力就会显现，它可以实现高效知识检索（例如由向量数据库和FAISS等库支持的RAG）、工具集成（例如通过OpenAI强大的函数调用机制）、监控和部署。在本章中，我们将检查当前使用的主要智能体框架，回顾选择和优化LLMs的策略，并深入支持内存、推理、评估和部署的基础工具。本章并不是提供当前可用选项的快照（这些选项可能很快过时），而是侧重于即使在特定实现变化时也会保持相关的底层原理和模式。在整本书中，我们将主要使用LangChain和LangGraph作为核心开发框架，是因为它们拥有稳健的生态系统、生产就绪的文档。虽然我们会探索其他框架以提供背景并帮助你理解更广泛的格局，但我们的实用示例、代码实现和深度教程将专注于LangChain生态系统（编写时为 v0.3.x）。在本章中我们将涵盖以下主题：

• 智能体开发框架：架构蓝图

• 大语言模型：认知核心

• 支持基础设施：智能体生态系统

• 云原生智能体开发平台：托管军库

智能体开发框架：架构蓝图

框架是构建智能体的基础。它们提供了结构，规范了模式并封装了最佳实践，使开发者能够从随机实验转向可重复的可扩展工程。选择框架不仅仅是一个工具选择——它是一项影响扩展性、可维护性和性能的战略决策。以下是主要智能体开发框架的总结表。该表对它们的优势、局限性和理想用例场景进行了简要对比。

| 框架 | 优势 | 局限性 | 理想用场景 |

| :--- | :--- | :--- | :--- |

| LangChain | 模块化设计、广泛集成 | 原生不支持多智能体 | LLM 流、工具工作流 |

| LlamaIndex | 高级检索、语义压缩 | 需要编排支持 | 文档问答、内存层 |

| AutoGPT | 自主目标规划 | 可靠性低、控制脆弱 | 研究原型 |

| CrewAI | 基于角色的协调 | 处于早期阶段 | 多智能体团队 |

表 2.1 – 代理开发框架对比

正如第 1 章中关于cognitive loop model章节所讨论的，有效的代理必须不断在感知、推理、规划、行动和学习之间循环。我们在本章中探索的框架在代码中实现了这种认知架构，每个框架在结构化这些关键功能方面都有自己的方法。

理解这些不同的方法至关重要，因为你选择的框架不仅决定了你构建和迭代代理的速度，还决定了它们最终能实现什么能力。例如，LangGraph 的有向无环图（DAG）模型支持复杂多步推理的并行分支，优化了复杂工作流的吞吐量；而 CrewAI 的设计则可以为线性、专门化的任务提供更快速、更集中的对话。每个框架都体现了对代理行为的不同假设，为常见模式提供了不同的抽象，并对底层认知过程提供了不同程度的控制。通过研究它们的优势、局限性和最佳使用场景，你将能够做出符合你对性能、可扩展性和可维护性特定要求的明智决策。

关键框架的综合分析

起初，是一片混乱：拼凑在一起的临时脚本、模型与工具之间脆弱的连接、以及在复杂性压力下崩溃的脆弱推理链。随后，框架出现了：这种代理架构的结构化方法为这片数字荒野带来了秩序。然而，至关的一点是，虽然框架提供了显著的加速和结构，但它们引入了层层抽象。这种抽象虽然对快速开发有利，但有时会导致对底层机制的低级控制水平和理解的削弱。对于基础学习或高度自定义的场景，从更简单的 Python 代码开始构建代理能力，可以在利用完整框架之前提供更深层次的洞察。每个框架都代表了关于代码中如何结构化智能的不同哲学。

LangChain：组合式的先驱

在数字星空中拥有超过 70,000 个 GitHub Star，LangChain 堪称代理框架中的元老级。它的计算图模型镜像了认知科学中关于顺序推理的理论（通常被称为 chain-of-thought 思维链处理），允许开发者从更简单的构建模块组合复杂的行为。这种设计使代理能够遵循分步推理流水线，图中的每个节点都对应一个认知或功能操作，就像人类如何将问题分解为顺序子任务一样。

LangChain 的架构围绕几个核心抽象构建，我们将在书中广泛地使用它们：

• Chains（链）：连接多个组件的顺序处理流水线。LangChain 还提供了稳健的回调和追踪机制，允许开发者观察、记录和调试这些链的执行流，这对于理解复杂的代理行为至关重要。

• Agents（代理）：自主决策者，它们接收输入，决定要采取什么行动（例如调用工具或查询 API），然后执行这些行动以实现目标。这一过程可能涉及工具选择、记忆检索或推理步骤，使代理能够以某种程度的自主运行。

• Tools（工具）：外部系统和 API 的接口

• Memory（内存）：维护对话上下文和长期存储的系统

• Retrievers（检索器）：访问和过滤相关信息的组件

• Embeddings（嵌入）：用于语义操作的文本向量转换

框架的模块化设计在实际实现显而易见。考虑这个基础代理设置的示例：

from langchain.agents import initialize_agent, AgentType
from langchain.llms import OpenAI
from langchain.tools import Tool
from sympy import sympify
from langchain.tools.ddg_search.tool import DuckDuckGoSearchRun  # hypothetical import

#### 定义代理可以使用的工具
def calculator(expression: str) -> str:
    """安全地评估数学表达式."""
    try:
        result = sympify(expression)
        return str(result)
    except Exception:
        return "Invalid mathematical expression"

#### 使用 LangChain 提供的 DuckDuckGoRun tool
search = DuckDuckGoSearchRun()
tools = [
    Tool(name="Calculator", func=calculator,
         description="Useful for mathematical calculations"),
    Tool(name="WebSearch", func=search.run,
         description="Search the web for current information")
]

#### 初始化代理
llm = OpenAI(temperature=0)
agent = initialize_agent(
    tools=tools,
    llm=llm,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True
)

#### 让代理对工具的使用进行推理
result = agent.run("What’s the square root of 144, and can you find recent news about that number?")

此示例展示了LangChain的强大：代理自动确定它既需要数学计算也需要网络搜索，按适当顺序执行它们，并汇总结果。ZERO_SHOT_REACT_DESCRIPTION代理类型实现了 ReAct（推理与行动）模式，模型对要采取的行动进行推理，然后根据这些决策采取行动。LangChain的内存系统特别复杂，支持多种内存类型：

from langchain.memory import ConversationBufferMemory, ConversationSummaryMemory
from langchain.schema import BaseMessage

#### Buffer memory 保留原始对话历史
buffer_memory = ConversationBufferMemory(
    memory_key="chat_history",
    return_messages=True
)

#### Summary memory 压缩旧对话
summary_memory = ConversationSummaryMemory(
    llm=OpenAI(),
    memory_key="chat_history",
    return_messages=True
)

该框架广泛的生态系统包含了超过 100 个与流行服务的预构建集成，如OpenAI、Anthropic、Google、AWS、向量数据库（Pinecone、Chroma、Weaviate）以及无数 API。这种生态系统的丰富性意味着大多数集成挑战已经由社区解决并测试。LangChain的核心是模块化的研究：用于顺序处理的链、用于环境交互的工具，以及在对话数字突触中维护上下文的内存系统。其丰富的组件库减少了实现常见代理模式所需的代码，让开发者专注于他们作品的独特之处。然而，LangChain的灵活性也带来了复杂性。框架大量的抽象层可能会引入性能开销，而且在没有LangSmith等适当的可观测工具的情况下，调试复杂的链可能是挑战性的。正如传统软件工程从简单的打印语句演变为结构化日志，再到全面的可观测平台一样，代理工程也需要类似的进步。此外，虽然LangChain在单代理场景中表现出色，但在复杂的多代理系统中还需要额外的编排——这就是LangGraph变得至关的地方。参考 URL：www.langchain.com/

LangGraph：工作流可视化器

LangGraph 代表了LangChain向有状态、循环工作流的演进，这种模式更密地反映了人类的认知过程。LangChain的链通常是线性的，而LangGraph允许具有循环、条件逻辑和复杂的状态管理的复杂分支决策树。这种可视化且有状态的方法显著缓解了调试复杂代理行为的痛点；通过像LangSmith等专用的可观测性工具，或通过集成标准的OpenTelemetry钩子来实现全面的跟踪和监控，可以获得更高的透明度。LangGraph的核心是将代理工作流建模为有向图：

• Nodes（节点）代表离散的处理步骤或代理函数

• Edges（边）定义步骤之间的流

• State（状态）在nodes之间维护并传递

• Conditional routing（条件路由）实现了动态决策

这种架构对于实现第 1 章中讨论的认知循环特别强大，其中代理必须在感知、推理、规划和行动阶段之间循环。以下是一个实用的示例：

from langgraph.graph import Graph, Node
from langgraph.prebuilt import ToolExecutor
from langchain.tools import DuckDuckGoSearchRun, Calculator

#### 定义代理的工作流节点
def research_node(state):
    """收集关于该主题的信息."""
    query = state.get("user_query")
    search_tool = DuckDuckGoSearchRun()  # 指定它更安全
    research_results = search_tool.run(query)
    return {"research_data": research_results, "next": "analyze"}

def analyze_node(state):
    """分析收集到的信息."""
    research_data = state.get("research_data")
    # 在真实系统中，在此插入 LLM/分析逻辑
    analysis = f"Analysis of: {research_data[:200]}..."
    return {"analysis": analysis, "next": "decide"}

def decide_node(state):
    """决定是否需要更多研究."""
    analysis = state.get("analysis")
    # 带有可选 MAX_ITER 的循环条件
    if "insufficient data" in analysis.lower():
        if state.get("loop_count", 0) >= 3:  # 防止无限循环
            return {"next": "respond"}
        return {
            "next": "research",
            "loop_count": state.get("loop_count", 0) + 1
        }
    else:
        return {"next": "respond"}

def respond_node(state):
    """生成最终响应."""
    analysis = state.get("analysis")
    response = f"Based on my research and analysis: {analysis}"
    return {"final_response": response, "next": "END"}

#### 构建图
workflow = Graph()
workflow.add_node("research", research_node)
workflow.add_node("analyze", analyze_node)
workflow.add_node("decide", decide_node)
workflow.add_node("respond", respond_node)

#### 定义转换
workflow.add_edge("research", "analyze")
workflow.add_edge("analyze", "decide")
workflow.add_conditional_edges("decide", lambda state: {
    "research": "research" if state.get("next") == "research" else None,
    "respond": "respond"
})
workflow.set_entry_point("research")
workflow.set_finish_point("respond")

#### 编译并运行
app = workflow.compile()
result = app.invoke({"user_query": "Latest developments in quantum computing"})
print(result)

此示例展示了LangGraph的关键优势：如果初始分析不足，代理可以智能地循环回以收集更多信息，并在整个过程中保持状态。这种循环能力对于实现简单链无法实现的复杂推理模式至关重要。LangGraph在传统LangChain无法胜任的几个关键领域表现：

• 带有条件分支的多步推理

• 带有审批关卡的人机交互工作流：LangGraph允许开发者设计暂停执行并等待外部输入或人工审查的节点，例如在财务交易之前进行审批。这使得代理能够与人类就关键决策或复杂任务进行协作

• 复杂的多代理协调和交接

• 跨长时间运行过程的持久化状态管理

• 复杂的错误处理和重试逻辑

该框架还提供了强大的调试和可视化功能：

#### 可视化工作流
from langgraph.graph import draw_mermaid

#### 生成工作流的 Mermaid 图
graph_diagram = draw_mermaid(workflow.get_graph())
print(graph_diagram)  # 显示你的代理逻辑的可视流

LangGraph的状态管理特别为复杂，支持简单的字典状态和复杂的类型化状态模式：

Python 类型化状态与代码示例

from typing import TypedDict, List
from langgraph.graph import Graph
class AgentState(TypedDict):
    user_input: str
    research_results: List[str]
    analysis_confidence: float
    iteration_count: int
    final_response: str
#### 图在执行过程中维护此类型化状态

LangGraph 将 LangChain 扩展为基于图的架构，将代理步骤视为有向无环图中的节点。这种推理路径的可视化为代理决策过程提供了所未有的透明度。在实际实现中，LangGraph 对多步代理任务提供了精确控制，在具有分支路径、高级错误处理和状态管理要求的复杂工作流中表现出色。虽然它比简单的框架学习曲线更陡，但这种投资在复杂的企业级应用中将获得回报。在本书的剩余章节中，我们将广泛使用 LangGraph 来实现复杂的代理工作流，从简单的顺序过程到复杂的多代理编排。

智能体框架探索

在智能体框架的殿堂中，AutoGPT 曾梦想过一种彻底的变革——真正的自主目标导向行为。凭借惊人的 150,000 GitHub Stars，它向世界引入了递归自我提示（recursive self-prompting），允许智能体在无需人工干预的情况下将高级目标分解为可执行的子任务。AutoGPT 为目标分解、任务规划和自主工具选择实现了更高层次的抽象，这些与目标导向认知系统的理论模型相一致。这种方法能够创建能够在极少人工监督下追求复杂目标的智能体。但这种自主性是有代价的。其控制机制仍然脆弱，生产环境的部署需要仔细配置以保持与用户意图一致。然而，在追求真正自主的道路上，AutoGPT 暗示了智能体架构的未来可能性。

参考 URL: github.com/Significant-Gravitas/AutoGPT

CrewAI：协作编排者

我们框架探索中的最新竞争者带来了一种不同的哲学——基于角色分化和多智能体协作的理念。CrewAI 抽象了“团队”协作工作的概念，通过分配的角色来处理复杂任务。在 CrewAI 中，每个智能体都通过角色、目标和背景等属性定义——在协作系统中创建出独特的人格。智能体通过内置的消息和委托机制进行通信，本质上是相互之间“大声思考”以规划和解决问题。CrewAI 拥有 30,000 GitHub Stars 且不断增长，代表了向更结构化的协作智能的转变——即专业智能体在中央编排者的指导下结合其能力。

从 0.4 版本开始，CrewAI 引入了与 LangChain 更紧密的集成，依赖 LangChain 的智能体和工具抽象来实现工具使用和编排。这使得 CrewAI 特别适用于已经在使用基于 LangChain 工作流的团队，尽管它也引入了一些依赖方面的考虑。

参考 URL: github.com/crewAIinc/crewAI

AutoGen：对话架构师

由微软开发的 AutoGen 采用了一种独特的智能体编排方法，将 LLM 视为对话参与者。AutoGen 不仅仅关注智能体的角色定义或目标分解，而是引入了一种对话编程范式——每个由 LLM 支持的智能体通过消息进行交互，共同解决任务。AutoGen 通过将智能体定义为具有角色的函数（例如用户代理、代码执行器、规划器），并通过自定义的消息传递循环进行连接，实现了复杂的、有状态的多智能体工作流。这种结构允许动态协调、自适应规划和工具调用，比响应式智能体具有更高程度的控制力。它的优势在于精粒度的编排——允许开发者显式地管理轮替、输入/输出流和停止条件。AutoGen 越来越多地应用于企业级应用，其中透明度、协调性和模块化是关键。

参考 URL: github.com/microsoft/autogen

优势、劣势与最佳用例

选择合适的智能体开发框架是一项战略性决策，它从根本上塑造了你的系统能力：

• LangChain 通过其模块化编排和庞大的集成生态系统脱而出。它在需要快速原型或复杂工具集成的场景中表现优异。然而，其分层抽象可能会在延迟敏感的应用中引入性能开销。

• LlamaIndex 以其以知识为中心的设计与众不同，提供了先进的语义索引和上下文压缩。请注意，上下文压缩是提炼大量信息的技巧。

• AutoGPT 专注于自主的目标导向行为，尽管其控制机制仍然脆弱。

• CrewAI 代表了向更结构化的协作智能的转变——即专业智能体在中央编排者的指导下结合其能力。

构建与集成决策

现代智能体工程遵循“组合优于构建”（compose-over-build）的哲学——通过集成组件组装智能系统，而不是从开始构建单体架构。在实践中，大多数团队遵循混合路径：在开发期间利用 LangChain 等框架进行编排，当出现特定的性能或安全限制时，选择性地替换组件。例如，一个团队可能开始使用 LangChain 的 ConversationBufferMemory 进行快速原型开发，但当其智能体需要持久且语义丰富的内存时，随后将其更换为 Pinecone 或 Chroma 等生产级向量数据库。

认知引擎与模型集成

当我们从框架转向其所编排的模型时，我们进入了人工智能认知领域。大语言模型（LLMs）代表的不仅仅是文本预测系统——它们是构建智能体（agent）智能的基础。这些模型作为第一章中组件之间的通信模式章节概述的智能体架构中的推理引擎，其中认知核心（Cognition Core）在感知、规划、记忆和执行组件之间进行协调。理解它们的能力、局限性和集成模式对于构建有效的智能体架构至关重要。在本节中，我们将研究驱动现代智能系统的认知引擎，以及如何有效利用它们的能力。

模型选择与集成

语言模型的选择从根本上决定了你的智能体能够感知、理解和生成什么。模型在能力频谱、专业化程度、上下文窗口、推理性能和运行特性方面存在差异。选择语言模型时需要考虑的因素：

• 模型从轻量且快速（尽管在复杂推理、事实检索或特定领域知识方面存在局限，例如 Mistral 7B）到功能强大但计算密集型的系统，例如 GPT-4、Claude 3、Gemini 以及其他以先进的问题解决和逻辑推理能力闻名的尖端模型。

• 某些模型擅长编码，另一些则擅长创意内容生成或多轮推理。

• 上下文窗口范围从 8K 到超过 1M 个 token。

• 托管选项、定价模型和速率限制差异巨大。

• 许可协议：模型可以是开源权重的（允许完全访问模型权重以进行本地部署和微调），也可以是闭源（通过 API 访问，由第三方提供商管理），影响控制权、定制性和长期成本。

混合模型架构

模型集成最引人的迷的方法可能是混合架构——即多个模型协作，每个模型处理与其优势相匹配的任务。这种方法类似于认知分工，不同的模型在统一的系统中承担专门的功能。这种混合方法与第一章中多智能体系统：协作智能章节中描述的多智能体系统非常契合，其中专门的智能体通过协作实现复杂目标。在混合模型架构中，我们在模型层面而非智能体层面实现了这种协作专业化原则，创造了一场由专门化认知引擎协同工作的交响乐。让我们来看演示这种方法的部分代码：

def route_to_model(self, query, query_type, conversation_history=None):
    """Route query to appropriate model based on classification."""

    if query_type == QueryType.FACTUAL:
        return self._generate_mistral_response(query, conversation_history)
    elif query_type == QueryType.CREATIVE:
        return self._generate_claude_response(query, conversation_history)
    elif query_type == QueryType.ANALYTICAL:
        return self._generate_gpt4o_response(query, conversation_history)

这段代码展示了混合模型的实际实现。系统首先将传入的查询分类为类别（事实、创意或分析），然后将每个查询路由到最合适的专门模型。例如，简单的事实性问题由 Mistral 高效的 7B 模型处理以保证速度和成本效益；而复杂的创意任务则路由到 Claude 以利用其卓越的创意能力，分析性工作则利用 GPT-4 的推理优势。这个编排层使系统通过确保每个查询都由最适合它的模型处理，从而优化性能和成本。同时，考虑不同模型之间的 token 归一化也至关重要，因为独特的分词方法意味着相同的输入文本可能会导致不同的 token 数量，直接影响成本和对上下文窗口限制的遵循情况。编排层充当 AI 请求的交通调度员，位于用户查询和各种语言模型之间。该编排层将不同类型的查询路由到专门模型——以任何单一模型无法实现的方式平衡性能、成本和能力。在充分理解了如何选择和编排语言模型（从单模型部署到复杂的混合架构）之后，我们现在转向更广泛的工具和服务生态系统，将这些模型转换为生产级的智能体系统。虽然模型提供了认知能力，但支持基础设施使智能体能够记住过去的交互、访问外部数据源、与 API 和工具集成，并在大规模上可靠运行。这一基础设施层是理论潜力变为实际现实的地方。

基础设施：智能体生态系统

在框架和模型之外，存在丰富的支持技术生态系统，它们扩展了智能体的能力并确保可靠运行。就像城市需要建筑之外的基础设施——道路、公用事业、通信网络一样，智能体系统需要处理数据存储、外部交互、评估和监控的专门组件。这一基础设施层直接支持第一章中讨论的互操作协议，其中 MCP（模型上下文协议）和 A2A（智能体到智能体）协议为工具发现、调用和协作消息建立了标准接口。我们在本节中探索的支持技术提供了具体的实现，使这些协议能够在生产环境中运行。这些基础设施组件将理论潜力变为现实，使智能体能够感知环境、采取有意义的行动并随着时间的不断改进。掌握这些支持技术至关重要，因为它们决定了你的智能体是孤立的原型，还是能够进行真实世界部署的可扩展系统。你的记忆系统的质量影响智能体从经验中学习的程度；你的工具集成方法决定了智能体可以采取哪些行动；你的评估框架揭示了智能体是否按预期运行；你的监控基础设施确保了大规模的可靠运行。理解这些组件使你能够构建不仅智能而且健壮、可观测且不断改进的智能体。

记忆革命：向量数据库如何为 AI 智能体加速

想象你问朋友去年的一段对话。他们回忆细节的能力不仅取决于内存容量，还取决于大脑索引和检索信息的方式。同样，为了让 AI 智能体在我们的世界中智能地运行，它们不仅仅需要原始处理能力——还需要一个理解含义而非仅仅匹配单词的记忆系统。

为什么传统搜索无法通过智能测试

想象一下：你正在排查代码，并搜索如何修复运行时错误。尽管网上有数以万计的相关资源，但你的搜索返回了无帮助的结果，因为最相关的解决方案使用了不同的术语来描述同一个概念，例如“调试代码异常”——它们在语义上相同但在词汇上不同。这不仅令人沮丧，更是纯基于关键词搜索的一个根本局限性。传统的搜索就像在拥挤的火车站通过大喊某人的名字来寻找他们，希望他们回应。只有当他们正在听这个名字时，这种方法才有效。虽然许多现代检索系统将关键词方法与更先进的技术相结合，但在搜索概念相关性时，仅依赖精确单词匹配的局限性就显而易见了。向量搜索因此出现了：这是一个范式转移，它理解的是概念，而不仅仅是关键词。这就像是一个只检查书名的管理员与一个理解你想要实现什么目标的管理员之间的区别。这种概念理解如何运作的细节细节——通过高维数学表示和语义相似性计算——将在下一节中探讨。通过使用 OpenAI 的 text-embedding-ada-002 等模型将文本转换为高维语义向量，向量搜索捕捉了意义的本质。两个用不同词表达相同思想的文本现在在这个意义的数学空间中“彼此”在一起。

深入探索：OpenAI 的嵌入乐场 (https://platform.openai.com/docs/guides/embeddings) 让你直可视化相似的概念是如何聚集在一起的，即使措辞不同。

魔法背后的数学

向量数据库听起来可能复杂，但其核心原理非常直观：将意义表示为空间中的方向。当你搜索向量数据库时，在后台发生的是一场数学之舞：

1. 你的问题变成了一个向量——本质上是指向高维空间中特定方向的箭头（取决于嵌入模型，例如 768、1,024 或 1,536 维）。

2. 数据库找到指向相似方向的已存储向量。

3. 最接近的向量（通过 cosine similarity 或 dot product 测量）对应于最相关的信息。

这种方法与搜索精确模式匹配的传统数据库截然不同。它是“找到这些精确的单词”与“找到这个概念”之间的区别。真正的魔法发生在近似近邻 (ANN) 算法中，如 Hierarchical Navigable Small World (HNSW) 或 Inverted File Index (IVF)，它们使得在毫秒内搜索数十亿高维向量成为可能。

冷知识：没有这些算法突破，在十亿向量数据库中找到最近的向量需要几分钟而不是毫秒。高效高维搜索的数学是让现代 AI 助手成为可能。

向量数据库格局：谁是谁

向量生态系统正在迅速进化，不同的平台针对不同的需求进行了优化：

• Pinecone – 专家：从底层开始为向量搜索构建。当毫秒至关重要且你需要云原生扩展时，Pinecone 可以胜任。它的 upsert API 让实时知识更新变得轻而许多 (pinecone.io (`https://www.pinecone.io/))

• Weaviate – 混合力量：在 GraphQL 接口将向量搜索与传统过滤相结合。当你的用户既需要语义理解又需要精确元数据过滤时，它是完美的 (weaviate.io (`https://weaviate.io/))

• Chroma – 开发者的朋友：轻量级、开源，并旨在让本地开发变得愉快。当你想在几分钟而不是几小时内原型 RAG 系统时，Chroma 表现优异 (trychroma.com (`https://trychroma.com/))

• Milvus – 企业基础：为大规模和复杂部署而构建。当你的向量搜索需要处理跨分布式系统的数十亿条记录时，Milvus 提供了工业级的能力 (milvus.io (`https://milvus.io/))

• Qdrant – 可靠的开源竞争者：Qdrant 为高性能、生产就绪的向量搜索设计。具有健壮的过滤功能、对负载索引的支持以及无缝集成到 RAG 流中，它平衡了开发者灵活性与企业级能力 (qdrant.tech (`https://qdrant.tech/))

你应该选择哪一个？诚实的答案是这取决于你的特定需求。对于早期实验，Chroma 的简单是不可比拟的。对于处理敏感数据的生产系统，自托管的 Weaviate 或 Milvus 可能更好。对于没有运营开销的纯云性能，Pinecone 很有吸引力。

构建你 AI Agent 的大脑

当向量数据库集成到代理架构中时，它们真正大放异彩。将它们想象是你 AI 系统的海马体——负责形成、索引和检索记忆的结构。向量数据库的最佳选择通常取决于关键因素，例如所需的规模、检索延迟的服务水平协议 (SLAs) 以及为了合规性数据驻留的要求。为了看到这些想法的应用，请考虑向量数据库如何支撑检索增强生成 (RAG) 流水线——使 AI 系统能够实时检索相关知识并将其纳入推理中。一个简单但强大的 RAG 流如下如下：

1. 分块你的知识：将文档拆分为易于处理的部分（通常为 500–1000 tokens）

2. 嵌入所有内容：将分块转换为向量（称为 embedding），以机器可以理解和比较的方式捕捉分块的意义。这些向量允许语义搜索和相似性匹配。

3. 带元数据存储：将向量与源信息和时间戳一起保存

4. 按需检索：当代理需要上下文时，找到相关的向量

5. 注入提示词：在 LLM 响应之前将这些上下文知识馈给它

这种方法之所以具有革命性，是因为你的代理的知识变成了动态的而不是静态的。新信息可以持续添加到向量存储器中，立即增强代理的能力。

如 LangChain (docs.langchain.com (https://python.langchain.com/docs/introduction/)) 和 CrewAI (github.com/joaomoura/crewai (https://github.com/crewAIInc/crewAI)) 等框架为构建这些流水线提供了优雅的抽象。

第一阶段向量检索能帮你找到相关内容的区域，但重排序器（rerankers）能帮助你找到精确的房屋。像 Cohere 的 reranker 或 Sentence Transformers 的 cross-encoders 等模型会对查询-文档对进行详细检查，从而大幅提高精度。

元数据：你的秘密武器

纯语义搜索虽然强大，但将其与元数据过滤相结合可以产生魔法。想象不仅通过含义，还可以通过：

• 时效性（优先考虑新信息）

• 来源权威性（偏经过验证的来源）

• 部门相关性（关注特定的业务部门）

• 用户交互历史（个性化检索）

可观测性：透视黑箱

当检索失败时，理解原因至关重要。像 LangSmith (smith.langchain.com) 等工具让你可视化：

• 检索了哪些块

• 它们获得了什么样的相似性评分

• 它们是如何影响最终响应的

这种观测性让 RAG 从神秘变得可管理。

展望：内存增强的未来

我们正见证内存增强 AI 智能体的开始。未来的系统可能具有以下特征：

• 多模态向量存储：将图像、音频和文本嵌入到统一空间中

• 推理感知检索：系统不仅理解存在哪些信息，还理解哪些信息有助于解决特定的推理任务（这一能力目前是活跃的研发领域）

• 自演进的内存：智能体根据用户反馈完善自己的分块和检索策略

向量数据库不仅仅是技术上的改进——它们代表了 AI 系统与知识之间关系的根本性转变。它们将 LLM 从静态、冻结的知识系统转变为动态的推理器，能够纳入新信息并适应变化的环境。然而，这种向可变内存的转变引入了新的挑战，特别是关于实时更新的写入延迟以及确保分布式内存存储之间的数据一致性问题。对于构建下一代 AI 智能体的开发者来说，掌握向量检索不是可选的——它是创建一个智能聊天机器人与构建真正智能助手之间的区别。

智能的衡量在于改变的能力。

— 阿尔特·爱因斯坦

这句话不仅适用于人类，也适用于我们的 AI 系统。向量数据库赋予了智能体改变其所知的能力——这是迈向真正机器智能的第一步。在探索了向量数据库如何彻底改变智能体内存和知识检索之后，我们现在转向让智能体与外部世界交互并操作的机制。内存系统允许智能体学习和记忆信息，而工具集成框架在智能体的内部推理与其采取具体行动的能力之间提供了关键桥梁——从 API 调用、数据库查询到文件操作和系统命令。

工具集成框架

工具是智能体智能的解放，使其能够超越数字限制并操纵世界。在“感知-推理-行动”循环中，工具代表了思想转化为结果的时刻。可用工具的生态系统庞大且不断扩展——从简单的 API 封装器和数据库连接器到复杂的自动化平台和专业的领域工具。我们并没有尝试列出详尽的目录，而是专注于支持几乎所有智能体-工具交互的最两个基础的集成模式：用于 Python 开发的LangChain的Tool抽象，以及用于直接模型集成的OpenAI的function calling（函数调用）。注意的是，这两种方法并不是互斥的；例如，LangChain可以使用StructuredTool类封装OpenAI的 JSON Schema，允许开发者在LangChain智能体中使用OpenAI强大的函数调用能力。理解这些核心模式为集成任何工具提供了基础，无论其具体的实现或领域如何。

LangChain Tools

LangChain提供了Tool抽象，这是一种强大的模式，可以将普通的 Python 函数转换为智能体兼容的工具。这种抽象处理了语言模型与外部系统之间复杂的编排，自动管理输入验证、错误处理和响应格式。Tool封装器本质上创建了一个智能体可以可靠发现和调用的标准接口，Python 函数在此转换为生产环境中的可靠工具：

from langchain.agents import Tool
def get_stock_price(ticker: str) -> str:
    """返回模拟的股票价格或处理无效输入."""
    try:
        # 虚拟逻辑：在真实场景中，这可以调用 API
        if not ticker.isalpha():
            raise ValueError("Invalid ticker symbol")
        return f"The price of {ticker} is $123.45"
    except Exception as e:
        return f"Error fetching stock price: {str(e)}"
tool = Tool(
    name="StockPriceTool",
    func=get_stock_price,
    description="Fetches the current price of a stock"
)

这个示例展示了Tool模式的简单性：我们从一个普通的 Python 函数开始，它接受股票代码并返回价格信息。然后Tool封装器将该函数与智能体可以理解的元数据打包——一个用于识别的描述性名称、实际执行的函数，以及对工具用途的清晰描述。当智能体需要股票价格信息时，它可以通过名称和描述发现此工具，然后通过带有适当参数的底层函数来调用。Tool抽象处理了智能体推理过程与函数执行之间桥接的所有复杂性。

OpenAI function calling

OpenAI的函数调用通过基于 JSON 的 Schema 提供了一套复杂的命令系统：

{
  "name": "get_weather",
  "description": "Get the weather for a city",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string" }
    },
    "required": ["city"]
  }
}

此 JSON Schema 定义了一个智能体可以调用的天气函数，指定了函数名称、其用途以及带有数据类型的必需参数。与LangChain以 Python 为中心的方法不同，OpenAI的函数调用使用跨越不同语言和平台的标准 JSON Schema。语言模型可以解释此 Schema 以理解函数的功能以及如何正确调用它，从而在对话期间生成格式正确的函数调用。在有了健壮的工具集成让智能体能够在世界中采取行动后，我们的下一个重点转向如何通过全面的评估和基准测试系统确保这些行动产生预期的结果。

云原生智能体开发平台：托管军库

本节提供了 LLM Agent（智能体）开发云原生平台的对比概述，参考了行业报告和云提供商的文档。开源框架为自定义实现和特殊需求提供了无与伦比的灵活性和控制力，而主要的云提供商——Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud——提供了强大的托管平台，旨在简化生产环境中 LLM Agent 的开发、部署和扩展。这些云原生解决方案抽象了大部分底层基础设施的复杂性，提供了核心能力，如多智能体协作、RAG（检索增强生成）、记忆保留以及用于安全和可靠性的集成护栏。代理工程领域日益增长的趋势是混合方法，即结合这些托管云服务在基础基础设施和核心 LLM 访问方面的优势，以及开源框架在定义复杂代理逻辑和自定义工具集成方面的优势。本节将探索各家主要云供应商的核心产品，重点介绍它们的原生工具、集成能力和部署考虑。

AWS：灵活的生态系统

AWS 提供了一全套用于构建和部署 LLM Agent 的服务，其特点是模型选择广泛且与现有 AWS 服务有深度集成。

原生工具：Amazon Bedrock Agents

Amazon Bedrock是 AWS 旗舰级的生成式 AI 托管服务，通过单一 API 端点访问多种基础模型（FMs），包括 Amazon 的Titan模型以及第三方模型，如Anthropic Claude、AI21 Labs Jurassic、Cohere Command、Meta's Llama 2和Stability AI。Bedrock支持按需使用以及微调和 RAG 等自定义技术。AWS 内部的一个独特功能是Amazon Bedrock Agents，这是一项完全托管的服务，用于构建和扩展能够自主执行复杂任务的生成式 AI 机器人。关键特性包括：

• 多智能体协作：Bedrock Agents支持编排多智能体工作流，由单个主管（协调器）智能体管理链式任务代理的执行。虽然这实现了分工协作和模块化任务处理，但它目前遵循的是中心化协调模型，而不是去中心化的智能体间协作。

• RAG：Bedrock Knowledge Bases提供了全托管的 RAG 工作流，负责处理文档摄入、向量数据库中的嵌入存储以及从你的数据中检索上下文。它可以连接到数据库和S3等各种数据源。值得注意的是，它支持使用自然语言进行结构化数据检索。

• 编排与多步任务：Bedrock Agents使用基础模型的推理能力来分析用户请求，将其分解为逻辑序列，并自动调用必要的 API（定义为“动作组”）。AWS Step Functions是一个强大的无服务器编排器，可以跨多个步骤排序并管理状态，并直接与BedrockAPI 调用集成。

• 记忆保留：智能体可以在交互中维护对话历史，以提供个性化且无缝的用户体验，并提高多步任务的准确性。

• 代码解释：该服务支持在安全环境中动态生成和执行代码，实现复杂的分析查询和数据分析。

• 提示词工程：Bedrock Agents可根据用户指令、动作组和知识库自动创建提示词模板，开发者可以对其进行精炼。

• 护栏：内置的安全和可靠性功能（如Amazon Bedrock Guardrails）可以过滤用户输入和模型响应中的有害内容。然而，这些护栏目前仅支持预定义的审核配置——尚不支持自定义策略脚本或深度定制的安全规则。

对于托管自定义模型或开源 LLM，Amazon SageMaker提供了将任何模型部署到具有自动扩展能力的托管端点的功能。此外，SageMaker JumpStart为Llama 3、Mixtral等热门开源模型提供了预构建的推理容器和部署模板——显著减少了生产级部署的运营工作。

在 AWS 上集成开源框架

AWS 积极支持流行的开源 LLM Agent 框架的集成：

• LangChain 和 LangGraph：有一个的langchain-aws工具包和官方示例，展示了如何将LangChain（以及LangGraph）与Bedrock集成。LangChain代理可以直接调用AWS Lambda函数作为工具。

• Strands Agents：AWS 推出了Strands Agents，这是一个通过模型驱动方法进行 AI 开发的开源 SDK。它允许通过自然语言提示词、工具和模型定义代理（通过LiteLLM支持Bedrock等其他模型）。

• 模型上下文协议 (MCP)：AWS 支持MCP，这是一种定义 AI 模型如何连接到各种数据源或工具的开放标准，旨在标准化智能体与工具的交互并促进企业内部的用（注意：MCP规范目前处于草稿阶段，可能会发生变化）。SageMaker AI在托管通过MCP服务器实现的工具执行动作的 LLM 起着至关重要的作用。

AWS 部署架构

AWS 提供灵活的部署架构：

• 无服务器 (AWS Lambda, API Gateway)：Lambda函数是事件驱动应用和微服务的理想选择，作为由Amazon API Gateway触发用于实时交互的 LLM Agent 核心逻辑。这种设置提供了自动扩展和按需付费模式。

• 容器化 (Amazon ECS, Amazon EKS)：对于复杂的、分布式或有状态的 LLM Agent 应用程序，AWS 提供了Amazon Elastic Container Service (ECS)和Amazon Elastic Kubernetes Service (EKS)。ECS是 AWS 专有的容器编排平台，具有成本效益并与其他 AWS 服务深度集成。基于 Kubernetes 构建的EKS提供了管理大规模容器化应用的丰富功能和更强的开源支持。实现代理工具的MCP服务器可以托管在EC2、ECS或EKS上。

Azure：企业级动力源

Microsoft Azure 为开发和部署 LLM Agent 提供了一个强大且集成的生态系统，特别是对于深度嵌入微软生态系统的组织。

原生工具：Azure AI Foundry Agent Service

Azure OpenAI Service是 Azure 的旗舰产品，提供了对 OpenAI 模型（GPT-3.5 Turbo、GPT-4、Codex、DALL-E 2）的 API 访问，这些模型托管在微软云数据中心，具有企业级的安全性和合规性。注意 GPT-4o 目前仅支持多租户模式。Azure AI Foundry Agent Service 是一个统一平台，旨在为企业环境构建、部署和运行由 LLM 驱动的智能代理。它被概念化为代理工厂，在多个维度具有全面的能力：

• 模型：从不断增长的目录中选择，包括Azure OpenAI模型、Llama、Mistral和Cohere。

• 自定义：通过微调、蒸馏或领域提示词对模型进行定制，以编码代理行为。

• AI 工具：智能体配备了访问企业知识（例如Bing、SharePoint、Azure AI Search）并并通过Azure Logic Apps、Azure Functions或OpenAPI采取行动的能力。

• 编排：“连接的代理体”负责管理工具调用、更新线程状态并处理重试。Azure AI Foundry 支持具有内置代理体间消息传递的多代理体协作。Azure Logic Apps 是一种类似于 AWS Step Functions 的无服务器工作流引擎，适用于定义 LLM 代理流并与各种服务集成。Azure Durable Functions（Azure Functions 的扩展）允许通过代码编写编排函数以处理复杂的序列。Azure AI Studio Prompt Flow 提供了一个可视化画布，用于链接提示词和 Python 代码节点。

• 信任：企业级功能确保了可靠性，包括通过 Microsoft Entra 进行身份管理、基于角色的访问控制 (RBAC)、内容过滤、加密和网络隔离。

• 观测性：AI Foundry 捕获日志、跟踪和评估，具有全线程级可见性并与 Azure Application Insights 集成。

Azure 还提供了“OpenAI on Your Data”，这是在 Azure AI Studio 中用于 RAG 的简化设置方案，它可以自动使用 Azure Cognitive Search 为聊天模型索引并检索数据。

在 Azure 上集成开源框架

Azure AI Foundry Agent Service 显式支持结合各种开源 SDK：

• Semantic Kernel：Semantic Kernel 中的AzureAIAgent提供了高级的对话能力和无缝的工具集成，专注于企业级就绪性、安全合规性。

• AutoGen：由微软研究院开发，AutoGen 将一切构化为专业代理体之间的异步对话，适用于多轮对话和实时工具调用。Azure AI Agent Service 可以将 AutoGen 中定义的单个代理体编排成复杂的多代理体工作流。

• LangChain：虽然集成深度不如 Semantic Kernel 或 AutoGen，但 LangChain 代理体可以部署在 Azure 的计算服务（如 Azure Container Apps Dynamic Sessions）上，以为代码解释器提供安全的沙箱环境。

在 Azure 上的部署架构

Azure 提供了灵活的部署选项：

• 无服务器 (Azure Functions, Azure Container Apps)：Azure Functions 适用于部署 Semantic Kernel SDK 和 AutoGen 多代理体应用，提供自动扩展和成本效益。Azure Container Apps 可以托管带有 AI 代理的 Web 端聊天应用程序，并为代码执行提供安全隔离的沙箱环境。

• 容器化 (Azure Kubernetes Service - AKS)：AKS 是一种托管的 Kubernetes 服务，非常适用于需要大规模容器编排和对 Kubernetes 环境进行深度控制的复杂分布式应用。

Google Cloud：AI 创新中心

Google Cloud 利用其在 AI 研究领域的领先地位和基础设施实力，提供高度可扩展且成本效益的 AI 服务，并战略性地关注互操作性和企业搜索。

原生工具：Agentspace, Vertex AI Agent Builder/Engine/ADK

Google Cloud 的 LLM 中心是Vertex AI，特别是其生成式 AI 产品，如 PaLM 2 和即将推出的 Gemini 模型系列。Vertex AI 还通过其 Model Garden 包含了 Meta 的 Llama 2 等特定的外部模型。Google Cloud 提供了一套用于构建和部署 LLM 代理体的集成服务：

• Agentspace：用于企业工作的搜索和 AI 代理体中心，将应用程序连接到 Google 品的多模态搜索和 AI 代理体。它包含“代理设计器”（Agent Designer）和“代理库”（Agent Gallery）。注意 Agentspace 目前处于私测预览阶段。

• Vertex AI Agent Builder：用于发现、构建和部署 AI 代理体的全面功能 set。

• 代理体开发包 (ADK)：一个开源、框架无关的框架，通过对代理体行为的精确控制，简化了复杂的多代理体系统的创建。它驱动了 Agentspace 并简化了多代理体传输和规划。

• Vertex AI Agent Engine：一种全托管的 Google Cloud 服务，用于在生产环境中部署、管理和扩展 AI 代理体。它抽象了低级任务，并处理基础设施、扩展、安全、评估和监控。

Agent2Agent (A2A) 协议：Google 正在积极开发开放的 A2A 协议，以实现 AI 代理体之间的互操作性，无论其底层框架或供应商为何。

模型上下文协议 (MCP)：Google Cloud 还支持 MCP，这是一种代理体以标准化方式连接并利用外部工具及数据源的开放协议。

Google Cloud 的代理工具适用于多种用例，包括企业搜索、内容生成和自动化。作为 Agent Builder 部分的 Vertex AI 扩展允许代理体连接到 Google Workspace 和其他外部 API。

在 Google Cloud 上集成开源框架

Vertex AI Agent Engine 设计为与框架无关，为流行的开源 LLM 框架提供灵活支持：

• LangChain, LangGraph：Vertex AI Agent Engine 提供与 LangChain 和 LangGraph 的完全集成。LangChain 也可以通过LangServe部署在 Google Cloud Run 和 Google Kubernetes Engine (GKE) 上。

• AutoGen, LlamaIndex：通过 Vertex AI SDK 与托管模板集成的支持。

• CrewAI：通过 Vertex AI Agent Engine 上的自定义模板支持。

Google 对ADK和 A2A 协议等开源工具的关注旨在为 AI 代理体培养更广泛、更互操作的生态系统，减少供应商锁定。

在 Google Cloud 上的部署架构

Google Cloud 提供了灵活且可扩展的部署选项：

• 无服务器 (Cloud Run)：一个全托管无服务器平台，为 AI 应用负载和代理体提供可扩展的环境。它根据需要自动扩展实例，提供按需付费模型，并与 Gemini API 或 Vertex AI 端点集成。Cloud Run 可以配置为沙箱化代码执行。

• 容器化 (Google Kubernetes Engine - GKE)：GKE 是一种托管的 Kubernetes 服务，适用于复杂的微服务架构、有状态应用以及需要自定义基础设施或网络配置的负载。LangServe可以简化 GKE 上的 LangChain 部署。Cloud Run 和 GKE 提供了高移植性，允许在两者之间运行相同的容器镜像。

对于核心代理体推理之外的任务（如模型训练、微调和持续 RAG 更新）的健壮工作流编排，Vertex AI Pipelines提供了一种定义和执行这些复杂 ML 工作流的托管服务。

云平台选择建议

“最佳”的云平台取决于特定的项目需求和现有的组织基础设施：

• 对于 AWS：适用于已深耕 AWS 生态系统的组织，重视灵活性、多样化模型以及与现有 AWS 服务和数据湖的深度集成。它对多代理体协作和边缘分布式推理的关注使其适用于复杂、大规模的部署。

• 对于 Azure：当必须使用尖端 OpenAI 模型（GPT-4），或需要将 AI 集成到以微软为中心的组织（Office 365, Dynamics, Teams, SharePoint）时是首选平台。Azure AI Foundry 提供了统一的平台体验，对代理体具有强大的治理和身份管理，吸引优先考虑简化运营和合规性的用户。

• 对于 Google Cloud：对于那些重视成本效益的扩展、Google 的 AI 研究优势以及更强调开放标准和易工具连接的“整体”代理平台的人来说是一个强有竞争者。它在企业搜索和多模态 AI 方面的优势，结合 Cloud Run 等快速部署选项，使其对偏好编码与托管服务混合的开发者具有吸引力。

你所构建的工具包从根本上塑造了你的系统的感知能力、推理方式以及能够采取的行动。本章探讨了核心组件——框架、模型、数据库、集成机制、评估系统和监控解决方案。

这些关于工具包的决策决定了你的实现在智能 AI 演进框架（Agentic AI Progression Framework）中所处的位置。你的选择决定了智能体未来可能成为边界。

随着格局的演变，保持适应性应始终是一个核心设计原则。在下一章中，我们将探索智能体工作流架构——研究决策循环和多步执行路径。