Agent

本文整理自 Anthropic 的工程师 Barry 和 Mahesh 在 AI Engineer 做的关于 Skills 的分享：Don’t Build Agents, Build Skills Instead。 Anthropic 这帮工程师真的非常高产，继创造了 MCP 协议、Claude Code 编码 Agent 后，又创造了 Skills。他们的每一次创新都是源于实际工程开发中的真实需求，比如： MCP 协议的提出是因为解决模型与异构数据源（如本地文件、SaaS工具）连接的碎片化与标准化难题； Claude Code 创造是因为突破对话框的限制，让 AI 直接深入本地开发环境，实现从“阅读代码”到“执行构建”的自主闭环。 而 Skills 的创造是因为 将高频、复杂的任务逻辑封装为可复用的标准化模块，让 Agent 拥有长期的“肌肉记忆”，避免在重复任务中反复进行低效的 Prompt 引导。 以下是本次分享的核心内容，由我和 Gemini 3 Pro 共同整理而成。 代码就是这一层通用的接口 以前我们有个误区，觉得不同领域的 Agent 应该长得完全不一样。做金融的 Agent 和写代码的 Agent，肯定需要完全不同的工具和脚手架，甚至得为每个用例单独造一个 Agent。 但后来我们发布了 Claude Code（我们的第一个编程 Agent），搞着搞着发现：原来底下那个通用的 Agent 其实比我们想象的要强大得多。 代码不仅仅是一个使用场景，它其实是连接数字世界的通用接口。 想象一下生成一份财务报告：模型调用 API 拉数据、在文件系统里整理、用 Python 分析、最后输出格式化文件。这一整套流程，其实只需要极薄的一层脚手架（Bash 和文件系统）就能搞定。 智商 300 的天才 vs....

本文由 Anthropic 工程师 Justin Young 撰写：Effective harnesses for long-running agents。本文探讨了随着 AI Agent能力增强，在处理跨越数小时或数天的复杂任务（如软件工程）时面临的核心挑战：如何在多个有限的上下文窗口（context windows）之间保持工作的连贯性。作者指出，仅靠上下文压缩不足以解决问题，Agent 容易出现试图一次性完成任务（one-shotting）或过早宣布任务完成的失败模式。 为了解决上述问题，作者提出了一套基于 Claude Agent SDK 的双重解决方案： 初始化Agent （Initializer agent）：负责在首次运行时设置环境和规划任务。 编码Agent （Coding agent）：负责在后续会话中进行增量开发，并为下一次会话留下清晰的记录。 这一方案通过结构化的环境设置、详细的功能列表和严格的增量工作流，确保Agent 能够像人类工程师轮班一样，在没有先前记忆的情况下高效接手工作。 关键细节 核心挑战与失败模式 上下文限制：Agent 在离散的会话中工作，新会话开始时没有之前的记忆。 常见错误：在使用 Opus 4.5 等前沿模型时，若仅给出高层级提示，Agent 倾向于试图一次性构建整个应用，导致上下文耗尽、功能半途而废且缺乏文档；或者在仅完成部分功能后误判项目已完成。 解决方案的具体实施 环境初始化：Initializer agent 会创建关键的基础设施，包括： init.sh 脚本：用于启动开发环境。 claude-progress.txt 文件：记录Agent 的操作日志。 初始的 git 提交：建立版本控制基础。 功能列表（Feature List）：创建一个包含详细需求的 JSON 文件（例如 claude.ai 克隆项目包含 200 多个功能点）。选择 JSON 而非 Markdown 是为了防止模型意外覆盖文件结构。 增量工作流与状态管理 快速上手（Getting up to speed）：Coding agent 在每个会话开始时执行标准化步骤： 运行 pwd 确认工作目录。 读取 git 日志和进度文件以了解最近的工作。 读取功能列表，选择优先级最高且未完成的功能。 运行 init....

