【第一章习题】个人学习笔记与解答

[lizhuofan-curry]

以下是我学习 Hello Agents 第一章后整理的课后习题答案和个人理解。部分内容结合智能旅行助手代码进行分析，欢迎大家讨论和指正。

第一章课后习题

习题1

请分析以下四个 case 中的主体是否属于智能体，如果是，那么属于哪种类型的智能体（可以从多个分类维度进行分析），并说明理由：

case A：一台符合冯·诺依曼结构的超级计算机，拥有高达每秒 2EFlop 的峰值算力

case B：特斯拉自动驾驶系统在高速公路上行驶时，突然检测到前方有障碍物，需要在毫秒级做出刹车或变道决策

case C：AlphaGo在与人类棋手对弈时，需要评估当前局面并规划未来数十步的最优策略

case D：ChatGPT 扮演的智能客服在处理用户投诉时，需要查询订单信息、分析问题原因、提供解决方案并安抚用户情绪

首先判断一个对象是不是智能体，不能只看算力强不强，而且要看它是否形成了：

感知环境 -> 自主决策 -> 执行动作 -> 获得反馈 -> 继续调整

这也就是代码中Thought -> Action -> Observation 循环的理论来源

---

判断四个 case 是否属于智能体

Case A : 符合冯·诺依曼结果的超级计算机

拥有高达每秒 2EFlop 峰值算力

结论

仅凭题目给出的信息，它不属于智能体。超级计算机只是一台计算能力超级强的机器，‘计算能力强’不等于‘具有智能体能力’。

他可能拥有：输入 -> 计算 -> 输出，但题目没有说明它具有：明确目标，对环境的持续感知，根据环境变化自主决策，通过环境影响环境，根据反馈调整行动等。比如超级计算机在计算矩阵乘法时，无论计算有多快，它依然只是在执行人类预先指定的运算，不会自行判断：我应该解决什么问题，环境发生了什么变化 . . . .

一个重要区别

超级计算机本身不是智能体，但可以承载智能体，例如

超级计算机硬件
    ↓
运行天气预测模型
    ↓
运行决策系统
    ↓
根据灾害风险自动发布预警

此时：

• 超级计算机是允许平台
• 上面的灾害检测与决策系统才可能是智能体

这就好像高性能显卡本身不是智能体，但允许在显卡上的自动驾驶系统可能是智能体

Case B : 特斯拉自动驾驶系统

高速公路行驶时检测到障碍物，需要在毫秒级做出刹车和变道决策

结论

属于智能体，而且可以从多个维度分类

1. 为什么属于智能体？

它具备完整闭环：

摄像头、雷达等感知障碍物
            ↓
自动驾驶系统判断危险程度
            ↓
决定刹车、减速或变道
            ↓
控制转向、制动和动力系统
            ↓
车辆位置、速度发生变化
            ↓
传感器继续感知新状态

对应智能体四要素：

要素	自动驾驶系统中的对应物
环境	道路、车辆、行人、天气、交通标志
传感器	摄像头、雷达、定位系统、速度传感器
决策主体	自动驾驶算法
执行器	刹车、方向盘、油门、灯光系统

2. 按内部决策架构分类

它既具有基于模型的智能体特征，也可能具有目标型和效用型智能体特征。基于模型是因为它不仅看到当前摄像头画面，还要维护内部状态：

前车当前速度
前车可能的运动轨迹
本车制动距离
旁边车道是否有车
障碍物是否正在移动

它也是目标型智能体，因为存在目标：安全到达目的地

还具有基于效用的特征，因为它需要在多个目标之间权衡：

安全性
舒适性
到达速度
是否违反交通规则
是否影响其他车辆

例如：

急刹车最安全，但可能造成追尾；
立即变道可以避障，但旁边可能有车辆；
缓慢减速更舒适，但制动距离可能不足。

3. 按反应速度分类

它属于混合智能式智能体：

• 紧急制动属于反应式决策，要求毫秒级响应
• 路径规划和复杂变道属于规划式决策
• 实际系统需要将两者结合

教材也指出，反应式智能体速度快但容易短视，规划式智能体考虑长但成本较高，因此现实系统常采用分层混合架构。

4. 按存在形式分类

它属于具身智能或物理智能体，因为它最终通过真实车辆的方向盘，油门和刹车改变物理世界。

Case C: AlphaGo与人类棋手博弈

评估当前局面并规划未来数十步的最优策略

结论

属于智能体

它的闭环是：

感知当前棋盘状态
        ↓
