hello-agents/

[giscus[bot]]

hello-agents/

Description

https://datawhalechina.github.io/hello-agents/

[jjyaoao]

Hello, thank you for learning HelloAgents. The discussion forum is specifically for discussing the exercises after class. If you have any insights, please feel free to share them here!

[Tasselszcx]

习题1：
Case A：一台符合冯·诺依曼结构的超级计算机，拥有高达每秒 2EFlop 的峰值算力
是否属于智能体：否。

理由：
自主性：该超级计算机没有自主决策能力，它仅仅是一个计算工具，需要外部指令（如程序或用户输入）才能运行。它无法主动发起行动或调整目标。
反应性：它无法实时感知环境变化并做出响应，只能根据预定义的代码执行计算任务。
主动性：它没有内在目标或动机，无法主动规划或追求目标。
社交能力：它无法与其他智能体或人类进行交互或通信。
学习能力：尽管算力强大，但它本身不具备从经验中学习或改进的能力，除非搭载特定的机器学习算法。
理性：它无法评估决策效果或优化行为，只能机械地执行计算。

总结：该超级计算机更接近于一种资源或平台，而非智能体。它缺乏智能体的核心特征，如感知-决策-行动循环。

[hopestar]

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

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

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

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

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

请分析：

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

1. 有标准化流程的用工作流。 其它的可以用agent。
2. 这里有标准流程，倾向于A
3. 结合方案。可以先让agent判断是否需要退款，对需要退款的case再让人工介入审核，减少人工工作量。

[WensingDing]

提示工程（Prompt Engineering），指令模版中，缺少了Observation，但是后续的代码出现了，加上可能效果会更好；但是也不排除现在大模型已经在前置内部提示中，内置Observation的可能？

[jjyaoao]

Observation就是指我们外界给他传入的信息，他获取到的过程已经是Observation了

[WensingDing]

作者您好。明白你的意思。每次调用llm.generate(full_prompt, system_prompt=AGENT_SYSTEM_PROMPT)时，传入的full_prompt就是包含Thought，Action，Observation的信息，我们每次拼接full_prompt时，TAO都拼进去了，但提示工程中只提到了要输出T和A的格式和位置，需不需要再加上根据O（明确告诉Observation这个名字，和格式，模版位置），让输入的模型明确知道Observation的含义。猜测可能现在模型是本身就知道TAO，所以根据T和A预判了full_prompt中Observation的含义？

[jjyaoao]

能把具体的位置告诉我吗，我去看看，建议在issue里讨论，discussion是用来讨论课后习题的哈

[WensingDing]

思维链（Chain-of-Thought）推理：通过引导模型在回答复杂问题前，先输出一步步的推理过程，可以显著提升其在逻辑、算术和常识推理任务上的准确性。
推测可以理解为，大模型本身拥有的上下文连贯逻辑能力，在输出思维链的情况下，整个输出被拉长，长输出的情况下仍然能保持逻辑连贯，同时能自己补充未知信息，最终增加准确性，看起来就像人类的思维推测一样。也是一种有效减少幻觉的方法，本质上是用算力（能源）获取信息的准确度，因为拉长输出的情况下，思考的时间也变长了。信息准确也是一种墒减，花费更多的能源，获取局部环境中更多的墒减，像是这样一种情况。这类似于问人类一个问题，是根据瞬时条件无脑回答，还是深思熟虑谨慎回答一样。但是人类的深思熟虑，类似于前文的Thought-Action-Observation范式，会反复的获取脑海中历史经验，或者从现实世界获得新的经验，来进行思考，目前的各类应用的“深度思考”，看起来好像只是一直在历史记忆中寻找答案，如果能在“深度思考”的同时继续做TAO，从互联网查阅资料（而不是仅最开始获取一次），可能效果会更好（可能目前其实已经这样做了）。综上，如果仅仅是完全基于历史记忆的“思维链推理”，就类似于人仅根据历史经验的细细揣摩，还可以继续提升。

[Starfychen]

代码示例的提示词工程里，Action的这个例子感觉会让有的模型产生我一定要调用一个tool的幻觉，导致陷入无限循环。是不是在Action里加上如何finish更好，逻辑链更连贯。

[jmb0217]

yes

[octopus117]

分析电商公司采用什么流程，涵盖业务 技术和风险维度。
假设电商公司处于初期阶段，公司资源有限技术弱/功能需要快速上线/商品类型标准化/对损失敏感等，优先用workflow确保基本运营同时积累数据。
假设公司处于高速发展，有一定的数据和技术，可以逐步实施，workflow持续收集数据，引入agent处理复杂的案例，设置人工复核降低风险。

[WensingDing]

干货满满，追求极致正确的情况下，甚至可以高层Plan-and-Solve + 底层ReAct，最后设定特定条件下触发Reflection反思，通过用大量的算力换取准确性能提升？

[RavenCaffeine]

Case A：符合冯・诺依曼结构的超级计算机（非智能体）
缺乏传感器感知环境（无法主动获取外部动态信息）、执行器作用于环境（无法自主采取行动改变外部状态）及目标导向的自主性（需依赖人类输入指令，无独立决策能力）

