每位 AI 工程师都必须构建的 30 个智能体——智能体工程师工具箱

数据智能老司机
0 阅读47分钟

在智能体中，智能表现为目标导向的自主行为。
—— Andrej Karpathy，前 Tesla AI 总监（2024）

在智能智能体领域，工具定义能力。随着智能体从反应式脚本转向目标导向的自主系统，开发者必须掌握一个不断扩展的框架、模型和基础设施生态系统。本章将对智能体工程领域中的工具进行结构化探索，为你提供实践洞察和比较分析，帮助你在整个技术栈中作出明智选择。想象一下，一个智能体能够实时自主研究市场趋势、综合数据，并起草战略报告。这正是合适工具箱所能释放的力量。

选择合适的工具和框架，是智能体开发过程中的关键决策点。这一选择不仅会显著影响开发时间和运营成本，例如 LLM 推理成本，根据模型和供应商不同，可能从每百万 token 几美分到几美元不等，也会影响最终系统的基本能力。作为一名智能体工程师，你的工具箱定义了智能体能够感知什么、如何推理，以及能够在世界中采取什么行动。

虽然 LLM 提供了驱动现代智能体的认知引擎，但原始模型本身不足以构建有用系统。智能体开发的真正力量，来自于将这些模型与设计良好的工具箱结合起来，使其能够高效进行知识检索，例如由向量数据库和 Facebook AI Similarity Search（FAISS）等库支持的 RAG；进行工具集成，例如通过 OpenAI 强大的函数调用机制；并实现监控和部署。

本章将考察当前使用中的主要智能体框架，回顾选择和优化 LLM 的策略，并深入介绍支持记忆、推理、评估和部署的基础工具。本章并不只是提供一个当前可用选项的快照，因为这些选项可能很快过时；相反，它聚焦于底层原则和模式，即使具体实现发生变化，这些原则和模式仍然相关。

在本书中，我们将主要使用 LangChain 和 LangGraph 作为核心开发框架，因为它们具备稳健生态、生产就绪能力和完整文档。虽然我们也会探索其他框架，以提供背景并帮助你理解更广阔的工具版图，但我们的实践示例、代码实现和深入教程将聚焦于 LangChain 生态系统，写作时版本为 v0.3.x。

本章将覆盖以下主题：

  • 智能体开发框架：架构师蓝图
  • LLM：认知核心
  • 支撑基础设施：智能体生态系统
  • 云原生智能体开发平台

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

框架是构建智能智能体的基础。它们提供结构、强化模式并封装最佳实践，使开发者能够从临时实验转向可重复、可扩展的工程实践。选择框架并不仅仅是工具选择，而是一项战略决策，会影响可扩展性、可维护性和性能。

下面是一张智能体开发框架关键对比表。这张表简明比较了它们的优势、局限和理想用例。

FrameworkStrengthsLimitationsIdeal Use Case
LangChain模块化设计、广泛集成没有原生多智能体支持LLM 流水线、工具工作流
LlamaIndex高级检索、语义压缩需要编排支持文档问答、记忆层
AutoGPT自主目标规划可靠性较低、控制脆弱研究原型
CrewAI基于角色的协调早期成熟度实验性多智能体系统、沙盒化协作原型

表 2.1——智能体开发框架对比

正如第 1 章中关于认知循环模型的部分所讨论的，有效智能体必须持续经历感知、推理、规划、行动和学习的循环。本章探索的框架，会用代码实现这种认知架构，每个框架都有自己组织这些关键功能的方法。

理解这些不同方法非常重要，因为你选择的框架不仅决定你构建和迭代智能体的速度，也决定它们最终能够实现哪些能力。例如，LangGraph 的有向无环图（DAG）模型天然支持复杂、多步骤推理中的并行分支，从而优化复杂工作流中的吞吐；而 CrewAI 的设计则可以支持更快速、更聚焦的线性专业任务对话。每个框架都体现了关于智能体行为的不同假设，为常见模式提供不同抽象，并对底层认知过程提供不同层级的控制。通过考察它们的优势、局限和最佳用例，你将能够围绕具体性能、可扩展性和可维护性需求作出明智决策。

关键框架综合分析

一开始，是混乱：临时拼凑的脚本，模型与工具之间脆弱的连接，以及一旦复杂性增加就崩塌的推理链。后来，框架出现了：它们为智能体架构提供结构化方法，为这片数字荒野带来了秩序。不过，必须承认，虽然框架能显著加快开发并提供结构，但它们也引入了抽象层。抽象有利于快速开发，但有时会降低对底层机制的低层控制和理解。对于基础学习或高度定制化场景，从更直接的 Python 代码开始构建智能体能力，可能在使用完整框架之前提供更深洞察。每个框架都代表一种关于智能应如何在代码中被组织的不同哲学。

LangChain

LangChain 在 GitHub 上拥有超过 70,000 颗星，像数字天幕中的明星一样，是智能体框架中的资深代表。它的计算图模型呼应了认知科学中关于序列推理的理论，也常被称为 chain-of-thought processing，使开发者能够由更简单的构件组合出复杂行为。这种设计使智能体能够遵循逐步推理流水线，其中图中的每个节点对应一个认知或功能操作，类似人类将问题拆解为连续子任务的方式。

LangChain 的架构围绕几个核心抽象构建，本书后续会大量使用这些抽象：

Chains 链：连接多个组件的顺序处理流水线。LangChain 还提供稳健的 callback 和 tracing 机制，使开发者能够观察、记录和调试这些链的执行流，这对理解复杂智能体行为至关重要。

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

# Define tools the agent can use

