Coinbase AgentKit：给 Agent 接上工具，也要接上授权边界

客服助手可以查看订单、解释退款规则。一旦让它直接退款，系统的性质就变了：根据客户消息生成的动作，可能真正转走资金。Coinbase AgentKit 提供 Agent 与链上操作之间的连接，产品团队仍需决定，哪些操作根本不应该交给模型自由调用。

资料边界： 本文于 2026 年 11 月 1 日核对官方仓库与文档。下文退款流程是建议架构，没有安装 SDK、创建钱包或执行转账。

三个组件，三种职责

TypeScript 参考文档区分 wallet provider 与 action providers：前者提供钱包能力，后者暴露查余额、转代币等动作。框架适配层再把这些动作变成 Agent 可以选择的工具，LangChain 扩展就是其中一种接法。

已有钱包服务的团队，可以利用这种拆分。但“AgentKit 支持某钱包”还不算完整方案，需要一起核对包版本、提供方、网络和具体动作。自动生成的 API 文档与仓库示例可能属于不同版本，应固定实际验收过的组合。

对于退款助手，如果工具只接受一个已经批准的退款单号，就没有必要暴露任意转账接口。应用从自己的订单记录解析收款地址和金额，让模型提出业务请求，而不是自由拼出交易参数。

在钱包前面放一道真正的审批边界

退款方案概念示意，并非 AgentKit 内置审批流程，也不是支付实测。

仓库风险说明明确指出，AgentKit 本身不要求人工批准转账，不强制支出上限，也不提供收款地址白名单。外部文本与资金操作工具结合，还会产生提示注入风险。接入钱包 SDK，不能作为已经建立授权策略的证据。

在这里提出的方案中，订单服务独立检查退款资格和金额，不依赖 Agent 自己的解释。审批应绑定到具体退款请求；之后如果工具调用更换收款人或金额，旧审批就不能继续生效。这些是应用要求，并非 AgentKit 自动提供的功能。

钱包归谁控制，决定了谁能叫停

钱包提供方可能连接不同账户模型。例如，CDP 账户文档区分用户钱包与服务器控制的 API Key 钱包，也区分 EVM EOA、智能账户和 Solana 账户。“Agent 有一个 Coinbase 钱包”会掩盖这些重要差别。

服务器控制的退款钱包，与需要用户授权的钱包，给运营方带来的责任并不相同。应该记录资金归属、哪项服务能签名、管理员能撤销哪些凭证，以及 Agent 进程被攻破后还有什么恢复路径。签名凭证不应进入模型上下文，也不应作为工具结果返回。

付款工具需要返回可对账的结果

对支付动作而言，交易哈希只是开始。订单系统需要区分：拟议调用、提交已受理、链上成功，以及执行失败。Agent 给客户的自然语言答复，应当来自这些结构化状态。

建议验收场景	产品应有的表现
客户消息里夹带新的收款地址	仍使用核验过的订单记录
两个工作进程收到同一退款请求	只授权并核对一笔业务退款
提交后钱包接口超时	先查询旧尝试，再决定是否重试
管理员暂停退款	新签名请求在执行边界被阻止
查余额任务遇到提示注入	无法调用本来就没分配的支付工具

这些是团队应实现的检查，不是本文已经跑出的测试结果。它们让“自主 Agent”变成可以审核的业务约定。

哪些团队适合继续研究

如果团队希望自行组合 Agent 框架、钱包和链上动作，AgentKit 值得评估；但权限、恢复、回执和运行限额仍有不少产品工程工作。希望直接使用完整钱包体验的团队，可以另外查看 Coinbase Agentic Wallets。同一家公司提供的两个产品，不能互相替代概念。

对退款助手，一个合理的起点是只读接入，再增加受审批约束的测试网动作。验证一条业务流程，并不需要一次性开放整套资金工具。相关资料见 AgentKit 目录页与钱包额度设计。