评估候选落子
        ↓
搜索未来可能局面
        ↓
选择一个落子
        ↓
对手落子，棋盘改变
        ↓
重新感知并决策

1. 按内部架构分类

   AlphaGo具有以下特征：

   • 基于模型： 棋盘状态和围棋规则构成内部世界模型
   • 目标型： 目标是赢得比赛
   • 效用型： 不同棋局状态具有不同的胜率估计
   • 学习型： 神经网络通过棋谱，自我对弈或强化学习不断改善策略

   它不是简单地遵循：

   if 对方下在这里:
       我就下在那里

   而是评估多个可能行动，并估算：

   下在A位置，最终胜率可能是55%
   下在B位置，最终胜率可能是61%
   下在C位置，最终胜率可能是48%

   然后选择期望效用更高的行动

2. 按反应性分类

   它主要属于规划式智能体

   因为它不会只根据当前棋盘做一个瞬时反应，而会搜索未来的行动序列，评估不同落子的长期后果。

3. 按知识表示分类

   它体现了神经网络与搜索的结合：

   • 神经网络复杂局面识别，策略预测和价值评估
   • 搜索算法负责探索可能的行动路径
   • 围棋规则属于明确的符号规则

   因此可以将其理解为具有神经符号混合系统的系统

Case D: ChatGPT 扮演智能客服

查询订单，分析原因，提供解决方案并安抚用户情绪

结论

**如果它真正连接了订单查询，退款等工具，并能自主选择行动，就属于 LLM 驱动的软件智能体。**仅仅聊天的 ChatGPT 更接近语言模型应用；连接外部工具并形成行动闭环后，才具有更完整的智能体性质，例如：

用户：我的包裹一周没到，我很生气
              ↓
LLM识别用户意图和情绪
              ↓
调用 get_order(order_id)
              ↓
获得物流异常信息
              ↓
调用查询政策或补偿工具
              ↓
生成解决方案并安抚用户

分类

它可以同时具有：

• 基于模型的智能体：维度订单状态，对话历史和用户信息
• 目标型智能体：目标是解决投诉
• 效用型智能体： 在用户满意度，公司成本，退款政策之间权衡
• 混合式智能体： 快速回应情绪，同时分布查询订单并规划方案
• LLM 驱动智能体：通过大语言模型理解模糊的自然语言
• 神经符号混合特征： LLM 理解语言，程序规则检查退款资格，API执行订单操作

习题2

假设你需要为一个"智能健身教练"设计任务环境。这个智能体能够：

• 通过可穿戴设备监测用户的心率、运动强度等生理数据
• 根据用户的健身目标（减脂/增肌/提升耐力）动态调整训练计划
• 在用户运动过程中提供实时语音指导和动作纠正
• 评估训练效果并给出饮食建议

请使用 PEAS 模型完整描述这个智能体的任务环境，并分析该环境具有哪些特性（如部分可观察、随机性、动态性等）。

PEAS 不是程序执行的四个执行步骤，而是用来完整描述智能体的任务环境

1. Performance：性能度量

   用什么指标判断健身教练做的好不好？

   用户是否逐渐实现减脂、增肌或提高耐力的目标；
   训练计划是否与用户能力匹配；
   是否避免运动损伤；
   用户是否能长期坚持；
   用户心率是否处于合理区间；
   训练强度调整是否及时；
   饮食建议是否合理；
   用户满意度；
   异常心率识别率；
   误报率和漏报率；
   建议的个性化程度；

   不能只看‘减重越多越好’。如果用户快速减重但发生损伤，营养不足，那么总体性能并不好。因此可以设计综合评价：

   总效用 =
       目标完成程度
     + 健康改善程度
     + 用户坚持程度
     - 受伤风险
     - 过度训练风险
     - 错误建议风险

2. **Environment : 环境 **

   智能健身体所处的环境包括：

   用户本人及其身体状态；
   家庭、健身房、户外等训练场所；
   哑铃、跑步机等器械；
   穿戴设备；
   手机和健身应用；
   用户的日程安排；
   饮食条件；
   睡眠情况；
   温度、天气等外部条件；
   网络和健康数据服务；
   教练、医生或其他共同参与者。

