企业官网建设流程全解析

1. 多agent系统工程为什么突然成了硬需求

这两年聊AI应用，单agent的Demo已经满天飞了，真正拉开差距的反而是那些把多个agent塞进一个生产系统的团队。我见过不少项目，最开始只是一个 chatbot 套了层工具调用，跑通之后业务方立刻提需求：你帮我加个能查库存的、加个能写周报的、加个能自动跟客户对线的。单个agent的功能越堆越臃肿，提示词里塞了几十条规定，上下文窗口永远不够用，改一个需求要连带调三处prompt。这时候你才会意识到，agent这玩意儿本质上跟微服务一样，得拆。

拆成多个agent之后，问题并没有变少，反而变多了。谁来调度？消息怎么传？每个agent的记忆是共享还是隔离？A agent调B agent，B agent又调C agent，调用链断了怎么办？某个agent抽风输出了非法JSON，是重试还是降级？更头疼的是，每个agent背后可能挂着不同的模型、不同的API Key、不同的知识库权限，怎么统一管？这些事儿单个agent时代根本不会遇到，一旦你走上了多agent的路，它们就全是绕不开的工程问题。

这篇文章要聊的，就是我从架构设计到治理体系落地过程中踩过的坑和沉淀下来的方法。不是给你讲学术概念，也不是贴一堆论文术语，而是站在工程视角，把一套可复制的多agent系统落地路径掰开揉碎讲清楚。内容包括：agent之间到底该用什么协议通信、记忆和工具怎么拆分、规则引擎和LLM的边界画在哪里、从POC到生产要经过哪几个阶段、身份权限和可观测性怎么建设、以及成本失控和prompt注入这些坑的应对手法。适合正在做多agent应用的开发者、准备把AI Agent引入业务系统的技术负责人，以及被老板一句话“搞个AI出来”逼到墙角的朋友参考。

2. 多agent架构设计的方法论拆解

2.1 先搞清楚：你到底需要几个agent

很多人一上来就规划了十几个agent，什么客户画像agent、情绪识别agent、话术推荐agent、跟单提醒agent……听起来很酷，实际上维护成本直接爆炸。我见过最夸张的项目，一个售前咨询系统挂了12个agent，其中3个agent的prompt几乎一模一样，区别只是名字不同，纯属凑数。

我的建议是，agent拆分的粒度要遵循三个原则。第一，职责单一且不可再分，一个agent只干一类事，比如“订单状态查询”和“售后政策解释”就应该拆开，但“订单状态查询”和“物流轨迹查询”如果数据源是同一个系统，可以先合并成一个“订单物流查询agent”。第二，依赖边界清晰，agent之间的交互要尽量通过消息而不是共享内存，如果一个agent要频繁读另一个agent的内部状态，说明边界没画对。第三，演进成本可控，agent数量控制在7±2个以内，超过这个数，编排逻辑的复杂度会指数级上升，排查问题也会变得非常痛苦。

我在实际操作中常用一个反向验证法：先写单agent版本，把业务跑通，然后观察这个agent里哪些意图是互相干扰的、哪些工具调用是频繁切换的、哪些上下文是不同角色才需要的，再按这些信号来做拆分。说白了，多agent不是设计出来的，是长出来的。

2.2 协作协议：不要自己发明轮子，直接用message bus

多agent系统里最核心的架构决策，不是选哪个模型，而是agent之间怎么说话。我在早期项目里试过直接让agent之间互相调函数，A agent把参数传给B agent，B处理完再返回。听起来很直接，但实际跑起来全都是坑：调用链深了之后，中间任何一环超时，整个链路就挂在那一层；A和B必须同时在线，部署和升级都得一起搞；想插一个日志或者审计节点，得改一堆代码。

后来我采用了基于message bus的协作方式。简单说，所有agent不直接互调，而是把消息发到一个统一的路由层，由路由层决定这条消息该由哪个agent处理，处理完的结果再作为新消息回到总线上。这个方案的好处是：agent之间彻底解耦，每个agent只关心“收到消息、产出结果”，不关心消息是谁发的、发给谁；中间任何环节出问题，消息可以在总线上重试、排队、甚至转发到人工处理；新增一个agent只需要注册消息类型，不用改动现有链路。

