企业官网建设流程全解析

1. 这不是又一篇“Agent概念科普”，而是我在真实训练现场撕下来的几页笔记

最近三个月，我带着两个实习生在实验室里反复跑通了三套Agentic RL pipeline——一套基于LLM的决策型agent，一套嵌入物理仿真环境的具身agent，一套面向工业质检的多step reasoning agent。过程中踩过的坑、调过的参数、重写的reward函数，比过去两年读的综述加起来还实在。这篇整理，不讲“Agent是什么”“RL和监督学习的区别”这类教科书定义，也不堆砌论文标题和SOTA榜单。它只回答三个问题：为什么Agentic RL现在突然变得可落地了？哪些能力模块真正在决定一个agent能不能走出demo跑进产线？训练时哪几个环节一错就全盘崩，但文献里几乎从不提？

核心关键词——Agent、Agentic RL、RL、模型训练、训练框架——全部来自真实项目日志。比如“agent execution terminated due to error.”这个报错，我们光是定位它就花了17小时；再比如“skill和agent的区别”，不是理论辨析，而是我们在设计任务编排层时，为是否把OCR识别封装成独立skill而激烈争论过四轮。你看到的每一个小节，背后都对应着至少一次GPU显存溢出、一次reward曲线诡异震荡、一次线上服务超时告警。如果你正卡在“模型训得出来但agent跑不稳”“能做单步推理但没法自主规划”“本地效果好一上真机就失效”这些具体问题上，这篇就是为你写的。它不承诺“5分钟上手”，但保证每一步操作都有上下文、有取舍依据、有失败快照。

2. Agentic RL不是RL+Agent的简单拼接，而是训练范式的结构性迁移

2.1 传统RL训练框架的“三座大山”如何被Agent范式悄然瓦解

先说清楚一个前提：Agentic RL ≠ 在RL算法外加个LLM当“大脑”。这是当前最大的认知误区。我见过太多团队把PPO算法直接套在LLM输出上微调，结果reward涨了，但agent在真实环境中连最基础的“先看再动”都做不到。问题出在哪？在于传统RL训练框架的底层假设，和Agent运行的实际需求存在三处根本性错位。

第一座山：状态空间的爆炸性与稀疏性矛盾。标准RL（如DQN、PPO）依赖密集、低维、可微的状态表示（比如机器人关节角度、游戏像素帧）。但Agent面对的是高维异构输入：一段用户语音转文本、一张模糊的工业零件图、一个包含12个字段的JSON API响应。把这些全塞进state vector？维度直接上万，且99%是噪声。我们试过用ResNet34提取图像特征再拼接文本embedding，结果reward收敛速度下降60%，因为特征对齐完全失效。后来改用分层状态抽象——图像走CNN backbone，文本走RoBERTa中文预训练模型，结构化数据走轻量MLP，三路输出再经cross-attention融合。关键不是模型多强，而是状态表征必须可解释、可调试、可人工干预。比如当agent在质检中漏检，我们能快速回溯是图像特征提取失真，还是文本指令理解偏差，而不是面对一个黑箱state vector干瞪眼。

第二座山：奖励信号的延迟性与任务粒度的错配。传统RL常用稀疏奖励（如游戏通关才给+1），靠算法探索。但Agent的真实任务是“完成用户请求”，这个目标天然分层：用户说“找出流水线上裂纹最严重的3个零件”，分解为“定位流水线区域→识别所有零件→对每个零件做裂纹检测→排序并返回Top3”。如果只在最终返回结果正确时给reward，中间任何环节出错（比如ROI框偏移5像素导致漏检）都无法被梯度捕获。我们最终采用分层奖励塑形（Hierarchical Reward Shaping）：视觉定位阶段用IoU loss作为dense reward，检测阶段用F1-score加权，排序阶段用NDCG。每一层reward都经过归一化处理，确保量级可比。实测下来，训练收敛时间从平均2800 episode缩短到620 episode，更重要的是，失败案例的分布从“全链路随机崩溃”变成“集中在排序层”，debug效率提升数倍。

