【Agent】Building Effective Agents：构建有效的AI Agent系统：从理论到实践

原创已于 2025-12-03 18:16:12 修改 · 936 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #大数据

于 2025-12-03 18:15:52 首次发布

智能体-Agent 专栏收录该内容

1 篇文章

订阅专栏

文章目录

本文基于Anthropic公司工程团队发布的《Building Effective Agents》一文，结合与各行业团队合作构建大型语言模型（LLM）智能体的实践经验，为开发者提供构建高效智能体系统的实用指南。

引言

在人工智能快速发展的今天，构建高效的智能体（Agent）系统已成为众多开发者的关注焦点。然而，如何选择合适的架构模式、何时使用框架、如何平衡复杂性与性能，这些问题往往困扰着开发者。Anthropic公司通过大量实践总结出了一套行之有效的方法论，本文将对这套方法论进行深入解读。

适用对象：

正在构建或计划构建LLM应用的开发者
需要理解智能体系统架构的技术决策者
希望优化现有智能体系统的工程师

内容一览

本文核心内容包括：

智能体系统的定义与分类：理解工作流（Workflow）与智能体（Agent）的本质区别
何时使用智能体：明确使用智能体的决策标准，避免过度设计
框架选择策略：理解何时使用框架，何时直接使用API
构建模块详解：增强型LLM的实现要点
工作流模式：提示链（Prompt Chaining）和树搜索（Tree Search）的应用场景
自主智能体：动态决策系统的构建方法

学习路线建议

初学者路径：

先理解智能体系统的定义与分类
掌握"何时使用智能体"的决策标准
学习增强型LLM的构建方法
实践提示链模式

进阶路径：

深入理解框架选择的权衡
掌握树搜索模式
构建自主智能体系统
优化系统性能与成本

实践路径：

从最简单的单次LLM调用开始
逐步增加检索和上下文示例
仅在确实需要时引入智能体系统
持续评估复杂性与性能的平衡

一、智能体系统的定义与分类

[!NOTE]
📝 关键点总结：智能体系统分为工作流和智能体两类，核心区别在于控制方式。

核心概念：

工作流（Workflow）：预定义代码路径编排LLM和工具
智能体（Agent）：LLM动态指导自身流程和工具使用

决策标准：根据任务是否需要动态决策来选择架构类型

核心结论：智能体系统本质上是LLM与工具的编排方式，分为预定义和动态决策两类

智能体系统并非单一概念，不同团队对其定义存在差异。一些团队将其视为完全自主的系统，能够在长时间内独立运行，使用各种工具完成复杂任务；另一些团队则将其定义为遵循预定义工作流程的系统。Anthropic将这些变体统称为"智能体系统"，并在架构上区分了两类：

怎么解决？

（1）工作流（Workflow）模式

核心观点：工作流通过预定义的代码路径编排LLM和工具，适合任务流程相对固定的场景。

首先，工作流的控制权在开发者手中。

开发者预先定义好任务执行的步骤和顺序
LLM按照预定义的路径调用工具和处理数据
每个步骤的执行逻辑都是可预测和可调试的

其次，工作流适合任务可以清晰分解的场景。

任务可以分解为固定的子任务序列
每个子任务的处理方式相对明确
不需要根据中间结果动态调整执行路径

（2）智能体（Agent）模式

核心观点：智能体由LLM动态指导自身流程和工具使用，适合需要灵活性和模型驱动决策的场景。

首先，智能体的控制权在LLM手中。

LLM根据当前状态和任务目标自主决定下一步行动
LLM可以选择使用哪些工具，以及如何使用
执行路径会根据中间结果动态调整

其次，智能体适合复杂且不确定的任务场景。

任务难以预先分解为固定步骤
需要根据执行过程中的反馈调整策略
任务空间较大，需要探索多种可能的解决方案

效果评估：两类模式各有优势，选择取决于任务特性

工作流模式：

优点：执行可预测、易于调试、延迟可控、成本相对较低
缺点：灵活性有限、难以处理意外情况
适用场景：任务流程相对固定、需要可预测性的生产环境

智能体模式：

优点：高度灵活、能处理复杂任务、适应性强
缺点：执行不可预测、调试困难、延迟和成本较高
适用场景：任务复杂且不确定、需要模型驱动决策的场景