从我的实践来看，实现一个轻量的message bus并不复杂，本质上就是一个带有路由规则的消息队列。路由规则可以基于意图识别、正则匹配、或者简单的LLM分类。初期可以用Redis Stream或者RabbitMQ顶一阵子，别一上来就上重型中间件，等量起来之后再演进到Kafka，这个节奏比较稳妥。

2.3 多agent接口设计的坑：参数、超时、流式，一个都不能少

多agent之间传递消息，接口设计直接决定系统的可靠性和排查效率。我总结了一个“最小可靠接口”清单，任何一个agent对外暴露能力，至少需要包含以下字段：消息ID（用于全链路追踪）、来源agent标识、目标agent标识（可以是通配符，表示广播）、消息类型（业务类型）、业务参数（结构化JSON）、时间戳、以及可选的元信息（如模型版本、prompt版本、trace ID）。

在实际调用中，有两个参数特别容易被忽视。一个是超时时间。agent之间互相调用，如果同步等待响应，必须设置合理的超时，我一般默认设成10到15秒，复杂的任务会放宽到30秒，但必须配合异步回调或者轮询机制，否则一个慢agent会把整个链路拖死。另一个是流式响应。有些agent任务（比如长文生成、多轮复杂分析）耗时很长，如果非得上同步返回，前端体验极差，这时候应该改成消息总线上推送流式事件，让调用的agent按事件类型增量处理结果。

我之前踩过一个严重的坑：两个agent同步互调，其中一个agent调外部API偶尔要40秒才返回，结果请求全部挂在那个agent等待上，导致整个API gateway超时，上游全报502。后来改成了异步事件驱动，所有长任务都走消息总线的发布订阅模式，核心链路的稳定性直接上了一个台阶。

2.4 记忆与工具设计：可插拔的三级记忆体系

多agent系统最容易被人忽略的，其实是记忆架构。很多团队把记忆简单理解成“把聊天记录存下来再传回给LLM”，这在单agent场景勉强能用，但多agent下，每个agent对记忆的需求完全不同——订单agent需要知道这个用户的订单上下文，推荐agent需要知道用户的偏好历史，而安全agent可能完全不需要记忆，每次调用都应该是无状态的。

我实际落地的是三级记忆体系。第一级是线程级记忆，类似会话session，记住当前这一轮任务中Agent之间的交互过程，作用域是单个任务链路，任务结束就可以释放，实现上直接放Redis，TTL设成任务预估时长的1.5倍。第二级是对象级记忆，比如用户画像、订单状态、项目上下文，这类记忆按业务对象维度做Key-Value存储，多个agent可以共享读，但写权限要严格控制，避免互相覆盖。第三级是长期记忆存储，沉淀用户的长期偏好、历史决策、行为模式，一般落到向量数据库，供需要相似性检索的agent使用。

工具的设计同理。不是每个agent都要挂全套工具，工具应该按agent职责做白名单，同时工具挂在总线上做成可编排的。我的做法是工具注册表+工具路由，agent声明自己需要哪些工具，路由层做鉴权和分发，工具执行结果再写回消息总线。这样新增工具不用改agent，新增agent不用改工具，两边都保持了松耦合。

3. 多agent基础架构与核心组件选型

3.1 组装层是灵魂：别把编排逻辑塞进prompt

多agent系统的架构图，很多人第一反应是画一堆agent方块然后连上线，实际上真正的核心是中间的编排组装层。这个层承担三件事：意图解析与任务规划、agent选择与调用编排、结果汇聚与冲突消解。

意图解析和任务规划，我建议用LLM做粗粒度判断，再用规则做细粒度锁定。比如用户说“帮我查一下上周订单的物流状态，顺便看看有没有退款纠纷”，粗粒度识别出这里面有两个意图（物流查询+退款查询），规则层再映射到对应的agent。完全依赖LLM做规划的问题在于不可控，完全依赖规则又太死板，所以分层是最合理的。

结果汇聚这块也很关键。多个agent返回结果后，不能简单拼在一起返给用户。需要先检测冲突——比如订单agent说已发货，售后agent说在退款处理中，这俩信息要合并得讲清楚状态优先级。我常用的做法是设置一个“结果仲裁agent”，专门做信息合并、矛盾消解、以及最终的回复生成。它不干业务，只干表达，但是这一步的质量直接决定了用户体验。

