企业官网建设流程全解析

1. 项目概述：当企业级集成平台遇上大语言模型

“AI Orchestration in Action: How MuleSoft and LLMs Fuel the Future of Enterprise AI”——这个标题不是一句空泛的行业口号，而是我在过去18个月里亲手落地的三个生产级AI增强型集成项目的统一内核。它讲的不是“用LLM写个周报”，而是如何把大语言模型真正嵌进银行核心账务系统的审批流里、塞进制造业ERP的工单闭环中、焊进医疗设备IoT平台的告警响应链路里。MuleSoft在这里不是配角，它是那个在LLM狂奔时踩刹车、在数据洪流中搭桥、在安全红线前立界碑的“AI交响乐指挥家”。我见过太多团队把LLM当成万能插件往现有系统里硬塞，结果API调用雪崩、上下文错乱、审计日志一片空白，最后项目卡在法务合规那关动弹不得。而MuleSoft的Anypoint Platform提供的不只是API网关，它是一整套企业级AI编排的基础设施：统一的策略引擎管住Prompt调用频次与敏感词过滤，可追溯的数据血缘图谱让每个LLM生成结果都能回溯到原始订单号和操作人，基于角色的细粒度权限控制确保销售助理只能调用客户摘要模型，而风控总监才能触发反欺诈推理链。这背后是企业对AI落地最根本的诉求：可控、可审、可集成、可扩展。如果你正被“LLM效果好但不敢上生产”、“模型跑得欢但业务流程接不上”、“POC很惊艳但上线就崩盘”这些问题反复折磨，这篇内容就是为你写的实战手记——没有PPT式概念堆砌，只有我在真实产线里调过的每一个参数、填过的每一个配置项、踩过的每一个深坑。

2. 核心架构设计：为什么必须用MuleSoft做AI编排，而不是直接调用LLM API

2.1 企业AI落地的四大死穴与MuleSoft的破局逻辑

很多技术负责人第一反应是：“我们自己写个Spring Boot服务调OpenAI API不就行了？”——这个想法在Demo阶段确实快，但一旦进入企业级场景，立刻会撞上四堵高墙：

第一堵是协议与格式墙。你的CRM系统用SOAP协议传客户数据，而LLM API只认JSON；你的遗留主机会发EBCDIC编码的二进制报文，而大模型输入必须是UTF-8文本。如果每对接一个系统都重写一次协议转换层，三个月后你会拥有十几个脆弱的胶水代码模块。MuleSoft的DataWeave引擎原生支持超过200种数据格式的实时转换，我曾用一行DataWeave表达式把AS400主机发来的EDIFACT报文里的UNB+UNOA:3+SENDER++RECEIVER+230501:1200+000000001'解析成结构化JSON，并自动提取出交易时间戳注入LLM的system prompt里。这种能力不是“能用”，而是“必须用”——它把协议适配从开发任务降维成配置任务。

第二堵是安全与合规墙。某金融客户要求所有LLM调用必须满足三项铁律：1）客户身份证号、银行卡号等PII字段在进入LLM前必须脱敏；2）每次调用必须记录完整审计日志，包含调用者AD账号、原始请求payload哈希值、LLM返回结果哈希值；3）禁止任何模型返回包含“投资建议”字样的内容。如果靠应用层代码硬编码这些规则，等于把安全策略写死在业务逻辑里，每次合规审计都要全量代码扫描。而MuleSoft的Policy Manager允许你把这三条规则封装成可复用的“AI-Safe Policy”，一键绑定到所有LLM调用API上。当法务部下周突然要求增加“禁止输出收益率预测”的新条款时，我只需要在Policy编辑器里加一行正则表达式.*收益率.*预测.*，点击发布，全平台生效——整个过程耗时92秒，不需要重启任何服务。

第三堵是可观测性墙。LLM调用失败时，你是想看到“Connection refused”这种无意义报错，还是想立刻定位到：是OpenAI的us-east-1区域API网关超时？是本地网络策略阻断了HTTPS 443端口？还是上游ERP系统返回的客户地址字段为空导致Prompt模板渲染失败？MuleSoft的Anypoint Monitoring提供开箱即用的分布式追踪，它能把一次跨三个系统的调用（CRM → MuleSoft → OpenAI → SAP）串成一条完整Trace。我在某次故障排查中发现，97%的LLM超时其实源于SAP系统响应慢——因为MuleSoft在等待客户主数据返回时，把LLM调用的timeout错误地设成了全局60秒，而实际应该按业务场景分级：客户摘要生成允许15秒，合同风险分析必须≤5秒。这个洞察，只有在统一观测平台上才能获得。

