简介这份PDF资料源自北大青鸟人工智能研究院、北大计算机学院及北大教育学院学习科学实验室联合发布的讲座内容面向对AI工具感兴趣的技术探索者、效率实践者以及希望提升工作与学习效率的专业人士。它跳出单纯讲解工具使用的思路以“完成任务”为主线围绕知识探索与深度研究、行业洞察与时机分析、内容创作与媒体制作、创意设计与成果转换四大高频场景系统梳理Manus、Skywork、Genspark、扣子空间等11个AI Agent产品的特点与协同策略并配有任务分解、信息整合与流程优化的案例解析。资源包共1个PDF文件约27.03MB内容涵盖AI工具全景概览、各Agent基础操作与适用场景以及公众号日更、播客制作、学术调研、品牌营销设计等实战方向的操作指南与工具组合建议。目前已有29人学习适合希望找到适合自己的“最佳拍档”、在人机协作中兼顾效率与创意的读者参考。1. 从单点工具到协同网络AI Agent 工具协同到底在解决什么你可能已经装了七八个 AI 工具用 Coze 搭工作流、用 Manus 跑任务、用某个代码助手写脚本但真到干活的时候还是手动在几个窗口之间来回粘贴。问题不在于工具不够强而在于它们各干各的没有形成协同。北京大学这套「从 AI 工具到最佳拍档」的思路核心就是让多个 Agent 各司其职、互相调用把「我操作工具」变成「工具自己流转」。它适合已经用过至少一个 AI 工具、想进一步把重复流程自动化的从业者也适合正在评估 Agent 中台方案的技术负责人。读完你能判断自己的场景该不该做协同、用 Coze 还是自建框架、以及第一个可跑通的协同链路怎么搭。2. 协同的底层逻辑Agent 之间靠什么对话2.1 三种协同模式与选型依据Agent 协同不是把两个工具图标画在一起就完事。常见做法有三种串行流水线、主从调度、对等协商。串行流水线最简单A 的输出直接喂给 B适合格式转换、内容加工这类线性任务比如 Coze 工作流里「抓取网页 → 摘要 → 转 Markdown → 存文件」。主从调度是有一个 Orchestrator Agent 负责拆任务、分发给子 Agent子 Agent 干完回报适合任务边界清晰但步骤多的场景比如「收集竞品信息 → 分析定价 → 生成报告」。对等协商最复杂多个 Agent 共享上下文、互相质疑和补充适合需要多视角校验的决策类任务但落地成本高新手不建议一上来就做。选型的判断标准就一条你的任务能不能画成一张没有环的流程图。能画成 DAG 的用串行或主从画出来有回环、需要反复讨论的才考虑对等协商。我见过太多人一上来就追求「多 Agent 辩论」结果连最基本的串行链路都没跑稳调试成本直接翻倍。2.2 用 Coze 工作流搭一条最小协同链路下面这条链路实现的是输入一个技术标题自动搜索背景资料生成一段摘要再把摘要转成 Markdown 文件。这是最基础的串行协同两个 Agent 节点加一个工具节点。# Coze 工作流配置简化结构实际在可视化界面拖拽 workflow: name: title_to_summary nodes: - id: start type: input schema: title: string # 用户输入的技术标题 - id: search_agent type: llm model: doubao-pro prompt: | 你是一个技术资料检索助手。根据用户输入的标题{{start.title}} 生成 3 条相关的背景检索关键词只输出关键词用换行分隔。 output: keywords - id: search_tool type: plugin plugin: web_search input: {{search_agent.keywords}} output: raw_results - id: summary_agent type: llm model: doubao-pro prompt: | 根据以下检索结果写一段 200 字以内的技术摘要 {{search_tool.raw_results}} output: summary - id: markdown_tool type: plugin plugin: text_to_file input: content: {{summary_agent.summary}} format: markdown output: file_url逻辑说明search_agent负责把标题转成可检索的关键词这一步用 LLM 而不是直接拿标题去搜是因为标题往往太长、太具体直接搜召回率低。search_tool是 Coze 内置的联网搜索插件输入关键词数组输出原始结果。summary_agent做信息压缩把可能几千字的检索结果压到 200 字。最后markdown_tool负责落盘。参数说明model选doubao-pro是因为它在中文摘要任务上响应稳定如果你的场景以英文为主可以换。prompt里的{{变量名}}是 Coze 的变量引用语法必须和上游节点的output字段名一致否则运行时会报「变量未定义」。text_to_file的format参数支持markdown、txt、json选markdown会保留标题层级。注意Coze 工作流调试时每个节点都可以单独运行看输出。先逐个节点验证再连起来跑比整条链路一起调效率高得多。2.3 自建 Agent 协同Spring AI 的编排方式如果你需要把 Agent 协同嵌到自己的 Java 后端里Spring AI 是目前比较顺手的选择。它的核心抽象是ChatClient和ToolCallback多个 Agent 通过共享ChatMemory来传递上下文。// Spring AI 中两个 Agent 串行协同的简化示例 Service public class SummaryPipeline { private final ChatClient searchAgent; private final ChatClient summaryAgent; public SummaryPipeline(ChatClient.Builder builder) { this.searchAgent builder .defaultSystem(你是一个检索关键词生成助手只输出关键词。) .build(); this.summaryAgent builder .defaultSystem(你是一个技术摘要助手输出 200 字以内。) .build(); } public String run(String title) { // 第一个 Agent标题转关键词 String keywords searchAgent.prompt() .user(title) .call() .content(); // 模拟检索实际接搜索引擎 API String rawResults mockSearch(keywords); // 第二个 Agent检索结果转摘要 return summaryAgent.prompt() .user(rawResults) .call() .content(); } }逻辑说明两个ChatClient实例各自持有独立的 system prompt互不干扰。run方法里先调searchAgent拿关键词再用关键词去检索最后把检索结果交给summaryAgent。这就是最朴素的串行协同。参数说明defaultSystem设定了每个 Agent 的角色边界这一步很关键——如果不设两个 Agent 的行为会趋同协同就退化成一次普通对话。prompt().user().call().content()是 Spring AI 的链式调用content()返回纯文本。如果你需要结构化输出可以用.entity(SomeClass.class)替代.content()。3. 把协同链路做稳上下文传递与错误处理3.1 上下文在 Agent 之间怎么传才不丢协同链路最容易翻车的地方就是上下文丢失。串行链路里上游 Agent 的输出直接作为下游的输入看起来简单但实际会遇到三个问题格式不匹配、长度超限、语义漂移。格式不匹配的典型场景上游 Agent 输出了一段带 Markdown 标记的文本下游 Agent 期望的是纯文本结果下游把##也当成了内容的一部分去处理。解决办法是在上游的 prompt 里明确输出格式比如「只输出纯文本不要任何 Markdown 标记」或者在下游加一个清洗节点。长度超限更常见。LLM 的上下文窗口有限如果上游输出几千字下游可能直接截断。我一般会在中间加一个「压缩节点」用一个小模型把上游输出压到 500 字以内再传给下游。Coze 里可以用一个 LLM 节点专门做这件事Spring AI 里可以加一个ContentCompressor组件。语义漂移是最隐蔽的。上游 Agent 输出的内容下游 Agent 理解成了另一个意思。比如上游说「这个方案的成本较高」下游理解成「这个方案不可行」。避免方法是让下游 Agent 在 prompt 里明确「你收到的输入来自上游 Agent请基于以下内容继续处理不要自行推断未提及的信息」。3.2 错误处理Agent 执行失败时怎么办Agent 协同链路里任何一个节点失败都会导致整条链路中断。常见做法是给每个节点加重试和降级。重试策略LLM 调用失败超时、限流时重试 2 次间隔 1 秒。Coze 工作流里可以在节点设置里配重试次数Spring AI 里可以用 Spring Retry 注解。降级策略如果检索节点失败不要让整条链路挂掉而是让下游 Agent 基于已有信息继续生成并在输出里标注「检索结果缺失」。这样至少能拿到一个不完整但可用的结果。// Spring AI 中带重试和降级的节点调用 Retryable(maxAttempts 3, backoff Backoff(delay 1000)) public String callWithRetry(String input) { return chatClient.prompt().user(input).call().content(); } public String callWithFallback(String input) { try { return callWithRetry(input); } catch (Exception e) { // 降级返回一个占位提示让下游继续 return [检索失败以下内容基于已有信息生成]; } }逻辑说明Retryable注解让方法在抛出异常时自动重试最多 3 次每次间隔 1 秒。callWithFallback包了一层 try-catch重试耗尽后返回降级内容保证链路不中断。参数说明maxAttempts不要设太大3 次足够再多会拖长整体响应时间。delay设 1000 毫秒是因为大多数限流错误的恢复窗口在 1 秒左右。降级返回的占位文本要足够明确让下游 Agent 知道「这里缺了东西」而不是把占位文本当成真实内容。3.3 用 Coze 工作流做条件分支不是所有任务都适合一条直线走到底。有些场景需要根据中间结果决定下一步走哪条路。Coze 工作流支持条件分支节点可以根据上游输出的内容判断走哪个分支。# Coze 工作流中的条件分支配置 nodes: - id: classify_agent type: llm prompt: | 判断以下内容属于哪一类只输出 tech 或 business {{start.input}} output: category - id: branch type: condition conditions: - when: {{classify_agent.category}} tech next: tech_agent - when: {{classify_agent.category}} business next: business_agent - id: tech_agent type: llm prompt: 你是一个技术分析助手请分析{{start.input}} - id: business_agent type: llm prompt: 你是一个商业分析助手请分析{{start.input}}逻辑说明classify_agent先做一次分类branch节点根据分类结果决定走tech_agent还是business_agent。这样两个下游 Agent 各自有独立的 prompt不会互相干扰。参数说明condition里的表达式语法是 Coze 特有的是精确匹配。如果你的分类结果可能带空格或换行建议在classify_agent的 prompt 里加一句「只输出一个词不要任何标点或空格」。4. 避坑与排查协同链路跑不通时先看这几处4.1 变量引用报「未定义」现象工作流运行到某个节点时报错提示变量未定义或为空。原因上游节点的output字段名和下游节点prompt里的{{变量名}}不一致。Coze 里变量名是大小写敏感的summary和Summary会被当成两个不同的变量。解决逐个节点检查output字段名复制粘贴到下游的引用位置不要手动敲。如果上游节点有多个输出字段确认引用的那个字段确实有值。4.2 LLM 节点输出格式不稳定现象上游 Agent 有时输出纯文本有时带 Markdown 标记有时多一段解释性文字导致下游解析失败。原因LLM 的输出本身有随机性prompt 里如果没有强约束模型会「自由发挥」。解决在 prompt 末尾加硬约束比如「只输出结果不要任何解释、不要 Markdown 标记、不要换行」。如果还是不稳定在下游加一个清洗节点用正则把非目标内容去掉。更稳妥的做法是用结构化输出Coze 里可以配 JSON SchemaSpring AI 里用.entity()。4.3 链路太长导致超时现象工作流节点超过 5 个之后整体运行时间超过平台限制报超时错误。原因每个 LLM 节点平均耗时 3-5 秒串行下来总时间线性增长。Coze 免费版的工作流超时限制比较紧。解决把能并行的节点改成并行。比如两个独立的检索任务不要串行跑用并行分支同时跑。另外把不必要的小模型调用合并成一个节点减少 LLM 调用次数。4.4 检索插件返回空结果现象检索节点返回空数组下游 Agent 拿到空输入后输出一段无关内容。原因检索关键词太具体或太生僻搜索引擎没有匹配结果。或者关键词里带了特殊字符插件解析失败。解决在检索节点后面加一个判断如果结果为空走降级分支让下游 Agent 基于标题本身生成内容而不是基于空检索结果。另外关键词生成时让 LLM 输出 3-5 个不同角度的词不要只输出一个。4.5 自建 Agent 时内存泄漏现象Spring AI 项目跑一段时间后响应变慢最终 OOM。原因ChatMemory如果没有设置上限每次对话都会往内存里追加消息长时间运行后内存被撑满。解决给ChatMemory设置maxMessages上限比如 20 条超出后自动淘汰最早的消息。或者用InMemoryChatMemory的替代方案把对话历史存到 Redis 里设置 TTL。5. 进阶让协同链路自己判断该不该继续前面讲的都是「预设好的链路」节点和分支在运行前就定死了。但真实场景里你往往希望 Agent 自己能判断「这一步的结果够不够好要不要再来一轮」。这就是自省循环也是从「工具协同」走向「最佳拍档」的关键一步。实现方式是在链路末尾加一个「质检 Agent」它检查最终输出是否满足要求如果不满足把问题反馈给上游触发一轮重做。Coze 工作流里可以用循环节点实现Spring AI 里可以用一个 while 循环包住整条链路。// Spring AI 中的自省循环质检不通过就重做 public String runWithReflection(String title, int maxRounds) { String result ; for (int i 0; i maxRounds; i) { result pipeline.run(title); String feedback qualityAgent.prompt() .user(请检查以下内容是否满足要求\n result \n如果满足只输出 PASS如果不满足输出具体问题。) .call() .content(); if (PASS.equals(feedback.trim())) { return result; } // 把质检反馈作为额外上下文重新跑一轮 title title \n[上一轮问题 feedback ]; } return result; // 达到最大轮次后返回最后一版 }逻辑说明qualityAgent负责质检输出PASS或具体问题。如果通过直接返回如果不通过把问题追加到输入里重新跑一轮。maxRounds控制最大重做次数防止无限循环。参数说明maxRounds建议设 2-3再多收益递减且耗时翻倍。质检 Agent 的 prompt 要写得具体比如「检查是否包含至少 3 个数据点、是否有明确的结论」而不是笼统的「检查质量」。反馈信息要能指导下一轮改进所以质检 Agent 输出的问题描述要足够具体。一个我踩过的坑质检 Agent 本身也可能误判。有一次它把一段完全合格的输出判为不合格导致链路白跑了两轮。后来我在质检 prompt 里加了一句「如果不确定倾向于输出 PASS」误判率明显下降。这个策略叫「宽松质检」适合对准确性要求不是极端高的场景。另一个技巧是把质检结果存下来跑一段时间后统计「哪些问题最常被质检 Agent 标记」然后针对性优化上游 Agent 的 prompt。这比盲目调 prompt 有效得多。希望帮到你。本文还有配套的精品资源点击获取
