企业官网建设流程全解析

上个月接了个活儿，要做一条自动输出数据分析报告的流程：输入原始数据，系统自己产出图文报告，还要根据反馈自动改稿。我最初采取的做法比较偷懒，把一个Agent的系统提示词写得很长，让它同时扮演分析师、文案、图表工程师和审核编辑四个角色。前面两轮效果还可以，但从第三轮开始就明显不对劲：数据口径前后对不上、图表描述和结论开始跑偏、甚至有一次它把上一批数据混了进来。问题根源不是模型不行，而是我把太多职责压在一个Agent身上。

后来我把这套流程改成“多个Agent各管一段、由编排层统一调度”的结构，效果立刻不一样。这种把多个智能体组合成可协作系统的做法，在技术社区里常被称为Agent编排（Agent Orchestration），也有一类专门做这件事的项目，文件名里往往带着“agency-agents”，核心就是解决“多个Agent怎么配合”这个问题：谁负责拆任务、谁负责执行、谁负责检查、结果怎么传递、失败怎么处理。

这篇文章不打算只讲概念，我会把一套多Agent协作系统的完整链路拆开讲，包括为什么单Agent容易翻车、编排框架到底在做什么、自己搭一个时哪些模块最关键、真实跑起来会踩哪些坑、以及怎么判断一套框架适不适合自己。最后给你一套我一直在用的最小落地模板。适合正在做Agent应用开发、或者准备把复杂业务拆给多个Agent处理的开发者参考。

1. 单Agent翻车实录：上下文失忆、工具切换损耗与角色内耗

1.1 上下文失忆不是玄学：注意力资源是有限的

大模型的上下文窗口虽然越做越大，但“能装下”不等于“用得好”。在一个多步骤任务里，单个Agent需要同时记住用户原始需求、中间推导过程、工具返回结果、自己上一轮的输出。信息一多，注意力会被稀释，早期确定下来的关键约束很容易被遗忘。我遇到的具体现象是：任务进行到第四轮，Agent突然换了另一种口径重新计算，而且没有任何提示性说明，仿佛之前所有的对话都不存在。

上下文不只是对话历史，还包括工具调用结果。很多框架会把“用户消息+助手消息+工具返回”全部拼在同一份上下文里，这些信息之间会产生相互干扰。在单Agent模式下，这种干扰只能靠模型自身的注意力机制去扛；任务一长，效果必然下降。多Agent模式下，每个Agent只维护自己的局部上下文，相当于给每个岗位配了一本只写自己工作的笔记本，上下文串扰会明显减少。

1.2 思维与执行的反复横跳，损耗比想象中高

单Agent另一个常见问题，是在“思考”和“执行”之间反复横跳。举个例子，Agent为了回答问题，调了一个统计工具，工具返回了几千字的原始结果；它要把这个结果消化完，再回到原来的写作任务里。这时候它的思维连续性已经被打断，如果工具调用过程中出现报错，它还要额外花一轮去补救、自我纠正，而且纠正方向不一定对，有时候会陷入无效循环。

拆开之后情况就不一样了。执行类Agent可以连续专注在自己负责的工具调用上，不需要频繁切换任务状态；规划类Agent只做分析和调度，不接触具体工具输出。这种结构更贴近人类团队的工作方式：项目经理不会一边画图表一边审报表，专业的人只需要做好自己的那一段。

1.3 一个Agent扛四个角色，最后哪个都做不好

让同一个Agent既写代码、又写文案、又做质量审计，本质上是在要求一个模型在多套身份和话语风格之间来回切换。实测下来，稳定度很不理想。让它写报告的时候，它更像“写手”；让它审查自己的报告时候，它特别容易站在写作者立场自我辩护，而不是客观挑错。

多Agent协作可以做到职责分离，尤其是能安排一个专职审查Agent，它跟执行Agent没有利益绑定，指出的问题往往更尖锐、也更准确。这也是我最终转向多Agent结构的原因——不是追求架构上的炫技，而是因为单Agent的模式在综合任务里确实达不到可用标准。

1.4 多Agent真正改变了什么：注意力隔离与反向校验

总结成一句话：多Agent协作的核心不是“模型变聪明了”，而是通过职责拆分，让每个Agent的注意力范围变小、上下文更聚焦，同时引入独立的校验环节。规划者只做规划，执行者只做执行，审查者只做检查，每层都在自己专业范围内追求一致性和准确率。这套思路，也是“agency-agents”这类编排项目的灵感来源。

2. 编排系统到底在编排什么：Agent、任务、通信通道与一次完整生命周期

2.1 先把三个核心对象定义清楚

