如何构建有效的AI Agents：从复杂到简约——深度解读Claude实践总结《Building effective agents》(下)

本文链接：https://blog.youkuaiyun.com/GYN_enyaer/article/details/144896245

在前文中，我们深入探讨了Anthropic团队在AI代理系统设计中的一个重要发现：

简约性往往优于复杂性。

这个观点不仅挑战了行业常规认知，更为我们提供了一个全新的系统设计视角。

今天，让我们继续探索这份研究报告中的其他实践经验，特别是在AI Agents的具体实践层面。

如何在保持系统简约的同时确保其效能？

如何在实际应用中平衡自主性与可控性？

这些问题不仅关系到技术实现，更涉及到整个AI系统的设计哲学。

在这个快速发展的AI时代，我们常常被各种新技术和框架所吸引，却可能忽视了最基本的工程智慧。

正如数学和物理学中最基础的定律往往以最简洁的方程呈现，优秀的AI系统设计同样应该追求"大道至简"的境界。

让我们继续深入Anthropic团队的研究发现，看看他们如何将这种简约理念付诸实践。

在这里插入图片描述

五、构建模块、工作流和代理

代理系统的基本构建模块是经过增强的LLM，它具备检索、工具使用和记忆等功能。

我们当前的模型可以主动使用这些能力 —— 生成自己的搜索查询、选择合适的工具，并决定保留哪些信息。
对于实现，我们建议重点关注两个方面：

将这些功能针对性地适配您的具体用例，并确保为LLM提供简单、文档完备的接口。

虽然实现这些增强功能的方式有很多，

但其中一种方法是通过我们最近发布的模型上下文协议（Model Context Protocol），

它允许开发者通过简单的客户端实现来集成不断增长的第三方工具生态系统。

在探索完AI代理系统设计的基本原则后，Anthropic团队为我们揭示了一个渐进式的系统构建方法。

这种方法从最基础的构建块开始，通过不同的工作流模式组合，最终达到复杂的自主代理系统。

让我们先深入理解这个构建体系的基石——增强型LLM。

这不是一个简单的语言模型，而是一个经过精心增强的系统，集成了检索、工具使用和记忆等核心能力。

有趣的是，现代LLM已经能够主动利用这些能力，比如自主生成搜索查询、选择合适的工具，并决定需要保留哪些信息。

在这里插入图片描述

在实现层面，Anthropic特别强调两个关键点：

一是要根据具体应用场景定制这些增强能力，
二是要确保为LLM提供清晰、文档完备的接口。

这种设计思路体现了工程实践中"易用性"与"可靠性"的平衡。

比如说，如果我们在开发一个代码分析助手，那么增强型LLM不仅需要理解代码，还需要能够有效使用版本控制工具、代码分析工具等。

这些工具接口的设计必须既要足够简单清晰，让LLM能够准确理解和使用，又要保持足够的灵活性以适应不同的使用场景。

增强型LLM：代理系统的基石

在我们深入探讨工作流和代理系统之前，必须先理解其核心基础——增强型LLM（Large Language Model）。

在当前的AI系统设计中，增强型LLM(Large Language Model)已经成为构建智能代理系统的核心基石。

这种设计理念超越了传统的"单纯语言模型"思维，转而追求一种更全面的智能体系。

什么是增强型LLM？从本质上看，它是一个集成了检索、工具调用和记忆等多重能力的综合系统。

增强型LLM不同于普通的语言模型，它集成了三个关键能力：

检索（Retrieval）、工具使用（Tools）和记忆（Memory）。

想象一下，这就像是给予了大语言模型一套完整的"感知-思考-行动"能力：

通过检索获取信息（感知），通过推理处理信息（思考），通过工具使用来实现目标（行动）。

这种设计让AI系统不再局限于简单的文本生成，而是能够与现实世界进行更深层次的互动。

Anthropic团队在实践中发现，现代LLM已经展现出令人惊喜的能力

——它们能够主动生成搜索查询、自主选择合适的工具、判断需要保留的关键信息。

这种主动性的出现，标志着AI系统正在向真正的"智能助手"方向发展。

在这里插入图片描述