本文由 Anthropic 工程师 Ken Aizawa 所写：Writing effective tools for agents — with agents。其中介绍了一系列为 AI 代理（agents）构建高效工具的最佳实践和核心原则。为非确定性的 AI 代理设计工具与为传统的确定性软件系统编写函数或 API 有着根本性的不同，需要采取一种以代理为中心、由评估驱动的迭代开发方法。 关键细节 1. 构建和优化工具的流程 文章提出了一个与 AI 代理协作、以评估为驱动的迭代流程： 构建原型： 快速搭建工具原型，并利用 Claude Code 等 AI 代理辅助编写。可以通过本地 MCP (Model Context Protocol) 服务器或桌面扩展进行测试。 运行综合评估： 生成任务： 与 AI 代理协作，生成大量源于真实世界、具有足够复杂度的评估任务。强任务可能需要多次、甚至数十次工具调用。 运行评估： 通过直接调用 LLM API，在简单的代理循环中运行评估。建议让代理输出推理过程（CoT）以更好地理解其行为。 分析结果： 代理是发现问题的合作伙伴。通过分析其推理过程、原始交互记录以及调用指标（如冗余调用、错误率），可以发现工具的不足之处。 与代理协作改进： 将评估结果和记录直接输入给 Claude Code，让它分析问题并重构优化工具代码和描述，从而形成一个持续改进的闭环。 2. 编写高效工具的核心原则 选择合适的工具： 质量优于数量。避免简单地将每个 API 端点都包装成一个工具。 应构建少数几个针对高影响力工作流程的、经过深思熟虑的工具。例如，用一个 schedule_event 工具整合查找空闲时间和创建会议等多个步骤。 命名空间（Namespacing）： 当工具数量增多时，使用共同的前缀（如 asana_projects_search）对相关工具进行分组，可以帮助代理在不同工具间做出正确选择，避免混淆。 返回有意义的上下文： 工具返回的数据应优先考虑上下文相关性，而非技术细节。使用自然语言名称（name）代替晦涩的标识符（uuid）。 提供多种响应格式（如 concise 和 detailed），让代理可以根据需要选择信息的详细程度，从而控制上下文的消耗。 优化令牌（Token）效率：...

文本由 Anthropic 工程师由 Erik Schluntz 和 Barry Zhang 撰写：Building effective agents，文中探讨了构建高效 AI 代理（Agent）的最佳实践。 最成功的 AI 代理系统并非建立在复杂的框架之上，而是采用简单、可组合的模式。开发者应从最简单的方案（如优化单个 LLM 调用）开始，仅在确实需要时才引入更复杂的代理系统。诸如 LangGraph 等框架虽然可以简化初始开发，但也可能引入不必要的抽象层，使调试变得困难。建议开发者直接使用 LLM API，并确保理解所使用框架的底层逻辑。 代理系统的核心在于 LLM 与工具的交互。因此，投入精力设计一个清晰、易于使用的“代理-计算机接口” (ACI) 至关重要，这包括编写详尽的工具文档和进行充分的测试。文章提出了一系列从简单到复杂的构建模式，从基础的“增强型 LLM”到自主代理，开发者可以根据具体需求组合和定制这些模式。 关键细节 代理系统的类型 工作流 (Workflows)：通过预定义的代码路径来编排 LLM 和工具，具有较高的可预测性。 代理 (Agents)：LLM 能够动态地指导自己的流程和工具使用，更加灵活，适用于无法预知步骤的开放式问题。 核心构建模式 基础模块：增强型 LLM 这是所有代理系统的基础，即一个集成了检索、工具和记忆等增强功能的 LLM。 工作流：提示链 (Prompt Chaining) 将一个任务分解为一系列连续的步骤，每一步的 LLM 调用处理上一步的输出。适用于可清晰分解为固定子任务的场景。 工作流：路由 (Routing) 对输入进行分类，并将其引导至专门的下游任务或模型。例如，将简单的客户问题路由到成本更低的 Claude Haiku 4.5 模型。 工作流：并行化 (Parallelization) 让 LLM 同时处理一个任务的不同部分。具体可分为： 分片 (Sectioning)：将任务分解为独立的子任务并行运行。 投票 (Voting)：多次运行同一个任务以获得多样化的输出或更可靠的结果。 工作流：协调器-工作者 (Orchestrator-workers) 由一个中央 LLM（协调器）动态分解任务，并将其分配给多个 LLM（工作者）执行。适用于子任务无法预先确定的复杂场景，如编码。 工作流：评估器-优化器 (Evaluator-optimizer) 一个 LLM 负责生成响应，另一个 LLM 在循环中提供评估和反馈，以迭代方式改进输出质量。 自主代理 (Autonomous Agents) 适用场景：用于解决难以预测所需步骤的开放式问题。代理能够独立规划和执行，并通过与环境（如工具调用结果）的交互来评估进展。 注意事项：自主代理的成本更高，且存在错误累积的风险。因此，必须在沙盒环境中进行广泛测试，并设置适当的护栏（如最大迭代次数）。 实践应用领域 客户支持：代理可以通过集成工具来查询客户数据、处理退款等，将对话与实际操作相结合。 编码代理：代理可以根据需求描述自主修改多个代码文件，并通过自动化测试来验证解决方案的正确性，例如在 SWE-bench 基准测试中的应用。 原文：构建高效的智能体 发布于 2024年12月19日...