第四堵是弹性伸缩墙。LLM API的调用成本是按token计费的，而企业业务流量有明显波峰波谷。某电商客户在大促期间LLM调用量暴涨20倍，如果直接把流量打到OpenAI，账单会失控。MuleSoft的Rate Limiting策略支持动态配额：工作日9:00-18:00给客服机器人分配5000 QPS，凌晨自动降为500 QPS；同时设置burst capacity，允许突发流量在5秒内消耗最多2000个令牌。更关键的是，它能把超出配额的请求自动路由到降级方案——比如当OpenAI调用失败时，无缝切换到本地微调的Llama3-8B模型（部署在客户私有云GPU集群上），虽然生成质量略低，但保证了服务可用性。这种“智能熔断+多模型路由”的能力，是裸调API永远无法实现的。

2.2 架构分层详解：从LLM调用到业务价值交付的七层穿透

真正的AI编排不是简单串联，而是构建七层穿透式架构，每一层解决一个特定维度的问题：

第1层：接入层（Ingress Layer）
这是企业系统的“门禁系统”。我们不用让每个业务系统都学习LLM API规范，而是统一通过MuleSoft暴露标准REST API。例如，为销售团队提供POST /sales/lead-summary接口，内部自动完成：1）从Salesforce拉取线索详情；2）调用DataWeave清洗掉营销话术冗余字段；3）拼装符合公司合规要求的system prompt。这一层的关键参数是api-version路径变量，我们强制所有客户端必须声明版本号，便于后续灰度发布新Prompt模板。

第2层：协议适配层（Protocol Translation Layer）
这里处理所有“方言翻译”。某制造客户的老式MES系统用JMS协议发送工单事件，而我们的LLM服务只接受HTTP。MuleSoft的JMS Connector自动监听队列，收到{ "workOrder": "WO-2023-001", "status": "pending" }后，用DataWeave将其转为{ "input": "请分析工单WO-2023-001的当前状态pending可能存在的风险点，用中文 bullet point 列出" }。重点在于，我们把JMS连接参数（host/port/queue name）全部外置到Anypoint Properties中，运维人员无需改代码就能切换测试/生产环境。

第3层：上下文编织层（Context Weaving Layer）
这是AI编排的灵魂所在。LLM不是孤立工作的，它的输出质量取决于输入上下文的丰富度。我们设计了一个Context Builder模块，它并行调用多个系统组装上下文：1）从CMDB获取该服务器的硬件配置；2）从监控系统拉取过去2小时CPU负载曲线；3）从知识库检索同类故障的TOP3解决方案。最终生成的prompt不是简单的“分析问题”，而是：

你是一名资深运维工程师，请基于以下上下文诊断问题： [CMDB] 服务器型号：Dell R750, CPU：Intel Xeon Gold 6330, 内存：256GB [Monitoring] 过去2小时CPU使用率：[92%, 88%, 95%, 91%, 89%] [KB] 类似高CPU案例：1) Java应用内存泄漏 2) 磁盘IO瓶颈 3) 定时任务堆积 请用中文分三点说明最可能原因，并给出验证命令。

这个过程在MuleSoft中用Parallel For Each实现，每个子流程超时设为3秒，任一环节失败不影响整体执行——这是保障SLA的关键设计。

第4层：模型路由层（Model Routing Layer）
我们绝不把所有鸡蛋放在一个篮子里。这一层根据业务场景、成本预算、延迟要求动态选择模型：

• 客户服务摘要：优先调用Azure OpenAI的gpt-4-turbo（平衡质量与成本）
• 合同关键条款提取：强制使用本地部署的Phi-3-mini（满足数据不出域要求）
• 实时聊天机器人：fallback到量化后的Llama3-8B（<200ms P95延迟）
  路由策略用MuleSoft的Choice Router实现，判断条件包括#[attributes.queryParams.priority == 'high']或#[vars.contextSize > 5000]。特别要注意的是，我们为每个模型通道配置独立的Circuit Breaker，当gpt-4-turbo连续5次超时，自动熔断10分钟并切到备用通道。

