本期博客学习第十章https://github.com/bojieli/ai-agent-book/blob/main/chapter10/README.md第十章的标题是多agent协作我最近也正好想搭建多gent在钉钉处理我的工作任务正好借这个机会了解下这种模式有什么利弊需要我和agent之间怎么协作。实验10-1 multi-role-transfer 比较角色切换与按需加载技能这个实验的核心目标是了解多agent任务里在同一个会话中让agent自己去判断自动吧任务交给不同的专业角色skill去做。实验开头需要先配置环境# 从仓库根目录开始使用共享的第 10 章环境 uv sync --locked --python 3.12 --extra ch10 切换目录前先激活环境 macOS/Linux: source .venv/bin/activate cd chapter10/multi-role-transfer配置大模型key# 配置 key二选一 export OPENAI_API_KEYyour-openai-api-key # 直接 export export TAVILY_API_KEYyour-tavily-key # research.web_search 必需无 mock fallback # 或 cp env.example .env 后填写做到这一步我有点疑惑着三行是什么意思通过查阅资料了解到这一步主要是配置两个apikey一个是openai的一个是tavily的。Tavily 是第三方网页检索服务器。我的方案是实验里的全集任务都要跑并且都是用千问模型不用openai。实验中配了三个skillcoding、writing、research那为什么要配置Tavily不能用模型自带的工具去完成research呢一是这个实验这个实验考察的是Agent 架构里检索是一个独立可插拔的外部工具。二是千问内置搜索是 “模型平台打包在一起” 的黑盒搜索模型和搜索绑定不利于观察【工具解耦】这个要点Tavily 模式模型 ↔ 检索工具两层分离Agent 显式发起工具调用我们作为开发者角度能看到搜索 query、返回的网页原文片段可控、可观测而模型自带联网工具是平台内部封装看不到搜索中间过程检索逻辑被平台藏起来了。跑完这个实验看到了agent之间的分工我只想说真的太可怜完美适配我当下的卡点想试着从这个方向做切入点做好自己工作流程的优化工具之间的每一步交互思考内容经过几轮思考skill之间的分工都非常清晰。1、先对整体流程有个基础的认知这是一套分工式多 Agent角色移交 的执行链路核心机制所有 Agent 共享同一份对话上下文每个 Agent 只拥有自己的一套专属工具只能通过transfer_to_agent把会话交给别的角色附带移交理由 reason不能直接调用别的角色的工具。任务被拆成4个环节模型之间自动承接任务不需要人工干预。2、通过拆解这段日志详细的学习一下每一个步骤背后的设计思想1traige领取任务2阶段一拆解复合任务1大模型以 triage 的系统提示词做身份约束读取全部用户需求2triage 内部推理任务第一步需要互联网实时事实数据属于 research 的职责3triage 自身没有web_search工具不能自己联网4调用唯一可用工具transfer_to_agent目标 agent 名称写research同时输出 reason移交理由用于日志可观测5系统底层动作把活跃角色切换为 research完整对话上下文原样传递过去不截断、不丢失用户三条需求。3阶段二第一次 web_search 调用query11research 读取完整上下文用户要三年销量需要拿到精确数字2research 可用工具二选一web_search /transfer_to_agent。现在缺少数据所以选择web_search3构造第一个搜索 query作为入参传给工具4工具函数底层发起 POST 请求到 Tavily 的搜索 API带上 query、你的 TAVILY_API_KEY5Tavily 服务内部拿着这个 query 检索互联网抓取一批匹配网页做摘要压缩组装 json 返回给我们的程序6返回结果解读Tavily 这次搜到的网页里没有同时集齐 21/22/23 三年准确销量数字answer 字段直接告知缺少目标数据7research千问读到这个返回结果推理判断当前搜索词太宽泛搜不到精准数据需要改写 query 再次搜索不移交。4第三阶段第二次 web_search 调用query2:1模型反思上一轮搜索失败原因缺少权威数据源限定词新能源销量官方发布方是【中国汽车工业协会】2重构 query加入权威机构名称再次调用 web_search3再次请求 Tavily 接口独立新一轮全网检索4这次 Tavily 返回的网页摘要里拿到了 2022、2023 的两组数据688.7 万、829.2 万5模型校验还差 2021 年的数据信息不全不能移交下游继续搜索。这一次搜索池和上一次不一样因为搜索词变了5第四阶段第三次 web_search 调用query3:1现在已经有 22、23缺 21模型选择拆成单年精准查询2第三次调用 web_search新 query 只查 2021 中汽协3Tavily 新一轮检索返回 2021 数据352.1 万4模型校验上下文内收集到的数据2021352.1 万2022688.7 万2023829.2 万 ✅ 三年数据全部集齐信息需求满足停止调用 web_search5research 内部判断我的职责是搜集事实数据数据已经齐了计算 CAGR 不属于我的能力范围我没有 calculate 工具6所以调用 transfer_to_agent移交给 data_analysis。移交的时候三年销量数据全部留在共享上下文里data_analysis 可以直接读到。6data_analysis开始干活1data_analysis 读取上下文拿到三组销量、用户要求计算 CAGR2CAGR 公式CAGR (期末值 / 期初值) ^ (1/间隔年数) − 1期初 2021期末 2023间隔 2 年所以开 1/2 次方3选择工具calculate把数学表达式作为参数传入4calculate 是本地安全求值工具不是调用外部 API本地 Python 求值返回小数 0.5346也就是 53.46%5模型校验计算完成data_analysis 只负责定量计算统计不负责写投资人文稿没有文字润色、字数统计的工具6调用 transfer_to_agent移交 writing上下文携带原始销量 CAGR 结果。7writing1writing 读取上下文拿到全部数据、CAGR、约束条件面向投资人、≤120 字2模型生成符合风格的中文总结文案3用户有硬性字数约束writing 自带工具count_characters本地工具统计文本字符4传入生成好的文本执行字数校验返回 107 字满足 ≤120 的限制如果这里字数超过 120writing 会改写文本、重新调用 count_characters 反复校验直到合规5校验通过写作任务闭环writing 角色职责完成没有后续子任务6调用 transfer_to_agent交还控制权给 triage入口角色统一对外输出。8活跃角色回到 triage输出最终回复triage 不再做推理、不再移交只把上下文里已经产出好的定稿整理成友好格式返回给用户。拆解任务步骤之后有几个风险点也随之暴露1、搜索是串行的这样效率比较慢怎么做优化2、Tavily给错数字后面的计算也会出错怎么前置的规避这个问题3、traige的路由依赖模型对齐模糊需求是不是容易移交错角色自己在网上找了对应的优化方案记录一下1、搜索效率优化方案1预生成多候选 query并行搜索。research 拿到信息需求之后一次性生成 3~5 条差异化搜索 query不同关键词、不同权威数据源并发调用 Tavily一次性拿到多组检索结果再做结果融合、去重、筛选有效数据。2增加 query 质量提示词减少重试次数。给 research 角色的系统 prompt 增强约束要求优先指定权威来源、限定时间范围、精准字段尽量一次命中目标数据从源头减少反复试错。 比如强制要求构造query时带上权威机构名称、年份尽量一次拿到全部需要指标避免多次迭代搜索。3增加检索缓存层。搭建本地缓存query 时间窗口作为 key短时间内相同搜索词直接返回缓存结果不用重复调用 Tavily API。适合重复测试、eval 批量跑 case 的场景。2、强单点依赖规避水线单点故障风险1多源检索交叉校验。同时调用多个检索源Tavily 备选检索服务比如 bocha、serpapi拿到多份独立来源的数据。research 增加校验逻辑对比不同来源的数值只有多个来源数字一致才采信数据冲突时标记异常不直接往下游移交退回 triage 告警或者重新检索。2增加事实校验子步骤 / 校验 Agent。在 research 拿到数据之后、移交数据分析之前插入校验环节校验规则年份、数值范围、环比 / 同比逻辑是否符合常识异常判定比如销量几千万这种明显不符合常识的离谱数字识别出来拒绝向下传递。 我们这次日志里 Tavily 返回的688.7 million本身就是错误单位写错应该是万不是百万校验环节就可以拦截掉。3给下游角色增加告警能力。data_analysis、writing 增加数据合理性自检如果数值明显异常不继续输出最终文稿主动调用 transfer_to_agent 回退到 research 重新核查数据而不是基于错误数据产出结论。4输出溯源标注最终结果附带数据来源链接方便人工复核。3、triage 路由判断依赖模型对齐模糊需求容易移交错角色1增强 triage 系统提示词 明确判定规则。triage 的 system prompt 里写死清晰的判定清单、边界 case。比如只要需要外网实时事实优先交给 research明确每个角色的职责边界、禁止范围分不清的时候不要强行路由可以询问用户澄清需求而不是随便移交。2把路由从纯 LLM 判断改成【LLM 提取特征 硬规则兜底】混合路由。先用模型提取需求标签是否需要联网、是否需要代码执行、是否是纯文本写作、是否需要数学计算 然后写规则引擎做兜底路由。3增加路由评审 Agent。triage 生成移交决策目标角色 reason之后先交给一个轻量的 reviewer 角色专门复核路由是否合理 评审不通过打回 triage 重新判断。适合高稳定性要求的场景。4多轮澄清机制。当triage 对路由结果置信度低的时候模型输出置信标记不强行移交主动向用户提问澄清需求“你的需求同时包含查数据、写代码我需要确认优先完成哪一部分” 
长河君 · 2026/10/28 10:22:50 · 阅读 1.2k 跟着Datawhale打卡·【ai-agent-book：从入门到 Agent 工程实践】学习笔记Task5
本期博客学习第十章https://github.com/bojieli/ai-agent-book/blob/main/chapter10/README.md第十章的标题是多agent协作我最近也正好想搭建多gent在钉钉处理我的工作任务正好借这个机会了解下这种模式有什么利弊需要我和agent之间怎么协作。实验10-1 multi-role-transfer 比较角色切换与按需加载技能这个实验的核心目标是了解多agent任务里在同一个会话中让agent自己去判断自动吧任务交给不同的专业角色skill去做。实验开头需要先配置环境# 从仓库根目录开始使用共享的第 10 章环境 uv sync --locked --python 3.12 --extra ch10 切换目录前先激活环境 macOS/Linux: source .venv/bin/activate cd chapter10/multi-role-transfer配置大模型key# 配置 key二选一 export OPENAI_API_KEYyour-openai-api-key # 直接 export export TAVILY_API_KEYyour-tavily-key # research.web_search 必需无 mock fallback # 或 cp env.example .env 后填写做到这一步我有点疑惑着三行是什么意思通过查阅资料了解到这一步主要是配置两个apikey一个是openai的一个是tavily的。Tavily 是第三方网页检索服务器。我的方案是实验里的全集任务都要跑并且都是用千问模型不用openai。实验中配了三个skillcoding、writing、research那为什么要配置Tavily不能用模型自带的工具去完成research呢一是这个实验这个实验考察的是Agent 架构里检索是一个独立可插拔的外部工具。二是千问内置搜索是 “模型平台打包在一起” 的黑盒搜索模型和搜索绑定不利于观察【工具解耦】这个要点Tavily 模式模型 ↔ 检索工具两层分离Agent 显式发起工具调用我们作为开发者角度能看到搜索 query、返回的网页原文片段可控、可观测而模型自带联网工具是平台内部封装看不到搜索中间过程检索逻辑被平台藏起来了。跑完这个实验看到了agent之间的分工我只想说真的太可怜完美适配我当下的卡点想试着从这个方向做切入点做好自己工作流程的优化工具之间的每一步交互思考内容经过几轮思考skill之间的分工都非常清晰。1、先对整体流程有个基础的认知这是一套分工式多 Agent角色移交 的执行链路核心机制所有 Agent 共享同一份对话上下文每个 Agent 只拥有自己的一套专属工具只能通过transfer_to_agent把会话交给别的角色附带移交理由 reason不能直接调用别的角色的工具。任务被拆成4个环节模型之间自动承接任务不需要人工干预。2、通过拆解这段日志详细的学习一下每一个步骤背后的设计思想1traige领取任务2阶段一拆解复合任务1大模型以 triage 的系统提示词做身份约束读取全部用户需求2triage 内部推理任务第一步需要互联网实时事实数据属于 research 的职责3triage 自身没有web_search工具不能自己联网4调用唯一可用工具transfer_to_agent目标 agent 名称写research同时输出 reason移交理由用于日志可观测5系统底层动作把活跃角色切换为 research完整对话上下文原样传递过去不截断、不丢失用户三条需求。3阶段二第一次 web_search 调用query11research 读取完整上下文用户要三年销量需要拿到精确数字2research 可用工具二选一web_search /transfer_to_agent。现在缺少数据所以选择web_search3构造第一个搜索 query作为入参传给工具4工具函数底层发起 POST 请求到 Tavily 的搜索 API带上 query、你的 TAVILY_API_KEY5Tavily 服务内部拿着这个 query 检索互联网抓取一批匹配网页做摘要压缩组装 json 返回给我们的程序6返回结果解读Tavily 这次搜到的网页里没有同时集齐 21/22/23 三年准确销量数字answer 字段直接告知缺少目标数据7research千问读到这个返回结果推理判断当前搜索词太宽泛搜不到精准数据需要改写 query 再次搜索不移交。4第三阶段第二次 web_search 调用query2:1模型反思上一轮搜索失败原因缺少权威数据源限定词新能源销量官方发布方是【中国汽车工业协会】2重构 query加入权威机构名称再次调用 web_search3再次请求 Tavily 接口独立新一轮全网检索4这次 Tavily 返回的网页摘要里拿到了 2022、2023 的两组数据688.7 万、829.2 万5模型校验还差 2021 年的数据信息不全不能移交下游继续搜索。这一次搜索池和上一次不一样因为搜索词变了5第四阶段第三次 web_search 调用query3:1现在已经有 22、23缺 21模型选择拆成单年精准查询2第三次调用 web_search新 query 只查 2021 中汽协3Tavily 新一轮检索返回 2021 数据352.1 万4模型校验上下文内收集到的数据2021352.1 万2022688.7 万2023829.2 万 ✅ 三年数据全部集齐信息需求满足停止调用 web_search5research 内部判断我的职责是搜集事实数据数据已经齐了计算 CAGR 不属于我的能力范围我没有 calculate 工具6所以调用 transfer_to_agent移交给 data_analysis。移交的时候三年销量数据全部留在共享上下文里data_analysis 可以直接读到。6data_analysis开始干活1data_analysis 读取上下文拿到三组销量、用户要求计算 CAGR2CAGR 公式CAGR (期末值 / 期初值) ^ (1/间隔年数) − 1期初 2021期末 2023间隔 2 年所以开 1/2 次方3选择工具calculate把数学表达式作为参数传入4calculate 是本地安全求值工具不是调用外部 API本地 Python 求值返回小数 0.5346也就是 53.46%5模型校验计算完成data_analysis 只负责定量计算统计不负责写投资人文稿没有文字润色、字数统计的工具6调用 transfer_to_agent移交 writing上下文携带原始销量 CAGR 结果。7writing1writing 读取上下文拿到全部数据、CAGR、约束条件面向投资人、≤120 字2模型生成符合风格的中文总结文案3用户有硬性字数约束writing 自带工具count_characters本地工具统计文本字符4传入生成好的文本执行字数校验返回 107 字满足 ≤120 的限制如果这里字数超过 120writing 会改写文本、重新调用 count_characters 反复校验直到合规5校验通过写作任务闭环writing 角色职责完成没有后续子任务6调用 transfer_to_agent交还控制权给 triage入口角色统一对外输出。8活跃角色回到 triage输出最终回复triage 不再做推理、不再移交只把上下文里已经产出好的定稿整理成友好格式返回给用户。拆解任务步骤之后有几个风险点也随之暴露1、搜索是串行的这样效率比较慢怎么做优化2、Tavily给错数字后面的计算也会出错怎么前置的规避这个问题3、traige的路由依赖模型对齐模糊需求是不是容易移交错角色自己在网上找了对应的优化方案记录一下1、搜索效率优化方案1预生成多候选 query并行搜索。research 拿到信息需求之后一次性生成 3~5 条差异化搜索 query不同关键词、不同权威数据源并发调用 Tavily一次性拿到多组检索结果再做结果融合、去重、筛选有效数据。2增加 query 质量提示词减少重试次数。给 research 角色的系统 prompt 增强约束要求优先指定权威来源、限定时间范围、精准字段尽量一次命中目标数据从源头减少反复试错。 比如强制要求构造query时带上权威机构名称、年份尽量一次拿到全部需要指标避免多次迭代搜索。3增加检索缓存层。搭建本地缓存query 时间窗口作为 key短时间内相同搜索词直接返回缓存结果不用重复调用 Tavily API。适合重复测试、eval 批量跑 case 的场景。2、强单点依赖规避水线单点故障风险1多源检索交叉校验。同时调用多个检索源Tavily 备选检索服务比如 bocha、serpapi拿到多份独立来源的数据。research 增加校验逻辑对比不同来源的数值只有多个来源数字一致才采信数据冲突时标记异常不直接往下游移交退回 triage 告警或者重新检索。2增加事实校验子步骤 / 校验 Agent。在 research 拿到数据之后、移交数据分析之前插入校验环节校验规则年份、数值范围、环比 / 同比逻辑是否符合常识异常判定比如销量几千万这种明显不符合常识的离谱数字识别出来拒绝向下传递。 我们这次日志里 Tavily 返回的688.7 million本身就是错误单位写错应该是万不是百万校验环节就可以拦截掉。3给下游角色增加告警能力。data_analysis、writing 增加数据合理性自检如果数值明显异常不继续输出最终文稿主动调用 transfer_to_agent 回退到 research 重新核查数据而不是基于错误数据产出结论。4输出溯源标注最终结果附带数据来源链接方便人工复核。3、triage 路由判断依赖模型对齐模糊需求容易移交错角色1增强 triage 系统提示词 明确判定规则。triage 的 system prompt 里写死清晰的判定清单、边界 case。比如只要需要外网实时事实优先交给 research明确每个角色的职责边界、禁止范围分不清的时候不要强行路由可以询问用户澄清需求而不是随便移交。2把路由从纯 LLM 判断改成【LLM 提取特征 硬规则兜底】混合路由。先用模型提取需求标签是否需要联网、是否需要代码执行、是否是纯文本写作、是否需要数学计算 然后写规则引擎做兜底路由。3增加路由评审 Agent。triage 生成移交决策目标角色 reason之后先交给一个轻量的 reviewer 角色专门复核路由是否合理 评审不通过打回 triage 重新判断。适合高稳定性要求的场景。4多轮澄清机制。当triage 对路由结果置信度低的时候模型输出置信标记不强行移交主动向用户提问澄清需求“你的需求同时包含查数据、写代码我需要确认优先完成哪一部分”