MuleSoft+LLM企业级AI编排：语义化工作流与智能服务治理

1. 项目概述：当企业级集成平台遇上大语言模型，不是叠加，而是重定义工作流

“AI Orchestration in Action: How MuleSoft and LLMs Fuel the Future of Enterprise AI”——这个标题里藏着一个正在发生的静默革命。它不是讲怎么用ChatGPT写周报，也不是教你在Excel里调个API，而是直指企业数字化最顽固的痛点：系统孤岛林立、数据沉睡在ERP/CRM/HRIS深处、业务逻辑被硬编码在老旧中间件里，而AI能力却像一把锋利但没手柄的刀，悬在半空，切不进真实业务流。MuleSoft在这里不是配角，不是“又一个API网关”，它是那个把LLM从演示厅请进产线车间的调度主任；LLM也不是万能胶水，它是在MuleSoft织就的语义化服务网络上，被精准调用、受控执行、可审计回溯的智能执行单元。我做过7个跨行业AI集成项目，其中4个卡在“模型训得好，上线就崩盘”——不是模型不准，是它根本不知道销售总监今天审批了哪三份合同、库存系统刚触发了哪条补货预警、法务部上周更新的合规条款编号是多少。这些信息不在向量库里，它们躺在SAP的RFC接口里、藏在ServiceNow的REST响应中、锁在Oracle EBS的PL/SQL包里。MuleSoft做的，是把这堆“非结构化语义”翻译成LLM能听懂的、带上下文约束的指令；LLM做的，是把“生成一份符合最新GDPR条款的客户沟通话术”这种模糊需求，拆解成调用Salesforce获取客户画像、调用Confluence查合规文档、调用Workday确认员工权限、最后拼装成话术的原子操作链。这不是AI+Integration，这是用Integration为AI装上企业级的骨骼、神经和反射弧。适合谁看？如果你是企业架构师，正被CIO追问“大模型怎么落地”；如果你是集成开发负责人，天天在Anypoint Studio里写DataWeave脚本却觉得离业务价值越来越远；如果你是AI产品经理，手握百亿参数模型却找不到真实场景喂养——这篇就是为你写的实战手记，不讲概念，只拆MuleSoft Flow里那几行关键配置、DataWeave里那三处致命陷阱、以及为什么LLM调用必须加timeout="8000"而不是默认的30秒。

2. 核心设计思路：为什么非得是MuleSoft + LLM，而不是直接调用OpenAI API？

2.1 企业级AI落地的四大死穴，MuleSoft如何逐个击穿

很多团队第一步就想绕过MuleSoft，直接在应用层调OpenAI API。我试过，也踩过坑。去年给一家保险集团做理赔文案自动生成，前端React应用直连Azure OpenAI，结果上线三天就崩溃——不是模型崩，是并发请求把后端审批系统拖垮了。原因很简单：企业AI不是单点智能，而是多系统协同的闭环智能。MuleSoft的价值，恰恰在于它用企业级基础设施，堵住了四个致命缺口：

• 安全合规缺口：LLM调用必须携带用户身份令牌（JWT）、必须记录完整审计日志（谁、何时、对哪个客户、生成了什么内容）、必须强制数据脱敏（比如自动把身份证号替换成[REDACTED_ID]）。OpenAI原生API不提供这些。MuleSoft的Policy Manager可以插在Flow入口，自动注入OAuth2.0令牌、调用内部DLP服务扫描输出、写入Splunk审计日志——这些不是代码，是拖拽配置的策略组件。

• 协议与数据格式鸿沟：LLM需要JSON输入，但你的SAP系统返回的是IDoc XML，Workday返回的是SOAP，老财务系统只认FTP CSV。MuleSoft的DataWeave引擎不是简单转换，它能做语义映射：比如把SAPEKKO-EKORG字段（采购组织代码）自动关联到主数据管理系统的org_name，再注入LLM提示词的"user_department": "Procurement"。这种映射靠写Python脚本？维护成本高到无法接受。

