# 把任务交出去前，先知道这个 Agent 还有没有人维护 | EasyNet

Source: https://easynet.run/cases/problems/agent-maintenance-status

[easynet.run · 全部问题场景](https://easynet.run/cases#problem-scenarios)

# 把任务交出去前，先知道这个 Agent 还有没有人维护

项目负责人从目录里选了一个资料整理 Agent，介绍很完整，任务交出去后才发现它依赖的账号已经失效，原维护者也换了项目。能搜到一个名字，和今天能把工作交给它，是不同的事情。

只有几个助手时，服务清单加定期检查已经有效。成熟服务目录也能保存负责人和退役状态。需要统一看跨设备能力时，可以把维护事实附着到 EasyNet 的发现入口，但不要再发明一个无法解释的可信分数。

维护者应提供当前负责范围、联系入口和最近验证的具体任务。目录存在、网络可达、一个业务样本成功、有人负责处理失败，应分别呈现。Runtime 返回的执行状态可以支撑其中一部分，不能替代完整健康检查。

小型探测操作只接受无副作用的测试输入，返回能核对的结果与版本。维护流程保存检查时间和失效原因，不把客户真实附件塞进公开探测。探测身份能做什么也要受限，不能为了检查而拥有全部用户权限。

还需要负责人交接、检查周期和无人认领后的处置规则。已失效入口可以提示不接受新任务，但运行中的工作必须留下处理责任；从目录隐藏不能被当作旧任务已经取消。

试着断开上游依赖，确认页面不会因为进程仍在线就显示一切正常；再完成一次维护人交接。使用者最后看到的应是“哪件事在什么时候被检查过、现在找谁”，而不是一个让人无从追问的绿点。

01

目录找到入口

说明它负责哪项工作

02

看具体检验

时间、样本和失败原因

03

确认维护责任

失败后知道找谁

在线、样本通过、有人维护，是三件不同的事。

一个绿点解释不了这些事实

合成维护记录，不是现成健康检查 API；检查时间和负责人应由真实流程维护。
示例内容 · json

```
{
  "operation": "organize_documents",
  "network_reachable": true,
  "last_business_probe": {
    "checked_at": "2026-09-07T00:00:00Z",
    "sample": "synthetic-two-documents",
    "status": "failed",
    "reason": "upstream account expired"
  },
  "maintainer": "document-operations-team",
  "accepting_new_work": false
}
```

预期结果：网络可达也明确不接新任务，原因是上游账号失效；不把进程在线当业务健康。

接入时的检查项

失联 Agent 是否仍被误显示为可立即使用。

每项关键能力是否有明确维护责任。

探测通过但业务失败时能否展示两种不同事实。

源码与接入资料

[设备接入指南](https://easynet.run/docs/connect/runtime)

[函数接入指南](https://easynet.run/docs/connect/function)