AI Agents For Beginners | Whispers of the Stars

type

status

date

slug

summary

Framework Design

AI Agent 是一个有目标，能使用工具，具备角色和技能，甚至能进行一定自我反思和调整的系统。

从用户的体验角度（UX|UE）来考虑如何设计可信赖的智能体，即以人为中心的设计原则；它强调在设计智能体时，不仅要考虑功能，更要考虑用户如何感知、交互和信任这个系统。

模糊性贯穿 Agent 的整个生命周期，也是其显著的特性，亦是可以做功的点。

主要分两个维度来探讨这个问题：时间和核心。

时间维度上，关注智能体如何在时间流中与用户交互并建立信任。 过去（Past），智能体应能反思和利用过去的交互历史，提供连贯和个性化的体验； 现在（Presant），交互应亲和，而非干扰性的通知，智能体应能动态适应当前情境的变化； 未来（Future），设计应考虑跨平台性，智能体应能适应用户行为上的变化，并且具备持续学习和进化的能力；

核心维度上，关注智能体本身的设计如何建立信任。核心原则：拥抱不确定性，但建立信任。

承认 AI，尤其是基于 llm 的智能体，本身就存在不确定性。设计上尽可能透明化，让用户来了解智能体的能力边界和潜在风险，基于用户控制权，让用户能理解，监督和干预智能体的行为，提供可解释性，尽可能让用户知道智能体做出某个决策或推荐的原因，比如 rag 的源数据等；

Rag

llm 存在的几个内核痛点：静态性、缺乏领域知识、黑箱问题，还有效率和成本，这些问题若不得以解决，那 llm 在很多实际应用中便很难真正落地｜效果会大打折扣；如就静态性来说，若知识仅停留在过去，那对于快速变化的领域里影响就很大，如医疗研究、金融市场、法律法规、科技动态，这些领域每天都有新的信息和变化，如果依赖于一个知识截止在一年甚至两年前的 AI 来做决策或获取信息，那风险太高了；并且来更新 llm 的训练数据以让其张伟最新的知识，成本极高、周期极长，不具备可行性。

广泛的定义上

RAG：Retrieval Augmented Generation，检索增强生成职责上，rag 通常基于用户 query 从外部知识库中检索语义上相关的信息，然后将这些信息与用于的 query 作为上下文的一部分一块给到 llm 以来生成最终的答案。

检索

从外部的知识库中检索与用户提问最为相关的知识，其作为是 rag 流程中的关键一步，用于为 llm 提供上下文；检索信息的方式通常包括语义检索，而关键词检索则是另一种传统的检索方法；语义检索：

核心目标是理解用户询问的真正含义或意图，而不仅仅是匹配关键词；它通过将用户的询问与外部知识库中的数据（文本、图像、音视频等）转换成数值表示，称为嵌入（Embeddings） 或 向量（Vectors）；这些向量通常存储在专门的向量数据库中，当用户询问时，系统会将 query 转换为向量，然后在向量数据库中执行“最近邻”检索，以找到与查询向量语义上最接近（即含义最相似）的数据项；

因此，即使查询中没有包含文档中的确切关键词，语义检索也能找到最相关的文档。向量数据库在处理自然语言查询进行语义检索时非常有效。在 rag 系统中，通常会使用语义检索搜索与用户查询相关的、最新的或领域特定的信息，检索到的相关内容随后会作为“上下文窗口”的一部分提供给 llm，从而帮助 llm 生成更准确的、更不容易“幻觉”（hallcination）的回答；一些系统还支持混合搜索，结合了语义和关键词检索的优点。

增强提示

Augmented，在 rag 系统中主要做的事情，即增强用户查询或 llm 输入，其作为 rag 的核心理念之一，通过将外部检索到的相关知识融入到 llm 的输入中，极大地提升了 llm 在处理需要最新消息、特定领域知识或减少事实错误方面的能力。

当用户查询时，首先从外部的知识库中检索与查询相关的、最具上下文重要性的信息，然后将这些检索到的相关信息（上下文）添加到用户的原始查询中，创建一个“增强的”或“扩展的”提示；

为 llm 提供上下文：增强后的提示提供给 llm，这些检索到的信息充当了 llm 的“上下文窗口”的一部分。就像是给 llm 提供一张包含关键点的提示卡，帮助它生成更准确的响应；

提高生成结果的准确性、相关性和事实性：通过提供这些外部的、相关的上下文信息，llm 能够基于这些具体事实来生成答案，而不仅仅是依赖其静态的训练数据。这能显著减少 llm“幻觉”（hallucination），即听起来合理但实际上不准确或捏造的信息的可能性；