Anthropic 最近虽然口碑差，但人才密度还是高，继 MCP 之后他们又新推出来 Agent Skills，这个思路非常好，既给了 Agent 确定性，也给了其几乎无限的上下文，顺便帮你省了钱。也算是和 MCP 互补，一个连接外部系统，一个连接本地脚本和文档。 Agent Skills 的核心思想也很简单，就是通过提供一个由Skill、脚本和资源组成的结构化文件夹，将领域专家的知识打包在这些文件夹中，让 Agent 能够动态加载这些“Skills”。 Skill 的构成与工作原理大概是下面这样： 一个 Agent Skill 本质上就是一个包含 SKILL.md 文件的目录，该文件有一定的规范，比如必须以包含元数据（如name和description）的 YAML 前置内容开头等等。 Agent Skills 通过分层加载信息来高效管理上下文窗口： 第一层: Agent 在启动时仅加载所有已安装 Skill 的name 和 description，以便知道何时使用某个 Skill。 第二层: 当 Agent 认为某个 Skill 与当前任务相关时，它会读取该技能的 SKILL.md 文件的完整内容。 第三层及以上: 对于更复杂的任务，技能可以包含额外的辅助文件（如 reference.md 或脚本）。Agent 只在需要时才会读取这些文件，这个意思基本就是 Skills 可以包含几乎无限的上下文信息。 Skill 中可以包含预先编写好的固定的代码（如 Python 脚本）。Agent 可以像使用工具一样执行这些代码，以处理传统代码更擅长的确定性或高效率的任务，而不需要把代码本身加载到上下文中。 这个的好处很明显，把AI 生成的质量不稳定的代码变成稳定可控的代码，既大大缩小上下文，也节省了很多成本。 这篇文章中也举了两个 Skills 的典型应用例子： 通过AI 生成的代码来对列表进行排序，远比简单地运行一个排序算法要昂贵得多。除了效率问题，许多应用还需要只有代码才能提供的确定性可靠性。 PDF Skills 包含一个预先编写的 Python 脚本，用于读取 PDF 并提取所有表单字段。Claude 可以在不将脚本或 PDF 加载到上下文的情况下运行此脚本。而且由于代码是确定性的，这个工作流程是一致且可重复的。...