def calculator(expression: str) -> str:
    """Safely evaluate mathematical expressions."""
    try:
        result = sympify(expression)
        return str(result)
    except Exception:
        return "Invalid mathematical expression"

# Use DuckDuckGoSearchRun tool provided by LangChain
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")
]

# Initialize the agent
llm = OpenAI(temperature=0)
agent = initialize_agent(
    tools=tools,
    llm=llm,
    agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION,
    verbose=True
)

# Ask the agent to reason about tool usage
result = agent.run("What's the square root of 144, and can you find recent news about that number?")

这个示例展示了 LangChain 的力量：智能体会自动判断自己同时需要数学计算能力和网络搜索能力，并以合适顺序执行这些能力，然后综合结果。ZERO_SHOT_REACT_DESCRIPTION 智能体类型实现了 Reasoning and Acting（ReAct）模式，模型会先推理应该采取什么行动，然后基于这些决策行动。

LangChain 的记忆系统尤其复杂，支持多种记忆类型：

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

# Buffer memory keeps exact conversation history
buffer_memory = ConversationBufferMemory(
    memory_key="chat_history",
    return_messages=True
)

# Summary memory compresses older conversations
summary_memory = ConversationSummaryMemory(
    llm=OpenAI(),
    memory_key="chat_history",
    return_messages=True
)

LangChain 丰富的生态包含超过 100 个预构建集成，支持 OpenAI、Anthropic、Google、Amazon Web Services（AWS）、向量数据库（Pinecone、Chroma、Weaviate）以及大量 API 等热门服务。这种生态丰富度意味着，大多数集成挑战已经被社区解决并测试过。

从本质上看，LangChain 是对模块化的研究：链用于顺序处理，工具用于环境交互，记忆系统用于在对话的数字突触之间维护上下文。其丰富组件库显著减少了实现常见智能体模式所需的代码，使开发者能够专注于自身系统的独特部分。

然而，LangChain 的灵活性也带来复杂性。框架的大量抽象层可能引入性能开销，如果没有 LangSmith 等合适的可观测性工具，调试复杂链也会很有挑战。就像传统软件工程从简单 print 语句，演进到结构化日志，再到完整可观测性平台一样，智能体工程也需要类似进步，以确保复杂认知工作流的透明度和可调试性。此外，虽然 LangChain 擅长单智能体场景，但对于复杂多智能体系统，它需要额外编排，而这正是 LangGraph 变得必要的地方。

参考 URL：www.langchain.com/

LangGraph

LangGraph 代表着 LangChain 向有状态、循环工作流方向的演化，这类工作流更接近人类认知过程。LangChain 链通常是线性的，而 LangGraph 支持带循环、条件逻辑和复杂状态管理的分支决策树。这种可视化且有状态的方法显著缓解了复杂智能体行为调试中的痛点；进一步的透明度可以通过 LangSmith 等专门可观测性工具，或通过集成标准 OpenTelemetry hooks 实现完整 tracing 和 monitoring。

从核心上看，LangGraph 将智能体工作流建模为有向图：

  • Nodes 节点代表离散处理步骤或智能体函数。
  • Edges 边定义步骤之间的流转。
  • State 状态在节点之间维护和传递。
  • Conditional routing 条件路由支持动态决策。

这种架构特别适合实现第 1 章讨论的认知循环，在这个循环中，智能体必须经历感知、推理、规划和行动阶段。下面是一个实践示例：

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

# Define the agent's workflow nodes
def research_node(state):
    """Gather information about the topic."""
    query = state.get("user_query")
    search_tool = DuckDuckGoSearchRun()  # safer to specify
    research_results = search_tool.run(query)
    return {"research_data": research_results, "next": "analyze"}

def analyze_node(state):
    """Analyze the gathered information."""
    research_data = state.get("research_data")
    # In a real system, plug in LLM/analysis logic here
    analysis = f"Analysis of: {research_data[:200]}..."
    return {"analysis": analysis, "next": "decide"}

def decide_node(state):
    """Decide whether more research is needed."""
    analysis = state.get("analysis")
    # Loop condition with optional MAX_ITER
    if "insufficient data" in analysis.lower():
        if state.get("loop_count", 0) >= 3:  # prevent infinite loop
            return {"next": "respond"}
        return {
            "next": "research",
            "loop_count": state.get("loop_count", 0) + 1
        }
    else:
        return {"next": "respond"}

def respond_node(state):
    """Generate final response."""
    analysis = state.get("analysis")
    response = f"Based on my research and analysis: {analysis}"
    return {"final_response": response, "next": "END"}

# Build the graph
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)
# Define transitions
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")

# Compile and run
app = workflow.compile()
result = app.invoke({"user_query": "Latest developments in quantum computing"})
print(result)

这个示例展示了 LangGraph 的关键优势：如果初始分析不充分，智能体可以智能地回到前一步收集更多信息，并在整个过程中维护状态。这种循环能力对于实现复杂推理模式至关重要，而简单链无法做到这一点。

LangGraph 在几个传统 LangChain 表现不足的关键领域表现突出：

  • 带条件分支的多步骤推理。
  • 带审批门的 human-in-the-loop 工作流：LangGraph 允许开发者设计暂停执行并等待外部输入或人工审查的节点，例如在金融交易前等待批准，然后再继续。这使智能体能够在关键决策或复杂任务上与人类协作。
  • 复杂多智能体协调和交接。
  • 跨长时间运行流程的持久状态管理。
  • 复杂错误处理和重试逻辑。

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

# Visualize the workflow
from langgraph.graph import draw_mermaid

