AI Agent自主下单,合同责任到底谁承担?

AI Agent自主下单引发的合同责任,取决于任务启动、权限范围、授权边界与后续行为的完整链条。
当AI Agent自主完成采购并引发争议时,"这不是我亲自下的单"并不能自动免责。文章通过三层问题拆解——合同是否成立、交易能否归责于使用者、能否撤销及损失由谁承担——提供了系统性分析框架。核心判断标准在于:使用者是否主动启用Agent、开放了哪些权限、交易是否超出预设范围,以及后续行为是否构成对交易结果的接受。系统错误或外部攻击场景下,企业对外承担合同责任与企业内部向技术服务商追偿是两个独立层面,不可混淆。文章最后指出,表见代理问题——交易相对方能否主张"有理由相信Agent有权限"——是这一议题更深层的法律难题。
一个正在发生的真实场景
设想这样一个情况:你给AI Agent设定了任务——帮你比较价格、选择供应商,并在预算范围内完成采购。Agent自主搜索商品、与商家沟通,最终提交订单完成计划。但具体买了哪一款、以什么价格成交,你在事前并不知情。等货送到手上,你发现这并不是自己想要的东西。
于是问题来了:你能否主张"这不是我亲自下的单,不是我真实想买的东西,所以合同不应该由我承担"?
这类由AI Agent在生产环境中自主完成采购的公开案例目前还很少,很难给出一个适用所有商品的标准答案。但基于现有的法律规则,我们仍然可以对这一场景进行系统性分析。
首先需要明确一个基本前提:AI本身不是民事主体,也没有独立的意思表示能力。合同的一方通常仍然是使用Agent的个人或企业,而不是Agent本身。电子商务规则已经承认,当事人使用自动信息系统订立或履行合同,相应行为可以对使用系统的一方产生效力。这条规则至少为AI Agent交易提供了一个分析的起点。

合同成立、归责与撤销:三层问题拆解
面对AI Agent下单的争议,不能笼统地看待,而要把问题分层拆开。
第一层:合同到底有没有成立
系统发出的订单,是否构成了一项明确的交易表示,而对方是否已经接受?如果账号在交易平台上完成了下单和确认流程,从形式上看合同可能已经成立。
第二层:交易能不能归到使用者身上
合同即使成立,还要判断能否归责于具体的个人或企业。这就要看发出订单的账号权限和任务,究竟指向谁。
第三层:交易成立后能否撤销、损失由谁承担
这一层最为关键,也最容易被混淆。Agent选错商品、价格判断失误、账号受到攻击——这些是完全不同的原因,不能因为它们最后都表现为"AI下错了单",就套用同一个结论。

过去的自动收货、自动补货、程序化交易,通常是按照预先写好的条件运行的。而今天的AI Agent多了一层自主性:用户只需交代目标和边界,具体的商品、价格、交易时间都由Agent在执行过程中自行选择。但"事前不知道最终结果",并不等于"最终结果一定与自己无关"。
归责的核心:使用者是否交出了交易过程
如果一个人主动启用了AI Agent,为它开放账户、开放支付、开放权限,允许它在一定范围内自行选择,那么判断的重点就不在于"Agent自己想不想买",而在于使用者是否已经把形成交易结果的过程交给了这个系统。
这个判断可以从四个方面展开。
谁启动了任务
是用户主动要求采购,还是系统在没有指令的情况下自动运行?是公司正式部署的采购Agent,还是员工为便利工作私下接入的工具?任务的起点会直接影响行为能否归到个人或公司头上。
Agent实际获得了什么权限
如果Agent只有搜索和推荐能力,最终仍需人来确认,那么推荐本身通常不构成下单;但如果它的权限已经能调用企业账号、数字证书或支付接口,直接向外发送订单,那么其外部交易的法律分量就完全不同了。
交易有没有超出预设范围
商品类别、供应商名单、条件、风险限制等,是否都在授权范围内?如果使用者只是不满意结果,就用"不是我亲手操作"来否认整个交易,这个理由恐怕并不充分。
交易结果有没有被后续行为接受
这一点常被忽略却极其重要。如果买家收到通知后没有提出异议,甚至收货、使用商品,或继续要求供应商履行义务,这些行为往往说明他实际上接受了这个交易。相反,如果系统刚发出订单,企业立刻叫停支付、截止发货,那么这种行为也会影响对合同状态和损失范围的判断。