Case B：特斯拉自动驾驶系统（是智能体）混合式智能体
分类维度 1：时间与反应性：混合式智能体）理由：需在毫秒级响应障碍物（即时决策，无长远规划），决策延迟极低，符合反应式智能体 “快速响应、无复杂规划” 的特征，适用于动态环境（高速公路）的紧急场景。
同时，自动导航也满足规划式智能体，自动导航行驶过程中还需要及时反应
分类维度 2：内部决策架构：基于模型的反射智能体理由：通过摄像头、雷达（传感器）感知环境后，依赖内部 “世界模型”（如道路规则、障碍物运动轨迹预测模型）追踪环境状态（如障碍物位置），而非仅依赖瞬时感知，符合 “模型驱动反射” 的逻辑。

Case C：AlphaGo（是智能体）
分类维度 1：时间与反应性：规划式智能体理由：需评估当前棋盘局面并规划未来数十步策略（深思熟虑后行动），决策聚焦 “长远最优解”，符合规划式智能体 “基于内部模型探索未来可能性” 的特征（文档 1-142）。
分类维度 2：内部决策架构：基于效用的学习型智能体理由：目标是 “最大化赢棋概率”（效用最大化），且通过强化学习（自我对弈）自主优化策略（学习元件修正性能元件），符合 “效用驱动 + 自主学习” 的架构。
分类维度 3：知识表示：神经符号混合主义理由：核心是神经网络（亚符号，学习棋谱模式），但需遵循围棋规则（符号，如落子位置合法性），实现 “直觉（模式识别）+ 理性（规则约束）” 的融合。

Case D：ChatGPT 扮演的智能客服（是智能体）
分类维度 1：时间与反应性：混合式智能体理由：需实时响应用户投诉（反应性，如即时安抚情绪），同时规划多步骤任务（规划性，如 “查询订单→分析原因→提供方案”），符合 “反应 + 规划平衡” 的混合模式。
分类维度 2：内部决策架构：基于目标的智能体理由：核心目标是 “解决用户投诉”，需主动分解目标为子任务（查询订单、分析问题），并选择行动达成目标，符合 “主动规划导向目标” 的特征。

[Liuhb1024]

Case A：冯·诺依曼架构超级计算机

判断：不属于智能体

理由：

• 缺乏自主性：仅提供计算能力，需要外部程序指令才能运作
• 无感知能力：没有传感器获取环境信息
• 无目标导向：本身不具备目标，只是执行工具
• 类比：就像一个强大的"计算器"，算力≠智能

---

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

判断：属于智能体 ✓

类型分析：

从自主性维度

• 反应式智能体（Reactive Agent）
  • 直接的感知-行动映射
  • 毫秒级响应，无复杂推理过程
  • 基于当前传感器数据即时决策

从环境交互维度

• 具身智能体（Embodied Agent）
  • 物理世界中的实体系统
  • 通过摄像头、雷达、激光雷达感知
  • 通过制动/转向系统执行动作

从应用场景维度

• 专用智能体（Task-specific Agent）
  • 专注于驾驶任务
  • 功能边界明确

核心特征：

• ✓ 感知：多传感器融合
• ✓ 决策：障碍物检测→风险评估→动作选择
• ✓ 执行：物理控制车辆
• ✓ 实时性：安全关键系统

---

Case C：AlphaGo

判断：属于智能体 ✓

类型分析：

从认知能力维度

• 深思熟虑型智能体（Deliberative Agent）
  • 内部状态建模（棋盘局面）
  • 长期规划（数十步推演）
  • 目标导向（追求胜利）

从决策机制维度

• 基于模型的智能体（Model-based Agent）
  • 使用价值网络和策略网络
  • 通过蒙特卡洛树搜索模拟未来
  • 评估-规划-执行循环

从学习能力维度

• 学习型智能体（Learning Agent）
  • 通过自我对弈改进策略
  • 强化学习优化决策

从应用场景维度

• 游戏智能体（Game Agent）
  • 完全信息博弈环境
  • 离散状态空间
  • 明确的胜负目标

核心特征：

• ✓ 感知：棋盘状态识别
• ✓ 推理：复杂的前瞻性规划
• ✓ 决策：策略优化
• ✓ 学习：持续进化

---

Case D：ChatGPT智能客服

判断：属于智能体 ✓

类型分析：

从架构维度

• 混合型智能体（Hybrid Agent）
  • 反应式：快速理解用户意图
  • 深思熟虑：制定多步骤解决方案
  • 结合规则（查询流程）和学习（语言理解）

从能力维度

• 认知智能体（Cognitive Agent）
  • 自然语言理解与生成
  • 多任务处理（查询+分析+安抚）
  • 上下文维护（对话连贯性）

从交互维度

• 对话式智能体（Conversational Agent）
  • 多轮交互能力
  • 情感识别与表达
  • 动态调整沟通策略

从功能集成维度

• 工具使用型智能体（Tool-using Agent）
  • 调用外部API（订单查询系统）
  • 集成多个功能模块
  • 工作流编排

核心特征：

• ✓ 感知：理解用户文本、情绪
• ✓ 推理：问题分析、方案生成
• ✓ 执行：信息检索、回复生成
• ✓ 社交智能：情绪管理、说服能力

---

对比总结表

维度	Case A	Case B	Case C	Case D
是否为智能体	✗	✓	✓	✓
自主性	无	高	高	中
感知能力	无	物理传感器	棋盘状态	文本/情感
决策复杂度	N/A	低（反应式）	高（规划式）	中-高（混合）
学习能力	无	有限	强	强
环境类型	N/A	物理连续	离散确定	社交开放