2025 年 7 月 17日，OpenAI 发布 ChatGPT Agent 功能，这是一个统一的 Agent 系统，它能利用自己的虚拟计算机和多种工具，处理从数据分析、网络研究到任务执行的复杂工作流程。该功能融合了 OpenAI 年初发布的两个 Agent 功能： Operator 的网页交互能力和 DeepResearch 的深度分析能力，并引入了新工具，使其能够在一个统一的界面中完成更广泛、更复杂的任务。 关键细节 核心功能与工作方式 任务执行能力： 用户可以要求 ChatGPT agent 执行诸如“分析竞争对手并创建幻灯片”、“规划并预订旅行”或“根据最新新闻为我简报即将到来的客户会议”等复杂任务。 工具套件： 它配备了一套综合工具，包括可视化浏览器、文本浏览器、终端和 API 访问权限，使其能够智能地选择最高效的方式来完成任务。 协同工作流程： ChatGPT agent 支持与用户进行迭代式协作。它会在需要时主动向用户请求更多信息，用户也可以随时介入以澄清指令或调整任务方向。 性能与基准测试 业界顶尖表现： 在多个衡量真实世界任务能力的基准测试中，ChatGPT agent 的表现均达到了新的业界顶尖（SOTA）水平，显著优于之前的模型，在某些任务上甚至超过了人类专家。 具体数据： 在 Humanity’s Last Exam（专家级问题测试）中，得分达到 41.6%。 在 DSBench（数据科学任务）上，准确率达到 89.9%，显著超越人类表现。 在 BrowseComp（网络浏览信息定位）中，准确率达到 68.9%，比 deep research 高出 17.4 个百分点。 风险与安全措施 应对新风险： 该功能引入了新的风险，如处理敏感数据和防范“提示词注入”（prompt injection）攻击。 多层安全防护： 用户确认： 在进行购买等有实际影响的操作前，必须获得用户的明确许可。 主动监督： 发送邮件等关键任务需要用户在“观察模式”（Watch Mode）下进行监督。 风险规避： 模型被训练以主动拒绝银行转账等高风险请求。 生物安全： 由于能力增强，该模型被置于最高级别的生物安全防护之下。 可用性与当前限制 推出范围： 该功能已开始向 Pro、Plus 和 Team 用户推出，Pro 用户每月有 400 条消息的使用额度。其他付费用户每月有 40 条消息，额外用量可通过灵活的基于积分的选项获得。 功能局限： ChatGPT agent 仍处于早期阶段，有时可能会出错。 幻灯片生成功能尚处于 beta 测试阶段，生成的内容在格式和美观度上可能较为基础。 原文：推出 ChatGPT 智能体：连接研究与行动 ChatGPT 现已具备思考和行动的能力，能主动从一系列智能体技能中进行选择，使用其自己的计算机为您完成任务。...

本文是 LangChain CEO Harrison Chase 在 OpenAI 发布了一份关于构建智能体 ( agents ) 的指南之后写的一篇文章，这篇文章主要用于指出 OpenAI 的智能体指南中的一些误导性观点，并给出了自己的一些看法。 定义区分： 工作流 (Workflows)：通过预定义代码路径编排 LLM 和工具，可预测性高。 代理 (Agents)：LLM 动态指导自身流程和工具使用，灵活性高。作者更倾向于 Anthropic 对此的精确技术定义。 代理失败原因：LLM 表现不佳通常源于上下文问题，如：系统提示不完整、用户输入模糊、工具描述/访问不当、未传入正确上下文、工具响应格式不佳等。 LangGraph 特点： 提供底层编排能力（节点 Nodes 和边 Edges）。 支持声明式（图结构）和命令式（节点/边内部逻辑）编程。 内置持久化层，支持容错、短期/长期记忆。 支持“人在回路”（human-in-the-loop）和“人监控回路”（human-on-the-loop）模式。 内置流式处理（streaming）支持。 与 LangSmith 集成，提供调试、评估和可观测性。 框架价值：除了代理抽象，好的框架还应提供：短期/长期记忆管理、人机交互支持、流式输出、调试/可观测性、容错机制等。这些价值对工作流和代理都适用。 对 OpenAI 指南的批评：作者认为 OpenAI 的指南： 错误地将 LangGraph 等声明式方法描绘为繁琐且不灵活。 混淆了“声明式 vs 命令式”与“工作流 vs 代理”以及“抽象”的概念。 声称 Agents SDK 等“非声明式”（实为抽象）方法更灵活、“代码优先”，作者认为这与事实相反。 未能抓住构建可靠代理系统的核心挑战（上下文控制）和框架应提供的核心价值（可靠的编排层）。 多代理系统：关键在于代理间的通信机制，工作流常用于组织多个代理的协作。 框架对比：作者提供了一个电子表格链接，用于比较 LangGraph, Agents SDK, CrewAI, AutoGen 等多种框架在不同维度（如编排 vs 抽象、特性支持）上的表现。 原文：如何看待 AI 智能体框架 总结：...