第三座山：策略网络的静态性与环境动态性的冲突。标准PPO policy network是一个固定参数的函数映射。但Agent必须应对未见过的工具调用（比如新接入一个YOLOv11模型API）、突发的环境约束（比如机械臂突然报告力矩超限）、甚至用户中途修改意图（“等等，只要A型号零件”）。硬编码这些逻辑？维护成本爆炸。我们的解法是引入可插拔技能库（Pluggable Skill Library）：每个skill是一个独立微服务（如ocr_service:8080/extract_text,yolo_v11_infer:8000/detect），agent core只负责生成skill调用序列（action plan）和参数。训练时，policy network输出的是skill ID + 参数向量，而非原始动作。这样，新增一个skill只需注册接口，无需重训整个agent。上周产线升级了新的缺陷检测模型，我们只改了1行配置，没碰训练代码。

提示：别被“Agentic RL”这个词唬住。它本质是把RL的优化目标，从“最大化累积奖励”转向“最大化任务完成率”，而实现路径是重构状态、奖励、动作三要素的定义方式。那些还在用CartPole思维训练Agent的团队，本质上是在用自行车链条驱动挖掘机。

2.2 Agent能力光谱：从“能动”到“会想”的五个不可跳过的层级

很多团队一上来就想做“自主规划”，结果连基础执行都飘忽不定。我们按实际交付难度，把Agent能力拆成五个递进层级，每个层级对应明确的技术验证点和失败红线：

注意：L1和L2是生死线，必须100%达标才能进入L3训练。我们曾因L1工具调用稳定性不足（98.7%），导致L3规划模块学到了大量“无效重试”行为，后续花了两周时间回退重构执行层。所谓“能力光谱”，不是画饼，而是每个层级都对应着GPU显存占用、训练时长、线上QPS的硬指标。比如L4记忆层，向量数据库选型直接影响L5反思的实时性——用FAISS在树莓派5上部署，单次记忆检索耗时230ms，而用Qdrant集群压测到80ms，这直接决定了反思能否嵌入实时交互流。

2.3 训练框架选型：为什么我们弃用Ray + RLlib，转向自研轻量框架

当前主流方案是Ray + RLlib，文档丰富、生态成熟。但我们在线上压测时发现三个致命短板：

• 状态同步开销过大：RLlib默认用Redis做rollout worker和learner的state同步。当agent需要每步都查询向量数据库（L4记忆层）时，Redis成为瓶颈。我们实测100并发下，Redis CPU占用率达92%，P99延迟飙升至1.2s，远超agent单步容忍上限（300ms）。

• 奖励计算耦合过深：RLlib的reward_fn必须在env.step()内完成。但我们的分层奖励需要调用外部服务（如调用YOLOv11模型算F1-score），这会导致env阻塞。强行异步？RLlib的callback机制不支持跨进程reward计算，容易丢失reward信号。

• 调试黑盒化：RLlib的log只记录episode-level reward和loss。当L3规划层出现“步骤颠倒”时，我们需要看到每一步的action概率分布、skill参数置信度、跨模态注意力权重——这些RLlib根本不暴露。

于是我们砍掉所有通用组件，用Python + gRPC + SQLite构建了极简训练框架：

• Rollout Engine：每个worker独立加载env和policy，通过gRPC调用统一的Reward Service（暴露HTTP接口，内部用FastAPI+缓存）。Reward Service收到请求后，异步触发YOLOv11推理、调用向量DB查记忆、计算NDCG，全部完成后回调worker。worker只管执行，reward由Service兜底。

• Learner Core：不用Redis，改用SQLite做经验回放（Replay Buffer）。每条experience存为一行，字段包括state_embedding,action_id,skill_params_json,reward_vector（长度=层数），done_flag。SQL索引建在done_flag和timestamp上，确保采样高效。

• Debug Dashboard：所有worker启动时注册到中央Registry（内存Dict），Dashboard通过gRPC实时拉取每个worker的last_action_probs,attention_weights,memory_query_log，渲染成可交互的时序图。某次发现L3规划总在第4步出错，Dashboard直接标出该步的跨模态注意力热力图——文本指令中“最严重”一词，与图像裂纹区域的注意力权重只有0.13，而与背景金属纹理权重高达0.67。根源立刻清晰：文本embedding没对齐视觉语义。

这个框架代码量不到RLlib的1/20，但让我们把一次完整debug周期从“重启训练→等2小时→看log猜原因”压缩到“Dashboard圈出异常点→5分钟定位→热更新embedding层”。

3. 核心细节解析：从数据、奖励到评估，每个环节的魔鬼都在参数里

3.1 数据构造：不是“越多越好”，而是“错得恰到好处”

Agentic RL的数据，绝不是简单收集用户query+agent response。我们发现，高质量训练数据必须满足三个反直觉条件：

第一，必须包含可控的“合理错误”样本。纯正确样本会让agent丧失纠错能力。我们专门构造三类错误：