实际应用示例：

示例1：客服机器人工作流

用户输入 → 意图识别（LLM调用1） → 分类到预定义流程 → 
知识库检索 → 生成回复（LLM调用2） → 返回用户

示例2：研究助手智能体

研究主题 → LLM分析 → 自主决定搜索策略 → 
动态选择工具（搜索、计算、分析） → 根据结果调整方向 → 
持续迭代直到满足研究目标

二、何时使用智能体

[!NOTE]
📝 关键点总结：优先选择最简单的解决方案，仅在确实需要时增加复杂性。

核心原则：

先尝试单次LLM调用 + 检索 + 上下文示例
智能体系统以延迟和成本换取性能
需要权衡这种取舍是否合理

决策标准：任务是否真的需要动态决策能力

核心结论：智能体系统不是万能的，大多数应用可能根本不需要构建智能体系统

在使用LLM构建应用程序时，开发者往往倾向于构建复杂的智能体系统，认为这样能获得更好的性能。然而，Anthropic的实践经验表明，最成功的应用往往采用最简单的解决方案。智能体系统通常会以延迟和成本为代价，换取更好的任务性能，因此需要权衡这种取舍何时是合理的。

怎么解决？

（1）优先尝试简单方案

核心观点：大多数任务可以通过单次LLM调用、检索和上下文示例解决，无需构建智能体系统。

首先，简单方案往往已经足够。

单次LLM调用配合精心设计的提示词可以解决大部分问题
通过检索增强生成（RAG）可以提供必要的上下文信息
在提示词中包含少量示例（Few-shot Learning）可以引导模型行为

其次，简单方案具有明显优势。

延迟低：单次调用避免了多次往返
成本低：减少了API调用次数
可预测：输出结果更容易控制和调试
易维护：代码简单，逻辑清晰

（2）评估是否需要智能体系统

核心观点：仅在任务确实需要动态决策能力时，才考虑构建智能体系统。

首先，需要评估任务的复杂性。

任务是否可以分解为固定的步骤序列？
如果任务流程相对固定，工作流模式可能更合适
如果任务需要根据中间结果动态调整，才考虑智能体模式

其次，需要权衡性能与成本。

智能体系统带来的性能提升是否值得额外的延迟和成本？
用户是否能够接受更长的响应时间？
预算是否允许更高的API调用成本？

（3）渐进式增加复杂性

核心观点：从简单方案开始，逐步增加复杂性，避免过度设计。

首先，先实现最小可行产品（MVP）。

使用单次LLM调用实现核心功能
验证方案是否满足基本需求
收集用户反馈和性能数据

其次，根据实际需求逐步优化。

如果发现需要多步骤处理，考虑提示链模式
如果发现需要动态决策，再引入智能体模式
始终以实际需求为导向，而非技术炫技

效果评估：简单优先策略能够显著降低开发成本和维护难度

简单方案的优势：

开发效率高：代码量少，实现快速
调试容易：逻辑清晰，问题定位简单
成本可控：API调用次数少，费用低
用户体验好：响应速度快，等待时间短

智能体系统的适用场景：

复杂任务：需要多步骤、多工具协作的复杂任务
动态环境：任务环境变化频繁，需要实时调整策略
探索性任务：需要在多个可能路径中寻找最优解
长期运行：需要长时间运行并持续调整的系统

实际应用示例：

示例1：简单问答系统（不需要智能体）

# 单次LLM调用 + RAG
def answer_question(question):
    # 1. 检索相关文档
    context = retrieve_relevant_docs(question)
    
    # 2. 单次LLM调用生成答案
    prompt = f"基于以下上下文回答问题：\n{context}\n\n问题：{question}"
    answer = llm.generate(prompt)
    
    return answer

示例2：复杂研究任务（需要智能体）

# 需要动态决策的智能体
def research_agent(topic):
    # LLM自主决定研究步骤
    while not research_complete:
        # LLM分析当前状态
        analysis = llm.analyze_current_state()
        
        # LLM决定下一步行动
        action = llm.decide_next_action(analysis)
        
        # 执行行动（可能是搜索、计算、分析等）
        result = execute_action(action)
        
        # 更新状态
        update_state(result)

