企业官网建设流程全解析

2026年国内AI Agent企业应用的预测报告陆陆续续放出来了，我前后筛了150份相关报告和十几套数据合集，越看越觉得有意思：大家嘴上都在聊“智能体取代流程”，实际动手时却都在问同一批问题——Agent怎么扛并发、平台搭建和自己写框架到底差在哪、智能体行为审计是什么、Rust写的Agent是不是噱头。

这篇就把我梳理过程中觉得最关键的几个判断、工程上最扎手的几个坑，以及报告里不会写但执行时一定会踩的细节，统一拆出来讲清楚。内容主要面向正在做AI转型规划的企业架构师、研发负责人，以及想从零搭建智能体的开发者和产品经理。你可以把它当成一份“预测报告之外的施工参考”，而不是又一篇理念科普。

1. 2026年智能体市场预测的核心信号

1.1 预测数字怎么读：别只看“千亿”和“渗透率”

市面上能看到的2026年中国AI Agent企业应用预测，绝大多数是两条线推出来的：一条是自上而下的市场规模测算，另一条是自下而上的场景渗透率调研。前者给你一个总数，后者告诉你钱会流向哪里。真正有用的不是“2026年中国AI Agent市场规模将突破XXX亿”这种标题，而是支撑这个数字的场景拆分、客户画像和付费意愿数据。

我在整理报告时注意到一个共性现象：所有预测里增速最快的都不是那种“大而全”的企业级超级智能体，而是聚焦单一业务职能的垂直智能体——智能客服、营销内容生成、数据查询助手、代码评审助手。理由很朴素：企业买单看的是“能不能在我现有系统里跑起来并省下人力”，而不是“你是不是通用人工智能”。所以阅读这类预测报告时，我建议你直接跳到场景章节，把“渗透率”当成“落地难度”的反向指标：渗透率越高的场景，说明技术成熟度和付费意愿都已验证，反而可以放心抄作业。

另一个值得关注的指标是“预算归属”。部分报告会统计企业在智能体上的预算是从哪个部门出的：IT部门、运营部门还是市场部门。这个信息比规模数字更实用。它直接决定了你的项目汇报对象、验收标准，甚至还影响你用Python自建还是用平台快速搭——由业务部门出钱的项目，通常更看重交付速度和可视化，技术部门出钱的项目则更看重扩展性和源代码可控。

1.2 四大基本盘：客服、营销、运营、研发

综合我手头这批报告的场景分类，几乎都把企业Agent应用分成四个主战场。

客服与售前触达是渗透最早的一批。智能体在这里承担的不只是“转人工之前接住对话”，而是把整个会话历史、订单状态、退换货策略全部联动起来。预测报告里体现的趋势是：2026年客服类智能体的增量主要来自“主动外呼+意图识别+多轮业务办理”的组合，而不只是被动问答。换句话说，智能体要替人完成操作，而不只是陪人聊天。

营销内容与投放优化是另一个热点。这个方向受益于多模态能力成熟，文案生成、图片素材、投放数据分析可以串联成流水线。但我看过几个实际案例后发现，营销类Agent真正难的不是“生成”，而是“归因”——报告给出的是未来的流量预测，企业要知道这个线索到底是哪个内容带来的，如果没有闭环埋点和渠道追踪，Agent跑得再欢也只是帮市场部“做得更快”，而不是“做得更准”。

运营流程自动化是预测报告里金额最高的场景，包括订单异常处理、对账、报表生成、审批流摘要等。这个场景的特点是需要大量对接内部系统，RPA时代的经验和资产可以复用，但注意Agent和RPA有一个本质区别：RPA执行的是固定步骤，Agent是按目标选择步骤。这意味着流程设计要从“录制点击路径”改为“定义目标、约束、审批节点和兜底策略”。

研发提效类智能体是2026年新增量最明显的一块。代码补全只是开胃菜，头部企业开始把智能体塞进代码评审、缺陷修复、安全扫描、用例生成等环节。我做代码评审类智能体时体会很深：它能从“帮助你写代码”升级到“代替你Review代码”，关键在于有没有把企业自己的编码规范、历史缺陷库和架构约束喂进去。通用模型只知道“通用最佳实践”，不知道你们团队“哪些写法被禁止”。

1.3 AI转型负责人真正要做的判断