这里有一个容易掉进去的误区：把所有编排逻辑都塞进某个主agent的prompt里。早期我就是这么干的，结果那个主agent的prompt越来越长，最后超过上下文窗口极限，还得花钱买更大的token限额，关键是行为越来越不稳定。后来我把编排逻辑下沉到代码层，prompt里只留策略性描述，系统可靠性明显改善。记住一句话：prompt只表达策略，不承载流程，流程交给代码。

3.2 规则引擎与LLM的边界：能上规则就上规则，别什么都让模型去猜

在多agent系统里，规则引擎和LLM不是替代关系，是互补关系。我从失败经验里总结了一个边界划分原则：凡是逻辑确定、输入明确、判断标准固定的环节，一律用规则引擎；凡是逻辑模糊、语义复杂、需要推理和生成的地方，才交给LLM。

举个例子，订单退款申请里有“金额超过5000元必须人工审核”这么一条规则。你当然可以把这条写进agent的prompt，让它“理解并在超限时触发人工审核”，但实测下来模型偶尔会漏判断，或者因为上下文里刚好出现了别的数字而搞混。更稳的做法是，agent只负责提取退款金额，规则引擎判断是否触发人工审核条件，一旦命中就走人工队列，agent完全不需要知道这条规则的存在。

我自己在项目里用的是一套两层漏斗：请求先进规则层做合法性校验、权限校验、频率限制、参数格式检查，通过之后才进LLM层做语义处理和生成。这套架构下，LLM的调用量大概能减少30%到50%，成本下降还只是一方面，更关键的是系统行为的一致性大幅提升。很多p70问题（模型偶尔抽风）根本不会露到用户面前。

3.3 多agent基础架构图：组装层和executor层的拆分

这里给一张我实际落地的多agent基础架构图，画成文字描述也完全够用。最底层是Agent Runtime，提供agent运行环境和通用能力，包括prompt模板管理、上下文构建、模型调用封装、响应解析。这一层之上是Agent Executor，每个agent业务逻辑的执行单元，接收标准化的输入，调用自身的工具集和记忆，输出标准化协议格式的结果。

再往上是组装协调层，对应前面说的规则引擎、任务规划、agent路由、结果仲裁。这个层不执行具体业务，但它决定了哪个agent在什么条件下被调用、调用顺序是什么、并发还是串行、结果如何合并。架构图最顶层是暴露层，统一出口的API Gateway，把内部分散的消息协议转换成前端的HTTP/WS接口，同时承担auth、限流、审计。

为什么一定要拆出这两个层？从运维角度看，executor层的agent可以按资源和负载独立扩容，组装层则作为有状态服务做集群部署，避免单点。从升级角度看，业务迭代只需要升级某个executor，组装层的路由规则可以通过配置热更新，不用重新发版。从治理角度看，完全的横切能力——日志、trace、鉴权、限流——可以统一挂在组装层，不用每个agent自己实现一遍。

4. 多agent工程落地路径：从POC到生产化的三个关键阶段

4.1 路径规划：不是一步到位，而是分三阶段走

多agent系统最忌讳的就是“一步到位”。我见过一个团队花两个月设计了一套完美的多agent架构，结果上线后发现业务根本没那个复杂度，白白养了8个agent在跑空气。我现在的习惯是分三个阶段推进，每个阶段有明确的目标和退出条件。

第一阶段是POC验证，目标只有一个：“证明多agent比单agent更能解决业务问题”。这个阶段不需要完善的工具链，不需要写复杂的消息总线，甚至可以直接用AgentScope 2.0这类框架内部的多agent API来快速搭原型，逻辑上跑通就行。重点记录的是：多agent拆分的收益在哪里？复杂的编排是否真的可靠？哪些问题上多agent反而更差？这个阶段一般控制在2到3周，不该恋战。

第二阶段是MVP上线，目标从“能跑”变成“能用”。这时候开始引入message bus、规范化消息协议、搭建基础的可观测性。这个阶段可以容忍一些小问题，比如偶尔的调参不稳、部分agent还需要人为兜底，但核心链路必须是稳定的。我通常会把所有agent的failback路径都梳理一遍，保证任何一个agent宕了都有降级方案，不会让用户直接看到报错。

第三阶段才是生产化，目标进化成“可治理”。身份权限体系、全面的trace、token粒度的成本核算、安全审计、prompt版本管理、灰度发布机制，全部在这个阶段到位。很多团队前两个阶段走得很快，第三阶段拖了很久，我实测的结论是：如果前两个阶段把协议和边界理得够清楚，第三阶段更多是配置和平台层的搭建，反而会很快。