• 弹性与熔断缺口：LLM服务会抖动。我们实测过，Azure OpenAI在流量高峰时P95延迟从1.2秒跳到8秒。如果应用直连，用户界面就卡死。MuleSoft的Flow Ref组件天然支持Retry Policy（指数退避重试）、Circuit Breaker（连续3次超时自动熔断5分钟）、Fallback（熔断时返回缓存的模板话术）。这些能力写在Anypoint Platform的UI里，不用改一行Java代码。

• 可观测性黑洞：你永远不知道LLM调用失败是因为网络问题、token超限、还是提示词写错了。MuleSoft的Monitoring Dashboard能把一次LLM调用拆成：HTTP Request → DataWeave Transform → LLM API Call → Response Parse → Business Logic，每个环节的耗时、错误码、输入输出样本全在Dashboard里。某次故障，我们5分钟定位到是DataWeave里一个mapObject没处理null值，导致LLM收到{"customer": null}，直接返回{"error": "invalid input"}——这种问题，直连API时你只能看到一串HTTP 400，根本不知道错在哪一层。

提示：别把MuleSoft当成“API代理”。它的核心价值是“语义编排器”——把业务语言（“生成理赔拒付说明”）翻译成技术动作（调SAP查保单状态→调OCR解析医疗票据→调LLM生成合规话术→调邮件系统发送），再把技术动作的结果，翻译回业务语言（“已生成并发送拒付说明，ID: CLM-2024-8871”）。

2.2 架构选型对比：为什么不是Zapier、不是Node-RED、不是自研微服务？

市面上有太多“自动化工具”，但企业级AI编排要求完全不同。我们做过横向测试，用同一套理赔流程（查保单→验票据→生成话术→发邮件），对比四种方案：

关键差异在“LLM调用可控性”。Zapier调OpenAI，超时就是失败；Node-RED要写JavaScript Promise.race()；自研服务要写Hystrix或Resilience4j。而MuleSoft里，你只需在HTTP Request组件属性面板勾选“Enable Circuit Breaker”，填入failure threshold: 3,open state duration: 300000（5分钟），再拖一个Fallback Router组件——整个熔断逻辑就完成了。更绝的是，Fallback里你可以接一个“调用本地规则引擎生成话术”的Flow，保证服务永不降级。这种“企业级韧性”，是低代码工具无法替代的。

2.3 LLM角色重定义：从“问答机器人”到“可编排的智能服务单元”

很多人误解，以为集成LLM就是把/v1/chat/completionsendpoint塞进MuleSoft。错了。在企业编排语境下，LLM必须被抽象为标准化的智能服务（Intelligent Service），具备明确的契约（Contract）：

• 输入契约（Input Contract）：不是丢一段prompt过去。而是结构化JSON，包含context（业务上下文）、constraints（合规约束）、output_schema（期望输出格式）。例如理赔场景的输入：

  { "context": { "policy_id": "POL-2024-9981", "claim_amount": 12500, "denial_reason": "pre-existing_condition" }, "constraints": ["GDPR Article 17", "HIPAA Section 164.502"], "output_schema": { "type": "object", "properties": { "reason_summary": {"type": "string"}, "compliance_reference": {"type": "string"}, "next_steps": {"type": "array", "items": {"type": "string"}} } } }

• 输出契约（Output Contract）：LLM返回的必须是严格符合output_schema的JSON，不能是自由文本。这靠两层保障：一是Prompt Engineering强制LLM输出JSON（如“只输出JSON，不要任何解释”），二是MuleSoft的JSON Schema Validator组件校验，不合规则走Fallback。

• 服务元数据（Service Metadata）：在Anypoint Exchange注册该LLM服务时，必须标注latency_p95: 3200ms,max_tokens: 2048,compliance_certifications: ["SOC2", "ISO27001"]。这些元数据驱动着上游Flow的超时设置和熔断阈值——这才是真正的“服务契约驱动开发”。