预测报告最后都会落到“AI转型”这个词上。我看下来，一份高质量预测报告给企业真正的启示不是“快上Agent”，而是三个判断：

第一个判断是场景选择和切入点。不要一上来做“公司级智能体平台”，要先挑一个业务部门痛、数据质量好、失败影响可控的场景做样板间。很多报告都会引用这类案例：先做营销文案助手，三个月内跑出成本节省和人力替代数据，再反向推动IT部门做基础设施。

第二个判断是组织配套。智能体部署之后，原本负责这部分流程的员工做什么？这是转型最大的隐形成本。我看到不少企业踩坑：Agent活儿干了，但人的编制没动，成本一点没省。靠谱的做法是转型初期就把“Agent处理常规、人处理异常”的分工写进SOP，让员工从执行者变成审核者和升级处理者，人力节省体现在“同样的业务量不再扩编”，而不是“立刻裁员”。

第三个判断是自建还是采购。这个决定不能只比单价。平台型产品胜在开箱即用，但定制能力、数据驻留、底层调度可控性都是变数；自建框架胜在可控，但所有的工程化问题——重试、队列、并发、可观测——都需要自己扛。后面我会单独用一节展开讲。

2. 基础设施：2026年智能体真正卡脖子的地方

2.1 为什么Agent和“聊天机器人”需要完全不同的基础设施

很多团队从“调用大模型接口做问答”切换到“做Agent”时，第一个不适应的点就是：Agent不是一次请求就能结束的。

一个典型Agent任务会拆成多轮：规划、调用工具、读取结果、再决策、再调用。这意味着同一个用户请求会产生多次模型调用、多次外部接口调用，而且调用链长短不可预知。如果还是照着传统Web服务的方式，每个请求同步处理、超时设为30秒，很容易把上游数据库连接池打爆，或者让用户在浏览器里干等两分钟没有任何反馈。

我的理解是，Agent基础设施要回答三个基本问题。一是状态放哪里：Agent的多步执行状态是放在内存里、数据库里还是专门的编排器里？二是任务怎么排队：当用户请求并发进来，每个请求又分支出一堆工具调用，用什么策略控制并发水位？三是失败了怎么处理：某一步工具调用超时，是重试、降级还是让Agent重新规划一条路径？

你去看2026年的预测报告，基础设施建设列为独立章节的概率很高，因为厂商已经从“卖模型”转向“卖Agent运行环境”。这背后有个很实在的经济学逻辑：模型调用单价逐年下降，但Agent因为调用链变长，单次任务的Token消耗可能是简单问答的5到20倍。如果基础设施不做缓存和上下文压缩，算下来成本涨幅惊人。

2.2 Agent怎么扛并发：问题不在模型，在调度

热词里有一条问得很实在：“AI Agent怎么扛并发”。这问题一问出来，说明已经跳过概念阶段，进入工程阶段了。

并发问题通常分三层。最外层是用户请求并发，比如1万个用户同时触发Agent；中间层是每个Agent任务内部的工具调用并发，比如Agent要同时查询库存、查物流、查客户等级；最内层是大模型接口并发，包括模型服务的限流、Token吞吐和超时。

绝大多数并发瓶颈不在模型本身，而在调度策略。模型服务商给你的是每分钟调用次数限制，你要做的不是让每个用户请求都直连模型，而是设计一个队列层。外部请求进来先落队列，Agent工作节点从队列里取任务，再控制每个任务发往模型的频率。这样可以把“突发流量”平滑成“可控流量”，避免触发限流引发的连锁重试。

我说个生活化类比：餐厅高峰期，客人一下涌进来，厨房只有一个灶台。如果每个客人都直接冲到厨房门口盯着厨师，那厨房乱成一锅粥，还容易烧糊菜。正确做法是门口取号，候餐区等待，厨房按顺序出菜，做完一盘叫一桌。队列就是那个取号机，Agent工作节点就是厨师，模型限流参数就是炉灶火力上限。

具体到系统架构，我建议在企业落地时至少包含这几层：

• 接入层：负责身份鉴权、用户请求入队、返回任务ID。
• 任务队列：用Redis Stream或者RabbitMQ都行，关键是支持延迟重试和死信队列。
• Agent运行时：从队列取任务，完成规划、工具调用、模型推理循环。
• 工具调用网关：统一封装外部API、数据库查询、内部RPC的调用，集中做超时控制和熔断。
• 可观测性：记录每一次规划的Token消耗、工具调用耗时、失败原因。