4.2 POC阶段怎么做：先定目标，再定验收标准

POC是最容易跑偏的阶段，因为做Demo太容易了。做个多agent协作演示，看起来很酷，但你要清楚这3周花的每一分钟都在验证什么。我给团队定的POC目标是限制在“能自主走通业务流程闭环”这一点上，只选择一条核心业务链路来跑通多agent协作，其它分支全部忽略。

验收标准要有明确的量化数字。我在一个电商售后场景里定的标准是：同一问题，多agent方案的首次解决率要比单agent基线高15个百分点，且平均响应时长不超过基线时长的1.5倍。如果达不到，说明这个场景确实不适合拆成多agent，那就回去用单agent，别死磕。

这个阶段技术上的关键其实就在三个地方：上下文是怎么在多agent之间传递的、工具调用会不会互相阻塞、以及模型在agent间互相调用时的指令遵循度如何。AgentScope 2.0的多agent调用API在POC阶段挺好用，因为它内置了消息传递和agent编排的基本能力，起码不用你从头写一套总线，省下来的时间全部拿去验证业务假设。

4.3 从POC到MVP：补齐稳定性短板

从POC到了MVP，最大的变化是从“万岁，跑通了”变成“挂着也要能用”。这阶段最优先做的事，是给每个agent定义明确的降级策略。比如订单agent挂了，是直接从ERP系统拉数据做个简化版回复，还是走人工客服兜底？我通常按“agent重要程度”和“替代难度”画个矩阵：高重要+高替代难度的，要做双活或者热备；低重要+低替代难度的，直接容错跳过就行。

第二个要做的，是编织核心链路的全链路trace。多agent系统排查难度比单agent高出太多，一条消息从进入总线到最终返回，中间可能经过三四个agent、六七次函数调用，任何一个节点出问题，如果没trace光靠日志翻，能把人逼疯。我用的方案是每个请求从API网关入口生成一个trace ID，通过消息协议里的元数据字段传递到所有agent，每次调用和工具执行都把trace ID带上，落到统一的日志平台，后续用trace ID一键拉全链路记录。

第三个是组件精简。MVP阶段不要什么都上，向量数据库、知识图谱、流式计算这些，等真有需求了再加。我在早期项目里吃过苦头：POC阶段为了演示效果，接了一个很重的本地知识库引擎，MVP阶段线上流量一起来，性能瓶颈全在那个引擎上，排查了两天才定位到问题，后来切成了Redis缓存+轻量检索，性能问题直接消失，而这个操作只花了半天。

5. 多agent治理体系怎么搭：身份、观测、评估、安全与成本

5.1 身份与权限治理：每个agent必须有自己的身份

多agent系统一旦接入真实业务，首先面对的就是权限边界问题。你不能让一个只负责查天气的agent拥有删除订单的权限，也不能让一个业务agent看到另一个业务agent的敏感数据。这块的落地经验是两件事：身份隔离和权限矩阵。

身份隔离的意思是，每个agent在系统里都注册成一个独立的服务账号，有自己的agent ID、独立的API Key、独立的密钥存储。所有消息总线的读写、工具调用、知识库访问，都用这个agent ID做身份标识。这一层的价值，不只是安全，更是审计——任何一条消息和操作，都能回溯到具体的agent和服务，出了事能问责到具体对象。

权限矩阵则是定义每个agent能干什么、不能干什么、能看什么数据。我通常用两种粒度来做：项目级权限和函数级权限。项目级是粗粒度隔离，比如A项目组的agent不能访问B项目组的工具；函数级是细粒度控制，比如订单agent能够调用退款工具但单笔退款上限是1000元，超过就得经过审批流。这种双层权限体系，既保证了业务灵活，又卡住了底线风险。

5.2 可观测性建设：trace之外，还有三层数据不能丢

可观测性是多agent系统治理的基石。很多团队做trace只关注“谁调了谁”，但我实际落地下来发现，至少还有三层数据同等重要。

第一层是LLM调用层面的token审计，也就是每个agent每次模型调用用了多少token、什么模型、请求和响应摘要存一份。这一层数据直接决定成本归因——哪个agent烧钱最凶、哪条业务链路成本不合理，一查就知道。第二层是任务层面的状态流转日志，每个任务从进入总线到完成，经历了哪些状态、每个状态耗时多少、哪一步卡住了，都要有日志。第三层是决策记录，就是LLM在编排层做的关键判断——为什么选了A agent而不是B agent，这是排查幽灵问题时候的救命线索。

