AI助手把卖价报低了,问题只是模型不够聪明吗?

Matt Robb请AI助手Muse帮忙在Facebook Marketplace卖东西，也交代了最低价。但在其中一件商品的议价中，助手却向买家表示，他可以接受比底价低100美元的价格。

这件事出自美联社（AP）记者Wyatte Grantham-Philips的个人Agent使用与隐私报道。Meta向记者承认了定价错误，没有进一步解释。报道未证明商品最终按低价成交，也没公开足以定位故障的完整执行记录。

我会把这笔代办交易分开检查：助手有没有权跟买家说话，发出的价格是否符合条件，最后卖得是否合心意。三个要求，都关系到能不能放心交出去。

这篇文章把报价个案与两家开发方公开的安全设计对读，再用一次模型升级的实际变化，检查哪些问题值得期待模型进步，哪些还需要其他办法。

能发消息，不等于价格就符合要求

Muse并非没有独立的权限机制。Meta在《How We Built Safety Into Muse》中介绍，主Agent运行在隔离环境里，名为Sentinel的服务在环境之外决定动作是放行、拒绝，还是交给人确认。主Agent不能改写这些决定。

人通过独立界面给出的批准直接进入Sentinel。授权可以只用一次，也可以覆盖一项任务或更长时间，要看批准的范围与期限。

所以，获得了“替我联系买家”的许可，只说明某类沟通可以进行。某一句承诺有没有违反底价，还要检查消息里的交易条件。公开报道不足以判断，这次错误是模型误解、条件没传到检查处，还是其他环节出了问题。

OpenAI在9月29日发布的Dots安全说明里，也没有把控制全部交给主Agent自觉遵守。后台主动研究只能读取获准来源、留下私有笔记，限制由代码执行；它不能直接发消息、修改连接应用里的内容或操控浏览器。

Dots发送邮件、修改文件等动作，还会经过Auto-review检查。执行这些检查的控制位于Dots不能修改的环境之外。它核对用户指令、自定义规则和安全要求，阻断后会把原因返回给Agent。

这些设计有明确价值：即使主Agent想继续做，外部控制也可以不让动作发生。但用户要求仍可能被误解或漏查，实际发出的内容也要核对。那100美元提醒我们去看这个差别，不能据此断言现有权限服务被绕过了。

底价可以交给程序检查，前提也要说全

如果用户已经确认，同一件商品、同一种币种，最低接受价就是某个金额，我倾向于把它保存为可检查的条件，在发送报价前比较，而不只让模型记住“别卖便宜了”。

这是一个设计建议，不是对Muse内部故障的诊断：低于底价就不发送，需要破例时重新取得批准；主Agent不能自行降低底价，也不能关闭这道检查。

难点在于，检查的必须是将要发给买家的真实条件。如果程序只核对旁边一个价格字段，消息正文却承诺另一个金额，仍然会漏。币种、数量、是否含运费也得对应；“净到手不少于300美元”和“售价不少于300美元”并不是同一条规则。

模型在这里仍有用：理解买家的话、提取条件、发现信息缺口，再把需要确认的地方递给人。更强模型可能减少这些环节的错误。但把金额读对、让错误报价无法发出，是两种可以分别检查的能力。

程序也只管得住写进去的条件。买家临时要求包邮，或者把取货时间改到你无法接受的凌晨，即使价格过线，交易也未必合适。不能把一条底价校验包装成“替我卖东西”已经得到全面保证。

模型升级，确实能让某些补丁退休

把所有问题都归为LLM的永久缺陷，同样说得过早。Anthropic在《Scaling Managed Agents with stable interfaces》中记录过一个很具体的变化。

Sonnet 4.5接近上下文容量上限时，会因为担心剩余空间不够而提前结束任务。团队曾在运行框架里加入重置上下文的办法，帮助它继续。换成Opus 4.5后，同样设置下的这种行为消失了，原有重置办法反而成了多余负担。

今天为模型行为加上的补救办法，升级后可能不再需要，应当重新检查。

但同一篇文章也解释了为什么要把模型运行、执行环境和会话日志分开。任务记录持久保存在上下文窗口之外，执行环境出故障时，可以独立恢复。理解力更好，并不会自动替用户保存丢失的记录，或替系统完成崩溃后的恢复。

对报价错误也应保留这种区分：模型改进可能让它更少误读底价；发送前的条件检查，则不必把“它这次应该会记得”当作唯一保障。两项改进可以同时推进。

“帮我卖个好价钱”，还有没说清的部分

底价清楚，适合检查；“尽快、少折腾、卖得划算”却要继续商量。

有人宁可少收一点，换买家今天来取；有人不急，愿意再等一周。有的人允许熟客议价，有的人不想让陌生人知道住址。这些都可能影响一次委托，却不会自动包含在一个价格数字里。

如果用户只说“尽快卖掉”，助手不能凭空知道，方便和收入之间该怎么选。它需要追问，或按已经确认的偏好办事。环境变化后，旧偏好是否仍适用，也可能需要重新确认。这不是LLM独有的困难，委托人类代办时也会遇到。

OpenAI在2025年的《Why language models hallucinate》中讨论过另一种相关压力：只奖励答对的评价，容易鼓励模型在不知道时猜一个答案；承认不确定、请求澄清，也应得到合理评价。

这项回答研究不能诊断那次报价错误。它对代办任务的启发是，不要把每次顺利往下做都算成进步。有时先问一句“包邮之后，净到手还能低于底价吗”，比自行补齐条件更有用。拒答或询问也不是万能办法，仍要看它是否在该停的地方停下、在条件明确后继续完成。

“可靠、可控、少监督”因此不适合只用一个模型分数回答。同样一个助手，整理资料时可以允许事后修正，发出价格承诺时却需要更明确的条件。可接受的错误及补救成本变了，能交出去的工作也会变。

少监督，要看完成了什么、又要补救什么

AP的这则个案不能证明Muse整体失败；公开的安全设计，也不能证明用户已经可以放心不看过程。Robb后来断开了大部分应用连接，仍期待产品改进后可能再用。

我更愿意看一段实际代办记录：有多少报价符合条件，多少次需要用户补充，哪些错误在发出前被挡住，哪些已经发生、又花了多久处理。被安全阻断的错误和真正完成的交易，要分开记；总是停下来等待，也不能算替人办完了事。

这比只说“审批次数变少了”更接近省心。一次授权可以覆盖很多合适的动作，也可能让一个被误解的条件反复沿用。监督减少之后，用户是否反而多花了时间检查聊天记录、解释价格、联系买家，也应计入。

我看好模型继续减少理解和规划上的错误，也主张把已经明确、代价较高的交易条件放到执行前检查。至于尚未说清的取舍，先问清楚，不要替用户猜成一条长期规则。

如果让助手代卖一件闲置物品，我想看到一份清楚的记录：按什么条件谈，向谁承诺了什么，有没有需要我善后的地方。报价偏离了底价，也应该能查清发生在哪一步。

延伸阅读