# Generate a Mermaid diagram of the workflow
graph_diagram = draw_mermaid(workflow.get_graph())
print(graph_diagram)  # Shows the visual flow of your agent's logic

LangGraph 的状态管理尤其复杂，既支持简单字典状态，也支持复杂的类型化状态 schema：

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

# The graph maintains this typed state throughout execution

LangGraph 将 LangChain 扩展为基于图的架构，把智能体步骤视为 DAG 中的节点。这种推理路径可视化，为智能体决策过程提供了前所未有的透明度。

在实践实现中，LangGraph 对多步骤智能体任务提供精确控制，尤其适合具有分支路径、高级错误处理和状态管理需求的复杂工作流。虽然它比更简单的框架学习曲线更陡，但在复杂企业应用中，这项投入会带来巨大回报。

在本书后续章节中，我们将大量使用 LangGraph 来实现复杂智能体工作流，从简单顺序流程到复杂多智能体编排。它结合了灵活性、可观测性和状态管理，非常适合构建生产级智能体系统。

参考 URL：www.langchain.com/langgraph

LlamaIndex

如果说 LangChain 负责编排，那么 LlamaIndex 负责记忆。LlamaIndex 在 GitHub 上拥有 41,000 颗星，它从根本不同的角度处理智能体开发，优先关注知识集成，而不是流程编排。

LlamaIndex 实现了复杂的数据结构，模拟联想记忆系统，为文档摄取、文本分段和上下文感知检索提供专门组件。它在高级语义索引、层级记忆模型和上下文压缩技术方面表现突出，特别适合智能体必须在海量信息海洋中导航的应用。

从核心上看，LlamaIndex 通常通过以下流水线运行：

Index 索引：该组件接收原始数据，例如文档、文本等，并将其处理为可查询结构，通常涉及嵌入并存储到向量数据库中。

Query engine 查询引擎：该引擎接收自然语言查询，从索引中检索相关信息，并将其传递给 LLM。

Response synthesizer 回应综合器：将检索到的信息和 LLM 的理解综合为连贯的最终答案。

虽然 LlamaIndex 不是完整的编排解决方案，但它非常适合作为大型智能体系统中的记忆皮层，尤其适用于企业知识助手或研究 copilot 等应用，因为这些应用必须在海量文档空间中保持连贯理解。在 LangChain 或 LangGraph 工作流中，LlamaIndex 的 Query Engine 可以作为一个专门工具无缝集成，使智能体在需要从知识库中检索上下文感知信息时调用它。

参考 URL：www.llamaindex.ai/

AutoGPT

在智能体框架生态中，AutoGPT 曾经大胆梦想一种激进能力：真正自主的目标导向行为。它在 GitHub 上拥有惊人的 150,000 颗星，让世界认识到递归式自我提示，使智能体能够在没有人工介入的情况下，将高层目标分解为可执行子任务。

AutoGPT 实现了面向目标分解、任务规划和自主工具选择的高层抽象，与目标导向认知系统的理论模型相一致。它的方法使开发者能够创建以最少人工监督追求复杂目标的智能体。

这种自主性也有代价。控制机制仍然脆弱，生产部署需要谨慎配置，才能保持与用户意图对齐。尽管如此，AutoGPT 对真正自主性的追求，暗示了智能体架构的未来可能性。

参考 URL：github.com/Significant…

CrewAI

在本次框架探索中，最新竞争者带来了一种不同哲学：基于角色专业化和多智能体协作。CrewAI 抽象了一个“crew”，也就是团队共同协作，并被分配不同角色来处理复杂任务的概念。

在 CrewAI 中，每个智能体都用角色、目标和背景故事等属性定义，从而在协作系统中创建不同 persona，也就是人格。智能体通过内置消息和委派机制通信，本质上是在相互“出声思考”，以规划和解决问题。

CrewAI 在 GitHub 上已有 30,000 颗星，并持续增长，它代表着向更结构化协作智能的转变，其中专门智能体在中心编排器指导下组合各自能力。

截至 0.4 版本，CrewAI 引入了与 LangChain 更紧密的集成，依赖 LangChain 的 agent 和 Tool 抽象来支持工具使用和编排。这使 CrewAI 特别适合已经使用 LangChain 工作流的团队，不过也引入了一些依赖方面的考量。

参考 URL：github.com/crewAIinc/c…

AutoGen

AutoGen 由 Microsoft 开发，它采用一种独特的智能体编排方法：把 LLM 视为对话参与者。AutoGen 不只聚焦于智能体角色定义或目标分解，而是引入了一种对话式编程范式，在这种范式中，每个由 LLM 支撑的智能体通过消息互动，共同解决任务。

AutoGen 通过将智能体定义为带角色的函数，例如用户代理、代码执行器、规划器，并通过可定制的消息传递循环连接起来，支持复杂、有状态的多智能体工作流。这种结构允许动态协调、自适应规划和工具调用，并比反应式智能体提供更高程度的控制。

它的优势在于细粒度编排，使开发者能够显式管理轮次、输入/输出流和停止条件。AutoGen 越来越多地被用于企业级应用，因为这些应用重视透明性、协调能力和模块化。

参考 URL：github.com/microsoft/a…

优势、弱点与最佳用例

选择合适的智能体开发框架，是一项战略设计决策，会从根本上塑造系统能力。

LangChain 凭借模块化编排和庞大集成生态表现出色。它在需要快速原型或复杂工具集成的场景中尤其突出。然而，其多层抽象可能在延迟敏感应用中引入性能开销。