这三层加一块，就是从“系统在跑”到“我知道系统为什么这么跑”的差距。我曾遇到过一个问题：某个agent在特定条件下老是回复错误答案，单看它的输入输出完全看不出毛病，后来靠决策记录发现，是编排层的路由规则每次都把这类请求错误地路由给了一个不相干的agent，才导致上下文完全错位。没有决策记录，这个问题可能查一晚上都找不到根因。

可观测性上还有个小坑，就是日志格式的统一。多agent系统里日志来源太多了，bus日志、agent日志、工具日志、LLM调用日志，如果格式不统一，排查起来就是灾难。我的做法是定义一套全系统统一的日志schema，包含时间戳、级别、trace ID、agent ID、消息类型、输入摘要、输出摘要、耗时、token用量这几个字段，所有的日志SDK都按这个schema输出，后续接入ELK或者Loki都不用再加工。

5.3 评估机制与质量保障：离线评估和线上回流都要做

多agent系统上线后，质量评估是很多团队完全没做的事。单agent时代可以靠人肉看几条对话来判断效果，多agent的链路复杂度和状态空间太大，人肉根本看不过来。我落地的是“层别评估+场景集合测试”的方案。

层别评估就是把评估分成三个层级。单agent层，评估每个agent在自己的职责范围内的输出质量，这个可以用传统的LLM评估方法，比如基于标注集跑Bleu/Rouge，或者用GPT4做裁判，但注意要建一套自己的标注集。链路层，评估整条业务链路的完成率和质量，这里就得设计端到端的场景集，每个场景包含一组用户输入和对应的期望结果路径，跑完之后统计链路完成率和步骤正确率。系统层，评估系统在多用户并发、异常情况下的表现，比如agent宕机降级是否生效、bus积压时会不会拒单、恶意输入会不会被挡住。

线上回流也很重要。我会给线上系统加一个“低置信度样本标记”机制，凡是用户点了踩、用户转人工、或者answer仲裁agent觉得多个子agent结果冲突较大的，都自动回流到标注池，定期人工分析，再补进场景集。这套机制跑两个月，场景集会越来越完整，系统的回归测试价值会体现得非常明显。

5.4 评估指标怎么定：别只盯响应时间，多看业务完成度和安全红线

指标定义直接决定系统的优化方向。我给团队定的多agent系统关键指标分五类：响应性能、业务质量、安全合规、成本效率、稳定性。

响应性能就是端到端的响应时间、首包时间、排队时间，监控这部分用我们第二套trace系统就够了。业务质量最核心的指标是业务完成率，也就是用户目标最终被解决的比例——很多团队只盯响应时长，结果系统回应越来越快但用户的单子反而都没搞定，这就本末倒置了。安全合规方面，必要的时候像Prompt注入拦截率、敏感数据泄露检测覆盖率、权限越权拦截数，要有基础的数字。成本效率则是每单成本、每token产出、agent利用率，这个后面单独讲。

稳定性指标我用三个数：核心链路SLA（要定义到具体链路，比如订单处理链路95线小于10秒）、agent故障恢复时间MTTR、以及消息总线积压量峰值。拿这些指标建一张大屏，每日跑批自动刷新，每周一份报告，哪个agent快不行了一眼就能看出来。

我放一张我常参考的评估指标矩阵表格，方便你直接对照建自己的版本：

5.5 安全与成本控制：LLM幻觉输出和prompt注入要双层拦截

安全和成本这两块，是生产环境跑一段时间后才会浮出水面的问题，但必须在设计期就给到足够的关注。

安全方面，多agent系统比单agent多出来的攻击面是很明显的。一个是Prompt注入。在单agent场景，注入的PV可能只是单纯影响模型输出，但在多agent系统里，一个被注入的agent可能会把恶意指令传递到下游，变成跨agent的“指令渗透”，破坏范围被指数级放大。我采用的方案是双层拦截：第一层在消息总线入口和出口设置规则级过滤器，对明显可疑的内容直接拦截；第二层在关键agent的prompt里注入防注入的约束指令，同时对所有agent的外部输出做一次LLM判断是否包含敏感指令。另外，如果消息包含URL或者代码块，必须先经过安全沙箱再转发给下一个agent，防止SSRF或者提示词注入。