关键区分点： 智能体的本质是"感知-决策-行动"的自主循环，而非单纯的计算能力。

[Liuhb1024]

一、PEAS 模型

P - Performance Measure (性能度量)

核心指标

• 目标达成：体脂率/肌肉量/VO2max变化
• 安全性：运动损伤率（目标=0）、过度训练预警准确率
• 依从性：训练完成率、用户留存率
• 效率：单位时间效果、目标达成周期

---

E - Environment (环境)

物理环境

• 训练场所（家庭/健身房/户外）
• 器械条件、空间限制

生理环境

• 实时数据：心率、血氧、运动强度、体温
• 基础特征：年龄、BMI、体脂率、健康史

行为环境

• 运动状态：动作姿态、速度、休息时间
• 生活数据：睡眠、饮食、压力、月经周期

---

A - Actuators (执行器)

1. 训练调整：动作选择、强度/组数/休息设定
2. 实时指导：
   • 语音（指令、激励、倒计时）
   • 视觉（心率区间、AR姿态线）
   • 触觉（手环震动提醒）
3. 动作纠正：识别错误姿态并给出纠正指令
4. 营养建议：热量目标、营养配比、进食时机
5. 恢复管理：休息日安排、拉伸方案

---

S - Sensors (传感器)

硬件传感器

• 可穿戴：心率、加速度、体脂、GPS
• 视觉：摄像头（姿态）、深度相机（3D骨骼）
• 器械：跑步机速度、力量器械负重

用户输入

• 主观疲劳度(RPE)、肌肉酸痛标注
• 饮食日志、睡眠数据

历史数据

• 训练记录、身体成分趋势、表现曲线

---

二、环境特性分析

1. 部分可观察 (Partially Observable) ★★★★☆

• ✓ 可观察：心率、步数、动作视频
• ✗ 不可观察：肌肉微损伤、神经疲劳、真实饮食、深度睡眠质量
• 应对：多源数据融合、概率模型估计隐藏状态

2. 单智能体 (Single Agent) ★☆☆☆☆

• 一对一服务
• 可扩展：多用户组队训练场景

3. 随机性 (Stochastic) ★★★★☆

随机源	表现
生理波动	同样训练不同天效果差异大
突发伤病	肌肉拉伤、关节不适
依从性	用户情绪/动机波动
环境干扰	器械被占用
测量误差	传感器噪声

4. 序列化 (Sequential) ★★★★★

• 强时间依赖：今日训练→明日恢复→下周能力
• 延迟奖励：减脂效果需数周显现
• 需维护长期状态记忆

5. 动态环境 (Dynamic) ★★★★☆

• 慢变化（周）：体重、肌肉力量、心肺能力
• 中速变化（天）：疲劳恢复、糖原储备、肌肉酸痛
• 快变化（分钟）：心率、血糖、体温
• 挑战：即使不行动，用户状态也在演变

6. 混合型 (Continuous & Discrete) ★★★☆☆

• 连续：心率(60-200)、体重、关节角度
• 离散：动作类型{深蹲/硬拉/卧推}、强度{低/中/高}

7. 部分已知 (Partially Known) ★★★☆☆

• ✓ 已知：运动生理学原理、力学标准、营养学基础
• ✗ 未知：个体差异精确模型、心理-生理耦合
• 应对：模型驱动+数据驱动混合、在线学习个性化参数

---

三、综合对比

特性	智能健身教练	特斯拉自驾	AlphaGo	ChatGPT客服
实时性	中(秒级)	极高(毫秒)	中(秒)	低
物理风险	中	高	无	无
规划周期	长(数月)	短	中	短
个性化	极高	低	无	中
多模态	语音+视觉+触觉	单向	单向	文本

综合复杂度：★★★★☆ (高度复杂)

[Liuhb1024]

一、两种方案对比分析

方案 A：Workflow（工作流）

优点 ✓

1. 高度可预测性

   • 相同条件必然得到相同结果
   • 便于向用户解释决策（"根据第X条规则"）

2. 易于审计与合规

   • 每个决策路径清晰可追溯
   • 符合财务审计要求
   • 责任归属明确

3. 低成本低风险

   • 无需AI训练，开发周期短
   • 不会出现"意外决策"
   • 维护成本低（修改规则即可）

4. 性能稳定

   • 响应时间恒定（毫秒级）
   • 不依赖模型推理
   • 不会因数据漂移失效

5. 易于理解和操作

   • 客服人员培训成本低
   • 规则透明，内部共识容易达成

缺点 ✗

1. 僵化缺乏灵活性

   • 无法处理规则未覆盖的边缘案例
   • 例：用户买错尺码但超过7天，严格执行可能损失忠诚客户

2. 规则爆炸问题

   • 随着业务复杂度增加，规则数量指数增长
   • 规则间可能产生冲突或漏洞

3. 无法综合考量复杂因素

   • 不能评估："这是VIP客户第一次退款"
   • 不能识别："商品质量问题导致的集中退款"

4. 适应性差

   • 市场策略调整需手动修改规则
   • 无法从历史数据中学习优化

5. 容易被恶意利用

   • 羊毛党研究规则漏洞
   • 例：连续购买99元商品后退款（自动通过阈值）

---