• 工具调用错误：让OCR service返回乱码文本，但保留JSON结构（模拟网络抖动）；
• 感知混淆错误：在工业图片上叠加与裂纹纹理相似的金属划痕（考验视觉鲁棒性）；
• 规划逻辑错误：人工编写“步骤颠倒”的bad plan（如先delete_file再read_file），并标注正确DAG。

这些错误样本占训练集18%，但使L5反思模块的修正有效率从31%提升至79%。关键参数：错误注入率必须随训练epoch衰减——初期100%错误样本，后期降至5%，否则agent学不会基础能力。

第二，状态表征必须带“可编辑标记”。传统做法把原始输入（如整张图片+整段文本）喂给模型。但我们发现，agent在真实场景中会主动“聚焦”：质检员先扫视流水线全局，再放大可疑区域。于是我们在state中加入focus_mask字段：图像部分是二值掩码（1=关注区域），文本部分是token-level重要性分数（由RoBERTa attention layer输出）。Policy network的输入变成(image * focus_mask, text * focus_weight)。实测L2感知准确率提升12个百分点，因为模型不再被迫“看全图”，而是学着分配注意力。

第三，动作空间必须“离散化+参数化”混合。纯离散动作（如100个skill ID）导致维度爆炸；纯连续参数（如直接输出坐标）无法保证语义正确。我们的解法：

• Skill ID：离散，取值范围[0, N-1]，N=当前注册skill总数；
• Skill Params：连续向量，但每个维度有明确物理意义和约束。例如yolo_v11_detect的params向量定义为[confidence_threshold, iou_threshold, max_detections, class_filter_id]，训练时用tanh激活后线性映射到合法区间（如confidence_threshold∈[0.3, 0.9]）。

这样既保持动作语义清晰，又让梯度可回传。参数约束的数学表达很重要：param_i = low_i + (high_i - low_i) * (tanh(x_i) + 1) / 2，避免模型输出非法值导致工具调用崩溃。

3.2 奖励函数设计：从“写死规则”到“可学习的奖励代理”

早期我们用if-else写reward：检测到裂纹+1，漏检-2，误检-1。结果agent学会“保守策略”——宁可全漏检也不冒误检风险。后来意识到，reward不是规则，而是教学信号。我们构建了三层奖励代理：

• 基础层（Rule-based）：覆盖硬性约束，如tool_call_timeout → reward = -5，invalid_skill_id → reward = -10。这部分必须100%确定，不容学习。

• 质量层（Model-based）：用小型监督模型打分。例如，训练一个轻量CNN（ResNet18精简版）专门判断YOLOv11检测框的质量（IoU、置信度分布、框间重叠度），输出0~1分。这个模型在训练前用10万张标注图预训练好，冻结权重，只作reward计算器。它比人工规则更细粒度，且能捕捉复杂模式（如多个小裂纹聚集成簇时，单框覆盖优于多框分散）。

• 一致性层（LLM-as-Judge）：对L3/L4/L5能力做终局评判。例如，给定用户query、agent执行步骤、最终结果，调用本地部署的Qwen2-7B模型，prompt为：“请从任务完成度、步骤合理性、信息复用准确性三方面评分，每项0-5分，只输出JSON {‘completion’:x, ‘plan’:y, ‘memory’:z}”。这个reward计算慢（平均800ms），所以只在episode结束时调用，不参与每步梯度更新，但用于指导长期策略优化。

三层reward加权求和：R_total = 0.4*R_basic + 0.4*R_quality + 0.2*R_consistency。权重不是拍脑袋，而是用网格搜索在验证集上找到的Pareto最优解——当R_basic权重低于0.3时，工具调用稳定性暴跌；高于0.5时，质量层信号被淹没。

注意：LLM-as-Judge必须用本地小模型！我们试过调用GPT-4 API，结果训练过程受网络波动影响，reward方差极大，policy network学到了“网络好的时候激进，差的时候保守”的诡异行为。本地Qwen2-7B虽弱于GPT-4，但reward稳定，这才是训练稳定的基石。

3.3 评估体系：拒绝“准确率幻觉”，建立端到端可信度仪表盘

很多团队用“任务完成率”作为唯一指标，结果上线后发现：完成率95%，但90%的完成是靠暴力重试（平均调用工具7.3次）。这毫无工程价值。我们构建了五维评估仪表盘：