成本方面，多agent系统的成本失控一般有三种典型路径。第一种是编排层失控，意图解析之后每个子任务都调一次LLM，单单意图解析一个环节就烧掉很多token，这种能做缓存就做缓存，能上规则就上规则。第二种是循环调用失控，两个agent互相传递消息陷入死循环，每条消息都触发LLM调用，这种必须设置跳数上限和环路检测，我实际设的是单条业务链路最多嵌套5跳agent调用，超过就直接中断并转人工。第三种是token浪费，每个agent返回的完整结果都被下游原样带进上下文，越传越长越传越贵，这种要对agent间传递的消息做裁剪，只保留和下游任务相关的字段，能省下一大笔成本。

我最后一次核算过，一个中等规模的多agent系统，如果只做了裁剪和缓存两项优化，LLM调用成本直接降了差不多一半，而业务效果几乎没变化。成本治理这件事，很多时候不用憋大招，把浪费的路径堵上，收益就已经很可观了。

6. 多agent落地遇到的坑与高频问题实录

6.1 典型故障与排查思路速查表

多agent系统的故障，很多是从单agent时代想象不到的。我把生产环境里最常遇到的五类问题单独拎出来，整理成一张速查表，也是我每次新项目都会拿出来过一遍的清单。

我的经验是，多agent系统里80%的管线问题，其实都能通过trace数据快速定位，真正难查的是“行为正确但逻辑错误”的问题，比如agent选错了、推理路径偏了，这种就只能靠积累决策记录和场景集回归了。

6.2 避坑过程实操：一例多agent链路调优的复盘

拿一个真实场景来说，一个售前咨询系统我上了三个agent——商品信息agent、库存查询agent、优惠计算agent。上线第一周就发现，用户问“这款鞋什么码还有货，能便宜点吗”，系统经常卡在优惠计算agent很久不返回。

排查过程是这样的。先拿trace ID拉全链路，发现请求进入到优惠计算agent之后，该agent又调用了商品信息agent去查询价格，然后才计算优惠，整个过程多了一次跨agent调用。原因在于，商品信息agent返回的结果里只带了基本字段，优惠计算agent拿不到它需要的原价商品ID字段，所以只能回头再查一次。

解决办法其实很简单，就是消息协议里在商品信息agent的返回结果里补上原价商品ID，同时把优惠价格计算的依赖前置——在进入优惠计算agent之前，路由规则先把原价和优惠券信息都准备好塞进消息。这样改完之后，这个链路的响应时间基本砍半，而且优惠计算agent的prompt也简化了，因为它不用再从下游捞数据了。

这个案例给我的启发很直接：多agent系统的性能问题，很多时候不是模型太慢，而是agent之间的数据依赖设计不合理。你在设计 agent 职责边界的时候，就要顺手把每个agent的输入输出契约定清楚，下游需要什么字段，上游一次给全，能少一次调用就少一次调用，性能提升立竿见影。

7. 留给后来者的个人经验与关键提醒

多agent系统做到最后，你会发现最难的部分永远不是技术，是取舍。你要在智能程度和可维护性之间取舍，在自动化和可控性之间取舍，在成本和质量之间取舍。架构上没有完美方案，只有当前业务阶段下的最优解。我个人的经验是：先搭一套尽量简单的agent协作协议，能用顺序调用解决的绝不引入复杂路由，等业务复杂度真的上来了，再逐步演进，让架构跟着业务走，而不是让业务被架构卡死。

另一个我觉得非常重要的经验，是治理要前置。不少团队把治理当成上线之后的事，结果一上线就碰到越权调用、成本飙升、故障无法回溯这些幺蛾子，才回头补治理，补的时候又要停工，代价翻倍。所以我的习惯是：哪怕是在POC阶段，消息协议里就必须带上trace ID字段；哪怕是在MVP阶段，每个agent就必须有独立身份。这些基础工作越早做，后期省下的时间就越多。

最后说一个我在这个领域里反复验证过的体会：多agent系统的落地，本质上是把一个复杂任务拆成多个简单任务，再把多个简单任务编排成一个可靠的工程系统。任何一步做得过度，都会让系统变得复杂低效。真正能跑上生产的多agent系统，一定是那些知道什么时候该用agent、什么时候不该用agent的团队做出来的。这比你能用多少agent，重要得多。