不管用什么框架，做Agent编排本质上都在管理三样东西：Agent、任务、通信通道。

Agent描述指角色、系统提示词、可用工具、上下文策略、输出契约。任务描述指输入、输出、依赖关系、超时时间、重试策略。通信通道描述指消息如何从A传到B、是同步还是异步、共享状态的读写权限怎么定。这三者缺一不可。

{ "agent_id": "data_analyst", "system_prompt": "你是一名数据分析师，负责根据给定数据集输出结构化分析结论。", "tools": ["data_reader", "statistics_calculator"], "context": { "window": 10, "shared_memory": "read_only" }, "output_schema": { "type": "object", "properties": { "metrics": { "type": "array" }, "conclusion": { "type": "string" } } } }

我最想强调的就是这个output_schema字段。没有结构化输出约定，后面的Agent只能靠语义理解去猜前一个Agent到底想说什么，这是大量踩坑的源头。后面我会专门展开讲。

2.2 三种编排拓扑：串行、并行与层级

• 串行流水线：Agent A的输出作为Agent B的输入，一路往后走。适合固定流程、依赖关系明确的任务，比如“先清洗数据，再算指标，最后写结论”。
• 并行扇出/汇聚：一个Router Agent把子任务同时分给多个Worker，最后统一汇总。适合子任务彼此独立的场景，能大幅缩短整体耗时，但汇总Agent的输入往往会很大，需要提前做好摘要。
• 层级委派：主管Agent把任务拆给子Agent，子Agent还可以再往下拆。适合组织层级复杂的业务，但每增加一层，延迟和失败概率都会上升。

没有绝对最优的拓扑，只有最匹配场景的拓扑。实际项目里三层往往混着用：顶层是Router，中间某些环节走串行，某些环节走并行。

2.3 一次完整生命周期：从用户请求到交付

以生成数据分析报告为例，一次完整的编排生命周期是这样走的：

1. 用户提交数据和需求，Planner Agent先做任务拆解，输出任务列表：数据清洗、指标计算、结论生成、图表方案、报告撰写、质量审查。
2. Router Agent把任务分发给对应Worker，每个Worker只拿自己需要的那个数据子集，而不是全部原始数据。
3. Worker执行完成后，必须返回结构化结果，并写入中间存储。
4. 汇总Agent读取所有中间结果，组装成完整报告草稿。
5. Reviewer Agent对草稿做质量检查，给“通过”或“不通过”。
6. 不通过则回到对应Worker重做，最多N轮。

这个闭环里每个节点都有清晰输入输出，任何一个环节出问题，都能快速定位到具体Agent和具体字段。

2.4 在哪个环节做失败回滚

每个环节都需要提前定义“什么算成功”：schema校验通过、关键字段非空、质量分达标、耗时在预算内。我建议用“状态机+重试+熔断”的方式，每个环节最多重试两次，连续失败就终止整条链路，并返回可读的错误信息。伪代码逻辑如下：

for idx, step in enumerate(plan): result = run_agent(step) if not validate(result): result = retry(step) if not result.ok() or retry_count >= MAX_RETRY: raise PipelineError(step.agent_id, result.error_detail)

这段伪代码背后的核心思想是：不要在大模型身上赌运气，而是把不确定交给系统层面的机制去兜底。让错误信息携带“哪个Agent、哪个字段、什么原因”，是后续快速定位问题的关键。

3. 自建Agent协作框架，建议先搭好这五块地基

3.1 上下文隔离与全局黑板的设计

我第一次搭建时犯过一个典型错误：让所有Agent共享整个对话历史。结果审查Agent能看到执行Agent的内部草稿，甚至被草稿里的语气带偏，把明显错误审成了基本通过。后来改成“上下文隔离+共享黑板”才解决问题。

所谓黑板模式，就是搞一个全局共享存储区域。每个Agent从黑板里取自己需要的数据，而不是接收完整对话上下文。写入权限必须严格把控，默认只读，只有执行结果确认有效后才能写。我会在黑板里给每条数据都带“数据版本+写入者+时间戳”，谁改了什么一目了然，出问题可以直接回溯。

3.2 工具注册表：工具描述规范比提示词更值钱

工具是Agent与外部世界交互的通道，工具描述越规范，模型调用准确率就越高。每个工具至少要有以下几部分：

• 名称、功能描述、参数schema、返回值schema；
• 超时时间、错误码定义；
• 权限级别：哪些Agent允许调用，哪些不允许。

工具返回值还需要限制长度。工具经常返回超大JSON，Agent拿着这么长的输出继续推理，非常容易迷失重点。我一般会在工具层做截断或者摘要，只把当前环节需要的关键字段塞回上下文。