这套结构和传统Java后端“网关+MQ+Worker”几乎同构。所以你会看到，真正能把Agent扛住高并发的团队，往往不是最懂Prompt的，而是最有后端经验的那批人。

2.3 韧性、安全与“自主容错”：2026年企业绕不开的工程约束

报告里出现“自主容错控制”这类词时，多数人以为是学术概念。但它对应的是很现实的问题：Agent在无人看管的情况下跑生产流程时，遇到API波动、上游系统返回脏数据、模型偶尔犯傻，系统能不能自己收敛到安全状态。

我在多个项目里总结出的容错优先级是：先保证不崩，再保证不脏，最后才优化性能。所谓不崩，是任何非核心依赖挂了都不能拖垮主流程，工具调用必须有超时和兜底返回值；所谓不脏，是Agent写入业务系统的操作必须有幂等控制，重试不会产生重复订单、重复打款；所谓性能优化，则是把不必要的模型调用压缩掉。

安全审计同样在2026年上升为基础设施的一部分。一方面是因为Agent开始具备调用业务系统、发邮件、改数据库的权限，权限边界放得越大，风险面就越大；另一方面是监管场景对智能体行为审计提出了明确要求——出了问题要能回放，要知道Agent在什么状态下、基于什么上下文、调用了哪些工具、输出了什么内容。实际操作时，我至少会要求记录四类日志：用户输入原文、模型回复、工具入参出参、触发审批或降级的事件。有了这四类日志，审计时基本就能还原现场。

安全层面的另一个愈发被重视的参考是OWASP针对大模型应用发布的风险清单，2026年版本里大量内容直接指向Agent场景，包括提示注入、敏感信息泄露、工具权限过度授权、Agent记忆中的偏见数据、模型拒绝服务、供应链漏洞等。这不是给人读的“威胁模型PPT”，而是要落到Agent代码审查清单上的具体检查项。后面我会给出一份常用的排查表格。

3. 技术选型：平台搭建与代码开发，到底差在哪

3.1 平台派与代码派：一场关于控制力的取舍

热词里有两条问题几乎可以合并回答：“用平台构建的智能体”和“用Python构建的智能体”有什么不一样。平台类产品（国内像Coze、Dify，以及各类云厂商的Agent Studio）重新定义了智能体应用的安全与工程边界，恰恰是因为它们之间，语言是唯一的区分维度，而工程化的差距正隐藏在这条灵巧路径之后。

先给结论：不在乎源码控制、想快速验证业务价值，选平台；对调用链、数据、部署环境有强约束，或者要做深度定制，选代码自建。

平台的核心优势是做了一层非常好的“发言人抽象”：你不用关心LangGraph的图怎么画、LangChain的工具调用怎么接、向量数据库的索引怎么建，通过拖拽连线就能把Agent流跑起来，还自带可视化调试和日志界面。这对市场、运营、客服这类业务团队特别友好，他们不需要等IT排期，自己就能迭代。

但平台的问题也随之而来：第一，复杂的编排逻辑用可视化节点表达会非常笨重；第二，平台内置的插件和工具库未必能覆盖企业内部系统；第三，最要命的是，一旦任务规模上去，你想看底层调度细节、想调并发参数、想自定义重试策略时，平台不一定给你开放这些旋钮。

用Python自建（比如FastAPI+LangGraph / LangChain组合），本质上是你把Agent的每一层都接管了。你可以控制模型调用的频率、缓存策略、工具调用的超时、任务队列的消费并发；你可以把Agent嵌入到现有的微服务架构里，共享统一监控和链路追踪；你还可以写单元测试覆盖Agent的每条分支路径。代价是你需要有人长期维护这套东西，而且初期开发速度一定比平台慢。

我建议的混合路线是：业务探索期用平台快速搭原型，跑通业务指标后，再评估是否需要迁到代码自建。有些团队会继续停在平台，因为业务场景简单；有些场景涉及大量私有化部署和安全合规，那就必须迁出来。这里的决策依据不是技术，而是业务对系统实时性、可审计性、可定制性的要求层级。

3.2 为什么很多人盯上基于Rust的Agent基础设施