三、是否使用框架

[!NOTE]
📝 关键点总结：框架简化开发但增加抽象层，建议先直接使用API，理解底层后再考虑框架。

核心原则：

许多模式可以用几行代码实现
框架可能掩盖底层细节，导致调试困难
框架可能诱使开发者增加不必要的复杂性

决策标准：是否理解框架的底层实现，是否真的需要框架提供的功能

核心结论：框架并非必需，直接使用LLM API往往更灵活且易于理解

市面上有许多框架可以简化智能体系统的实现，例如Claude Agent SDK、Amazon Bedrock的AI Agent框架、Rivet、Vellum等。这些框架通过简化调用LLM、定义和解析工具以及链接调用等标准低级任务，使入门变得容易。然而，它们通常会增加额外的抽象层，可能会掩盖底层的提示和响应，导致调试变得困难。此外，它们可能会诱使开发者增加不必要的复杂性。

怎么解决？

（1）优先直接使用LLM API

核心观点：许多智能体模式可以通过几行代码实现，直接使用API更灵活且易于理解。

首先，直接使用API可以更好地控制行为。

可以精确控制每次LLM调用的提示词
可以自定义工具调用的格式和解析逻辑
可以灵活处理各种边界情况

其次，直接使用API有助于理解底层机制。

能够清楚地看到每次API调用的输入和输出
能够理解工具调用的具体实现方式
能够更好地调试和优化系统

（2）理解框架的底层实现

核心观点：如果确实需要使用框架，必须理解其底层代码，避免错误的假设。

首先，框架可能隐藏重要的实现细节。

框架如何处理工具调用可能与你期望的不同
框架的错误处理机制可能不符合你的需求
框架的性能优化可能引入意外的副作用

其次，理解底层实现有助于正确使用框架。

知道框架在什么情况下会失败
知道如何绕过框架的限制
知道如何优化框架的性能

（3）评估框架的必要性

核心观点：只有在框架真正简化开发且不引入额外复杂性时，才使用框架。

首先，评估框架是否真的简化了开发。

框架是否减少了代码量？
框架是否提高了开发效率？
框架是否解决了实际痛点？

其次，评估框架是否引入了不必要的复杂性。

框架的学习曲线是否合理？
框架的抽象层是否过度？
框架是否限制了灵活性？

效果评估：直接使用API通常更灵活，框架适合快速原型开发

直接使用API的优势：

灵活性高：可以完全控制实现细节
易于调试：能够清楚地看到每次调用
性能可控：没有额外的抽象层开销
学习价值高：深入理解LLM的工作原理

框架的优势：

开发速度快：快速搭建原型
标准化：遵循最佳实践
功能丰富：提供开箱即用的功能
社区支持：有文档和社区帮助

实际应用示例：

示例1：直接使用API实现工具调用

# 直接使用API，完全控制
def agent_with_tools(user_query):
    # 1. LLM生成工具调用请求
    prompt = f"""
    用户查询：{user_query}
    
    可用工具：
    - search(query): 搜索信息
    - calculate(expression): 计算表达式
    
    请决定使用哪个工具，并生成工具调用。
    """
    
    response = llm.generate(prompt)
    
    # 2. 解析工具调用（自己实现解析逻辑）
    tool_call = parse_tool_call(response)
    
    # 3. 执行工具
    result = execute_tool(tool_call)
    
    # 4. 将结果返回给LLM
    final_prompt = f"{prompt}\n\n工具执行结果：{result}\n\n请生成最终回答。"
    final_answer = llm.generate(final_prompt)
    
    return final_answer

示例2：使用框架实现相同功能

# 使用框架，代码更简洁但控制力降低
from agent_framework import Agent

agent = Agent(
    tools=[search, calculate],
    llm=llm
)

answer = agent.run(user_query)

四、构建模块：增强型LLM

[!NOTE]
📝 关键点总结：增强型LLM是智能体系统的基础，需要为LLM提供易于使用、文档齐全的接口。

核心要点：

LLM可以主动使用检索、工具和记忆能力
需要根据具体场景定制这些能力
接口设计要清晰，便于LLM正确调用

设计原则：接口要简单、文档要清晰、错误处理要完善

