多Agent办公自动化最近讨论度很高。不少团队都做过类似的尝试把一个真实办公任务丢给好几个Agent希望它们像一支小分队同时开工、各管一块最后拼出一个完整结果。然而真到了企业内部流程里这套“人多力量大”的做法经常翻车。任务并不是分下去就结束的真正的难点在于任务由谁来拆、拆完之后的中间结果怎么交接、某个环节出错时是重跑整条链路还是只重跑那一棒。这次的挑战任务是让多个Agent接力完成一份项目周报的生成与审核。任务本身不复杂汇总项目进度、分析风险、生成周报、检查格式、输出最终可分发版本。但把它交给四个不同角色的Agent后真正的问题才开始浮现上下文如何传递、并发如何控制、最后一棒发现第一棒的数据有问题时责任应该如何定位。先把文章的核心判断放在这里在办公自动化场景里多Agent的价值不在于“数量多”而在于“接力稳”。任务拆得合理、交接清晰、并发克制远比把一堆Agent同时塞进同一个Prompt里可靠。全文会从概念、架构、配置、代码和排错五个角度展开读完你可以照着搭一套属于自己的接力式办公自动化流水线。1. 为什么办公自动化任务需要多Agent接力先讨论一个现象多Agent真正解决的是什么问题如果只是把一个任务切成几块扔给几个模型那和单Agent长Prompt的差别其实没有想象中那么大。真正让多Agent产生价值的是它改变了任务的执行结构。1.1 单Agent指令越堆越长效果越来越差办公自动化任务有一个共同特点环节多而且每个环节需要注意的点完全不同。比如“生成周报”这四个字实际展开之后至少包含数据收集、进度对比、风险分析、文案撰写、格式审核。如果只用一个Agent最自然的做法是把所有要求写进一个很长的系统提示词里。结果往往是模型确实“记住了”所有要求但真正执行时每个环节都只做到七成。原因并不神秘模型在同一轮生成里要同时处理“提取数据”“分析风险”“写周报”“检查格式”多个目标注意力会被分散上下文越长中间环节的信息越容易被稀释。更麻烦的是这种大而全的模式没有“阶段产物”。当周报格式错误时你没法定位是“周报撰写”这一步的问题还是“数据收集”这一步就错了只能把整段指令重新跑一遍。这个体验做过真实办公自动化项目的人应该都不陌生。1.2 “并发群聊”式的多Agent并不适合办公流程很多人看到多Agent的第一反应是让多个Agent并行处理同一个任务各写各的最后拼起来。并行模式确实适合某些场景比如批量翻译文件、批量审核多张图片。但办公自动化流程大多是强顺序依赖的先取数后分析再撰写最后审核。分析依赖取数结果撰写依赖分析结果审核又要同时参考报告和数据天然没法完全并行。如果把这种强依赖的流程硬做成“群聊式”多Agent还会遇到两个问题。一是上下文冗余每个Agent为了“看到全貌”都得复制一份完整任务信息Token成本成倍上涨。二是责任不清多个Agent同时改同一份中间结果时版本冲突会频繁出现而到底听谁的最终又得靠人拍板。三种模式的差别可以用下面这张表快速看清维度单Agent全流程多Agent并行多Agent接力适用任务简单固定步骤的任务环节之间无依赖的批量任务强顺序依赖的流程性任务上下文负担全部信息塞进一个窗口压力大每个Agent各自维护信息冗余只传递阶段产物上下文精简出错定位难以定位具体环节单Agent失败可定位可按棒次精确回溯审核能力生成与审核混在一起各Agent视角受限可安排独立质检Agent资源消耗一次长调用消耗大并发高时Token成本高按阶段裁剪输入输出相对可控1.3 接力式协作的优势阶段产物、单点定位、可控审核接力式协作的处理思路完全不同。它先把任务拆成一串有顺序的环节每个环节只交给一个Agent上一环节的输出就是下一环节的“唯一输入”。这样做的好处是每个Agent的上下文都被压缩到它真正需要的那一小段信息。中间任何一棒失败错误可以被定位到具体Agent和具体步骤。可以在最后一棒安排独立质检Agent而不是让写周报的Agent自己审自己。一句话总结接力式多Agent把“一个模型干全部”变成“多个模型各干一段用标准协议把段与段接起来”。这正好匹配办公自动化流程本身自带的阶段顺序。2. 多Agent接力协作的核心概念概念部分讲清楚三件事角色怎么设计、上下文怎么交接、失败怎么处理。这三件事决定了接力流程是稳定还是脆弱的。2.1 角色与分工在接力式多Agent里“角色”不是花哨的设定而是一段职责边界明确的系统提示词加一组有限的工具权限。角色设计的目标是让每个Agent只回答它职责范围内的问题。举例来说“项目数据收集员”这个角色只需要读任务列表、提取已完成和未完成任务、输出JSON。“风险分析员”则只负责基于上一步的JSON做分析和建议它不应该被允许直接修改数据或编写周报。这样的职责隔离既降低模型的判断难度也便于后续做权限控制和审计。这里很容易踩一个坑角色描述写得太泛。比如给“数据收集员”写了一段“你是万能办公助手请协助处理所有办公事务”Agent下一次处理时就会把格式审核、文案润色一起做了反而破坏流程的确定性。角色的系统提示词应该像岗位说明书只写职责、产出格式、边界三条。2.2 上下文交接接力式协作的核心机制是上下文交接也就是前一个Agent把“做了什么、得到了什么、有什么需要特别注意的”打包传给下一个Agent。交接有两种常见方式。第一种是全量交接把上一步的完整输出塞进下一步的输入适合步骤少、输出短的小任务。第二种是精简交接只传递上一步的结论摘要、关键字段和新产生的中间文件路径适合长流程。实际项目里链路越复杂越推荐精简交接因为它能显著降低Token消耗也能避免下一步被上一步的冗长中间内容干扰。交接时有一个细节很关键要给每份上下文带上“数据版本”或“步骤编号”。否则一旦流程重跑或并发调试你会分不清某份周报到底是哪一批数据生成的。2.3 任务验收与重试接力流程里每个Agent的输出都应该有一个明确的验收标准。最简单实用的是格式验收要求输出必须是合法JSON、必须包含某些字段、必须通过长度检查。格式验收失败时可以直接把这个Agent重跑一次而不是把整条流水线从头跑。更高级一些的做法是安排一个独立质检Agent去验收上一个Agent的产物。比如“周报质检员”的任务就是对着原始数据检查周报内容是否一致。这等于在流程里加了一道“机器质检关”比只靠Prompt约束可靠得多。重试需要设计退避策略。模型接口在突发高并发下偶尔超时是正常现象通常重试两到三次、每次退避递增的指数退避比“死磕一次”和“无限重试”都更合理。2.4 从单Agent到多Agent协同的架构演进从架构视角看多Agent协同近年经历了一个明显的演进早期是“单Agent 长Prompt”后来是“多Agent自由对话”再往后是“多Agent按流程接力”。社区里像 jiuwenswarm 这类多 Agent 协同架构方案核心思路也落在“接力”二字上通过一套定义好的交接协议让Agent之间以标准化的方式传递任务和结果而不是让它们自由聊天。这类架构通常包含三个基础组件Agent注册中心负责维护角色清单和职责说明任务编排器负责决定谁接下一棒、什么时候交接上下文总线负责保存和传递中间结果。理解了这三个组件也就理解了多Agent协同架构的绝大部分内容。无论用什么框架落地本质上都是在做这三件事。3. 挑战任务设计一个完整的办公自动化场景架构聊完回到具体任务。为了验证接力式多Agent的真实效果我们把挑战任务设定为许多公司周一都会遇到的场景生成一份项目周报并且要能直接分发。3.1 任务背景从“周报”到“可分发结果”任务输入是两类文件一份任务列表JSON包含6个项目的任务条目、状态、负责人和进度百分比一份本周变更记录包含3条需求变更和1条风险提醒。任务输出是一份结构完整的周报文档并且要能通过质检。之所以强调“可分发结果”是因为实际办公里周报写出来只是第一步后续还要粘贴到群里、放进邮件、同步到看板。如果一个流程生成的周报还需要人手工整理格式那自动化的价值就已经打了一半折扣。3.2 任务要求我们给这个流程定了四条验收要求周报必须包含项目概况、本周进展、风险与建议、下周计划四个部分。项目进度数据必须与输入JSON完全一致不能由模型凭记忆补数据。周报语言风格统一可直接用于群发。流程中任意一棒失败要能定位到具体Agent并单独重跑。3.3 为什么这个任务适合接力式上面的四条要求里第一、二条尤其能体现接力式的价值。进度一致性要求意味着如果让一个Agent从头到尾处理它很可能在写周报时凭印象“美化”数字而接力流程里数据收集、风险分析、周报撰写、质检是四个独立步骤每个步骤的输出都被下一棒当作“客观事实”来使用改动数据的概率会大幅下降。团队协作场景也同理。当你需要一份报告经过多个人审核时接力流程天然相当于“数据收集员→分析员→撰写员→审核员”的虚拟团队。这套模式一旦跑通可以复用到日报、会议纪要、销售分析等一大批办公自动化任务。4. 环境准备与Agent并发配置进入实操前先说明运行环境和多Agent并发配置的核心要点。4.1 运行环境本次演示不绑定特定框架使用Python即可运行。建议环境Python 3.10及以上安装PyYAML库用于读取YAML配置准备一个可访问的大模型API或企业内部部署的模型网关。模型版本和接口协议以实际项目为准本文重点演示通用思路不绑定特定厂商。4.2 模型API接入真实项目里模型API接入一般会封装成一个统一的聊天函数输入是消息列表输出是文本。这个函数的内部实现取决于你用的模型供应商可能是OpenAI的API格式也可能是国内模型厂商的协议甚至可能是公司内部的私有模型服务。关键设计是多Agent流程不关心底层模型是谁只关心这个统一函数存在。这样一来替换模型时不需要修改任何Agent代码只需要改llm_func这个函数的内部实现。很多团队把模型切来切去Agent代码完全不用动就是这个设计带来的好处。4.3 Agent多并发配置的几个关键参数多并发配置是很多团队的踩坑点。把并发数值调大表面看是“让多个Agent同时干活”实际却可能触发模型API限流导致整条流程超时失败。以下参数需要认真配置。配置项作用建议max_workers全局并发线程池大小根据模型API的限流上限的50%到70%设置agent_concurrency单个Agent内部的并发上限有顺序依赖的Agent建议设1IO密集任务可设4左右timeout单次模型调用超时时间30到120秒视模型响应速度调整max_retries单次调用失败重试次数2到3次配合指数退避不要无限重试queue_size等待队列长度超过后拒绝新任务避免积压过深这些数值不是越大越好。尤其是max_workers和agent_concurrency需要根据模型API的吞吐能力和任务的实际依赖关系去调整。4.4 并发不是越大越好多Agent办公自动化的目标不是压榨吞吐量而是稳定完成流程。故意限制并发有时反而是正确设计。比如“质检员”Agent的并发设为1是因为审核步骤必须按顺序逐个处理同时审核多份报告容易让模型互相“看到”对方的上下文反而降低审核质量。另一个常见误区是把全局线程池开得很大认为这样能加速。实际运行中模型API的限流、上下文窗口长度、单次调用的响应时间都会比线程数更早成为瓶颈。更稳妥的做法是先小并发全链路跑通确认每个环节的平均耗时再按最慢环节来调整并发。5. 完整示例多Agent接力生成周报并审核分发下面是本次挑战的最小工程实现。代码不依赖特定Agent框架所有逻辑都在直观的Python文件里方便你理解每一步在做什么。5.1 项目目录结构agent-weekly-report/ ├── config/ │ └── pipeline.yaml ├── data/ │ ├── tasks_2025_week6.json │ └── changes_2025_week6.json └── src/ ├── agent_worker.py ├── concurrency.py ├── run_weekly_report.py └── main.pyconfig目录放多Agent配置data目录放办公任务输入数据src目录放Python执行代码。5.2 多Agent配置# config/pipeline.yaml version: 1.0 global: model: qwen-max temperature: 0.3 timeout: 60 max_retries: 2 agents: - name: collector role: 项目数据收集员 system_prompt: | 你是办公自动化流程中的项目数据收集员。 输入是项目任务列表和本周变更记录 你需要提取已完成任务、进行中任务、阻塞任务、变更说明。 输出JSON不要输出无关内容。 concurrency: 4 max_retries: 3 - name: analyzer role: 进度风险分析员 system_prompt: | 你是项目进度风险分析员。 输入是JSON格式的项目进度数据 你需要分析风险项、亮点、延期原因并给出建议。 输出结构清晰的Markdown分析结果。 concurrency: 2 max_retries: 2 - name: writer role: 周报撰写员 system_prompt: | 你是周报撰写员。 输入是Markdown格式的分析结果 你需要生成一份包含项目概况、本周进展、风险与建议、下周计划四部分的周报。 语言专业、简洁。 concurrency: 2 max_retries: 2 - name: reviewer role: 周报质检员 system_prompt: | 你是周报质检员。 输入是周报草稿以及原始项目数据。 请检查时间范围是否正确、任务数据是否一致、格式是否完整。 如果发现问题返回修改意见如果无误返回PASS。 concurrency: 1 max_retries: 3 pipeline: - step: 1 agent: collector output_key: collected_data - step: 2 agent: analyzer depends_on: collected_data output_key: analysis_result - step: 3 agent: writer depends_on: analysis_result output_key: weekly_report - step: 4 agent: reviewer depends_on: [weekly_report, collected_data] output_key: review_result重点解释一下这段配置。global节点是所有Agent的默认参数每个agents节点是一个角色的完整定义其中concurrency是Agent级并发上限max_retries控制重试次数。最后的pipeline节点定义接力步骤顺序output_key很像编程中的变量名每一步的输出都会写回一个全局上下文字典供后面的步骤引用。5.3 Agent执行单元先写最核心的AgentWorker类它负责执行单个Agent的调用与重试# src/agent_worker.py import json import time from datetime import datetime from typing import Any, Callable class AgentWorker: 一个轻量级的多Agent接力执行单元。 def __init__(self, config: dict, llm_func: Callable[[list], str]): :param config: 从 YAML 加载的 pipeline 配置 :param llm_func: 模型聊天接口入参是 messages 列表出参是文本 self.config config self.llm_func llm_func self.registry {agent[name]: agent for agent in config[agents]} self.context: dict[str, Any] {} def run_agent(self, agent_name: str, payload: dict) - dict: agent self.registry[agent_name] max_retries agent.get(max_retries, self.config[global][max_retries]) for attempt in range(max_retries): try: messages [ {role: system, content: agent[system_prompt]}, {role: user, content: json.dumps(payload, ensure_asciiFalse)}, ] result_text self.llm_func(messages) return { agent: agent_name, output: result_text, finished_at: datetime.now().isoformat(timespecseconds), } except Exception as exc: if attempt max_retries - 1: raise RuntimeError( fAgent [{agent_name}] 重试 {max_retries} 次后仍失败: {exc} ) from exc time.sleep(2 ** attempt) raise RuntimeError(fAgent [{agent_name}] 执行失败)这个类的核心逻辑是为每个Agent准备系统提示词和用户输入调用统一的模型函数得到文本返回时带上Agent名称和时间戳。失败时会指数退避重试直到耗尽max_retries。所有中间产物都保存在context字典里它就是“上下文总线”在最小实现里的样子。5.4 接力流程编排接下来定义办公任务的接力顺序# src/run_weekly_report.py import json from agent_worker import AgentWorker def run_weekly_report_pipeline(worker: AgentWorker, config: dict) - dict: 按 pipeline 配置的顺序执行接力。 每个 Agent 的输出写入 context下个 Agent 依赖上一个 Agent 的产物。 # 第1棒数据收集 collected worker.run_agent(collector, { task_files: [ data/tasks_2025_week6.json, data/changes_2025_week6.json, ] }) worker.context[collected_data] collected[output] # 第2棒风险分析 analysis worker.run_agent(analyzer, { project_data: json.loads(worker.context[collected_data]) }) worker.context[analysis_result] analysis[output] # 第3棒周报撰写 report worker.run_agent(writer, { analysis_result: worker.context[analysis_result] }) worker.context[weekly_report] report[output] # 第4棒质检需要同时看到报告和原始数据 review worker.run_agent(reviewer, { weekly_report: worker.context[weekly_report], collected_data: worker.context[collected_data], }) worker.context[review_result] review[output] return worker.context这段代码没有任何魔法就是按顺序调用四个Agent把前一步输出作为后一步输入。之所以这么“朴素”是因为接力协作的关键恰恰在流程透明每一步都显式写在代码里出问题时可以立刻定位到具体某一棒而不是混在复杂框架内部让人无从排查。5.5 并发控制与任务提交前面配置里的concurrency字段在最小演示里可以直接用信号量实现# src/concurrency.py from concurrent.futures import ThreadPoolExecutor from threading import BoundedSemaphore # 全局线程池建议先把线程数控制到不超过模型 API 限流上限的一半。 executor ThreadPoolExecutor(max_workers8, thread_name_prefixagent-task) # 每个 Agent 使用独立信号量避免多个 Agent 同时冲高请求量。 agent_semaphores { collector: BoundedSemaphore(4), analyzer: BoundedSemaphore(2), writer: BoundedSemaphore(2), reviewer: BoundedSemaphore(1), } def submit_with_limit(agent_name: str, fn, *args, **kwargs): 提交任务前先获取当前 Agent 对应的并发额度。 sem agent_semaphores.get(agent_name, BoundedSemaphore(2)) sem.acquire() def _wrapper(): try: return fn(*args, **kwargs) finally: sem.release() return executor.submit(_wrapper)信号量的作用类似“限行杆”当一个Agent已经有太多任务在跑时新任务会在sem.acquire()处等待直到有位置空出来。这样无论上游同时提交多少个任务落到模型API上的请求量都始终受控。5.6 入口文件最后把它们组合到主入口文件中# src/main.py import json import sys import yaml from agent_worker import AgentWorker from run_weekly_report import run_weekly_report_pipeline def load_config(path: str) - dict: with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def fake_llm_chat(messages: list) - str: 演示用占位函数实际项目请替换为真实的模型接口。 只需要保证入参是 messages 列表出参是文本。 这里根据系统提示词中的角色返回一段固定文本 方便你先把整个接力链路跑通。 system_prompt messages[0][content] if 项目数据收集员 in system_prompt: return {completed: 4, in_progress: 1, blocked: 1} if 进度风险分析员 in system_prompt: return ## 风险分析\n本周整体进展正常roadmap-data-delay 项目存在延期风险。 if 周报撰写员 in system_prompt: return ## 项目周报\n### 项目概况\n### 本周进展\n### 风险与建议\n### 下周计划 return PASS if __name__ __main__: config load_config(sys.argv[1]) worker AgentWorker(config, llm_funcfake_llm_chat) context run_weekly_report_pipeline(worker, config) print(json.dumps(context, ensure_asciiFalse, indent2))这里用fake_llm_chat作为占位函数目的只有一个让你在不依赖真实模型的情况下先把多Agent接力链路完整跑通。替换成真实模型时只需要改这个函数内部实现调用你自己的模型服务即可。运行命令python src/main.py config/pipeline.yaml到这里一个不含任何具体框架依赖的多Agent接力流水线就成型了。6. 运行结果与效果验证6.1 运行命令cd agent-weekly-report python src/main.py config/pipeline.yaml前置条件config/pipeline.yaml存在src目录下代码完整且已经在当前Python环境中安装了pyyaml。6.2 预期输出使用占位模型函数时输出是一份包含了collected_data、analysis_result、weekly_report、review_result四个键的JSON。每个键对应一棒的产物结构类似{ collected_data: {\completed\: 4, \in_progress\: 1, \blocked\: 1}, analysis_result: ## 风险分析\n本周整体进展正常roadmap-data-delay 项目存在延期风险。, weekly_report: ## 项目周报\n### 项目概况\n### 本周进展\n### 风险与建议\n### 下周计划, review_result: PASS }不要被这段看起来“简单”的输出迷惑。它的价值在于验证了接力链路本身是通的。替换成真实模型之后collected_data应该是结构化JSONreview_result要么是“PASS”要么是一段具体的修改意见。6.3 如何判断接力成功判断成功的标准有三个四个步骤全部执行完毕没有抛出 RuntimeError。每一棒的输出都成功写入上下文字典后面的Agent读取到了前一步的结果。review_result标示检查通过或者给出了可执行的修改建议。如果失败不要急着调并发参数先看是哪个Agent出错。日志里Agent [xxx] 重试 N 次后失败会直接告诉你问题出在哪一棒这是接力模式比单Agent长Prompt最大的优势之一。7. 常见问题与排查思路多Agent接力流程在实际运行中会遇到的问题很多都是共通的。下面这张表整理了几个高频问题问题现象可能原因排查方式解决方案Agent调用偶尔超时全局并发过高触发模型API限流查看模型网关或SDK返回的限流错误码降低max_workers每个Agent并发减半后再观察接力流程中途失败只能整条重跑上下文交接不完整下一步读不到上一步关键字段检查context字典中上一步的输出是否完整使用精简交接先做字段级校验再传给下一棒周报里的进度数字与源数据不一致模型在长上下文中“凭印象”补写对比周报数值与原始JSON把数据收集单独拆为一棒让撰写Agent只接触结构化结论并发较高时review结果变差审核类Agent被并行调用上下文互相干扰观察相同输入在不同并发下结果是否不一致审核Agent的concurrency降为1JSON解析报错模型返回了非JSON文本打印该Agent的原始输出在系统提示词中强调“只输出JSON”并在代码里做容错解析重试次数耗尽后仍然失败模型接口持续不可用检查模型服务状态和网络加熔断机制避免连续重试进一步放大故障这里重点提醒一下“重试次数耗尽”的情况。很多团队在重试失败后会把max_retries调大但真正的问题可能是接口配置、Prompt格式或者权限。先把单个Agent的输入输出打印出来检查比盲目调大重试次数更有效。8. 最佳实践与工程建议多Agent接力从“能跑”到“好用”中间还有很长的路。这里给出几条在真实项目中比较关键的建议。8.1 任务拆解的粒度多Agent接力的第一步是决定拆成几棒。拆得太粗比如“生成周报”作为一个Agent内部仍然是长Prompt模式失去了接力优势拆得太细比如“提取项目名”单独一棒又会引入大量无谓的模型调用和延迟。经验原则是按“阶段产物”来拆。每个Agent都要产出一个可以被后续环节消费的明确结果比如一份JSON、一段分析结论、一版草稿。步骤之间最好存在单向依赖尽量避免两个Agent互相修改同一个中间文件。8.2 上下文的传递结构上下文不要直接传原始大文本推荐设计成“核心字段 摘要 数据引用”的结构。比如收集员传给分析员的不是全部任务明细而是{ summary: 本周完成4项进行中1项阻塞1项, risk_keys: [roadmap-data-delay], data_ref: data/collected_2025_week6.json }这样做的好处是分析员不需要重新理解整份数据只需要基于摘要展开分析。如果需要看明细可以按data_ref指向的文件去读。数据引用方式也比全量复制更节省Token。8.3 容错与重试策略接力流程的容错要分层。第一层是格式校验每个Agent输出后立刻检查字段和类型第二层是单Agent重试配合指数退避避免连续失败打爆接口第三层是流程级补偿比如质检不通过时可以把报告退回给撰写Agent重新生成而不是重跑整个链路。退避策略建议使用2 ** attempt的指数退避并设置最大延迟上限。不要使用固定间隔重试也不要做无穷重试。任何重试逻辑都要配合超时和熔断防止模型接口出现故障时拖垮整个办公流程。8.4 安全边界与合规提醒办公自动化涉及阅读内部项目数据、生成对外文档甚至可能触发消息发送。实际落地时至少要做三件事最小权限每个Agent只授予完成本环节所需的数据读取和工具调用权限不要把“全部文档目录”都交给它。人工确认涉及对外发送的环节如邮件、群消息、审批提交建议先生成草稿由人确认后再发送。自动发送功能即使已经开发完成也建议先经过灰度验证。审计留痕每个Agent的输入、输出、耗时和重试记录都写入日志方便后续排查和追溯。上面的示例中没有写“自动发送”代码原因就在这里真正进入生产环境的办公自动化流程任何会产生外部副作用的操作都应该先具备确认和回滚能力。9. 总结与后续学习方向多Agent接力协作的价值不是把任务“摊”给多个Agent一起做而是把任务按阶段“切”开让每个Agent只处理自己擅长的环节再通过清晰的上下文交接把它们串联起来。它更适合办公自动化这类强顺序依赖的流程相比单Agent长Prompt更稳、更可控、更容易定位问题。本文通过一个周报生成与审核的挑战任务完整演示了四个角色、一套YAML配置、一个执行单元和一条显式接力流程。你可以直接在这个最小工程上继续扩展把fake_llm_chat替换成真实模型的聊天接口给每个Agent增加工具调用能力把pipeline配置改成支持热更新再逐步加入日志、监控和人工审核节点。下一步值得研究的方向有三个第一把pipeline.yaml抽象成通用配置让非开发同事也能配置Agent流程第二加入流程级补偿机制让“质检不通过→退给撰写员重写”这类回环成为标准能力第三探索动态角色调整比如根据任务复杂度自动决定拆成几棒。每个方向单独拎出来都是一片很大的实践空间而理解这些的前提是先跑通一套朴素的接力流程。建议你保存上面的最小工程下次遇到“又要取数、又要分析、又要写文档”的办公任务时先别急着写一条超长的系统提示词试着拆两棒、三棒让Agent们接力试试。 多Agent接力式办公自动化：从周报生成到流程编排的实践指南
多Agent办公自动化最近讨论度很高。不少团队都做过类似的尝试把一个真实办公任务丢给好几个Agent希望它们像一支小分队同时开工、各管一块最后拼出一个完整结果。然而真到了企业内部流程里这套“人多力量大”的做法经常翻车。任务并不是分下去就结束的真正的难点在于任务由谁来拆、拆完之后的中间结果怎么交接、某个环节出错时是重跑整条链路还是只重跑那一棒。这次的挑战任务是让多个Agent接力完成一份项目周报的生成与审核。任务本身不复杂汇总项目进度、分析风险、生成周报、检查格式、输出最终可分发版本。但把它交给四个不同角色的Agent后真正的问题才开始浮现上下文如何传递、并发如何控制、最后一棒发现第一棒的数据有问题时责任应该如何定位。先把文章的核心判断放在这里在办公自动化场景里多Agent的价值不在于“数量多”而在于“接力稳”。任务拆得合理、交接清晰、并发克制远比把一堆Agent同时塞进同一个Prompt里可靠。全文会从概念、架构、配置、代码和排错五个角度展开读完你可以照着搭一套属于自己的接力式办公自动化流水线。1. 为什么办公自动化任务需要多Agent接力先讨论一个现象多Agent真正解决的是什么问题如果只是把一个任务切成几块扔给几个模型那和单Agent长Prompt的差别其实没有想象中那么大。真正让多Agent产生价值的是它改变了任务的执行结构。1.1 单Agent指令越堆越长效果越来越差办公自动化任务有一个共同特点环节多而且每个环节需要注意的点完全不同。比如“生成周报”这四个字实际展开之后至少包含数据收集、进度对比、风险分析、文案撰写、格式审核。如果只用一个Agent最自然的做法是把所有要求写进一个很长的系统提示词里。结果往往是模型确实“记住了”所有要求但真正执行时每个环节都只做到七成。原因并不神秘模型在同一轮生成里要同时处理“提取数据”“分析风险”“写周报”“检查格式”多个目标注意力会被分散上下文越长中间环节的信息越容易被稀释。更麻烦的是这种大而全的模式没有“阶段产物”。当周报格式错误时你没法定位是“周报撰写”这一步的问题还是“数据收集”这一步就错了只能把整段指令重新跑一遍。这个体验做过真实办公自动化项目的人应该都不陌生。1.2 “并发群聊”式的多Agent并不适合办公流程很多人看到多Agent的第一反应是让多个Agent并行处理同一个任务各写各的最后拼起来。并行模式确实适合某些场景比如批量翻译文件、批量审核多张图片。但办公自动化流程大多是强顺序依赖的先取数后分析再撰写最后审核。分析依赖取数结果撰写依赖分析结果审核又要同时参考报告和数据天然没法完全并行。如果把这种强依赖的流程硬做成“群聊式”多Agent还会遇到两个问题。一是上下文冗余每个Agent为了“看到全貌”都得复制一份完整任务信息Token成本成倍上涨。二是责任不清多个Agent同时改同一份中间结果时版本冲突会频繁出现而到底听谁的最终又得靠人拍板。三种模式的差别可以用下面这张表快速看清维度单Agent全流程多Agent并行多Agent接力适用任务简单固定步骤的任务环节之间无依赖的批量任务强顺序依赖的流程性任务上下文负担全部信息塞进一个窗口压力大每个Agent各自维护信息冗余只传递阶段产物上下文精简出错定位难以定位具体环节单Agent失败可定位可按棒次精确回溯审核能力生成与审核混在一起各Agent视角受限可安排独立质检Agent资源消耗一次长调用消耗大并发高时Token成本高按阶段裁剪输入输出相对可控1.3 接力式协作的优势阶段产物、单点定位、可控审核接力式协作的处理思路完全不同。它先把任务拆成一串有顺序的环节每个环节只交给一个Agent上一环节的输出就是下一环节的“唯一输入”。这样做的好处是每个Agent的上下文都被压缩到它真正需要的那一小段信息。中间任何一棒失败错误可以被定位到具体Agent和具体步骤。可以在最后一棒安排独立质检Agent而不是让写周报的Agent自己审自己。一句话总结接力式多Agent把“一个模型干全部”变成“多个模型各干一段用标准协议把段与段接起来”。这正好匹配办公自动化流程本身自带的阶段顺序。2. 多Agent接力协作的核心概念概念部分讲清楚三件事角色怎么设计、上下文怎么交接、失败怎么处理。这三件事决定了接力流程是稳定还是脆弱的。2.1 角色与分工在接力式多Agent里“角色”不是花哨的设定而是一段职责边界明确的系统提示词加一组有限的工具权限。角色设计的目标是让每个Agent只回答它职责范围内的问题。举例来说“项目数据收集员”这个角色只需要读任务列表、提取已完成和未完成任务、输出JSON。“风险分析员”则只负责基于上一步的JSON做分析和建议它不应该被允许直接修改数据或编写周报。这样的职责隔离既降低模型的判断难度也便于后续做权限控制和审计。这里很容易踩一个坑角色描述写得太泛。比如给“数据收集员”写了一段“你是万能办公助手请协助处理所有办公事务”Agent下一次处理时就会把格式审核、文案润色一起做了反而破坏流程的确定性。角色的系统提示词应该像岗位说明书只写职责、产出格式、边界三条。2.2 上下文交接接力式协作的核心机制是上下文交接也就是前一个Agent把“做了什么、得到了什么、有什么需要特别注意的”打包传给下一个Agent。交接有两种常见方式。第一种是全量交接把上一步的完整输出塞进下一步的输入适合步骤少、输出短的小任务。第二种是精简交接只传递上一步的结论摘要、关键字段和新产生的中间文件路径适合长流程。实际项目里链路越复杂越推荐精简交接因为它能显著降低Token消耗也能避免下一步被上一步的冗长中间内容干扰。交接时有一个细节很关键要给每份上下文带上“数据版本”或“步骤编号”。否则一旦流程重跑或并发调试你会分不清某份周报到底是哪一批数据生成的。2.3 任务验收与重试接力流程里每个Agent的输出都应该有一个明确的验收标准。最简单实用的是格式验收要求输出必须是合法JSON、必须包含某些字段、必须通过长度检查。格式验收失败时可以直接把这个Agent重跑一次而不是把整条流水线从头跑。更高级一些的做法是安排一个独立质检Agent去验收上一个Agent的产物。比如“周报质检员”的任务就是对着原始数据检查周报内容是否一致。这等于在流程里加了一道“机器质检关”比只靠Prompt约束可靠得多。重试需要设计退避策略。模型接口在突发高并发下偶尔超时是正常现象通常重试两到三次、每次退避递增的指数退避比“死磕一次”和“无限重试”都更合理。2.4 从单Agent到多Agent协同的架构演进从架构视角看多Agent协同近年经历了一个明显的演进早期是“单Agent 长Prompt”后来是“多Agent自由对话”再往后是“多Agent按流程接力”。社区里像 jiuwenswarm 这类多 Agent 协同架构方案核心思路也落在“接力”二字上通过一套定义好的交接协议让Agent之间以标准化的方式传递任务和结果而不是让它们自由聊天。这类架构通常包含三个基础组件Agent注册中心负责维护角色清单和职责说明任务编排器负责决定谁接下一棒、什么时候交接上下文总线负责保存和传递中间结果。理解了这三个组件也就理解了多Agent协同架构的绝大部分内容。无论用什么框架落地本质上都是在做这三件事。3. 挑战任务设计一个完整的办公自动化场景架构聊完回到具体任务。为了验证接力式多Agent的真实效果我们把挑战任务设定为许多公司周一都会遇到的场景生成一份项目周报并且要能直接分发。3.1 任务背景从“周报”到“可分发结果”任务输入是两类文件一份任务列表JSON包含6个项目的任务条目、状态、负责人和进度百分比一份本周变更记录包含3条需求变更和1条风险提醒。任务输出是一份结构完整的周报文档并且要能通过质检。之所以强调“可分发结果”是因为实际办公里周报写出来只是第一步后续还要粘贴到群里、放进邮件、同步到看板。如果一个流程生成的周报还需要人手工整理格式那自动化的价值就已经打了一半折扣。3.2 任务要求我们给这个流程定了四条验收要求周报必须包含项目概况、本周进展、风险与建议、下周计划四个部分。项目进度数据必须与输入JSON完全一致不能由模型凭记忆补数据。周报语言风格统一可直接用于群发。流程中任意一棒失败要能定位到具体Agent并单独重跑。3.3 为什么这个任务适合接力式上面的四条要求里第一、二条尤其能体现接力式的价值。进度一致性要求意味着如果让一个Agent从头到尾处理它很可能在写周报时凭印象“美化”数字而接力流程里数据收集、风险分析、周报撰写、质检是四个独立步骤每个步骤的输出都被下一棒当作“客观事实”来使用改动数据的概率会大幅下降。团队协作场景也同理。当你需要一份报告经过多个人审核时接力流程天然相当于“数据收集员→分析员→撰写员→审核员”的虚拟团队。这套模式一旦跑通可以复用到日报、会议纪要、销售分析等一大批办公自动化任务。4. 环境准备与Agent并发配置进入实操前先说明运行环境和多Agent并发配置的核心要点。4.1 运行环境本次演示不绑定特定框架使用Python即可运行。建议环境Python 3.10及以上安装PyYAML库用于读取YAML配置准备一个可访问的大模型API或企业内部部署的模型网关。模型版本和接口协议以实际项目为准本文重点演示通用思路不绑定特定厂商。4.2 模型API接入真实项目里模型API接入一般会封装成一个统一的聊天函数输入是消息列表输出是文本。这个函数的内部实现取决于你用的模型供应商可能是OpenAI的API格式也可能是国内模型厂商的协议甚至可能是公司内部的私有模型服务。关键设计是多Agent流程不关心底层模型是谁只关心这个统一函数存在。这样一来替换模型时不需要修改任何Agent代码只需要改llm_func这个函数的内部实现。很多团队把模型切来切去Agent代码完全不用动就是这个设计带来的好处。4.3 Agent多并发配置的几个关键参数多并发配置是很多团队的踩坑点。把并发数值调大表面看是“让多个Agent同时干活”实际却可能触发模型API限流导致整条流程超时失败。以下参数需要认真配置。配置项作用建议max_workers全局并发线程池大小根据模型API的限流上限的50%到70%设置agent_concurrency单个Agent内部的并发上限有顺序依赖的Agent建议设1IO密集任务可设4左右timeout单次模型调用超时时间30到120秒视模型响应速度调整max_retries单次调用失败重试次数2到3次配合指数退避不要无限重试queue_size等待队列长度超过后拒绝新任务避免积压过深这些数值不是越大越好。尤其是max_workers和agent_concurrency需要根据模型API的吞吐能力和任务的实际依赖关系去调整。4.4 并发不是越大越好多Agent办公自动化的目标不是压榨吞吐量而是稳定完成流程。故意限制并发有时反而是正确设计。比如“质检员”Agent的并发设为1是因为审核步骤必须按顺序逐个处理同时审核多份报告容易让模型互相“看到”对方的上下文反而降低审核质量。另一个常见误区是把全局线程池开得很大认为这样能加速。实际运行中模型API的限流、上下文窗口长度、单次调用的响应时间都会比线程数更早成为瓶颈。更稳妥的做法是先小并发全链路跑通确认每个环节的平均耗时再按最慢环节来调整并发。5. 完整示例多Agent接力生成周报并审核分发下面是本次挑战的最小工程实现。代码不依赖特定Agent框架所有逻辑都在直观的Python文件里方便你理解每一步在做什么。5.1 项目目录结构agent-weekly-report/ ├── config/ │ └── pipeline.yaml ├── data/ │ ├── tasks_2025_week6.json │ └── changes_2025_week6.json └── src/ ├── agent_worker.py ├── concurrency.py ├── run_weekly_report.py └── main.pyconfig目录放多Agent配置data目录放办公任务输入数据src目录放Python执行代码。5.2 多Agent配置# config/pipeline.yaml version: 1.0 global: model: qwen-max temperature: 0.3 timeout: 60 max_retries: 2 agents: - name: collector role: 项目数据收集员 system_prompt: | 你是办公自动化流程中的项目数据收集员。 输入是项目任务列表和本周变更记录 你需要提取已完成任务、进行中任务、阻塞任务、变更说明。 输出JSON不要输出无关内容。 concurrency: 4 max_retries: 3 - name: analyzer role: 进度风险分析员 system_prompt: | 你是项目进度风险分析员。 输入是JSON格式的项目进度数据 你需要分析风险项、亮点、延期原因并给出建议。 输出结构清晰的Markdown分析结果。 concurrency: 2 max_retries: 2 - name: writer role: 周报撰写员 system_prompt: | 你是周报撰写员。 输入是Markdown格式的分析结果 你需要生成一份包含项目概况、本周进展、风险与建议、下周计划四部分的周报。 语言专业、简洁。 concurrency: 2 max_retries: 2 - name: reviewer role: 周报质检员 system_prompt: | 你是周报质检员。 输入是周报草稿以及原始项目数据。 请检查时间范围是否正确、任务数据是否一致、格式是否完整。 如果发现问题返回修改意见如果无误返回PASS。 concurrency: 1 max_retries: 3 pipeline: - step: 1 agent: collector output_key: collected_data - step: 2 agent: analyzer depends_on: collected_data output_key: analysis_result - step: 3 agent: writer depends_on: analysis_result output_key: weekly_report - step: 4 agent: reviewer depends_on: [weekly_report, collected_data] output_key: review_result重点解释一下这段配置。global节点是所有Agent的默认参数每个agents节点是一个角色的完整定义其中concurrency是Agent级并发上限max_retries控制重试次数。最后的pipeline节点定义接力步骤顺序output_key很像编程中的变量名每一步的输出都会写回一个全局上下文字典供后面的步骤引用。5.3 Agent执行单元先写最核心的AgentWorker类它负责执行单个Agent的调用与重试# src/agent_worker.py import json import time from datetime import datetime from typing import Any, Callable class AgentWorker: 一个轻量级的多Agent接力执行单元。 def __init__(self, config: dict, llm_func: Callable[[list], str]): :param config: 从 YAML 加载的 pipeline 配置 :param llm_func: 模型聊天接口入参是 messages 列表出参是文本 self.config config self.llm_func llm_func self.registry {agent[name]: agent for agent in config[agents]} self.context: dict[str, Any] {} def run_agent(self, agent_name: str, payload: dict) - dict: agent self.registry[agent_name] max_retries agent.get(max_retries, self.config[global][max_retries]) for attempt in range(max_retries): try: messages [ {role: system, content: agent[system_prompt]}, {role: user, content: json.dumps(payload, ensure_asciiFalse)}, ] result_text self.llm_func(messages) return { agent: agent_name, output: result_text, finished_at: datetime.now().isoformat(timespecseconds), } except Exception as exc: if attempt max_retries - 1: raise RuntimeError( fAgent [{agent_name}] 重试 {max_retries} 次后仍失败: {exc} ) from exc time.sleep(2 ** attempt) raise RuntimeError(fAgent [{agent_name}] 执行失败)这个类的核心逻辑是为每个Agent准备系统提示词和用户输入调用统一的模型函数得到文本返回时带上Agent名称和时间戳。失败时会指数退避重试直到耗尽max_retries。所有中间产物都保存在context字典里它就是“上下文总线”在最小实现里的样子。5.4 接力流程编排接下来定义办公任务的接力顺序# src/run_weekly_report.py import json from agent_worker import AgentWorker def run_weekly_report_pipeline(worker: AgentWorker, config: dict) - dict: 按 pipeline 配置的顺序执行接力。 每个 Agent 的输出写入 context下个 Agent 依赖上一个 Agent 的产物。 # 第1棒数据收集 collected worker.run_agent(collector, { task_files: [ data/tasks_2025_week6.json, data/changes_2025_week6.json, ] }) worker.context[collected_data] collected[output] # 第2棒风险分析 analysis worker.run_agent(analyzer, { project_data: json.loads(worker.context[collected_data]) }) worker.context[analysis_result] analysis[output] # 第3棒周报撰写 report worker.run_agent(writer, { analysis_result: worker.context[analysis_result] }) worker.context[weekly_report] report[output] # 第4棒质检需要同时看到报告和原始数据 review worker.run_agent(reviewer, { weekly_report: worker.context[weekly_report], collected_data: worker.context[collected_data], }) worker.context[review_result] review[output] return worker.context这段代码没有任何魔法就是按顺序调用四个Agent把前一步输出作为后一步输入。之所以这么“朴素”是因为接力协作的关键恰恰在流程透明每一步都显式写在代码里出问题时可以立刻定位到具体某一棒而不是混在复杂框架内部让人无从排查。5.5 并发控制与任务提交前面配置里的concurrency字段在最小演示里可以直接用信号量实现# src/concurrency.py from concurrent.futures import ThreadPoolExecutor from threading import BoundedSemaphore # 全局线程池建议先把线程数控制到不超过模型 API 限流上限的一半。 executor ThreadPoolExecutor(max_workers8, thread_name_prefixagent-task) # 每个 Agent 使用独立信号量避免多个 Agent 同时冲高请求量。 agent_semaphores { collector: BoundedSemaphore(4), analyzer: BoundedSemaphore(2), writer: BoundedSemaphore(2), reviewer: BoundedSemaphore(1), } def submit_with_limit(agent_name: str, fn, *args, **kwargs): 提交任务前先获取当前 Agent 对应的并发额度。 sem agent_semaphores.get(agent_name, BoundedSemaphore(2)) sem.acquire() def _wrapper(): try: return fn(*args, **kwargs) finally: sem.release() return executor.submit(_wrapper)信号量的作用类似“限行杆”当一个Agent已经有太多任务在跑时新任务会在sem.acquire()处等待直到有位置空出来。这样无论上游同时提交多少个任务落到模型API上的请求量都始终受控。5.6 入口文件最后把它们组合到主入口文件中# src/main.py import json import sys import yaml from agent_worker import AgentWorker from run_weekly_report import run_weekly_report_pipeline def load_config(path: str) - dict: with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def fake_llm_chat(messages: list) - str: 演示用占位函数实际项目请替换为真实的模型接口。 只需要保证入参是 messages 列表出参是文本。 这里根据系统提示词中的角色返回一段固定文本 方便你先把整个接力链路跑通。 system_prompt messages[0][content] if 项目数据收集员 in system_prompt: return {completed: 4, in_progress: 1, blocked: 1} if 进度风险分析员 in system_prompt: return ## 风险分析\n本周整体进展正常roadmap-data-delay 项目存在延期风险。 if 周报撰写员 in system_prompt: return ## 项目周报\n### 项目概况\n### 本周进展\n### 风险与建议\n### 下周计划 return PASS if __name__ __main__: config load_config(sys.argv[1]) worker AgentWorker(config, llm_funcfake_llm_chat) context run_weekly_report_pipeline(worker, config) print(json.dumps(context, ensure_asciiFalse, indent2))这里用fake_llm_chat作为占位函数目的只有一个让你在不依赖真实模型的情况下先把多Agent接力链路完整跑通。替换成真实模型时只需要改这个函数内部实现调用你自己的模型服务即可。运行命令python src/main.py config/pipeline.yaml到这里一个不含任何具体框架依赖的多Agent接力流水线就成型了。6. 运行结果与效果验证6.1 运行命令cd agent-weekly-report python src/main.py config/pipeline.yaml前置条件config/pipeline.yaml存在src目录下代码完整且已经在当前Python环境中安装了pyyaml。6.2 预期输出使用占位模型函数时输出是一份包含了collected_data、analysis_result、weekly_report、review_result四个键的JSON。每个键对应一棒的产物结构类似{ collected_data: {\completed\: 4, \in_progress\: 1, \blocked\: 1}, analysis_result: ## 风险分析\n本周整体进展正常roadmap-data-delay 项目存在延期风险。, weekly_report: ## 项目周报\n### 项目概况\n### 本周进展\n### 风险与建议\n### 下周计划, review_result: PASS }不要被这段看起来“简单”的输出迷惑。它的价值在于验证了接力链路本身是通的。替换成真实模型之后collected_data应该是结构化JSONreview_result要么是“PASS”要么是一段具体的修改意见。6.3 如何判断接力成功判断成功的标准有三个四个步骤全部执行完毕没有抛出 RuntimeError。每一棒的输出都成功写入上下文字典后面的Agent读取到了前一步的结果。review_result标示检查通过或者给出了可执行的修改建议。如果失败不要急着调并发参数先看是哪个Agent出错。日志里Agent [xxx] 重试 N 次后失败会直接告诉你问题出在哪一棒这是接力模式比单Agent长Prompt最大的优势之一。7. 常见问题与排查思路多Agent接力流程在实际运行中会遇到的问题很多都是共通的。下面这张表整理了几个高频问题问题现象可能原因排查方式解决方案Agent调用偶尔超时全局并发过高触发模型API限流查看模型网关或SDK返回的限流错误码降低max_workers每个Agent并发减半后再观察接力流程中途失败只能整条重跑上下文交接不完整下一步读不到上一步关键字段检查context字典中上一步的输出是否完整使用精简交接先做字段级校验再传给下一棒周报里的进度数字与源数据不一致模型在长上下文中“凭印象”补写对比周报数值与原始JSON把数据收集单独拆为一棒让撰写Agent只接触结构化结论并发较高时review结果变差审核类Agent被并行调用上下文互相干扰观察相同输入在不同并发下结果是否不一致审核Agent的concurrency降为1JSON解析报错模型返回了非JSON文本打印该Agent的原始输出在系统提示词中强调“只输出JSON”并在代码里做容错解析重试次数耗尽后仍然失败模型接口持续不可用检查模型服务状态和网络加熔断机制避免连续重试进一步放大故障这里重点提醒一下“重试次数耗尽”的情况。很多团队在重试失败后会把max_retries调大但真正的问题可能是接口配置、Prompt格式或者权限。先把单个Agent的输入输出打印出来检查比盲目调大重试次数更有效。8. 最佳实践与工程建议多Agent接力从“能跑”到“好用”中间还有很长的路。这里给出几条在真实项目中比较关键的建议。8.1 任务拆解的粒度多Agent接力的第一步是决定拆成几棒。拆得太粗比如“生成周报”作为一个Agent内部仍然是长Prompt模式失去了接力优势拆得太细比如“提取项目名”单独一棒又会引入大量无谓的模型调用和延迟。经验原则是按“阶段产物”来拆。每个Agent都要产出一个可以被后续环节消费的明确结果比如一份JSON、一段分析结论、一版草稿。步骤之间最好存在单向依赖尽量避免两个Agent互相修改同一个中间文件。8.2 上下文的传递结构上下文不要直接传原始大文本推荐设计成“核心字段 摘要 数据引用”的结构。比如收集员传给分析员的不是全部任务明细而是{ summary: 本周完成4项进行中1项阻塞1项, risk_keys: [roadmap-data-delay], data_ref: data/collected_2025_week6.json }这样做的好处是分析员不需要重新理解整份数据只需要基于摘要展开分析。如果需要看明细可以按data_ref指向的文件去读。数据引用方式也比全量复制更节省Token。8.3 容错与重试策略接力流程的容错要分层。第一层是格式校验每个Agent输出后立刻检查字段和类型第二层是单Agent重试配合指数退避避免连续失败打爆接口第三层是流程级补偿比如质检不通过时可以把报告退回给撰写Agent重新生成而不是重跑整个链路。退避策略建议使用2 ** attempt的指数退避并设置最大延迟上限。不要使用固定间隔重试也不要做无穷重试。任何重试逻辑都要配合超时和熔断防止模型接口出现故障时拖垮整个办公流程。8.4 安全边界与合规提醒办公自动化涉及阅读内部项目数据、生成对外文档甚至可能触发消息发送。实际落地时至少要做三件事最小权限每个Agent只授予完成本环节所需的数据读取和工具调用权限不要把“全部文档目录”都交给它。人工确认涉及对外发送的环节如邮件、群消息、审批提交建议先生成草稿由人确认后再发送。自动发送功能即使已经开发完成也建议先经过灰度验证。审计留痕每个Agent的输入、输出、耗时和重试记录都写入日志方便后续排查和追溯。上面的示例中没有写“自动发送”代码原因就在这里真正进入生产环境的办公自动化流程任何会产生外部副作用的操作都应该先具备确认和回滚能力。9. 总结与后续学习方向多Agent接力协作的价值不是把任务“摊”给多个Agent一起做而是把任务按阶段“切”开让每个Agent只处理自己擅长的环节再通过清晰的上下文交接把它们串联起来。它更适合办公自动化这类强顺序依赖的流程相比单Agent长Prompt更稳、更可控、更容易定位问题。本文通过一个周报生成与审核的挑战任务完整演示了四个角色、一套YAML配置、一个执行单元和一条显式接力流程。你可以直接在这个最小工程上继续扩展把fake_llm_chat替换成真实模型的聊天接口给每个Agent增加工具调用能力把pipeline配置改成支持热更新再逐步加入日志、监控和人工审核节点。下一步值得研究的方向有三个第一把pipeline.yaml抽象成通用配置让非开发同事也能配置Agent流程第二加入流程级补偿机制让“质检不通过→退给撰写员重写”这类回环成为标准能力第三探索动态角色调整比如根据任务复杂度自动决定拆成几棒。每个方向单独拎出来都是一片很大的实践空间而理解这些的前提是先跑通一套朴素的接力流程。建议你保存上面的最小工程下次遇到“又要取数、又要分析、又要写文档”的办公任务时先别急着写一条超长的系统提示词试着拆两棒、三棒让Agent们接力试试。