方案 B：Agent（智能体）

优点 ✓

1. 高度灵活性

   • 能综合多维信息：用户信用、历史订单、商品状况、季节因素等
   • 适应复杂场景："虽然超过7天，但用户首次购买+物流延误"

2. 持续学习优化

   • 从历史决策中学习最优策略
   • 自动发现新的欺诈模式

3. 个性化决策

   • 对高价值客户适当放宽
   • 对异常账户严格审查

4. 处理能力强

   • 能理解自然语言退款理由
   • 识别图片中的商品瑕疵

5. 业务洞察

   • 发现退款模式（某批次商品质量问题）
   • 预测退款率趋势

缺点 ✗

1. 黑盒问题

   • 决策逻辑难以解释（"为什么我的被拒了？"）
   • 可能导致用户不满和法律风险

2. 不可预测性

   • 相似案例可能得到不同结果
   • 可能做出违背公司政策的决策

3. 高成本高风险

   • 开发周期长（数据标注、模型训练）
   • 需持续投入（监控、迭代）
   • 可能出现灾难性错误（批量误判）

4. 合规挑战

   • 金融审计困难
   • 可能存在算法歧视（对某类用户系统性偏见）

5. 依赖数据质量

   • 训练数据偏差导致模型偏差
   • 新业务场景缺乏历史数据

6. 技术门槛

   • 需专业AI团队
   • 客服人员难以理解系统逻辑

---

二、适用场景分析

Workflow 更合适的场景

场景特征	具体说明	案例
规则清晰简单	决策逻辑可穷举	标准化商品的7天无理由退换
高合规要求	需严格审计追溯	涉及税务、发票的退款
低频高额交易	风险大需人工兜底	奢侈品、大宗采购
初创或小规模	订单量<1000/天	创业公司早期
用户期望明确	政策公开透明	"7天无理由"法律要求
稳定业务	政策长期不变	成熟品类（图书、标品）

典型案例：京东"211限时达"退款 —— 规则明确，时效要求高，workflow 响应快

---

Agent 更有优势的场景

场景特征	具体说明	案例
高复杂度	需综合多因素决策	跨境电商（关税、物流、汇率）
大规模高频	订单量>10万/天	双11期间退款洪峰
个性化需求	不同用户差异化对待	会员分级服务
欺诈高发	需智能风控	虚拟商品（游戏点卡）退款
动态环境	政策频繁调整	新兴市场、促销季
NLP需求	需理解非结构化数据	分析用户退款理由文本

典型案例：淘宝"小蜜"客服 —— 处理海量咨询，需理解语义并个性化响应

---

三、决策建议（负责人视角）

我的选择：阶段性策略

第一阶段（0-6个月）：Workflow 为主

理由：

• 快速上线验证业务模式
• 积累数据（用户行为、退款原因、决策结果）
• 建立基准指标（退款率、处理时长、用户满意度）

配置：

├─ 自动通过：<100元 + 7天内 + 一般商品
├─ 客服审核：100-500元 或 7-15天
├─ 主管审批：>500元 或 特殊商品 或 异常账户

第二阶段（6-18个月）：Workflow + Agent 辅助

• Workflow 保持主流程
• Agent 辅助功能：
  • 风险评分：为每个申请生成风险等级（低/中/高）
  • 推荐理由提取：自动总结用户退款描述
  • 相似案例检索：帮助客服参考历史决策

价值：

• 提升客服效率（处理时长-30%）
• 降低误判率（Agent发现规则未覆盖的合理退款）
• 积累Agent训练数据

第三阶段（18个月后）：混合架构（方案C）

• 见下一节详细设计

---

四、方案 C：混合架构设计

核心思想：分层决策 + 人机协同

退款申请
    ↓
【规则层】快速筛选
    ├─ 明确通过 → 自动批准 (40%)
    ├─ 明确拒绝 → 自动驳回 + 解释 (10%)
    └─ 模糊地带 → 进入智能层
         ↓
【智能层】Agent 分析
    ├─ 高信心决策 → 自动处理 (30%)
    ├─ 中等信心 → 推荐+解释 → 客服快速确认 (15%)
    └─ 低信心/高风险 → 升级人工 (5%)
         ↓
【人工层】专家决策
    └─ 复杂案例 + 持续反馈训练 Agent

---

详细设计

1. 规则层（Workflow）

职责：处理简单明确案例（~50%订单）

优势：

• 低成本高效处理大部分常规案例
• 保持政策透明性和可解释性

---

2. 智能层（Agent）

职责：综合分析复杂案例（~45%订单）

输入特征：

{
    "订单信息": {金额, 商品类型, 购买时间},
    "用户画像": {信用分, 历史订单数, 退款率, 会员等级},
    "退款详情": {申请时间, 退款原因(NLP), 图片证据},
    "商品状态": {质量评分, 近期退款率, 库存},
    "上下文": {节日促销, 物流异常, 同批次问题}
}

决策输出：

{
    "决策": "批准/拒绝/不确定",
    "信心分数": 0.92,
    "关键因素": ["用户首次退款", "物流超时7天", "高价值客户"],
    "建议操作": "批准并赠送50元券安抚"
}

分流逻辑：

• 信心>0.85 → 自动执行
• 0.6<信心<0.85 → 推荐给客服（"建议批准，因为..."）
• 信心<0.6 → 升级人工