核心结论：增强型LLM是智能体系统的基本构建模块，其设计质量直接影响系统性能

智能体系统的基本构建模块是经过增强的LLM，如检索、工具和记忆。当前的模型可以主动使用这些能力——生成自己的搜索查询、选择适当的工具，并确定保留哪些信息。在实现上，需要根据具体场景定制这些能力，并确保它们为LLM提供易于使用、文档齐全的接口，以便LLM正确调用。

怎么解决？

（1）检索增强（Retrieval）

核心观点：为LLM提供检索能力，使其能够主动获取相关信息。

首先，检索接口要简单明了。

提供清晰的搜索函数，如search(query: str) -> List[Document]
函数名和参数要直观，便于LLM理解
返回格式要结构化，便于LLM解析

其次，检索结果要高质量。

确保检索到的文档与查询相关
控制返回文档的数量，避免信息过载
提供文档的元数据（来源、时间等），帮助LLM判断可信度

（2）工具调用（Tools）

核心观点：为LLM提供工具调用能力，使其能够执行具体操作。

首先，工具接口要标准化。

每个工具要有清晰的名称和描述
参数要有明确的类型和说明
返回值要有统一的格式

其次，工具文档要详细。

在提示词中清晰说明每个工具的用途
提供工具使用的示例
说明工具的限制和注意事项

（3）记忆管理（Memory）

核心观点：为LLM提供记忆能力，使其能够保留和检索历史信息。

首先，记忆要结构化存储。

使用向量数据库存储对话历史
为每条记忆添加元数据（时间、重要性等）
支持按时间、主题等维度检索

其次，记忆要智能管理。

自动识别重要信息并长期保存
定期清理过时或无关的记忆
根据当前任务检索相关记忆

效果评估：良好的增强型LLM设计能够显著提升智能体系统的性能

检索增强的效果：

准确性提升：LLM能够获取最新、最相关的信息
知识扩展：突破训练数据的限制
实时性：能够获取实时信息

工具调用的效果：

能力扩展：LLM能够执行原本无法执行的操作
准确性提升：使用专业工具获得准确结果
效率提升：自动化执行重复性任务

记忆管理的效果：

上下文保持：在长对话中保持上下文连贯
个性化：根据历史交互提供个性化服务
学习能力：从历史交互中学习用户偏好

实际应用示例：

示例1：增强型LLM的接口设计

# 为LLM提供清晰的接口
class EnhancedLLM:
    def __init__(self):
        self.retriever = DocumentRetriever()
        self.tools = {
            "search": self.search_tool,
            "calculate": self.calculate_tool,
            "send_email": self.send_email_tool
        }
        self.memory = MemoryStore()
    
    def get_available_capabilities(self):
        """返回LLM可用的能力描述"""
        return """
        可用能力：
        
        1. 检索（search）：
           - 函数：search(query: str) -> List[Document]
           - 用途：搜索相关文档和信息
           - 示例：search("Python异步编程")
        
        2. 计算（calculate）：
           - 函数：calculate(expression: str) -> float
           - 用途：计算数学表达式
           - 示例：calculate("2 + 3 * 4")
        
        3. 发送邮件（send_email）：
           - 函数：send_email(to: str, subject: str, body: str) -> bool
           - 用途：发送电子邮件
           - 示例：send_email("user@example.com", "Hello", "This is a test")
        
        4. 记忆（memory）：
           - 自动保存重要信息
           - 可通过上下文自动检索
        """

五、工作流模式：提示链（Prompt Chaining）

[!NOTE]
📝 关键点总结：提示链将任务分解为固定步骤，每个LLM调用处理前一个的输出，适用于可清晰分解的任务。

核心要点：

任务可以分解为固定的子任务序列
每个步骤的输出作为下一步的输入
可以在中间步骤添加程序化检查

适用场景：任务流程相对固定，需要高准确性的场景

核心结论：提示链通过将复杂任务分解为简单步骤，以延迟换取更高的准确性

提示链将任务分解为一系列步骤，每个LLM调用处理前一个的输出。可以在任何中间步骤添加程序化检查，以确保过程仍在正轨。该模式适用于任务可以轻松且清晰地分解为固定子任务的情况。主要目标是通过对每个LLM调用执行更简单的任务，以延迟换取更高的准确性。

