# 合作方只核验一个结果，就给他一个核验操作 | EasyNet

Source: https://easynet.run/cases/problems/partner-result-verification

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

# 合作方只核验一个结果，就给他一个核验操作

合作方想知道交付包是否通过约定检查，团队却只能给后台账号。账号里还有其他项目、修改按钮和批量导出。对方要的只是一份当前核验结果，给后台既增加风险，也让他先学会在哪里找答案。

一次确认，发经过核对的静态报告最简单。已有客户门户支持受限查询，就继续用。交付会持续更新、不同合作方要重复查，而检查程序已经在内部运行时，才值得接出一个独立操作。

提供方可以写按交付标识查询的函数，返回检查时间、规则版本、通过项、失败项和未检查项。通过 EasyNet 接入后，合作方使用获准身份调用；输入不接受任意 SQL，输出也不包含后台其他项目和原始敏感附件。

对象级范围必须在适配器中校验。合作方替换另一个交付标识时应被拒绝，不能只依赖网页隐藏入口。访客身份、期限、查询页面和结果过滤仍需要团队接好，函数存在不代表已经有完整合作门户。

规则更新后，旧结果应保留其依据，不自动改成新规则下已通过。调用完成证明检查程序结束，不证明交付物符合双方约定；具体规则由业务维护者测试，是否接受交付仍由合作流程决定。

先用两份不同合作方的测试交付验证允许和拒绝，再更换规则版本看旧结果是否清楚。对方最终能够自己回答“我的交付还差哪一项”，团队也不再为一个查询分发整套管理界面。

01

合作方提交编号

按实际身份确认归属

02

运行获准检查

固定规则版本与范围

03

返回检查清单

通过、失败、未检查分别列出

只回答这份交付的检查结果，保留未检查项。

交付检查结果形状

合成输出数据，不代表真实交付已通过。调用方归属和规则执行需要由实际服务验证。
示例内容 · json

```
{
  "delivery": "demo-package-17",
  "rule_version": "print-v2",
  "checked_at": "2026-09-07T09:00:00Z",
  "passed": ["page-size"],
  "failed": ["missing-font"],
  "unchecked": ["legal-approval"]
}
```

预期结果：能看见缺失字体和未做法律审查；不能把一次结果概括成全部通过。

接入时的检查项

合作方能否完成核验而无需后台账号。

替换交付标识是否被真实拒绝。

结果是否明确注明规则版本、时间和未检查范围。

源码与接入资料

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

[只返回需要的摘要，不带出原始记录](https://easynet.run/cases/data-resident-ai)

[MCP 官方：授权规范（2025-11-25）](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)