---

3. 人工层（Human-in-the-loop）

职责：处理边缘案例（~5%）+ 监督学习

工作流：

1. 客服/主管处理复杂案例
2. 标注Agent决策是否正确
3. 定期审查Agent自动决策样本
4. 反馈数据用于模型再训练

案例库建设

---

混合架构的优势

维度	效果
效率	自动化率85%（规则40% + Agent 45%）
准确性	规则保底 + Agent提升 + 人工兜底
可解释性	规则透明 + Agent输出关键因素
灵活性	Agent处理长尾案例
成本	人工仅处理5%复杂案例
风险可控	高风险强制人工审核
持续改进	人工反馈→Agent学习

[FrankWang307]

1、caseA不是 caseB是反应性智能体 caseC是规划智能体 caseD是混合式智能体
2、Performance：心率、运动强度 Environment：动作监控 Actuators：动作指导&饮食效应 Sensors：饮食习惯&动作
3、A方案不考虑商品原始价值，可能存在多付导致公司损失或者少付导致用户不满的情况；B方案比较灵活，会结合用户历史行为、相关政策、商品信息给出一个合理的解决方案，但可能会需要人力介入复合；设计合理的B方案我觉得更优，相对来说用户体验会更好。
4、增加用户偏好的tool，是否有余票的tool，react自动观测推理下一步动作；按照用户 query 和 系统answer的逻辑记录对话历史并持续代入最新的交互上下文中，调整系统提示词，限定三次拒绝后重新规划推理路径
5、员工报销场景：系统1：查询报销单信息，无需经过规划思考可直接查询 系统2：按照上传的发票以及语义需要匹配是否执行创单指令或者更新指令或者问题反馈等指令；通过multiagent设计将意图理解和多种报销类型的agent进行拆分设计，最终顺利帮助用户自动创单
6、幻觉的原因可能是训练数据的错误、提示词的引导错误等因素；可能会在某个环境信息无法获取的时候进入死循环；场景覆盖度和准确性可能需要综合评估，结合场景可能还需要评估效率的导向。

[wtn98498]

1：
A.冯诺伊曼计算机：不属于智能体（只是台计算机
B.tesla自动驾驶系统：反应式智能体（快速，简单反应
C.Alphago：规划式智能体（自己规划很久最优解
D.智能客服：混合式智能体
2：
p:根据用户心率等身体信息调节运动强度，用户健身目标动态调节计划
e：天气（户外运动，保温），运动手表api 传入用户数据，饮食时拍照计算卡路里
a：llm 模型，生成食谱，训练计划
s：运动手表传入的运动数据读取，拍摄食材时的照片解析
环境特性：可读取数据很多，用户的身高，体重，心率，运动姿态等，随机性则是用户的运动心情（今天心情不好不想练，或者练轻松点），或者天气不好不能户外运动，动态性，用户身材每天变化，或者锻炼后身体更好，计划的运动强度可以更高
3：
1）a 方案更严谨，不会出错，但是没有通融性，比如特殊商品一律退款，或许有特殊情况呢，b 则是比较自由，但是 ai 可能会幻觉或出问题，比如一点小钱，ai 和客户会扯皮很久
2）你的货物是没有特殊物品的话，的确 workflow 更好，不需要扯皮，什么金额什么人物指定，但如果你的客户消费大多在 100-500 或大多是 500 以上的，客服和主管会很忙，b 的话节约人力成本，但金额重大时，ai 的决策责任谁来承担？我的话都得依据我卖什么来选择
3）方案 c，智能体工作流，依据商品，政策等，让 ai 分工，这些退款让谁负责，然后一定金额时，让主管或者客服介入，然后 ai 会辅助他们了解情况
4：
1）这些写入 md 文件中，作为后续思考的参考
2）接入旅游景点的 api（或者爬虫），看看规划的日期内
是否有票，然后根据票数多少（和往年这个时候情况）来让 ai 判断，如果票很畅销，那就生成备选
3）写死一个判断，如果思考次数过多（调度过多）说明客户很不满意llm 目前的思考（上下文已经影响了），要么开新的 llm 思考（当然有上一次对话的好的上下文）或者引入惩罚
5：车机
快速直觉：紧急避险，预测超车，过隧道自动调速
慢速推理：选择不塞车的路线，要路过某个地方，最优路径选择
最终目标，就是安全，快速的到达目的地
6：1）错误的上下文，然后为了讨好用户编造信息（没有惩罚）
2）可能会“钻牛角尖” agent 在细枝末节一直追究，不符合用户大体目标
3）用户评价（部分 llm 官方会有评分系统，看你是否满意回答）或者 ai 代码助手，看你是否接受 ai 改动代码，准确率是不够的，有时候就是要天马行空的想法

[InTheFuture7]

第三章

问题

上下文示例 (In-context Example) 与少样本提示有什么联系和区别？

---

习题

1.1. P(agent works)=P(agent)P(works|agent)=(2/6)(1/2)=1/6
1.2. 马尔可夫假设含义：下一个词出现的概率之和其前n-1个词有关，而非其前的所有词。局限性：计算词出现的频率时受限于语料库的大小；忽略单词语义信息
1.3. rnn 通过隐藏状态，记录历史信息；LSTM通过细胞状态和门控机制，有选择的输入和记录信息；transformer 增加并行计算，提高计算效率（理解不清楚）

