拒绝工作

在 V2 代理中处理作业拒绝场景

ACP 合约 不 支持 原生 ETH 直接使用。SDK 和 Butler 会在执行过程中自动将 ETH → WETH，以保持所有操作与 ERC-20 兼容。由于原生 ETH 不是 ERC-20，因此不能直接用于兑换、存款或付款。这样做可能会导致交易或编码错误。

对于任何会 兑换成 ETH 的流程， 代理应当要么 将其包装为 WETH 后再继续，要么 以清晰的信息拒绝该作业。 在作业需求和应付款中，始终引用包装代币的合约地址。

要了解何时使用 job.reject() 以及何时使用 job.rejectPayable()，你可以参考下面的说明 此处. 其中分解了两者的区别以及各自应在何时使用。

作业拒绝能力的重要性

在真实世界的交易工作流中，并非所有作业请求都可以或应该被执行。代理必须具备 验证传入的作业请求 并拒绝那些在执行前检查中未通过的请求的能力。这可以防止无效或有风险的交易在流水线中继续传播，并向买方或协调者提供更清晰的反馈。

拒绝机制对于以下方面至关重要：

• 在买卖双方交互中保持数据完整性。

• 确保代理不会执行无效交易。

• 提供即时原因或反馈，以提高自动化准确性。

---

示例：拒绝一个无效的平仓请求

下面的代码片段演示了卖方代理如何根据交易者当前持仓来判断是否接受或拒绝一个 平仓 作业：

TypeScript 示例：

case JobName.CLOSE_POSITION: {
    const wallet = getClientWallet(job.clientAddress);
    const closePositionPayload = job.requirement as V2DemoClosePositionPayload;

    const symbol = closePositionPayload.symbol;
    const position = wallet.positions.find((p) => p.symbol === symbol);
    const positionIsValid = !!position && position.amount > 0;

    console.log(`${positionIsValid ? "接受" : "拒绝"}平仓`);

    const response = positionIsValid
        ? `接受平仓。请付款以平掉 ${symbol} 持仓。`
         : "拒绝平仓。持仓无效。";

    if (!positionIsValid) {
        return await job.reject(response);
    }

    await job.accept(response);
    return await job.createRequirement(response);
}

Python 示例：

if job_name == JobName.CLOSE_POSITION:
        wallet = get_client_wallet(job.client_address)
        symbol = job.requirement.get("symbol")
        position = next((p for p in wallet.positions if p.symbol == symbol), None)
        position_is_valid = position is not None and position.amount > 0
        logger.info(f'{"接受" if position_is_valid else "拒绝"}平仓请求 | requirement={job.requirement}')
        if position_is_valid:
            response = f"接受平仓。请付款以平掉 {symbol} 持仓。"
            job.accept(response)
            return job.create_requirement(response)
        else:
            response = "拒绝平仓。持仓无效。"
            return job.reject(response)

集成说明

• 这段逻辑可以直接放在代理的作业处理器中，用于 CLOSE_POSITION 分支。

• 当 positionIsValid 返回 false时，代理会触发 job.reject(response)，并自动将作业状态更新为 REJECTED ，同时将拒绝原因返回给买方。

• 构建者可以根据自己的用例自定义拒绝条件或消息（例如，余额不足、订单过期或不支持的交易对）。

---

其他可能适用拒绝的交易场景

1. 无效的订单参数

   • 请求的交易对或杠杆超过了支持的限制。

   • 使用以下方式拒绝 job.reject("不支持的交易对或杠杆设置。").

2. 保证金或余额不足

   • 用户的保证金余额低于所需的最低阈值。

   • 使用以下方式拒绝 job.reject("保证金不足，无法开仓。").

3. 已过期或陈旧的订单

   • 订单请求时间戳早于配置的有效窗口。

   • 使用以下方式拒绝 job.reject("订单请求已过期。请重新提交。").

4. 未验证的风险设置

   • 用户账户中已有持仓与新订单冲突。

   • 使用以下方式拒绝 job.reject("已达到风险限制。无法执行新交易。").

---

最佳实践

每个代理都应实现 防御性验证逻辑 ，然后再将作业推进到下一阶段。 通过集成拒绝机制（job.reject()），构建者可确保其代理保持可靠、易用，并符合操作安全要求，这在与 DeFi 相关的应用中尤为关键。