凌晨30多个任务级联失败。值班人员需要先查失败原因再判断影响范围、确定处理方式最后检查任务是否恢复。在某业务线的实践中值班 Agent 已经参与这条处理链路扫描失败任务、提取失败特征、匹配知识库针对符合已上架规则和处置条件的 OOM内存不足问题调整内存配置、重跑任务并验证结果。但它并不会对所有失败任务直接动手。没有匹配到处理规则的问题只做诊断交由人员判断。这也是数据平台接入 Agent 后需要解决的一个实际问题查询状态、修改配置、重跑任务都能通过接口完成但什么时候可以调用、调用前检查什么、执行后如何验证需要有明确依据。上一篇我们介绍了 EasyAgent 如何在 EasyData 页面内通过对话辅助搭建任务、排查异常。本篇继续介绍背后的平台改造网易智企·数帆如何通过 CLI、技能和语义知识开放 EasyData 的操作能力以及业务团队如何利用这些能力组织运维与开发流程。夜间任务失败后Agent 如何参与处理这项值班实践有两条相互衔接的流程一条处理故障一条积累经过审核的处理规则。【值班 Agent 的处理流、规则采集流与三类执行检查】处理故障先匹配再决定是否执行值班 Agent 定期扫描失败任务提取失败特征并与知识库中的规则匹配。匹配到已上架规则且满足处置条件时按规则执行修复、验证和通知没有匹配到规则时继续分析日志、整理诊断结论不直接修改任务。前述 OOM 故障就属于按规则处置的场景。Agent 完成批量诊断后按对应规则调整内存配置并重跑再检查处理结果。这里需要区分两个判断找到了可能的失败原因不等于已经具备自动修复的条件。诊断可以为人员提供依据执行修复则还需要明确的规则和授权。执行之前检查范围避免重复处理在这项实践中自动处置还设置了三类检查任务范围自动修复限定在基线及关联任务范围内。在途状态写入前检查是否已有处理正在进行避免并发处置。重复处理同一实例已有处理结论时不再重复处理。处理过程保留记录便于事后核对。这些检查对应的都是日常运维问题任务是否属于本次授权范围是否已有人员或其他流程在处理同一故障会不会被反复触发积累规则处理经验需要审核后才能复用另一条流程负责从异常任务及处理过程中提取失败特征整理候选规则纳入知识库。候选规则经过人工审批上架后才能用于后续故障处理。因此新增经验不会直接变成自动操作。团队先判断规则是否适用再决定是否允许 Agent 按规则执行。对准备建设值班 Agent 的团队这个案例提供了一种可参考的顺序先梳理哪些故障已有明确处置方法再确定自动执行范围对尚未覆盖的问题先保留诊断和人工判断。这些流程如何调用EasyData的能力业务团队能够组织上述流程前提是 Agent 可以查询任务、读取日志、修改配置和跟踪执行结果。EasyData 的 AI 化改造围绕三个部分展开CLI 提供命令技能组织步骤语义知识补充平台用法和业务定义。【EasyData AI化能力架构】CLI让平台操作可以被Agent调用CLI 是命令行工具。EasyData CLI 将已接入的平台 API 封装为命令覆盖查询实例、查看基线、执行 SQL、重跑任务等操作。以故障排查为例Agent 可以通过命令获取实例和日志信息进入处置阶段后再调用相应操作并读取返回结果。原本需要在页面中查找、填写和提交的步骤由此具备了被连续调用的基础。命令根据 Schema 中的接口定义动态生成。Schema 描述接口名称、参数和返回结构。对于符合接入规范且定义已更新的接口CLI 可以通过刷新缓存识别减少新增接口时逐项适配的工作。不过一条命令返回成功只能作为该步骤的执行反馈。任务是否恢复、后续操作能否继续还需要进一步检查。技能写清执行顺序和分支条件同样是“处理失败任务”不同原因可能对应不同操作。流程不能只写“发现失败后重跑”还需要交代先查什么、依据什么选择处理方式、完成后检查什么以及何时停止。这些要求通过技能组织底座技能说明命令用法、参数要求及通用操作约束。场景技能描述开发、运维等工作的处理步骤和判断条件。值班案例中的“命中规则才处置未命中只诊断”就是一项具体的流程要求。规则如何匹配、允许执行什么操作需要由团队结合实际场景明确。技能为 Agent 提供执行依据操作能否执行仍受平台权限、参数校验和相应确认机制约束。语义知识补齐命令本身没有说明的信息接口可以定义参数格式但业务含义和平台用法还需要其他知识补充。例如创建订单汇总任务时“订单金额”是否扣除退款、按下单时间还是支付时间统计属于业务定义选择哪类节点、如何填写调度字段属于平台操作知识。EasyData 从三个方面建设这些知识【三类语义知识及当前建设状态】从故障处理延伸到数仓任务交付运维需要把处理经验写成规则开发则需要把需求、操作步骤和检查要求组织成可执行的流程。“帮我创建一个每天运行的订单汇总任务”就不只涉及生成 SQL。还要确定项目、目录、明确统计口径、创建任务、配置调度依赖与告警并完成发布前检查。端到端交付需要把这些步骤接起来同时保留结果检查和必要确认。创建任务成功后要检查配置进入发布环节前要核对业务逻辑及上线要求。信息不足或检查未通过时先解决问题再继续推进。一项开发实践让新人沿着已有规范完成工作在某科技企业的实践中团队采用 SDD规范驱动开发将数仓开发从需求到上线的流程交由 Agent 推进并在关键节点由人员确认。该实践已在客户生产环境投产。团队根据使用者的经验选择入口有数据开发经验的人员通过本地 AI Coding 工具组织复杂工作非数据团队人员通过 EasyAgent 处理简单需求。对新人而言已有规范可以提供任务步骤和检查要求减少反复查找平台用法、询问操作顺序的工作。业务口径和交付要求仍需明确Agent 则帮助使用者沿着既定流程推进。该团队还将“端到端跑通数据闭环”列为内部 AI 开发认证标准。检验的对象因此延伸到完整任务需求是否落实、配置是否完成、结果是否经过检查以及是否按流程上线。【SDD端到端交付实践】这项实践的参考价值在于把团队已有的开发方法整理成 Agent 可使用的规范。规范越清楚新人越容易找到下一步该做什么团队也更容易检查交付结果。同一套平台能力适配不同工作方式上述实践使用的是 EasyData 开放的调用能力但接入方式可以根据工作需要选择。在页面内处理任务使用 EasyAgent。在已启用 EasyAgent 的 EasyData 环境中用户可以直接对话无需额外安装 CLI。Agent 可利用当前会话中的身份、项目权限和集群上下文辅助查询状态、取数和完成开发配置。组织复杂或批量操作使用本地终端。安装 EasyData CLI、配置访问凭据并加载技能后团队可以在支持命令行工具调用的 Agent 环境中开展工作查看命令输出、组织批处理流程或加载自定义技能。执行周期性工作配置常驻 Agent。团队可以在常驻运行的 Agent 环境中配置定时巡检、诊断和消息推送。进一步执行自动处置则需要配置相应规则、授权范围与执行检查。这里需要区分平台提供可调用的能力业务团队在此基础上配置场景流程。前述值班和开发案例包含团队自身的规则与规范并不意味着启用入口后就自动具备全部案例能力。让流程跑起来也要能检查和停止从查询任务到修改生产配置操作的影响范围不同执行要求也应明确。身份与权限要对应。Agent 应在已授权的项目和操作范围内工作。本地 CLI 的访问凭据需要妥善管理身份认证通过并不代表所有操作都获准执行。缺失信息不能用猜测补齐。项目、集群、任务对象或必填参数无法确定时应先查询或向用户确认不能使用示例值替代真实配置。敏感操作要落实确认要求。终止实例、删除任务等操作需要依据敏感度标记及相应执行流程处理。前述案例中的规则审批、任务范围检查也应与实际操作权限配合。执行结果要能核对。用户需要知道操作对象、执行依据、当前状态以及哪些步骤等待确认。CLI 对相关输入、路径参数和终端输出的处理则与其他机制共同降低异常输入和输出带来的风险。对团队来说验收一条 Agent 流程时除了检查正常情况下能否完成也需要检查信息不全时如何处理、执行失败后如何继续、超出授权范围时能否停止下一步连接更多工作环节目前EasyData 的 AI 化主要围绕数据开发、任务运维和自助分析展开。后续将继续推进三方面建设扩展工作流程。逐步衔接数据源登记、传输任务创建、模型设计、数据标准与数据服务发布等环节。扩展主动检查。从被动响应走向主动发现探索元数据缺失、落标异常、监控配置及分类分级等方面的检查与建议。丰富语义知识。不断补齐表、指标、字段、血缘之间的知识图谱持续沉淀指标口径与术语映射为 Agent 理解任务提供依据。从值班运维到数仓开发Agent 能承担多少工作取决于可调用的能力也取决于流程、知识和执行条件是否明确。已知故障按经过审批的规则处理新问题交由人员判断开发需求沿着团队规范推进新人也能获得必要的操作指引。EasyData 将继续完善这些基础让 Agent 参与更完整的交付过程也让人员更容易检查结果、处理异常和积累经验。