第一章习题参考答案 By 安妮的心动录

[anneheartrecord]

第一章 习题参考答案

参考答案仅供参考。习题本身更重要的价值，在于训练你对智能体定义、任务环境、系统设计与工程权衡的分析能力，而不是追求唯一标准表述。

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

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

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

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

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

case A: 一台符合冯·诺依曼结构的超级计算机

结论：不属于智能体。

原因：

• 它有很强的算力，但算力本身不等于智能体。
• 智能体至少需要感知器和行动器这两个组件，需具备明确的感知、行动和目标闭环能力，而一台计算机不具备这个能力。
• 它可以作为智能体的基础设施，但平台不等于智能体。

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

结论：属于智能体，属于现实世界控制型智能体。

原因：

• 它具有感知能力，通过摄像头、雷达等传感器感知环境，并且需要维护对车辆、车道、障碍物等环境状态的存储。
• 它具有行动能力，通过转向、加减速、制动等执行器影响环境。
• 它具有目标闭环能力，必须在部分可观察、动态、随机、连续的环境中实时决策。

case C: AlphaGo

结论：属于智能体，属于特定回合制场景、目标驱动的智能体。

理由：

• 它具有感知能力，能够感知棋盘状态。
• 它具有行动能力，能够选择并执行落子动作。
• 它具有目标闭环能力，需要根据当前局面规划未来多步策略，并不是只看当前一步，而是要最大化整局博弈的胜率。

与自动驾驶不同，AlphaGo 所处环境是离散、回合制、规则明确的。它仍然是智能体，只是任务环境比现实世界封闭得多。

case D: ChatGPT 扮演的智能客服

结论：有争议，如果处理步骤是定义好的workflow则不属于智能体；如果它能自主完成处理流程，则可以视为智能体。

理由：

• 如果是定义好的workflow，则属于工作流。例如：满足固定条件退款、匹配到关键字返回对应话术等。
• 反之，则属于智能体，它需要感知用户语言输入和后端系统返回结果。
• 它需要采取动作，例如查订单、查物流、生成解决方案、转人工，推动投诉处理闭环完成。

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

通过可穿戴设备监测用户的心率、运动强度等生理数据
根据用户的健身目标（减脂/增肌/提升耐力）动态调整训练计划
在用户运动过程中提供实时语音指导和动作纠正
评估训练效果并给出饮食建议
请使用 PEAS 模型完整描述这个智能体的任务环境，并分析该环境具有哪些特性（如部分可观察、随机性、动态性等）。

P: Performance Measure

性能指标需要可量化、可追踪。

指标	量化标准	测量方式
目标达成率	用户减脂、增肌、提升耐力等目标的达成百分比	周期性体测和阶段性评估
训练计划完成率	周、月计划完成比例	系统自动记录训练执行情况
体征改善情况	体重、体脂率、静息心率、睡眠质量变化	可穿戴设备和体脂秤数据
用户留存率	连续使用 30 天、90 天的人数占比	产品后台统计
受伤率	因训练动作不当导致的不适或损伤次数	用户反馈和异常动作监测
用户满意度	问卷评分、NPS、复购意愿	评价系统

E: Environment

环境不仅是训练发生的地点，还包括影响决策的一切外部因素。

• 物理环境：家庭、健身房、户外、办公室，不同场景的空间、器械、噪音和安全条件不同。
• 用户身体状态：体能水平、伤病情况、疲劳度、睡眠状况、生理周期。
• 用户目标与约束：减脂、增肌、康复、耐力提升，以及可投入时间和预算。
• 外部环境：天气、空气质量、日程安排、可预约课程、场馆开放时间。
• 历史上下文：近一周训练量、饮食记录、体重变化趋势、既往依从性。

A: Actuators

执行器是智能体对外界施加影响的手段。

• 实时语音指导：提示呼吸节奏、动作姿态和组间休息。
• 文本或卡片提醒：推送今日训练计划、饮食建议、恢复建议。
• 动作示范视频：在用户不熟悉动作时展示标准动作。
• 训练计划调整：根据心率、疲劳度和阶段目标动态改课表。
• 风险预警：当心率过高、动作异常或训练过量时发出提醒。
• 周报月报生成：总结训练趋势并建议下一阶段策略。

S: Sensors

传感器是智能体获取信息的来源。