2.1. 自注意力机制思想：建模在序列中的上下文关系，计算权重
2.2. transformer 并行处理是因为基于矩阵来计算，一次性计算所有token的KQV，然后得到权重；RNN串行是因为下一阶段需要上一阶段的输出作为输入；位置编码能记录序列中元素的位置关系，并行计算忽略位置关系
2.3. Decoder-Only 只需要进行解码，和大模型预测下一个词的任务类似。而encoder-decoder架构是先理解输入，等encoder结束后，再进入decoder阶段

3. 直接用字符作为输入，造成序列过长、学习语义信息的难度增加；直接用单词会增加词表规模，难以覆盖所有词。BPE通过合并高频子词减小词表规模，基于词表拆分不常见词，是一种折中办法

5.1. RAG。工作原理：基于相关文档切块、索引、存储并构建出一个知识库，根据问题和知识库中的相似度计算，得到输出结果。适用场景：进一步增强大模型知识的时效性，扩充到最新的知识，用于对私有知识的处理
5.2. oai 曾提出通过为输出正确性设置奖励函数，来缓解模型幻觉。

6.1. gpt-5。gpt-5的幻觉低，能避免输出非论文中的内容和虚假信息，但是输出不是太清晰。
6.2. 强调禁止基于论文外的内容回答问题，必须引用原文内容来支撑回答。分块总结汇总。让不同的智能体阅读论文不同的章节，将总结的内容整理汇总输出给一个汇总智能体，最后经过整理输出最终的回答
6.3. 回答时需要引用论文原文

[stuPETER12138]

• 习题 3.6

学术研究是严谨的，这意味着我们需要确保智能体生成的信息是准确客观忠于原文的。你认为系统中加入哪些设计能够更好的实现这一需求？

我认为这个问题非常棒！不仅是学术研究，垂类的生产环境也很需要agent的稳定和准确。我想到最简单的办法就是在prompt中限制，以及可以在RAG的过程中加入准确性、忠诚度检查与反馈，甚至对rag做强化学习？不知道大家有什么不同的想法嘛

[lx123ing-cell]

作者你好，我在最近这个的学习中，最开始是准备按照作者的线路一点点复现的，但是发现代码量有点宏大，在Tool工具的实现过程中也有很多的细节，以及许多作者较为精妙或者是工程化可进行后续拓展以及规范化的设计方式，导致在复现代码学习上十分缓慢，作者认为这样的方式有必要吗。或者对于作者的agent的项目学习，您更推荐用什么方式呢

[jjyaoao]

issue中#85 已经回复了类似的问题哈，以后有问题欢迎提Issue，discussion留给习题讨论~

[InTheFuture7]

第四章

思考/问题

问题1

关于 Reflection.py 代码，我在想是否最好将每轮生成的code和feedback统一存储到memory中，然后从memory中获取信息，构建prompt？当前代码有的是从memory中读取last_code ，有的直接从函数返回得到feedback，感觉好像是有点乱

            print("\n-> 正在进行反思...")
            last_code = self.memory.get_last_execution()
            reflect_prompt = REFLECT_PROMPT_TEMPLATE.format(task=task, code=last_code)
            feedback = self._get_llm_response(reflect_prompt)
            self.memory.add_record("reflection", feedback)
            # ......
            refine_prompt = REFINE_PROMPT_TEMPLATE.format(
                task=task,
                last_code_attempt=last_code,
                feedback=feedback
            )

如果修改，只需要在Memory类中创建一个获取最新反思结果的函数

    def get_last_reflection(self) -> Optional[str]:
        """
        获取最近一次的反思结果
        如果不存在，则返回 None。
        """
        for record in reversed(self.records):
            if record['type'] == 'reflection':
                return record['content']
        return None

然后修改ReflectionAgent部分的run()优化部分代码

            # c. 优化
            print("\n-> 正在进行优化...")
            last_reflection = self.memory.get_last_reflection()  # 新增
            refine_prompt = REFINE_PROMPT_TEMPLATE.format(
                task=task,
                last_code_attempt=last_code,
                feedback=last_reflection # 修改
            )

作业

1.1 ReAct 在思考上会获得由行动所获得的环境反馈信息，行动的特点是支持外部工具的调用；P&S 在思考上有设计，能够拆分出子任务，但是在行动上没有什么特别设计；Reflecxion 在思考或行动上没有什么特别设计，引入迭代的思想对流程做优化

1.2 ReAct 支持外部工具调用，PS 能够制定详细的子任务，我会基于这两种架构来设计。因为Reflexion会花费太多的时间成本，不太适合，但是其中的记忆机制可以对用户习惯做追踪，可以拆取其中的记忆机制，以补充ReAct+PS。

1.3 可以组合，deep research场景，需要调用搜索工具，拆解用户复杂需求，不断迭代反馈给用户高质量回复。

2.1 该方法假定大模型输出格式符合正则，一旦大模型输出格式错误会比较导致信息提取失败

2.2 我觉得设置输出固定为 json 格式来解析更好，因为当前大多数大模型对 json 格式支持的比较好

2.3 待修改代码

3. 待代码实现

4.1 收集行动及其observation，在进行下一轮行动前，让大模型思考，是否可以继续按着当前步骤进行，如果不可以就尝试重新制定计划，具体在 response_text = self.llm_client.think(messages=messages) or "" 后面增加一个 if 判断，在 Executor.execute 函数中增加一个重试参数，如果if判断当前计划不合理，重新执行execute函数。

