1. 从一句标题说起AI代理替你谈交易卡在哪一步“AI 代理替你谈成交易先得知道你真正想要什么”——这句话我第一次看到的时候正坐在电脑前调一个自动询价的小脚本。当时我的第一反应是这不就是我一直踩的那个坑吗我让模型帮我去跟供应商砍价结果它把价格砍下来了但交期从两周变成了两个月而我真正在意的其实是交期。价格是它自己脑补出来的“目标”交期才是我心里的底线。这个标题说的是一件很具体的事让 AI 代理AI Agent代替人去完成谈判、比价、撮合这类交易型任务前提是系统必须先准确捕捉到用户真实的偏好而不是用户嘴上说的、或者模型猜的那个偏好。它涉及的核心技术点包括 AI 代理的任务编排、Claude 这类大模型在代理场景下的使用、偏好排序preference ranking的建模方式以及提示词prompt如何把模糊的人类意图翻译成机器可执行的约束条件。适合谁来读如果你正在用 Claude、Claude Code 或者本地模型搭自动化代理想让它在采购、比价、日程协调、外包对接这类“有来有回”的场景里替你干活那这篇就是写给你的。如果你只是把大模型当聊天工具用那可能感受不深但只要你开始让模型“替你做决定”偏好这件事就绕不过去。我先说结论代理谈不成交易十有八九不是模型不够聪明而是你没把“你想要什么”这件事说清楚也没设计好让模型反复确认的机制。下面我按自己实际搭过的流程把这件事拆开讲。2. 为什么“知道你想要什么”比“会谈判”更难2.1 人类自己往往说不清偏好我做过一个小实验。让十个朋友写下“买一台笔记本最看重的三点”八个人写的是“性能、价格、续航”。然后我追问如果性能强但贵两千你选哪个如果续航多三小时但重了四百克你选哪个这时候答案就开始分化了有人愿意为续航加钱有人宁可轻一点。这就是偏好问题的本质人给出的是一组并列的标签但真实决策依赖的是这些标签之间的权衡关系trade-off。代理如果只拿到“性能、价格、续航”这三个词它没法知道当三者冲突时该牺牲谁。它只能猜而猜错的方向往往就是交易谈崩的方向。所以标题里“先得知道你真正想要什么”重点不在“知道”而在“真正”。用户说的和用户要的中间隔着一层需要被挖掘的偏好结构。2.2 代理的“目标函数”和人的“效用”不是一回事从工程角度看代理需要一个可优化的目标函数。比如砍价场景最朴素的目标函数是“成交价最低”。但人的效用函数里还有交期、质量、售后、付款条件、甚至跟对方的关系。你把这些都塞进一个标量目标里权重怎么定我试过两种做法。第一种是让模型自己定权重结果它倾向于把价格权重拉得很高因为价格最容易量化。第二种是我手动给权重但每换一个品类就要重调维护成本爆炸。后来我改成分层约束 偏好排序先划出硬约束不可谈判的底线再对软偏好做排序让代理在硬约束内去优化排序靠前的项。这个思路后面会详细讲。2.3 提示词在这里扮演什么角色热词里“提示词工程”“偏好排序”“AI代理”是绑在一起的。提示词不是用来“命令”模型去谈判的而是用来把偏好结构显式地写进上下文并且设计出让模型主动追问的机制。举个反例。我早期写的提示词是“帮我跟对方谈价格尽量低交期尽量短。”模型收到这种指令会自己脑补一个平衡点然后一路谈下去中途不回来问我。等它谈完告诉我结果我一看交期还是太长但已经来不及了。后来我改成两段式第一段提示词只做偏好采集让模型用提问的方式帮我把硬约束和软偏好分离出来第二段提示词才进入谈判并且带上“遇到冲突先暂停并回报”的规则。这个改动之后代理的可用性提升非常明显。3. 偏好排序把“我想要”翻译成机器能算的东西3.1 硬约束、软偏好、禁忌项三类要分开我在实际项目里把用户偏好分成三类这个分类方式参考了决策分析里常见的约束满足思路但做了简化方便直接写进提示词。类型定义例子代理行为硬约束不可违反的底线预算不超过 8000必须支持某接口违反直接否决不进入谈判软偏好可权衡的排序项续航优先于重量价格优先于品牌在硬约束内按排序优化禁忌项一票否决的特征不接受二手不接受某地区发货命中即排除这三类分开之后代理的决策逻辑就清晰了先用硬约束和禁忌项筛掉不合格选项再在剩下的选项里按软偏好排序。很多代理谈崩是因为把软偏好当成了硬约束或者把硬约束当成了软偏好。比如“价格尽量低”是软偏好但模型可能把它当成硬约束为了低价牺牲了交期这个更靠前的软偏好。3.2 用排序代替打分减少权重调参的麻烦打分法需要给每个维度定权重权重一变结果就变很难维护。排序法只需要用户回答“A 和 B 你选哪个”相对更稳定。我常用的做法是让模型做成对比较生成一个偏好序列。比如交期 vs 价格选交期价格 vs 售后选价格交期 vs 售后选交期那么排序就是交期 价格 售后。代理在谈判时优先保交期其次压价格最后才考虑售后。这个序列可以直接写进提示词作为优化顺序。注意成对比较的项不要超过五六个否则用户会烦模型也会绕晕。超过六个就先做一轮粗筛把明显不重要的项去掉。3.3 偏好不是静态的要允许中途修正谈判过程中用户可能改主意。比如原本交期优先但对方给了一个特别低的价格用户可能愿意等。所以代理需要支持偏好修正在关键节点暂停把当前选项和偏好冲突点报给用户让用户决定是否调整排序。我在提示词里加了一条规则“当出现某个选项在排序靠后的维度上显著优于当前最优选项时暂停并询问用户是否调整偏好顺序。”这条规则让代理从“闷头谈”变成了“边谈边确认”实际用下来用户对结果的满意度高很多。4. 提示词怎么写从采集偏好到执行谈判的完整链路4.1 第一段提示词只做偏好采集不做决策这段提示词的目标是让模型通过提问把用户脑子里的模糊需求变成结构化的偏好表。我用的模板大致是这样你是一个偏好采集助手。你的任务是通过提问帮用户明确以下三类信息 1. 硬约束不可违反的底线预算、必须满足的条件 2. 软偏好可以权衡的维度并给出排序 3. 禁忌项一票否决的特征 规则 - 每次只问一个问题等用户回答后再问下一个 - 对软偏好用成对比较的方式确认排序不要直接问权重 - 采集完成后输出一个结构化的偏好表让用户确认 - 不要在这个阶段给出任何交易建议这段提示词的关键是限制模型的行为范围。早期我没加“不要给建议”这条模型采集到一半就开始推荐产品把采集流程打断了。加上限制之后采集效率明显提高。4.2 第二段提示词带上偏好表进入谈判采集完成后把偏好表作为上下文传给谈判提示词你是一个谈判代理。用户的偏好如下 硬约束预算 8000必须支持 X 接口 软偏好排序交期 价格 售后 禁忌项不接受二手 规则 - 任何选项先检查硬约束和禁忌项不合格直接排除 - 在合格选项中按软偏好排序选择最优 - 当出现排序靠后的维度显著更优、可能值得调整偏好时暂停并询问用户 - 每轮谈判后输出当前状态已排除项、候选集、当前最优、待确认点这里“每轮输出状态”很重要。代理谈判是多轮交互如果不输出中间状态用户不知道它谈到了哪一步出了问题也很难排查。4.3 提示词里的常见坑我踩过的几个坑列出来供参考把偏好写成一句话“价格低交期短质量好”——模型无法处理冲突只能瞎猜。必须拆成排序。硬约束写得太软“预算大概 8000 左右”——模型会试探性超预算。硬约束要用明确的不等式。忘了禁忌项用户说“不要二手”但提示词里没写模型可能把二手选项放进候选集。没有暂停机制模型一路谈到底中途不回报用户失去控制权。偏好表没有让用户确认模型自己总结的偏好可能有偏差必须让用户过目。提示偏好表最好用表格形式输出用户一眼就能看出哪项排错了改起来也方便。5. 用 Claude 和本地模型搭代理时的实操细节5.1 Claude 在代理场景下的优势与限制Claude 系列模型在长上下文和指令遵循上表现比较稳适合做多轮谈判这种需要记住大量约束的任务。我用 Claude 做偏好采集和谈判编排主要看重它能把结构化规则执行得比较到位。但有几个限制要注意。一是 API 调用有速率和成本约束多轮谈判如果每轮都调大模型成本会上去。我的做法是把简单判断下沉到规则引擎比如硬约束检查用代码做只有需要权衡和生成话术的时候才调模型。二是模型有时会“过度礼貌”在谈判里表现为过早让步。我在提示词里加了“不要主动让步除非对方给出对等条件”来压制这个倾向。5.2 本地模型接入的取舍热词里“claude code 调用 lmstudio 的本地模型”“ai代理助手加本地模型”出现频率很高说明很多人想在本地跑代理。我试过用本地模型做偏好采集体验是采集阶段可以用本地模型谈判阶段建议用能力更强的模型。原因是偏好采集主要是提问和结构化对模型能力要求不高本地模型够用还能省成本、保隐私。但谈判阶段需要理解对方话术、识别隐含条件、生成有策略的回应本地模型容易露怯。我的折中方案是本地模型做前端采集和初筛云端模型做核心谈判。5.3 环境配置的常见报错热词里有一堆安装和连接报错比如“unable to connect to anthropic services”“claude native binary not installed”“requires the virtual machine platform on windows”。这些大多是环境问题不是模型问题。我的排查顺序是先确认网络能正常访问服务端点用 curl 测一下再确认 API key 和权限配置正确然后看本地运行时依赖是否装全Node 版本、二进制文件最后看系统级依赖比如 Windows 上的虚拟机平台组件大部分“连不上”的问题出在第二步和第三步。尤其是把 key 写在错误的环境变量里或者用了过期的 key报错信息往往很模糊容易误判成网络问题。6. 常见问题与排查技巧实录6.1 代理谈出来的结果和预期不符这是最高频的问题。排查思路现象可能原因排查方法价格谈下来了但交期变长软偏好排序没写对或模型把价格当硬约束检查偏好表确认排序代理中途不回报提示词缺少暂停规则加“冲突时暂停”规则候选集里有禁忌项禁忌项没写进提示词或检查逻辑漏了补禁忌项加前置过滤代理过早让步提示词缺少让步条件加“对等条件才让步”规则偏好表总结有偏差模型自行脑补采集后让用户确认6.2 偏好采集阶段用户不耐烦成对比较问多了用户会烦。我的做法是限制问题数量硬约束最多问三个软偏好最多做四轮成对比较禁忌项一次问完。超过这个量就先按默认排序走谈判中再修正。6.3 多轮谈判上下文太长谈判轮次多了上下文会膨胀成本和延迟都上去。我的处理是每轮只保留结构化状态不保留完整对话历史。状态包括已排除项、候选集、当前最优、待确认点、偏好表。这样上下文长度可控模型也不会被历史对话带偏。6.4 本地模型和云端模型切换时的状态同步如果采集用本地模型、谈判用云端模型偏好表要作为显式上下文传递不能依赖模型记忆。我一般把偏好表序列化成 JSON两边都读同一份避免理解偏差。7. 我个人在实际操作中的几点体会搭这套东西的过程中我最大的体会是代理的能力上限取决于偏好表达的清晰度而不是模型参数。同一个模型偏好表写得好谈出来的结果就靠谱偏好表写得糊再强的模型也白搭。第二个体会是暂停机制比自动化更重要。很多人追求全自动但交易场景里用户往往需要在关键节点介入。代理的价值不是替用户做所有决定而是把选项和冲突点整理清楚让用户做更高质量的决定。第三个体会是偏好排序要允许模糊。不是所有维度都能排出严格顺序有些就是“差不多就行”。这时候可以用分组排序比如“交期和价格是第一组售后和品牌是第二组”组内不严格排序组间有优先级。这样既保留了灵活性又给了代理可执行的约束。最后分享一个小技巧在偏好采集阶段让模型顺便问一句“如果只能保一个你保哪个”。这个问题往往能逼出用户真正的底线比问一堆维度都管用。我试过很多次用户在这个问题上的回答和他们在成对比较里的选择高度一致但回答速度更快体验也更好。