解决 llm 知识过期和缺乏领域特定信息的问题：基础的 llm 通常被训练到特定的知识点，并且不包含最新的信息或特定的私有/领域数据。 rag 的增强机制使得 llm 能够访问并利用这些最新的或特定领域的信息，从而生成更及时和更相关的回答。

生成

Generation，即 llm 利用检索到的外部知识作为上下文生成最终的回答，这也是 rag 能够增强 llm 能力，使其提供更准确、相关和最新响应的关键环节。

延伸

除了 rag 外，提升 llm 的性能还有其它方法，比如自己来训练一个专门的基础模型或者用微调（Fine-turning）方法，但 rag 还是成为目前主流的选择，主要还是 rag 解决了核心问题--提供最新领域知识，减少幻觉和成本效益--之间找到了一个非常好平衡点

自建模型

从零到一训练像 gpt 那么大的模型，基本上只适用于少数资源极其雄厚的巨头公司，成本是天文数字，需要顶尖 AI 人才团队（稀缺），其次便是数据，你需要海量的、高质量的、经过精心处理和标注的数据（屏蔽内容农场），数据的获取本身已经是巨大的挑战，加上技术复杂性极高、投入这么多的成本，最终是否能训练出来一个好模型，仍存在很大的确定性。

微调（Fine-turning）

简单来说，基于一个已经训练好的基础模型，比如 gpt 3.5，然后在自己的特定数据集上再进行额外的训练，让它学习特定领域的知识或风格。虽然比自建模型从零到一训练简单，但也不是零成本，并且微调在知识更新上并不比基础模型好太多，如果你是的领域知识是不断变化的，那么便需要持续准备新数据，重新进行微调；并且微调还有一个很大的缺点，它很难让模型忘记或者删除已经学到的过时信息（不像 rag）。 stackOverflow 上甚至言道，微调可能是一种过时的方法。

提示工程

精心设计提示词来引导大模型，确实成本最低，也最容易实施，对于引导大模型如何行动，以怎样的风格回应很有帮助。核心局限解决不了根本问题，它无法给大语言模型提供新的、模型本身不知道的信息.

Agent 中 rag 的应用

传统的 Rag：相较来说是静态的流程，通常会基于用户 query 从外部数据源检索相关信息，然后将这些信息与用户 query 一起传递给 LLM 以来生成答案。 Agentic Rag：LLM 自主规划下一步操作，并从外部数据源中获取信息。

与传统的 Rag 不同，可迭代调用 LLM，穿插工具/函数调用和结构化输出。 rag 在 agent 中扮演至关重要的角色，可以说是 agent 获取和利用知识的核心机制之一，但其应用方法比传统的 rag 要更复杂、更多样。

智能体｜编排层知道在需要信息时可以来调用 rag 工具，工具内部就自己来完成检索、增强流程，然后返回结果给智能体；这样运行的 rag 其实更像是一个黑盒子，通常需要提示技术更加灵活些，同时包含更多人工的精心设计；agent 作为工具自动化水平越高，可能内部的执行细节越不透明。

修正性 rag（Corrective RAG）

不仅具备传统 rag 检索和生成的能力，同时具备对检索结果进行修正和优化的能力。

抢先上下文加载（Proactive Context Loading）

即在用户真正提出具体问题之前，智能体预先加载一些它预测用户可能会需要的背景信息。这样的裨益主要是效率上的提升，当用户后面问到相关问题时，智能体可以直接利用这些已经加载好的上下文，而不需要每次都实时去检索，这样反应速度会更快（前提：智能体需要对用户可能的意图有比较好的预测）。

效果提升

在 rag 和智能体效果提升上，存在两个关键的概念：评估相关性（Evaluating relevancy） 和 意图搜索（Search with intent）。

评估相关性

rag 在 agent 中的检索，仅仅语义相似是不够的，还需要考虑上下文感知，信息否是符合当前对话的语境，准确性，是否真实，新鲜度，信息是否最新以及用户反馈等好的 rag 需要有机制来综合评估这些因素。

意图搜索

更加高级的应用，它强调的 rag 或智能体不应仅仅根据用户问题的字面意思来搜索，而应该努力理解用户背后的真实意图。一个良好的智能体需要能识别出来用户的意图，然后来才去最好的搜索策略。

Agentic Rag

与传统的静态 rag 不同，可以理解为具备智能体特性的 rag，或者由智能体驱动的 rag 。核心区别在于在 agentic rag 中，llm 不仅仅是被动地接受 rag 检索来的信息，然后生成答案，它还能主动规划和控制整个信息检索与利用的过程。

遵循"maker-checker" style（质检），核心关注点是其自我迭代和自我评估，通过循环迭代的方式让 llm 在生成答案的过程中不断检查和改进自己的工作，从而提高准确性和处理格式错误的查询。