“基于Rust语言AI Agent”这个热度一直不低。我得先泼盆冷水：纯业务逻辑用Rust写Agent，开发效率提升并不明显，但如果你关注的是运行时基础组件，Rust的价值就非常实在。

Agent基础设施里有很多底层组件：任务队列、向量索引、嵌入模型推理服务、网关、权限策略引擎。这些组件的特点是并发要求高、内存占用敏感、需要在低资源环境里跑得稳。Rust在这类场景的优势是：无GC暂停、内存安全性由编译器保证、单条Worker的吞吐可以做到很高。所以你会看到有些厂商已经用Rust重写了Agent网关和向量检索组件，对外暴露的还是标准REST/GRPC接口。

对大部分企业开发团队来说，我不建议从零用Rust写Agent编排器，除非你们团队确实拥有较强的Rust人才储备。更务实的做法是：用Python做Agent业务逻辑，用Rust做性能敏感的基础组件，中间通过API或消息队列通信。这样你既拿到了Rust在并发和资源控制上的红利，又保住了Python生态里Agent框架的迭代速度。

3.3 可观测性：智能体运维最大的缺口

如果预测报告只提“Agent可以自动完成流程”，那它一定漏掉了一个隐性工程命题：怎么观察Agent在干什么。

普通接口可以靠监控响应时间、错误率、吞吐量来界定健康度，Agent不行。Agent是多轮决策系统，用户感知到的“这一单为什么处理慢了”可能是某次工具调用超时，可能是模型生成了错误格式，也可能是编排器陷入死循环。你需要在链路里打点，把每一次LLM调用的输入输出、每一步工具入参出参、每轮规划的决策原因都记录下来。

我目前见过比较成型的方案是OpenTelemetry的GenAI语义约定，把模型调用、向量检索、Agent步骤统一规范成可以追踪和关联的Span数据，配合Grafana/LangSmith这类工具做可视化。这套方案的好处是，你可以在一个界面里看到：某个用户请求→触发了哪些子任务→每个子任务调用了哪些工具→每个工具的返回是什么→最后哪一步出错了。

关于可观测性，我给出三个必须看的指标：Token成本需要按模块聚合，看看哪个环节吃掉了最多的模型预算；工具调用的成功率和P95延迟，这才是Agent整体延迟的主要来源，而不是模型本身；关键失败事件，比如重试超过阈值、死信队列堆积、权限拒绝，这些应该直接告警。把这三类指标接好，你的Agent才算真正进入了“可运维”状态。

4. 代码智能体：从“能聊天”到“能修代码”的工程化之路

4.1 召回率是什么，为什么代码评审Agent必须看它

近期热度里有一个“代码检视修复智能体，召回率91.3%”的实战评测，这个数字背后其实扣住了代码智能体最核心的评价维度。

代码Review类的智能体本质上是个“检索+判断”系统：从代码仓库里找出可能存在的缺陷，再判断是否误报。它的核心指标是召回率和精确率。召回率衡量的是“已知缺陷里，你找出来了多少”，精确率衡量的是“你报告出来的缺陷里，多少是真的”。做代码质量保障，召回率权重通常更高，因为漏掉的缺陷会流到生产环境，而误报最多浪费一次人工review的时间。

91.3%这个数字放在真实业务里是什么水平？如果你的团队历史缺陷库里有1万个已知坏味道，智能体能找出9130个，剩下的870个会漏到下一层。再配合人工抽查，整体质量就开始接近可用线。关键是你不能只看这个数字，还要看评测采样里是否包含你们团队特有的框架和业务代码，不同语言、不同业务场景下，同一模型的表现差异巨大。

我在集成代码智能体时，最重要的经验是把企业编码规范、历史缺陷样本和历史修复提交记录喂进去，而不是直接用通用模型开箱即用。让模型知道“你们项目里禁止在循环里查数据库”“禁止在事务里做远程HTTP调用”，它的检查精度会明显提升。这是任何评测排行给不了你的定制价值。

4.2 代码智能体的实战配方

一套可落地的代码评审智能体通常包含四个模块：代码上下文采集、静态规则引擎、LLM深度分析和结果回写。

代码上下文采集是基础。传统静态检查工具只分析单个文件，LLM要想理解“这个函数会不会被并发调用”，需要读取调用链、相关类定义、甚至数据库设计文档。这块做得越充分，Agent的判断越准。