怎么解决？

（1）任务分解

核心观点：将复杂任务分解为一系列简单的子任务，每个子任务由一次LLM调用完成。

首先，分解要遵循逻辑顺序。

前一个步骤的输出是下一个步骤的输入
每个步骤都有明确的输入和输出
步骤之间的依赖关系要清晰

其次，每个步骤要足够简单。

每个LLM调用只处理一个明确的子任务
避免在一个步骤中处理多个不相关的任务
确保每个步骤的成功率较高

（2）中间检查

核心观点：在关键步骤之间添加程序化检查，确保过程在正确的轨道上。

首先，检查要针对关键决策点。

在任务分解的关键节点进行检查
验证中间结果的格式和内容
确保没有偏离预期目标

其次，检查失败要有恢复机制。

如果检查失败，要有明确的处理策略
可以重试当前步骤
可以回退到上一个步骤
可以终止流程并返回错误

（3）结果整合

核心观点：将各个步骤的结果整合为最终输出。

首先，整合要保留关键信息。

确保重要信息不会在传递过程中丢失
使用结构化的数据格式传递信息
在提示词中明确说明需要保留的信息

其次，整合要考虑上下文。

最终步骤要能够访问所有中间结果
可以使用摘要的方式传递大量信息
确保最终输出符合预期格式

效果评估：提示链模式在准确性上有显著优势，但会增加延迟和成本

提示链的优势：

准确性高：每个步骤专注于简单任务，错误率低
可调试：每个步骤的输出都可以检查，问题容易定位
可控性强：可以在任何步骤添加检查和验证
可扩展：容易添加新的步骤或修改现有步骤

提示链的劣势：

延迟高：需要多次API调用，总延迟较长
成本高：多次调用增加了API成本
复杂度增加：需要管理多个步骤的状态和传递

实际应用示例：

示例1：文档摘要生成流程

def summarize_document(document):
    # 步骤1：提取关键信息
    key_info_prompt = f"""
    请从以下文档中提取关键信息：
    {document}
    
    提取以下内容：
    1. 主要主题
    2. 关键观点
    3. 重要数据
    """
    key_info = llm.generate(key_info_prompt)
    
    # 检查：验证关键信息是否提取成功
    if not validate_key_info(key_info):
        return "无法提取关键信息"
    
    # 步骤2：生成摘要大纲
    outline_prompt = f"""
    基于以下关键信息，生成摘要大纲：
    {key_info}
    
    大纲应包含：
    1. 引言
    2. 主要观点
    3. 结论
    """
    outline = llm.generate(outline_prompt)
    
    # 步骤3：生成最终摘要
    summary_prompt = f"""
    基于以下大纲和关键信息，生成完整的文档摘要：
    
    大纲：{outline}
    关键信息：{key_info}
    
    摘要要求：
    - 长度：200-300字
    - 语言：简洁明了
    - 结构：遵循大纲
    """
    summary = llm.generate(summary_prompt)
    
    return summary

示例2：代码审查流程

def code_review(code):
    # 步骤1：代码分析
    analysis = llm.generate(f"分析以下代码的功能和结构：\n{code}")
    
    # 步骤2：问题识别
    issues = llm.generate(f"基于以下分析，识别代码中的问题：\n{analysis}")
    
    # 步骤3：生成改进建议
    suggestions = llm.generate(f"针对以下问题，提供改进建议：\n{issues}")
    
    # 步骤4：生成审查报告
    report = llm.generate(f"""
    生成代码审查报告：
    
    代码分析：{analysis}
    发现的问题：{issues}
    改进建议：{suggestions}
    """)
    
    return report

六、工作流模式：树搜索（Tree Search）

[!NOTE]
📝 关键点总结：树搜索在任务空间中探索多个可能路径，适用于需要在多个解决方案中找到最优解的场景。

核心要点：

在任务空间中生成多个候选解决方案
评估每个候选方案的质量
选择最优方案或继续探索

适用场景：任务有多种可能的解决方案，需要找到最优解

核心结论：树搜索通过探索多个可能路径，在复杂任务空间中寻找最优解决方案