第5层：安全加固层（Security Hardening Layer）
所有LLM输入输出在此层接受三重过滤：
1）输入净化：用Java正则预处理，移除可能引发越狱的特殊字符序列（如<|endoftext|>）
2）输出审查：调用本地部署的Guardrails模型（基于DistilBERT微调），实时检测是否包含政治敏感词、医疗建议、未授权数据引用
3）审计留痕：将原始请求、模型ID、响应哈希、调用者信息写入Splunk，索引字段包含ai_model_type=gpt4、ai_pii_masked=true
这个层的关键配置是security.policy.timeout=800ms，必须严格小于LLM调用总超时，否则会拖垮整个链路。

第6层：结果精炼层（Output Refinement Layer）
LLM的原始输出往往需要二次加工才能喂给下游系统。例如，LLM返回的JSON可能是：

{ "risk_points": ["CPU使用率过高", "磁盘空间不足", "网络延迟大"] }

但SAP系统要求的格式是：

<RISK_LIST> <RISK><CODE>CPU_HIGH</CODE><DESC>CPU使用率持续高于90%</DESC></RISK> <RISK><CODE>DISK_FULL</CODE><DESC>/var/log分区使用率98%</DESC></RISK> </RISK_LIST>

我们用DataWeave的map函数和预定义code mapping表（存在Anypoint Properties中）完成转换。这里有个血泪教训：早期我们把mapping表硬编码在DataWeave脚本里，结果某次安全审计要求将DISK_FULL重命名为STORAGE_CRITICAL，不得不修改17个Flow——后来全部改为外部Properties，修改后5分钟全量生效。

第7层：反馈闭环层（Feedback Loop Layer）
真正的智能在于进化。我们在每个LLM调用后插入Feedback Collector：

• 当用户点击“此回答有帮助”时，将原始prompt+response+用户ID写入Kafka Topicai-feedback-positive
• 当用户提交纠错（如“应为2023年合同，不是2024年”），写入Topicai-feedback-correction
  这些数据被Flink作业实时消费，每周自动生成Prompt优化报告。某次我们发现，对“合同金额”字段的提取准确率仅63%，深入分析发现是LLM混淆了“总额”和“税额”。于是我们在Context Weaving层增加一条规则：“当文档类型=采购合同，强制在prompt中强调‘请严格区分合同总额与含税金额’”，一周后准确率提升至91%。

3. 核心实操环节：从零搭建一个可审计的AI编排Flow

3.1 环境准备与基础配置：避开企业环境的三大陷阱

在Anypoint Studio中新建Mule 4.4.0项目时，第一个致命陷阱是JDK版本错配。MuleSoft官方明确要求使用JDK 11（非17或21），但很多开发者习惯性用最新版。我亲眼见过团队因JDK 17导致DataWeave的write()函数在处理大XML时内存溢出——错误日志里只显示OutOfMemoryError，根本看不出根源。正确做法是在Studio的Preferences→Installed JREs中添加JDK 11，并在项目Properties→Java Build Path→Libraries中确认JRE System Library指向11。更稳妥的是在pom.xml中强制锁定：

<properties> <mule.version>4.4.0</mule.version> <jdk.version>11</jdk.version> </properties>

第二个陷阱是Anypoint Properties的加载顺序。企业环境通常有dev/test/prod三级配置，但很多人把所有配置写在一个properties文件里，用if判断环境。这会导致安全风险——测试环境的API Key可能意外泄露到生产配置中。我们必须采用MuleSoft推荐的分层覆盖机制：
1）在src/main/resources下创建application-dev.properties、application-test.properties、application-prod.properties
2）在Anypoint Runtime Manager中，为每个环境单独上传对应properties文件
3）在Flow中通过#[p('ai.openai.api.key')]引用，MuleSoft会自动按环境加载对应文件
关键细节：application-prod.properties绝不能包含任何明文密钥，而是用#[secure::vault('openai-key')]从HashiCorp Vault读取——这是金融客户过等保的硬性要求。

第三个陷阱是HTTP Request组件的连接池配置。默认的maxConnections="10"在高并发下必然成为瓶颈。我们根据压测结果重新计算：假设单次LLM调用平均耗时1.2秒，目标QPS为200，则最小连接数=200×1.2=240。但在MuleSoft中，连接池大小需考虑失败重试，最终配置为：

