🎯 目标
超出内置操作范围：让 Agent 预览并执行你自己构造的合约调用，以及生成 EIP-712结构化数据签名——每一步动作之前都有模拟执行、风险检查和一次明确的确认。
✅ 前置条件
- 已安装 Agentic Wallet 并完成登录。
- 已在 Binance App 中开启开发者模式。 这个开关无法由 Agent、CLI 或网页端打开——这是有意为之的设计。
动手之前先确认当前状态：
"我的钱包开启开发者模式了吗？"
Code
查看 devMode.enabled。如果是 false，请到 Binance App → Agentic
Wallet 管理页 → 设置中开启，然后再问一次。在接进脚本之前，有四个字段值得先读一遍：
| 字段 | 含义 |
|---|---|
devMode.enabled | 当前是否允许外部签名 |
devMode.expiresAt | 开发者模式的过期时间（Unix 秒）；未开启或已过期时为 null |
devMode.dailyLimit | 外部签名在 24 小时内的额度上限 |
developerModeQuotaUsed | 今天已消耗掉的额度 |
这是一个独立额度池。 开发者模式的花费独立于主
dailyLimit，也独立于预测市场、DeFi 和x402 的额度——既不消耗它们，也不受它们限制。查开发者模式用量请读developerModeQuotaUsed，不要读defiQuotaUsed或quotaUsed。
开发者模式改变了什么、没改变什么
默认情况下，Agentic Wallet 只执行经过端到端验证的能力——兑换、转账、限价单、预测市场、代币化证券、DeFi——不签署也不发起任意交易。这是一个安全设计选择，而不是尚未实现的功能，理由见仅支持经过验证的能力。
开发者模式是唯一的例外，而且刻意做得很窄。
开启后新增的能力：
- 你自己构造的任意合约调用——EVM 的
to+ calldata，或 Solana 的未签名交易。 - 对你自己构造的数据做 EIP-712 结构化签名，例如 Permit 与 Permit2。
不会改变的部分：
| 边界 | 是否仍然生效 |
|---|---|
| 独立额度 | 外部签名走开发者模式专属的每日限额，在 App 内配置 |
| 时效限制 | 开发者模式会过期（devMode.expiresAt），需重新在 App 内开启 |
| 风险拦截 | 被判定为高风险的操作会被直接拦截，你连确认的机会都没有 |
| 私钥托管 | 密钥基于 MPC Keyless，无法导出——不存在在钱包之外签名的途径 |
| 两步确认 | 每一次合约调用和签名都必须先预览、再明确确认 |
开启开关只存在于 Binance App 内——Agent 无法自行开启开发者模式，这也是在你把它接进脚本之前，前置条件那一步自查为什么重要。
支持的签名类型
开发者模式扩大了 Agent 的能力范围，但并不会降低安全底线。消息签名依然限定为可解析、可在你确认之前完整展示给你的结构化数据：
| 签名类型 | 方法 | 是否支持 |
|---|---|---|
| EIP-712 结构化数据 | eth_signTypedData_v4 | ✅ 支持 |
| EIP-191 纯文本消息 | personal_sign / eth_sign | ❌ 不支持 |
sign-message 只接受 --signType EIP712，且 --message 必须是一个完整的 eth_signTypedData_v4
JSON-RPC 请求——不能是纯字符串，也不能是预先哈希过的摘要。
为什么只支持结构化数据。 EIP-712 自带 schema——domain、types 以及被授权的具体数值——所以 preview 能把你真正授予的 spender、额度和有效期展示出来。而 EIP-191 纯文本消息完全没有结构：无论是你还是 Agent，都无法核实这个签名最终会被用在什么地方，而这恰恰是盲签攻击所依赖的特性。由于 Agent 在签名时不会有人逐条检查待签内容，这类请求不被允许。
这在实际使用中意味着什么
相当多的第三方流程要求你签一段纯文本消息，而不是结构化数据。常见的有：
- "Sign in with Ethereum" 这类登录和 dApp 会话认证
- 通过签一句话来验证地址归属的空投、奖励、积分领取流程
- 白名单或活动报名
这些用的都是 EIP-191 personal_sign，无法通过 Agentic Wallet 完成。
即使产生这份奖励的操作本身就是通过 Agentic Wallet 做的也一样——例如你通过 DeFi
流程提供了流动性或参与了质押，之后该协议要求你签一条消息来领取分发。
由于密钥无法导出，这个签名也无法用同一个地址在别处完成。
两步安全流程
开发者模式下的每个操作都被刻意拆成两步。Agent 会：
- 执行 preview——解析操作、模拟执行、返回风险信息。
- 向你展示解析后的交易或消息、
risks，以及即将授予的任何权限。 - 等待你明确确认。
- 用该次 preview 返回的
requestId执行 execute。
preview 报错时不会返回
requestId，也就无法 execute。preview 还有有效期——如果 execute 提示 preview 已过期，重新 preview 一次即可。
合约调用
"帮我预览一笔调用 BSC 上 0xTargetContract 的合约调用，calldata 是这个"
Code
| 参数 | 必填 | 说明 |
|---|---|---|
--binanceChainId | 是 | 例如 56（BSC）、1（以太坊）、CT_501（Solana） |
--from | 是 | 你在该链上的 Agentic Wallet 地址——服务端会校验归属 |
--to | EVM 必填 | 目标合约地址 |
--value | 否 | 原生代币数量，单位是 wei，不是可读金额。只接受整数，小数会被拒绝 |
--inputData | 否 | EVM calldata，默认 0x |
--unsignedTx | Solana | base58 编码的未签名交易，替代 --to / --inputData |
不要传 gas 参数。
contract-call不接受 gas limit、gas price 或任何 gas 选项。preview 直接模拟，execute 使用后端的 gas 估算。
然后用返回的 requestId 执行：
Code
怎么读结果：
status: BROADCASTED——已签名并广播，用返回的txHash追踪链上状态。status: PENDING_CONFIRMATION——需要你在 Binance App 里确认后才能完成。- preview 里的
requireConfirmation会提前告诉你会走上面哪一种。 parsedTx.amount是最小单位。展示给人看之前，要先除以tokenInfos里该代币的decimals。
如果 preview 被拦截，会返回错误且没有
requestId——该操作被判定为高风险，在你确认之前就被拦下了。这种情况下没有可执行的对象，具体原因见错误返回体。
消息签名
"帮我预览这个 EIP-712 签名请求"
Code
params[0] 必须是你自己的 Agentic Wallet 地址；params[1]
是以 JSON 字符串形式传入的 EIP-712 结构化数据（domain、types、primaryType、message）。
Code
成功时返回 status: COMPLETED，附带 signature 和 signatureRecovery。如果返回
PENDING_CONFIRMATION，请在 App 内确认后再获取结果：
Code
REJECTED 或 EXPIRED 意味着不会产生签名。
Permit 与 Permit2： 这类签名授予的是花费权限，不只是一个签名。确认之前，请从
parsedMessage中读清spender、sigDeadline以及details[]里的每一项（代币、额度、有效期）——那才是你真正在授权的内容。
签名历史
"看一下我最近的消息签名记录"
Code
返回历史签名，包含 signatureTime、messageType，以及 Permit 类消息的
spenderAddress、tokenPermits 和
signatureDeadline。可以用它审计钱包在过去授予过哪些权限。授权的查看与撤销另见
安全与设置。