静态规则引擎负责快速初筛，用ESLint、SonarQube等工具把低垂果子先摘掉。这步的好处是便宜、稳定、不会误报高。LLM深度分析只处理规则引擎无法判断的复杂问题，比如“这段订单状态逻辑在异常路径下会不会造成重复支付”，需要的是一次“带着上下文的推理”，而不是全文扫描。

结果回写是很多人忽略的一环。Agent光提问题价值有限，最好直接生成修复补丁或者带行号的问题报告，自动提交到CI里，和现有代码评审流程集成。我见过最顺滑的落地形态是：研发提MR，Agent扫描MR，标记高危缺陷并生成修订建议，如果发现P0级问题则直接阻塞合入。这样既保留了人的决策权，又把重复劳动降到最低。

4.3 自建代码智能体的最小路径

如果你要在团队里从零起一个代码Review智能体，我建议按下面这个顺序做，不需要一上来就铺很大：

1. 先确定分析对象：选一类最常见的缺陷，比如“空指针风险”或“资源未关闭”，不要一开始就“全缺陷覆盖”。
2. 搭一个脚本：读取MR变更文件列表，过滤掉非代码文件，拼出变更上下文。
3. 写一个修复方向对齐的Prompt：把你团队对这个缺陷的历史Review意见放进去，作为Few-shot示例。
4. 接入LLM接口：输出结构化为JSON，包含问题等级、文件行号、原因、修复建议。
5. 加一层校验：用正则或树解析技术校验输出，防止模型胡编文件行号。
6. 接CI：在Pipeline里加一步，失败或高优先级问题时报给开发者。
7. 累积正反馈：把每次人工确认为真的缺陷加入知识库，定期迭代Prompt和示例。

这套路径看着简单，但每一步都有坑。比如你在第2步读取Git变更时，要注意只分析真正的代码改动，不要分析生成文件和后端vendor目录，否则噪声会淹没信号。第5步尤其重要，模型给的行号经常偏一位，如果不校验就直接通知人，很快大家就不信这套系统了。

5. 常见问题与排查技巧实录

5.1 Agent调用链超时与熔断排查

现象：Agent的任务“卡住”或“转圈”，用户端等不到结果。

排查思路：先看可观测性面板，定位最后一步完成的Span在哪。如果卡在工具调用，看是外部API超时还是内部库查询慢；如果卡在模型调用，看是不是触发了限流，返回了429。

常见的坑是重试策略设置不当。很多团队给工具调用设置了重试3次，但没加抖动，结果上游服务挂了以后，所有并发任务在同一秒内一起重试，直接把上游打得更死。重试一定要用指数退避加随机抖动，而且要在队列层做全局限速，否则并发情况下重试就是雪崩的加速器。

5.2 智能体行为审计到底查什么

“智能体行为审计”这个词听起来偏合规，实际做起来是工程事。你要能回答：这个Agent在某个时间点为什么做了某个操作，依据是什么，权限来源是谁。

我建议审计日志最低限度包括：会话ID、用户ID、触发时间、完整输入、完整输出、工具调用记录含参数、人工审批记录、降级/跳过事件。如果涉及修改类操作，比如发邮件、订单改价，还要记录本次操作对应的权限校验结果。没有这些，出事时你只能道歉，无法定位。

5.3 Token预算怎么定

热词里的“AI Agent token是什么意思”是新人常见困惑。Token是模型计费和上下文单位，但它不能直接等同于“字数”。

Agent项目的Token成本大头通常不是用户输入，而是系统提示、工具返回结果和中间多轮推理。有一次我看到某客户的Agent成本远超预期，追查后发现是因为工具调用返回了一个超大的JSON，然后这个JSON每次对话都塞进上下文重新发给模型。解法是字段裁剪、加摘要、或用向量检索只取相关片段。

做成本预估时，我建议先跑一个最小场景，统计“完成一个典型任务平均消耗多少Token”，再乘以目标日活和并发系数。别拿简单问答的Token单价直接估算Agent成本，否则预算一定翻车。

5.4 “让AI真的下地干活”：从Demo到生产差在哪

热词里有“让AI真的下地干活”这句话，正好点出从Demo到生产之间的巨大缝隙。Demo里只要把单条链路跑通，生产还要考虑多租户隔离、失败重试、数据权限、审计合规、模型版本回滚、灰度发布。