核心流程：

制造（Maker）：llm 首次尝试解决问题｜回答问题时，可能会调用 rag 工具或者其它工具获取信息；

检查（Checker）：llm 或者智能体中一个专门模块对上一步生成的结果进行评估；

结果足够准确？完整么？数据格式对么？... etc

优化（Optimizer）或迭代（Iteration）：如果检索发现问题，智能体不会直接放弃，它会主动决定下一步该怎么做；

比如优化查询，重新构造 rag 的查询，更换检索策略，更换外部检索工具，拆解问题；
这其实是一个不断尝试、评估、修正的循环，直到智能体认为结果足够好，或者达到了某个预设的停止条件；

agentic rag 的核心是让智能体在信息获取和使用上具备了自主规划、迭代优化和一定程度的自我纠错能力。

语义检索、RAG 与智能体中的意图理解与优化

基础的语义检索工作原理是将用户的查询和知识库的文本内容都转换成向量（一串数字），这些向量捕获了文本的语义信息，通过在向量数据库中查找与查询向量在数学空间中距离最近的文档向量来进行检索，即最近邻检索（K 最近邻 - KNN）。

当下很多矢量数据库便是用于存储这些向量并支持相似性的检索，如 Milvus 等；然而，仅仅是向量空间的“距离近”或“局部相关”并不总是代表信息在当前整个任务或对话语境下（即“全局正确”）是真正有用的或相关的。简单地检索 k 个最相似的文本向量块可能不足以捕捉复杂的上下文需求或用户真正的意图，这其实也是当下 rag 语义检索存在的短板；

在 rag 中，存在“粗排”、“精排”两种术语，来对 rag 的运作流程来做优化，通常来说，“粗排”是指检索流程的第一步，即“初始检索”，基于向量相似度做向量检索，用于快速从知识库中筛选出来一批与用户查询最相关的候选文档，为后续的更精细化的处理做准备，但这个阶段下仅向量空间下的“距离近”的判断其实还是很粗糙、不够准确。简单来说，“粗排”更像是海选，先圈定范围，快速筛选出来与用户 query 相关的内容，再由后续的“精排”进行更加细致的筛选和排序。

粗排的局限：仅仅向量相似度检索出来的 k 个结果可能不是最优的。

向量检索可能返回语义相似但质量不高、过时的或与当前语境不咋搭边的信息；
用户的查询可能包含更加复杂的意图或偏好，相似度检索并不能捕捉到这些细微却关键之处；

为了克服基本语义检索的局限性，特别是在 agent 框架下，引入了诸多机制来提升检索的质量和上下文的相关性，这也是在“粗排”中工程端可以来发力优化的点：

优化数据处理和分块策略（Splitting Strategy）

在数据的处理阶段，将原始的文档切分成有意义的小块非常关键。选择合适的分块策略对最终效果影响很大，需要根据数据集进行调整优化，合理的分块有助于保持单个文本内部的局部上下文完整性。 rag 系统并不会将整个长文档扔给 llm，而是会将其切分成更小、有意义的块。检索是基于这些小块进行的，因此，如何切割文档直接影响到检索的“上下文”质量。如果块太大，可能会混入不相关的噪音信息；如果块太小，可能会丢失必要的上下文信息；如果块太大，可能会混入不相关的噪音信息。 工程发力点：

尝试不同的分块方法：可以基于段落、按句子或按固定长度切割。如对 markdown 文档，可以考虑基于标题和代码块等结构进行切割。

保留上下文： 在切割时，可以考虑一些策略来保留块之间的上下文，比如在每个块中包含前面和后面的一小部分内容，确保即使切割了，每个块也拥有足够的自身信息来保留与其他块之间的联系。

优化嵌入模型（Embedding Model）

嵌入模型负责将文本（查询和文档块）转换成高维向量。向量的质量决定语义相似性搜索的准确性 -- 意思相似的文本，它们的向量在向量空间里的距离应该比较近。 工程发力点：

选择高性能的嵌入模型： 不同的嵌入模型在捕捉语义信息方面表现不同。工程团队可以实验不同的开源|闭源模型，选择最适合自己的领域数据和查询类型的模型

微调嵌入模型： 对于包含大量领域特定术语的知识库，通用嵌入模型可能表现不佳。工程团队可以在自己的知识库数据集上微调嵌入模型，使其更能理解领域内的专业词汇和概念，从而提高检索结果的相关性。

优化向量存储&索引（Vector Store & Indexing）

向量数据库专门用户存储文本向量并高效地执行相似性检索（如 KNN），向量数据库的性能和索引策略直接影响索引的速度和准确性。 工程发力点：