树搜索模式适用于需要在多个可能路径中找到最佳解决方案的情况。LLM生成多个候选解决方案，评估每个方案的质量，然后选择最优方案或继续探索。这种模式特别适合任务空间较大、有多种可能解决方案的场景。

怎么解决？

（1）生成候选方案

核心观点：使用LLM生成多个不同的候选解决方案。

首先，要确保候选方案的多样性。

使用不同的提示词生成不同的方案
可以设置温度参数增加随机性
可以从不同的角度思考问题

其次，候选方案要覆盖主要可能性。

确保候选方案覆盖不同的解决思路
避免生成过于相似的方案
平衡探索的广度和深度

（2）评估方案质量

核心观点：对每个候选方案进行评估，确定其质量。

首先，评估标准要明确。

定义清晰的评估指标（准确性、效率、成本等）
可以使用LLM进行评估，也可以使用程序化方法
评估结果要可比较

其次，评估要全面。

考虑多个维度的质量
评估方案的可行性和风险
考虑实施成本和难度

（3）选择或继续探索

核心观点：根据评估结果选择最优方案，或继续探索更好的方案。

首先，要有明确的停止条件。

找到满足要求的方案就停止
达到最大探索深度就停止
评估分数达到阈值就停止

其次，要有探索策略。

可以优先探索高分方案的分支
可以随机探索增加多样性
可以平衡探索和利用

效果评估：树搜索能够找到更好的解决方案，但计算成本较高

树搜索的优势：

解决方案质量高：通过探索多个方案找到最优解
鲁棒性强：有多种备选方案
创新性：可能发现意想不到的解决方案

树搜索的劣势：

计算成本高：需要生成和评估多个方案
延迟长：探索过程需要时间
复杂度高：需要实现搜索和评估逻辑

实际应用示例：

示例1：问题解决树搜索

def solve_problem_with_tree_search(problem, max_depth=3):
    # 初始状态
    candidates = [{"solution": "", "score": 0, "depth": 0}]
    
    for depth in range(max_depth):
        new_candidates = []
        
        for candidate in candidates:
            # 生成多个候选解决方案
            solutions = llm.generate_multiple(
                f"问题：{problem}\n当前方案：{candidate['solution']}\n生成3个改进方案",
                n=3
            )
            
            # 评估每个方案
            for solution in solutions:
                score = evaluate_solution(solution, problem)
                new_candidates.append({
                    "solution": solution,
                    "score": score,
                    "depth": depth + 1
                })
        
        # 选择最优的N个方案继续探索
        candidates = sorted(new_candidates, key=lambda x: x['score'], reverse=True)[:5]
        
        # 如果找到足够好的方案，提前停止
        if candidates[0]['score'] > 0.9:
            break
    
    return candidates[0]['solution']

示例2：代码生成树搜索

def generate_code_with_tree_search(requirement):
    # 生成多个实现方案
    implementations = []
    
    for approach in ["面向对象", "函数式", "过程式"]:
        code = llm.generate(f"使用{approach}方法实现：{requirement}")
        score = evaluate_code(code, requirement)
        implementations.append({"code": code, "score": score, "approach": approach})
    
    # 选择最优方案
    best = max(implementations, key=lambda x: x['score'])
    
    # 如果分数不够高，继续优化
    if best['score'] < 0.8:
        improved = llm.generate(f"优化以下代码：\n{best['code']}")
        return improved
    
    return best['code']

七、智能体模式：自主智能体（Autonomous Agents）

[!NOTE]
📝 关键点总结：自主智能体由LLM动态指导自身流程，适用于需要高度灵活性和模型驱动决策的复杂任务。

核心要点：

LLM自主决定下一步行动
根据执行结果动态调整策略
需要明确的目标和停止条件

适用场景：任务复杂且不确定，需要长期运行和持续调整

核心结论：自主智能体通过LLM的动态决策能力，能够处理复杂且不确定的任务

自主智能体是指LLM动态指导自身流程和工具使用，保持对任务完成方式的控制。这种模式适用于需要灵活性和模型驱动决策的大规模任务。然而，自主智能体通常会以延迟和成本为代价，换取更好的任务性能，因此需要权衡这种取舍何时是合理的。

怎么解决？

（1）明确目标和状态