Anthropic团队的研究表明，一个优秀的AI代理系统往往建立在经过精心设计的增强型LLM之上。

它们可以自主生成搜索查询，选择最适合当前任务的工具，并判断哪些信息值得保留。

让我想起了斯坦福大学研究的一个发现：

工具的威力不在于其复杂程度，而在于使用者能否准确理解并恰当运用它。

同样的道理，构建增强型LLM时，我们需要关注两个核心问题：

1. 如何让这些增强能力真正服务于特定场景
2. 以及如何确保LLM能够轻松地理解和使用这些能力。

Anthropic最近发布的Model Context Protocol就是一个很好的例子。

这个协议允许开发者通过简单的客户端实现来集成各种第三方工具。

在这里插入图片描述

这种增强型LLM的设计思路，让我想起了Unix操作系统的设计哲学：

提供一组简单而强大的工具，通过灵活的组合来解决复杂的问题。

正如物理学中夸克和电子这样的基本粒子通过精妙的组合构成了浩瀚宇宙中的一切物质，

增强型LLM的这些基础能力也能在其相互作用与组合中，绽放出令人惊叹的智能效果。

在下一部分，我们将探讨如何基于这个强大的基础构建块，设计出更复杂的工作流模式。

但请记住，无论系统变得多么复杂，增强型LLM始终是其中最重要的基石。

一座大厦能够屹立不倒，关键在于它的地基是否扎实。

工作流模式的艺术

提示链工作流：任务的优雅分解

接下来让我们探索工作流模式中的第一个重要形态：提示链工作流（Prompt Chaining）。

提示链将任务分解为一系列步骤，每个LLM调用都会处理前一个调用的输出。

您可以在任何中间步骤添加程序化检查（参见下图中的"gate"），以确保整个流程仍在正轨上。

工作流的使用时机：这种工作流最适合那些可以轻松、清晰地分解为固定子任务的情况。

主要目标是通过让每个LLM调用处理更简单的任务来用延迟换取更高的准确性。

提示链的实用示例：

• 生成营销文案，然后将其翻译成其他语言
• 撰写文档大纲，检查大纲是否符合特定标准，然后基于大纲撰写文档

在这里插入图片描述

提示链工作流将复杂任务分解为连续的步骤，每个LLM调用都基于前一步的输出进行处理。

关键在于，开发者可以在任意中间步骤添加程序化的检查点，确保流程始终在正确的轨道上。

这种工作流特别适合那些可以清晰分解为固定子任务的场景。

比如将营销文案生成和多语言翻译组合在一起，或是先生成文档大纲，验证其符合要求后再展开完整内容。

在这里插入图片描述

它的主要优势在于用轻微的延迟换取更高的准确性——通过让每个LLM调用专注于更简单的任务来实现。

这种设计反映了软件工程中的单一职责原则：每个组件只负责一个明确的任务。

在实践中，这种模式不仅提高了系统的可靠性，还大大简化了调试和优化的过程。

接下来探讨的路由工作流展示了另一种优雅的任务处理方式。

路由工作流：智能分流的艺术

这是另一种精妙的设计模式。

路由会对输入进行分类，并将其引导至专门的后续任务。

这种工作流允许关注点分离，并构建更专门化的提示。

如果没有这种工作流，为某一类型输入优化可能会影响到其他输入的性能表现。

使用时机：路由适用于那些有明显不同类别、需要分开处理的复杂任务，且这些类别可以通过LLM或传统的分类模型/算法进行准确分类。

路由的实用示例：

• 将不同类型的客服查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具
• 将简单/常见问题路由给较小的模型（如Claude 3.5 Haiku），将困难/特殊问题路由给更强大的模型（如Claude 3.5 Sonnet），以优化成本和速度

在这里插入图片描述

路由工作流的核心思想是对输入进行智能分类，然后将其导向专门的处理流程。

这种设计允许我们为不同类型的任务优化独立的提示和工具，避免了一个通用解决方案可能带来的性能损失。

实际应用中，这种模式特别适合处理客户服务场景。

比如，一个查询可能是技术支持请求、退款申请或一般咨询，通过路由系统，每种类型的请求都能得到最专业的处理。

在这里插入图片描述