关键创新在于失败归因分析（Failure Attribution Analysis）：当某次评估失败，仪表盘自动触发根因诊断：

• 若TCSR低 → 检查工具SDK日志，定位是网络超时还是参数错误；
• 若DVR低 → 提取失败episode的step list，用图算法检测环路或依赖断裂；
• 若CU低 → 对比反思前后的action probs，看是否聚焦到错误维度。

这套仪表盘不是训练完再跑，而是嵌入训练循环：每个epoch结束后，自动在验证集上跑一轮五维评估，生成趋势图。当DVR连续3个epoch不升反降，训练脚本自动暂停，弹出诊断报告——这比盯着loss曲线有效十倍。

4. 实操过程：从零搭建Agentic RL pipeline的七步关键操作

4.1 第一步：定义你的Agent边界——比写代码更重要的事

很多人跳过这步，直接冲去搭模型。结果训了两周，发现agent在真实场景中“不该做的做了，该做的没做”。我们强制执行“三问边界法”：

• 问输入：Agent接收什么？仅限用户文本？是否要处理摄像头流？是否要读取PLC寄存器？明确输入源、频率、格式、SLA（如图像必须≤200ms内送达）。我们产线agent的输入边界是：①用户微信文字（延迟≤3s）②工控机推送的JSON状态（延迟≤50ms）③USB摄像头H.264流（帧率15fps）。超出此边界的输入（如用户发语音），由前置服务转文本后接入。

• 问输出：Agent能做什么？是只生成文本回复？还是能控制机械臂？能写数据库？明确输出通道、协议、安全约束。我们规定：所有输出必须经由ActionExecutor统一网关，该网关内置白名单（只允许调用yolo_v11_detect,ocr_extract,db_update三个service），且每个调用需附带intent_id（由用户query哈希生成）用于审计。

• 问失败：Agent失败时，谁兜底？怎么兜底？不能只写“报错”。我们定义三级兜底：

  • L1：Agent自身重试（最多2次，间隔指数退避）；
  • L2：降级到规则引擎（如OCR失败则用正则从文本抽数字）；
  • L3：人工接管（触发企业微信告警，附带失败上下文截图和trace_id）。

这三问的答案，直接决定后续所有技术选型。比如输入含实时视频流，就必须选支持streaming inference的模型（我们弃用PyTorch原生，改用Triton Inference Server）；输出需控制硬件，则reward函数必须包含安全约束项（如机械臂力矩超限立即reward=-100）。

4.2 第二步：构建可调试的技能库——不是写API，是设计契约

技能（Skill）不是把现有API包一层就完事。它是Agent的能力原子单元，必须定义清晰的契约（Contract）：

• 输入契约：明确参数名、类型、范围、必填性。例如yolo_v11_detect的契约：

  { "image_base64": {"type": "string", "required": true}, "confidence_threshold": {"type": "float", "min": 0.1, "max": 0.95, "default": 0.5}, "class_filter": {"type": "list", "items": {"type": "string"}, "default": ["crack"]} }

  这个契约自动生成SDK文档、输入校验代码、mock server。我们用OpenAPI 3.0规范描述，工具链自动生成Python client。

• 输出契约：定义成功/失败的结构化响应。成功必须含detections数组（每个元素有bbox,class,score）；失败必须含error_code（如TOOL_TIMEOUT,INVALID_INPUT）和retryable布尔值。Agent core据此决定重试还是降级。

• SLA契约：每个skill声明P95延迟、最大并发数、错误率容忍阈值。ocr_service契约：延迟≤800ms，错误率≤0.3%，超限则触发熔断。这些契约不是摆设——训练时，Reward Service会实时监控skill SLA，超限时自动注入负reward。

我们用YAML管理所有skill契约，存于Git仓库。新增skill只需提交YAML，CI/CD自动：

• 生成client SDK；
• 部署mock server（用于训练时隔离依赖）；
• 更新Dashboard的技能健康度监控面板。

4.3 第三步：设计分层状态表征——让Agent“看得懂”世界

状态（State）是Agent的认知基础。我们摒弃“把所有东西flatten成vector”的粗暴做法，采用分层状态抽象（Hierarchical State Abstraction）：

• L0 原始层：不做任何处理，存原始字节流。图像存为bytes，文本存为str，JSON存为dict。仅用于debug回放，不参与训练。

• L1 特征层：用专用模型提取特征，每个子模块输出固定维度向量：

  • 图像：ResNet34 backbone（去掉FC层），输出512维向量；
  • 文本：RoBERTa中文预训练模型（取[CLS] token），输出768维向量；
  • 结构化数据：轻量MLP（3层，128→64→32），输入为数值字段归一化后拼接，输出32维向量。