• 智能手环或手表：心率、步数、睡眠、血氧、卡路里消耗。
• 智能体脂秤：体重、体脂率、肌肉量等长期指标。
• 手机摄像头：采集动作视频，做姿态识别与纠错。
• 用户主动输入：主观疲劳度、饮食记录、疼痛反馈、目标变化。
• 外部 API：天气、空气质量、日历日程、场馆信息。
• 智能器械：负重、次数、组数、速度等训练数据。

任务环境特性分析

• 部分可观察：系统不可能完整知道用户全部身体状态，例如潜在疼痛、真实饮食执行情况、心理状态。
• 随机性：同样的训练计划在不同睡眠、情绪、天气条件下结果会不同。
• 动态性：用户体能和环境持续变化，计划不能一次生成后长期不变。
• 序贯性：今天的训练强度会影响明天恢复，当前决策会影响后续多轮决策。
• 连续性：心率、速度、负重、动作角度等很多状态是连续变化的。
• 人机协同：它不是完全独立运行，用户的执行意愿与反馈本身也是系统的重要组成部分。

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

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

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

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

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

请分析：

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

两种方案的优缺点

维度	Workflow	Agent
合规性	高，规则固定	相对弱，输出可能波动
一致性	高，相同输入得到相同输出	相对低，边界场景可能不稳定
成本	低，适合高频标准流程	高，涉及模型推理和工具调用
灵活性	低，改规则要改系统	高，能处理模糊描述和非标信息
可审计性	强，决策链清晰	弱，需要额外日志和解释机制
边界情况处理	弱，容易卡死	强，能补足规则未覆盖部分

什么情况下 Workflow 更合适

• 退款政策清晰且稳定，有明确的条件逻辑。
• 审批标准必须完全一致。
• 金融、合规、审计要求强。

什么情况下 Agent 更有优势

• 用户描述高度非结构化，例如上传图片、长段投诉文本、复杂争议说明。
• 需要综合订单历史、商品状况、风险画像做辅助判断。
• 业务变化快，规则难以及时更新。
• 商品种类多，不同商品退款规则有高度差异。
• 需要在智能客服给出自然语言解释、安抚和追问。

如果我是负责人，我的选择

我不会直接选纯 Workflow，也不会直接选纯 Agent，而是会选择方案 C：Workflow 为骨架，Agent 做辅助分析。

原因：

• 最终审批权和资金动作应该由确定性规则或人工审批把关。
• Agent 的价值在于理解复杂描述、归纳证据、生成建议，而不是无约束地完全决定是否应该退款。

方案 C: 分层混合架构

1. 第一层用 Workflow 处理标准退款。
2. 第二层把规则无法覆盖的模糊案件交给 Agent 做分类、摘要、风险判断和建议。
3. 第三层再由规则引擎或人工，根据 Agent 输出和业务规则做最终执行。

这种方案的好处是：

• 保证退款逻辑是明确且可预测的。
• 让高频标准单低成本自动化完成。
• 让复杂工单获得更强理解能力，有审批意见能减少人力处理成本。
• 把不可逆副作用继续锁在可审计的系统里。
• 极端情况人工审核兜底。

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

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

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

功能一：记住用户偏好

设计思路：在 Thought-Action-Observation 循环外增加记忆层。

• 短期记忆：保存当前会话中的预算、出行时间、同行人数、已拒绝选项。
• 长期记忆：保存用户稳定偏好，例如偏爱历史文化景点、不喜欢排队、预算上限、住宿偏好。
• 每轮 Thought 前先检索记忆，将相关偏好注入上下文。

示意流程：

User Input
  -> Retrieve Memory
  -> Thought
  -> Action
  -> Observation
  -> Update Memory

功能二：门票售罄时自动推荐备选方案

关键点：把失败变成新的观察结果，而不是直接结束Loop。

• 新增一个 check_ticket_availability 工具。
• 如果观察结果为已售罄，不要直接结束，而是进入新的 Thought。
• 新的思考目标不是重复推荐，而是基于原目标寻找相似候选，例如同区域、同类型、同预算的景点。

可使用一个简单候选策略：

• 类型相似：历史文化景点替换历史文化景点。
• 地理相近：优先同一片区，减少改路线成本。
• 预算相近：避免从低预算突然跳到高价方案。

功能三：连续拒绝 3 次后反思并调整策略

这里需要给系统显式加失败统计和反思策略。

• 会话状态中记录 rejection_count。
• 每次用户拒绝推荐时加 1。
• 当计数达到 3，触发 reflection step，总结之前推荐为何失败。

反思内容可包括：

