つい先ほど、私の仲裁 Agent が連続して 2 つの実際の仲裁ケースを処理しました。両方とも同じ方向の紛争です。

タスクタイトル：XLayer Top5 DeFiレポート
タスク報酬：0.1 USDT

この 2 つの案件は現在、両方とも commit 投票を完了しており、次の reveal 段階を待っています。

今回も、仲裁 Agent が実際にどのように動作するかを完全に検証しました。

システムがまず私の Agent を仲裁席に選出する。
ローカルで動作する evaluator agent が evaluator_selected イベントを受信する。
自動で紛争証拠を取得する（双方が提出した説明と添付ファイルを含む）。
デフォルトの仲裁ルール + 私がインストールしたドメイン補足 Skill に従って、証拠チェックとスコアリングを実行する。
完全な裁定理由を生成し、vote-commit をオンチェーンで提出する。
システムが reveal_started に入るのを待ち、その後ローカルエージェントが reveal を実行する。

これら 2 つのケースにおいて、私の Agent は最終的に同じ結論を出しました。

vote = 1

つまり：仲裁申請を却下し、Provider / ASP の勝訴を支持する。

なぜそう判断したのか？

ケース 1
Client の主な異議は：レポートが「十分にリアルタイムではない」というもの。
しかし Agent が確認したところ：

タスク要件は、HTML 形式の XLayer Top 5 DeFi 分析レポートを納品すること。
要件には「リアルタイムでなければならない」や「納品当日のスナップショットでなければならない」とは明確に書かれていなかった。
双方が提出した HTML ファイルの内容は一致していた。
Client は、「非リアルタイム」がタスクの明示的な要件に違反していることを証明する、十分に検証可能な証拠を提供していなかった。
したがって Agent の判断は：

納品は満点ではないものの、全体的に仕様を満たしており、スコア 89.2/100、Provider を支持する。

ケース 2
Client の主な異議は：納品が遅延し、投資のタイミングに影響を与えたというもの。
しかし Agent が確認したところ：

実際に納品されたファイルは完全で読み取り可能な HTML レポートだった。
双方が提出したのは同一の成果物だった。
「遅延」という主張はあったが、十分に明確で検証可能な期限の証拠はなく、検査不合格と判断するには至らなかった。
納品内容自体は「HTML + コアデータ + 比較分析 + 結論と推奨事項」の主要要件を満たしていた。
したがって Agent の判断は：

遅延の主張は証拠不十分、スコア 84/100、引き続き Provider を支持する。

私の考えでは、この 2 つのケースは非常に代表例です。なぜなら、次のことを示しているからです。

仲裁 Agent は「誰がより大声で言うか」だけを見るのではなく、以下を確認します。

タスク仕様が明確に書かれているかどうか
証拠が検証可能かどうか
紛争点がファイル、スクリーンショット、成果物そのものによって裏付けられているかどうか
一方的な口頭による主張が実際に成立するかどうか

つまり、Agent の仕事は「直感で味方する」ことではなく、紛争を次のように分解することです。

仕様 -> 証拠 -> 判断 -> スコア -> 投票

これが、私が先に Agent にドメイン補足 Skill を追加した意味でもあります。

プラットフォームのルールを変更するのではなく、実際の案件で Agent が証拠をより安定して判断し、問題を特定し、スコアリングを完了できるようにするためです。

原文表示