4.2 结合起来更好，既能制定分步骤的详细计划，又能调用工具。单看的化，可以选择 ReAct

4.3 避免步骤过于零散，适用于步骤过多的场景？使用嵌套的list或嵌套dict来实现？

5.1 效率提升

5.2 使用另一个模型来评估是否可以完成用户问题，从而设定终止条件？

5.3 多维度的反思可以通过设定特殊的提示词，让大模型从预先定义的几个角度来提供反思结果

6.1 ReAct提示词特点是定义了工具，并要求每次行动为条用工具或输出最终结果，对思考过程没有做细致的拆分
PS提示词特点是要求拆分细分的步骤，比较简洁，没有工具

6.2

6.3

7.1. 全部都可以用，基于ReAct调用工具，reflection的反思，PS的步骤规划

7.2. 在线查询订单、查询政策文件、撰写邮件并发送

7.3. 设定角色：你是一位注重准确性的电商客服。你的首要任务是提供准确、清晰、可靠的信息。在回答中，请始终做到：准确无误，礼貌友好，简洁高效。

7.4 响应及时性：如果使用reflection机制，可能造成给顾客反馈慢的问题。如果长时间未反馈，则由人工克服介入；
agent具有访问大量信息的权限，需要注意数据安全和数据泄露的问题。约束并监控agent查阅的数据范围。

[beston123]

电商退款方案 C：分层式人机协同决策

1. 第一层：Workflow 过滤器
   • 所有退款申请首先进入一个简化的 Workflow 系统。
   • 确定性分流： 系统执行最明确、最无争议的规则。
     • 自动通过: 绝对符合条件的申请（如：7 天内、<100元、普通商品、首次退款用户）。 -- Workflow 的效率优势
     • 自动拒绝: 绝对不符合条件的申请（如：明确标注不可退的特殊商品、有欺诈历史的用户）。-- Workflow 的风控优势
   • 所有其他“不确定”或“需要权衡”的申请，都被传递到第二层。
2. 第二层：Agent 分析器
   • 进入这一层的申请具有一定的复杂性（如：金额在 100-500元，超过 7 天但未满 30 天等）。
   • Agent 开始工作，它会：
     • 解析用户的退款理由。
     • 拉取并分析用户画像（历史购买记录、退款频率、会员等级等）。
     • 分析商品属性和相关政策。
   • Agent 的输出不是简单的“同意”或“拒绝”，而是一个带有置信度和决策依据的建议包。例如：“建议批准。理由：该用户为高价值年费会员，近一年无退款记录。虽然商品已超 7 天，但批准此次退款有助于维持客户关系。置信度：95%。” -- Agent
     的智能优势
3. 第三层：人工审核与仲裁
   • 低置信度/高风险案件： 如果 Agent 的置信度低于某个阈值（如 90%），或者申请金额巨大（>500元），系统会自动将 Agent 的建议包推送给人工客服或主管。
   • 人类做最终决策： 人工客服可以快速浏览 Agent 整理好的所有信息和建议，迅速做出最终判断。这比从零开始审核要快得多。
   • 结合了人类的最终把关和对复杂情况的理解，弥补了 Agent 的“黑盒”和误判风险。
4. 闭环反馈
   • 人工在第三层做的所有最终决策，都会被系统记录下来，作为新的高质量训练数据，反过来喂给第二层的 Agent。
   • 这样，Agent 会不断学习人类专家的决策模式，其准确率和自主处理范围会越来越广，未来需要人工干预的案例就会越来越少。

[islsy]

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

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

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

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

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

请分析：

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

A方案的优势就是流程可控，比较好预测，稳定性会比较高。B方案的优势是可以分析更多的背景信息数据进行更人性化的判断
当前的场景，更倾向于使用A方案
结合方案。可以先通过workflow对严格性的指标进行评估分析，判断是否需要审核流程。如果需要审核流程使用agent的方式对获取的用户历史行为和商品状况进行打分标注，帮助客服和主管进行简单决策，如果决策难度比较大再移交人工处理，agent可以提供一些打分用于参考

[yukangming]

请问，使用open ai的 api是不是调不通呀

[RainbowYv]

需要自己申请open ai的api，或者用一些国产模型的api代替一下也能跑

[jjyaoao]

请问，使用open ai的 api是不是调不通呀

第一章1.3节就已经提供了快捷的获取api方式，可以自行去搜索一下。

[jerryoung]

https://www.perplexity.ai/search/ben-zhang-jie-shao-liao-san-ch-hKWo6fq9QBuZwBYSip6zdA

ai解题

[InTheFuture7]

打开链接显示：This answer is private. You can access this page if the owner accepts your request.

[jerryoung]

https://www.perplexity.ai/search/ben-zhang-jie-shao-liao-san-ch-hKWo6fq9QBuZwBYSip6zdA

[jerryoung]

点多了

[RainbowYv]