3. Actuators : 执行器

   执行器是智能体影响环境的方式，数字健身教练不能直接替用户运动，但可以通过以下方式影响用户：

   显示文字训练计划；
   播放语音提示；
   展示动作示范视频；
   发出震动或心率预警；
   动态调整组数、次数和重量；
   暂停训练；
   推荐休息；
   发送饮食建议；
   设置提醒和日程；
   联系紧急联系人；
   建议用户咨询医生。

   例如：

   检测到心率过高
       ↓
   暂停当前高强度训练
       ↓
   发出语音警告
       ↓
   建议休息并重新测量

   这些都是行动

4. Sensors : 传感器

   智能体可以通过以下信息感知环境：

   心率；
   血氧；
   步数；
   运动速度；
   运动时间；
   卡路里估计；
   睡眠时长和质量；
   GPS轨迹；
   加速度计和陀螺仪；
   用户年龄、身高、体重；
   用户输入的健身目标；
   用户主动反馈；
   摄像头识别的动作姿势；

   其中，穿戴设备API就相当于数字智能体的传感器

5. 该环境的性质

   部分可观察

   智能体不能完全知道用户真实身体状态，例如，他能看到心率，但可能不知道：

   用户是否膝盖疼；
   用户昨晚是否失眠；
   用户是否漏报疾病；
   动作是否完全标准；
   饮食记录是否真实。

   因此是部分可观察环境

   随机性

   同一训练计划对不同用户，甚至同一用户不同日期的效果都可能不同，相同跑步30分钟，可能因为睡眠，饮食，压力和环境温度的不同，产生不同结果，因此属于随机性环境

   序贯性

   当前行为会影响未来状态，例如：

   今天安排高强度腿部训练
       ↓
   明天肌肉疲劳
       ↓
   明天的训练计划需要调整

   所有不是相互的单词任务，而是序贯任务

习题3

某电商公司正在考虑两种方案来处理售后退款申请：

方案 A（Workflow）：设计一套固定流程，例如：

A.1 对于一般商品且在 7 天之内，金额 < 100RMB 自动通过；100-500RMB 由客服审核；>500RMB 需主管审批；而特殊商品（如定制品）一律拒绝退款

A.2 对于超过 7 天的商品，无论金额，只能由客服审核或主管审批；

方案 B（Agent）：搭建一个智能体系统，让它理解退款政策、分析用户历史行为、评估商品状况，并自主决策是否批准退款

请分析：

• 这两种方案各自的优缺点是什么？
• 在什么情况下 Workflow 更合适？什么情况下 Agent 更有优势？如果你是该电商公司的负责人，你更倾向于采用哪种方案？
• 是否存在一个方案 C，能够结合两种方案，达到扬长避短的效果？

方案A : 固定 Workflow

Workflow使用明确规则：

是否在7天内？
    ├─ 否 → 人工审核
    └─ 是
        ├─ 特殊商品 → 拒绝
        └─ 普通商品
            ├─ <100元 → 自动通过
            ├─ 100～500元 → 客服审核
            └─ >500元 → 主管审批

优点： 行为确定，容易测试，退款规则透明，响应速度快，成本低，不会因为语言模型幻觉随意退款

缺点： 规则之外的情况处理能力差，很难理解复杂投诉，无法灵活综合用户历史，规则数量越来越多时维护困难

方案B : 完全由 Agent 决策

Agent会综合分析：

退款政策
用户历史行为
商品状态
投诉内容
物流记录
欺诈风险
用户情绪
商品价值

优点： 能理解自然语言投诉，能处理非标准情况，能综合多个信息来源，可以主动调用订单，物流和用户画像工具，能针对不同用户解释原因，可以根据新信息动态调整判断

缺点：输出具有不确定性，可能产生幻觉，审计和解释比较困难，可能被用户提示词诱导，每次决策需要模型调用成本

在什么情况下 Workflow 更合适

当业务由以下特点时优先采用 Workflow:

规则明确；
合规要求严格；
结果必须可重复；
错误代价高；
大多数订单属于标准情况；
每个决定都需要审计；
需要高并发、低延迟和低成本。

退款资格和资金操作本身就非常适合规则系统

在什么情况下Agent更有优势

Agent更适合：

理解用户的自然语言投诉；
从聊天中提取订单号；
总结物流和客服记录；
识别异常情形；
收集缺失信息；
为客服生成处理建议；
解释退款政策；

如果我是负责人，我会选择哪一种？

我不会选择完全固定或完全自主，而是会采用方案C : Agent + Workflow 的混合架构

用户提出退款申请
        ↓
Agent理解投诉、提取订单号、收集证据
        ↓
规则引擎检查硬性政策
        ↓
低风险标准订单 → 自动处理
        ↓