LlamaIndex 通过知识中心化设计脱颖而出，提供复杂的语义索引和上下文压缩。需要注意的是，上下文压缩是一种将大量信息提炼为简洁摘要或更聚焦表征的技术，同时仍保留核心含义。这些能力使它成为必须摄取并推理海量文档集合的应用首选框架。

AutoGPT 以其对自主性和目标分解的关注而独树一帜。通过递归式自我提示，它使智能体能够在最少人工指导下围绕高层目标进行规划、执行和迭代。

CrewAI 通过形式化角色专业化解决多智能体编排问题。这种方法有助于分布式推理和任务委派，使 CrewAI 非常适合复杂协作工作流。

虽然每个框架都有不同优势，但现代智能体工程通常受益于一种“mix-and-match”方法，也就是组合不同框架的优势，后面的“构建还是集成”决策部分会详细说明这一点。

构建还是集成的决策

现代智能体工程遵循 compose-over-build，也就是“组合优于从零构建”的理念：通过集成专门组件来组装智能系统，而不是从零开始构建单体架构。

在实践中，大多数团队会采用混合路径：早期开发使用 LangChain 等框架进行编排，然后当具体性能或安全约束出现时，再有选择地用自定义实现替换某些组件。

例如，一个团队可能先使用 LangChain 的内存型 ConversationBufferMemory 实现快速原型，但当持久化、可扩展且语义丰富的记忆成为智能体需求后，再将其替换为 Pinecone 或 Chroma 等生产级向量数据库。

有效集成策略示例包括：

  • 使用 LangChain 进行编排，并结合 LlamaIndex 进行文档检索。
  • 部署 CrewAI + LangChain 来管理分布式智能体角色，需要注意 CrewAI 经常利用 LangChain 的 Tool 抽象来增强功能。
  • 在受监管行业中使用 LangGraph 实现确定性控制。

在探索了从 LangChain 模块化编排到 CrewAI 协作智能等智能体开发框架之后，我们接下来转向驱动这些系统的认知引擎。框架提供组织智能体行为的架构基础，而 LLM 则是将结构化输入转化为智能输出的推理核心。理解如何选择、集成并优化这些模型，是释放所选框架全部潜力的关键。

LLM：认知核心

当我们从框架转向它们所编排的模型时，我们进入了人工认知本身的领域。LLM 不只是文本预测系统；它们是构建智能体智能的基础层。这些模型在第 1 章“组件之间的通信模式”一节所概述的智能体架构中，充当推理引擎，认知核心会在感知、规划、记忆和行动组件之间进行中介。理解它们的能力、局限和集成模式，对于构建有效智能体架构至关重要。本节将考察驱动现代智能系统的认知引擎，以及如何有效利用它们的能力。

模型选择与集成

语言模型的选择，从根本上塑造了智能体能够感知、理解和生成什么。模型在能力谱系、专业化程度、上下文窗口、推理性能和运营特征方面各不相同。

选择语言模型时，需要考虑以下事项：

  • 模型从轻量快速型到高度强大但计算密集型不等。前者在复杂推理、事实召回或特定领域专业能力方面有限，例如 Mistral 7B；后者包括 GPT-4、Claude 3、Gemini 以及其他前沿模型，通常以高级问题解决和逻辑推理能力著称。
  • 有些模型擅长编码，有些模型擅长创造性内容或多轮推理。
  • 上下文窗口从 8K 到超过 100 万 token 不等。
  • 托管选项、定价模型和速率限制差异显著。
  • 许可：模型可以是 open weight，也就是允许完整访问模型权重以进行本地部署和微调；也可以是 closed source，也就是通过 API 访问，由第三方供应商管理。这会影响控制力、定制化能力和长期成本。

混合模型架构

也许最有趣的模型集成方法是混合架构，在这种架构中，多个模型协作，每个模型处理与自身优势匹配的任务。这种方法类似认知劳动分工，不同模型在统一系统中承担专门功能。

这种混合方法与第 1 章“多智能体系统：协作智能”部分描述的多智能体系统非常吻合，在那里，专门智能体协作完成复杂目标。在混合模型架构中，我们是在模型层面而不是智能体层面实现这种协作专门化原则，从而形成一组专门认知引擎协同工作的交响乐。

来看一段展示这种方法的代码：

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 和工具集成，并在规模化条件下可靠运行。这一基础设施层，正是理论潜力转化为实践现实的地方。

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

在框架和模型之外，还有一个丰富的支撑技术生态，用于扩展智能体能力并确保可靠运行。就像城市除了单体建筑之外，还需要道路、公用设施和通信网络等基础设施一样，智能体系统也需要专门组件来处理数据存储、外部交互、评估和监控。

这一基础设施层直接支持第 1 章讨论的互操作协议，其中 Model Context Protocol（MCP）和 Agent-to-Agent（A2A）协议为工具发现、调用和协作消息传递建立标准化接口。本节探索的支撑技术，提供了具体实现，使这些协议能够在生产环境中运行。这些基础设施组件将理论潜力转化为实践现实，使智能体能够感知环境、采取有意义行动，并随时间改进。

掌握这些支撑技术非常关键，因为它们决定你的智能体是停留在孤立原型，还是成为可集成、可扩展并能真实部署的系统。记忆系统质量影响智能体从经验中学习的能力；工具集成方法决定智能体能够采取哪些行动；评估框架揭示智能体是否按预期运行；监控基础设施则确保规模化条件下可靠运行。理解这些组件，使你能够构建不仅智能，而且稳健、可观测并能持续改进的智能体。

记忆革命：向量数据库如何增强 AI 智能体

