附录A:Advanced Prompting Techniques
Prompting 简介 Prompting 是与语言模型交互的主要接口,是通过精心构建输入来引导模型生成所需输出的过程。这包括结构化请求、提供相关上下文、指定输出格式以及展示期望的响应类型。精心设计的 Prompt 可以最大化语言模型的潜力,产生准确、相关且富有创造性的响应。反之,设计不当的 Prompt 可能导致模...
Prompting 简介
Prompting 是与语言模型交互的主要接口,是通过精心构建输入来引导模型生成所需输出的过程。这包括结构化请求、提供相关上下文、指定输出格式以及展示期望的响应类型。精心设计的 Prompt 可以最大化语言模型的潜力,产生准确、相关且富有创造性的响应。反之,设计不当的 Prompt 可能导致模糊、无关或错误的输出。
Prompt Engineering 的目标是持续从语言模型中引出高质量响应。这需要理解模型的能力和局限性,并有效地传达预期目标。它涉及通过学习如何最佳地指导 AI 来培养与 AI 交流的专业能力。
本附录详细介绍了各种超越基本交互方法的 Prompting 技术。它探讨了结构化复杂请求、增强模型推理能力、控制输出格式以及整合外部信息的方法。这些技术适用于构建从简单聊天机器人到复杂多 Agent 系统的各种应用,可以提高 Agentic 应用的性能和可靠性。
Agentic 模式是构建智能系统的架构结构,在正文章节中有详细说明。这些模式定义了 Agent 如何规划、使用工具、管理内存和协作。这些 Agentic 系统的有效性取决于其与语言模型进行有意义交互的能力。
Prompting 核心原则
语言模型有效 Prompting 的核心原则
有效的 Prompting 建立在指导与语言模型通信的基本原则之上,适用于各种模型和任务复杂度。掌握这些原则对于持续生成有用且准确的响应至关重要。
清晰性和具体性:指令应明确且精确。语言模型会解释模式;多种解释可能导致意外响应。应定义任务、期望的输出格式以及任何限制或要求。避免模糊的语言或假设。不当的 Prompt 会产生模糊和不准确的响应,阻碍有意义的输出。
简洁性:虽然具体性至关重要,但不应以简洁性为代价。指令应直接明了。不必要的措辞或复杂的句子结构可能会混淆模型或掩盖主要指令。Prompt 应该简单;对用户来说令人困惑的内容对模型来说也可能令人困惑。避免复杂的语言和多余的信息。使用直接措辞和主动动词来清楚地描述期望的操作。有效的动词包括:Act(行动)、Analyze(分析)、Categorize(分类)、Classify(归类)、Contrast(对比)、Compare(比较)、Create(创建)、Describe(描述)、Define(定义)、Evaluate(评估)、Extract(提取)、Find(查找)、Generate(生成)、Identify(识别)、List(列出)、Measure(衡量)、Organize(组织)、Parse(解析)、Pick(选择)、Predict(预测)、Provide(提供)、Rank(排名)、Recommend(推荐)、Return(返回)、Retrieve(检索)、Rewrite(重写)、Select(选择)、Show(展示)、Sort(排序)、Summarize(总结)、Translate(翻译)、Write(编写)。
动词的使用:动词选择是一个关键的 Prompting 工具。行动动词表明期望的操作。与其说"思考一下如何总结这个",不如使用直接的指令如"总结以下文本"更为有效。精确的动词引导模型激活与该特定任务相关的训练数据和过程。
正面指令优于约束:正面指令通常比负面约束更有效。指定期望的操作优于概述不应做什么。虽然约束在安全或严格格式化方面有其位置,但过度依赖可能导致模型将注意力集中在回避而非目标上。应以引导模型直接执行的方式来构建 Prompt。正面指令符合人类指导偏好,并减少混淆。
实验和迭代:Prompt Engineering 是一个迭代过程。识别最有效的 Prompt 需要多次尝试。从草稿开始,测试它,分析输出,识别不足,然后改进 Prompt。模型的差异、配置(如 temperature 或 top-p)以及措辞的微小变化都可能产生不同的结果。记录尝试对于学习和改进至关重要。实验和迭代是实现所需性能的必要条件。
这些原则构成了与语言模型有效通信的基础。通过优先考虑清晰性、简洁性、行动动词、正面指令和迭代,可以建立一个健壮的框架来应用更高级的 Prompting 技术。
基本 Prompting 技术
在核心原则的基础上,基础技术为语言模型提供不同级别的信息或示例来指导其响应。这些方法作为 Prompt Engineering 的初始阶段,适用于广泛的应用。
Zero-Shot Prompting
Zero-Shot Prompting 是最基本形式的 Prompting,语言模型接收指令和输入数据,但不提供任何期望的输入-输出对示例。它完全依赖模型的预训练来理解任务并生成相关响应。本质上,Zero-Shot Prompt 由任务描述和开始处理的初始文本组成。
- 何时使用:Zero-Shot Prompting 通常足以处理模型在训练中可能已经大量接触过的任务,如简单问答、文本补全或对直白文本的基本总结。这是首先要尝试的最快方法。
- 示例:
text
将以下英文句子翻译成法语:'Hello, how are you?'
One-Shot Prompting
One-Shot Prompting 涉及在呈现实际任务之前,为语言模型提供单个输入和对应期望输出的示例。此方法作为初始演示,展示模型应遵循的模式。目的是为模型提供一个具体的实例,它可以将其作为模板来有效地执行给定的任务。
- 何时使用:当期望的输出格式或风格较为特殊或不常见时,One-Shot Prompting 非常有用。它为模型提供了可以学习的具体实例。对于需要特定结构或语调的任务,与 Zero-Shot 相比,它可以提高性能。
- 示例:
text
将以下英文句子翻译成西班牙语: 英文:'Thank you.' 西班牙语:'Gracias.' 英文:'Please.' 西班牙语:
Few-Shot Prompting
Few-Shot Prompting 通过提供多个(通常三到五个)输入-输出对示例来增强 One-Shot Prompting。这旨在展示更清晰的期望响应模式,提高模型对新输入复制该模式的可能性。此方法提供多个示例来引导模型遵循特定的输出模式。
- 何时使用:Few-Shot Prompting 对于期望输出需要遵循特定格式、风格或展现细微变化的任务特别有效。它非常适合分类、使用特定 schema 进行数据提取或以特定风格生成文本等任务,尤其是当 Zero-Shot 或 One-Shot 无法产生一致结果时。使用至少三到五个示例是一般经验法则,应根据任务复杂度和模型的 token 限制进行调整。
- 示例质量与多样性的重要性:Few-Shot Prompting 的有效性很大程度上依赖于所提供示例的质量和多样性。示例应准确、具有任务代表性,并涵盖模型可能遇到的潜在变化或边缘情况。高质量、精心编写的示例至关重要;即使是微小的错误也可能混淆模型并导致不期望的输出。包含多样化的示例有助于模型更好地泛化到未见过的输入。
- 分类示例中混合类别:当使用 Few-Shot Prompting 进行分类任务(模型需要将输入归入预定义类别)时,最佳实践是混合来自不同类别的示例顺序。这可以防止模型可能对特定示例序列过拟合,并确保它学会独立识别每个类别的关键特征,从而在未见数据上实现更健壮、更可泛化的性能。
- 向"Many-Shot"学习的演进:随着现代 LLM(如 Gemini)在长上下文建模方面变得更强,它们在利用"Many-Shot"学习方面变得非常高效。这意味着通过在 Prompt 中直接包含更大量的示例——有时甚至数百个——可以实现复杂任务的最佳性能,允许模型学习更复杂的模式。
- 示例:
text
将以下电影评论的情感分类为 POSITIVE、NEUTRAL 或 NEGATIVE: 评论:"The acting was superb and the story was engaging." 情感:POSITIVE 评论:"It was okay, nothing special." 情感:NEUTRAL 评论:"I found the plot confusing and the characters unlikable." 情感:NEGATIVE 评论:"The visuals were stunning, but the dialogue was weak." 情感:
理解何时应用 Zero-Shot、One-Shot 和 Few-Shot Prompting 技术,以及深思熟虑地构建和组织示例,对于增强 Agentic 系统的有效性至关重要。这些基本方法构成了各种 Prompting 策略的基础。
Prompt 结构化
除了提供示例的基本技术之外,Prompt 的结构化方式在引导语言模型方面起着关键作用。结构化涉及在 Prompt 中使用不同的部分或元素,以清晰有序的方式提供不同类型的信息,如指令、上下文或示例。这有助于模型正确解析 Prompt 并理解每段文本的具体角色。
System Prompting
System Prompting 为语言模型设定整体上下文和目的,定义其在交互或会话中的预期行为。这包括提供建立规则、人设或整体行为的指令或背景信息。与特定的用户查询不同,System Prompt 为模型的响应提供基础指导方针。它影响模型在整个交互过程中的语调、风格和总体方法。例如,System Prompt 可以指示模型始终简洁而有益地响应,或确保响应适合一般受众。System Prompt 也用于安全性和毒性控制,包括保持尊重语言的指导方针等。
此外,为了最大化其效果,System Prompt 可以通过基于 LLM 的迭代优化进行自动 Prompt 优化。Vertex AI Prompt Optimizer 等服务通过根据用户定义的指标和目标数据系统地改进 Prompt 来促进这一点,确保在给定任务上实现尽可能高的性能。
- 示例:
text
你是一个有益且无害的 AI 助手。以礼貌和信息丰富的方式回应所有查询。不要生成有害、有偏见或不当的内容。
Role Prompting
Role Prompting 为语言模型分配特定的角色、人设或身份,通常与 System Prompting 或上下文 Prompting 结合使用。这涉及指示模型采用与该角色相关的知识、语调和沟通风格。例如,"扮演一个旅行指南"或"你是一个专业的数据分析师"等 Prompt 引导模型反映所分配角色的视角和专业知识。定义角色为语调、风格和专注的专业知识提供了框架,旨在提高输出的质量和相关性。还可以指定角色内期望的风格,例如"幽默而鼓舞人心的风格"。
- 示例:
text
扮演一位经验丰富的旅行博主。写一段简短而引人入胜的段落,介绍罗马最好的隐藏宝藏。
使用分隔符
有效的 Prompting 涉及为语言模型清晰地区分指令、上下文、示例和输入。分隔符,如三重反引号(```)、XML 标签(<instruction>、<context>)或标记(---),可用于在视觉和程序上分离这些部分。这种在 Prompt Engineering 中广泛使用的实践最小化了模型的误解,确保了 Prompt 每个部分的角色清晰明了。
- 示例:
text
<instruction>总结以下文章,重点关注作者提出的主要论点。</instruction> <article> [在此插入文章全文] </article>
Context Engineering
Context Engineering 与静态的 System Prompt 不同,它动态地提供任务和对话所需的背景信息。这种不断变化的信息帮助模型理解细微差别、回忆过去的交互并整合相关细节,从而产生有根据的响应和更流畅的交流。示例包括先前的对话、相关文档(如 Retrieval Augmented Generation)或特定的操作参数。例如,在讨论日本旅行时,可以要求推荐东京的三个适合家庭的活动,利用现有的对话上下文。在 Agentic 系统中,Context Engineering 是内存持久性、决策制定和跨子任务协调等核心 Agent 行为的基础。具有动态上下文管道的 Agent 可以随着时间推移维持目标、调整策略,并与其他 Agent 或工具无缝协作——这些品质对长期自主性至关重要。该方法论认为,模型输出的质量更多取决于所提供上下文的丰富程度,而非模型的架构。它标志着从传统 Prompt Engineering 的重要演进,后者主要关注优化即时用户查询的措辞。Context Engineering 将其范围扩展到包含多层信息。
这些层次包括:
- System Prompt:定义 AI 操作参数的基础指令(例如"你是一名技术撰稿人;你的语调必须正式且精确")。
- 外部数据:
- 检索到的文档:从知识库中主动获取以指导响应的信息(例如提取技术规格)。
- 工具输出:AI 使用外部 API 获取实时数据的结果(例如查询日历的可用时间)。
- 隐式数据:用户身份、交互历史和环境状态等关键信息。纳入隐式上下文会带来与隐私和伦理数据管理相关的挑战。因此,健全的治理对于 Context Engineering 至关重要,尤其是在企业、医疗和金融等领域。
核心原则是,即使是最先进的模型,在其操作环境视图有限或构建不当的情况下也会表现不佳。这种实践将任务从仅仅回答问题重新定义为为 Agent 构建一个全面的操作图景。例如,一个经过 Context Engineering 的 Agent 在响应查询之前,会整合用户的日历可用性(工具输出)、与邮件收件人的专业关系(隐式数据)以及之前会议的笔记(检索到的文档)。这使得模型能够生成高度相关、个性化和实用的输出。"工程化"方面涉及创建健壮的管道以在运行时获取和转换这些数据,并建立反馈循环以持续改进上下文质量。
为实现这一点,可以使用专门的调优系统(如 Google 的 Vertex AI Prompt Optimizer)来大规模自动化改进过程。通过根据样本输入和预定义指标系统地评估响应,这些工具可以增强模型性能,并在不同模型之间调整 Prompt 和系统指令,而无需大量手动重写。为优化器提供样本 Prompt、系统指令和模板,可以使其程序化地改进上下文输入,为实施复杂的 Context Engineering 所需的反馈循环提供了结构化方法。
这种结构化方法区分了基础 AI 工具和更复杂的、具有上下文感知能力的系统。它将上下文视为主要组件,强调 Agent 知道什么、何时知道以及如何使用这些信息。这种实践确保模型对用户的意图、历史和当前环境有全面的了解。最终,Context Engineering 是将无状态聊天机器人转变为高度能力强的、具有情境感知能力的系统的关键方法论。
Structured Output
通常,Prompting 的目标不仅仅是获得自由格式的文本响应,而是以特定的、机器可读的格式提取或生成信息。请求结构化输出,如 JSON、XML、CSV 或 Markdown 表格,是一种关键的结构化技术。通过明确要求以特定格式输出,并可能提供所需结构的 schema 或示例,可以引导模型以一种可以被 Agentic 系统或应用的其他部分轻松解析和使用的方式组织其响应。返回 JSON 对象进行数据提取是有益的,因为它迫使模型创建结构并可以限制幻觉。建议尝试不同的输出格式,尤其是对于提取或分类数据等非创造性任务。
- 示例:
text
从以下文本中提取信息,并将其作为 JSON 对象返回,包含键 "name"、"address" 和 "phone_number"。 文本:"Contact John Smith at 123 Main St, Anytown, CA or call (555) 123-4567."
有效利用 System Prompt、角色分配、上下文信息、分隔符和结构化输出,可以显著增强与语言模型交互的清晰度、控制力和实用性,为开发可靠的 Agentic 系统提供了坚实的基础。请求结构化输出对于创建语言模型输出作为后续系统或处理步骤输入的管道至关重要。
利用 Pydantic 实现面向对象的门面:强制结构化输出和增强互操作性的一种强大技术是使用 LLM 生成的数据来填充 Pydantic 对象的实例。Pydantic 是一个使用 Python 类型注解进行数据验证和设置管理的 Python 库。通过定义 Pydantic 模型,可以为所需的数据结构创建一个清晰且可强制执行的 schema。这种方法有效地为 Prompt 的输出提供了一个面向对象的门面,将原始文本或半结构化数据转换为经过验证的、带类型提示的 Python 对象。
可以使用 model_validate_json 方法直接将 LLM 生成的 JSON 字符串解析为 Pydantic 对象。这特别有用,因为它将解析和验证合并在一个步骤中。
from pydantic import BaseModel, EmailStr, Field, ValidationError
from typing import List, Optional
from datetime import date
# --- Pydantic Model Definition (from above) ---
class User(BaseModel):
name: str = Field(..., description="The full name of the user.")
email: EmailStr = Field(..., description="The user's email address.")
date_of_birth: Optional[date] = Field(None, description="The user's date of birth.")
interests: List[str] = Field(default_factory=list, description="A list of the user's interests.")
# --- Hypothetical LLM Output ---
llm_output_json = """
{
"name": "Alice Wonderland",
"email": "alice.w@example.com",
"date_of_birth": "1995-07-21",
"interests": [
"Natural Language Processing",
"Python Programming",
"Gardening"
]
}
"""
# --- Parsing and Validation ---
try:
# Use the model_validate_json class method to parse the JSON string.
# This single step parses the JSON and validates the data against the User model.
user_object = User.model_validate_json(llm_output_json)
# Now you can work with a clean, type-safe Python object.
print("Successfully created User object!")
print(f"Name: {user_object.name}")
print(f"Email: {user_object.email}")
print(f"Date of Birth: {user_object.date_of_birth}")
print(f"First Interest: {user_object.interests[0]}")
# You can access the data like any other Python object attribute.
# Pydantic has already converted the 'date_of_birth' string to a datetime.date object.
print(f"Type of date_of_birth: {type(user_object.date_of_birth)}")
except ValidationError as e:
# If the JSON is malformed or the data doesn't match the model's types,
# Pydantic will raise a ValidationError.
print("Failed to validate JSON from LLM.")
print(e)这段 Python 代码演示了如何使用 Pydantic 库定义数据模型并验证 JSON 数据。它定义了一个具有姓名、电子邮件、出生日期和兴趣字段的 User 模型,包括类型提示和描述。然后代码使用 User 模型的 model_validate_json 方法解析假设的 LLM JSON 输出。该方法根据模型的结构和类型处理 JSON 解析和数据验证。最后,代码从生成的 Python 对象中访问已验证的数据,并在 JSON 无效时包含 ValidationError 的错误处理。
对于 XML 数据,可以使用 xmltodict 库将 XML 转换为字典,然后传递给 Pydantic 模型进行解析。通过在 Pydantic 模型中使用 Field 别名,可以无缝地将 XML 通常冗长或属性密集的结构映射到对象的字段。
这种方法论对于确保基于 LLM 的组件与大型系统的其他部分之间的互操作性非常有价值。当 LLM 的输出被封装在 Pydantic 对象中时,它可以可靠地传递给其他函数、API 或数据处理管道,并确保数据符合预期的结构和类型。在系统组件边界处采用"解析,而非验证"的实践可以带来更健壮、更可维护的应用。
有效利用 System Prompt、角色分配、上下文信息、分隔符和结构化输出,可以显著增强与语言模型交互的清晰度、控制力和实用性,为开发可靠的 Agentic 系统提供了坚实的基础。请求结构化输出对于创建语言模型输出作为后续系统或处理步骤输入的管道至关重要。
Prompt 结构化
除了提供示例的基本技术之外,Prompt 的结构化方式在引导语言模型方面起着关键作用。结构化涉及在 Prompt 中使用不同的部分或元素,以清晰有序的方式提供不同类型的信息,如指令、上下文或示例。这有助于模型正确解析 Prompt 并理解每段文本的具体角色。
推理和思维过程技术
大型语言模型在模式识别和文本生成方面表现出色,但在需要复杂多步推理的任务上常常面临挑战。本节专注于旨在通过鼓励模型揭示其内部思维过程来增强这些推理能力的技术。具体来说,它涉及改进逻辑推理、数学计算和规划的方法。
Chain of Thought (CoT)
Chain of Thought (CoT) Prompting 技术是一种强大的方法,通过明确要求模型在得出最终答案之前生成中间推理步骤,来提高语言模型的推理能力。不是只要求结果,而是指示模型"逐步思考"。这个过程模仿了人类可能如何将一个问题分解为更小、更易处理的部分并按顺序解决。
CoT 帮助 LLM 生成更准确的答案,特别是对于需要某种计算或逻辑推理的任务,模型在这些任务上可能会挣扎并产生不正确的结果。通过生成这些中间步骤,模型更有可能保持在正确轨道上并正确执行必要的操作。
CoT 有两个主要变体:
- Zero-Shot CoT:这涉及简单地在 Prompt 中添加"让我们逐步思考"(或类似措辞),而不提供推理过程的任何示例。令人惊讶的是,对于许多任务,这个简单的添加可以通过触发模型暴露其内部推理轨迹的能力来显著提高模型的性能。
- 示例(Zero-Shot CoT):如果一列火车以每小时 60 英里的速度行驶并覆盖 240 英里的距离,旅程花了多长时间?让我们逐步思考。
- Few-Shot CoT:这结合了 CoT 和 Few-Shot Prompting。为模型提供多个示例,其中输入、逐步推理过程和最终输出都展示了。这为模型提供了如何执行推理和构建其响应的更清晰的模板,通常在更复杂的任务上产生比 Zero-Shot CoT 更好的结果。
- 示例(Few-Shot CoT):
text
Q:三个连续整数的和是 36。这些整数是什么? A:设第一个整数为 x。下一个连续整数是 x+1,第三个是 x+2。和为 x + (x+1) + (x+2) = 3x + 3。已知和为 36,所以 3x + 3 = 36。两边减去 3:3x = 33。除以 3:x = 11。整数是 11、11+1=12 和 11+2=13。整数是 11、12 和 13。 Q:Sarah 有 5 个苹果,她又买了 8 个。她吃了 3 个苹果。她还剩多少个苹果?让我们逐步思考。 A:让我们逐步思考。Sarah 开始有 5 个苹果。她又买了 8 个,所以她在初始数量上加了 8:5 + 8 = 13 个苹果。然后,她吃了 3 个苹果,所以我们从总数中减去 3:13 - 3 = 10。Sarah 还剩 10 个苹果。答案是 10。
- 示例(Few-Shot CoT):
CoT 提供了几个优势。它实现起来相对简单,无需微调即可与现成的 LLM 高效配合。一个显著的好处是模型输出的可解释性增强;你可以看到它遵循的推理步骤,这有助于理解为什么它得出特定答案,并在出现问题时进行调试。此外,CoT 似乎提高了 Prompt 在不同版本语言模型之间的鲁棒性,意味着当模型更新时性能不太可能下降。主要缺点是生成推理步骤会增加输出的长度,导致更高的 token 使用量,从而可能增加成本和响应时间。
CoT 的最佳实践包括确保最终答案在推理步骤之后呈现,因为推理的生成会影响答案的后续 token 预测。此外,对于有单一正确答案的任务(如数学问题),在使用 CoT 时建议将模型的 temperature 设置为 0(贪心解码),以确保在每个步骤中确定性选择最可能的下一个 token。
Self-Consistency
基于 Chain of Thought 的思想,Self-Consistency 技术旨在通过利用语言模型的概率特性来提高推理的可靠性。与依赖于单一贪心推理路径(如基本 CoT)不同,Self-Consistency 为同一问题生成多个不同的推理路径,然后选择其中最一致的答案。
Self-Consistency 涉及三个主要步骤:
- 生成多样化的推理路径:相同的 Prompt(通常是 CoT Prompt)被多次发送给 LLM。通过使用更高的 temperature 设置,鼓励模型探索不同的推理方法并生成不同的逐步解释。
- 提取答案:从每个生成的推理路径中提取最终答案。
- 选择最常见的答案:对提取的答案进行多数投票。在多样化的推理路径中出现最频繁的答案被选为最终的、最一致的答案。
这种方法提高了响应的准确性和连贯性,特别是对于可能存在多个有效推理路径的任务,或者模型在单次尝试中可能出错的场景。好处是答案正确的伪概率似然度增加,从而提高整体准确性。然而,显著的代价是需要对同一查询多次运行模型,导致更高的计算开销和费用。
- 示例(概念性):
- Prompt:"语句'所有鸟都会飞'是真还是假?解释你的推理。"
- 模型运行 1(高温度):推理大多数鸟会飞,结论为 True。
- 模型运行 2(高温度):推理企鹅和鸵鸟的情况,结论为 False。
- 模型运行 3(高温度):一般性地推理鸟类,简要提及例外,结论为 True。
- Self-Consistency 结果:基于多数投票(True 出现两次),最终答案为"True"。(注意:更复杂的方法会权衡推理质量)。
Step-Back Prompting
Step-Back Prompting 通过首先要求语言模型考虑与任务相关的一般原则或概念(然后再处理具体细节)来增强推理。对这个更广泛问题的响应随后被用作解决原始问题的上下文。
这个过程允许语言模型激活相关的背景知识和更广泛的推理策略。通过专注于底层原则或更高层次的抽象,模型可以生成更准确和更有洞察力的答案,减少受表面元素影响的可能性。最初考虑一般因素可以为生成特定的创造性输出提供更强的基础。Step-Back Prompting 鼓励批判性思维和知识的应用,通过强调一般原则来潜在地减轻偏差。
- 示例:
- Prompt 1(退一步):"什么因素使一个好的侦探故事?"
- 模型响应 1:(列出红鲱鱼、引人入胜的动机、有缺陷的主角、逻辑线索、令人满意的结局等元素)。
- Prompt 2(原始任务 + Step-Back 上下文):"使用好的侦探故事的关键因素 [在此插入模型响应 1],为一个设定在小城镇的新推理小说编写一个简短的情节摘要。"
Tree of Thoughts (ToT)
Tree of Thoughts (ToT) 是一种扩展 Chain of Thought 方法的先进推理技术。它使语言模型能够并发探索多个推理路径,而不是遵循单一的线性进展。这种技术利用树结构,其中每个节点代表一个"思维"——一个作为中间步骤的连贯语言序列。从每个节点,模型可以分支出去,探索替代的推理路线。
ToT 特别适合需要探索、回溯或在得出解决方案之前评估多种可能性的复杂问题。虽然比线性的 Chain of Thought 方法在计算上要求更高且实现更复杂,但 ToT 可以在需要深思熟虑和探索性解决问题的任务上取得更优的结果。它允许 Agent 考虑不同的视角,并通过调查"思维树"中的替代分支来潜在地从初始错误中恢复。
- 示例(概念性):对于复杂的创意写作任务,如"基于这些情节要点为故事开发三种不同的可能结局",ToT 将允许模型从关键转折点探索不同的叙事分支,而不仅仅是生成一个线性的延续。
这些推理和思维过程技术对于构建能够处理超越简单信息检索或文本生成任务的 Agent 至关重要。通过提示模型暴露其推理、考虑多种视角或退回到一般原则,我们可以显著增强其在 Agentic 系统中执行复杂认知任务的能力。
行动和交互技术
智能 Agent 具有积极与环境互动的能力,超越文本生成。这包括使用工具、执行外部函数以及参与观察、推理和行动的迭代循环。本节讨论旨在实现这些主动行为的 Prompting 技术。
Tool Use / Function Calling
Agent 的一个关键能力是使用外部工具或调用函数来执行超出其内部能力的操作。这些操作可能包括网页搜索、数据库访问、发送电子邮件、执行计算或与外部 API 交互。有效的 Tool Use Prompting 涉及设计 Prompt,指导模型在适当的时间和以适当的方式使用工具。
现代语言模型通常经过"function calling"或"tool use"的微调。这使得它们能够解释可用工具的描述,包括其目的和参数。在收到用户请求后,模型可以确定使用工具的必要性,识别适当的工具,并格式化调用所需的参数。模型不直接执行工具。相反,它生成一个结构化输出(通常为 JSON 格式),指定工具及其参数。Agentic 系统然后处理此输出,执行工具,并将工具的结果返回给模型,将其整合到正在进行的交互中。
- 示例:
text
你可以访问一个天气工具,可以获取指定城市的当前天气。该工具名为 'get_current_weather',接受 'city' 参数(字符串)。 用户:伦敦现在的天气怎么样? 预期模型输出(Function Call): { "tool_code": "get_current_weather", "tool_name": "get_current_weather", "parameters": { "city": "London" } }
ReAct (Reason & Act)
ReAct,即 Reason and Act 的缩写,是一种将 Chain of Thought 风格推理与使用工具执行行动的能力以交错方式结合的 Prompting 范式。ReAct 模仿人类的操作方式——我们进行言语推理并采取行动以收集更多信息或朝着目标推进。
ReAct 模式涉及一个循环:
- Thought:模型生成一个思维过程,解释其当前理解和计划。
- Action:基于思维,模型决定执行一个操作,通常使用工具(例如搜索、计算器、API 调用)。它输出工具名称和所需的输入。
- Observation:Agentic 系统执行工具并将结果(Observation)返回给模型。
- 循环继续,模型基于最新的"Observation"生成新的"Thought",从而产生进一步的"Action"和"Observation",直到任务完成,模型输出"Final Answer"。
这种思维和行动的交错过程允许 Agent 动态地收集信息、对工具输出做出反应并改进其方法,使其特别适用于需要与动态环境或外部知识源交互的任务。
- 示例(说明性 ReAct 轨迹):
text
用户:法国的首都是什么,其当前人口是多少? Thought:用户在询问两条信息:法国的首都和它的人口。我可以使用搜索工具来查找这些信息。我将首先确认首都,尽管我可能已经知道。 Action: Search({"query": "capital of France"}) Observation: Paris Thought:好的,首都是巴黎。现在我需要查找巴黎的人口。 Action: Search({"query": "current population of Paris"}) Observation: The population of Paris was estimated to be around 2.1 million people in 2023. Thought:我已经找到了两条信息。我现在可以向用户提供最终答案。 Final Answer: 法国的首都是巴黎,其 2023 年估计人口约为 210 万人。
这些技术对于构建能够积极与世界互动、检索实时信息以及执行需要与外部系统交互任务的 Agent 至关重要。
高级技术
在基础、结构和推理模式之外,还有其他几种 Prompting 技术可以进一步增强 Agentic 系统的能力和效率。这些技术包括使用 AI 优化 Prompt、整合外部知识以及基于用户特征定制响应。
Automatic Prompt Engineering (APE)
认识到构建有效的 Prompt 可能是一个复杂且迭代的过程,Automatic Prompt Engineering (APE) 探索使用语言模型本身来生成、评估和改进 Prompt。此方法旨在自动化 Prompt 编写过程,可能在不需要大量人工设计工作的情况下提高模型性能。
总体思想是让一个"元模型"或过程接收任务描述并生成多个候选 Prompt。然后根据这些 Prompt 在给定输入集上产生的输出质量来评估它们(可能使用 BLEU 或 ROUGE 等指标,或人工评估)。可以选择表现最佳的 Prompt,进一步改进,然后用于目标任务。使用 LLM 生成用户查询的变体来训练聊天机器人就是这种方法的一个例子。
- 示例(概念性):开发者提供描述:"我需要一个可以从电子邮件中提取日期和发件人的 Prompt。"APE 系统生成几个候选 Prompt。这些在样本电子邮件上进行测试,选择一致提取正确信息的那个 Prompt。
另一种强大的 Prompt 优化技术(由 DSPy 框架特别推广)涉及将 Prompt 视为可自动优化的程序化模块,而非静态文本。这种方法超越了人工试错,进入了更系统化的、数据驱动的方法论。
此技术的核心依赖于两个关键组件:
- Goldset(或高质量数据集):这是一个具有代表性的高质量输入-输出对集合。它作为定义给定任务成功响应样子的"基本事实"。
- 目标函数(或评分指标):这是一个自动将 LLM 的输出与数据集中对应的"黄金"输出进行比较评估的函数。它返回一个表示响应质量、准确性或正确性的分数。
使用这些组件,优化器(如贝叶斯优化器)系统地改进 Prompt。此过程通常涉及两个主要策略,可以独立或结合使用:
- Few-Shot 示例优化:不是由开发者手动为 Few-Shot Prompt 选择示例,而是优化器程序化地从 goldset 中采样不同的示例组合。然后测试这些组合,以识别最能有效引导模型生成期望输出的特定示例集。
- 指令 Prompt 优化:在这种方法中,优化器自动改进 Prompt 的核心指令。它使用 LLM 作为"元模型"来迭代地变异和重新表述 Prompt 的文本——调整措辞、语调或结构——以发现哪种措辞能从目标函数获得最高分数。
两种策略的最终目标都是最大化目标函数的分数,有效地"训练"Prompt 以持续产生更接近高质量 goldset 的结果。通过结合这两种方法,系统可以同时优化给模型什么指令以及向模型展示什么示例,从而产生针对特定任务的、机器优化后的高效且鲁棒的 Prompt。
Iterative Prompting / Refinement
此技术涉及从一个简单的、基本的 Prompt 开始,然后根据模型的初始响应迭代改进它。如果模型的输出不太正确,你分析不足之处并修改 Prompt 来解决它们。这与其说是一个自动化过程(如 APE),不如说是一个人工驱动的迭代设计循环。
- 示例:
- 尝试 1:"为一种新型咖啡机编写产品描述。"(结果太笼统)。
- 尝试 2:"为一种新型咖啡机编写产品描述。突出其速度和易于清洁的特点。"(结果更好,但缺乏细节)。
- 尝试 3:"为 'SpeedClean Coffee Pro' 编写产品描述。强调其在 2 分钟内煮一壶咖啡的能力和自清洁循环。目标受众是忙碌的专业人士。"(结果更接近期望)。
Providing Negative Examples
虽然"正面指令优于约束"的原则通常成立,但在某些情况下提供负面示例可能会有帮助,尽管需要谨慎使用。负面示例向模型展示一个输入和一个不期望的输出,或者一个输入和一个不应生成的输出。这可以帮助澄清边界或防止特定类型的错误响应。
- 示例:
text
生成一份巴黎热门旅游景点的列表。不要包括埃菲尔铁塔。 不应做的示例: 输入:列出巴黎的热门地标。 输出:埃菲尔铁塔、卢浮宫、巴黎圣母院。
Using Analogies
使用类比来构建任务可以帮助模型通过将其与熟悉的事物关联来理解期望的输出或过程。这对于创意任务或解释复杂角色特别有用。
- 示例:
text
扮演一个"数据厨师"。用原始食材(数据点)准备一道"摘要菜肴"(报告),为商业受众突出关键的风味(趋势)。
Factored Cognition / Decomposition
对于非常复杂的任务,将总体目标分解为更小的、更易管理的子任务,然后分别对每个子任务提示模型,是有效的。然后将子任务的结果组合以实现最终结果。这与 Prompt Chaining 和 Planning 相关,但强调的是对问题的有意分解。
- 示例:撰写一篇研究论文:
- Prompt 1:"生成一篇关于 AI 对就业市场影响的论文的详细大纲。"
- Prompt 2:"根据以下大纲撰写引言部分:[插入大纲引言]。"
- Prompt 3:"根据以下大纲撰写'对白领工作的影响'部分:[插入大纲部分]。"(对其他部分重复)。
- Prompt N:"将这些部分合并并撰写结论。"
Retrieval Augmented Generation (RAG)
RAG 是一种强大的技术,通过在 Prompting 过程中为语言模型提供外部、最新或领域特定的信息来增强它们。当用户提出问题时,系统首先从知识库(如数据库、文档集、网页)中检索相关文档或数据。然后将检索到的信息作为上下文包含在 Prompt 中,使语言模型能够基于该外部知识生成有根据的响应。这缓解了幻觉等问题,并使模型能够访问其未训练过的或非常新的信息。这是需要处理动态或专有信息的 Agentic 系统的关键模式。
- 示例:
- 用户查询:"Python 库 'X' 的最新版本有哪些新功能?"
- 系统操作:在文档数据库中搜索"Python library X latest features"。
- 给 LLM 的 Prompt:"基于以下文档片段:[插入检索到的文本],解释 Python 库 'X' 最新版本的新功能。"
Persona Pattern(用户画像)
虽然 Role Prompting 为模型分配一个人设,但 Persona Pattern 涉及描述模型输出的用户或目标受众。这有助于模型在语言、复杂度、语调和提供的信息类型方面定制其响应。
- 示例:
text
你在解释量子物理学。目标受众是没有该学科先备知识的高中生。简单解释并使用他们可能理解的类比。 解释量子物理学:[插入基本解释请求]
这些高级和补充技术为 Prompt 工程师提供了进一步优化模型行为、整合外部信息以及为 Agentic 工作流中特定用户和任务定制交互的工具。
使用 Google Gems
Google 的 AI "Gems"(见图 1)在其大型语言模型架构中代表了一个用户可配置的功能。每个"Gem"作为核心 Gemini AI 的一个专用实例运行,为特定的、可重复的任务定制。用户通过提供一组明确的指令来创建 Gem,建立其操作参数。这个初始指令集定义了 Gem 的指定用途、响应风格和知识领域。底层模型被设计为在整个对话过程中始终遵循这些预定义的指令。
这允许创建高度专用的 AI Agent 用于聚焦的应用。例如,一个 Gem 可以被配置为仅引用特定编程库的代码解释器。另一个可以被指示分析数据集,生成不带推测性评论的摘要。一个不同的 Gem 可能作为遵循特定正式风格指南的翻译器。这个过程为人工智能创建了一个持久的、任务特定的上下文。因此,用户避免了在每次新查询时重新建立相同上下文信息的需要。这种方法论减少了对话冗余并提高了任务执行效率。由此产生的交互更加聚焦,产生的输出与用户的初始需求始终保持一致。该框架允许将细粒度的、持久的用户方向应用于通用 AI 模型。最终,Gems 实现了从通用目的交互到专用的、预定义 AI 功能的转变。

使用 LLM 改进 Prompt(元方法)
我们已经探讨了多种构建有效 Prompt 的技术,强调了清晰性、结构以及提供上下文或示例。然而,这个过程可能是迭代的,有时甚至是具有挑战性的。如果我们能利用大型语言模型(如 Gemini)的能力来帮助我们改进 Prompt 呢?这就是使用 LLM 进行 Prompt 改进的精髓——一种"元"应用,AI 协助优化给 AI 的指令。
这种能力特别"酷",因为它代表了 AI 自我改进的一种形式,或者至少是 AI 辅助人类改进与 AI 交互的方式。与其仅依赖人类直觉和试错,我们可以利用 LLM 对语言、模式甚至常见 Prompt 陷阱的理解来获得改进 Prompt 的建议。它将 LLM 转变为 Prompt Engineering 过程中的协作伙伴。
在实践中如何运作?你可以为语言模型提供一个你试图改进的现有 Prompt,以及你希望它完成的任务,甚至可能包括你当前获得的输出示例(以及为什么它不符合你的期望)。然后你提示 LLM 分析该 Prompt 并提出改进建议。
像 Gemini 这样具有强大推理和语言生成能力的模型,可以分析你现有的 Prompt 中潜在的歧义、缺乏具体性或措辞低效的区域。它可以建议采用我们讨论过的技术,如添加分隔符、明确期望的输出格式、建议更有效的人设或推荐包含 Few-Shot 示例。
这种元 Prompting 方法的优势包括:
- 加速迭代:比纯人工试错更快地获得改进建议。
- 识别盲点:LLM 可能发现你忽略的 Prompt 中的歧义或潜在误解。
- 学习机会:通过观察 LLM 提出的建议类型,你可以更多地了解什么使 Prompt 有效,并提高你自己的 Prompt Engineering 技能。
- 可扩展性:潜在地自动化 Prompt 优化过程的部分,特别是在处理大量 Prompt 时。
需要注意的是,LLM 的建议并不总是完美的,应该像任何手工设计的 Prompt 一样进行评估和测试。然而,它提供了一个强大的起点,可以显著简化改进过程。
- 改进 Prompt 示例:
text
分析以下用于语言模型的 Prompt,并建议改进方法,使其能够始终从新闻文章中提取主要主题和关键实体(人物、组织、地点)。当前 Prompt 有时会遗漏实体或弄错主要主题。 现有 Prompt: "总结以下文章的要点,并列出其中的重要姓名和地点:[插入文章文本]"
改进建议:
在此示例中,我们使用 LLM 来批评和改进另一个 Prompt。这种元级别交互展示了这些模型的灵活性和强大功能,允许我们首先优化基本指令来构建更有效的 Agentic 系统。这是一个令人着迷的循环,AI 帮助我们更好地与 AI 对话。
特定任务的 Prompting
虽然到目前为止讨论的技术具有广泛的适用性,但某些任务受益于特定的 Prompting 注意事项。这些在代码和多模态输入领域尤为相关。
Code Prompting
语言模型,尤其是那些在大规模代码数据集上训练过的,可以成为开发人员的强大助手。代码 Prompting 涉及使用 LLM 来生成、解释、翻译或调试代码。存在各种使用场景:
- 编写代码的 Prompt:要求模型根据期望功能的描述生成代码片段或函数。
- 示例:"编写一个 Python 函数,接收一个数字列表并返回平均值。"
- 解释代码的 Prompt:提供代码片段并要求模型解释其功能,逐行或以摘要形式。
- 示例:"解释以下 JavaScript 代码片段:[插入代码]。"
- 翻译代码的 Prompt:要求模型将代码从一种编程语言翻译到另一种。
- 示例:"将以下 Java 代码翻译为 C++:[插入代码]。"
- 调试和审查代码的 Prompt:提供有错误或可以改进的代码,要求模型识别问题、建议修复或提供重构建议。
- 示例:"以下 Python 代码出现 'NameError'。哪里出了问题,我该如何修复?[插入代码和堆栈跟踪]。"
有效的代码 Prompting 通常需要提供足够的上下文、指定期望的语言和版本,并明确功能或问题。
Multimodal Prompting
虽然本附录和当前大部分 LLM 交互的重点是基于文本的,但该领域正迅速转向可以跨不同模态(文本、图像、音频、视频等)处理和生成信息的多模态模型。Multimodal Prompting 涉及使用输入的组合来引导模型。这指的是使用多种输入格式,而不仅仅是文本。
- 示例:提供一张图表的图像并要求模型解释图中展示的过程(图像输入 + 文本 Prompt)。或者提供一张图像并要求模型生成描述性标题(图像输入 + 文本 Prompt → 文本输出)。
随着多模态能力变得更加复杂,Prompting 技术也将演进,以有效地利用这些组合的输入和输出。
最佳实践和实验
成为一名熟练的 Prompt 工程师是一个涉及持续学习和实验的迭代过程。几个有价值的最佳实践值得重申和强调:
- 提供示例:提供 One-Shot 或 Few-Shot 示例是引导模型最有效的方法之一。
- 简洁设计:保持 Prompt 简洁、清晰和易于理解。避免不必要的行话或过于复杂的措辞。
- 明确输出要求:明确定义模型响应的期望格式、长度、风格和内容。
- 使用指令而非约束:专注于告诉模型你想要它做什么,而不是你不想要它做什么。
- 控制最大 Token 长度:使用模型配置或明确的 Prompt 指令来管理生成输出的长度。
- 在 Prompt 中使用变量:对于应用中使用的 Prompt,使用变量使其动态化和可重用,避免硬编码特定值。
- 尝试不同的输入格式和写作风格:尝试不同方式表达你的 Prompt(问题、陈述、指令)并尝试不同的语调或风格以查看哪种效果最好。
- 分类任务的 Few-Shot Prompting 中混合类别:随机化不同类别示例的顺序以防止过拟合。
- 适应模型更新:语言模型不断更新。准备好在新模型版本上测试现有 Prompt 并进行调整以利用新功能或保持性能。
- 尝试不同的输出格式:尤其是对于非创造性任务,尝试请求结构化输出如 JSON 或 XML。
- 与其他 Prompt 工程师合作:与他人协作可以提供不同的视角并导致发现更有效的 Prompt。
- CoT 最佳实践:记住 Chain of Thought 的特定实践,如将答案放在推理之后,以及对于有单一正确答案的任务将 temperature 设置为 0。
- 记录各种 Prompt 尝试:这对于跟踪什么有效、什么无效以及为什么至关重要。维护 Prompt、配置和结果的结构化记录。
- 在代码库中保存 Prompt:将 Prompt 集成到应用中时,将它们存储在单独的、组织良好的文件中,以便于维护和版本控制。
- 依赖自动化测试和评估:对于生产系统,实施自动化测试和评估程序来监控 Prompt 性能并确保对新数据的泛化。
Prompt Engineering 是一种通过实践不断提高的技能。通过应用这些原则和技术,并保持系统化的实验和文档记录方法,你可以显著增强构建有效 Agentic 系统的能力。
小结
本附录提供了 Prompting 的全面概述,将其重新定义为一门有纪律的工程实践,而非简单的提问行为。其核心目的是展示如何将通用语言模型转变为特定任务的、可靠且高度能力的工具。这一旅程始于不可妥协的核心原则——清晰性、简洁性和迭代实验——这些是与 AI 有效沟通的基石。
这些原则至关重要,因为它们减少了自然语言中固有的歧义,帮助将模型的概率性输出引导到单一的、正确的意图上。在此基础上,Zero-Shot、One-Shot 和 Few-Shot Prompting 等基础技术作为通过示例展示期望行为的主要方法。这些方法提供了不同程度的上下文指导,有力地塑造了模型的响应风格、语调和格式。除了示例之外,通过明确角色、系统级指令和清晰分隔符来结构化 Prompt 提供了一个精细控制的必要架构层。
在构建自主 Agent 的背景下,这些技术的重要性变得至关重要,因为它们为复杂的多步操作提供了必要的控制和可靠性。要有效地创建和执行计划,Agent 必须利用 Chain of Thought 和 Tree of Thoughts 等高级推理模式。这些复杂的方法迫使模型外化其逻辑步骤,系统地将复杂目标分解为一系列可管理的子任务。整个 Agentic 系统的运行可靠性取决于每个组件输出的可预测性。这正是为什么请求 JSON 等结构化数据并使用 Pydantic 等工具进行程序化验证不是一种便利,而是鲁棒自动化的绝对必要条件。没有这种纪律,Agent 的内部认知组件无法可靠地通信,导致自动化工作流中的灾难性故障。最终,这些结构化和推理技术成功地将模型的概率性文本生成转换为 Agent 的确定性和可信赖的认知引擎。
此外,这些 Prompt 赋予了 Agent 感知和作用于环境的关键能力,弥合了数字思维与现实世界交互之间的差距。ReAct 和原生 Function Calling 等面向行动的框架是作为 Agent "双手"的关键机制,允许它使用工具、查询 API 和操作数据。与此同时,Retrieval Augmented Generation (RAG) 和更广泛的 Context Engineering 学科充当 Agent 的"感官"。它们主动从外部知识库检索相关的实时信息,确保 Agent 的决策基于当前的、事实性的现实。这一关键能力防止 Agent 在真空中运行,使其不再局限于静态的、可能过时的训练数据。掌握这一全面的 Prompting 谱系因此是提升通用语言模型从简单文本生成器转变为真正复杂 Agent 的决定性技能,使其能够以自主性、感知力和智能执行复杂任务。
参考文献
以下是进一步阅读和深入探索 Prompt Engineering 技术的资源列表:
- Prompt Engineering, https://www.kaggle.com/whitepaper-prompt-engineering
- Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, https://arxiv.org/abs/2201.11903
- Self-Consistency Improves Chain of Thought Reasoning in Language Models, https://arxiv.org/pdf/2203.11171
- ReAct: Synergizing Reasoning and Acting in Language Models, https://arxiv.org/abs/2210.03629
- Tree of Thoughts: Deliberate Problem Solving with Large Language Models, https://arxiv.org/pdf/2305.10601
- Take a Step Back: Evoking Reasoning via Abstraction in Large Language Models, https://arxiv.org/abs/2310.06117
- DSPy: Programming—not prompting—Foundation Models, https://github.com/stanfordnlp/dspy
附录B - AI Agentic Interactions:从 GUI 到真实世界环境
AI Agent 越来越多地通过与数字界面和物理世界的交互来执行复杂任务。它们在这些多样化环境中感知、处理和行动的能力正在从根本上改变自动化、人机交互和智能系统。本附录探讨了 Agent 如何与计算机及其环境交互,重点介绍各种进展和项目。
交互:Agent 与计算机
AI 从对话伙伴到主动的、面向任务的 Agent 的演进正由 Agent-Computer Interfaces (ACI) 推动。这些接口允许 AI 直接与计算机的 Graphical User Interface (GUI) 交互,使其能够像人类一样感知和操作图标和按钮等视觉元素。这种新方法超越了依赖 API 和系统调用的传统自动化的僵化、依赖开发者的脚本。通过使用软件的视觉"前门",AI 现在可以以更灵活和强大的方式自动化复杂的数字任务,这个过程涉及几个关键阶段:
- 视觉感知:Agent 首先捕获屏幕的视觉表示,本质上是截取屏幕截图。
- GUI 元素识别:然后分析此图像以区分各种 GUI 元素。它必须学会将屏幕"看"作不仅仅是像素的集合,而是一个具有交互组件的结构化布局,辨别可点击的"提交"按钮与静态横幅图像,或可编辑文本字段与简单标签。
- 上下文解释:ACI 模块作为视觉数据和 Agent 核心智能(通常是大型语言模型或 LLM)之间的桥梁,在任务上下文中解释这些元素。它理解放大镜图标通常意味着"搜索"或一系列单选按钮代表一个选择。此模块对于增强 LLM 的推理至关重要,使其能够基于视觉证据形成计划。
- 动态行动和响应:Agent 然后以编程方式控制鼠标和键盘来执行其计划——点击、输入、滚动和拖拽。关键是,它必须不断监控屏幕的视觉反馈,动态地响应变化、加载屏幕、弹出通知或错误,以成功导航多步骤工作流。
这项技术已不再停留在理论阶段。几家领先的 AI 实验室已经开发了展示 GUI 交互强大功能的功能性 Agent:
ChatGPT Operator(OpenAI):被设想为数字合作伙伴,ChatGPT Operator 旨在直接从桌面跨广泛的应用程序自动化任务。它理解屏幕上的元素,使其能够执行将数据从电子表格传输到客户关系管理(CRM)平台、跨航空公司和酒店网站预订复杂的旅行行程,或填写详细的在线表单等操作,而无需为每个服务提供专门的 API 访问。这使它成为一个普遍适用的工具,旨在通过接管重复性数字杂务来提升个人和企业生产力。
Google Project Mariner:作为研究原型,Project Mariner 作为 Chrome 浏览器内的 Agent 运行。其目的是理解用户意图并自主代表用户执行基于网页的任务。例如,用户可以要求它在特定预算和社区内找到三套待租公寓;Mariner 将导航到房地产网站,应用筛选器,浏览列表,并将相关信息提取到文档中。该项目代表了 Google 在创建真正有用且"主动的"网络体验方面的探索,使浏览器主动为用户工作。

Anthropic 的 Computer Use:此功能使 Anthropic 的 AI 模型 Claude 能够成为计算机桌面环境的直接用户。通过捕获屏幕截图来感知屏幕并以编程方式控制鼠标和键盘,Claude 可以编排跨多个不相连应用程序的工作流。用户可以要求它分析 PDF 报告中的数据,打开电子表格应用程序对该数据执行计算,生成图表,然后将该图表粘贴到电子邮件草稿中——一系列以前需要持续人工输入的任务。
Browser Use:这是一个开源库,提供了一个用于编程式浏览器自动化的高级 API。它通过授予 AI Agent 访问和控制 Document Object Model (DOM) 的能力,使其能够与网页交互。该 API 将浏览器控制协议的复杂低级命令抽象为一组更简化和直观的函数。这使得 Agent 能够执行复杂的操作序列,包括从嵌套元素中提取数据、表单提交以及跨多个页面的自动化导航。因此,该库促进了将非结构化网页数据转换为 AI Agent 可以系统化处理和利用进行分析或决策的结构化格式。
交互:Agent 与环境
在计算机屏幕的局限之外,AI Agent 越来越被设计为与复杂、动态的环境(通常模拟真实世界)进行交互。这需要复杂的感知、推理和执行能力。
Google 的 Project Astra 是一个推动 Agent 与环境交互边界的首要例子。Astra 旨在创建一个在日常生活中的通用 AI Agent,利用多模态输入(视觉、声音、语音)和输出,以有上下文感知的方式理解和与世界交互。该项目专注于快速理解、推理和响应,允许 Agent 通过摄像头和麦克风"看到"和"听到"其周围环境,同时参与自然对话并提供实时协助。Astra 的愿景是一个可以无缝帮助用户处理从寻找丢失物品到调试代码等任务的 Agent,通过理解其观察到的环境。这超越了简单的语音命令,真正体现了对用户即时物理环境的理解。
Google 的 Gemini Live 将标准 AI 交互转变为流畅且动态的对话。用户可以与 AI 交谈并以自然的语音接收响应,延迟极小,甚至可以在句子中间打断或更改话题,促使 AI 立即适应。该界面扩展到语音之外,允许用户通过使用手机的摄像头、共享屏幕或上传文件来纳入视觉信息,进行更具上下文感知的讨论。更高级的版本甚至可以感知用户的语调并智能地过滤无关的背景噪音以更好地理解对话。这些能力结合起来创造了丰富的交互,例如只需将摄像头对准任务即可接收实时的操作指导。
OpenAI 的 GPT-4o 模型 是另一种为"全模态"交互设计的替代方案,意味着它可以跨语音、视觉和文本进行推理。它以模仿人类响应时间的低延迟处理这些输入,从而允许实时对话。例如,用户可以向 AI 展示实时视频流以询问正在发生的事情,或将其用于语言翻译。OpenAI 为开发者提供了"Realtime API"以构建需要低延迟、语音到语音交互的应用。
OpenAI 的 ChatGPT Agent 代表了相比其前身的重大架构进步,具有集成的新功能框架。其设计包含几个关键功能模态:自主导航实时互联网进行实时数据提取的能力、动态生成和执行计算代码以处理数据分析等任务的能力,以及直接与第三方软件应用交互的功能。这些功能的综合允许 Agent 从单一用户指令编排和完成复杂的顺序工作流。因此它可以自主管理整个流程,例如执行市场分析并生成相应的演示文稿,或规划后勤安排并执行必要的交易。在发布的同时,OpenAI 积极解决了此类系统中固有的新兴安全考虑因素。随附的"System Card"描述了与能够在线执行操作的 AI 相关的潜在操作风险,承认了新的滥用向量。为了减轻这些风险,Agent 的架构包含工程化的安全措施,例如要求对某些类别的操作获得明确的用户授权以及部署强大的内容过滤机制。
Seeing AI 是微软的一款免费移动应用,通过提供周围环境的实时叙述来赋能盲人或低视力人士。该应用通过设备摄像头利用人工智能来识别和描述各种元素,包括物体、文本甚至人物。其核心功能涵盖文档阅读、货币识别、通过条形码识别产品以及描述场景和颜色。通过提供对视觉信息的增强访问,Seeing AI 最终促进了视障用户的更大独立性。
Anthropic 的 Claude 4 系列 是另一个具有高级推理和分析能力的替代方案。虽然历史上专注于文本,Claude 4 包括强大的视觉能力,使其能够处理来自图像、图表和文档的信息。该模型适合处理复杂的多步骤任务并提供详细分析。虽然实时对话方面不是其主要关注点(与其他模型相比),但其底层智能专为构建高度能力的 AI Agent 而设计。
Vibe Coding:与 AI 直觉化开发
除了与 GUI 和物理世界的直接交互之外,开发者使用 AI 构建软件的方式正在出现一种新范式:"Vibe Coding"。这种方法摆脱了精确的、逐步的指令,转而依赖开发者和 AI 编码助手之间更直观、对话式和迭代的交互。开发者提供高层目标、期望的"氛围"或一般方向,AI 生成匹配的代码。
这个过程的特点是:
- 对话式 Prompt:开发者在不编写详细规范的情况下,可能会说"为一个新应用创建一个简单、现代风格的着陆页",或者"重构这个函数使其更 Pythonic 和可读"。AI 解释"现代"或"Pythonic"的"氛围"并生成相应的代码。
- 迭代改进:AI 的初始输出通常是一个起点。然后开发者用自然语言提供反馈,例如"这是一个好的开始,但你能把按钮变成蓝色吗?"或"添加一些错误处理"。这种来回交流继续进行,直到代码满足开发者的期望。
- 创意合作:在 Vibe Coding 中,AI 作为创意合作伙伴,提出开发者可能没有想到的想法和解决方案。这可以加速开发过程并导致更具创新性的结果。
- 专注于"什么"而非"如何":开发者专注于期望的结果("什么"),将实现细节("如何")留给 AI。这允许快速原型设计和探索不同方法,而不会陷入样板代码中。
- 可选的记忆库:为了在较长的交互中维持上下文,开发者可以使用"记忆库"来存储关键信息、偏好或约束。例如,开发者可以将特定的编码风格或一组项目需求保存到 AI 的记忆中,确保未来的代码生成与已建立的"氛围"保持一致,而无需重复指令。
Vibe Coding 随着强大的 AI 模型(如 GPT-4、Claude 和 Gemini)集成到开发环境中而变得越来越受欢迎。这些工具不仅是在自动补全代码;它们正积极参与软件开发的创意过程,使其更易于访问和更高效。这种新的工作方式正在改变软件工程的面貌,强调创造力和高层次思维而非对语法和 API 的死记硬背。
要点
- AI Agent 正从简单的自动化演变为通过图形用户界面视觉控制软件,就像人类一样。
- 下一个前沿是真实世界交互,Google 的 Astra 等项目使用摄像头和麦克风来看到、听到并理解其物理环境。
- 领先科技公司正在融合这些数字和物理能力,以创建跨两个领域无缝运行的通用 AI 助手。
- 这种转变正在创造一类新的主动的、具有上下文感知能力的 AI 伴侣,能够协助用户日常生活中的广泛任务。
小结
Agent 正在经历重大变革,从基础自动化转向与数字和物理环境的复杂交互。通过利用视觉感知来操作图形用户界面,这些 Agent 现在可以像人类一样操作软件,绕过对传统 API 的需求。主要技术实验室正在以能够自动化直接在用户桌面上执行的复杂、多应用程序工作流的 Agent 开拓这一领域。同时,下一个前沿正在扩展到物理世界,Google 的 Project Astra 等计划使用摄像头和麦克风来有上下文地与环境互动。这些高级系统被设计为多模态的、实时的理解,模拟人类交互。
最终愿景是这些数字和物理能力的融合,创建跨所有用户环境无缝运行的通用 AI 助手。这种演进也在通过"Vibe Coding"重塑软件创建本身——这是开发者和 AI 之间一种更直观和对话式的合作。这种新方法优先考虑高层目标和创意意图,让开发者专注于期望的结果而非实现细节。这种转变通过将 AI 视为创意合作伙伴来加速开发并促进创新。最终,这些进步正在为一个新的主动的、具有上下文感知能力的 AI 伴侣时代铺平道路,能够协助我们日常生活中的广泛任务。
参考文献
- Open AI Operator, https://openai.com/index/introducing-operator/
- Open AI ChatGPT Agent, https://openai.com/index/introducing-chatgpt-agent/
- Browser Use, https://docs.browser-use.com/introduction
- Project Mariner, https://deepmind.google/models/project-mariner/
- Anthropic Computer Use, https://docs.anthropic.com/en/docs/build-with-claude/computer-use
- Project Astra, https://deepmind.google/models/project-astra/
- Gemini Live, https://gemini.google/overview/gemini-live/?hl=en
- OpenAI's GPT-4, https://openai.com/index/gpt-4-research/
- Claude 4, https://www.anthropic.com/news/claude-4
附录C - Agentic 框架快速概览
LangChain
LangChain 是一个用于开发由 LLM 驱动的应用程序的框架。其核心优势在于其 LangChain Expression Language (LCEL),它允许你将组件"管道化"连接成一个链。这创建了一个清晰的线性序列,其中一个步骤的输出成为下一个步骤的输入。它构建用于是有向无环图(DAG)的工作流,即流程沿一个方向流动而没有循环。
适用于:
- 简单 RAG:检索文档、创建 Prompt、从 LLM 获取答案。
- 摘要:获取用户文本,输入到摘要 Prompt,返回输出。
- 提取:从文本块中提取结构化数据(如 JSON)。
# A simple LCEL chain conceptually
# (This is not runnable code, just illustrates the flow)
chain = prompt | model | output_parseLangGraph
LangGraph 是构建在 LangChain 之上的一个库,用于处理更高级的 Agentic 系统。它允许你将工作流定义为一个包含节点(函数或 LCEL 链)和边(条件逻辑)的图。其主要优势是创建循环的能力,允许应用循环、重试或以灵活顺序调用工具,直到任务完成。它显式管理应用状态,该状态在节点之间传递并在整个过程中更新。
适用于:
- 多 Agent 系统:一个主管 Agent 将任务路由到专门的 Worker Agent,可能循环直到目标达成。
- 计划-执行 Agent:Agent 创建计划,执行一个步骤,然后循环回来根据结果更新计划。
- Human-in-the-Loop:图可以在决定前往下一个节点之前等待人工输入。
| 特性 | LangChain | LangGraph |
|---|---|---|
| 核心抽象 | Chain(使用 LCEL) | 节点图 |
| 工作流类型 | 线性(有向无环图) | 循环(带循环的图) |
| 状态管理 | 每次运行通常无状态 | 显式和持久的状态对象 |
| 主要用途 | 简单、可预测的序列 | 复杂、动态、有状态的 Agent |
该用哪个?
- 当应用程序有清晰、可预测和线性的步骤流程时选择 LangChain。如果你可以将过程从 A 定义到 B 到 C 而不需要循环,LangChain 配合 LCEL 是完美的工具。
- 当需要应用程序进行推理、规划或在循环中操作时选择 LangGraph。如果 Agent 需要使用工具、反思结果并可能尝试不同的方法,你需要 LangGraph 的循环和有状态特性。
# Graph state
class State(TypedDict):
topic: str
joke: str
story: str
poem: str
combined_output: str
# Nodes
def call_llm_1(state: State):
"""First LLM call to generate initial joke"""
msg = llm.invoke(f"Write a joke about {state['topic']}")
return {"joke": msg.content}
def call_llm_2(state: State):
"""Second LLM call to generate story"""
msg = llm.invoke(f"Write a story about {state['topic']}")
return {"story": msg.content}
def call_llm_3(state: State):
"""Third LLM call to generate poem"""
msg = llm.invoke(f"Write a poem about {state['topic']}")
return {"poem": msg.content}
def aggregator(state: State):
"""Combine the joke and story into a single output"""
combined = f"Here's a story, joke, and poem about {state['topic']}!\n\n"
combined += f"STORY:\n{state['story']}\n\n"
combined += f"JOKE:\n{state['joke']}\n\n"
combined += f"POEM:\n{state['poem']}"
return {"combined_output": combined}
# Build workflow
parallel_builder = StateGraph(State)
# Add nodes
parallel_builder.add_node("call_llm_1", call_llm_1)
parallel_builder.add_node("call_llm_2", call_llm_2)
parallel_builder.add_node("call_llm_3", call_llm_3)
parallel_builder.add_node("aggregator", aggregator)
# Add edges to connect nodes
parallel_builder.add_edge(START, "call_llm_1")
parallel_builder.add_edge(START, "call_llm_2")
parallel_builder.add_edge(START, "call_llm_3")
parallel_builder.add_edge("call_llm_1", "aggregator")
parallel_builder.add_edge("call_llm_2", "aggregator")
parallel_builder.add_edge("call_llm_3", "aggregator")
parallel_builder.add_edge("aggregator", END)
parallel_workflow = parallel_builder.compile()
# Show workflow
display(Image(parallel_workflow.get_graph().draw_mermaid_png()))
# Invoke
state = parallel_workflow.invoke({"topic": "cats"})
print(state["combined_output"])此代码定义并运行一个并行操作的 LangGraph 工作流。其主要目的是同时生成关于给定主题的笑话、故事和诗歌,然后将它们合并为一个单一的、格式化的文本输出。
Google 的 ADK
Google 的 Agent Development Kit(ADK)提供了一个高级、结构化的框架,用于构建和部署由多个交互式 AI Agent 组成的应用程序。它与 LangChain 和 LangGraph 的区别在于提供了一种更加有主见的、面向生产的系统来编排 Agent 协作,而非提供 Agent 内部逻辑的基础构建块。
LangChain 在最基础层面运行,提供创建操作序列(如调用模型和解析其输出)的组件和标准化接口。LangGraph 通过引入更灵活和强大的控制流来扩展这一点;它将 Agent 的工作流视为有状态图。使用 LangGraph,开发者显式定义节点(函数或工具)和边(执行路径)。这种图结构允许复杂的循环推理,系统可以循环、重试任务并基于在节点之间传递的显式管理的状态对象做出决策。它为开发者提供了对单个 Agent 思维过程的精细控制,或从头构建多 Agent 系统的能力。
Google 的 ADK 抽象化了大部分这种低级别的图构建。它不是要求开发者定义每个节点和边,而是为多 Agent 交互提供预构建的架构模式。例如,ADK 具有内置的 Agent 类型如 SequentialAgent 或 ParallelAgent,它们自动管理不同 Agent 之间的控制流。它围绕 Agent "团队"的概念构建,通常有一个主 Agent 将任务委派给专门的子 Agent。状态和会话管理由框架更隐式地处理,提供了一种比 LangGraph 显式状态传递更内聚但不够精细的方法。因此,虽然 LangGraph 为你提供了设计单个机器人或团队复杂接线的详细工具,Google 的 ADK 为你提供了一条旨在构建和管理已知如何协作的机器人"舰队"的工厂装配线。
from google.adk.agents import LlmAgent
from google.adk.tools import google_search
dice_agent = LlmAgent(
model="gemini-2.0-flash-exp",
name="question_answer_agent",
description="A helpful assistant agent that can answer questions.",
instruction="""Respond to the query using google search""",
tools=[google_search],
)此代码创建了一个搜索增强的 Agent。当此 Agent 收到问题时,它不仅依赖其预存知识。相反,遵循其指令,它将使用 Google Search 工具从网页查找相关实时信息,然后使用该信息构建其答案。
CrewAI
CrewAI 提供了一个编排框架,通过专注于协作角色和结构化流程来构建多 Agent 系统。它在比基础工具包更高的抽象层次上运行,提供了一个模拟人类团队的概念模型。开发者不是将逻辑的细粒度流程定义为图,而是定义行为者和他们的任务,CrewAI 管理他们的交互。
此框架的核心组件是 Agent、Task 和 Crew。Agent 不仅由其功能定义,还由一个包含特定角色、目标和背景故事的人设定义,这指导其行为和沟通风格。Task 是一个具有清晰描述和期望输出的离散工作单元,分配给特定 Agent。Crew 是包含 Agent 和任务列表的内聚单元,它执行预定义的 Process。此过程决定工作流,通常是顺序的(一个任务的输出成为下一个任务的输入)或层级式的(类似管理者的 Agent 委派任务并在其他 Agent 之间协调工作流)。
与其他框架相比,CrewAI 占据了独特的位置。它摆脱了 LangGraph 的低级、显式状态管理和控制流,在后者中开发者需要连接每个节点和条件边。开发者不是构建状态机,而是设计团队章程。虽然 Google 的 ADK 为整个 Agent 生命周期提供了一个全面的、面向生产的平台,但 CrewAI 专门专注于 Agent 协作逻辑和模拟专家团队。
@crew
def crew(self) -> Crew:
"""Creates the research crew"""
return Crew(
agents=self.agents,
tasks=self.tasks,
process=Process.sequential,
verbose=True,
)此代码为一组 AI Agent 设置了顺序工作流,他们按特定顺序处理任务列表,启用详细日志以监控其进度。
其他 Agent 开发框架
Microsoft AutoGen:AutoGen 是一个以编排通过对话解决任务的多 Agent 为中心的框架。其架构使具有不同能力的 Agent 能够交互,允许复杂的问题分解和协作解决。AutoGen 的主要优势是其灵活的、对话驱动的方法,支持动态和复杂的多 Agent 交互。然而,这种对话范式可能导致不太可预测的执行路径,可能需要复杂的 Prompt Engineering 来确保任务高效收敛。
LlamaIndex:LlamaIndex 本质上是一个数据框架,旨在将大型语言模型与外部和私有数据源连接。它在创建复杂的数据摄取和检索管道方面表现出色,这是构建能够执行 RAG 的知识型 Agent 所必需的。虽然其数据索引和查询能力在创建具有上下文感知能力的 Agent 方面异常强大,但其原生工具在复杂的 Agentic 控制流和多 Agent 编排方面不如以 Agent 为首的框架发达。当核心技术挑战是数据检索和综合时,LlamaIndex 是最佳选择。
Haystack:Haystack 是一个开源框架,专为构建由语言模型驱动的可扩展、生产就绪的搜索系统而设计。其架构由模块化、可互操作的节点组成,形成用于文档检索、问答和摘要的管道。Haystack 的主要优势是其对大规模信息检索任务的性能和可扩展性的关注,使其适合企业级应用。一个潜在的权衡是,其为搜索管道优化的设计在实现高度动态和创意的 Agentic 行为时可能较为僵化。
MetaGPT:MetaGPT 通过基于一组预定义的标准操作程序(SOP)分配角色和任务来实现多 Agent 系统。此框架结构化 Agent 协作以模拟软件开发公司,Agent 扮演产品经理或工程师等角色来完成复杂任务。这种 SOP 驱动的方法产生高度结构化和连贯的输出,这在代码生成等专业领域是显著优势。该框架的主要限制是其高度专业化,使其在其核心设计之外的通用 Agentic 任务中适应性较差。
SuperAGI:SuperAGI 是一个开源框架,旨在为自主 Agent 提供完整的生命周期管理系统。它包括 Agent 配置、监控和图形界面等功能,旨在增强 Agent 执行的可靠性。关键好处是其对生产就绪性的关注,内置处理循环等常见故障模式的机制以及提供 Agent 性能的可观测性。一个潜在的缺点是其综合平台方法可能比更轻量级的、基于库的框架引入更多复杂性和开销。
Semantic Kernel:由微软开发的 Semantic Kernel 是一个 SDK,通过"插件"和"规划器"系统将大型语言模型与常规编程代码集成。它允许 LLM 调用原生函数并编排工作流,有效地将模型视为更大软件应用中的推理引擎。其主要优势是与现有企业代码库(特别是在 .NET 和 Python 环境中)的无缝集成。其插件和规划器架构的概念开销可能比更直接的 Agent 框架具有更陡峭的学习曲线。
Strands Agents:一个 AWS 的轻量级灵活 SDK,使用模型驱动的方法来构建和运行 AI Agent。它被设计为简单且可扩展,支持从基础对话助手到复杂的多 Agent 自主系统的各种场景。该框架是模型无关的,为各种 LLM 提供商提供广泛支持,并包含与 MCP 的原生集成以便轻松访问外部工具。其核心优势是其简单性和灵活性,具有易于上手且可定制的 Agent 循环。一个潜在的权衡是其轻量级设计意味着开发者可能需要构建更多的周边运营基础设施(如高级监控或生命周期管理系统),而这些在更全面的框架中可能是开箱即用的。
小结
Agentic 框架的格局提供了多样化的工具谱系,从用于定义 Agent 逻辑的低级库到用于编排多 Agent 协作的高级平台。在基础层面,LangChain 实现简单的线性工作流,而 LangGraph 引入有状态的循环图用于更复杂的推理。如 CrewAI 和 Google 的 ADK 等更高级框架将重点转移到编排具有预定义角色的 Agent 团队,而 LlamaIndex 等框架则专注于数据密集型应用。这种多样性为开发者提供了一个基于图的系统精细控制和更固执己见的平台简化开发之间的核心权衡。因此,选择合适的框架取决于应用程序是需要简单的序列、动态推理循环,还是管理的专家团队。最终,这个不断发展的生态系统通过选择项目所需的确切抽象层次来赋能开发者构建日益复杂的 AI 系统。
参考文献
- LangChain, https://www.langchain.com/
- LangGraph, https://www.langchain.com/langgraph
- Google's ADK, https://google.github.io/adk-docs/
- Crew.AI, https://docs.crewai.com/en/introduction
附录D - 使用 AgentSpace 构建 Agent
概述
AgentSpace 是一个旨在通过将人工智能集成到日常工作流程中来实现"Agent 驱动企业"的平台。其核心是在组织的整个数字足迹(包括文档、电子邮件和数据库)中提供统一的搜索能力。该系统利用先进的 AI 模型(如 Google 的 Gemini)来理解和综合来自这些多样化来源的信息。
该平台支持创建和部署可以执行复杂任务和自动化流程的专用 AI "Agent"。这些 Agent 不仅仅是聊天机器人;它们可以推理、规划和自主执行多步骤操作。例如,一个 Agent 可以研究一个主题,编制带引用的报告,甚至生成音频摘要。
为实现这一点,AgentSpace 构建了一个企业知识图谱,映射人员、文档和数据之间的关系。这使得 AI 能够理解上下文并提供更相关和个性化的结果。该平台还包括一个名为 Agent Designer 的无代码接口,用于创建自定义 Agent 而无需深厚的技术专业知识。
此外,AgentSpace 支持多 Agent 系统,不同的 AI Agent 可以通过被称为 Agent2Agent (A2A) Protocol 的开放协议进行通信和协作。这种互操作性允许更复杂和协调的工作流。安全性是一个基础组件,具有基于角色的访问控制和数据加密等功能,以保护敏感的企业信息。最终,AgentSpace 旨在通过将智能的、自主的系统直接嵌入到组织的运营结构中来提高生产力和决策能力。
如何使用 AgentSpace UI 构建 Agent
图 1 说明了如何通过从 Google Cloud Console 中选择 AI Applications 来访问 AgentSpace。

你的 Agent 可以连接到各种服务,包括 Calendar、Google Mail、Workaday、Jira、Outlook 和 Service Now(见图 2)。

Agent 然后可以利用其自己的 Prompt,从 Google 提供的预制作 Prompt 库中选择,如图 3 所示。

或者你可以创建自己的 Prompt,如图 4 所示,它将被你的 Agent 使用。

AgentSpace 提供许多高级功能,例如与数据存储集成以存储你自己的数据、与 Google Knowledge Graph 或你的私有 Knowledge Graph 集成、用于将你的 Agent 暴露在 Web 上的 Web 界面,以及用于监控使用情况的 Analytics 等等(见图 5)。

完成后,AgentSpace 聊天界面(图 6)将可访问。

小结
总之,AgentSpace 为在组织现有数字基础设施内开发和部署 AI Agent 提供了一个功能框架。系统的架构将复杂的后端流程(如自主推理和企业知识图谱映射)与 Agent 构建的图形用户界面连接起来。通过此界面,用户可以通过集成各种数据服务并通过 Prompt 定义其操作参数来配置 Agent,从而生成定制的、具有上下文感知能力的自动化系统。
这种方法抽象了底层的技术复杂性,使得无需深厚的编程专业知识即可构建专门的多 Agent 系统。主要目标是将自动化的分析和操作能力直接嵌入工作流程,从而提高流程效率并增强数据驱动的分析。如需实践指导,可以使用 Google Cloud Skills Boost 上的"Build a Gen AI Agent with Agentspace"实验等动手学习模块,它为技能获取提供了结构化的环境。
参考文献
- Create a no-code agent with Agent Designer, https://cloud.google.com/agentspace/agentspace-enterprise/docs/agent-designer
- Google Cloud Skills Boost, https://www.cloudskillsboost.google/
附录E - CLI 上的 AI Agent
简介
开发者的命令行长期以来是精确的、命令式命令的堡垒,正在经历深刻的变革。它正在从一个简单的 shell 演变为一个由新型工具驱动的智能、协作工作空间:AI Agent 命令行接口(CLI)。这些 Agent 超越了仅仅执行命令;它们理解自然语言,维护关于整个代码库的上下文,并可以执行复杂的多步骤任务,自动化开发生命周期的重要部分。
本指南深入探讨了这一新兴领域的四个主要参与者,探索它们独特的优势、理想用例和不同的理念,以帮助你确定哪个工具最适合你的工作流程。需要注意的是,许多为特定工具提供的示例用例通常也可以由其他 Agent 完成。这些工具之间的关键差异通常在于它们在给定任务上能够实现的结果质量、效率和细微差别。有专门的基准测试旨在衡量这些能力,将在以下部分讨论。
Claude CLI (Claude Code)
Anthropic 的 Claude CLI 被设计为一个具有对项目架构深入、整体理解的高级编码 Agent。其核心优势是其"Agentic"本质,允许它为复杂的、多步骤的任务创建代码库的心智模型。交互高度对话化,类似于配对编程会话,它在执行前解释其计划。这使其非常适合在涉及重大重构或实现具有广泛架构影响功能的大规模项目上工作的专业开发者。
示例用例:
- 大规模重构:你可以指示它:"我们当前的用户认证依赖 session cookie。重构整个代码库以使用无状态 JWT,更新登录/注销端点、中间件和前端 token 处理。"Claude 将读取所有相关文件并执行协调的更改。
- API 集成:在提供了新天气服务的 OpenAPI 规范后,你可以说:"集成这个新的天气 API。创建一个服务模块来处理 API 调用,添加一个新组件来显示天气,并更新主仪表板以包含它。"
- 文档生成:将其指向一个代码记录不佳的复杂模块,你可以要求:"分析 ./src/utils/data_processing.js 文件。为每个函数生成全面的 TSDoc 注释,解释其目的、参数和返回值。"
Claude CLI 作为一个专门的编码助手,具有用于核心开发任务的内置工具,包括文件摄取、代码结构分析和编辑生成。其与 Git 的深度集成促进了直接的分支和提交管理。Agent 的可扩展性由 Multi-tool Control Protocol (MCP) 协调,使用户能够定义和集成自定义工具。这允许与私有 API、数据库查询和执行项目特定脚本的交互。这种架构将开发者定位为 Agent 功能范围的仲裁者,有效地将 Claude 描述为由用户定义的工具增强的推理引擎。
Gemini CLI
Google 的 Gemini CLI 是一个为功能强大和易用性而设计的多功能开源 AI Agent。它凭借先进的 Gemini 2.5 Pro 模型、大规模上下文窗口和多模态能力(处理图像和文本)而脱颖而出。其开源性质、慷慨的免费层级以及"Reason and Act"循环使其成为一个透明、可控且出色的全能工具,面向从爱好者到企业开发者的广泛受众,特别是 Google Cloud 生态系统内的用户。
示例用例:
- 多模态开发:你提供设计文件中一个网页组件的截图并指示它:"编写 HTML 和 CSS 代码来构建一个看起来完全像这个的 React 组件。确保它是响应式的。"
- 云资源管理:使用其内置的 Google Cloud 集成,你可以命令:"找到生产项目中所有运行版本低于 1.28 的 GKE 集群,并生成 gcloud 命令逐一升级它们。"
- 企业工具集成(通过 MCP):一个开发者向 Gemini 提供了一个名为 get-employee-details 的自定义工具,连接到公司的内部 HR API。Prompt 是:"为我们新员工起草一份欢迎文档。首先使用 get-employee-details --id=E90210 工具获取他们的姓名和团队,然后用该信息填充 welcome_template.md。"
- 大规模重构:一个开发者需要重构一个大型 Java 代码库,以用新的结构化日志框架替换已弃用的日志库。他们可以使用 Gemini,Prompt 如:读取 'src/main/java' 目录中的所有 *.java 文件。对于每个文件,将所有 'org.apache.log4j' 导入及其 'Logger' 类替换为 'org.slf4j.Logger' 和 'LoggerFactory'。重写 logger 实例化和所有 .info()、.debug() 和 .error() 调用以使用新的带键值对的结构化格式。
Gemini CLI 配备了一套内置工具,使其能够与环境交互。这些包括文件系统操作工具(如读写)、用于运行命令的 shell 工具以及通过网页获取和搜索访问互联网的工具。对于更广泛的上下文,它使用专门的工具一次读取多个文件,以及一个记忆工具来为后续会话保存信息。这些功能建立在一个安全的基础之上:沙箱隔离模型的操作以防止风险,而 MCP 服务器作为桥梁,使 Gemini 能够安全地连接到你的本地环境或其他 API。
Aider
Aider 是一个开源 AI 编码助手,作为真正的配对程序员,直接在你的文件上工作并将更改提交到 Git。其定义特征是直接性;它应用编辑、运行测试进行验证,并自动提交每个成功的更改。作为模型无关的,它给予用户对成本和能力的完全控制。其以 Git 为中心的工作流使其非常适合重视效率、控制和对所有代码修改的透明、可审计跟踪的开发者。
示例用例:
- 测试驱动开发(TDD):一个开发者可以说:"为计算数字阶乘的函数创建一个失败的测试。"Aider 编写测试后它失败了,下一个 Prompt 是:"现在,编写代码使测试通过。"Aider 实现该函数并再次运行测试以确认。
- 精确 Bug 修复:给定一个 Bug 报告,你可以指示 Aider:"billing.py 中的 calculate_total 函数在闰年失败。将该文件添加到上下文中,修复 Bug,并针对现有测试套件验证你的修复。"
- 依赖更新:你可以指示它:"我们的项目使用了过时版本的 'requests' 库。请遍历所有 Python 文件,更新导入语句和任何已弃用的函数调用以兼容最新版本,然后更新 requirements.txt。"
GitHub Copilot CLI
GitHub Copilot CLI 将流行的 AI 配对程序员扩展到终端,其主要优势是与 GitHub 生态系统的原生深度集成。它理解 GitHub 中项目的上下文。其 Agent 能力允许它被分配一个 GitHub issue,处理修复,并提交 Pull Request 供人工审查。
示例用例:
- 自动化 Issue 解决:一个管理者将 Bug 工单(例如"Issue #123:修复分页中的差一错误")分配给 Copilot Agent。Agent 然后检出新分支、编写代码并提交引用该 issue 的 Pull Request,全部无需人工开发者干预。
- 仓库感知问答:团队中的新开发者可以问:"在这个仓库中,数据库连接逻辑在哪里定义的,它需要什么环境变量?"Copilot CLI 利用其对整个仓库的了解来提供带有文件路径的精确答案。
- Shell 命令助手:当不确定复杂的 shell 命令时,用户可以问:gh? 找到所有大于 50MB 的文件,压缩它们,并将它们放在一个存档文件夹中。Copilot 将生成执行任务所需的确切 shell 命令。
Terminal-Bench:CLI 中 AI Agent 的基准测试
Terminal-Bench 是一个新颖的评估框架,旨在评估 AI Agent 在命令行界面内执行复杂任务的熟练程度。终端被确定为 AI Agent 操作的理想环境,因为其基于文本的、沙箱化的特性。初始版本 Terminal-Bench-Core-v0 包含 80 个手动策划的任务,涵盖科学工作流和数据分析等领域。为确保公平比较,开发了 Terminus(一个极简 Agent)作为各种语言模型的标准化测试平台。该框架设计为可扩展的,允许通过容器化或直接连接集成各种 Agent。未来发展包括启用大规模并行评估和纳入已建立的基准测试。该项目鼓励开源贡献以扩展任务和协作增强框架。
小结
这些强大的 AI 命令行 Agent 的出现标志着软件开发的一个根本性转变,将终端转变为动态和协作的环境。如我们所见,没有单一的"最佳"工具;相反,一个充满活力的生态系统正在形成,每个 Agent 都提供专门的优势。理想的选择完全取决于开发者的需求:Claude 适用于复杂的架构任务,Gemini 适用于多功能和多模态问题解决,Aider 适用于以 Git 为中心和直接的代码编辑,GitHub Copilot 适用于与 GitHub 工作流的无缝集成。随着这些工具继续演进,熟练利用它们将成为一项基本技能,从根本上改变开发者构建、调试和管理软件的方式。
参考文献
- Anthropic. Claude. https://docs.anthropic.com/en/docs/claude-code/cli-reference
- Google Gemini CLI. https://github.com/google-gemini/gemini-cli
- Aider. https://aider.chat/
- GitHub Copilot CLI. https://docs.github.com/en/copilot/github-copilot-enterprise/copilot-cli
- Terminal Bench. https://www.tbench.ai/
附录G - Coding Agent
Vibe Coding:起点
"Vibe Coding" 已成为一种用于快速创新和创意探索的强大技术。这种实践涉及使用 LLM 生成初始草稿、概述复杂逻辑或构建快速原型,显著减少了初始摩擦。它对于克服"空白页"问题非常宝贵,使开发者能够快速从模糊概念过渡到切实的、可运行的代码。Vibe Coding 在探索不熟悉的 API 或测试新颖的架构模式时特别有效,因为它绕过了对完美实现的即时需求。生成的代码通常充当创意催化剂,为开发者提供批评、重构和扩展的基础。其主要优势在于加速软件生命周期的初始发现和构思阶段。然而,虽然 Vibe Coding 在头脑风暴方面表现出色,但开发健壮、可扩展和可维护的软件需要更结构化的方法,从纯粹的生成转向与专门的 Coding Agent 的协作伙伴关系。
Agent 作为团队成员
虽然最初的浪潮专注于原始代码生成——适合构思的"Vibe Code"——但行业现在正在转向一个用于生产工作的更集成、更强大的范式。最有效的开发团队不仅仅将任务委派给 Agent;他们通过一套复杂的 Coding Agent 来增强自己。这些 Agent 作为不知疲倦的、专门的团队成员,放大人类的创造力并显著提高团队的可扩展性和速度。
这种演进反映在行业领导者的声明中。2025 年初,Alphabet CEO Sundar Pichai 指出,在 Google,"超过 30% 的新代码现在由我们的 Gemini 模型辅助或生成,从根本上改变了我们的开发速度。"微软也做出了类似的声明。这种行业范围的转变表明,真正的前沿不是取代开发者,而是赋能他们。目标是一种增强的关系,人类指导架构愿景和创意问题解决,而 Agent 处理测试、文档和审查等专门的、可扩展的任务。
本章提出了一个基于核心理念组织人-Agent 团队的框架:人类开发者作为创意负责人和架构师,AI Agent 作为力量倍增器。该框架建立在三个基础原则之上:
-
人类主导的编排:开发者是团队负责人和项目架构师。他们始终在环中,编排工作流、设定高层目标并做出最终决策。Agent 是强大的,但它们是支持性的协作者。开发者指导哪个 Agent 参与,提供必要的上下文,最重要的是,对任何 Agent 生成的输出行使最终判断,确保其与项目的质量标准和长期愿景保持一致。
-
上下文至上:Agent 的性能完全取决于其上下文的质量和完整性。一个具有较差上下文的强大 LLM 是无用的。因此,我们的框架优先考虑精心策划的、人类主导的上下文管理方法。避免自动化的、黑盒的上下文检索。开发者负责为其 Agent 团队成员组装完美的"简报"。这包括:
- 完整的代码库:提供所有相关的源代码,使 Agent 理解现有的模式和逻辑。
- 外部知识:提供特定的文档、API 定义或设计文档。
- 人类简报:明确表达目标、需求、Pull Request 描述和风格指南。
-
直接模型访问:为了达到最先进的结果,Agent 必须由直接访问前沿模型(如 Gemini 2.5 PRO、Claude Opus 4、OpenAI、DeepSeek 等)驱动。使用较弱的模型或通过模糊或截断上下文的中间平台路由请求将降低性能。该框架建立在创建人类负责人与底层模型原始能力之间尽可能纯净的对话之上,确保每个 Agent 以其峰值潜力运行。
该框架被结构化为一个由专门的 Agent 组成的团队,每个 Agent 为开发生命周期中的核心功能而设计。人类开发者作为中央编排者,委派任务并整合结果。
核心组件
为了有效利用前沿大型语言模型,此框架为一组专门的 Agent 分配不同的开发角色。这些 Agent 不是独立的应用程序,而是通过精心设计的、特定角色的 Prompt 和上下文在 LLM 中调用的概念人设。这种方法确保模型的巨大能力精确地聚焦于当前任务,从编写初始代码到执行细致的、批判性的审查。
编排者:人类开发者
在这个协作框架中,人类开发者作为编排者,充当中央智能和 AI Agent 的最终权威。
- 角色:团队负责人、架构师和最终决策者。编排者定义任务、准备上下文并验证 Agent 完成的所有工作。
- 接口:开发者自己的终端、编辑器以及所选 Agent 的原生 Web UI。
上下文暂存区
作为任何成功 Agent 交互的基础,上下文暂存区是人类开发者精心准备完整且针对任务的简报的地方。
- 角色:每个任务的专用工作区,确保 Agent 接收完整且准确的简报。
- 实现:一个包含目标的 markdown 文件、代码文件和相关文档的临时目录(task-context/)。
专家 Agent
通过使用有针对性的 Prompt,我们可以构建一个专家 Agent 团队,每个都针对特定的开发任务定制。
-
Scaffolder Agent:实现者
- 目的:根据详细规范编写新代码、实现功能或创建样板代码。
- 调用 Prompt:"你是一位高级软件工程师。基于 01_BRIEF.md 中的需求和 02_CODE/ 中的现有模式,实现该功能..."
-
Test Engineer Agent:质量守护者
- 目的:为新代码或现有代码编写全面的单元测试、集成测试和端到端测试。
- 调用 Prompt:"你是一位质量保证工程师。对于 02_CODE/ 中提供的代码,使用 [测试框架,例如 pytest] 编写完整的单元测试套件。覆盖所有边缘情况并遵循项目的测试理念。"
-
Documenter Agent:记录者
- 目的:为函数、类、API 或整个代码库生成清晰、简洁的文档。
- 调用 Prompt:"你是一位技术撰稿人。为所提供代码中定义的 API 端点生成 markdown 文档。包括请求/响应示例并解释每个参数。"
-
Optimizer Agent:重构伙伴
- 目的:提出性能优化和代码重构建议以提高可读性、可维护性和效率。
- 调用 Prompt:"分析所提供的代码的性能瓶颈或可以重构以提高清晰度的区域。提出具体更改并解释为什么它们是一种改进。"
-
Process Agent:代码主管
- 批评:Agent 执行初始审查,识别潜在的 Bug、风格违规和逻辑缺陷,类似于静态分析工具。
- 反思:Agent 然后分析其自己的批评。它综合发现,优先考虑最关键的问题,忽略迂腐或低影响的建议,并为人类开发者提供高层次的、可操作的摘要。
- 调用 Prompt:"你是一位进行代码审查的首席工程师。首先,对更改进行详细的批评。其次,反思你的批评以提供最重要反馈的简洁、优先排序的摘要。"
最终,这种人类主导的模式在开发者的战略方向和 Agent 的战术执行之间创造了强大的协同效应。因此,开发者可以超越常规任务,将他们的专业知识集中在交付最大价值的创意和架构挑战上。
实践实施
设置清单
为了有效实施人-Agent 团队框架,推荐以下设置,专注于在提高效率的同时保持控制。
- 配置前沿模型的访问:至少两个领先大型语言模型(如 Gemini 2.5 Pro 和 Claude 4 Opus)的安全 API 密钥。这种双提供商方法允许进行比较分析并规避单平台限制或停机时间。这些凭证应像任何其他生产密钥一样安全地管理。
- 实现本地上下文编排器:使用轻量级 CLI 工具或本地 Agent 运行器来管理上下文,而非临时脚本。这些工具应允许你在项目根目录中定义一个简单的配置文件(如 context.toml),指定哪些文件、目录甚至 URL 应编译为 LLM Prompt 的单一负载。这确保你对模型每次请求看到的内容保持完全透明的控制。
- 建立版本控制的 Prompt 库:在项目的 Git 仓库中创建一个专用的 /prompts 目录。在其中,将每个专家 Agent 的调用 Prompt(如 reviewer.md、documenter.md、tester.md)存储为 markdown 文件。将 Prompt 视为代码使整个团队能够协作、改进和版本化随时间给 AI Agent 的指令。
- 使用 Git Hooks 集成 Agent 工作流:使用本地 Git hooks 自动化你的审查节奏。例如,可以配置一个 pre-commit hook,在暂存的更改上自动触发 Reviewer Agent。Agent 的批评-反思摘要可以直接在你的终端中呈现,在你最终确定提交之前提供即时反馈,并将质量保证步骤直接嵌入到你的开发流程中。
领导增强团队的原则
成功领导这个框架需要从个人贡献者进化为人-AI 团队的领导者,遵循以下原则:
- 保持架构所有权:你的角色是设定战略方向并拥有高层架构。你定义"什么"和"为什么",使用 Agent 团队来加速"如何"。你是设计的最终仲裁者,确保每个组件与项目的长期愿景和质量标准保持一致。
- 掌握简报的艺术:Agent 输出的质量是其输入质量的直接反映。通过为每个任务提供清晰、明确和全面的上下文来掌握简报的艺术。将你的 Prompt 不视为简单的命令,而是为新来的、高度能力的团队成员准备的完整简报包。
- 作为最终质量关卡:Agent 的输出始终是一个提案,而不是命令。将 Reviewer Agent 的反馈视为强大的信号,但你是最终的质量关卡。运用你的领域专业知识和项目特定知识来验证、挑战和批准所有更改,作为代码库完整性的最终守护者。
- 进行迭代对话:最佳结果来自对话,而非独白。如果 Agent 的初始输出不完美,不要丢弃它——改进它。提供纠正性反馈,添加澄清性上下文,并提示再次尝试。这种迭代对话至关重要,特别是与 Reviewer Agent,其"反思"输出被设计为协作讨论的起点,而非仅仅是一份最终报告。
小结
代码开发的未来已经到来,而且是增强的。孤独编码者的时代已经让位于一个新的范式,开发者领导专门的 AI Agent 团队。这种模式不会削弱人类角色;它通过自动化常规任务、扩大个人影响力和实现以前难以想象的开发速度来提升它。
通过将战术执行卸载给 Agent,开发者现在可以将认知能量投入到真正重要的事情上:战略创新、弹性架构设计以及构建令用户满意的产品所需的创意问题解决。基本关系已被重新定义;它不再是人与机器的竞争,而是人类智慧与 AI 作为单一、无缝集成的团队之间的伙伴关系。
参考文献
- AI is responsible for generating more than 30% of the code at Google, https://www.reddit.com/r/singularity/comments/1k7rxo0/ai_is_now_writing_well_over_30_of_the_code_at/
- AI is responsible for generating more than 30% of the code at Microsoft, https://www.businesstoday.in/tech-today/news/story/30-of-microsofts-code-is-now-ai-generated-says-ceo-satya-nadella-474167-2025-04-30
全书结论
在整本书中,我们从 Agentic AI 的基础概念走到了复杂自主系统的实践实现。我们从这样一个前提开始:构建智能 Agent 类似于在技术画布上创作一件复杂的艺术品——这不仅需要一个像大型语言模型这样的强大认知引擎,还需要一套健全的架构蓝图。这些蓝图(或 Agentic 模式)提供了将简单的、反应性模型转变为主动的、目标导向的、能够复杂推理和行动的实体所需的结构和可靠性。
本结论章节将综合我们探讨的核心原则。我们将首先回顾关键的 Agentic 模式,将它们分组为一个有凝聚力的框架以强调它们的集体重要性。接下来,我们将考察这些单独的模式如何组合成更复杂的系统,创造强大的协同效应。最后,我们将展望 Agent 开发的未来,探索将塑造下一代智能系统的新兴趋势和挑战。
关键 Agentic 原则回顾
本指南中详述的 21 个模式代表了 Agent 开发的综合工具包。虽然每个模式解决特定的设计挑战,但可以通过将它们分组为反映智能 Agent 核心能力的基础类别来集体理解。
-
核心执行和任务分解:在最基本的层面上,Agent 必须能够执行任务。Prompt Chaining、Routing、Parallelization 和 Planning 模式构成了 Agent 行动能力的基础。Prompt Chaining 提供了一种简单而强大的方法,将问题分解为离散步骤的线性序列,确保一个操作的输出逻辑性地指导下一个。当工作流需要更动态的行为时,Routing 引入条件逻辑,允许 Agent 根据输入的上下文选择最合适的路径或工具。Parallelization 通过启用独立子任务的并发执行来优化效率,而 Planning 模式将 Agent 从单纯的执行者提升为战略家,能够制定多步骤计划以实现高层目标。
-
与外部环境的交互:Agent 的效用通过其与超出其即时内部状态的世界交互的能力显著增强。Tool Use (Function Calling) 模式在此至关重要,提供了 Agent 利用外部 API、数据库和其他软件系统的机制。这将 Agent 的操作建立在真实世界的数据和能力之上。为了有效使用这些工具,Agent 通常需要从大量存储库中访问特定的相关信息。Knowledge Retrieval 模式(特别是 Retrieval-Augmented Generation (RAG))通过使 Agent 能够查询知识库并将该信息整合到其响应中来解决这一问题,使其更加准确和具有上下文感知能力。
-
状态、学习和自我改进:要使 Agent 执行的不仅是单轮任务,它必须具备维护上下文和随时间改进的能力。Memory Management 模式对于赋予 Agent 短期对话上下文和长期知识保留至关重要。超越简单的记忆,真正智能的 Agent 展现自我改进的能力。Reflection 和 Self-Correction 模式使 Agent 能够批评自己的输出,识别错误或不足,并迭代地改进其工作,从而产生更高质量的最终结果。Learning and Adaptation 模式进一步推进这一点,允许 Agent 的行为基于反馈和经验进行演进,使其随时间变得更加有效。
-
协作和通信:许多复杂问题最好通过协作来解决。Multi-Agent Collaboration 模式允许创建由多个专门 Agent(每个具有不同的角色和能力集)组成、共同实现共同目标的系统。这种分工使系统能够处理对于单个 Agent 来说难以应对的多方面问题。此类系统的有效性取决于清晰高效的通信,这一挑战由 Inter-Agent Communication (A2A) 和 Model Context Protocol (MCP) 模式解决,它们旨在标准化 Agent 和工具如何交换信息。
这些原则通过各自的模式应用时,为构建智能系统提供了健壮的框架。它们指导开发者创建不仅能执行复杂任务,而且结构化、可靠和适应性强的 Agent。
组合模式构建复杂系统
Agentic 设计的真正力量不是来自孤立地应用单一模式,而是来自将多个模式巧妙地组合以创建复杂的、多层次的系统。Agentic 画布很少由单一简单的工作流填充;相反,它变成一幅互连模式的织锦,协同工作以实现复杂目标。
考虑开发一个自主 AI 研究助手,这是一个需要规划、信息检索、分析和综合相结合的任务。这样的系统将是模式组合的首要例子:
- 初始规划:用户查询(如"分析量子计算对网络安全格局的影响")将首先由 Planner Agent 接收。该 Agent 利用 Planning 模式将高层请求分解为一个结构化的、多步骤研究计划。
- 使用 Tool Use 收集信息:Agent 将严重依赖 Tool Use 模式,每个步骤触发搜索或数据库 API 调用。
- 协作分析和写作:更健壮的架构将采用 Multi-Agent Collaboration,"Researcher" Agent 收集信息,"Writer" Agent 综合为连贯草稿。
- 迭代反思和改进:Reflection 模式通过"Critic" Agent 审查草稿,反馈给 Writer Agent 进行改进。
- 状态管理:Memory Management 系统在整个多步骤工作流中维护上下文。
在这个例子中,至少五个不同的 Agentic 模式交织在一起,将一组单独的能力转化为强大的、自主的系统。
展望未来
向更先进的 Agentic AI 迈进的旅程将以更大的自主性和推理驱动力为标志。未来将需要能够导航模糊性、执行抽象和因果推理的 Agent。这可能涉及与新型模型架构和神经符号方法的更紧密集成。我们将看到从 Human-in-the-Loop 系统到 Human-on-the-Loop 系统的转变。
Agent 生态系统的兴起和标准化将定义下一阶段。开放市场和平台将出现,MCP 和 A2A 原则将变得至关重要,导致行业标准。安全性、对齐和鲁棒性的挑战也将变得更加关键。
最终思考
在本指南中,我们将构建智能 Agent 描述为在技术画布上实践的艺术形式。这些 Agentic Design 模式是你的调色板和笔触。真正的技艺不在于掌握单一模式,而在于理解它们的相互作用。
Agentic AI 是技术中最令人兴奋和快速发展的领域之一。此处详述的概念和模式是一个起点——一个用于构建、实验和创新的坚实基础。未来不是我们仅仅是 AI 用户的未来,而是我们成为帮助解决世界最复杂问题的智能系统架构师的未来。画布在你面前,模式在你手中。现在,是时候构建了。
术语表
基本概念
Prompt:Prompt 是用户提供给 AI 模型以引出响应的输入,通常以问题、指令或陈述的形式。Prompt 的质量和结构严重影响模型的输出,使得 Prompt Engineering 成为有效使用 AI 的关键技能。
Context Window:上下文窗口是 AI 模型一次可以处理的 token 的最大数量,包括输入和其生成的输出。这个固定大小是一个关键限制,因为窗口外的信息会被忽略,而更大的窗口可以实现更复杂的对话和文档分析。
In-Context Learning:In-Context Learning 是 AI 直接从 Prompt 中提供的示例学习新任务的能力,无需任何重新训练。这个强大的功能允许单个通用模型即时适应无数特定任务。
Zero-Shot、One-Shot 和 Few-Shot Prompting:这些是 Prompting 技术,模型获得零个、一个或几个任务示例来指导其响应。提供更多示例通常有助于模型更好地理解用户意图并提高特定任务的准确性。
Multimodality:多模态是 AI 理解和处理跨多种数据类型(如文本、图像和音频)信息的能力。这允许更多样化和类似人类的交互,例如描述图像或回答口头问题。
Grounding:Grounding 是将模型的输出连接到可验证的真实世界信息源以确保事实准确性并减少幻觉的过程。这通常通过 RAG 等技术实现,使 AI 系统更加值得信赖。
核心 AI 模型架构
Transformers:Transformer 是大多数现代 LLM 的基础神经网络架构。其关键创新是自注意力机制,它高效地处理长文本序列并捕获词汇之间的复杂关系。
Recurrent Neural Network (RNN):循环神经网络是 Transformer 之前的基础架构。RNN 使用循环顺序处理信息,以保持先前输入的"记忆",这使其适用于文本和语音处理等任务。
Mixture of Experts (MoE):MoE 是一种高效的模型架构,其中"路由器"网络动态选择一小部分"专家"网络来处理任何给定输入。这允许模型拥有大量参数,同时保持计算成本可控。
Diffusion Models:扩散模型是擅长创建高质量图像的生成模型。它们通过向数据添加随机噪声然后训练模型仔细逆转该过程来工作,使它们能够从随机起点生成新数据。
Mamba:Mamba 是一种使用选择性状态空间模型(SSM)处理序列的最新 AI 架构,在处理非常长的上下文时具有高效率。其选择性机制允许它专注于相关信息同时过滤噪声,使其成为 Transformer 的潜在替代方案。
LLM 开发生命周期
强大语言模型的开发遵循一个独特的序列。它始于预训练,通过在大量通用互联网文本上训练来构建一个大规模基础模型,学习语言、推理和世界知识。接下来是微调,这是一个专业化阶段,在较小的、特定任务的数据集上进一步训练通用模型以使其能力适应特定目的。最后阶段是对齐,调整专业化模型的行为以确保其输出是有帮助的、无害的,并与人类价值观对齐。
预训练技术:预训练是模型从大量数据中学习一般知识的初始阶段。最常见的是 Causal Language Modeling (CLM),模型预测句子中的下一个词。另一种是 Masked Language Modeling (MLM),模型填充文本中被故意隐藏的词。其他重要方法包括 Denoising Objectives、Contrastive Learning 和 Next Sentence Prediction (NSP)。
微调技术:微调是使用较小的、专门的数据集将通用预训练模型适配到特定任务的过程。最常见的方法是 Supervised Fine-Tuning (SFT)。一个流行的变体是 Instruction Tuning。为了使此过程更高效,使用 Parameter-Efficient Fine-Tuning (PEFT) 方法,包括 LoRA (Low-Rank Adaptation) 及其内存优化版本 QLoRA。Retrieval-Augmented Generation (RAG) 通过在微调或推理阶段将模型连接到外部知识源来增强模型。
对齐与安全技术:对齐是确保 AI 模型的行为与人类价值观和期望对齐的过程。最突出的技术是 Reinforcement Learning from Human Feedback (RLHF)。更简单的替代方案包括 Direct Preference Optimization (DPO) 和 Kahneman-Tversky Optimization (KTO)。Guardrails 作为最终安全层,实时过滤输出并阻止有害操作。
增强 AI Agent 能力
Chain of Thought (CoT):此 Prompting 技术鼓励模型在给出最终答案之前逐步解释其推理过程。这种"大声思考"的过程通常会在复杂推理任务上产生更准确的结果。
Tree of Thoughts (ToT):Tree of Thoughts 是一个高级推理框架,Agent 同时探索多条推理路径。它允许 Agent 自我评估不同的思路并选择最有前途的一条来追求。
ReAct (Reason and Act):ReAct 是一个在循环中结合推理和行动的 Agent 框架。Agent 首先关于该做什么进行"思考",然后使用工具采取"行动",并使用观察结果来指导其下一个想法。
Planning:这是 Agent 将高层目标分解为一系列较小的、可管理的子任务的能力。
Deep Research:Deep Research 指 Agent 通过迭代搜索信息、综合发现和识别新问题来自主深入探索主题的能力。
Critique Model:Critique Model 是一个专门训练用于审查、评估和提供另一个 AI 模型输出的反馈的 AI 模型。
术语索引
本术语索引使用 Gemini Pro 2.5 生成。
A
- A/B Testing - 第3章:Parallelization
- Action Selection - 第20章:Prioritization
- Adaptation - 第9章:Learning and Adaptation
- Adaptive Task Allocation - 第16章:Resource-Aware Optimization
- Adaptive Tool Use & Selection - 第16章:Resource-Aware Optimization
- Agent - 什么使 AI 系统成为 Agent?
- Agent-Computer Interfaces (ACIs) - 附录B
- Agent-Driven Economy - 什么使 AI 系统成为 Agent?
- Agent as a Tool - 第7章:Multi-Agent Collaboration
- Agent Cards - 第15章:Inter-Agent Communication (A2A)
- Agent Development Kit (ADK) - 第2章:Routing、第3章:Parallelization、第4章:Reflection、第5章:Tool Use、第7章:Multi-Agent Collaboration、第8章:Memory Management、第12章:Exception Handling and Recovery、第13章:Human-in-the-Loop、第15章:Inter-Agent Communication (A2A)、第16章:Resource-Aware Optimization、第19章:Evaluation and Monitoring、附录C
- Agent Discovery - 第15章:Inter-Agent Communication (A2A)
- Agent Trajectories - 第19章:Evaluation and Monitoring
- Agentic Design Patterns - 引言
- Agentic RAG - 第14章:Knowledge Retrieval (RAG)
- Agentic Systems - 引言
- AI Co-scientist - 第21章:Exploration and Discovery
- Alignment - 术语表
- AlphaEvolve - 第9章:Learning and Adaptation
- Analogies - 附录A
- Anomaly Detection - 第19章:Evaluation and Monitoring
- Anthropic's Claude 4 Series - 附录B
- Anthropic's Computer Use - 附录B
- API Interaction - 第10章:Model Context Protocol (MCP)
- Artifacts - 第15章:Inter-Agent Communication (A2A)
- Asynchronous Polling - 第15章:Inter-Agent Communication (A2A)
- Audit Logs - 第15章:Inter-Agent Communication (A2A)
- Automated Metrics - 第19章:Evaluation and Monitoring
- Automatic Prompt Engineering (APE) - 附录A
- Autonomy - 引言
- A2A (Agent-to-Agent) - 第15章:Inter-Agent Communication (A2A)
B
- Behavioral Constraints - 第18章:Guardrails/Safety Patterns
- Browser Use - 附录B
C
- Callbacks - 第18章:Guardrails/Safety Patterns
- Causal Language Modeling (CLM) - 术语表
- Chain of Debates (CoD) - 第17章:Reasoning Techniques
- Chain-of-Thought (CoT) - 第17章:Reasoning Techniques、附录A
- Chatbots - 第8章:Memory Management
- ChatMessageHistory - 第8章:Memory Management
- Checkpoint and Rollback - 第18章:Guardrails/Safety Patterns
- Chunking - 第14章:Knowledge Retrieval (RAG)
- Clarity and Specificity - 附录A
- Client Agent - 第15章:Inter-Agent Communication (A2A)
- Code Generation - 第1章:Prompt Chaining、第4章:Reflection
- Code Prompting - 附录A
- CoD (Chain of Debates) - 第17章:Reasoning Techniques
- CoT (Chain of Thought) - 第17章:Reasoning Techniques、附录A
- Collaboration - 第7章:Multi-Agent Collaboration
- Compliance - 第19章:Evaluation and Monitoring
- Conciseness - 附录A
- Content Generation - 第1章:Prompt Chaining、第4章:Reflection
- Context Engineering - 第1章:Prompt Chaining
- Context Window - 术语表
- Contextual Pruning & Summarization - 第16章:Resource-Aware Optimization
- Contextual Prompting - 附录A
- Contractor Model - 第19章:Evaluation and Monitoring
- ConversationBufferMemory - 第8章:Memory Management
- Conversational Agents - 第1章:Prompt Chaining、第4章:Reflection
- Cost-Sensitive Exploration - 第16章:Resource-Aware Optimization
- CrewAI - 第3章:Parallelization、第5章:Tool Use、第6章:Planning、第7章:Multi-Agent Collaboration、第18章:Guardrails/Safety Patterns、附录C
- Critique Agent - 第16章:Resource-Aware Optimization
- Critique Model - 术语表
- Customer Support - 第13章:Human-in-the-Loop
D
- Data Extraction - 第1章:Prompt Chaining
- Data Labeling - 第13章:Human-in-the-Loop
- Database Integration - 第10章:Model Context Protocol (MCP)
- DatabaseSessionService - 第8章:Memory Management
- Debate and Consensus - 第7章:Multi-Agent Collaboration
- Decision Augmentation - 第13章:Human-in-the-Loop
- Decomposition - 附录A
- Deep Research - 第6章:Planning、第17章:Reasoning Techniques、术语表
- Delimiters - 附录A
- Denoising Objectives - 术语表
- Dependencies - 第20章:Prioritization
- Diffusion Models - 术语表
- Direct Preference Optimization (DPO) - 第9章:Learning and Adaptation
- Discoverability - 第10章:Model Context Protocol (MCP)
- Drift Detection - 第19章:Evaluation and Monitoring
- Dynamic Model Switching - 第16章:Resource-Aware Optimization
- Dynamic Re-prioritization - 第20章:Prioritization
E
- Embeddings - 第14章:Knowledge Retrieval (RAG)
- Embodiment - 什么使 AI 系统成为 Agent?
- Energy-Efficient Deployment - 第16章:Resource-Aware Optimization
- Episodic Memory - 第8章:Memory Management
- Error Detection - 第12章:Exception Handling and Recovery
- Error Handling - 第12章:Exception Handling and Recovery
- Escalation Policies - 第13章:Human-in-the-Loop
- Evaluation - 第19章:Evaluation and Monitoring
- Exception Handling - 第12章:Exception Handling and Recovery
- Expert Teams - 第7章:Multi-Agent Collaboration
- Exploration and Discovery - 第21章:Exploration and Discovery
- External Moderation APIs - 第18章:Guardrails/Safety Patterns
F
- Factored Cognition - 附录A
- FastMCP - 第10章:Model Context Protocol (MCP)
- Fault Tolerance - 第18章:Guardrails/Safety Patterns
- Few-Shot Learning - 第9章:Learning and Adaptation
- Few-Shot Prompting - 附录A
- Fine-tuning - 术语表
- Formalized Contract - 第19章:Evaluation and Monitoring
- Function Calling - 第5章:Tool Use、附录A
G
- Gemini Live - 附录B
- Gems - 附录A
- Generative Media Orchestration - 第10章:Model Context Protocol (MCP)
- Goal Setting - 第11章:Goal Setting and Monitoring
- GoD (Graph of Debates) - 第17章:Reasoning Techniques
- Google Agent Development Kit (ADK) - 第2章:Routing、第3章:Parallelization、第4章:Reflection、第5章:Tool Use、第7章:Multi-Agent Collaboration、第8章:Memory Management、第12章:Exception Handling and Recovery、第13章:Human-in-the-Loop、第15章:Inter-Agent Communication (A2A)、第16章:Resource-Aware Optimization、第19章:Evaluation and Monitoring、附录C
- Google Co-Scientist - 第21章:Exploration and Discovery
- Google DeepResearch - 第6章:Planning
- Google Project Mariner - 附录B
- Graceful Degradation - 第12章:Exception Handling and Recovery、第16章:Resource-Aware Optimization
- Graph of Debates (GoD) - 第17章:Reasoning Techniques
- Grounding - 术语表
- Guardrails - 第18章:Guardrails/Safety Patterns
H
- Haystack - 附录C
- Hierarchical Decomposition - 第19章:Evaluation and Monitoring
- Hierarchical Structures - 第7章:Multi-Agent Collaboration
- HITL (Human-in-the-Loop) - 第13章:Human-in-the-Loop
- Human-in-the-Loop (HITL) - 第13章:Human-in-the-Loop
- Human-on-the-loop - 第13章:Human-in-the-Loop
- Human Oversight - 第13章:Human-in-the-Loop、第18章:Guardrails/Safety Patterns
I
- In-Context Learning - 术语表
- InMemoryMemoryService - 第8章:Memory Management
- InMemorySessionService - 第8章:Memory Management
- Input Validation/Sanitization - 第18章:Guardrails/Safety Patterns
- Instructions Over Constraints - 附录A
- Inter-Agent Communication (A2A) - 第15章:Inter-Agent Communication (A2A)
- Intervention and Correction - 第13章:Human-in-the-Loop
- IoT Device Control - 第10章:Model Context Protocol (MCP)
- Iterative Prompting / Refinement - 附录A
J
- Jailbreaking - 第18章:Guardrails/Safety Patterns
K
- Kahneman-Tversky Optimization (KTO) - 术语表
- Knowledge Retrieval (RAG) - 第14章:Knowledge Retrieval (RAG)
L
- LangChain - 第1章:Prompt Chaining、第2章:Routing、第3章:Parallelization、第4章:Reflection、第5章:Tool Use、第8章:Memory Management、第20章:Prioritization、附录C
- LangGraph - 第1章:Prompt Chaining、第2章:Routing、第3章:Parallelization、第4章:Reflection、第5章:Tool Use、第8章:Memory Management、附录C
- Latency Monitoring - 第19章:Evaluation and Monitoring
- Learned Resource Allocation Policies - 第16章:Resource-Aware Optimization
- Learning and Adaptation - 第9章:Learning and Adaptation
- LLM-as-a-Judge - 第19章:Evaluation and Monitoring
- LlamaIndex - 附录C
- LoRA (Low-Rank Adaptation) - 术语表
- Low-Rank Adaptation (LoRA) - 术语表
M
- Mamba - 术语表
- Masked Language Modeling (MLM) - 术语表
- MASS (Multi-Agent System Search) - 第17章:Reasoning Techniques
- MCP (Model Context Protocol) - 第10章:Model Context Protocol (MCP)
- Memory Management - 第8章:Memory Management
- Memory-Based Learning - 第9章:Learning and Adaptation
- MetaGPT - 附录C
- Microsoft AutoGen - 附录C
- Mixture of Experts (MoE) - 术语表
- Model Context Protocol (MCP) - 第10章:Model Context Protocol (MCP)
- Modularity - 第18章:Guardrails/Safety Patterns
- Monitoring - 第11章:Goal Setting and Monitoring、第19章:Evaluation and Monitoring
- Multi-Agent Collaboration - 第7章:Multi-Agent Collaboration
- Multi-Agent System Search (MASS) - 第17章:Reasoning Techniques
- Multimodality - 术语表
- Multimodal Prompting - 附录A
N
- Negative Examples - 附录A
- Next Sentence Prediction (NSP) - 术语表
O
- Observability - 第18章:Guardrails/Safety Patterns
- One-Shot Prompting - 附录A
- Online Learning - 第9章:Learning and Adaptation
- OpenAI Deep Research API - 第6章:Planning
- OpenEvolve - 第9章:Learning and Adaptation
- OpenRouter - 第16章:Resource-Aware Optimization
- Output Filtering/Post-processing - 第18章:Guardrails/Safety Patterns
P
- PAL (Program-Aided Language Models) - 第17章:Reasoning Techniques
- Parallelization - 第3章:Parallelization
- Parallelization & Distributed Computing Awareness - 第16章:Resource-Aware Optimization
- Parameter-Efficient Fine-Tuning (PEFT) - 术语表
- PEFT (Parameter-Efficient Fine-Tuning) - 术语表
- Performance Tracking - 第19章:Evaluation and Monitoring
- Persona Pattern - 附录A
- Personalization - 什么使 AI 系统成为 Agent?
- Planning - 第6章:Planning、术语表
- Prioritization - 第20章:Prioritization
- Principle of Least Privilege - 第18章:Guardrails/Safety Patterns
- Proactive Resource Prediction - 第16章:Resource-Aware Optimization
- Procedural Memory - 第8章:Memory Management
- Program-Aided Language Models (PAL) - 第17章:Reasoning Techniques
- Project Astra - 附录B
- Prompt - 术语表
- Prompt Chaining - 第1章:Prompt Chaining
- Prompt Engineering - 附录A
- Proximal Policy Optimization (PPO) - 第9章:Learning and Adaptation
- Push Notifications - 第15章:Inter-Agent Communication (A2A)
Q
- QLoRA - 术语表
- Quality-Focused Iterative Execution - 第19章:Evaluation and Monitoring
R
- RAG (Retrieval-Augmented Generation) - 第8章:Memory Management、第14章:Knowledge Retrieval (RAG)、附录A
- ReAct (Reason and Act) - 第17章:Reasoning Techniques、附录A、术语表
- Reasoning - 第17章:Reasoning Techniques
- Reasoning-Based Information Extraction - 第10章:Model Context Protocol (MCP)
- Recovery - 第12章:Exception Handling and Recovery
- Recurrent Neural Network (RNN) - 术语表
- Reflection - 第4章:Reflection
- Reinforcement Learning - 第9章:Learning and Adaptation
- Reinforcement Learning from Human Feedback (RLHF) - 术语表
- Reinforcement Learning with Verifiable Rewards (RLVR) - 第17章:Reasoning Techniques
- Remote Agent - 第15章:Inter-Agent Communication (A2A)
- Request/Response (Polling) - 第15章:Inter-Agent Communication (A2A)
- Resource-Aware Optimization - 第16章:Resource-Aware Optimization
- Retrieval-Augmented Generation (RAG) - 第8章:Memory Management、第14章:Knowledge Retrieval (RAG)、附录A
- RLHF (Reinforcement Learning from Human Feedback) - 术语表
- RLVR (Reinforcement Learning with Verifiable Rewards) - 第17章:Reasoning Techniques
- RNN (Recurrent Neural Network) - 术语表
- Role Prompting - 附录A
- Router Agent - 第16章:Resource-Aware Optimization
- Routing - 第2章:Routing
S
- Safety - 第18章:Guardrails/Safety Patterns
- Scaling Inference Law - 第17章:Reasoning Techniques
- Scheduling - 第20章:Prioritization
- Self-Consistency - 附录A
- Self-Correction - 第4章:Reflection、第17章:Reasoning Techniques
- Self-Improving Coding Agent (SICA) - 第9章:Learning and Adaptation
- Self-Refinement - 第17章:Reasoning Techniques
- Semantic Kernel - 附录C
- Semantic Memory - 第8章:Memory Management
- Semantic Similarity - 第14章:Knowledge Retrieval (RAG)
- Separation of Concerns - 第18章:Guardrails/Safety Patterns
- Sequential Handoffs - 第7章:Multi-Agent Collaboration
- Server-Sent Events (SSE) - 第15章:Inter-Agent Communication (A2A)
- Session - 第8章:Memory Management
- SICA (Self-Improving Coding Agent) - 第9章:Learning and Adaptation
- SMART Goals - 第11章:Goal Setting and Monitoring
- State - 第8章:Memory Management
- State Rollback - 第12章:Exception Handling and Recovery
- Step-Back Prompting - 附录A
- Streaming Updates - 第15章:Inter-Agent Communication (A2A)
- Structured Logging - 第18章:Guardrails/Safety Patterns
- Structured Output - 第1章:Prompt Chaining、附录A
- SuperAGI - 附录C
- Supervised Fine-Tuning (SFT) - 术语表
- Supervised Learning - 第9章:Learning and Adaptation
- System Prompting - 附录A
T
- Task Evaluation - 第20章:Prioritization
- Text Similarity - 第14章:Knowledge Retrieval (RAG)
- Token Usage - 第19章:Evaluation and Monitoring
- Tool Use - 第5章:Tool Use、附录A
- Tool Use Restrictions - 第18章:Guardrails/Safety Patterns
- ToT (Tree of Thoughts) - 第17章:Reasoning Techniques、附录A、术语表
- Transformers - 术语表
- Tree of Thoughts (ToT) - 第17章:Reasoning Techniques、附录A、术语表
U
- Unsupervised Learning - 第9章:Learning and Adaptation
- User Persona - 附录A
V
- Validation - 第3章:Parallelization
- Vector Search - 第14章:Knowledge Retrieval (RAG)
- VertexAiRagMemoryService - 第8章:Memory Management
- VertexAiSessionService - 第8章:Memory Management
- Vibe Coding - 附录B
- Visual Perception - 附录B
W
- Webhooks - 第15章:Inter-Agent Communication (A2A)
Z
- Zero-Shot Learning - 第9章:Learning and Adaptation
- Zero-Shot Prompting - 附录A
用于生成索引的 Prompt
do you read
https://docs.google.com/document/d/1rsaK53T3Lg5KoGwvf8ukOUvbELRtH-V0LnOIFDxBryE/edit?tab=t.0
and all the related documents in the first page
Please extract all the titles for each chapter. and print them.
Then process the content of all the individual chapters, and create a detailed index used for publishing, a list of words or phrases ('headings') and associated pointers ('locators') to where useful material relating to that heading can be found in a document or collection of documents. I don't want a sample index. I want the full index, with 100 index termsGemini 2.5:推理步骤(摘要)
以下是 Gemini 2.5 生成索引时的关键推理步骤摘要:
- 开始索引创建:通过阅读 Google Doc 启动流程,提取章节标题。
- 定义索引提取过程:将请求分解为可操作步骤,使用 Workspaces 访问文档。
- 完善提取策略:规划多步骤方法,访问主文档和相关文档。
- 建立用户意图:确认需要章节标题列表和至少 100 个术语的全面索引。
- 考虑工具使用:使用正则表达式提取章节 URL,利用 Workspaces 检索内容。
- 编排章节检索:批量处理调用,防止速率限制问题。
- 提取标题和索引:从 31 个 Google Docs 获取内容,从文件名提取章节标题,构建字母顺序索引。
常见问题:Agentic Design Patterns
什么是"Agentic Design Pattern"? Agentic Design Pattern 是在构建智能自主系统(Agent)时遇到的常见问题的可重用、高层次解决方案。这些模式为设计 Agent 行为提供了结构化框架,就像软件设计模式对传统编程所做的那样。
本指南的主要目标是什么? 旨在为设计和构建 Agentic 系统提供实用的、动手的介绍,提供开发者可以用来创建能够可靠执行复杂目标导向行为的 Agent 的具体架构蓝图。
讨论了哪些关键的 Agentic 模式? 包括 Reflection、Planning、Tool Use、Multi-Agent Collaboration、Human-in-the-Loop 等。
为什么"Planning"是一个重要的模式? 因为它允许 Agent 处理无法用单一操作解决的多步骤复杂任务,保持一致的策略并处理错误。
什么是"ReAct"框架? ReAct 是一个集成推理和行动的流行框架,Agent 遵循 Thought-Action-Observation 循环直到完成任务。
什么是 Human-in-the-Loop (HITL)? 一种将人类监督集成到 Agent 工作流中的模式,Agent 在关键节点暂停以寻求反馈、批准或指导。
什么是 Multi-Agent Collaboration? 创建由多个专门 Agent 协同工作以实现共同目标的系统,通常涉及编排者 Agent 委派子任务。
什么是"Prompt 泄漏"? System Prompt 的部分内容无意中暴露在 Agent 的最终响应中,可通过分离推理和最终回答的 Prompt 来防止。
Agentic 系统的未来趋势是什么? 更自主的 Agent、高度专业化的 Agent 生态系统、更好的工具和平台。