本文的核心观点是，真正的 生成式 AI LLM 智能体 (agents) 正在到来，它们与目前常见的基于工作流的系统有着本质的区别。这些新型智能体能够进行规划、记忆，并有效地执行多步骤、长期的任务。与预定义规则和提示的工作流系统不同，真正的 LLM 智能体能够动态地指导自身流程和工具使用，从而克服了传统方法在可扩展性和长期效能方面的局限性，并有望在各个领域带来颠覆性变革。文章强调，要实现真正的 LLM 智能体，需要采用 强化学习 (RL) 与推理 (Reasoning) 相结合的方法，并克服数据和计算方面的挑战，以推动这项技术的民主化发展。 LLM 智能体的定义与兴起： 文章指出，OpenAI 在 2025 年 1 月发布的 DeepResearch 以及 Claude Sonnet 3.7 是真正的 LLM 智能体的早期例证。Anthropic 将 LLM 智能体定义为能够动态控制自身流程和工具使用的系统，这与通过预定义代码路径编排 LLM 和工具的工作流系统形成对比。 工作流系统的局限性： 文章批评了当前许多 “智能体” 系统，如 Manus AI，实际上是工作流系统，它们在规划、记忆和长期行动方面存在根本性缺陷，例如无法有效规划搜索策略、难以维持超过 5-10 分钟的任务、以及长期行动中容易累积错误。 “苦涩的教训” (Bitter Lesson)： 文章引用了 Richard Sutton 的 “苦涩的教训”，指出在 AI 智能体中硬编码知识和规则虽然短期内有效，但长期来看会阻碍进步。真正的突破来自于扩展计算规模，并基于搜索和学习的方法。这表明，依赖预定义提示和规则的工作流系统注定会遇到瓶颈。 RL + Reasoning 是制胜之道： 文章强调，真正的 LLM 智能体需要通过 强化学习 (RL) 进行训练，并结合推理能力。训练过程涉及生成草稿、评估结果 (通过验证器 verifiers) 以及迭代优化。DeepSeek 的 GRPO 算法和 vllm 技术被认为是实现高效 RL 训练的关键。 数据和计算的挑战与解决方案： 训练 LLM 智能体，特别是对于复杂任务如搜索，需要大量的行动序列数据。由于缺乏公开的 agentic 数据，文章提出了通过模拟 (emulation) 和合成数据生成来解决数据瓶颈的思路。例如，可以创建网络搜索的模拟环境，并利用 Common Crawl 等数据集进行训练。 LLM 智能体的应用前景： 文章展望了 LLM 智能体在搜索之外的应用，例如网络工程 (自动生成设备配置、分析网络拓扑) 和金融领域 (数据标准转换)。这些应用场景都超越了传统工作流系统的能力，需要智能体具备自主规划和动态决策的能力。 技术民主化的必要性： 文章最后指出，目前 LLM 智能体技术主要掌握在少数大型实验室手中，为了促进技术发展和应用普及，需要推动 LLM 智能体训练和部署的民主化，例如开放验证器、 GRPO 训练样本以及复杂的合成管线和模拟器。 原文：真正的 LLM Agents 即将到来 实际的大语言模型 AI 智能体 (LLM Agent) 即将到来。它们将被训练 现在“智能体”这个词随处可见。然而，在大语言模型 (LLM) 驱动的智能体研究领域，一项最重要的研究进展却几乎没有引起人们的注意。...