• L2 融合层：用Cross-Attention融合L1特征。Query来自文本特征，Key/Value来自图像和结构化特征。输出一个512维的state_embedding，这就是policy network的输入。关键技巧：在Cross-Attention后加一个门控机制，输出[text_gate, image_gate, struct_gate]三个权重，强制模型学习各模态贡献度。训练时监控这些gate值，若某模态gate长期<0.1，说明该模态特征提取失效，需调整backbone。

• L3 上下文层：注入记忆和焦点。将L2输出与focus_mask_embedding（由CNN生成的256维向量）和memory_embedding（从向量DB查出的512维向量）拼接，再经一层MLP压缩回512维。最终state维度恒为512，无论输入多复杂。

这套设计让state具有可解释性：当agent出错，我们能可视化focus_mask看它在“看哪里”，能查memory_embedding看它“记住了什么”，能看gate值看它“信谁更多”。

4.4 第四步：实现分层奖励塑形——让Agent“学得会”任务

奖励（Reward）是Agent的学习指南针。我们彻底抛弃单值reward，实现分层奖励塑形（Hierarchical Reward Shaping）：

• L1 执行层reward：针对工具调用本身。

  • 成功：+1.0
  • 超时：-2.0
  • 参数错误：-3.0
  • 熔断触发：-5.0
  • （注：所有值经归一化，确保量级一致）

• L2 感知层reward：针对多模态理解质量。

  • 图像-文本对齐度：用CLIP模型计算余弦相似度，映射到[0,1]；
  • 结构化数据关键字段提取准确率：人工标注1000条，训练轻量分类器打分；
  • 加权平均：0.6*alignment + 0.4*extraction

• L3 规划层reward：针对步骤逻辑。

  • 步骤DAG有效性：用图算法验证无环且依赖满足，有效则+1.0，否则-1.0；
  • 步骤必要性：人工标注每步是否冗余，冗余步数越多reward越低；
  • （注：此reward只在episode结束时计算，不参与每步更新）

• L4 记忆层reward：针对信息复用。

  • 关键实体召回率：用户提及的设备ID、型号等，在后续步骤中被正确使用的比例；
  • 记忆新鲜度：使用距今时间加权，24小时内使用得满分，72小时后得0分；

• L5 反思层reward：针对自我修正。

  • 修正后任务完成率提升幅度；
  • 修正方案的可执行性（由LLM-as-Judge评分）；

最终reward是各层加权和，权重通过验证集网格搜索确定。关键参数：L1 reward权重必须≥0.4，否则agent会忽视基础执行稳定性，沉迷“花式失败”。

4.5 第五步：训练策略网络——不是调参，是设计学习节奏

Policy network训练不是调learning rate那么简单。我们设计了三阶段渐进式训练（Three-Stage Progressive Training）：

• Stage 1：模仿学习（IL）主导（前30% epoch）

  • 数据：人工编写的1000条高质量轨迹（query→step list→result）；
  • 目标：最小化action ID和skill params的交叉熵损失；
  • 关键：冻结backbone（ResNet34/RoBERTa），只训head层，防止过拟合；
  • 效果：快速建立基础能力，TCSR从0%拉升至85%。

• Stage 2：强化学习（RL）主导（中间40% epoch）

  • 数据：IL阶段产出的agent与环境交互生成的rollout；
  • 目标：PPO loss + 分层reward加权和；
  • 关键：开启L1-L4 reward，L5 reward暂不启用（因反思模块未训）；
  • 效果：DVR从72%提升至93%，SPT从12.5降至7.1。

• Stage 3：反思增强（Reflection-Augmented）（后30% epoch）

  • 数据：Stage 2中失败的episode，经人工标注根因后，加入反思训练；
  • 目标：联合优化policy loss和反思loss（预测根因的交叉熵）；
  • 关键：L5 reward启用，权重逐步从0.1升至0.2；
  • 效果：CU从18%提升至67%，失败后首次修正成功率显著提高。

每个stage切换时，我们手动检查仪表盘的五维指标。若Stage 1后TCSR<80%，则退回Stage 1，增加人工轨迹；若Stage 2后DVR<90%，则检查L3 reward设计，可能需加强DAG约束项。

4.6 第六步：部署与监控——让Agent“活”在生产环境