<http:request-config name="OpenAI-Config" host="api.openai.com" port="443" connectionIdleTimeout="30000" maxConnections="300" responseTimeout="15000"> <http:authentication> <http:basic-authentication username="Bearer" password="#[p('ai.openai.api.key')]"/> </http:authentication> </http:request-config>

注意responseTimeout设为15秒而非默认的10秒——这是留给LLM生成长文本的缓冲时间，但必须配合上层Circuit Breaker的failureThreshold="5"，避免雪崩。

3.2 构建可审计的LLM调用Flow：七步精准实现

现在我们动手搭建一个真实的、可审计的客户投诉分析Flow。目标：接收来自ServiceNow的JSON投诉工单，调用LLM生成根因分析与处理建议，结果写入Salesforce并记录完整审计日志。

Step 1：定义入口API契约
在APIkit Router中创建/complaint/analyze端点，使用RAML 1.0定义：

/complaint/analyze: post: body: application/json: type: | { "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "properties": { "caseId": {"type": "string"}, "customerName": {"type": "string"}, "complaintText": {"type": "string", "maxLength": 5000}, "priority": {"type": "string", "enum": ["low","medium","high"]} }, "required": ["caseId","complaintText"] }

关键点：maxLength: 5000是硬性限制，防止恶意构造超长文本导致LLM OOM。我们在APIkit中启用validateRequest=true，非法请求直接返回400，不进入后续流程。

Step 2：提取并标准化上下文
用Transform Message组件调用DataWeave：

%dw 2.0 output application/json --- { caseId: payload.caseId, customerName: payload.customerName, complaintSummary: substring(payload.complaintText, 0, 2000), // 截断防超长 priorityLevel: payload.priority, timestamp: now() as String {format: "yyyy-MM-dd'T'HH:mm:ss.SSSXXX"}, systemContext: { sourceSystem: "ServiceNow", integrationVersion: "v2.1" } }

这里substring是防御性编程——即使前端没校验，后端也要截断。integrationVersion字段至关重要，它让后续所有审计日志都能关联到本次集成升级的版本号。

Step 3：并行组装多源上下文
用Parallel For Each启动三个子流程：

• Sub-Flow A（CRM Context）: 调用Salesforce REST API获取客户历史投诉次数、VIP等级
• Sub-Flow B（Product Context）: 查询产品数据库，获取该客户购买的产品型号、保修状态
• Sub-Flow C（KB Context）: 调用Elasticsearch，搜索近30天类似投诉的TOP5解决方案
  每个子流程设置maxConcurrency="3"和timeout="5000"。特别注意：我们为每个子流程配置独立的Error Handler，当Salesforce超时时，只记录警告日志，不中断主流程——因为CRM数据缺失不应影响LLM分析。

Step 4：构建带安全约束的Prompt
用Transform Message组装最终prompt：

%dw 2.0 output text/plain --- "你是一名资深客户服务专家，请基于以下上下文分析投诉根因并提供处理建议：" ++ "\n---客户信息---\n" ++ "姓名：" ++ vars.context.customerName ++ "，VIP等级：" ++ vars.context.crm.vipLevel ++ "，历史投诉次数：" ++ vars.context.crm.totalComplaints ++ "\n---产品信息---\n" ++ "型号：" ++ vars.context.product.model ++ "，保修状态：" ++ vars.context.product.warrantyStatus ++ "\n---类似案例---\n" ++ (vars.context.kb.hits map ((item, index) -> "- " ++ item.title)) joinBy "\n" ++ "\n---当前投诉---\n" ++ vars.context.complaintSummary ++ "\n\n请严格按以下JSON格式输出，不要任何额外文字：{ \"rootCause\": \"\", \"suggestedActions\": [\"\", \"\"] }"

这个prompt设计经过三次迭代：最初版本让LLM自由发挥，结果返回了HTML表格；第二次强制JSON格式，但LLM仍会加解释性文字；最终版本用“不要任何额外文字”+具体JSON schema，准确率达99.2%。

Step 5：调用OpenAI并实施熔断
配置HTTP Request调用https://api.openai.com/v1/chat/completions：

{ "model": "gpt-4-turbo", "messages": [ {"role": "system", "content": "你是一名资深客户服务专家..."}, {"role": "user", "content": "..."} ], "temperature": 0.3, "max_tokens": 1000 }

在HTTP Request外层包裹Circuit Breaker：

• failureThreshold="3"（连续3次失败触发熔断）
• resetTimeout="60000"（60秒后自动重试）
• halfOpenThreshold="5"（半开状态下允许5次试探调用）
  熔断开启时，自动跳转到Fallback Flow，调用本地Llama3模型——其prompt模板完全一致，只是模型不同。

Step 6：结构化解析与数据清洗
LLM返回的JSON可能包含非法字符，我们用JSON Schema Validator先校验：

{ "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "properties": { "rootCause": {"type": "string", "maxLength": 500}, "suggestedActions": { "type": "array", "items": {"type": "string", "maxLength": 200}, "maxItems": 3 } }, "required": ["rootCause", "suggestedActions"] }

校验失败则触发Error Handler，记录LLM_OUTPUT_INVALID_JSON错误码，并将原始响应存入Dead Letter Queue供人工复核。

Step 7：双写与审计日志
最终用Scatter-Gather并行执行：

• Branch 1: 将分析结果写入Salesforce Case对象的AI_Analysis__c字段
• Branch 2: 将完整审计日志写入MongoDB，包含：

  { "traceId": attributes.correlationId, "caseId": payload.caseId, "modelUsed": "gpt-4-turbo", "inputTokens": 1240, "outputTokens": 320, "responseTimeMs": 1420, "promptHash": "sha256:abc123...", "responseHash": "sha256:def456...", "invokedBy": attributes.headers."X-User-ID" }

  关键点：promptHash和responseHash必须在调用LLM前后即时计算，确保不可篡改。我们用MuleSoft的hashWith("SHA-256", ...)函数实现，比在应用层计算更可靠。

3.3 生产环境关键参数调优：来自12个客户的实测数据

参数调优不是玄学，而是基于真实流量的精密计算。以下是我们在不同行业客户中沉淀的黄金参数表：

特别提醒一个反直觉发现：增大maxConnections不一定提升吞吐量。在某银行POC中，我们将连接数从100提到500，QPS反而下降12%。经Wireshark抓包发现，过多空闲连接占用了操作系统TIME_WAIT端口资源。最终采用动态连接池：

<http:request-config name="OpenAI-Config"> <http:connection-pooling-profile maxConnections="200" exhaustedAction="WAIT" waitTimeout="5000"/> </http:request-config>

exhaustedAction="WAIT"让请求排队而非新建连接，配合waitTimeout="5000"避免无限等待，实测QPS稳定在210±5。

4. 常见问题与实战排障：那些文档里不会写的血泪教训

4.1 典型故障速查表：从现象到根因的秒级定位

4.2 那些只有踩过才懂的避坑指南

坑1：不要相信LLM的“自我报告”
某次我们让LLM在响应末尾加一行token_usage: {"input":1240,"output":320}，结果发现37%的响应里这个字段数值是错的。正确做法是：在HTTP Request组件的response属性中直接提取OpenAI返回头x-ratelimit-remaining-tokens，再用#[attributes.headers.'openai-organization']关联租户。我们专门写了Utility Flow，用正则从OpenAI的usage字段中提取精确值：

%dw 2.0 output application/json --- { inputTokens: (attributes.body.usage?.prompt_tokens default 0) as Number, outputTokens: (attributes.body.usage?.completion_tokens default 0) as Number, totalTokens: (attributes.body.usage?.total_tokens default 0) as Number }

这个Flow被所有LLM调用Flow复用，确保计费数据100%准确。

坑2：Prompt模板的版本管理比代码还重要
我们曾因测试环境更新了Prompt模板，但忘记同步到生产，导致客服机器人开始用新话术回复老客户，引发客诉。现在强制执行：

• 每个Prompt模板存为独立.dwl文件，命名含版本号prompt-customer-summary-v3.2.dwl
• 在主Flow中用readUrl("classpath://prompt-customer-summary-v3.2.dwl")加载
• 所有模板变更必须走Git PR流程，附带A/B测试报告（对比v3.1与v3.2在1000条样本上的准确率）
• Anypoint Runtime Manager中配置prompt.version=v3.2，通过Properties控制加载哪个版本

坑3：审计日志的存储成本远超预期
初期我们把每次LLM调用的完整prompt+response都存MongoDB，一个月后日志库暴涨到4TB。优化方案：

• 冷热分离：热数据（7天内）存MongoDB，冷数据自动归档到AWS S3，按year/month/day分区
• 字段精简：删除prompt全文，只存promptHash；response只存rootCause和suggestedActions两个字段
• 压缩存储：在写入前用gzip压缩JSON，MongoDB存储时启用zlib压缩算法
  最终日志存储成本降低76%，且不影响审计查询——因为promptHash可100%还原原始内容。

坑4：本地模型的“降级幻觉”
当Fallback到Llama3时，我们发现它有时会编造不存在的解决方案。例如，针对“打印机卡纸”，它返回“请检查硒鼓盖板下的传感器”，而该型号打印机根本没有这个部件。根因是本地模型训练数据不足。解决方案是：

• 在Fallback Flow中增加事实核查层：调用知识库API，验证LLM返回的每个技术术语是否存在
• 配置verification.threshold=0.8，当匹配度低于80%时，自动追加提示：“请仅基于您知识库中存在的部件名称作答”
• 对高频错误场景（如打印机型号），预置规则库：if model == "llama3" and product == "HP-LaserJet-MFP-M436" then useRule("sensor-check")

坑5：跨时区场景下的时间戳灾难
某全球客户要求所有审计日志用UTC时间，但他们的ServiceNow实例在东京时区。我们最初用now()函数，结果日志时间混乱。正确解法：

• 在入口Flow中统一提取#[attributes.headers.'X-Request-Time']（由API网关注入的ISO8601时间）
• 若无此头，则用#[now() as String {format: "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" }]强制UTC
• 所有后续时间计算基于此基准时间，避免多次调用now()产生毫秒级偏差
  这个细节让客户顺利通过ISO 27001认证——审计员特别抽查了100条日志，时间戳误差全部在±10ms内。

5. 从编排到智能体：企业AI演进的下一阶段实践

当我们把MuleSoft驱动的AI编排跑稳后，自然会思考：下一步是什么？答案不是更复杂的Prompt工程，而是构建可自主决策的AI智能体（Agent）。我们已在两个客户中落地初步实践，核心是把MuleSoft从“管道”升级为“大脑”。

智能体架构的三层跃迁：
第一层是工具调用层（Tool Calling）。传统编排是固定流程：A→B→C。而智能体需要动态决定调用哪些工具。我们在MuleSoft中构建了Tool Registry，每个工具（如“查询客户余额”、“创建服务工单”、“发送邮件”）注册为独立Flow，并标注toolSpec：

{ "name": "getCustomerBalance", "description": "获取指定客户的当前账户余额", "parameters": { "customerId": {"type": "string", "required": true} } }

LLM的system prompt中嵌入所有toolSpec，当它生成{"name": "getCustomerBalance", "parameters": {"customerId": "CUST-123"}}时，MuleSoft的Tool Dispatcher自动路由到对应Flow。这比硬编码流程灵活十倍——销售助理问“张三的余额够付新订单吗”，智能体自动调用余额查询+订单金额计算两个工具。

第二层是记忆管理层（Memory Management）。LLM本身无状态，但企业对话需要上下文记忆。我们用Redis构建Conversation Memory，Key为conv:${customerId}:${sessionId}，Value存储最近10轮对话的{role,prompt,response}。每次LLM调用前，用LRANGE conv:CUST-123:abc123 0 9拉取上下文，并注入system prompt。关键创新是记忆衰减算法：对30分钟前的对话，自动降低其权重，避免过期信息干扰决策。

第三层是自主规划层（Planning Engine）。最复杂的场景是“处理客户投诉并预防复发”。传统编排只能线性执行，而智能体需要拆解目标：1）分析当前投诉 → 2）检索历史相似案例 → 3）生成处理方案 → 4）识别流程漏洞 → 5）向改进委员会提报。我们在MuleSoft中实现Plan Generator Flow，它接收LLM的高层规划指令（如[{"step":"analyze_complaint"},{"step":"search_kb"},{"step":"generate_fix"}]），然后逐个调用对应工具Flow。当某步失败（如KB搜索无结果），自动触发Plan Refiner Flow，生成新计划[{"step":"escalate_to_human"}]。

这个演进不是推倒重来，而是渐进式升级。所有智能体能力都构建在现有MuleSoft基础设施上：Tool Registry复用API管理，Memory Storage复用