更智能的做法是根据任务复杂度将查询分配给不同能力的模型，如将简单任务交给Claude Haiku处理，复杂任务交给Claude Sonnet处理，从而实现性能和成本的最优平衡。

这种分而治之的方法让我想起了微服务架构的设计理念：通过服务的专业化来提高系统的整体性能和可维护性。

在AI系统中，这种专业化同样带来了显著的效果提升。

并行化工作流：效率与准确的平衡

这种设计模式有两个关键变体：任务分段和投票机制。

LLM有时可以同时处理任务，并通过程序化方式汇总其输出。这种并行化工作流主要有两种关键变体：

• 分段：将任务拆分为并行运行的独立子任务
• 投票：多次运行相同任务以获得多样化的输出

使用时机：并行化在以下情况下特别有效：
• 一是可以将子任务并行化以提高速度
• 二是需要多个视角或尝试来获得更高置信度的结果。
• 对于涉及多个考虑因素的复杂任务，当每个考虑因素由单独的LLM调用处理时，LLM通常表现更好，因为这允许对每个具体方面进行专注处理。

在这里插入图片描述

在任务分段模式中，系统将复杂任务拆分为可以并行处理的独立子任务。

例如，在代码安全审查中，一个LLM检查业务逻辑，另一个专注于安全漏洞，第三个关注性能优化。

这种并行处理不仅提高了效率，还能实现更专注和深入的分析。

在这里插入图片描述

投票机制则采用多个LLM同时处理相同任务，通过整合多个视角来提高结果的可靠性。

这在内容审核等需要高准确度的场景特别有用，通过设置不同的投票阈值来平衡准确率和召回率。

编排者（协调者）- 执行者工作流：动态任务分配

在编排者（协调者）- 执行者工作流中，一个中央LLM动态地分解任务，将它们分配给执行者LLM，并综合它们的结果。
使用时机：
这种工作流非常适合那些无法预测所需子任务的复杂任务（例如，在编程中，需要修改的文件数量和每个文件中的修改性质可能都取决于具体任务）。
虽然在结构上与并行化类似，但关键区别在于其灵活性 —— 子任务不是预先定义的，而是由编排者根据具体输入来确定。
编排者-执行者工作流的实用示例：
• 需要对多个文件进行复杂修改的编程产品
• 涉及从多个来源收集和分析可能相关信息的搜索任务

在这里插入图片描述

编排者（协调者）- 执行者工作流的独特之处在于其动态任务分解能力。

中央编排者（协调者）LLM根据具体任务动态规划子任务，并将它们分配给专门的执行者LLM。

这种架构特别适合需要复杂协调的场景，如多文件代码修改或跨领域的分析任务。

在实际应用中，这种模式在复杂的软件开发任务中表现出色。

在这里插入图片描述

例如，当需要修改多个相关文件时，协调者可以分析依赖关系，规划修改顺序，并将具体修改任务分配给专门的执行者。

与简单的并行处理不同，这种模式能够处理任务间的复杂依赖关系。

评估者-优化者工作流：迭代提升的智慧

这种模式通过引入反馈循环来不断提升输出质量。

在评估者-优化者工作流中，一个LLM调用生成响应，而另一个在循环中提供评估和反馈。

使用时机：

当我们有明确的评估标准，且迭代优化能带来可衡量的价值时，这种工作流特别有效。

判断是否适合使用这种工作流有两个标志：

• 首先，当人类明确表达反馈时，LLM的响应能够明显改善；
• 其次，LLM能够提供这样的反馈。这类似于人类作者在创作精良文档时可能经历的迭代写作过程。
评估者-优化者工作流的实用示例：
• 文学翻译，其中译者LLM最初可能无法捕捉到的细微差别可以通过评估者LLM的有用批评来改进。
• 需要多轮搜索和分析才能收集全面信息的复杂搜索任务，其中评估者决定是否需要进行更多搜索。

在这里插入图片描述

这种工作流模式特别适用于需要高质量输出的场景，如文学翻译或复杂搜索任务。

在实践中，评估者LLM会根据预设标准对生成的内容进行评估，提供具体改进建议。

