简介：这份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 B，B 再喂给 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% 以上，基本就可以投入日常使用了。

我自己踩过最深的坑是过早追求“全自动”。一开始就想让链路无人值守跑完所有任务，结果每个环节的小问题叠加，整体成功率惨不忍睹。后来改成“关键节点人工确认”，反而跑得更稳，等某个节点稳定了再放开自动。协同不是一步到位，是逐步放权的过程。希望帮到你。

本文还有配套的精品资源，点击获取