AI代理工具这半年有个很明显的变化，不再满足于“帮你做事”，而是开始尝试“替你完成交易”。边界一旦从信息处理跨到资金流动，整个系统的设计逻辑就会换一套算法。
Hermes Agent这次更新的重点不在界面，也不在模型能力，而是一个更底层的变化：分发工具（delegate tool）开始支持异步子代理，同时把支付能力直接接进任务执行链路。
表面看是效率优化——子代理运行时，主对话可以继续推进，不再被阻塞。但真正的变化在另一层：代理不再只是“执行指令”，而是可以在任务流程中触发支付动作。
安装方式也很直接，hermes skills install，然后进入一组预置支付技能。这里没有复杂的配置流程，更像是在给代理系统装插件，但插件的能力已经越过了传统API调用的范围。
三组Stripe相关能力被拆得很细：
stripe-LINK-cli，偏向网页购物场景，更多是消费行为入口；
mpp-agent，按次计费API调用，有点像把微支付嵌入工具链；
stripe-projects，面向SaaS订阅，直接覆盖持续性服务结算。
这三层结构其实对应了三种典型商业模型：电商、API经济、订阅服务。Hermes没有重新发明支付，而是把已有支付模型拆进代理执行流里。
Stripe在这里的角色更像基础设施提供者。它原本是“交易完成之后”的结算系统，但在代理架构里，被提前到了“任务执行过程中”。也就是说，支付不再是结果，而是过程的一部分。
这种变化带来的体验差异很直接。过去用户需要在不同应用之间切换：调用工具、确认费用、再执行支付。现在代理可以在后台异步运行任务，同时在需要的时候插入支付节点，用户只需要做确认动作，甚至可以预设限额。
为了避免风险扩散，系统做了几个比较克制的设计：临时交易凭证用完即清理，主凭证不写入对话日志，所有支付必须人工审批，并且支持额度控制。看起来像是传统风控逻辑，但被嵌进了代理执行流。
这个设计有点像在AI系统里复刻“企业财务审批链路”，只不过审批对象从报销单变成了API调用和任务执行。
更值得注意的是“异步子代理”的加入。它解决的不是性能问题，而是结构问题——代理可以在后台跑多个任务，而用户不必持续盯着执行过程。这种设计在复杂工作流里很关键，尤其是当任务开始涉及外部付费服务时。
从行业角度看，这类能力正在把AI代理推向一个更现实的方向：从“自动化工具”转向“可交易的执行系统”。一旦支付被嵌入执行链路，代理就不再只是生产效率工具，而是可以直接参与商业行为的节点。
这和早期API经济有一点相似，但方向更激进。API时代是“调用即服务”，现在变成“执行即支付”。
问题也随之出现：当代理可以自动触发付费行为，权限边界如何定义，责任归属如何划分，这些都还停留在工程实现层，而不是制度层。
Hermes的方案目前选择了保守路线——人工审批 + 限额控制 + 临时凭证清理。但结构已经打开，后续演化空间并不小。
代理系统一旦进入支付链路，工具与金融之间的边界会变得不那么清晰。效率提升只是表层变化，更深层的问题是：谁在控制“执行权”，以及执行的成本如何被实时计价。