在过去的一年里，我们与数十个团队合作，构建了跨行业的大语言模型 (LLM) 智能体。始终如一地，最成功的实施并没有使用复杂的框架或专门的库。相反，他们是用简单的、可组合的模式构建的。 在这篇文章中，我们分享了我们从与客户合作和自己构建智能体中学到的经验，并为开发人员提供了关于构建有效智能体的实用建议。 什么是智能体？“智能体” 可以通过几种方式定义。一些客户将智能体定义为在较长时间内独立运行的完全自主的系统，使用各种工具来完成复杂的任务。其他人使用该术语来描述遵循预定义工作流程的更具规范性的实现。在 Anthropic，我们将所有这些变体归类为智能体系统，但在工作流程和智能体之间进行了重要的架构区分： 工作流程是通过预定义的代码路径协调大语言模型和工具的系统。另一方面，智能体是大型语言模型动态地指导其自身流程和工具使用的系统，保持对其如何完成任务的控制。下面，我们将详细探讨这两种类型的智能体系统。在附录 1 (“实践中的智能体”) 中，我们描述了客户发现使用这些类型的系统具有特殊价值的两个领域。 何时 (以及何时不) 使用智能体当使用大语言模型构建应用程序时，我们建议找到尽可能简单的解决方案，并且仅在需要时增加复杂性。这可能意味着根本不构建智能体系统。智能体系统通常以延迟和成本换取更好的任务性能，您应该考虑何时这种权衡是有意义的。 当需要更高的复杂性时，工作流程为定义明确的任务提供可预测性和一致性，而当需要大规模的灵活性和模型驱动的决策时，智能体是更好的选择。然而，对于许多应用程序来说，通过检索和上下文示例优化单个大语言模型调用通常就足够了。 何时以及如何使用框架有许多框架可以使智能体系统更容易实现，包括： 来自 LangChain 的 LangGraph；Amazon Bedrock 的 AI 智能体 (AI Agent) 框架；Rivet，一个拖放式 GUI 大语言模型工作流程构建器；以及Vellum，另一个用于构建和测试复杂工作流程的 GUI 工具。这些框架通过简化标准的底层任务 (如调用大语言模型、定义和解析工具以及将调用链接在一起) 使入门变得容易。但是，它们通常会创建额外的抽象层，这可能会掩盖底层的提示和响应，从而使调试变得更加困难。当更简单的设置就足够时，它们也可能使添加复杂性变得很有诱惑力。 我们建议开发人员从直接使用大语言模型 API 开始：许多模式可以用几行代码实现。如果您确实使用了框架，请确保您了解底层的代码。对底层原理的错误假设是客户错误的常见来源。 请参阅我们的 cookbook 以获取一些示例实现。 构建模块、工作流程和智能体在本节中，我们将探讨我们在生产中看到的智能体系统的常见模式。我们将从我们的基础构建模块——增强型大语言模型——开始，并逐步增加复杂性，从简单的组合工作流程到自主智能体。 构建模块：增强型大语言模型智能体系统的基本构建模块是通过检索、工具和记忆等增强功能增强的大语言模型。我们目前的模型可以积极地使用这些功能——生成他们自己的搜索查询，选择合适的工具，并确定要保留哪些信息。 我们建议关注实现的两个关键方面：根据您的特定用例定制这些功能，并确保它们为您的 LLM 提供简单、完善的文档界面。虽然有很多方法可以实现这些增强功能，但一种方法是通过我们最近发布的 模型上下文协议 (Model Context Protocol)，该协议允许开发人员通过简单的 客户端实现 与不断增长的第三方工具生态系统集成。 在本帖的剩余部分，我们将假设每个大语言模型调用都可以访问这些增强的功能。 工作流程：提示链提示链将任务分解为一系列步骤，其中每个大语言模型调用处理前一个调用的输出。您可以在任何中间步骤中添加程序化检查 (请参阅下图中的“gate”) 以确保过程仍在轨道上。 何时使用此工作流程： 此工作流程非常适合可以轻松干净地分解为固定子任务的情况。主要目标是通过使每个大语言模型调用成为更简单的任务来权衡延迟以获得更高的准确性。 提示链有用的示例： 生成营销文案，然后将其翻译成不同的语言。编写文档大纲，检查大纲是否符合某些标准，然后根据大纲编写文档。工作流程：路由路由对输入进行分类并将其定向到专门的后续任务。此工作流程允许关注点分离，并构建更专业的提示。如果没有此工作流程，针对一种输入进行优化可能会损害其他输入的性能。 何时使用此工作流程： 路由适用于以下复杂任务：存在最好单独处理的不同类别，并且可以通过大语言模型或更传统的分类模型/算法准确处理分类。 路由有用的示例： 将不同类型的客户服务查询 (一般问题、退款请求、技术支持) 定向到不同的下游流程、提示和工具。将简单/常见的问题路由到较小的模型 (如 Claude 3.5 Haiku)，将困难/不常见的问题路由到功能更强大的模型 (如 Claude 3....

反思是一种用于提高代理和类似 AI 系统质量与成功率的提示策略。本文概述了如何使用 LangGraph 构建 3 种反思技术，包括 Reflexion 和语言代理树搜索的实现。 关键链接 简单反思： （Python）反思： （Python）语言智能体树搜索： （Python）Youtube反思是一种提示策略，用于提升智能体和类似 AI 系统的质量和成功率。它通过提示大语言模型（LLM）反思和批评其过去的行为，有时还会结合外部信息，如工具观察。 人们常提到“系统1”和“系统2”思维，系统1是反应迅速或本能的，而系统2则更为有条理和反思性。正确应用反思，可以帮助 LLM 系统摆脱纯粹的系统1思维模式，表现出更接近系统2的行为。 反思需要时间！本文中的方法都用了一些额外的计算换取更好的输出质量。虽然这可能不适合低延迟应用，但对于知识密集型任务，响应质量比速度更重要，确实值得这样做。 以下是三个示例： 基本反思 链接： （Python， Youtube） 这个简单示例由两个 LLM 调用组成：一个生成器和一个反思器。生成器尝试直接响应用户请求，反思器则扮演老师角色，对初始响应提供建设性的批评。 循环进行固定次数后，返回最终生成的输出。 简单反思循环 我们可以在 LangGraph 中定义以下循环： from langgraph.graph import MessageGraph builder = MessageGraph() builder.add_node("generate", generation_node) builder.add_node("reflect", reflection_node) builder.set_entry_point("generate") def should_continue(state: List[BaseMessage]): if len(state) > 6: return END return "reflect" builder.add_conditional_edges("generate", should_continue) builder.add_edge("reflect", "generate") graph = builder.compile() MessageGraph 表示一个有状态图，其中“状态”只是一个消息列表。每次调用生成器或反思节点时，它会将一条消息添加到状态的末尾。最终结果由生成器节点返回。 这种简单的反思方式有时可以通过让 LLM 多次尝试改进输出，并让反思节点在批评输出时扮演不同角色，从而提高性能。 然而，由于反思步骤不依赖于任何外部过程，最终结果可能不会显著优于原始结果。我们来探索一些可以改善这一情况的其他技术。 反思 链接：（Python， Youtube）...