3.3 状态机、重试、熔断、降级，一个都不能少

任务流转状态至少应该包含：pending、running、succeeded、failed、needs_review、retrying、cancelled。

• 重试策略用指数退避：第一次失败后等2秒重试，再失败等4秒，再失败等8秒，超过上限标记failed。
• 熔断策略：同一个Agent在同一任务里连续失败三次，直接触发链路熔断，不让后续任务继续消耗资源。
• 降级策略：主Agent不可用的时候，是否允许切换到备用Agent或者简化方案。比如统计接口挂了，可以让Agent用预先缓存的历史指标继续完成报告。

这套机制的本质是把异常处理从模型层面挪到系统层面，用确定性逻辑管理不确定性。

3.4 结构化结果契约

所有Agent的输出都应遵循明确的schema。可以是JSON、YAML，条件允许的话也可以上带版本号的Protobuf或Avro。哪怕没有条件引入强类型格式，至少也要约定JSON字段的命名和类型。

一个典型问题是：执行Agent输出“上个月用户量是五万左右”，汇总Agent无法判断“五万”是整数还是约数、单位是“人”还是“人次”。如果强制要求输出{"user_count": 50000, "unit": "person", "data_quality": "estimated"}，下游所有消费方都能稳定解析。我一直认为，在Agent协作里，结构约束的价值大于提示词引导。

3.5 可观测性：没有trace就别上生产

Agent系统调试极难，因为每一步都是非确定性输出。我会给每次Agent调用分配一个traceId，把输入摘要、输出摘要、token消耗、耗时、工具调用记录、失败原因全部落日志。关键中间产物也按traceId和step命名落盘。

没有可观测性的Agent编排，出了问题基本只能靠猜。我见过不少项目，线上跑一个月才发生一次问题，但因为没有trace，根本无法定位是哪一步逻辑出了问题，最后只能整体回滚。这代价太高了。

4. 真实踩坑记录：我反复遇到的几个高风险场景

4.1 上下文污染是怎么发生的

这个问题我前面反复提到，但值得展开讲。上下文污染有两种形态：一种是所有Agent共享全部对话历史，导致后一个Agent看到大量无关内容；另一种是系统提示词里塞进了过多背景材料，某个Agent承载了太多与自身职责无关的全局信息。

解决方式也简单：每个Agent的上下文只放三样东西——系统提示词、本轮任务输入、与该任务相关的黑板数据。其他信息一律不放。我甚至会在代码里做限制，某个Agent最多只能看到黑板里指定前缀的key，别的key直接过滤掉。

4.2 自然语言传值导致的关键字段丢失

第二次大坑是执行Agent输出一长段自然语言，汇总Agent得靠语义理解去提取关键数值。提取稳定是不可能的：有时候它会把“同比增长12.5%”理解成“绝对值增长12.5”，有时候又会漏掉小数位。后来我强制输出JSON，并且要求数值字段统一单位、统一小数位，提取准确率立刻提升。

这件事给我的教训很深：两个Agent之间传值，必须按数据结构传递，不能按自然语言传递。结构是机器可读的，语义是机器猜的。

4.3 两个Agent互怼到底：循环调用与成本失控

有一次，两个Agent互相挑毛病，一个说报告缺数据，另一个说数据已经提供了，来回修改了十几轮，token费用肉眼可见地上涨。问题出在哪？缺一个终止条件。

解决方案：给每条任务链设置最大轮次，比如最多3轮；同时全局设置成本预算，达到阈值自动终止，把最终版本交给人审。系统层面一定要有个“总开关”，不要指望Agent自己克制。让模型自我约束是不可靠的。

4.4 任务切得太碎与切得太粗，都是问题

项目初期，我把任务拆得很细，一个业务的逻辑被切成了十几个Agent，管理层和通信层变得非常复杂，一个环节出问题，整条链就卡住。后来又走到另一个极端，一个Agent塞进太多子任务，效果退化成单Agent。

现在我的原则是：能由一个Agent独立闭环完成的一个环节，就不要拆。判断标准是看这个Agent里面是否存在大量条件分支，如果它一会儿做A、一会儿做B、一会儿又要根据结果跳转到C，那就该拆；如果它只是按固定流程做完一件事，那保持原样。粒度以“环节”为单位，而不是以“动作”为单位。

4.5 随机性带来的调试噩梦与中间结果落盘

多Agent问题经常无法稳定复现。同一个输入，上午跑是好的，下午跑就挂了，因为模型输出有随机性。解决方式有两种：一是固定温度、top_p等采样参数；二是保留完整trace，把每一步的输入输出都记录下来。