系统错误与外部攻击:责任的两个层面
如果AI Agent因为系统错误、外部攻击或权限配置异常,做出了明显偏离任务的行为,问题会重新回到授权范围、业务撤销、平台责任和安全管理等维度。即便如此,也不能只盯着最终数据下结论。
举个例子:用户要求采购办公电脑,Agent却因为网页中的隐藏指令去购买了高价商品。这时需要继续区分——交易对方是否知道订单明显异常?平台有没有识别或拦截异常调用?企业有没有把支付权限开放得过宽?供应商是否违反了约定的安全标准?
这里有一个关键区分:外部交易是否约束企业,与企业内部最终由谁承担损失,是两个不同层面的问题。即使企业最终需要向供应商承担合同责任,也不意味着损失只能由企业自行消化。企业还可以依据采购系统合同、技术服务协议、员工管理制度或网络安全事件责任,继续向平台、技术供应商或相关责任人追偿。

实务中如果把这两个层面混为一谈,企业很容易把"系统有故障"直接当成对抗供应商的理由,同时忽略了对技术服务商的违约追责。
重大误解与证据保存
这类场景还可能涉及"重大误解",但重大误解不能被简单理解为"AI选得不好"。如果商品价格或数量都在授权范围内,只是模型没选到最优方案,这通常更接近商业判断,不影响合同效力。只有当交易内容与部署者原本设定的意思出现重大偏离、且相对方相应可预见时,才有讨论撤销的空间。所以能否撤销,仍要结合错误来源、相对人状态和个案证据来判断。
最后,这类场景对证据保存提出了很高要求。指令、权限、授权证据、调用的工具、账户与供应商之间的完整沟通信息、订单与付款过程、最终的通知或处置记录——这些都需要完整保存。如果不保存真实的执行过程,一旦发生争议,很难说明系统为什么做出这样的选择、到底哪里出了问题,责任划分自然也就难以判断。
从结果回到过程
AI Agent自主下单带来的责任难题,本质上要求我们从"最终结果"回到"任务、权限和控制范围"的完整链条去判断归责。谁启动了任务、开放了多大权限、是否超出授权、后续有没有接受结果——这些事实共同决定了责任的归属。
下一步值得追问的是:如果AI Agent超出了内部授权,而交易相对方却声称"有理由相信它有权限",这种情况能否直接适用表见代理?这将是自动化交易法律责任讨论中更进一步的难题。
相关推荐

Treebar:Mac菜单栏管理Git工作树,一眼掌控所有AI编程Agent
Treebar是一款macOS菜单栏应用,专为AI编程多工作树场景设计。它将所有Git Worktree状态统一展示在MacBook刘海区域,让开发者实时监控Codex等AI Agent的工作进度,无需切换终端即可掌握全局。即将开源核心代码。

苹果确认Hide My Email域名永久保留,用户隐私获长期保障
苹果公司公开承诺iCloud+ Hide My Email功能使用的@icloud.com域名将永久保留,不会弃用或迁移。本文解析域名稳定性对邮箱转发隐私工具的关键意义,以及对用户账户安全的底层保障。

终端正在拖慢你:多任务时代的效率反思
终端是程序员的信仰工具,但在多任务并行的现代开发场景中,它的线性设计正在成为效率瓶颈。本文分析终端的心智负担模型为何在第六个任务时崩溃,以及开发者该如何重新评估工具选择。