训练完的model只是半成品。部署是另一场硬仗：

• 模型服务化：Policy network用Triton Inference Server封装。输入是state_embedding（512维），输出是action_id和skill_params。Triton配置关键参数：

  • max_batch_size=32（平衡吞吐与延迟）；
  • dynamic_batching启用，但preferred_batch_size=[8,16]（避免小batch浪费）；
  • instance_group设为[{"kind": "KIND_CPU", "count": 2}]（CPU推理足够，GPU留给YOLOv11）；

• 状态服务化：L1特征提取（ResNet34/RoBERTa）也用Triton部署，但与policy分离。这样，当图像分辨率变化，只需更新特征服务，不动policy。

• 实时监控：在Dashboard嵌入四大看板：

  • 执行健康度：TCSR、平均延迟、错误码分布；
  • 规划健康度：DVR、平均步数、步骤类型分布；
  • 记忆健康度：Entity Recall@5、记忆查询P95延迟；
  • 反思健康度：CU、反思触发率、修正方案采纳率。

• 灰度发布：新版本agent先对5%流量生效，监控仪表盘。若TCSR下降>0.5%或DVR下降>2%，自动回滚。我们曾因一个参数微调，导致DVR从98.2%跌至95.7%，灰度系统在3分钟内完成回滚，未影响用户。

4.7 第七步：持续迭代——建立Agent的“免疫系统”

Agent上线不是终点，而是迭代起点。我们构建了自动化反馈闭环（Automated Feedback Loop）：

• 用户反馈采集：在UI添加“这个回答有帮助吗？”按钮，用户点“否”时，强制填写原因（下拉菜单：步骤错误/信息过时/没解决/其他）。

• 失败自动归因：当用户反馈“步骤错误”，系统自动提取该episode的完整trace（state、action、reward、tool logs），用预训练的根因分类器（BERT微调）打标，归入对应知识库。

• 增量训练触发：每周汇总归因数据，若某类错误（如步骤颠倒）占比超阈值（5%），自动触发增量训练：

  • 从知识库采样100条该类错误样本；
  • 用Stage 3的反思增强模式，只训最后2层网络；
  • 训练后验证DVR，达标则发布。

• 知识库进化：每次增量训练，将新学到的“错误模式-修正方案”对，存入向量DB，供后续LLM-as-Judge参考。知识库不是静态文档，而是agent的“免疫记忆”。

这套机制让我们实现了“越用越聪明”：上线3个月，DVR从93%提升至98.7%，CU从67%提升至89%。用户反馈“步骤错误”类投诉下降76%。

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

5.1 “agent execution terminated due to error.”——不是bug，是设计缺陷的警报

这个报错出现频率最高，但90%的团队只把它当异常处理。我们发现，它本质是执行层契约违反的集中爆发。排查必须按顺序：

1. 查SLA超限：先看tool_call_timeout。我们日志显示，83%的该报错源于OCR service响应超时（>2s）。根源不是OCR模型慢，而是前端没做请求合并——用户连发3条图片，后端发起3次独立OCR调用。解法：在ActionExecutor网关加请求合并（request coalescing），同一批次图片打包成batch infer。

2. 查参数越界：用契约校验日志。曾发现yolo_v11_detect的confidence_threshold被policy network输出为1.2（超出[0.1,0.95]范围），导致YOLOv11 C++ backend崩溃。解法：在skill SDK入口加硬校验，越界则clip并log warning，绝不让非法参数透传。

3. 查依赖缺失：某些错误只在特定环境出现。如db_update报错，本地OK，线上失败。查日志发现线上MySQL连接池耗尽。解法：在契约中明确定义skill的资源依赖（如requires: ["mysql_pool_10"]），部署时自动校验。

实操心得：把这个报错当成“健康体检报告”，每次出现都必须追溯到契约层。我们为此写了自动化脚本，扫描所有报错日志，自动聚类到三类根因，并生成修复建议。

5.2 Reward曲线震荡剧烈——不是算法问题，是奖励设计失衡

很多团队看到PPO的reward曲线像心电图，第一反应是调clip_epsilon或learning_rate。我们发现，95%的剧烈震荡源于奖励量纲不一致：

• 问题：L1执行reward是[-5, +1]，L2感知reward是[0, 1]，L3规划reward是[-1, +1]。当policy network试图同时优化，梯度方向互相撕扯。

• 解法：对每层reward做在线归一化（Online Normalization）。不是简单除以max，而是用running mean/std：

  # 伪代码 reward