例如，在翻译任务中，评估者可能会指出原文的细微含义是否被准确传达，或是文化背景是否得到恰当处理。

这个过程类似于人类写作中的编辑流程：通过多轮审阅和修改来提升作品质量。

在这里插入图片描述

系统会在达到预设质量标准或完成指定迭代次数时停止优化过程。

这种模式的关键在于评估标准的设定和反馈的质量。

好的评估标准应该具体、可衡量，而反馈则需要既有建设性又足够具体，能指导生成器进行有效改进。

六、自主代理：走向真正的AI智能

6.1 自主代理的本质与实现

接下来是很多人关注的热点——自主代理（Autonomous Agents）。

随着LLM在关键能力上日趋成熟 —— 理解复杂输入、进行推理和规划、可靠地使用工具以及从错误中恢复，代理系统正在生产环境中逐渐兴起。
代理通过接收用户的指令或与用户进行交互对话来开始工作。
一旦任务明确，代理就会独立规划和运行，必要时会向用户寻求更多信息或判断。
在执行过程中，代理需要在每个步骤都从环境中获取"基准事实"（如工具调用结果或代码执行情况）来评估其进展。

在这里插入图片描述

这是AI代理系统中最复杂的形态。

自主代理是随着LLM核心能力的成熟而出现的高级形态：理解复杂输入、推理规划、可靠使用工具、错误恢复。

它们通过与环境的持续交互获取"基础事实"，在执行过程中可以暂停等待人类反馈或处理阻碍。

典型应用包括：

SWE-bench任务解决，涉及多文件代码修改
计算机使用任务，代理直接操作计算机完成任务

关键设计原则：

保持设计简单性
确保规划步骤透明
精心设计代理-计算机接口

6.2 自主代理的实现细节和最佳实践

自主代理系统实现的关键在于设计合理的控制流程和干预机制。

在这里插入图片描述

如图所示，整个执行过程包含多个关键节点：

任务理解和规划：代理需要准确理解任务目标，制定执行计划
控制点设置：在关键节点（C1-C3）设置检查点，用于验证执行进度和结果
工具调用：通过清晰的接口文档和严格的测试确保工具使用的可靠性
人工干预：预设明确的干预条件和机制，在必要时暂停执行等待人类反馈

与框架驱动的方法不同，这种实现更注重底层控制的直接性和透明性。

让我们看看自主代理的代码实现示例。

class AutonomousAgent:
    def __init__(self, llm, tools, max_iterations=10):
        self.llm = llm
        self.tools = tools
        self.max_iterations = max_iterations
        self.execution_history = []
        
    async def execute_task(self, task_description):
        """执行给定任务"""
        plan = await self.create_plan(task_description)
        
        for i in range(self.max_iterations):
            # 检查点1: 任务理解和计划验证
            if not self.validate_plan(plan):
                await self.request_human_feedback("计划验证失败")
                plan = await self.revise_plan(task_description)
            
            # 执行当前步骤
            step_result = await self.execute_step(plan.current_step)
            self.execution_history.append(step_result)
            
            # 检查点2: 执行结果验证
            if not self.validate_step_result(step_result):
                await self.handle_error(step_result)
                continue
                
            if self.is_task_complete(plan):
                return self.compile_final_result()
                
        return {"status": "max_iterations_reached", "history": self.execution_history}
    
    async def create_plan(self, task_description):
        """使用LLM创建执行计划"""
        prompt = self.create_planning_prompt(task_description)
        response = await self.llm.generate(prompt)
        return self.parse_plan(response)
    
    async def execute_step(self, step):
        """执行单个步骤"""
        tool = self.select_tool(step.tool_name)
        try:
            result = await tool.execute(step.parameters)
            return {"status": "success", "result": result}
        except Exception as e:
            return {"status": "error", "error": str(e)}
    
    async def handle_error(self, error_result):
        """错误处理逻辑"""
        if self.can_auto_resolve(error_result):
            await self.auto_resolve_error(error_result)
        else:
            await self.request_human_feedback(error_result)
    
    def validate_step_result(self, result):
        """验证步骤执行结果"""
        validation_prompt = self.create_validation_prompt(result)
        validation_result = self.llm.generate(validation_prompt)
        return self.parse_validation_result(validation_result)
    
    async def request_human_feedback(self, context):
        """请求人类反馈"""
        feedback_request = self.format_feedback_request(context)
        return await self.human_interface.get_feedback(feedback_request)