我做的最值的一件事，就是给每个任务加“中间产物持久化目录”，按traceId和step命名，哪个节点出错一目了然。后来每次有人报问题，我第一句话都是“把traceId发我”，而不是问“你刚才做了什么操作”。

5. 怎么判断一个Agent编排框架适不适合你：我的评估维度与选型建议

5.1 我评估编排框架时的五个维度

1. 稳定性：是否支持超时、重试、熔断、回滚；错误信息是不是结构化。
2. 可控性：能不能精确控制每个Agent的上下文窗口、工具集合、模型参数。
3. 扩展性：新增Agent和新工具是否方便；有没有自定义中间件或钩子。
4. 成本透明度：能不能按任务、按Agent、按轮次统计token成本，而不是月底才看到一张总额账单。
5. 调试体验：有没有trace、回放、单Agent独立调试能力。

这五个维度我按顺序看，稳定性过不了关的框架，其他方面再亮眼也不会上生产。

5.2 我接触过的几类方案对比

我不妨用代号来分类我实际接触过的几类方案，避免废话：

开源式框架灵活度高，但很多稳定性功能要自己动手补；托管式平台开箱即用，可定制能力受限；轻量API式方案适合把已有Agent串成一条固定的任务链，稳定可控，但复杂拓扑的并发协调要自己设计。

5.3 我的选型决策建议

如果是固定流水线，我建议优先选轻量API式方案，或者直接在业务代码里写一个简单的编排层。不需要动不动就上一整套Agent关系图，很多项目的复杂度根本不需要那种重装备。

如果业务快速变化，后期要叠加很多模块，再考虑引入更完整的编排框架。我的判断标准是：当业务里出现“同一类任务要支持多套处理路径”时，才真正需要一套可视化的编排系统；如果只是从头到尾一条路走到底，自己写个循环就够用了。

6. 我在用的最小落地模板：Router + 三个Worker + 一个Reviewer

6.1 模板结构：五个Agent起步

这套模板是目前我在多种业务场景里反复使用的基础结构，一共五个Agent：

• Router Agent：负责拆解用户请求，把子任务分发给各类Worker，并收集结果。
• Worker 1：负责数据准备和数据清洗。
• Worker 2：负责核心计算、分析和内容生成。
• Worker 3：负责格式整理和图表输出建议。
• Reviewer Agent：负责对整体结果做质量校验，给出修改建议。

每个Worker的输出都定义成JSON，都有清晰的字段约束。整个流程一句话概括：用户请求进来，Router拆解，Worker们并行执行，汇总成结果，Reviewer校验通过后输出。

6.2 从一个Agent升级到五个Agent，具体怎么改

如果你手上已经有一个能跑但总出问题的单Agent，不要推倒重来，按下面几个步骤改造：

1. 梳理单Agent现在要做的所有事，画出一条任务链。比如：理解需求、取数、分析、写作、检查。
2. 把每两个相邻环节之间要传递的关键信息列出来，定义成数据结构，并加好字段名和类型。
3. 为每个环节单独创建一个Agent，把原来系统提示词里对应角色的描述剪切过去。
4. 写一个Router逻辑，把上一步Agent的输出解析成数据，作为下一步Agent的输入。
5. 最后加一个Reviewer Agent，专门做“挑错”这件事。

这套改造不依赖任何重型框架，Base逻辑可以全部放在业务代码里。跑通之后，你自然就理解了编排系统到底在解决什么问题。

6.3 向更复杂场景扩展时，我一直坚持的三个原则

首先，每次想加一个新的Agent或层级，我会先问自己这层真的有必要吗。Agent数量一多，通信链路、错误排查、token成本都是指数级上升。能用已有的Agent解决的问题，绝不多开一个。

其次，任何Agent都要有“不知道就直说”的出口。大模型在被逼无奈时倾向于强行生成结果，我在这上面吃过不少亏。现在每个Agent的提示词里都会有一句“如果信息不足以回答，直接说明，不要猜测”。

最后，可观测性永远前置。新的Agent上线前，先把日志、traceId、中间产物落盘这些配套做好，再让流量进来。没有监控就跑生产，等于在裸奔。

回到开头那个数据分析报告项目，现在它已经稳定运行一段时间了。每次有新的分析需求，只需要Router拿到任务列表，分发给对应Worker，Reviewer兜底审核，整套流程就能自动闭环。我想说的不是某个具体框架有多好，而是在多Agent协作这条路上，真正决定上限的不是单个模型的能力，而是把任务切分清楚、把上下文隔离干净、把失败处理到位。这套工程经验，比任何具体工具都值钱。