核心观点：为智能体提供清晰的目标和当前状态信息，使其能够做出正确决策。

首先，目标要具体可衡量。

使用清晰的语言描述任务目标
定义成功标准，使智能体知道何时停止
提供目标优先级，帮助智能体权衡不同行动

其次，状态信息要全面。

提供当前任务的上下文信息
记录已执行的行动和结果
提供可用资源和工具的信息

（2）行动决策机制

核心观点：让LLM根据当前状态自主决定下一步行动。

首先，决策要基于充分的信息。

为LLM提供完整的当前状态
说明可用的行动选项
提供历史行动的结果，帮助学习

其次，决策要有约束。

定义允许的行动范围
设置资源限制（时间、成本等）
防止无限循环或危险操作

（3）执行和反馈循环

核心观点：执行行动后收集反馈，用于调整后续决策。

首先，反馈要及时准确。

立即获取行动的执行结果
评估行动是否达到预期效果
识别执行过程中的错误或异常

其次，反馈要用于改进。

将反馈信息整合到状态中
让LLM根据反馈调整策略
记录成功和失败的模式，用于未来决策

（4）停止条件

核心观点：定义明确的停止条件，防止智能体无限运行。

首先，成功条件要明确。

定义任务完成的判断标准
当目标达成时自动停止
提供明确的完成信号

其次，失败保护要完善。

设置最大执行步数
设置超时机制
检测到错误模式时停止

效果评估：自主智能体能够处理复杂任务，但需要精心设计以避免失控

自主智能体的优势：

灵活性高：能够适应复杂和变化的环境
创新能力强：可能发现意想不到的解决方案
适应性强：能够根据反馈调整策略
可扩展性好：容易添加新的能力和工具

自主智能体的劣势：

不可预测：行为难以完全预测
调试困难：问题定位和修复复杂
成本高：需要大量API调用
风险高：可能出现意外行为

实际应用示例：

示例1：研究助手自主智能体

class ResearchAgent:
    def __init__(self, topic):
        self.topic = topic
        self.knowledge = []
        self.actions_taken = []
        self.max_steps = 20
    
    def run(self):
        step = 0
        while step < self.max_steps:
            # LLM分析当前状态并决定行动
            action = self.decide_action()
            
            # 执行行动
            result = self.execute_action(action)
            
            # 更新状态
            self.update_state(action, result)
            
            # 检查是否完成
            if self.is_complete():
                break
            
            step += 1
        
        return self.generate_report()
    
    def decide_action(self):
        prompt = f"""
        研究主题：{self.topic}
        
        当前知识：
        {self.knowledge}
        
        已执行行动：
        {self.actions_taken}
        
        可用行动：
        1. search(query) - 搜索相关信息
        2. analyze(data) - 分析数据
        3. summarize(findings) - 总结发现
        4. generate_hypothesis(question) - 生成假设
        
        请决定下一步行动，说明原因。
        """
        return llm.generate(prompt)
    
    def execute_action(self, action):
        # 解析并执行行动
        # 返回执行结果
        pass
    
    def is_complete(self):
        # 检查是否达到研究目标
        prompt = f"""
        研究主题：{self.topic}
        当前知识：{self.knowledge}
        
        是否已经收集到足够的信息来完成研究？回答是或否。
        """
        return llm.generate(prompt) == "是"

示例2：任务规划自主智能体

class TaskPlanningAgent:
    def __init__(self, goal):
        self.goal = goal
        self.plan = []
        self.current_step = 0
        self.resources = {}
    
    def plan_and_execute(self):
        while not self.goal_achieved():
            # LLM分析当前情况
            situation = self.analyze_situation()
            
            # LLM决定下一步
            next_action = self.decide_next_action(situation)
            
            # 执行行动
            result = self.execute(next_action)
            
            # 更新计划
            self.update_plan(next_action, result)
            
            # 检查是否需要调整计划
            if self.need_replan():
                self.replan()
    
    def decide_next_action(self, situation):
        prompt = f"""
        目标：{self.goal}
        
        当前情况：{situation}
        当前计划：{self.plan}
        可用资源：{self.resources}
        
        请决定下一步行动，说明原因。
        """
        return llm.generate(prompt)