我见过太多项目失败，根源就是把LLM当黑盒。当它返回{"error": "rate limit exceeded"}时，上游系统不知道该重试还是降级。而标准化后的智能服务，错误码是INTELLIGENT_SERVICE_RATE_LIMIT，上游Flow能立刻触发“调用缓存模板”Fallback，并告警给AI运维团队。这种确定性，是企业敢把AI放进核心业务流的前提。

3. 核心细节解析：DataWeave、Flow设计与LLM交互的魔鬼细节

3.1 DataWeave不是转换器，是LLM的“语义预处理器”与“输出净化器”

DataWeave常被当作XML/JSON转换工具，但在AI编排中，它是LLM与企业系统之间的“神经突触”。它干三件关键事，每一件都决定AI输出的可用性：

第一，语义富化（Semantic Enrichment）：LLM需要的不是原始数据，而是带业务含义的上下文。比如从SAP获取的保单数据：

{ "EKKO": { "EBELN": "4500001234", "BUKRS": "1000", "LIFNR": "V-7890" } }

直接喂给LLM，它不知道BUKRS=1000是“中国区总部”。DataWeave脚本必须做：

%dw 2.0 output application/json var companyCodeMap = { "1000": "China HQ", "2000": "US West" } --- { policy_id: payload.EKKO.EBELN, business_unit: companyCodeMap[payload.EKKO.BUKRS] default "Unknown", vendor_name: lookupVendorName(payload.EKKO.LIFNR) // 调用另一个Flow查供应商主数据 }

这里lookupVendorName是另一个MuleSoft Flow，实现了主数据实时查询。DataWeave的威力，在于它能把多个系统调用的结果，在一次Flow中组装成LLM的完美输入——这比在Python里写requests.get()优雅得多。

第二，提示词工程（Prompt Engineering）的工业化实现：别在代码里拼字符串！用DataWeave模板：

%dw 2.0 output text/plain --- "Generate a claim denial letter for policy \$(payload.policy_id) with amount \$(payload.claim_amount). Constraints: \$(joinBy(payload.constraints, ', ')). Output must be valid JSON matching this schema: \$(write(payload.output_schema, 'application/json'))."

这个模板把动态业务数据、合规约束、输出Schema全注入Prompt。关键是，所有变量都经过DataWeave类型检查——如果payload.claim_amount是String而非Number，Flow在启动时就报错，而不是等LLM返回乱码。

第三，输出净化（Output Sanitization）：LLM可能返回带Markdown的JSON，或在JSON外加解释文字。DataWeave必须做“外科手术式清洗”：

%dw 2.0 output application/json var rawResponse = payload // 假设这是LLM返回的原始字符串 var jsonStart = rawResponse indexOf "{" var jsonEnd = rawResponse lastIndexOf "}" --- if (jsonStart > -1 and jsonEnd > jsonStart) read(rawResponse[jsonStart to jsonEnd], "application/json") else { "error": "LLM did not return valid JSON", "raw_response": rawResponse }

这段脚本暴力提取第一个{到最后一个}之间的内容，再解析。比用正则可靠，且能处理嵌套JSON。我们线上环境发现，Azure OpenAI在流式响应（stream=true）时，偶尔会在JSON前加data:前缀，这个脚本也能处理。

注意：永远不要信任LLM的原始输出。DataWeave的read()函数必须配合try/catch——在Flow里用On Error Propagate捕获MULE:EXPRESSION错误，走Fallback流程。我吃过亏：某次LLM返回{"reason_summary": "Pre-existing condition"}，但compliance_reference字段缺失，read()直接抛异常，整个Flow中断。后来加了default {}兜底，才保证业务不中断。

3.2 Flow设计：三层编排架构，让AI真正融入业务流

一个健壮的AI编排Flow，绝不是“HTTP Request → LLM → HTTP Response”。我们采用三层架构，每层职责分明：

3.2.1 接入层（Ingress Layer）：统一入口与安全网关

• 组件：HTTP Listener + APIkit Router + Rate Limiting Policy + JWT Validation Policy
• 关键配置：在APIkit Router里定义OpenAPI 3.0规范，明确/generate-denial-letter的requestBody和responses。Policy Manager里启用“Rate Limiting”，按client_id限流（防恶意刷），同时启用“JWT Validation”，自动从Header提取Authorization: Bearer <token>，验证签名并注入user_id到attributes。
• 为什么重要：这层把LLM调用变成了标准API调用。前端App不用知道背后是LLM还是规则引擎，只要按OpenAPI契约传参即可。某次我们把LLM替换为规则引擎（因合规要求），接入层零修改，只改了编排层。

3.2.2 编排层（Orchestration Layer）：智能服务的“交响乐指挥”

• 组件：Flow Ref（查SAP）→ Transform Message（DataWeave富化）→ Flow Ref（查主数据）→ Transform Message（构建Prompt）→ HTTP Request（调LLM）→ Transform Message（解析JSON）→ Choice Router（校验输出）
• 关键技巧：在HTTP Request组件里，timeout设为8000毫秒（不是默认30秒！），因为LLM响应时间波动大，30秒太长，用户会放弃；8秒是用户体验临界点。followRedirects必须设为false，避免LLM服务重定向导致Flow逻辑混乱。
• Choice Router逻辑：

  <choice doc:name="Validate LLM Output"> <when expression="#[payload.reason_summary != null and payload.compliance_reference != null]"> <!-- 正常流程 --> </when> <otherwise> <!-- Fallback：调用本地规则引擎生成模板话术 --> <flow-ref name="generateTemplateDenialLetter" /> </otherwise> </choice>

  这里payload是DataWeave解析后的JSON对象，校验字段存在性，比用正则判断字符串靠谱百倍。

3.2.3 输出层（Egress Layer）：结果分发与审计归档

• 组件：Transform Message（格式化最终响应）→ Scatter-Gather（并行调用：1. 发送邮件 2. 写入Audit Log 3. 更新CRM状态）→ HTTP Response
• 关键细节：Scatter-Gather里三个分支必须设maxConcurrency="3"，且每个分支用On Error Continue——邮件发送失败不能影响审计日志写入。Audit Log写入用Database Connector，插入一条记录包含trace_id,input_hash,llm_provider,response_time_ms,is_fallback（标记是否走了Fallback）。这条日志是后续AI效果分析的黄金数据源。

整个Flow的Trace ID贯穿三层，Anypoint Monitoring里能看到从HTTP请求开始，到每个数据库写入结束的完整链路。某次性能优化，我们发现“查主数据”Flow平均耗时2.1秒，拖慢了整体响应——于是把它改成异步调用，用Publish Consume模式，主流程不等结果，只把主数据ID传给LLM，由LLM在生成话术时引用。响应时间从4.8秒降到1.9秒。

3.3 LLM调用实战：不只是Endpoint，是服务治理的战场

调用LLM不是填个URL那么简单。我们在生产环境总结出五条铁律：

第一，Endpoint必须带版本号与区域标识：

• 错误：https://api.openai.com/v1/chat/completions
• 正确：https://eastus.api.azure.com/v1/chat/completions?api-version=2023-12-01-preview
  理由：Azure OpenAI不同区域（eastus, westus）的SLA不同，版本号确保API契约稳定。MuleSoft的HTTP Request组件里，basePath设为/v1/chat/completions，host设为eastus.api.azure.com，queryParameters里加api-version。这样升级版本时，只改一个地方。

第二，Headers必须精细化控制：

<http:request-config name="LLM_Request_Config" ...> <http:headers> <![CDATA[#[{ "Authorization": "Bearer " ++ vars.llm_api_key, "Content-Type": "application/json", "api-key": vars.llm_api_key, // Azure特有 "X-Request-ID": attributes.correlationId // 关联Trace ID }]]> </http:headers> </http:request-config>

注意api-key是Azure必需的Header，而OpenAI用Authorization。X-Request-ID把MuleSoft的Trace ID透传给LLM服务，方便跨系统排查。

第三，Payload必须结构化，禁用自由文本：

{ "model": "gpt-4-turbo-2024-04-09", "messages": [ { "role": "system", "content": "You are an insurance compliance assistant. Output ONLY valid JSON." }, { "role": "user", "content": vars.prompt } // vars.prompt是DataWeave生成的富化Prompt ], "temperature": 0.1, // 企业场景要确定性，不是创意性 "max_tokens": 1024, "response_format": { "type": "json_object" } // 强制JSON输出 }

temperature=0.1是血泪教训——设成0.7时，LLM对同一保单会生成不同话术，法务部直接否决。

第四，错误处理必须覆盖LLM全错误谱系：

• 429 Too Many Requests→ 触发Circuit Breaker
• 400 Bad Request→ 检查vars.prompt长度，超限则截断并告警
• 401 Unauthorized→ 立即通知运维轮换API Key
• 500 Internal Server Error→ 走Fallback，同时发送PagerDuty告警

这些在MuleSoft里用On Error Propagate+Error Type匹配实现，比在应用层写if-else清晰。

第五，监控指标必须超越HTTP层面：
在Anypoint Monitoring里，我们自定义了三个关键指标：

• llm_response_time_p95：从HTTP Request发出到收到响应的耗时
• llm_output_validity_rate：DataWeaveread()成功解析JSON的比例
• fallback_activation_rate：走Fallback流程的请求占比

当fallback_activation_rate超过5%，自动触发根因分析Flow——查是不是prompt里某个字段为空，或是LLM模型更新导致Schema不兼容。这才是真正的AI可观测性。

4. 实操过程：从零搭建理赔拒付话术生成Flow的完整步骤

4.1 环境准备与连接器配置（30分钟）

第一步不是写Flow，是搭地基。我们用MuleSoft Anypoint Platform Cloud，版本4.4.0。

Step 1：创建专用环境与VPC

• 在Anypoint Platform → Runtime Manager → Environments，新建prod-ai-orchestration环境
• 启用VPC Peering，打通与企业内网（含SAP、Workday）的网络——这是安全前提，LLM Flow绝不能走公网调用内部系统。
• 为该环境分配专用Worker Size：Medium (4 vCPU, 16GB RAM)，因为LLM调用内存压力大。

Step 2：配置核心连接器

• SAP Connector：在Exchange下载SAP RFC Connector 1.5.0，安装到Runtime。配置JCo Destination：

  jco.client.ashost = sap-prod.internal jco.client.sysnr = 00 jco.client.client = 800 jco.client.user = MULE_AI_USER jco.client.passwd = ${secure::sap_password} // 用Secure Properties加密

• Azure OpenAI Connector：没有官方Connector，我们用HTTP Connector。创建LLM_HTTP_Config：
  • Host:eastus.api.azure.com
  • Base Path:/openai/deployments/gpt-4-turbo/chat/completions
  • Query Parameters:api-version=2023-12-01-preview
  • Authentication: None（因为Headers里传Key）

Step 3：创建共享资源

• Global Error Handler：在src/main/resources下建error-handler.xml，定义全局On Error Propagate，捕获所有错误并写入ai-audit-log数据库表。
• Shared DataWeave Functions：建utils.dwl，封装常用函数：

  %dw 2.0 fun hashInput(input: Any) = write(input, "application/json") as String as Binary as String { encoding: "base64" } fun truncateText(text: String, maxLength: Number) = if (sizeOf(text) > maxLength) text[0 to maxLength-1] else text

实操心得：SAP密码绝不能硬编码！用Anypoint Platform的Secure Properties功能，${secure::sap_password}会自动解密。我们曾因密码明文暴露，被安全审计一票否决。另外，VPC Peering配置后，务必用telnet sap-prod.internal 3300测试连通性——很多团队卡在这一步，以为是代码问题，其实是网络不通。

4.2 Flow开发：理赔话术生成的七步精炼（2小时）

创建新Flow，命名为generate-denial-letter-flow，按以下顺序组装：

Step 1：HTTP Listener

• Path:/api/v1/claims/denial-letter
• Allowed Methods: POST
• Enable CORS: true（允许前端调用）
• 在Listener里添加Correlation ID：attributes.correlationId default uuid()，为全链路追踪打基础。

Step 2：APIkit Router

• 引用OpenAPI文件claim-api.yaml，自动生成POST:/api/v1/claims/denial-letter路由。
• OpenAPI里定义requestBody为：

  requestBody: required: true content: application/json: schema: type: object properties: policy_id: type: string claim_amount: type: number denial_reason: type: string

Step 3：调用SAP查保单（Flow Ref）

• Flow Ref指向get-policy-from-sap-flow
• 输入：{ "ebeln": payload.policy_id }
• 输出：SAP返回的IDoc XML，用XML to Map转换器转成Map。

Step 4：DataWeave富化（Transform Message）

%dw 2.0 output application/json import * from utils --- { policy_id: payload.EKKO.EBELN, claim_amount: payload.EKKO.NETWR as Number, denial_reason: payload.denial_reason, business_unit: "China HQ", // 简化版，实际查主数据 constraints: ["GDPR Article 17", "HIPAA Section 164.502"] }

Step 5：构建Prompt（Transform Message）

%dw 2.0 output text/plain import * from utils --- "Generate a claim denial letter for policy \$(payload.policy_id) with amount \$(payload.claim_amount) USD. Reason: \$(payload.denial_reason). Compliance constraints: \$(joinBy(payload.constraints, ', ')). Output MUST be valid JSON with these fields: reason_summary (string), compliance_reference (string), next_steps (array of strings). NO EXPLANATION, NO MARKDOWN, ONLY JSON."

Step 6：调用LLM（HTTP Request）

• Config:LLM_HTTP_Config
• Method: POST
• Headers: 如前文所述，带api-key和X-Request-ID
• Body:

  { "messages": [ { "role": "system", "content": "You are an insurance compliance assistant." }, { "role": "user", "content": vars.prompt } ], "temperature": 0.1, "max_tokens": 1024, "response_format": { "type": "json_object" } }

• Timeout:8000ms
• Follow Redirects:false

Step 7：解析与校验（Transform Message + Choice Router）

• Transform Message：用read(payload, "application/json")解析
• Choice Router：#[payload.reason_summary != null and payload.compliance_reference != null]
  • True：走正常路径，格式化响应
  • False：flow-ref到generate-template-denial-letter-flow（用FreeMarker模板生成话术）

Step 8：输出层（Scatter-Gather）

• Branch 1：Send Email via SMTP Connector
• Branch 2：Insert Audit Log via Database Connector
• Branch 3：Update CRM Status via Salesforce Connector
• 所有分支设On Error Continue，并记录错误日志。

Step 9：HTTP Response

• Status:200
• Payload:

  { "status": "success", "trace_id": attributes.correlationId, "generated_letter": payload, "is_fallback": vars.is_fallback default false }

实操心得：DataWeave里as Number必须加！SAP返回的金额是字符串"12500.00"，不转Number，LLM会当成文本处理。还有，response_format必须设，否则LLM可能返回Markdown格式JSON，read()直接失败。我们第一次上线，50%请求走Fallback，查日志发现全是MULE:EXPRESSION错误，根源就是没设response_format。

4.3 测试与部署：从Postman到生产环境的三道关卡

关卡一：单元测试（Postman + Mock）

• 用Postman发请求：

  POST /api/v1/claims/denial-letter { "policy_id": "4500001234", "claim_amount": 12500, "denial_reason": "pre-existing_condition" }

• 在Anypoint Platform里，为SAP Connector启用Mock Mode，返回预设XML，隔离外部依赖。
• 验证点：响应时间<2秒，is_fallback=false，compliance_reference字段存在。

关卡二：集成测试（真实系统）

• 切换SAP Connector到真实环境，但LLM用Mock：

  <mock:config name="LLM_Mock_Config" /> <mock:when messageProcessor="http:request" config-ref="LLM_HTTP_Config"> <mock:response> <mock:body>{"reason_summary":"Pre-existing condition","compliance_reference":"GDPR Art.17","next_steps":["Contact customer","File appeal"]}</mock:body> </mock:response> </mock:when>

• 测试100次，验证SAP数据正确注入、Prompt构建无误、JSON解析稳定。

关卡三：生产灰度（Canary Release）

• 在Runtime Manager，为generate-denial-letter-flow启用Canary Deployment：
  • 5%流量走新Flow（带LLM）
  • 95%流量走旧规则引擎
• 监控fallback_activation_rate，若>3%，自动回滚。
• 我们灰度期发现，LLM对denial_reason="coding_error"的响应不稳定，于是加了DataWeave预处理：payload.denial_reason replace "coding_error" with "billing_code_mismatch"，问题解决。

部署命令：

# 打包 mvn clean package -DskipTests # 部署到Cloud mule-maven-plugin:deploy -Dmule.env=prod-ai-orchestration

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 LLM调用超时频发？先查这三处，别急着加超时

LLM超时是最高频问题，但90%不是LLM慢，而是MuleSoft配置陷阱：

问题1：HTTP Request的followRedirects=true（默认值）

• 现象：Flow卡住30秒，日志显示HTTP Request timed out
• 根因：Azure OpenAI有时返回302重定向到另一台服务器，MuleSoft默认跟随，但重定向目标可能不可达或防火墙拦截。
• 解决：在HTTP Request组件属性里，显式设followRedirects=false。重定向应由LLM服务端处理，MuleSoft只做客户端。

问题2：DataWeaveread()函数阻塞

• 现象：Flow在Transform Message卡住，CPU飙升
• 根因：LLM返回超大JSON（>1MB），read()解析耗时。我们遇到过LLM返回12MB的冗余日志。
• 解决：在HTTP Request后加Transform Message，用DataWeave截断：

  %dw 2.0 output text/plain --- if (sizeOf(payload) > 500000) // 500KB payload[0 to 499999] ++ "...TRUNCATED" else payload

问题3：SAP Connector的JCo连接池耗尽

• 现象：LLM Flow正常，但SAP查询超时，日志报JCO_ERROR_RESOURCE
• 根因：SAP JCo默认连接池大小为3，高并发时排队。
• 解决：在JCo Destination配置里加：

  jco.client.pool_capacity = 20 jco.client.idle_timeout = 600000 // 10分钟

排查技巧：打开Anypoint Monitoring的Thread Dump功能。当Flow卡住时，点击Take Thread Dump，搜索http-request或jco，看线程在等什么。比猜快10倍。

5.2 LLM输出格式错乱？DataWeave的五个救命函数

LLM返回的“JSON”常有陷阱，DataWeave必须层层过滤：

我们把这些封装成cleanJsonString()函数，放在utils.dwl里复用。某次上线，发现LLM返回的JSON里有\u0007（响铃符），导致read()失败，加了这一行，问题消失。

5.3 审计日志写入失败？数据库连接的隐藏雷区

Audit Log必须100%写入，否则合规审计不过。但我们踩过两个深坑：

坑1：Database Connector的autoCommit=false（默认）