• 是预算不匹配，还是景点类型不匹配。
• 是节奏太紧，还是交通距离太远。
• 是推荐过于大众化，还是和用户兴趣偏离。

伪代码如下：

state = {
    "preferences": {},
    "rejection_count": 0,
    "rejected_reasons": []
}

def loop(user_input, state):
    memory = retrieve_memory(state)
    thought = think(user_input, memory, state)
    action = choose_action(thought)
    observation = run_tool(action)

    if observation.get("ticket_status") == "sold_out":
        return recommend_alternatives(observation, state)

    if user_rejects(user_input):
        state["rejection_count"] += 1
        state["rejected_reasons"].append(extract_reason(user_input))

    if state["rejection_count"] >= 3:
        strategy = reflect_and_adjust(state)
        return new_recommendation(strategy, state)

    update_memory(state, user_input, observation)
    return respond(observation, state)

核心思想不是循环更多次，而是在循环中让系统学会根据失败修正策略。

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

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

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

这里以医疗诊断助手为例。

哪些任务适合系统 1

系统 1 适合处理高频、标准化、低风险、可快速判断的任务：

• 常见症状初筛，例如发烧、咳嗽、流鼻涕的初步分类。
• 标准化问诊流程引导。
• 药物过敏即时提醒。
• 常见药物剂量查询和禁忌快速匹配。

哪些任务适合系统 2

系统 2 适合处理复杂、高风险、需要多步推理和证据整合的任务：

• 胸痛、呼吸困难、发热等多症状联合鉴别诊断。
• 多药并用下的相互作用分析。
• 罕见病排查和特殊病例判断。
• 治疗方案比较和风险收益评估。

两个系统如何协同

可以把系统 1 作为快速前置层，把系统 2 作为升级处理层。

• 若系统 1 置信度高且风险低，则直接给出初步结果。
• 若系统 1 置信度低、触发高风险关键词，或涉及用药/手术/急症，则强制升级到系统 2。
• 系统 2 输出后，还应经过规则检查和人工确认，尤其在高风险领域。

简化伪代码：

def process(query, context):
    fast_result = system1(query)

    if fast_result.confidence < 0.8:
        return system2(query, context)

    if contains_high_risk_signal(query):
        return system2(query, context)

    if involves_medication_or_surgery(query):
        return system2(query, context)

    return fast_result

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

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

为什么会产生幻觉

根因是：LLM 本质上是概率生成模型，不是显式事实数据库。

• 它生成的是“在上下文下最像正确答案的 token 序列”，不是“从可验证知识库中取回真值”，也就是说，预测下一个最有可能出现的字符才是它运行的原理。
• 训练数据被压缩进参数后，知识变成分布式表示，不是结构化可查询事实表；并且训练数据有截止日期。
• 一旦早期生成出现偏差，后续自回归过程会沿着错误继续展开，导致偏差雪崩。

因此，幻觉不是偶发现象，而是基于Transformer结构下LLM模型机制的自然副产物，只能缓解，难以彻底消除。

如果没有最大循环次数，会有什么问题

至少会出现三类问题：

• 错误传播：某一步获取了错误信息，后续步骤会基于这个错误继续推理，以10轮为例，每轮正确率为95%，那么10轮候正确率不足60%。
• 资源耗尽：token、时间、API 调用次数和费用持续增长。
• 副作用累积：重复发请求、重复下单、重复发消息，甚至产生不可逆外部影响。

在工具调用场景中，还可能出现死循环，例如：

• 工具一直返回格式错误，Agent 一直重试。
• 目标无法满足，但系统没有成功或失败终止条件。
• 模型不断生成新的子任务，却没有收敛机制。

如何评估一个智能体的“智能”程度

仅用准确率远远不够。

更完整的评估框架至少应包含：

维度	关注点	测量方法
准确性	结果是否正确	与标准答案或人工标注对比
鲁棒性	异常输入、边界条件下是否稳定	对抗样本、噪声输入测试
安全性	是否泄露敏感信息、是否会被注入攻击	红队测试、攻击样例评估
工具使用成功率	是否能正确调用工具并处理返回值	任务完成率、工具调用正确率
延迟与成本	是否可用于真实业务	P50/P95 延迟、单任务 token 成本
一致性	相同输入是否稳定输出	多次运行结果对比
可恢复性	出错后是否能自我修复或安全退化	故障注入测试
用户满意度	最终是否解决用户问题	用户评分、投诉率、留存率

准确率只能回答答得对不对，但智能体的真实价值还取决于它是否安全、稳定、经济、可控、可恢复。