1. 这不是又一个“Hello World”而是你第一次真正握住智能体的缰绳AgentScope 2.0 这个名字最近在 Python 开发者圈子里出现的频率已经快赶上 WSL 安装教程的搜索量了。我第一次看到它的时候也以为是另一个包装精美的 ChatGPT 封装库——点开文档满屏的agent、orchestration、pipeline配上几行看似简单的代码心里直犯嘀咕这玩意儿真能跑起来还是又一个“概念先行、落地靠猜”的玩具框架直到我在一台刚装好 Ubuntu-24.04 的 WSL 2 环境里从零开始敲下第一行pip install agentscope到最终让两个智能体——一个负责查天气一个负责写周报——像同事一样坐在一起开完会整个过程只用了不到 45 分钟。那一刻我才明白AgentScope 2.0 的核心价值根本不在它有多“智能”而在于它把“智能体编排”这件事从分布式系统工程师的专属领域拉回到了普通 Python 开发者能随手调试的终端里。它解决的是一个非常具体、非常痛的现实问题过去我们写一个调用大模型的脚本逻辑是线性的——输入→调用→输出。但真实业务场景哪有这么简单你让 AI 写一份市场分析报告它得先查行业数据再对比竞品还要参考最新财报最后才动笔。这中间每一步都可能失败、需要重试、依赖前序结果、甚至要人工介入。把这些环节串成一条可靠、可观测、可调试的流水线就是“编排”的本质。AgentScope 2.0 不是让你去造轮子而是直接给你一套带刹车、带仪表盘、带维修手册的智能体小车。它不强制你学 Kubernetes也不要求你部署 Redis 集群它只要求你理解Agent是什么、Pipeline怎么连、Monitor在哪儿看日志——这些全是 Python 基础语法的自然延伸。所以这篇笔记不是教你怎么成为 AGI 架构师而是带你亲手把第一个智能体流水线跑通、看懂、改顺。无论你是刚学会pip install的 Python 新手还是在 WSL 里配过十次 CUDA 却总卡在nvidia-smi报错的老兵只要你能运行python --version这篇笔记里的每一步你都能跟着敲出来、看到结果、理解为什么。2. 为什么是 AgentScope 2.0为什么必须用 WSL为什么不能跳过编排2.1 框架选型不是“哪个最强”而是“哪个最不折腾”市面上叫“Agent 框架”的东西不少LangChain、LlamaIndex、Semantic Kernel……它们各有千秋但共同点是上手门槛和生产可用性之间隔着一堵叫“调试成本”的墙。LangChain 的链式调用写起来很优雅但一旦某个节点出错你得一层层扒日志搞不清是 Prompt 写错了还是 LLM 返回格式崩了还是你自己的回调函数抛了异常。LlamaIndex 强在检索可如果你的需求只是“让 A 查完数据传给 B 处理”它就显得过于厚重——就像为了煮一杯咖啡先去考了咖啡豆种植师执照。AgentScope 2.0 的破局点恰恰在于它的“克制”。它不试图做所有事而是死死盯住一个核心命题如何让多个智能体像人一样协作。为此它做了三件关键的事显式定义角色与能力Role Capability每个 Agent 不再是黑盒函数而是有明确身份WeatherAgent、明确技能search_weather、明确输入/输出契约input: city_name, output: dict{temp, condition}的实体。这就像给团队成员发工牌和岗位说明书协作才有基础。声明式编排Declarative Orchestration你不用写if-else去控制流程走向而是用Pipeline对象像搭积木一样把 Agent 串起来pipeline Pipeline([weather_agent, report_agent])。失败重试、超时控制、结果路由全由框架内置的Router和Executor处理。这省下的不是代码行数而是心智负担。开箱即用的可观测性Observability Out-of-the-Box运行时自动生成结构化日志、调用链追踪、甚至带时间戳的对话记录。你不需要额外集成 Prometheus 或 ELKagentscope.monitor模块启动后所有关键事件自动落盘为 JSONL 文件打开就能看谁在什么时候说了什么、返回了什么、耗时多少。这对排查“Agent 执行终止”这类模糊错误简直是救命稻草。提示别被“2.0”这个版本号迷惑。它不是对 1.x 的简单升级而是架构级重构。旧版偏重单智能体能力新版则把“多智能体协作”作为第一设计原则。如果你搜到的教程还在讲AgentRuntime或AgentClient那基本是 1.x 的内容和 2.0 的Pipeline、Monitor体系完全不兼容。2.2 环境基石WSL 2 是 Windows 用户唯一靠谱的选择为什么所有 AgentScope 2.0 的新手教程几乎都默认以 WSL 为起点答案很现实Windows 原生环境对 Python 科学计算生态的支持依然存在不可忽视的裂缝。CUDA 与 GPU 加速AgentScope 本身不强制依赖 GPU但你的底层 LLM比如本地部署的 Qwen 或 Llama3几乎必然需要。Windows 上安装torchcuda组合经常遇到DLL load failed、cudnn version mismatch这类玄学错误。而在 WSL 2 的 Ubuntu 环境里apt install nvidia-cuda-toolkitpip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121命令清晰、路径干净、错误信息明确。文件系统与权限AgentScope 的Monitor默认将日志写入./logs/目录。Windows 的 NTFS 文件系统在 WSL 下挂载时偶尔会出现权限继承混乱导致 Python 进程无权创建子目录。Ubuntu 的 ext4 文件系统则不存在这个问题mkdir -p logs后Python 进程天然拥有完整读写权限。网络与代理很多国内用户需要配置 API Key 访问商业 LLM如 Qwen、GLM。WSL 2 共享宿主 Windows 的网络但 DNS 解析更稳定尤其在使用企业级防火墙时且~/.bashrc中设置http_proxy和https_proxy环境变量对所有 Python 子进程生效比在 Windows 的 PowerShell 或 CMD 里逐个设置更可靠。注意wsl --install -d ubuntu-24.04是目前最稳妥的安装方式。不要用ubuntu-22.04因为 AgentScope 2.0 的某些依赖如pydantic2.6在较老的setuptools版本下会编译失败也不要手动下载 ISO 安装WSL 商店一键安装能自动配置好 systemd 支持虽然 AgentScope 不依赖它但后续扩展 Docker 时会省心。2.3 编排不是锦上添花而是智能体工程化的分水岭很多人初学 Agent会陷入一个误区把“调用一次大模型”当成“完成一个 Agent”。比如写个脚本输入“北京天气”调用openai.ChatCompletion.create()打印结果。这确实能跑但它和真正的 Agent 差了整整一个维度——状态管理与流程韧性。没有状态就没有记忆单次调用无法记住“用户上一句问的是上海这一句问的是温度”更无法在多轮对话中维护上下文。AgentScope 的Pipeline通过Session对象在内存中维护整个会话的state字典每个 Agent 的输出自动成为下一个 Agent 的输入的一部分。没有编排就没有容错真实世界里API 会超时、模型会拒答、网络会抖动。一个健壮的 Agent 流水线必须内置重试机制max_retries3、降级策略fallback_agentSimpleReportAgent、超时控制timeout30。这些不是业务逻辑而是基础设施AgentScope 2.0 把它们封装在Pipeline的run()方法里你只需传参无需操心。没有可观测性就没有迭代当你发现“Agent 执行终止”是 Prompt 写错了是模型返回了非法 JSON还是report_agent的parse_response()函数崩溃了没有结构化日志你只能靠print()二分法排查。AgentScope 的Monitor会在logs/下生成pipeline_20240520_143022.jsonl里面每一行都是一个事件{event: agent_start, agent_id: weather_agent, timestamp: 2024-05-20T14:30:22.123Z, input: {city: Beijing}} {event: llm_call, model: qwen2-7b, prompt_tokens: 156, completion_tokens: 42} {event: agent_finish, agent_id: weather_agent, output: {temp: 28, condition: Sunny}}一眼就能定位问题发生在哪个环节。3. 零基础实操从 WSL 安装到双智能体协同办公3.1 环境准备四步搞定纯净 Python 环境这一步看似简单却是后续所有操作稳定的地基。我建议严格按顺序执行不要跳过任何检查点。启动 WSL 并更新系统# 在 Windows 的 PowerShell管理员中执行 wsl --install -d ubuntu-24.04 # 启动后首次登录会提示设置用户名密码按提示完成 # 进入 WSL 终端执行更新 sudo apt update sudo apt upgrade -y安装 Python 3.11 及 pipUbuntu-24.04 默认已预装但需确认python3 --version # 应输出 3.11.x pip3 --version # 应输出 23.x 或更高 # 如果 pip 版本过低升级它 sudo apt install python3-pip -y pip3 install --upgrade pip创建并激活虚拟环境强烈推荐避免包冲突# 创建名为 agentenv 的虚拟环境 python3 -m venv ~/agentenv # 激活它注意每次新开终端都需要重新激活 source ~/agentenv/bin/activate # 激活后命令行前缀会变成 (agentenv) $安装 AgentScope 2.0 核心包# AgentScope 2.0 的 PyPI 包名就是 agentscope pip install agentscope # 验证安装 python -c import agentscope; print(agentscope.__version__) # 应输出 2.0.x实操心得如果pip install agentscope卡在Building wheel for xxx大概率是网络问题。此时不要慌先执行pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple切换清华源再重试。清华源在国内的稳定性和速度远超默认 PyPI。3.2 第一个智能体天气查询 Agent理解Agent类的本质AgentScope 2.0 中一个Agent的本质就是一个继承自agentscope.agents.Agent的 Python 类。它有三个核心要素__init__初始化能力、__call__执行逻辑、_reply封装响应。我们来写一个最简版的WeatherAgent# weather_agent.py from agentscope.agents import Agent from agentscope.message import Msg import requests import json class WeatherAgent(Agent): def __init__( self, name: str WeatherAgent, model_name: str dashscope/qwen2-7b-instruct, # 这里先用一个占位符实际会替换 ) - None: super().__init__(namename) # 初始化时我们不连接任何外部服务只定义能力契约 # 真实项目中这里可能会初始化 API client 或数据库连接池 def __call__(self, city: str) - dict: 核心执行方法。输入城市名输出天气字典。 注意这是同步阻塞调用AgentScope 会自动处理并发调度。 # 模拟调用第三方天气 API此处用 mock 数据演示 # 真实场景下这里会是 requests.get(fhttps://api.weather.com/v3/weather/forecast?city{city}) mock_data { Beijing: {temp: 28, condition: Sunny, humidity: 45}, Shanghai: {temp: 25, condition: Cloudy, humidity: 72}, Guangzhou: {temp: 31, condition: Rainy, humidity: 88}, } result mock_data.get(city, {temp: N/A, condition: Unknown, humidity: N/A}) # 构建标准消息对象这是 AgentScope 的通信协议 # Msg 是 Agent 间传递数据的标准载体包含 content, role, name 等字段 msg Msg( nameself.name, contentfWeather in {city}: {result[condition]}, {result[temp]}°C, humidity {result[humidity]}%, roleassistant, metadata{raw_data: result} # 可以附带原始数据供下游解析 ) return msg关键点解析Msg对象是 AgentScope 的“通用语言”。它强制所有 Agent 使用统一的数据结构通信避免了dict、str、list混用导致的类型错误。content是给人看的文本metadata是给机器用的结构化数据。__call__方法的签名def __call__(self, city: str) - dict定义了该 Agent 的“接口”。下游 Agent 或Pipeline调用它时必须传入city参数它保证返回一个Msg对象。这就是契约。model_name参数在这里是占位符因为我们还没接入真实的 LLM。AgentScope 2.0 的设计哲学是Agent 的能力可以是规则引擎、API 调用、甚至人工审核不一定是大模型。这让你能渐进式地替换组件。3.3 第二个智能体周报生成 Agent理解Pipeline的串联逻辑有了WeatherAgent我们再写一个ReportAgent它接收天气数据生成一份简洁的周报# report_agent.py from agentscope.agents import Agent from agentscope.message import Msg class ReportAgent(Agent): def __init__( self, name: str ReportAgent, ) - None: super().__init__(namename) def __call__(self, weather_data: dict) - dict: 输入从 WeatherAgent 获取的原始天气数据字典 输出格式化的周报消息 # 解析上游传来的 Msg 对象中的 metadata # 注意Pipeline 会自动将前一个 Agent 的返回值Msg作为参数传入 if not isinstance(weather_data, dict) or raw_data not in weather_data: # 容错如果上游没传 metadata尝试从 content 解析 city Unknown temp N/A else: raw weather_data[raw_data] city list(raw.keys())[0] if isinstance(raw, dict) and raw else Unknown temp raw.get(temp, N/A) # 生成周报内容 report_content f【智能体周报】\n城市{city}\n当前温度{temp}°C\n建议{self._get_suggestion(temp)} msg Msg( nameself.name, contentreport_content, roleassistant, metadata{report_type: weekly, generated_by: ReportAgent} ) return msg def _get_suggestion(self, temp: str) - str: 根据温度给出生活建议展示 Agent 内部逻辑封装 try: t int(temp) if t 30: return 注意防暑降温多喝水 elif t 10: return 注意保暖适时增添衣物 else: return 天气适宜适合户外活动 except (ValueError, TypeError): return 温度数据异常请检查上游输入现在把两个 Agent 串起来# main.py from agentscope.pipelines import Pipeline from agentscope.agents import Agent from agentscope.message import Msg from weather_agent import WeatherAgent from report_agent import ReportAgent # 1. 初始化两个 Agent 实例 weather_agent WeatherAgent(nameWeatherFetcher) report_agent ReportAgent(nameWeeklyReporter) # 2. 创建 Pipeline指定执行顺序 # Pipeline 的参数是一个 Agent 列表顺序即执行顺序 pipeline Pipeline([weather_agent, report_agent]) # 3. 运行 Pipeline传入第一个 Agent 的初始输入 # 这里传入 Beijing它会被自动作为 weather_agent.__call__() 的参数 result pipeline.run(Beijing) # 4. 打印最终结果 print(Pipeline 最终输出) print(result.content) # 输出示例 # 【智能体周报】 # 城市Beijing # 当前温度28°C # 建议天气适宜适合户外活动执行流程图解文字版pipeline.run(Beijing)→ 调用weather_agent(Beijing)weather_agent返回一个Msg对象其content是天气描述metadata是{raw_data: {...}}Pipeline自动提取这个Msg并将其作为参数传给report_agent.__call__()report_agent从Msg.metadata中取出raw_data生成周报返回新的Msgpipeline.run()的返回值就是report_agent返回的Msg注意Pipeline的run()方法是同步的。它内部会按顺序调用每个 Agent 的__call__并将前一个的输出Msg作为下一个的输入。这种“数据流驱动”的模式比传统的“函数调用链”更清晰、更易测试。3.4 加入可观测性让每一次执行都留下痕迹AgentScope 2.0 的Monitor模块是它区别于其他框架的最大亮点之一。启用它只需两行代码# 在 main.py 开头添加 from agentscope.monitor import Monitor # 在 pipeline.run() 之前初始化 Monitor monitor Monitor() monitor.start() # 启动监控 # ... 其他代码不变 ... # 运行 pipeline result pipeline.run(Shanghai) # 运行结束后停止监控可选程序退出时会自动停止 monitor.stop()运行后你会在当前目录下看到logs/文件夹里面有一个类似pipeline_20240520_154233.jsonl的文件。用cat或 VS Code 打开它内容如下{event:pipeline_start,pipeline_id:pipeline_20240520_154233,timestamp:2024-05-20T15:42:33.123Z,input:Shanghai} {event:agent_start,agent_id:WeatherFetcher,timestamp:2024-05-20T15:42:33.125Z,input:{city:Shanghai}} {event:agent_finish,agent_id:WeatherFetcher,timestamp:2024-05-20T15:42:33.128Z,output:{name:WeatherFetcher,content:Weather in Shanghai: Cloudy, 25°C, humidity 72%,role:assistant,metadata:{raw_data:{temp:25,condition:Cloudy,humidity:72}}}} {event:agent_start,agent_id:WeeklyReporter,timestamp:2024-05-20T15:42:33.129Z,input:{name:WeatherFetcher,content:Weather in Shanghai: Cloudy, 25°C, humidity 72%,role:assistant,metadata:{raw_data:{temp:25,condition:Cloudy,humidity:72}}}} {event:agent_finish,agent_id:WeeklyReporter,timestamp:2024-05-20T15:42:33.131Z,output:{name:WeeklyReporter,content:【智能体周报】\n城市Shanghai\n当前温度25°C\n建议天气适宜适合户外活动,role:assistant,metadata:{report_type:weekly,generated_by:ReportAgent}}} {event:pipeline_finish,pipeline_id:pipeline_20240520_154233,timestamp:2024-05-20T15:42:33.132Z,output:{name:WeeklyReporter,content:【智能体周报】\n城市Shanghai\n当前温度25°C\n建议天气适宜适合户外活动,role:assistant,metadata:{report_type:weekly,generated_by:ReportAgent}}}这份日志的价值精准定位失败点如果某次运行报错Agent execution terminated due to error.你不再需要盲猜。直接看日志里最后一个agent_start事件它的agent_id就是出问题的那个 Agent。性能分析对比agent_start和agent_finish的timestamp可以精确计算每个 Agent 的耗时。如果WeatherFetcher耗时 200ms而WeeklyReporter耗时 2ms说明瓶颈在外部 API而非本地逻辑。审计与回溯所有输入、输出、中间状态都被持久化。你可以随时打开日志复现当时发生了什么这对于合规性要求高的场景如金融、医疗至关重要。4. 常见问题与排查技巧实录那些官方文档不会写的坑4.1 “Agent couldnt generate a response. please try again.” —— 这不是你的错是配置问题这个错误信息几乎是 AgentScope 新手遇到的第一个“拦路虎”。它通常出现在你尝试接入真实 LLM如 DashScope、OpenAI时。根本原因只有一个AgentScope 无法从你提供的 API Key 或模型配置中成功发起一次 HTTP 请求并获得有效响应。排查步骤检查环境变量AgentScope 依赖DASHSCOPE_API_KEY或OPENAI_API_KEY等环境变量。在 WSL 终端中执行echo $DASHSCOPE_API_KEY确认输出是你的真实 Key。如果为空执行export DASHSCOPE_API_KEYyour_actual_key_here并把它加到~/agentenv/bin/activate文件末尾这样每次激活虚拟环境都会自动加载。验证网络连通性在 WSL 中执行curl -v https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation。如果返回401 Unauthorized说明网络通、Key 无效如果返回Could not resolve host说明 DNS 或代理配置有问题。检查模型名称拼写DashScope 的模型名是qwen2-7b-instruct不是qwen-2-7b或qwen2-7b。少一个-instruct就会返回Model not found错误AgentScope 将其泛化为“无法生成响应”。实操心得我踩过的最大坑是在 Windows 的 PowerShell 里设置了$env:HTTP_PROXYhttp://127.0.0.1:7890以为 WSL 会自动继承。实际上WSL 的网络是独立的必须在 WSL 的~/.bashrc里单独设置export http_proxyhttp://host.docker.internal:7890注意host.docker.internal是 WSL 访问宿主 Windows 的特殊域名。4.2 WSL 中pip install太慢别硬等三招提速WSL 的pip速度常常被诟病。这不是你的网速问题而是默认源在国外。方案一推荐全局切换清华源在 WSL 终端中执行pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple pip config set global.trusted-host pypi.tuna.tsinghua.edu.cn这会修改~/.pip/pip.conf对所有后续pip命令生效。方案二临时指定源安装pip install agentscope -i https://pypi.tuna.tsinghua.edu.cn/simple --trusted-host pypi.tuna.tsinghua.edu.cn方案三终极预下载 wheel 包在 Windows 浏览器中访问https://pypi.tuna.tsinghua.edu.cn/simple/agentscope/找到最新版本的.whl文件如agentscope-2.0.1-py3-none-any.whl下载到 Windows 的Downloads文件夹。然后在 WSL 中执行# 将 Windows 的 Downloads 映射到 WSL 的 /mnt/c/Users/YourName/Downloads cd /mnt/c/Users/YourName/Downloads pip install agentscope-2.0.1-py3-none-any.whl这种方式完全绕过网络秒装。4.3 “VSCode 中使用 WSL” 配置不生效检查 Python 解释器路径很多用户在 VSCode 里安装了 WSL 扩展却依然无法识别agentscope。这是因为 VSCode 的 Python 解释器没有指向你的虚拟环境。正确配置路径在 VSCode 中按CtrlShiftP输入Python: Select Interpreter。在弹出的列表中选择Enter path...。手动输入你的虚拟环境 Python 路径/home/your_username/agentenv/bin/python注意不是~/agentenv/bin/pythonVSCode 不识别~。重启 VSCode 的 Python 终端CtrlShiftP→Python: Restart Language Server。提示在 VSCode 的集成终端里如果看到(agentenv)前缀说明解释器已正确激活。此时import agentscope才会成功。4.4 日志文件logs/空空如也Monitor启动时机不对Monitor必须在Pipeline实例化之前启动否则它无法捕获Pipeline的初始化事件。错误写法pipeline Pipeline([agent1, agent2]) monitor Monitor() monitor.start() # ❌ 太晚了Pipeline 的初始化事件已被错过 result pipeline.run(input)正确写法monitor Monitor() monitor.start() # ✅ 第一行就启动 pipeline Pipeline([agent1, agent2]) # Pipeline 初始化事件会被捕获 result pipeline.run(input)此外确保你的工作目录有写入权限。如果logs/目录被设为只读Monitor会静默失败。执行ls -ld logs查看权限必要时chmod 755 logs。4.5 “Python 安装详细步骤”陷阱别用apt install python3装生产环境Ubuntu 的apt install python3安装的是系统 Python它被 OS 依赖绝对不要用pip install往里面装第三方包否则极易破坏apt的依赖关系导致sudo apt upgrade失败。安全做法永远是用apt install python3-venv安装虚拟环境支持。用python3 -m venv myproject_env创建隔离环境。用source myproject_env/bin/activate激活后再pip install。这是 Linux 系统管理的铁律和 AgentScope 无关但却是无数新手翻车的根源。5. 从“跑通”到“用好”三个必做的进阶动作跑通第一个 Pipeline 只是起点。要真正把 AgentScope 2.0 变成你的生产力工具这三个动作一个都不能少。5.1 动手改写WeatherAgent接入真实 API把weather_agent.py里的mock_data替换为真实的 HTTP 调用。我推荐使用免费的 Open-Meteo API它无需 Key响应快# 替换 weather_agent.py 中的 __call__ 方法 def __call__(self, city: str) - dict: # 使用 Open-Meteo 的地理编码 API 获取经纬度 geo_url fhttps://geocoding-api.open-meteo.com/v1/search?name{city}count1languageenformatjson geo_resp requests.get(geo_url).json() if not geo_resp.get(results): raise ValueError(fCity {city} not found) lat geo_resp[results][0][latitude] lon geo_resp[results][0][longitude] # 使用经纬度获取天气 weather_url fhttps://api.open-meteo.com/v1/forecast?latitude{lat}longitude{lon}currenttemperature_2m,weather_codetimezoneauto weather_resp requests.get(weather_url).json() current weather_resp[current] weather_code current[weather_code] # 天气码映射表简化版 weather_map {0: Clear sky, 1: Mainly clear, 2: Partly cloudy, 3: Overcast, 45: Fog, 48: Depositing rime fog, 51: Light drizzle, 53: Moderate drizzle, 55: Dense drizzle, 56: Light freezing drizzle, 57: Moderate freezing drizzle, 61: Slight rain, 63: Moderate rain, 65: Heavy rain, 66: Light freezing rain, 67: Moderate freezing rain, 71: Slight snow fall, 73: Moderate snow fall, 75: Heavy snow fall, 77: Snow grains, 80: Slight rain showers, 81: Moderate rain showers, 82: Violent rain showers, 85: Slight snow showers, 86: Heavy snow showers, 95: Thunderstorm, 96: Thunderstorm with slight hail, 99: Thunderstorm with heavy hail} condition weather_map.get(weather_code, Unknown) temp current[temperature_2m] msg Msg( nameself.name, contentfWeather in {city}: {condition}, {temp}°C, roleassistant, metadata{raw_data: {temp: temp, condition: condition, weather_code: weather_code}} ) return msg这个改动带来的质变你不再依赖模拟数据而是和真实世界产生了连接。你学会了如何处理 API 的两级调用先地理编码再天气查询。你理解了requests的异常处理try-except包裹requests.get这是生产环境的必备技能。5.2 给 Pipeline 加上“人工审核”环节真正的业务流程不可能 100% 自动化。加入一个HumanReviewAgent当天气温度超过 35°C 时强制人工确认周报内容# human_review_agent.py from agentscope.agents import Agent from agentscope.message import Msg class HumanReviewAgent(Agent): def __init__(self, name: str HumanReviewer) - None: super().__init__(namename) def __call__(self, weather_data: dict) - dict: # 从 metadata 中提取温度 temp weather_data.get(raw_data, {}).get(temp, 0) if temp 35: # 温度过高需要人工确认 content f⚠️ 高温预警检测到 {temp}°C是否仍按原计划生成周报请回复 YES 或 NO msg Msg(nameself.name, contentcontent, roleassistant, metadata{need_review: True}) else: # 温度正常自动通过 msg Msg(nameself.name, content✅ 温度正常自动通过审核, roleassistant, metadata{need_review: False}) return msg然后修改main.py的 Pipeline# pipeline Pipeline([weather_agent, human_review_agent, report_agent]) # 这样流程就变成了查天气 → 人工审核 → 生成报告这个设计体现了 AgentScope 的核心优势混合编排。你可以无缝地把规则判断