简介这份PDF资料源自北大青鸟人工智能研究院、北大计算机学院及北大教育学院学习科学实验室联合发布的讲座内容面向对AI工具感兴趣的技术探索者、效率实践者及希望提升工作效率的专业人士。它跳出单纯讲解工具使用的思路以完成任务为核心主线围绕知识探索与深度研究、行业洞察与时机分析、内容创作与媒体制作、创意设计与成果转换四大高频场景系统梳理Manus、Skywork、Genspark、扣子空间等11个AI Agent产品的特点与协同策略并配有案例解析与操作指南。资源包为1个PDF文件大小约27.03MB内容涵盖AI工具全景概览、各Agent基础操作及场景化应用路径便于按目录模块检索学习。目前已有29人学习适合希望借助AI Agent完成文献综述、行业调研、公众号日更、播客制作、品牌营销设计等任务的读者从中找到适合自己的最佳拍档。1. 从单点工具到“最佳拍档”AI Agent 协同到底在解决什么问题很多人用 AI 工具的现状是写文案开一个窗口查资料开另一个做表格再换一个最后人肉在中间搬运。单点工具再强链路一长就断。AI Agent 协同要解决的不是“再找一个更强的模型”而是让多个 Agent 各管一段、互相交接把一条完整任务链跑通。北京大学这套面向场景实战的协同指南核心思路就是把 AI Agent 当成团队里的角色来编排而不是当成一个万能问答框。它适合已经用过 Coze、Manus 这类平台、想从“单次对话”升级到“多步任务自动化”的从业者也适合想搞清楚 agent 开发到底怎么落地的新手。读完你能判断自己的场景该不该上多 Agent以及怎么用最小成本搭出第一条协同链路。2. 拆解 AI Agent 协同角色分工、上下文传递与工具调用2.1 为什么单 Agent 撑不住复杂场景一个 Agent 干所有事最先崩的不是模型能力而是上下文。你让它先检索、再分析、再写报告、再转格式中间每一步都会往上下文里塞内容到后面模型开始“忘事”前面查到的数据它记不住格式要求它也对不上。这不是玄学是上下文窗口和注意力分配的现实约束。常见做法是把任务拆成几个专职 Agent一个负责信息收集一个负责分析归纳一个负责产出格式化结果。每个 Agent 只关心自己那一段的输入输出上下文干净出错也容易定位。这就是协同的第一层价值——用分工换稳定。第二层价值是工具调用的隔离。检索 Agent 需要联网和爬取工具写作 Agent 需要文档生成工具如果全塞给一个 Agent工具描述会互相干扰模型经常选错工具。分开之后每个 Agent 的工具集小而准调用成功率明显上升。第三层是复用。你把“资料收集”这个 Agent 调好之后换一个写作 Agent 就能复用到另一个场景不用从头再训一遍提示词。协同架构本质上是把提示词工程变成了可组装的模块。2.2 协同的三种主流拓扑串行、并行、带仲裁落地时不用想太复杂先认清三种基本拓扑。串行链路最简单Agent A 输出直接喂给 Agent BB 再喂给 C。适合流程固定、步骤有先后依赖的场景比如“收集竞品信息 → 对比分析 → 生成报告”。优点是实现快缺点是任何一环卡住整条链就停。并行链路是多个 Agent 同时处理同一份输入的不同维度最后汇总。比如一份用户反馈一个 Agent 做情感分类一个做关键词提取一个做优先级排序三份结果再合并。适合分析类任务能压缩总耗时。带仲裁的拓扑多了一个“调度 Agent”或“评审 Agent”它决定任务分给谁、结果是否合格、要不要重跑。这是最接近“最佳拍档”的形态也是 Coze 工作流和多数 agent 框架里最值得花时间调的部分。仲裁 Agent 的提示词要写清楚验收标准否则它会放行明显不合格的结果。选哪种拓扑看你的任务有没有固定步骤、能不能并行、需不需要质量兜底。新手建议从串行开始跑通再加并行和仲裁。2.3 用 Coze 工作流搭一条最小协同链路下面用 Coze 工作流的方式描述一条“资料收集 → 摘要 → 格式化输出”的串行链路。不同平台节点名称略有差异但逻辑一致。# 伪配置描述一条串行 Agent 协同链路 workflow: name: research_to_report nodes: - id: collector # 收集 Agent type: agent tools: [web_search, page_fetch] prompt: | 你是资料收集员。根据用户主题检索并抓取 5 条以上来源 只输出结构化要点每条包含来源标题和核心事实不要评论。 output_key: raw_points - id: summarizer # 摘要 Agent type: agent input: ${raw_points} prompt: | 你是分析员。基于以下要点归纳 3 个核心结论 每个结论必须能追溯到至少一条来源不要引入新事实。 output_key: summary - id: formatter # 格式化 Agent type: agent input: ${summary} prompt: | 你是排版员。把结论整理成 Markdown 表格 列为结论 / 依据来源 / 可信度高/中/低。 output_key: final_output逻辑说明collector 只负责“拿到料”不负责判断summarizer 只负责“归纳”且被约束不能引入新事实防止模型自由发挥formatter 只负责“排版”不碰内容。三个 Agent 的职责边界写死在提示词里这是协同能跑稳的关键。参数说明tools只给 collector 配检索和抓取其他 Agent 不给联网工具避免它们自己去查导致结果不一致。input用变量引用上一步输出保证上下文只传必要内容。output_key是节点间传递的字段名命名要语义化后面排查时一眼能看出数据从哪来。跑通这条链路后你会得到一个可复用的骨架换掉 collector 的检索源就能变成另一个场景换掉 formatter 的输出格式就能对接不同下游。2.4 上下文传递协同里最容易翻车的地方多 Agent 协同最常见的翻车不是模型不行是上下文传丢了或传脏了。传丢是指上一步的输出没正确引用到下一步Agent 拿到空输入还在硬编。传脏是指把上一步的中间过程、调试信息、无关字段全塞给下一步模型被干扰。我一般会做三件事第一每个节点的输出只保留下游需要的字段多余的在节点内消化掉第二在提示词里明确“你只接收以下字段”让模型知道边界第三加一个校验节点或校验逻辑输入为空或格式不对时直接报错不要让它带着空数据往下跑。还有一个隐蔽的坑变量名冲突。两个节点都叫output引用时就乱了。命名带上节点前缀比如collector_points、summarizer_summary排查时省很多时间。3. 从 0 到 1 搭建可用的 AI Agent 协同选型、编排与调试3.1 平台选型Coze、Dify、自研框架怎么选选型先看你的团队和场景不要一上来就自研。Coze 适合快速验证和轻量场景工作流可视化插件生态现成文件上传、Markdown 转 Word 这类常见需求有现成节点。缺点是深度定制受限复杂仲裁逻辑写起来别扭。Dify 适合需要一定定制、又想保留可视化编排的团队对模型接入和 RAG 支持更灵活适合做知识库类 Agent 协同。自研框架比如基于 Spring AI 或类似方案适合有明确工程团队、需要和内部系统深度打通的场景比如 Agent 要和 PLC 编程、内部工单系统联动。代价是开发周期长调试工具要自己搭。我的建议先用 Coze 或 Dify 把协同链路跑通验证场景价值再决定要不要自研。很多需求在可视化平台里就能满足自研是最后一步不是第一步。3.2 编排实战把任务拆成 Agent 能接住的粒度拆任务的原则是每个 Agent 的输入输出能用一句话说清。说不清就是拆得不够或拆错了。# 任务拆解检查清单伪代码用于人工评审 def check_agent_task(task_desc): checks { 输入明确: 能否列出这个 Agent 接收哪些字段, 输出明确: 能否用一句话描述它产出什么, 边界清晰: 它不负责什么是否写进提示词, 可独立测试: 能否单独喂输入验证输出, } for name, question in checks.items(): if not answer_yes(question): return f任务粒度不合格{name} 不通过 return 可进入编排逻辑说明这段不是运行代码是拆任务时的自检逻辑。四个检查项对应协同里最常见的四类问题——输入不明导致空跑输出不明导致下游接不住边界不清导致 Agent 越权不可独立测试导致出问题无法定位。参数说明task_desc是你要拆的原始任务描述。实际使用时每个 Agent 都过一遍这个清单任何一项不通过就继续拆或合并。粒度太细会导致节点过多、传递损耗大粒度太粗会导致单个 Agent 上下文过载。一般一条链路 3 到 5 个 Agent 比较舒服。3.3 调试方法怎么定位是哪个 Agent 出了问题协同链路出问题时不要从头到尾重跑要分段验证。第一步单独测每个 Agent。给它构造好的输入看输出是否符合预期。这一步能排除大部分提示词问题。第二步测相邻两个 Agent 的交接。把上游真实输出喂给下游看下游能不能正确解析。很多问题出在格式不匹配比如上游输出带 Markdown 标记下游按纯文本解析。第三步全链路跑但在每个节点后打印输入输出。日志要包含节点名、输入字段、输出字段、耗时。这样一眼能看出是哪一步开始偏的。第四步如果某一步输出不稳定先降低该 Agent 的自由度收紧提示词、减少可选工具、固定输出格式。稳定性优先于聪明。3.4 让协同结果可验证加一个评审 Agent产出类任务建议加一个评审 Agent它的职责不是生成是挑毛病。- id: reviewer type: agent input: ${final_output} prompt: | 你是评审员。检查以下产出是否满足 1. 每个结论都有来源支撑 2. 格式符合要求 3. 没有明显事实错误。 对每条给出通过/不通过不通过要说明原因。 只输出评审结果不要重写内容。 output_key: review_result逻辑说明评审 Agent 和生成 Agent 分开避免“自己批自己”放水。它的输出是结构化的通过/不通过方便后续做条件分支——不通过就回退到对应节点重跑。参数说明评审标准要具体可判定不要写“质量高”这种模糊词。output_key单独命名方便在工作流里加条件判断节点。评审 Agent 不建议给联网工具它只基于已有产出判断避免引入新变量。4. 协同链路的避坑与排查那些让我重跑十几次的问题4.1 坑一Agent 之间格式不匹配下游直接解析失败现象上游输出一段带标题和列表的文本下游 Agent 按 JSON 解析直接报错或拿到空值。原因每个 Agent 的输出格式没有统一约定上游按自己习惯输出下游按自己预期解析。解决在链路层面约定中间格式常用 JSON 或固定字段的 Markdown。每个 Agent 的提示词里明确“输出必须符合以下格式”并在节点后加格式校验。校验不通过就重试或报错不要带着坏数据往下走。4.2 坑二上下文越传越长后面 Agent 开始“失忆”现象链路跑到第三、四个 Agent 时它开始忽略前面的要求或者把早期信息搞混。原因每一步都把完整历史塞进上下文窗口被占满模型注意力被稀释。解决每个节点只传下游必需的字段不传完整历史。需要追溯的信息用摘要形式传递不要原文堆砌。如果确实需要长上下文考虑在关键节点做一次压缩归纳。4.3 坑三工具调用冲突Agent 选错工具现象一个 Agent 配了多个工具它频繁调用错误的那个或者该调工具时它直接编答案。原因工具描述太相似或者工具太多导致模型选择困难。解决每个 Agent 的工具集控制在 3 个以内工具描述写清楚“什么时候用我”。如果两个工具功能接近合并或明确分工。对于不该编答案的场景在提示词里写死“没有工具结果时不要猜测”。4.4 坑四评审 Agent 放水不合格结果被放行现象评审 Agent 几乎全部通过但人工一看产出质量很差。原因评审标准太模糊或者评审 Agent 和生成 Agent 用了相似的提示词风格导致它倾向于认可。解决评审标准写成可判定的条目每条要有明确的通过条件。评审 Agent 的提示词要和生成 Agent 明显不同强调“找问题”而不是“给好评”。可以先用一批已知好坏的样本测试评审 Agent 的判断力。4.5 坑五链路没有超时和重试一个节点卡死整条链现象某个 Agent 调用外部工具超时整条链路挂起没有任何输出。原因没有设置节点级超时和失败处理。解决每个节点设超时时间超时后走降级逻辑或报错。关键节点加重试但重试次数要限制避免无限循环。整条链路也要有总超时防止个别节点拖垮整体。5. 进阶技巧用协同思维把 AI 工具变成真正的“最佳拍档”跑通基础链路之后真正拉开差距的是两件事一是让协同具备自适应能力二是把协同结果沉淀成可复用资产。自适应能力指的是链路能根据输入动态调整。比如一个内容生成场景输入是短需求时走“轻量链路”两个 Agent输入是复杂需求时走“完整链路”四个 Agent 加评审。实现方式是在入口加一个路由 Agent它判断任务复杂度并决定走哪条分支。路由 Agent 的提示词要给出明确的判断标准比如按输入字数、涉及维度数量、是否需要外部数据来分档。沉淀可复用资产重点是把调好的 Agent 提示词、工具配置、中间格式约定存成模板。下次遇到相似场景直接复用收集 Agent 和评审 Agent只换生成 Agent。我一般会维护一个自己的 Agent 模板库按职能分类收集类、分析类、生成类、评审类。每类里存几个调优过的版本用的时候按场景挑。还有一个容易被忽略的技巧给协同链路加“后悔药”。也就是在每个关键节点保留输入输出快照出问题时能回放到任意一步而不是从头重跑。Coze 和 Dify 的工作流一般有执行记录但保留时间有限重要链路建议自己落一份日志到本地或数据库。日志字段至少包含链路 ID、节点名、输入、输出、耗时、状态。有了这份日志排查效率能提升一个量级。验证协同效果不要只看最终产出要看每个节点的通过率和重试率。某个节点重试率一直很高说明它的提示词或工具配置有问题优先优化它。整体链路的一次通过率能到 80% 以上基本就可以投入日常使用了。我自己踩过最深的坑是过早追求“全自动”。一开始就想让链路无人值守跑完所有任务结果每个环节的小问题叠加整体成功率惨不忍睹。后来改成“关键节点人工确认”反而跑得更稳等某个节点稳定了再放开自动。协同不是一步到位是逐步放权的过程。希望帮到你。本文还有配套的精品资源点击获取