INFO:hello_agents.memory.storage.qdrant_store:✅ 成功连接到Qdrant云服务:
INFO:hello_agents.memory.storage.qdrant_store:✅ 使用现有Qdrant集合: hello_agents_vectors
Batches: 100%|██████████| 1/1 [00:00<00:00, 164.34it/s]
INFO:hello_agents.memory.types.semantic:✅ 嵌入模型就绪，维度: 384
D:\Anaconda\envs\helloAgent\Lib\site-packages\hello_agents\memory\storage\qdrant_store.py:152: UserWarning: Failed to obtain server version. Unable to check client-server compatibility. Set check_compatibility=False to skip version check.
self.client = QdrantClient(
INFO:hello_agents.memory.storage.qdrant_store:✅ 成功连接到本地Qdrant服务: localhost:6333
ERROR:hello_agents.memory.storage.qdrant_store:❌ Qdrant连接失败: Unexpected Response: 502 (Bad Gateway)
Raw response content:
b''
INFO:hello_agents.memory.storage.qdrant_store:💡 本地连接失败，可以考虑使用Qdrant云服务
INFO:hello_agents.memory.storage.qdrant_store:💡 或启动本地服务: docker run -p 6333:6333 qdrant/qdrant

这一章开头的demo代码我这里为什么会有两次连接Qdrant

[jjyaoao]

这类问题最好放在issue，可以看一下云端的启动没有？有一个控制台

[InTheFuture7]

第五章

coze 的链接：https://code.coze.cn/

问题

coze 每日 AI 简报助手中下面三处不知道怎么做？教程中信息较少，coze网页没有摸索出来😓
1、如何设置系统和用户提示词？
2、可视化编排在哪里？
3、24小时新闻插件里面，如何添加多个网页链接。我看输入参数只有rss_url，输入默认值只有一个框能填信息

[2238043627]

教程中的coze每日 AI 简报助手是一个工作流。
1、点击你发的这个链接进去，点击“工作流开发”，填写工作流名称和描述点击确定就创建了一个工作流，也就是可视化编排页面。
2、需要你添加一个大模型节点，点击这个节点设置系统和用户提示词。
3、一个24小时新闻插件只能设置一个url链接，如果向添加多个网页链接，你需要多添加几个24小时新闻插件

[InTheFuture7]

感谢大佬指点，成功了 😁

因为我原本想让插件抓取中文三大顶会的内容，发现抓取不了，只能抓取教程中的那几个，所以返回结果不多。

因为那个插件只抓取近 24h 的内容，所以当输入其他时间，也只是返回24小时内的新闻。

[xjy486]

第5章的实战教程不清晰，一步一步操作根本做不出来，尤其是n8n那部分，前后逻辑不清晰，这种实操建议还是录一个视频会好一点。

[jjyaoao]

已经在进行中了。如果有你觉得的逻辑问题，欢迎提PR和issue反馈

[jerryoung]

https://www.perplexity.ai/search/jie-da-xi-ti-fudI.6WJQAqK4gpOtPsjNw#1

[vitorian2]

在chapter8，配置Qdrant时，我通过脚本验证了云端 URL 和 API KEY是有效的。但在使用 MemoryTool 时，框架日志显示其初始化 EpisodicMemory 成功连上云端，但在初始化 SemanticMemory 时却跳回了 localhost，改了一下源码，两个都连上云端了，现在还在攻克neo4j中...

[qz383102-ops]

第一章

以下四个case中的主体是否属于智能体

case A

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

判断：不属于智能体

理由：没有自主性，被动根据外部的输入执行预设程序。

case B

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

判断：智能体

分类：属于反应式智能体，决策延迟低。

case C

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

判断：智能体

理由：属于学习型智能体，通过学习优化自己的决策策略。

case D

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

判断：智能体

理由：属于认知智能体，能够和用户进行交流，并处理事件。

“智能健身教练”

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

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

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

环境描述

P--能够根据用户的情况给出建议，让用户在短时间内的健身效果达到目标，包括减脂、增肌、提升耐力等。

E--监测用户的生理数据以及用户健身时周围的环境状况。

A--根据内部的思考实时为用户提供反馈，包括语音指导和动作纠正。

S--可以对用户输入的自身情况进行解析，并通过硬件传感器测量用户的实时身体状况。

环境特性

1. 部分可观察：能够观察到用户的心率、动作等。
2. 随机性：用户每天的情况都会发生变化。

电商公司

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

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

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

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

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

请分析：

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

优缺点

workflow：由人力进行审核，更加严谨，能够减少错误决策的出现；但消耗的资源较多，效率低。

agent：由智能体进行自主学习，减少了人力的耗费，提升了处理效率；但在过程中会发生错误情况，导致用户不满等。

适合场景

workflow：适用于订单量较少，需要严格审核的情况。

agent：适用于订单量大，复杂度较高的情况。

如果我是电商公司的负责人，在初期我会选择workflow方案来进行售后，在后期业务逐渐成熟之后会选择使用agent处理售后，提升客服的效率。

方案C

可以将那些复杂度很高，需要人工严格审核的售后订单交给人工处理，agent则负责能够自动处理的订单。

卡尼曼

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

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

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

例如医疗诊断助手：
在诊断病情以及制定治疗方案时需要使用系统1，在例如做手术过程中的快速决断需要用到系统2。

局限

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

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

产生幻觉：可能是用户在提问过程中用到了引导性的词语，并且在训练时喂了错误的信息和数据。

如果没有限制可能会进入死循环，最终跑偏。

不仅要使用准确率指标，还需要收集用户的评价，判断智能体是否灵活，不能过于死板。