最近在折腾多智能体框架发现圈子里聊 AgentScope 的人明显多起来了。这个框架最打动我的地方是它把“构建多智能体应用”这件事的门槛降得很低尤其是它原生支持的 skills 机制——简单说你既可以把某个 Agent 当作一个技能注入到另一个 Agent 的对话流里也可以把一段自定义的 Python 函数注册成可复用的工具让智能体在推理过程中按需调用。这篇内容不是我抄文档而是我把 AgentScope 的 skills 用法从安装到跑通、再到踩坑填坑的完整过程捋了一遍。如果你正准备在项目里把多个模型角色组织成一条工作流或者想让某个 Agent 具备调用外部工具的能力这篇文章应该能帮你少走不少弯路。整个方案经过我本地实测验证所有的参数和示例都给出了可操作的具体写法不同基础的朋友都能照着落地上手。1. 深入理解 AgentScope 的 skills 机制1.1 为什么我最终选定了 AgentScope市面上的多智能体框架并不少。我用过不少同类工具它们各有亮点但总有几个让我觉得别扭的地方要么是将 Agent 的定义和模型绑定得太死换一个模型就要改一遍逻辑要么是把多智能体的调度写得太重本地调试困难重重要么工具调用和 Agent 的对话管理是两条独立的逻辑维护成本很高。AgentScope 给我的感觉是“清爽”。它自带一套完整的多智能体调度方案同时把 Agent 的定义、模型的接入、消息的传递和工具的执行拆得很开。它提供了灵活的 pipeline 编排能力你可以用几行代码把多个 Agent 串成一条流水线甚至支持分布式部署让不同 Agent 跑在不同的进程或者机器上。但真正让我下定决心在项目里全面使用它的还是它把 skills 组织成第一等公民的这个设计。在 AgentScope 里一个 skill 可以有两种形态一种是一个完整的 ReagentAgent它有自己独立的系统提示词、模型配置和执行逻辑你可以把它当作一个“子 Agent”交给另一个 Agent 去调用这就实现了 Agent 嵌套另一种形态是更轻量的工具函数通过注册机制挂到某个 Agent 上让它在推理时决定何时调用。这两种形态让我在搭建复杂应用时不用再纠结“到底该把逻辑塞进提示词里还是拆成一个 Agent”而是可以根据复用性和复杂度自由取舍。我在实际项目中体验下来的感受是AgentScope 最值得称道的是它把“Agent 调度”和“工具使用”统一到了同一个消息协议里。Agent 之间传递的是 msg 对象Agent 调用工具返回的也是 msg 对象。这让整个系统的数据流动非常干净调试的时候用内置的打印工具可以很直观地看到每一步发生了什么。1.2 skills 机制的三种核心形态我刚开始接触的时候对“skills”这个概念有些模糊因为框架里并没有一个叫 skill 的强制基类而是通过几种不同的方式来实现“技能”这层抽象。我用一张表来区分这三种形态理解它们各自的适用场景形态实现方式适用场景我实际用的感受ReagentAgent 独立技能定义一个新的 ReagentAgent设定自己的 system prompt 和 model作为可复用单元需要独立记忆、独立上下文、可能被多个 Agent 复用的复杂技能配置稍多但复用性极强适合封装领域专家工具函数注册用AgentScope.init_tool或函数装饰器把 Python 函数注册为工具挂载到 Agent 上简单、无状态的计算或信息获取类操作轻量直接模型能根据描述自动判断何时调用多 Agent 编排技能通过 pipeline 将多个 Agent 串成一条工作流整体作为一个大技能有明确流程顺序的复合任务阅读代码时逻辑清晰适合流程稳定的场景这三种形态并不互斥实际项目中经常搭配使用。比如我在做一个信息整理类的任务时先让一个“检索 Agent”通过工具函数去查数据再把结果交给一个“总结 Agent”输出结论最后通过一个“审核 Agent”做质量把关。三个阶段被组织成一个 pipeline整体看就是一个复合技能。值得多说一句的是AgentScope 对工具函数的参数schema处理得很好。你不需要手动写 JSON Schema框架会根据函数的类型注解自动生成。这意味着只要你写 Python 函数的时候老老实实把类型标注写清楚Agent 调用工具时就能获得非常准确的参数提示几乎不会出现参数幻觉。我在项目里实测过一个带- str类型注解的函数被模型正确调用的成功率非常高。2. 从零搭建 AgentScope skills 开发环境2.1 环境准备与安装坑位提醒AgentScope 目前对 Python 版本要求比较明确3.9 到 3.12 我都在不同环境里试过都能正常跑。安装方式很简单直接 pip 安装即可pip install agentscope但这里有几个坑我要提前告诉你如果你的项目还需要用到分布式的功能记得额外安装完整版依赖pip install agentscope[distribute]。这个方括号的安装方式在我早期使用时容易漏掉结果后面要用分布式调度时发现缺少消息通信的库又要回头补装。AgentScope 底层依赖了多个第三方库包括 pydantic、numpy 等如果你所在的网络环境有源限制建议用国内镜像源安装速度会快很多pip install agentscope -i https://pypi.tuna.tsinghua.edu.cn/simple。如果你本机装了多个 Python 版本建议在虚拟环境里操作。我在一个旧项目中直接装进全局环境结果和另一个框架的 pydantic 版本冲突排查了大半天。后来所有 AgentScope 项目我都用 venv 隔离再没出过类似问题。安装完成后可以跑一条简单的命令验证是否正常python -c import agentscope; print(agentscope.__version__)我当时跑出版本号的那一刻才算是松了一口气。别小看这一步环境问题往往是新手入门的第一道坎。2.2 模型接入配置与注意事项AgentScope 是一个模型无关的框架它支持市面上主流的模型提供方。接入模型的方式是通过AgentScope.init来统一初始化而不是在创建 Agent 时才去指定模型。这是我的一个认知转变——之前用其他框架时模型配置总是散落在各个 Agent 初始化参数里而 AgentScope 把这层配置收敛到了一处。下面是我常用的初始化方式import agentscope agentscope.init( model_configs[ { model_type: openai, model_name: gpt-4o-mini, api_key: sk-..., generate_args: { temperature: 0.7 } }, { model_type: openai, model_name: qwen-max, api_key: sk-..., base_url: https://dashscope.aliyuncs.com/compatible-mode/v1, } ] )这里有两个关键细节第一model_type参数非常灵活。它不局限于 openai还支持anthropic、google、dashscope、ollama等多种类型。如果你本地有跑 Ollama甚至可以直接接入本地模型实现完全离线的智能体应用。第二base_url的存在让这个框架在国内使用变得很方便。你可以把model_type设为 openai但把base_url指向任何兼容 OpenAI 协议的服务地址。很多国产模型服务都提供了这种兼容模式这让 AgentScope 在模型选择上的自由度变得极高。初始化的时候还有一个值得注意的参数是agentscope.init(seed42)这个 seed 参数可以控制随机数种子保证结果的可复现性。我在调试多智能体流程时非常依赖这个参数因为有时候同样的代码跑两次结果不一样你根本分不清是代码逻辑问题还是模型随机性问题。设置了固定 seed 之后至少排除了一个变量。2.3 快速验证一个最小可运行的 Agent环境配置完成后我先写了一个最简单的单 Agent 程序来验证模型连接是否正常。这一步我强烈建议每个人都做不要跳过去直接写复杂的多智能体逻辑否则出了问题根本不知道是框架问题还是模型配置问题。from agentscope.agent import ReagentAgent agent ReagentAgent( nameassistant, sys_promptYou are a helpful assistant., model_config_namegpt-4o-mini ) response agent(请用一句话介绍你自己。) print(response)注意几个细节name字段是整个 Agent 的唯一标识在消息传递中这个字段非常重要后续 Agent 之间的消息路由都靠它sys_prompt是系统提示词决定了这个 Agent 的角色定位model_config_name必须与init时配置的model_name保持一致。如果你看到终端顺利打印出了回答恭喜你环境搭建这一步已经完成了。接下来就可以开始真正体验 skills 的魅力了。3. 手把手实现 skills 的注册与调用3.1 如何把自定义函数注册为一个 skill框架的 tool 注册机制是我最推荐新手先掌握的技能。它的使用方式非常直观直接在一个普通 Python 函数上加上装饰器它就被注册成了一个可供模型调用的工具。下面是一个完整的示例模拟一个“天气查询”技能import agentscope from agentscope.agent import ReagentAgent agentscope.tool def get_weather(city: str) - str: 查询指定城市的当前天气情况。 Args: city: 城市名称例如“北京”、“上海”。 Returns: 包含天气信息的字符串。 # 这里在实际项目中会调用天气 API weather_data { 北京: 晴25℃, 上海: 多云28℃, 广州: 阵雨30℃ } return weather_data.get(city, f抱歉没有 {city} 的天气数据) agent ReagentAgent( nameweather_agent, sys_prompt你是一个天气助手可以帮助用户查询城市的天气情况。, model_config_namegpt-4o-mini ) # 将该工具注册给 agent agent.register_tool(get_weather) response agent(请问北京今天天气怎么样) print(response)整个过程不需要你手动描述这个函数是干什么的也不需要写参数 schema。AgentScope 会自动从函数名、函数 docstring、参数类型注解、返回值类型注解中提取信息生成一个模型的工具描述。这里的诀窍是要把 docstring 写清楚写得像你在给一个完全不了解这个函数的人解释怎么用它——因为模型本质上就是通过这段描述来理解工具的。我个人的经验是docstring 里必须明确写出每个参数的单位、取值范围和默认行为。模型对于“模糊的描述”容易产生幻觉性的参数值比如把字符串参数填成数字或者把布尔值含义理解反。把参数描述写清楚能有效避免这些问题。3.2 注册与调用 ReagentAgent 作为技能除了工具函数把一个 ReagentAgent 注册为另一个 Agent 的技能是 AgentScope 更高级也更精髓的玩法。场景很好理解你有一个“数据分析专家”Agent你想让一个“项目管理员”Agent 在需要时调用它。这个时候可以把“数据分析专家”整个 Agent 作为技能注入到“项目管理员”的可用工具列表中。from agentscope.agent import ReagentAgent # 创建一个数据分析专家 Agent data_analyst ReagentAgent( namedata_analyst, sys_prompt你是一名资深数据分析师擅长分析结构化数据并提供洞察。, model_config_namegpt-4o-mini ) # 创建一个项目经理 Agent project_manager ReagentAgent( nameproject_manager, sys_prompt你是一个项目管理助手负责协调团队成员并汇总报告。, model_config_namegpt-4o-mini ) # 将 data_analyst 作为技能注册给 project_manager project_manager.register_tool(data_analyst) response project_manager(请数据分析师帮我分析一下我们最近三个月的销售趋势。) print(response)这段代码运行时底层的逻辑是project_manager这个 Agent 在收到用户请求后经过模型推理决定调用名为data_analyst的这个“工具”。框架通过消息机制将请求转发给data_analystAgentdata_analyst独立完成思考后将回复结果作为工具返回值传回给project_manager。project_manager再基于这个结果继续组织自己的最终回答。这和多 Agent 对话的区别在于这种模式下“数据专家”没有自主发话的主动权它只在“项目经理”召唤时才说话。这有点像你在公司里项目经理不会直接去找数据分析师聊天而是通过任务分配的方式让分析师完成特定工作再拿回结果做汇总。这避免了多个 Agent 之间互相“抢话”带来的混乱是实战中非常需要的控制力。3.3 权重参数与调用方式的高级配置AgentScope 的 skills 调用不是只能做“询问-回答”这种简单模式它还可以配置更多的执行细节。我在实际项目中用到的几个进阶参数值得分享execute_tools参数这个参数可以限制 Agent 是否在每一轮推理后都尝试调用工具。默认情况下Agent 会根据用户输入自主决定是否调用工具。但某些场景下你可能希望第一轮强制调用工具、或者完全不调用工具这个参数就能派上用场。它接受一个包含字符串的列表可以精确控制哪一步执行工具调用。max_round参数定义了 Agent 在执行一段任务时的最大交互轮数。这个参数对防止 Agent 陷入死循环或者无意义的来回拉扯很有用。在多 Agent 技能调用链比较深的情况下我会把这个参数调大一些比如 10在简单问答场景我就保持默认避免模型浪费 token 在无关的来回中。此外还有类似stream的参数控制是否流式输出print_message参数控制是否在终端打印中间消息。在开发调试阶段我强烈建议把print_messageTrue打开这样可以非常清晰地看到整个调用链用户消息传给哪个 Agent、哪个 Agent 调用了哪个工具、工具返回了什么内容、最终答案是如何生成的。我在开发早期就因为省事没开这个参数结果面对一个偏离预期的输出完全无从下手排查浪费了很多时间。4. 实战案例用 skills 搭建一个多智能体工作流4.1 案例拆解与角色设计理论讲再多不如一个完整的案例。这里我分享一个我最近搭建的“文章创作助手”系统。这个系统的目的是用户给定一个主题系统自动完成资料整理、初稿撰写、质量审核三个环节最终输出一篇结构完整的文章初稿。整个系统我设计了三个角色主编 Agent负责接收用户需求拆分创作任务调度其他两个 Agent。它的系统提示词里明确写了自己的职责不要自己写文章而是把任务分配给资料员和撰稿人。资料员 Agent一个带了搜索工具的 Agent。它的职责是根据主编提供的主题关键词搜索相关资料并整理成条目。撰稿人 Agent一个负责写作的 Agent。它接收资料员的整理结果结合自己的知识库撰写一篇结构完整的初稿。我把前两个 Agent 注册为工具挂到主编身上然后通过一轮简单的对话触发整个流程。这个设计的巧妙之处在于主编 Agent 并不需要提前决定“先调用谁、后调用谁”它的调度逻辑完全由模型根据用户需求动态决定。当用户说“写一篇关于人工智能的科普文章”时主编会自动判断先让资料员去搜集素材再让撰稿人基于素材写作。如果用户只说“帮我润色一段话”主编则可能直接让撰稿人处理不经过资料员。这种动态调度能力在传统编程里很难实现因为你不可能预先枚举所有用户需求路径。而 AgentScope 的 Agent 嵌套技能让“决策”和“执行”分离模型负责决策工具负责执行这种架构模式非常适合处理开放性任务。4.2 核心代码实现与参数设计我把核心代码简化提炼如下方便你理解整个结构import agentscope from agentscope.agent import ReagentAgent from agentscope.pipeline import pipeline agentscope.init( model_configs[ { model_type: openai, model_name: gpt-4o-mini, api_key: sk-..., } ] ) # 1. 创建资料员 Agent它自带一个检索工具 agentscope.tool def search_web(query: str) - str: 搜索网络获取资料。 Args: query: 搜索关键词。 Returns: 搜索到的资料文本摘要。 # 实际项目中这里会调用搜索 API return f关于 {query} 的搜索结果这是一段模拟资料内容涵盖背景信息、发展现状、未来趋势。 researcher ReagentAgent( nameresearcher, sys_prompt你是一名资料研究员根据用户给出的主题调用搜索工具获取相关资料并整理成清晰的条目。, model_config_namegpt-4o-mini ) researcher.register_tool(search_web) # 2. 创建撰稿人 Agent writer ReagentAgent( namewriter, sys_prompt你是一名资深撰稿人擅长根据资料撰写结构完整、观点清晰的文章。, model_config_namegpt-4o-mini ) # 3. 创建主编 Agent把前两个 Agent 注册为技能 editor ReagentAgent( nameeditor, sys_prompt你是一名内容主编负责协调资源完成创作任务。你可以调用 researcher 获取资料调用 writer 撰写文章。, model_config_namegpt-4o-mini ) editor.register_tool(researcher) editor.register_tool(writer) # 4. 执行任务 result editor(请写一篇关于人工智能伦理的科普文章。) print(result)注意我在这段代码里使用了pipeline模块的导入虽然在这个例子中没有显式使用管道编排但当你需要将这套流程固化为一个确定的执行顺序、而不是依赖模型动态决策时可以用 pipeline 将三个 Agent 串联形成固定的执行流程。动态调度和固定流水线各有优势动态调度灵活适应开放性问题固定流水线稳定适合流程明确的业务场景。两者可以在同一个系统中并存。这里有个参数我没有在前面提到但特别值得补充ReagentAgent创建时支持传入memory参数来配置记忆。默认情况下Agent 的记忆是对话级别的一轮对话结束就清空。但在多 Agent 协作场景中主编可能需要记住整个创作任务的上下文。我在项目里给它配置了共享记忆确保主编能够感知到资料员拿回了什么、撰稿人写了什么。这个能力在长流程任务中非常关键否则多个 Agent 各行其是最终结果就像拼图少了关键几块逻辑上会断。4.3 执行链路分析与结果验证跑完上面这个例子你会在终端看到相当清晰的消息流转记录如果你打开了print_messageTrue。整个链路是这样的用户消息进入editorAgent。editor的模型经过推理决定调用researcher技能并传给它一个搜索请求。框架将请求打包成一条特殊的 msg发送给researcherAgent。researcher收到消息后根据自己的系统提示词决定调用search_web工具。search_web返回模拟资料researcher整理成条目作为回复返回给editor。editor拿到资料后模型再次推理决定调用writer技能要求其撰写文章。writer根据资料撰写文章初稿返回给editor。editor将最终文章作为最终回复返回给用户。这就是一个完整的 Agent 嵌套技能调用链。我在验证时重点检查了两点一是调用链是否按预期顺序执行二是返回给用户的内容是否完整包含了资料员整理的信息。前者通过查看打印消息确认后者通过人工阅读最终文章内容确认。这套工作流上线后我明显感觉到创作类任务的自动化程度大大提升了。以前需要用 prompt 工程小心翼翼地编排多个模型的上下文现在 AgentScope 把这一切变成了标准的工具调用逻辑维护起来轻松很多。5. 常见问题与排查技巧实录5.1 工具注册后未被调用这是我遇到频率最高的问题工具已经注册了函数也没有写错但模型似乎就是“看不到”这个工具回答全靠自己的知识硬编完全不调用外部函数。排查思路有三种按出现概率从高到低排序第一检查sys_prompt里是否提到了这个工具的使用方式。模型确实有从系统提示词中获取信息的倾向如果提示词里完全没提到可以调用工具模型更容易选择直接回答。我后来习惯在系统提示词里显式写一句“你可以使用以下工具来获取信息xxx”效果立竿见影。第二检查函数的 docstring 写得是否“像人话”。如果 docstring 含糊不清模型难以判断这个工具到底能干什么就会倾向于不调用。尽量在每个参数描述里给出具体例子比如“city: 城市名称如‘北京’”这比干巴巴的“城市名”要好得多。第三检查model_config_name对应的模型是否真的支持函数调用。并不是所有模型都有良好的工具调用能力。我在某个模型上测试时发现它的工具调用准确率明显偏低换成一个工具调用能力更强的模型后问题立刻消失了。如果你的应用场景严重依赖工具调用我建议你在选型阶段就把“工具调用成功率”作为重要指标。5.2 Agent 技能嵌套时上下文丢失第二个常见问题是外层 Agent 调用内层 Agent 技能后内层 Agent 返回的结果非常简洁甚至只有一句“已完成”而外层 Agent 无法从这句话中判断具体得到了什么导致最终回答质量很差。这个问题的根源在于我没有在内层 Agent 的系统提示词中明确要求它返回完整的执行结果。ReagentAgent 的回复内容完全由系统提示词和模型决定如果你不告诉它“请完整返回所有处理后的信息”它默认只会给一个精简的总结。我的解决方案是在内层 Agent 的系统提示词末尾统一加上一句“请确保你的回复中包含所有需要传递给上级 Agent 的关键信息不要省略细节。”这个看似简单的调整对最终输出质量的提升非常明显。另外如果你希望内层 Agent 的输出严格结构化可以直接指定输出格式writer ReagentAgent( namewriter, sys_prompt你是一名撰稿人请根据资料撰写文章。, model_config_namegpt-4o-mini )你可以在 sys_prompt 里要求它用特定格式返回比如“请以 JSON 格式返回包含 title 和 content 字段”。AgentScope 会把模型的输出原样作为返回结果所以这个方法是完全可行的。5.3 参数幻觉与类型错误工具调用过程中的参数幻觉问题在模型能力较弱或者参数描述不清时非常容易出现。我遇到过模型把字符串参数填成数字、把枚举值改成完全不存在的内容等状况。要根治这个问题最有效的办法是做好参数约束。我建议你在注册工具时尽量使用Literal或Enum类型注解而不是普通的str。例如from typing import Literal agentscope.tool def send_report(channel: Literal[email, dingtalk, wecom], content: str) - str: 发送报告。 Args: channel: 发送渠道。 content: 报告内容。 Returns: 发送结果。 ...类型约束会让模型在生成参数时只能从枚举值里选从根源上消除参数幻觉。还有一个细节是不要给工具函数设置过于复杂的嵌套结构作为参数。比如让模型传一个多层嵌套的 dict模型的成功率会显著下降。我调整过的最复杂工具参数只有简单的字符串和整数效果非常好。如果一个任务需要复杂参数建议拆成两个简单工具或者让模型先通过简单工具返回一个中间结果。5.4 常见错误速查表整理一份我遇到的问题和对应解决办法速查表供大家快速查阅错误现象可能原因解决办法工具函数被调用但参数报错参数类型注解缺失或错误补全类型注解尤其注意 Literal 的使用Agent 嵌套调用返回空内容内层 Agent 输出为空可能是模型问题或提示词引导设置max_round增大轮数检查模型输出模型极其频繁调用同一个工具sys_prompt 中没有约束工具的调用时机在系统提示词中明确“只在需要时调用工具”调用工具后模型仍重复调用工具有效但没有一次调用成功的结果检查工具函数内部的返回逻辑是否完备消息卡在某个 Agent 不继续流转该 Agent 没有register_tool或模型配置错误逐一验证单 Agent 是否能独立工作6. 经验总结与提速技巧6.1 关于技能颗粒度的取舍我用 AgentScope 一段时间后最深的一个体会是技能的“颗粒度”设计直接决定了整个系统的复杂度和稳定性。颗粒度太粗一个技能内部包含了太多不可控环节出现问题难以定位颗粒度太细则一个简单任务需要串联十几个技能既消耗 token 又增加延迟。我的经验准则是一个技能应该只做一件“可描述清楚、可独立验证”的事。比如“搜索并整理资料”是一个合理的技能“完成整个项目”就不是一个合理的技能因为它的内部还是得拆。把技能设计成类似“函数”一样的行为——输入明确输出明确内部逻辑对调用方透明——这样整个系统的可维护性会非常高。6.2 资源消耗的优化经验多智能体应用最让人肉疼的就是 token 消耗。一套三个 Agent 的流程跑下来可能消耗掉单 Agent 三到五倍的 token。我优化资源消耗的三个方法第一用便宜的模型跑低难度环节。资料整理、简单问答可以交给参数量较小的模型只有最终内容生成才调用更强的模型。AgentScope 允许不同 Agent 使用不同的model_config_name这让我可以很自然地做模型分层。第二精简系统提示词。很多人写 sys_prompt 喜欢长篇大论但模型每次对话都会把系统提示词计入 token 消耗。在保证角色定位明确的前提下提示词越短越好。一个技巧是把不需要每轮都出现的细节放到用户消息里按需提供而不是写死在系统提示词中。第三善用记忆管理。AgentScope 的记忆机制默认会保存完整对话历史当对话轮数很多时token 消耗呈线性增长。如果你的场景是“一次性任务型”的不需要每轮都参考前面的对话可以对 Agent 做记忆清理。我在实际项目中会给每个技能 Agent 配置一个独立的短期记忆任务完成后自动清空避免在长流程中累积无用的历史消息。6.3 调试阶段的三个独家技巧最后分享三个调试阶段我觉得特别实用的技巧第一个技巧是打印中间消息。这个建议我在前面已经提过但重要性值得重复print_messageTrue是 AgentScope 开发者最好的朋友。它打印出来的消息流转记录能让你像看剧本一样看到每个 Agent 在想什么、做了什么。我上线前调试所有流程都会开着它确认无误后再关闭。第二个技巧是分段验证技能。不要一上来就组装完整的多步流程。我习惯先把工具函数单独用 Python 调一遍确认函数本身没问题再把工具挂到一个最小 Agent 上测试模型能否正确调用最后才把多个技能组装成完整系统。每层都验证通过才能保证上层出问题时能快速定位到具体环节。第三个技巧是利用seed参数做可复现调试。多智能体系统的输出有很大随机性但设置了agentscope.init(seed42)之后在同一个环境下多次运行输出的结果会趋于一致。这对于在调试时对比不同 prompt 的效果非常有价值相当于给模型的行为装了一个“录回放”功能。说实话AgentScope 的 skills 机制本身的实现并不复杂复杂的是如何设计出一套适合你业务场景的分工体系。工具注册、Agent 嵌套、pipeline 编排这些能力给了你充分的自由但也考验你对任务拆解的判断力。我建议新手先用最小的案例把工具注册和调用跑通再逐步叠加 Agent 嵌套和流水线编排每一步都确认无误再往前走。这套框架的上手曲线在同类工具里算是很平缓的只要耐下心来把每个环节捋清楚你会发现多智能体应用的开发效率能比传统方案高出不少。