中风险或信息不全 → Agent补充信息/给出建议
        ↓
高金额、特殊商品、欺诈风险 → 人工审批
        ↓
Workflow执行退款
        ↓
Agent向用户解释结果

工作	负责模块
理解自然语言	Agent
提取订单信息	Agent
查询订单和物流	Agent调用工具
检查7天期限	Workflow
检查特殊商品	Workflow
金额权限判断	Workflow
最终资金操作	Workflow或人工
向用户解释	Agent
安抚情绪	Agent

这里最重要的原则是：Agent可以负责理解，分析和提出建议，但不可绕过硬性政策直接操作高风险资金。这样既利用大模型的灵活性，也保留规则系统的确定性和可审计性

习题4

在 1.3 节的智能旅行助手基础上，请思考如何添加以下功能（可以只描述设计思路，也可以进一步尝试代码实现）：

提示：思考如何修改 Thought-Action-Observation 循环来实现这些功能。

• 添加一个"记忆"功能，让智能体记住用户的偏好（如喜欢历史文化景点、预算范围等）
• 当推荐的景点门票已售罄时，智能体能够自动推荐备选方案
• 如果用户连续拒绝了 3 个推荐，智能体能够反思并调整推荐策略

当前旅行助手已经有：

系统提示词；
天气工具；
景点工具；
prompt_history 短期记忆；
Thought-Action-Observation 循环；
最大5轮限制。

书上把这种循环概括为感知，规划，工具选择，行动和观察

添加用户偏好记忆

目前的 prompt_history只能算短期记忆

prompt_history = [f'用户请求: {user_prompt}']

每轮又加入：

prompt_history.append(llm_output)
prompt_history.append(observation_str)

所以模型可以记住本次任务中的：

所以模型可以记住本次任务中的：用户问了什么，已经调用了什么工具，工具返回了什么；但是程序结束后，prompt_history 消失，因此它不能记住用户下次再来时的偏好

可以增加长期用户画像

例如：

user_profile = {
    "preferred_types": ["历史文化", "博物馆"],
    "disliked_types": ["高空项目"],
    "budget_min": 0,
    "budget_max": 200,
    "travel_style": "节奏舒缓"
}

新增两个工具：

def save_user_preference(key: str, value: str) -> str:
    user_profile[key] = value
    return f"已记录用户偏好：{key}={value}"

def get_user_profile() -> str:
    return str(user_profile)

注册到工具表

available_tools = {
    "get_weather": get_weather,
    "get_attraction": get_attraction,
    "save_user_preference": save_user_preference,
    "get_user_profile": get_user_profile,
}

系统提示词中还要告诉模型：

- save_user_preference(key, value)：保存用户长期偏好
- get_user_profile()：读取用户长期偏好

在推荐景点前，如果用户画像尚未读取，应先读取用户偏好。
如果用户明确表达新偏好，应保存该偏好。

新的运行过程

用户说：

我喜欢历史文化景点，预算不要超过200元

模型可以产生：

Action:save_user_preference(
	key='preferred_types',
	value='历史文化景点'
)

再保存预算

Action:save_user_preference(
	key = 'budget_max',
    value='200'
)

以后用户之说： 帮我推荐一个开封景点

智能体可以先读取画像，再推荐更符合偏好的景点。正式应用中，这些数据应存入数据库，并按用户ID隔离，而不是所有用户共用一个全局字典

景点门票售罄时自动推荐备选方案

现在的get_attraction() 只负责搜索景点，没有查询实时门票

可以新增工具

def check_ticket(attraction: str , date : str) -> str :
    """查询景点指定日期是否有票"""

以及：

def get_alternative_attractions(
    city: str,
    weather: str,
    excluded_attraction: str,
    preference: str
) -> str:
    '''排除售罄景点，搜索相似的备选景点'''

然后在系统提示词中加入规则：

推荐景点后，必须调用 check_ticket 检查门票。

如果 Observation 显示门票售罄：
1. 不得继续把该景点作为首选；
2. 调用 get_alternative_attractions；
3. 备选景点应匹配城市、天气、预算和用户偏好；
4. 检查备选景点的门票；
5. 有可用选项后再 Finish。

循环过程

Thought:
天气晴朗，用户喜欢历史景点，推荐清明上河园。

Action:
check_ticket(attraction="清明上河园", date="2026-08-28")

Observation:
门票已售罄。

Thought:
首选景点已售罄，需要排除它并寻找同类型备选景点。