我的生产化清单包括：所有外部依赖都要走超时+熔断；所有写操作都要有幂等键；所有模型调用都要有降级方案；所有Prompt和工具定义都要进版本管理；所有配置变更都要能回滚。这五条齐了，你的Agent才配叫“企业级应用”。

5.5 个人开发者可以用Agent做量化交易吗

这个问题在技术上可以，但我建议极度谨慎。Agent天然存在不确定性，它会基于不完整信息做决策；用来做辅助分析可以，直接让它自动下单，等于把真金白银交给一个可能会因幻觉而误判的系统。如果只是学习和研究，可以拿历史数据回测；如果是实盘，先想清楚风控和熔断，这不是Prompt能解决的问题。金融合规也是一道不能忽视的线，个人开发者在没有资质的情况下触碰自动交易，风险不只在技术层面。

5.6 面试中被问“怎么设计Agent系统”怎么答

“智能体面试”后面跟了一堆搜索词，说明大家确实在准备这类岗位。如果你的面试考的是Agent系统设计，别只讲Prompt，要讲工程。典型的回答框架是：场景界定和数据流、任务编排与状态管理、工具调用与权限模型、并发与限流策略、可观测性与回滚方案、成本评估与安全审计。这套框架覆盖了从产品到工程的完整链路，比背几个概念强得多。

6. 关于150份报告和数据合集的整理思路与使用建议

6.1 我整理的这套材料的结构

这份“2026中国AI Agent企业应用市场预测报告”周边合集包括150份报告和数据包，我按照四类做了索引：

• 市场规模与趋势预测：包含各家机构对2026年企业智能体市场规模、细分场景渗透率、预算归属的统计和预测。
• 技术与产品选型参考：包含国内外主流智能体框架、平台、基础设施组件的性能对比和案例实测。
• 行业落地案例：覆盖金融、零售、制造、医疗、教育、政务等领域的具体Agent应用项目拆解。
• 工程实践方法论：包含可观测性、安全审计、并发设计、模型选型、Prompt工程等主题的深度技术报告。

6.2 看报告时最常见的两个误区

第一是只看图表不看假设。每份预测报告都会对自己的模型做假设，比如“假设大模型调用价格每年下降50%”“假设企业IT预算增长15%”。这些假设一变，结论全变。阅读时先把假设条件圈出来，再看结论，这样面对不同报告的“矛盾结论”时你至少知道为什么矛盾。

第二是被“官方数字”带跑。数据合集里有不少原始统计表，但对同一指标（比如“智能体在企业中的渗透率”），不同机构的统计口径差异很大——有人按“购买了AI工具的企业”算，有人按“实际跑通生产流量的企业”算。使用时先统一口径，别把两组口径不同的数字拼到一个结论里。

我的习惯是先按行业筛选出对标的3到5份核心报告精读，其他报告作交叉验证；再按“场景→预算→选型→风险”的四步流程，把核心信息抽取到自己的表格里，这比把150份全部读完再写笔记高效得多，至少能节省3倍时间。

6.3 怎么从“看完报告”到“做出决策”

报告的价值不在于让你知道“2026年市场会很大”，而在于帮你在“要不要做、做什么、怎么做”之间连出一条链路。我的使用顺序是：

先拿市场规模和渗透率数据向上级证明“赛道是真实的”；再拿行业案例找出“和自己业务形态最像的1个参考样本”；接着拿技术选型报告定方案边界；最后拿工程实践报告里的成本数据和技术难点做风险预案。

这四步走完，一份预测报告才真正从“行业观察”变成了“项目立项依据”。这也是我把整套报告合集整理成可搜索、可跳转的索引文件的原因——不是让你从头到尾读，而是让你在决策链条的每一环都能快速调到对应材料。

最后分享一个我的个人体会：2026年企业级Agent真正稀缺的不是模型能力，而是把模型放进业务流程里还能稳定运行、成本可控、出问题可追溯的工程能力。预测报告里所有的乐观数字，都建立在基础设施从“能跑”进化到“能扛、能审、能运维”这个前提上。你可以从任何一个小场景切入，但务必用生产系统的高标准去要求它。先跑通一个，跑稳了再复制，比一次性铺开几十个Agent然后全部失控要划算得多。