这个实现展示了自主代理的一些核心组件：

任务规划和验证
执行步骤的循环控制
错误处理机制
人类反馈集成

在构建自主代理系统时，代码结构反映了人类决策的基本思维过程。

就像我们在解决复杂问题时会制定计划、执行操作、评估结果并根据需要调整策略，这个代理系统也遵循着相似的模式。

代码的设计体现了一种优雅的平衡：既要让代理拥有足够的自主性来处理复杂任务，又要确保其行为始终在可控范围内。

通过设置迭代上限，我们避免了代理陷入无休止的循环，就像给一个人设定任务期限一样。

在执行过程中，系统会在关键节点进行自我检查。

这些检查点就像是项目中的里程碑，帮助我们及时发现和纠正问题。

当遇到无法自行解决的情况时，代理会寻求人类的帮助，这种设计反映了人机协作的理想状态。

错误处理机制也非常人性化，系统会先尝试自行解决问题，就像一个经验丰富的工程师会先试着独立处理遇到的困难。

只有在确实需要时，才会请求外部协助。

同时，所有的执行历史都被完整记录，这对于后期分析和改进系统至关重要。

合理使用自主代理的时机

使用时机：
代理适用于难以或无法预测所需步骤数量的开放性问题，以及无法硬编码固定路径的场景。
LLM可能需要运行多个回合，因此您必须对其决策能力有一定程度的信任。代理的自主性使其非常适合在可信环境中扩展任务。
代理的自主特性意味着更高的成本，以及错误累积的可能性。
我们建议在沙盒环境中进行广泛测试，并配备适当的安全防护措施。

在这里插入图片描述

自主代理最适合处理那些具有高度不确定性的复杂任务。

比如多文件代码重构，代理需要理解代码结构、确定修改范围，并在修改过程中持续验证系统完整性。

又如复杂的数据分析任务，需要根据阶段性发现来调整分析策略。

然而，使用自主代理也意味着更高的计算成本和更长的执行时间。

因此，最重要的是在系统设计初期就建立完善的安全机制和测试环境。

在实践中，我们应该从最简单的解决方案开始，只在确实需要时才考虑引入自主代理。

实践案例分析：代码编写与计算机使用

Anthropic 列举了2个实践案例，我们主要分析第2个案例

“我们的“计算机使用”参考实现，Claude 使用计算机来完成任务。”

在这里插入图片描述
这张图展示了代码编辑 Agent 系统的工作流程，我们可以看到整个过程分为两个主要循环：

第一个循环（Until tasks clear）:

用户提交查询后，系统通过接口与LLM交互
LLM通过澄清和优化来确保理解用户意图
Interface发送具体上下文给LLM

第二个循环（Until tests pass）:

LLM搜索相关文件
环境返回文件路径
LLM编写代码并获取执行状态
运行测试并根据结果进行迭代

在这里插入图片描述

这种精心设计的双层循环架构体现了系统的智能与稳健。

通过在任务理解和执行层面分别建立反馈循环，系统能够确保每个环节的准确性。

就像一个经验丰富的工程师，在动手之前会反复确认需求，在执行过程中也会不断验证结果。

持续的反馈机制让系统具备了自我纠正的能力，当发现偏差时能够及时调整。

这种设计特别注重人机协作的自然性，用户可以在任何阶段介入并提供指导，就像与一个细心的助手合作。

通过将复杂任务分解为连续的小步骤，系统能够在每个阶段都确保正确性，避免错误的累积效应。

正是这种周密的架构设计，让Claude能够像一个可靠的专业助手一样，稳妥地完成各种复杂的计算机操作任务。

这不仅提高了执行效率，更重要的是确保了任务完成的质量与可靠性。

七、构建之道：从模式到实践

这些构建模块并非强制性的规范。它们是开发者可以根据不同用例来塑造和组合的常见模式。
与任何LLM功能一样，成功的关键在于衡量性能并迭代实现。
需要重申的是：只有在确实能够改善结果的情况下，才考虑增加复杂性。