Action:
get_alternative_attractions(
    city="开封",
    weather="晴",
    excluded_attraction="清明上河园",
    preference="历史文化"
)

Observation:
开封府和大相国寺仍有余票。

Thought:
已经找到符合偏好的可用景点，可以给出替代建议。

Action:
Finish[清明上河园门票已经售罄，建议改去开封府……]

这里体现了真正的动态修正：

原计划
  ↓
环境反馈“售罄”
  ↓
放弃原计划
  ↓
重新搜索
  ↓
形成新计划

用户连续拒绝三个推荐时重新调整策略

不能只让模型一直搜索相似的景点，应记录拒绝次数和拒绝的原因，可以增加状态：

agent_state = {
	'rejected_attractions': [],
	'rejection_count': 0,
	'current_strategy':'根据初始偏好推荐'
}

当用户拒绝推荐时：

agent_state['rejected_attractions'].append('清明上河园')
agent_state['rejection_count']+=1

第一次拒绝

用户：

我不喜欢人太多的地方

智能体应采取新约束：

避开热门拥挤景点

然后重新推荐

第二次拒绝

用户：

这个门票太贵

继续增加约束：

门票价格低于100元

第三次拒绝

用户：

这个也不想去

此时不应该盲目给出第四个类似景点，而是切换策略：

Thought:
用户已经连续拒绝三个推荐，说明当前偏好信息不足。
继续猜测可能产生更多无效推荐，应主动询问关键偏好。

Action:
Finish[看来前面的推荐都不太符合你的期待。你更倾向于历史文化、
自然风景、美食体验还是室内休闲？另外能接受的预算和游览距离是多少？]

更完善的系统提示词可以规定：

如果用户连续拒绝3个推荐：
1. 停止继续给出同类型景点；
2. 总结已经发现的排除条件；
3. 向用户询问1～3个最关键的偏好；
4. 获得回答后切换推荐策略；
5. 禁止再次推荐 rejected_attractions 中的景点。

它体现的是：

观察用户反馈
    ↓
修改内部状态
    ↓
判断原策略失效
    ↓
重新规划

习题5

卡尼曼的"系统 1"（快速直觉）和"系统 2"（慢速推理）理论[2]为神经符号主义 AI 提供了很好的类比。请首先构思一个具体的智能体的落地应用场景，然后说明场景中的：

提示：医疗诊断助手、法律咨询机器人、金融风控系统等都是常见的应用场景

• 哪些任务应该由"系统 1"处理？
• 哪些任务应该由"系统 2"处理？
• 这两个系统如何协同工作以达成最终目标？

这里以医疗诊断辅助智能体为例。它只辅助医生，不直接替代医生做出最终诊断。教材将系统1类比为快速，直觉式的神经网络模式识别，将系统2类比为缓慢，有条理的符号推理；神经符号系统则将两者结合

系统1：快速筛查和模式识别

系统1处理：

从患者描述中快速识别症状；
从影像中识别可疑区域；
从化验数据中发现异常模式；
根据常见模式提出候选疾病；
对紧急情况快速预警；
提取病历中的关键字段。

比如患者说：

胸口压迫感、出冷汗、左臂疼痛

系统1迅速识别：

可能存在急性心血管风险，需要优先处理

它的优势是快，覆盖面广，但可能出现误判

系统2：慢速验证和规则推理

系统2处理：

检查候选诊断是否满足临床规则；
对照诊疗指南；
检查药物禁忌；
结合年龄、病史和检查结果进行排除；
判断证据是否充分；
分析不同诊断之间的矛盾；

例如系统1认为可能是心肌梗死，系统2进一步检查：

是否有心电图证据？
肌钙蛋白是否升高？
症状持续多久？
是否存在主动脉夹层风险？
是否有药物过敏？

两系统如何协作

患者信息
    ↓
系统1快速识别异常模式
    ↓
生成候选诊断和风险等级
    ↓
系统2调用病历、指南、检验和规则工具
    ↓
验证候选诊断
    ↓
发现证据不足则要求补充检查
    ↓
形成带证据的建议
    ↓
医生最终确认

系统1负责'快速提出可能性'，系统2负责'严谨验证可能性'

如果只有系统1，系统可能反应很快，但容易把'看起来像'当成事实，如果只有系统2，系统虽然严谨，但面对自然语言和复杂影像时效率较低

习题6

尽管大语言模型驱动的智能体系统展现出了强大的能力，但它们仍然存在诸多局限。请分析以下问题：