想象一下，你问朋友去年你们的一次对话。Ta 能否回忆细节，不仅取决于记忆容量，也取决于大脑如何索引和检索信息。同样，如果 AI 智能体要在我们的世界中智能运行，它们需要的不只是原始处理能力；它们需要一种理解意义，而不仅仅是匹配词语的记忆系统。

想象这个场景：你正在排查代码问题，并搜索如何修复运行时错误。尽管网上存在成千上万条相关资源，但你的搜索返回了无用结果，因为最相关的解决方案使用不同术语描述同一概念，例如 “debugging code exceptions”——语义上相同，但词汇不同。这不仅令人沮丧；它也是纯关键词搜索的根本局限。传统搜索就像在拥挤火车站大喊某人的名字，希望对方回应。只有当对方正在听那个完全相同的名字时，它才有效。虽然许多现代检索系统会把关键词方法与更高级技术结合起来，但如果只依赖精确词匹配，当搜索的是概念相关性时，局限就会显现。向量搜索登场：这是一种理解概念而不仅仅是关键词的范式转变。它就像一个不仅检查书名，还真正理解你想完成什么的图书管理员。

这种概念理解如何工作的技术细节，也就是通过高维数学表示和语义相似度计算，将在下一节中探索。

通过使用 OpenAI 的 text-embedding-ada-002 等模型将文本转换为高维语义向量，向量搜索捕获意义的本质。两个用不同词语表达相同想法的文本，如今会在这个数学意义空间中彼此接近。

深入探索：OpenAI 的 embedding playground（platform.openai.com/docs/guides…）可以让你可视化相似概念如何聚集在一起，即使用词不同也是如此。

向量数据库听起来可能很复杂，但其核心原则非常直观：将意义表示为空间中的方向。

当你搜索向量数据库时，幕后发生的是一场数学舞蹈：

  1. 你的问题变成一个向量，本质上是在高维空间中指向特定方向的箭头，例如根据 embedding 模型不同，可能有 768、1,024 或 1,536 个维度。
  2. 数据库寻找指向相似方向的已存储向量。
  3. 最接近的向量，通过余弦相似度或点积衡量，对应最相关的信息。

这种方法与传统数据库搜索精确模式匹配截然不同。它是“找到这些确切词语”和“找到这个概念”之间的区别。

真正的魔法发生在 approximate nearest neighbor（ANN，近似最近邻）算法中，例如 Hierarchical Navigable Small World（HNSW）或 Inverted File Index（IVF），这些算法使在数十亿高维向量中以毫秒级速度搜索成为可能。

趣味事实：没有这些算法突破，在十亿级向量数据库中寻找最近向量将需要数分钟，而不是数毫秒。高效高维搜索的数学，正是现代 AI 助手成为可能的基础。

向量数据库版图

向量数据库生态正在快速演化，不同平台针对不同需求进行了优化：

Pinecone——专业型选手：从一开始就为向量搜索而构建。当毫秒级响应很重要，并且你需要云原生扩展时，Pinecone 可以满足需求。它的 upsert API 使实时知识更新变得非常简单（pinecone.io）。

Weaviate——混合能力强者：通过 GraphQL 接口将向量搜索与传统过滤结合起来。当用户既需要语义理解，又需要精确元数据过滤时，Weaviate 非常合适（weaviate.io）。

Chroma——开发者之友：轻量、开源，并被设计为让本地开发更愉悦。当你想在几分钟而不是几小时内原型化一个 RAG 系统时，Chroma 很突出（trychroma.com）。

Milvus——企业级基础：为大规模和复杂部署而构建。当你的向量搜索需要在分布式系统中处理数十亿记录时，Milvus 提供工业级能力（milvus.io）。

Qdrant——可靠的开源竞争者：Qdrant 面向高性能、生产就绪向量搜索设计。它具备稳健过滤能力、支持 payload indexing，并能无缝集成进 RAG 流水线，在开发者灵活性与企业级能力之间取得平衡（qdrant.tech）。

应该选哪一个？诚实答案是：取决于你的具体需求。早期实验时，Chroma 的简单性很难被击败。对于处理敏感数据的生产系统，自托管 Weaviate 或 Milvus 可能更合适。对于不想承担运维负担、追求纯云性能的团队，Pinecone 很有吸引力。

构建你的 AI 智能体大脑

当向量数据库被集成进智能体架构时，它们会真正闪光。可以把它们看作 AI 系统的海马体，也就是负责形成、索引和检索记忆的结构。向量数据库的最佳选择通常取决于一些关键因素，例如所需规模、检索延迟 SLA，以及合规所需的数据驻留要求。为了看到这些想法如何落地，可以思考向量数据库如何支撑 RAG 流水线，使 AI 系统能够实时检索相关知识，并将其纳入推理。

一个简单但强大的 RAG 流水线如下：

  1. Chunk your knowledge 切分知识：将文档拆分为易消化片段，通常为 500–1,000 token。
  2. Embed everything 全量嵌入：将片段转换为 embedding vectors，也就是嵌入向量，以机器可理解和比较的方式捕获片段意义。这些向量支持语义搜索和相似度匹配。
  3. Store with metadata 携带元数据存储：将向量与来源信息和时间戳一起保存。
  4. Retrieve on demand 按需检索：当智能体需要上下文时，找到相关向量。
  5. Inject into prompts 注入提示：在 LLM 回答前，将上下文知识提供给它。

这种方法的革命性在于，你的智能体知识会变成动态的，而不是静态的。新信息可以持续添加到向量存储中，无需重新训练即可立即增强智能体能力。