选择合适的向量数据库：有多种向量数据库可选，如 Pinecone、Milvus 等。不同的数据库在性能、扩展性、功能（如过滤）等方面有差异。

优化索引策略：向量数据库使用不同的索引算法来实现最近邻检索（ANN）。选择合适的索引类型并调整其参数，可以在搜索速度和准确性之间取得平衡。

索引策略，即外部知识库在向量数据库中的组织形式，也是向量检索得以有效进行的基础和前提。

查询改写（Query Transformation）或增强

有些时候用户的原始查询可能不够清晰，或者包含多重意图，直接用于向量搜索效果可能不好。 工程端发力点：

将用户的原始查询转换为向量之前，先基于 llm 或其他方法对查询进行处理。例如，如果查询包含多个子问题，可以先拆解问题；如果查询表述含糊，可以尝试重写查询使其更精确（如我要退票 -> 我要退火车票）；这有助于生成更高质量的查询向量，从而查询到更相关的结果。

利用元数据过滤（Metadata Filtering）

文档块往往带有元数据，比如创建日期、作者、文档类型、所属产品、访问权限等，在检索时利用这些元数据可以进一步精确筛选结果。可以根据元数据（metadata）过滤向量数据库的检索结果，即在进行相似问检索后，可以根据文档特性、时间戳等结构化信息进行二次筛选，这有助于提高检索结果的全局相关性。 工程发力点： 在向量检索的结果基础上，或者在搜索之前，根据查询中的线索或预设的规则，利用元数据对检索到的文本进行过滤。例如，当用户询问关于“某年度的某品牌手机时”，可以先过滤出来对应年度日期以及特性产品相关的文档块，再结合向量检索。

洞察用户意图（Intent Understanding）

不同的用户意图（信息获取、交易、导航等）需要不同的检索策略和信息类型。 工程发力点： 在检索之前，利用 llm 或分类模型识别用户的查询意图。根据识别出来的意图，选择最合适的检索工具（向量检索、SQL 查询、调用特定 API 等）或调整检索参数（搜索结果的数量、过滤条件等），这能使第一步检索更有针对性。

使用 LLM 进行重排序和评分（Re-ranking and scoring）

即，精排。在向量检索初步筛选到 k 个结果后，可以使用 llm 根据更复杂的标准（如信息的详细程度、来源的可靠程度、是否直接回答了用户的特定疑问、用户的历史偏好等）对这些结果进行评估、打分并重新排序，这使得检索结果的排序不再仅仅依赖于向量相似度，而是结合了 llm 对上下文和相关性的更深层理解。

修正性 RAG（Corrective RAG）

这是一种迭代式的检索增强方式，agent 不仅仅是一次性检索，而是根据用户反馈或内部评估对检索结果进行分析，然后调整查询或过滤条件，重新进行检索和优化。这种迭代过程有助于逐步将检索结果导向用户真正需要的信息，纠正初次检索可能存在的偏差。

Trustworthy Agents

代理型应用程序的构建，安全性的保障也是其比较重要的一点，通常会在 agent 处理用户请求的流程中做工，涉及到请求的合法性校验，其中包含了任务与指令访问、对关键系统或服务的访问、资源和服务滥用、知识库污染等。

Planning Design

AI Agent 需要一个清晰且简洁的目标驱动其规划和行动，在分派任务之前，为 AI Agent 分配任务之前，通常需要考虑如下： 1、设定一个明确的总体目标是必需的，并且确保其需要实现的内容。 2、将复杂的任务拆分成可管理的子任务，并以逻辑顺序组织它们。 3、为 Agent 分配合适的工具（武器），自主决策使用工具的时机和方式，并处理可能出现的意外情况。 4、对子任务的结果进行评估，衡量性能、业务满意度，并通过迭代改进最终输出。

Multi-Agent Design Pattern

不存在真正意义上通用的 Agent，干一行精一行，让专业 Agent 干专业事，单一职责原则。在合适的场景应用多代理模式来针对性解决问题，如大规模的工作负载、复杂任务以及多样化的专业技能。常见的 Agent 模式有群聊、交接、协同过滤等。

Metacognition

元认知是对自身思维进行审视与调控的高级认知活动，即“思考关于思考”的过程。它能帮助 AI Agent 结合内部状态感知及过往经验，评估并调整行为，用于 AI Agent 的提升和发展。即便面对必然发生且无法改变的状况，元认知也能使 AI Agent 更好地适应与应对。

元认知重要性：

自我反思：AI Agent 可以分析其过去的表现并找出改进的地方。

适应性：AI Agent 可以根据反馈和变化的条件调整策略。

错误修正：AI Agent 可以自主检测和纠正错误。

资源管理：AI Agent 可以优化资源使用，例如算力的均衡。