这段内容实际上揭示了构建AI系统的一个核心设计理念。

这里强调了一个重要观点：以上的工作流模式和构建模块并不是教条式的规则，而是可以灵活运用的工具。

就像在厨房里，厨师会根据不同的菜品选择和组合不同的烹饪方法，开发者也需要根据具体的应用场景来选择和组合应用这些模式。

在当前AI快速发展的背景下，报告对"复杂性"的思考尤其深刻。

我们经常看到开发者陷入一个误区：过度追求复杂的技术方案，仿佛系统越复杂就越先进。

在这里插入图片描述

然而报告提醒我们，增加复杂性必须有明确的目的性，只有当增加复杂性能带来明显的性能提升时，才应该这么做。

它应该服务于性能的提升，而不是为了复杂而复杂。真正的成功来自于对系统性能的准确衡量和持续迭代优化。

技术模式就像工具箱中的工具，关键在于如何根据实际需求选择合适的工具组合。

我们要找到那个最佳平衡点，在这个点上，系统的复杂度刚好满足业务需求，而不会过度工程化。

最终的目标不是构建出最复杂的系统，而是打造一个"恰到好处"的解决方案。

这种追求简约但不简单的设计思维，在当前不断追求更大规模计算集群和模型参数的AI领域显得尤为珍贵。

简单来说，这段话传达了这样一个信息：模式是工具而不是规则，要根据实际需求灵活运用，同时始终记住："够用就好"的原则。

八、总结与展望

在LLM领域取得成功并不在于构建最复杂的系统，而在于构建最适合您需求的系统。
从简单的提示开始，通过全面的评估来优化它们，只有在更简单的解决方案不足以满足需求时，才添加多步骤的代理系统。
在实现代理时，我们遵循三个核心原则：
• 保持代理设计的简单性
• 通过明确展示代理的规划步骤来确保透明度
•> 通过全面的工具文档和测试来精心设计代理-计算机接口（ACI）
框架可以帮助您快速入门，但当转向生产环境时，不要犹豫于减少抽象层并使用基本组件构建。
通过遵循这些原则，您可以创建既强大又可靠、可维护，并能获得用户信任的代理系统。

回归本质：简约性的胜利

在当前AI技术快速迭代的时代，这份报告给我们带来了一个清醒的声音：回归本质。

成功并不在于堆砌最尖端复杂的技术，而是要找到最适合需求的解决方案。

这种思维方式让我想起了著名的"奥卡姆剃刀"原则：如无必要，勿增实体。 在LLM领域，这个原则再次展现。

报告建议我们从最简单的prompt开始，通过系统性的评估来逐步优化。

这种渐进式的方法不仅能帮助我们更好地理解问题本质，也能避免过度工程化带来的资源浪费。

正如报告中强调的简洁性原则，简单并不意味着能力的缺失，而是背后对问题本质的深刻理解。

未来发展：AI代理系统的新篇章

在这里插入图片描述

报告提出了构建Agent时应该遵循的三个核心原则：

首先是保持设计的简洁性。 这呼应了之前的讨论，简洁不等于简单，而是要做到精准而高效。
其次是重视透明性，要明确展示Agent的规划步骤。 这一点特别重要，因为它直接关系到系统的可理解性和可调试性。在实践中，我经常看到一些系统出现问题时很难定位原因，往往就是因为缺乏这种透明性。
第三是精心设计人机交互接口（ACI），并做好文档和测试工作。 这让我想起了人机交互（HCI）领域的经验，良好的接口设计和完整的文档对于系统的可用性和可维护性至关重要。

报告最后提到了框架的使用问题。框架确实能帮助快速起步，但在迈向生产环境时，不要犹豫于减少抽象层次，使用基础组件来构建。

这个建议非常实用，因为过多的抽象层可能会带来不必要的额外的复杂性和性能开销。

通过遵循这些原则，我们能够构建出既强大又可靠、可维护、可信赖的Agent系统。

感谢作者 Erik Schluntz 和 Barry Zhang 基于 Anthropic 的实践经验提出这些见解，为整个行业提供了宝贵的参考。