LangChain（docs.langchain.com）和 CrewAI（github.com/joaomdmoura/crewai）等框架为构建这些流水线提供了优雅抽象。

虽然基础 RAG 流水线提供了坚实基础，但要构建真正有效的检索系统，需要掌握多种高级技术和最佳实践。一个功能性 RAG 实现和一个卓越 RAG 实现之间的差异，往往就在于接下来这些细致优化：从智能切分策略到复杂重排序算法。

掌握检索的艺术

构建有效检索系统既是科学，也是艺术。下面的小节揭示了将平庸实现与卓越实现区分开的秘密。

切分的黄金区间

片段太小，会丢失关键上下文；片段太大，信号会淹没在噪声中。找到“刚刚好”的 chunk size 通常需要实验。

一种越来越受关注的方法是 hierarchical chunking，也就是分层切分：以多个粒度存储同一内容，例如段落、章节、文档，并在检索时动态选择合适层级。

重排序革命

第一阶段向量检索会把你带到相关内容的“街区”，但 reranker 可以帮你找到精确“门牌号”。Cohere Rerank 或 Sentence Transformers Cross-Encoders 等模型，会详细考察查询—文档对，从而显著提升精度。

元数据

纯语义搜索已经很强大，但将其与元数据过滤结合会产生魔法。想象一下，过滤不只是基于意义，还包括：

  • Recency 新鲜度：优先考虑更新信息。
  • Source authority 来源权威性：偏好已验证来源。
  • Department relevance 部门相关性：聚焦特定业务单元。
  • User interaction history 用户交互历史：个性化检索。

可观测性

当检索失败时，理解为什么失败至关重要。LangSmith（smith.langchain.com）等工具可以让你可视化：

  • 哪些 chunk 被检索到；
  • 它们获得了什么相似度分数；
  • 它们如何影响最终回应。

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

我们刚刚见证记忆增强型 AI 智能体的开端。未来系统很可能具备：

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

推理感知检索：系统不仅理解有哪些信息，也理解哪些信息有助于解决特定推理任务。该能力目前仍是活跃研究和开发领域。

自我改进记忆：智能体能够根据用户反馈优化自己的切分和检索策略。

向量数据库不只是技术改进；它们代表了 AI 系统与知识关系的一次根本转变。它们将 LLM 从静态、冻结知识系统，转变为能够纳入新信息并适应变化环境的动态推理者。然而，这种可变记忆的转向也引入了新的运营挑战，尤其涉及实时更新的写入延迟，以及分布式记忆存储中的数据一致性。

对于构建下一代 AI 智能体的开发者来说，掌握向量检索不是可选项；它是创造一个聪明聊天机器人和构建一个真正智能助手之间的差别。

衡量智能的标准，是改变的能力。
—— Albert Einstein

这句话不仅适用于人类，也适用于我们的 AI 系统。向量数据库赋予智能体改变其所知内容的能力：这是迈向真正机器智能的第一步。

在探索了向量数据库如何革新智能体记忆和知识检索之后，我们接下来转向使智能体能够与外部世界互动并操控外部世界的机制。记忆系统使智能体能够学习和回忆信息，而工具集成框架则在智能体内部推理与其采取具体行动的能力之间架起关键桥梁，从 API 调用和数据库查询，到文件操作和系统命令。

工具集成框架

工具释放了智能体智能，使它能够突破数字边界并操控世界。在 Perception-Reasoning-Action（PRA，感知—推理—行动）循环中，工具代表思想转化为后果的那一刻。可用工具生态庞大且持续扩展，从简单 API wrapper 和数据库连接器，到复杂自动化平台和专门领域工具。我们并不试图列出详尽目录，而是聚焦于几乎所有智能体—工具交互背后的两个最基础集成模式：面向 Python 开发的 LangChain Tool 抽象，以及面向直接模型集成的 OpenAI 函数调用。值得注意的是，这两种方法并不互斥；例如，LangChain 可以使用其 StructuredTool 类封装 OpenAI JSON schema，使开发者能够在 LangChain 智能体中利用 OpenAI 强大的函数调用能力。理解这些核心模式，可以为集成任何工具奠定基础，无论其具体实现或领域如何。

LangChain Tool 抽象

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

from langchain.agents import Tool

def get_stock_price(ticker: str) -> str:
    """Return a mock stock price or handle invalid input."""
    try:
        # Dummy logic: in real scenarios, this could call an 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 函数开始，它接收股票 ticker 符号并返回价格信息。Tool wrapper 随后将这个函数与智能体可理解的元数据打包在一起：用于识别的描述性名称、实际执行的函数，以及对工具功能的清晰描述。当智能体需要股票价格信息时，它可以通过名称和描述发现该工具，然后使用合适参数调用底层函数。Tool 抽象处理了从智能体推理过程到函数执行之间所有桥接复杂性。

OpenAI 函数调用

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 智能体开发的云原生平台进行比较性概览。

虽然开源框架为定制实现和特殊需求提供了无与伦比的灵活性和控制力，但主要云服务商，包括 AWS、Microsoft Azure 和 Google Cloud，也提供了强大的托管平台，用于简化生产环境中 LLM 智能体的开发、部署和扩展。这些云原生解决方案抽象掉了大量底层基础设施复杂性，并提供多智能体协作、RAG、记忆保留，以及用于安全性和可靠性的集成护栏等关键能力。

智能体工程中一个日益明显的趋势是混合方法：结合托管云服务在基础设施和核心 LLM 访问方面的优势，以及开源框架在定义复杂智能体逻辑和自定义工具集成方面的优势。本节将探索各大云服务商的关键产品，突出其原生工具、集成能力和部署考量。

