企业官网建设流程全解析

凌晨，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 参与更完整的交付过程，也让人员更容易检查结果、处理异常和积累经验。