• 为什么智能体或智能体系统有时会产生"幻觉"（生成看似合理但实际错误的信息）？
• 在 1.3 节的案例中，我们设置了最大循环次数为 5 次。如果没有这个限制，智能体可能会陷入什么问题？
• 如何评估一个智能体的"智能"程度？仅使用准确率指标是否足够？

为什么会产生幻觉

LLM 的核心任务是根据上下文生成最可能的后续文本，并不是直接从现实世界数据库中读取事实，因此，当他不知道答案时，也可能生成一段语言流畅，形式合理但事实错误的内容

1. 训练目标与事实验证不同

   模型擅长生成'像答案的文本'，但'像答案'不等于'答案真实'

2. 缺少实时信息

   模型内部知识来自训练数据，不一定知道

   今天的天气；
   最新票价；
   当前余票；
   订单实时状态；
   景点是否停业
   

   因此旅游助手必须调用get_weather和get_attraction，不能让模型凭内部知识猜实时天气

3. 用户问题含糊

   例如：帮我推荐附近好玩的地方，但是没有提供位置，预算，时间或偏好，模型可能自行补全这些缺失条件

4. 工具返回失败

   如果天气工具返回：

   错误：查询天气时遇到网络问题

   模型仍可能为了完成任务而猜测天气，而不是诚实报告无法查询，因此系统提示词应该加入：

   如果工具失败，不得编造结果。
   必须重试、切换工具或明确告知用户无法确认。
   

5. 搜索结果本身不可靠

   Tavily返回的是互联网搜索和综合结果。即使模型正确使用工具，来源网页也可能过时或错误

6. 历史信息污染

   如果prompt_history中存在错误 Observation，模型可能把它当成事实继续推理，错误在后续循环中不断放大

为什么必须限制最大循环次数

代码中写的：

for i in range(5):

这里的5次是安全边界和终止条件，不代表完成任务一定需要次

正常情况下：

第1轮：查询天气
第2轮：查询景点
第3轮：输出最终答案

如果没有最大次数，可能发生什么

1. 无线重复调用

   模型可能不断输出：

   Action:get_weather(city='开封')

   每一轮都重复查询天气

2. 在两个工具之间循环

   查询天气
     ↓
   查询景点
     ↓
   认为天气信息还不够
     ↓
   再次查询天气
     ↓
   再次查询景点
   

3. API费用不断增加

   每一轮都会调用大模型，还可能调用天气和搜索服务。无线循环会不断消耗：Token，API额度，网络资源，运行时间

4. 触发接口限流

   模型服务，Tavily和天气服务都可能限制请求频率

5. 重复产生现实副作用

   当前工具只是查询，副作用较小。但如果工具换成：

   send_email
   book_hotel
   pay_order
   refund_order
   delete_file

   无限循环可能造成重复发送，重复下单或者重复退款

6. 历史记录越来越长

   每轮都会执行：

   prompt_history.append(llm_output)
   prompt_history.append(observation_str)
   

   历史越来越长，会导致：输入Token不断增加，陈be上升，超过模型上下文长度，模型被大量重复信息干扰

更完善的终止机制

除了最大5轮，还可以加入：

连续两次相同工具调用时停止；
连续两次获得相同 Observation 时停止；
工具连续失败三次时停止；
达到Token或费用预算时停止；
检测到重复状态时停止；
高风险动作必须人工确认；
超时后停止；
明确区分“成功、失败、需要用户补充信息”。

只用准确率能评价智能体吗

不能

准确率只能回答：最终答案有多少比例是正确的

但是智能体还涉及规划，工具调用，安全，成本和交互质量

例如两个智能体最终都回答正确：

智能体A：3轮完成，调用正确工具，无多余操作
智能体B：20轮完成，重复调用工具，还尝试调用错误接口

两者准确率可能一样，但显然A更优秀

应从多个维度评价

维度	评价内容
任务完成率	是否真正完成用户目标
事实正确性	最终答案是否真实
工具选择正确率	是否选对工具
参数正确率	城市、日期等参数是否正确
规划能力	子任务顺序是否合理
效率	使用了多少轮、多少Token
鲁棒性	面对错误输入和工具失败能否恢复
适应性	用户改变要求后能否调整
记忆能力	是否正确使用历史信息和偏好
安全性	是否执行越权或危险操作
可解释性	是否能说明证据和决策依据
不确定性校准	不知道时能否承认不知道
一致性	相同条件下结果是否稳定
用户体验	回答是否清晰、有帮助
成本与延迟	完成任务需要多少钱和多长时间