AWS：灵活生态系统

AWS 提供了一整套用于构建和部署 LLM 智能体的服务，其特点是模型选择范围广，并与既有 AWS 服务深度集成。

原生工具：Amazon Bedrock Agents

Amazon Bedrock 是 AWS 面向生成式 AI（GenAI）的旗舰托管服务，通过单一 API 端点提供对多种基础模型（FMs）的访问，包括 Amazon 的 Titan 模型，以及 Anthropic Claude、AI21 Labs Jurassic、Cohere Command、Meta Llama 2 和 Stability AI 等第三方模型。Bedrock 支持按需使用，也支持微调和 RAG 等定制技术。

AWS 中的一项独特功能是 Amazon Bedrock Agents，这是用于构建和扩展能够自主执行复杂任务的 GenAI 机器人的完全托管服务。关键特性包括：

多智能体协作：Bedrock Agents 支持编排式多智能体工作流，其中单一 supervisor 或 orchestrator 智能体管理链式任务智能体执行。虽然这支持劳动分工和模块化任务处理，但它目前采用中心化协调模型，而不是去中心化 agent-to-agent 协作。

RAG：Bedrock Knowledge Bases 提供完全托管的 RAG 工作流，处理文档摄取、向量数据库中的嵌入存储，以及从数据中检索上下文。它可以连接数据库和 S3 等多种数据源。值得注意的是，它支持通过自然语言到 SQL 的结构化数据检索。

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

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

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

提示词工程：Bedrock Agents 会根据用户指令、action groups 和知识库自动创建提示模板，开发者可以进一步优化这些模板。

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

对于托管自定义模型或开源 LLM，Amazon SageMaker 提供将任意模型部署到带自动扩展能力的托管端点的能力。此外，SageMaker JumpStart 为 Llama 3、Mixtral 等热门开放模型提供预构建推理容器和部署模板，显著降低生产级部署的运维工作量。

在 AWS 上集成开源框架

AWS 积极支持与流行开源 LLM 智能体框架集成：

LangChain 和 LangGraph：AWS 提供专门的 langchain-aws 工具包和官方示例，展示如何将 LangChain 和 LangGraph 与 Bedrock 集成。LangChain 智能体可以直接调用 AWS Lambda 函数作为工具。

Strands Agents：AWS 推出了 Strands Agents，这是一个面向 AI 智能体开发的开源 SDK，采用模型驱动方法。它允许使用自然语言提示、工具和模型定义智能体，并通过 LiteLLM 支持 Bedrock 等模型。

MCP：AWS 支持 MCP，这是一项开放标准，定义 AI 模型如何连接各种数据源或工具，旨在标准化智能体—工具交互，并促进企业范围内复用。SageMaker AI 在托管 LLM 方面发挥重要作用，这些 LLM 可通过 MCP server 实现的工具执行行动。

AWS 上的部署架构

AWS 提供灵活部署架构：

Serverless 无服务器（AWS Lambda、API Gateway） ：Lambda 函数非常适合事件驱动应用和微服务，可以作为 LLM 智能体的核心逻辑，由 Amazon API Gateway 触发以支持实时交互。这种设置提供自动扩展和按使用量付费模型。

Containerized 容器化（Amazon ECS、Amazon EKS） ：对于复杂、分布式或有状态 LLM 智能体应用，AWS 提供 Amazon Elastic Container Service（ECS）和 Amazon Elastic Kubernetes Service（EKS）。ECS 是 AWS 专有容器编排平台，成本较低，并与其他 AWS 服务深度集成。EKS 基于 Kubernetes，提供大规模管理容器化应用所需的丰富功能和更强开源支持。实现智能体工具的 MCP server 可以托管在 Elastic Compute Cloud（EC2）、ECS 或 EKS 上。

Azure：企业级强者

Microsoft Azure 为开发和部署 LLM 智能体提供稳健且集成化的生态系统，尤其适合深度嵌入 Microsoft 生态的组织。

原生工具：Azure AI Foundry Agent Service

Azure OpenAI Service 是 Azure 的旗舰产品，提供对托管在 Microsoft 云数据中心中的 OpenAI 模型的 API 访问，包括 GPT-3.5 Turbo、GPT-4、Codex、DALL-E 2，并具备企业级安全和合规能力。需要注意的是，GPT-4o 当前仅以多租户模式提供。

Azure AI Foundry Agent Service 是一个统一平台，旨在企业环境中构建、部署和运行由 LLM 驱动的智能体。它被概念化为一个 “Agent Factory”，具备多个维度的综合能力：

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

Customization 定制：通过微调、蒸馏或领域特定提示来调整模型，以编码智能体行为。

AI tools AI 工具：智能体可以访问企业知识，例如 Bing、SharePoint、Azure AI Search，并通过 Azure Logic Apps、Azure Functions 或 OpenAPI 采取行动。

Orchestration 编排：“Connected agents” 管理工具调用、更新线程状态并处理重试。Azure AI Foundry 支持多智能体协调，并内置 agent-to-agent 消息。Azure Logic Apps 是类似 AWS Step Functions 的无服务器工作流引擎，适合定义 LLM 智能体流程并与各种服务集成。Azure Durable Functions 是 Azure Functions 的扩展，允许用代码编写复杂序列的 orchestrator functions。Azure AI Studio Prompt Flow 提供可视化画布，用于串联提示和 Python 代码节点。

Trust 信任：企业级特性确保可靠性，包括通过 Microsoft Entra 实现身份管理、基于角色的访问控制、内容过滤、加密和网络隔离。

