1. 学习内容总结

• 智能体的定义：能够感知环境、通过执行器采取行动以实现目标的实体，具备自主性、反应性和目标导向性。

• 传统智能体的演进：从简单反射式到基于模型、目标、效用的智能体，最终发展为强化学习驱动的学习型智能体。

• LLM智能体的新范式：以大语言模型为核心，具备自然语言理解、任务分解、工具调用和动态修正能力。

• PEAS模型：用于描述任务环境，包含性能指标（Performance）、环境（Environment）、执行器（Actuators）和传感器（Sensors）。

• 智能体的运行机制：基于“感知-思考-行动-观察”循环，通过结构化输出（Thought-Action-Observation）与环境交互。

2.旅行助手Agent案例

(1) 尝试在available_tools中增加preferences_tool(用户偏好工具)

考虑以下几点：

• 添加的工具：我们需要增加两个工具record_user_preferences（记录用户偏好）和get_user_preference（获取用户偏好）

• 用户偏好数据：由于我们在此之前只有两个工具get_attraction和get_weather，所以我们只记录用户喜欢的景点和天气。

• 修改已有工具：由于我们要根据用户的偏好去返回结果，那么就需要在已有的get_attraction中添加一个user_preference参数让智能体去思考。

• 潜在的问题：

  • 工具之间存在了依赖性：

    如果智能体将用户的历史偏好作为搜索条件的一部分，也就是说，需要在工具get_attraction内部调用get_user_preference，这样就导致工具的独立性被破坏了。

  • 解决方案：我们可以让智能体去主动获取用户的历史偏好（充分利用智能体的智能），只需调用get_attraction工具时，将偏好作为额外参数传入

  • 即便使用了上面的解决方案，我们仍然需要将get_user_preference和record_user_preference这两个工具保留：

    1. 智能体需要知道在什么情况下使用这些工具（比如用户明确表达偏好时记录，或者在推荐前获取偏好）。

    2. 智能体并不自动记住上下文，每次循环都是独立的，所以需要将偏好持久化，并在需要时通过工具获取。

    3. 这样智能体在推荐景点时既可以不需要额外步骤获取偏，也可以在需要时主动获取偏好。

    4. 示例：

       用户: 我想去北京，喜欢博物馆和历史遗迹 AI: Thought: 用户想去北京，我需要先获取天气信息，然后推荐景点。系统会自动记录用户对博物馆和历史遗迹的偏好。 Action: get_weather(city="北京")

       用户: 上海天气怎么样？我想去户外公园 AI: Thought: 查询上海天气，用户表达了喜欢户外公园的偏好，系统会记录并用于推荐。 Action: get_weather(city="上海")

3.Agent目前的一些问题

1. 工具调用的可靠性挑战：

   • 在旅行助手案例中，天气API可能返回“阴天”，但实际突然下雨。此时智能体需动态调整推荐（如从户外转向室内），而当前架构依赖固定观察反馈，缺乏实时性。可能的改进方向是引入传感器数据流和事件驱动机制。

2. Workflow与Agent的边界模糊化：

   • 纯规则引擎（Workflow）和纯智能体（Agent）的二分法并不绝对。实际应用中，混合模式可能更优。例如：

     • 初级判断用Workflow：如“金额<100元自动退款”。

     • 复杂场景用Agent：如“用户历史退款率过高但本次商品有瑕疵”，需结合上下文决策。

3. 对“黑盒性”的警惕：

   • LLM驱动的智能体容易产生“幻觉”（如虚构不存在的景点）。解决方案可包括：

     • 输出验证层：对关键信息（如景点名称）二次检索验证。

     • 用户确认机制：如“推荐颐和园，需查看最新开放时间吗？”

学习途径来自:https://github.com/datawhalechina/hello-agents/tree/main/docs