Observability 可观测性：AI Foundry 捕获日志、trace 和评估，提供完整线程级可见性，并与 Azure Application Insights 集成。

Azure 还提供 “OpenAI on Your Data”，这是 Azure AI Studio 中一种简化 RAG 设置，会自动使用 Azure AI Search 为聊天模型索引和检索数据。

在 Azure 上集成开源框架

Azure AI Foundry Agent Service 明确支持组合各种开源 SDK：

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

AutoGen：由 Microsoft Research 开发，AutoGen 将所有内容框定为专门智能体之间的异步对话，适合多轮对话和实时工具调用。Azure AI Agent Service 可以将 AutoGen 中定义的单个智能体编排进复杂多智能体工作流。

LangChain：虽然集成深度不如 Semantic Kernel 或 AutoGen，但 LangChain 智能体可以部署到 Azure 的计算服务上，例如 Azure Container Apps Dynamic Sessions，以提供安全、沙盒化的代码解释器环境。

Azure 上的部署架构

Azure 提供灵活部署选项：

Serverless 无服务器（Azure Functions、Azure Container Apps） ：Azure Functions 适合部署 Semantic Kernel SDK 和 AutoGen 多智能体应用，提供自动扩展和成本效率。Azure Container Apps 可以托管基于 Web 的 AI 智能体聊天应用，并为代码执行提供安全、隔离的沙盒环境。

Containerized 容器化（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，尤其是其 GenAI 产品，例如 PaLM 2 和即将推出的 Gemini 模型套件。Vertex AI 还通过其 Model Garden 库包含部分外部模型，例如 Meta Llama 2。

Google Cloud 提供一组用于构建和部署 LLM 智能体的集成服务：

Agentspace：面向企业工作的搜索和 AI 智能体中心，将应用连接到 Google 质量的多模态搜索和 AI 智能体。它包含 “Agent Designer” 和 “Agent Gallery” 功能。需要注意的是，Agentspace 当前处于 private preview。

Vertex AI Agent Builder：一整套用于发现、构建和部署 AI 智能体的功能。

Agent Development Kit（ADK） ：一个开源、框架无关的框架，用于简化复杂多智能体系统创建，并对智能体行为提供精确控制。它支撑 Agentspace，并简化多智能体转移和规划。

Vertex AI Agent Engine：一个完全托管的 Google Cloud 服务，用于在生产中部署、管理和扩展 AI 智能体。它抽象掉低层任务，并处理基础设施、扩展、安全、评估和监控。

A2A protocol：Google 正在积极开发开放 A2A 协议，使 AI 智能体之间实现互操作，无论它们底层使用什么框架或供应商。

MCP：Google Cloud 也支持 MCP，这是一项开放标准，使智能体能够以标准化方式连接并使用外部工具和数据源。

Google Cloud 的智能体工具适用于企业搜索、内容生成和自动化等多种用例。作为 Agent Builder 的一部分，Vertex AI extensions 允许将智能体连接到 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 提供灵活且可扩展的部署选项：

Serverless 无服务器（Cloud Run） ：一个完全托管的无服务器平台，为 AI 应用工作负载和智能体提供可扩展环境。它会按需自动扩展实例，提供按使用量付费模型，并与 Gemini API 或 Vertex AI endpoints 集成以访问 AI 模型。Cloud Run 可以配置为支持沙盒化代码执行。

Containerized 容器化（GKE） ：GKE 是托管 Kubernetes 服务，适合复杂微服务架构、有状态应用，以及需要自定义基础设施或网络配置的工作负载。LangServe 可以简化 LangChain 在 GKE 上的部署。Cloud Run 和 GKE 都具备高可移植性，允许同一容器镜像在二者之间运行。

对于核心智能体推理之外的稳健工作流编排，例如模型训练、微调和持续 RAG 更新，Vertex AI Pipelines 提供托管服务，用于定义和执行这些复杂 ML 工作流。

云平台选择建议

用于 LLM 智能体的“最佳”云，取决于具体项目需求和组织既有基础设施：

AWS：适合已经深度投入 AWS 生态的组织，尤其是重视灵活性、多种模型选择，以及与既有 AWS 服务和数据湖深度集成的组织。它对多智能体协作和边缘分布式推理的关注，使其适合复杂、大规模部署。

Azure：当必须使用前沿 OpenAI 模型（GPT-4），或需要将 AI 集成进 Microsoft 中心化组织（Office 365、Dynamics、Teams、SharePoint）时，Azure 是首选平台。Azure AI Foundry 提供统一平台体验，并为智能体提供强治理和身份管理能力，适合优先考虑流线化运营和合规的团队。

Google Cloud：适合重视成本高效扩展、Google AI 研究优势，以及更“整体化”智能体平台的团队，尤其强调开放标准和简便工具连接。它在企业搜索和多模态 AI 方面的优势，加上 Cloud Run 等无服务器选项支持快速部署，使其对偏好代码与托管服务混合模式的开发者很有吸引力。

小结

你组装的工具箱，从根本上塑造了系统能够感知什么、如何推理，以及可以采取什么行动。本章探索了关键组件：框架、模型、数据库、集成机制、评估系统和监控解决方案。

这些工具箱决策决定了你的实现处于 Agentic AI Progression Framework 的哪个位置。你的选择会确立智能体明天能够成为什么的边界。

随着技术版图不断演化，保持适应性应始终是核心设计原则。在下一章中，我们将探索面向智能体系统的高级提示工程，以最大化它们在给定用例中的效用。

avatar
文章
阅读
粉丝