1. 从“AI代理替你谈成交易”说起这件事到底难在哪“AI 代理替你谈成交易先得知道你真正想要什么”——这句话我第一次看到的时候正在给一个做二手设备撮合的朋友改他的自动化流程。他当时的诉求特别朴素让 AI 帮他跟供应商来回砍价最好能自动把价格压到心理价位以下谈不拢就换下一家。听起来是个很标准的代理任务但真正动手之后我发现卡住整个流程的从来不是模型会不会说话而是它压根不知道“我到底想要什么”。这不是一句废话。你让一个代理去谈交易它需要同时处理三层信息第一层是硬约束比如预算上限、交付时间、必须包含的配件第二层是软偏好比如你更在意价格还是更在意账期能不能接受二手成色差一点但便宜三成第三层是隐性优先级比如你嘴上说“价格最重要”但实际上如果对方能当天发货你愿意多付 8%。这三层里第一层最好写第二层要费点劲第三层几乎没人能一次性说清楚——而这恰恰是代理能不能真正替你谈成事的分水岭。所以这篇我想聊的不是“怎么装一个代理框架”而是怎么把一个人脑子里模糊的、自相矛盾的、连他自己都没想明白的偏好翻译成代理能执行、能排序、能在谈判桌上做取舍的结构化输入。核心关键词就三个AI代理、偏好排序、提示词。适合谁看如果你正在用 Claude、Claude Code 或者本地模型搭自动化谈判、采购比价、需求撮合这类流程或者你只是想让 AI 帮你回一封“既要礼貌又要强硬”的邮件这篇里的思路都能直接抄。我先把结论摆前面代理谈崩九成不是模型能力问题是偏好没被结构化。下面我从整体设计、偏好拆解、提示词落地、实操排查四个层面把这件事拆开讲。2. 整体设计思路为什么“偏好排序”比“提示词技巧”更关键2.1 代理谈判的本质是一个多目标排序问题很多人一上来就研究提示词怎么写得更“像人”比如加一堆“你是一位资深采购专家”的角色设定。我早期也这么干过效果很有限。后来我想明白了谈判代理的本质不是“生成一段话”而是在多个互相冲突的目标之间做排序和取舍。价格、账期、交期、质量、售后、关系维护这些目标不可能同时最优代理每说一句话本质上都是在替你做一次权重分配。举个我实际跑过的例子。帮朋友谈一批工业传感器硬约束是单价不超过 420 元、两周内到货。软偏好里他其实更在意“能不能先拿样品”因为要验证兼容性。如果我只写“帮我谈个低价”代理会一路压价把供应商逼到不愿意给样品但如果我在偏好里把“样品优先”排到价格前面代理的话术立刻变了会先谈样品再谈批量价。同一批供应商同一套模型结果完全不同。这就是偏好排序的威力——它决定了代理在每一个岔路口往哪走。2.2 为什么选“显式排序”而不是“让模型自己猜”有人会问现在模型这么强我把背景一股脑丢给它让它自己判断优先级不行吗我实测下来不行至少不稳定。原因有两个。第一模型没有你的“损失函数”。你丢 8% 的利润和丢一个长期供应商在它眼里可能都是“负面结果”但对你来说权重差十倍。第二谈判是动态的对方每还一次价你的偏好权重可能就要调整如果权重藏在模型的“理解”里你根本没法干预。所以我坚持用显式排序把偏好写成带权重的列表让代理在每一步都能读到“当前什么最重要”。这跟热搜里那些“提示词工程”“AI 编程提示词”的讨论是一脉相承的——提示词不是咒语是把你的意图翻译成机器可执行结构的接口。你把它写清楚了Claude 也好本地模型也好表现都会稳一大截。2.3 一个可复用的三层偏好模型我把偏好拆成三层这套结构在我做过的采购、比价、需求撮合里都能套用硬约束层Must不可谈判的红线。比如预算上限、合规要求、必须支持的功能。代理一旦发现对方触碰红线直接终止或换人不做任何妥协。权重偏好层Want可量化、可排序的软目标。比如价格权重 0.4、交期权重 0.3、账期权重 0.2、售后权重 0.1。这一层是代理做取舍的依据。情境调整层If-Then条件触发的临时优先级。比如“如果对方能当天发货价格权重下调 15%”“如果对方是老客户账期可以让步”。这三层写下来通常不超过一页纸但它能把一个模糊的“帮我谈好”变成代理能执行的决策树。下面我逐层拆解怎么写。3. 核心细节解析把“我真正想要的”翻译成代理能读的结构3.1 硬约束层先划红线再谈技巧硬约束最容易写但也最容易写错。常见的错误是把“希望”写成“必须”。比如“希望价格在 400 以内”如果你写成硬约束代理会在 401 的时候直接放弃一个其实可以接受的报价。我的做法是只有触碰了会让你直接否决整笔交易的条件才放进硬约束层。写硬约束的时候我习惯用“字段 阈值 动作”的格式这样代理读起来没有歧义hard_constraints: - field: unit_price operator: value: 420 action: reject_offer - field: delivery_days operator: value: 14 action: reject_offer - field: certification operator: contains value: CE action: reject_offer注意硬约束不要超过 5 条。超过 5 条说明你还没想清楚哪些是真的不能让步代理会变得极其僵硬谈判空间被压没。我踩过的一个坑是把“必须开发票”写进硬约束结果对方是个体户开不了专票代理直接终止但其实那批货朋友是可以接受普票的。后来我把这类“最好有但不是绝对”的条件挪到权重层谈判成功率立刻上来了。所以硬约束的判定标准就一条没有它这笔交易对你就是负价值。3.2 权重偏好层给每个目标一个数字而不是一个形容词权重层是整套结构里最值钱的部分。很多人写偏好喜欢用形容词“价格要便宜”“交期要快”“质量要好”。问题是代理没法比较“便宜”和“快”哪个更重要。你必须给数字。我的做法是让权重加起来等于 1然后逐项分配。分配的时候有个技巧先两两比较再定数值。比如价格和交期你更在意哪个如果价格那价格权重就高于交期。把所有目标两两比一遍排序自然就出来了数值只是把这个排序量化。偏好目标权重说明让步空间单价0.40越低越好但可接受上浮 5%中交期0.3014 天内越早越好小账期0.20希望 30 天可接受 15 天大售后0.10至少一年质保中这张表看起来简单但它解决了代理谈判里最大的难题当对方说“价格不能再降但我可以给你延长账期”时代理知道该不该接。按上表账期权重 0.20价格权重 0.40如果延长账期带来的效用提升能覆盖价格没降的损失就该接。这个判断靠形容词是永远做不出来的。提示权重不是拍脑袋定的。我通常会让需求方做一次“取舍测试”——比如“价格降 5% 但交期延后 3 天你接受吗”用一连串这样的问题反推权重比直接问“价格占多少权重”靠谱得多因为人对抽象数字没感觉对具体取舍有感觉。3.3 情境调整层让代理在谈判桌上会“看情况”前两层是静态的但真实谈判是动态的。情境调整层就是给代理装一个“如果……那么……”的开关。这一层写得好代理会显得特别“懂你”。我常用的几个情境规则时间压力规则如果距离截止日期不足 3 天交期权重临时上调到 0.5价格权重下调到 0.25。老客户规则如果对方是合作超过 2 年的供应商账期权重下调关系维护权重上调。批量规则如果采购量超过 1000 件价格权重上调因为批量议价空间大。竞争规则如果同时有 3 家以上在谈代理可以更强硬让步阈值收紧。写成结构大概是这样situational_rules: - condition: days_to_deadline 3 adjust: delivery_weight: 0.50 price_weight: 0.25 - condition: supplier_tenure_years 2 adjust: payment_term_weight: 0.10 relationship_weight: 0.15这一层的价值在于它让代理不再是“一套权重走天下”而是能根据谈判进程实时调整策略。我实测下来加了情境层之后代理在“该硬的时候硬、该让的时候让”这件事上表现比纯权重层好太多。3.4 提示词怎么写把结构喂给模型而不是把情绪喂给模型结构写好了接下来是提示词。这里我要泼一盆冷水提示词技巧解决不了偏好不清的问题。你偏好没写清楚提示词写得再花哨代理还是瞎谈。但反过来偏好清楚了提示词只需要做一件事——把结构准确地传给模型并约束它的输出格式。我常用的提示词骨架分四段角色与任务一句话说清代理在干什么不要长篇大论。偏好结构注入把上面三层 YAML 直接贴进去让模型读到。决策规则告诉它每一步怎么用权重做判断比如“每次收到报价先检查硬约束再计算加权效用效用低于当前最优就还价或拒绝”。输出格式强制它输出结构化结果方便你后续程序处理。一个简化版示例你是一个采购谈判代理。你的目标是在满足硬约束的前提下最大化加权效用。 硬约束 - 单价 420 - 交期 14 天 权重偏好 - 单价 0.40 - 交期 0.30 - 账期 0.20 - 售后 0.10 情境规则 - 若距截止日期不足 3 天交期权重调整为 0.50单价权重调整为 0.25 每次收到对方报价请 1. 检查是否触碰硬约束若触碰输出 REJECT 并说明原因。 2. 计算加权效用与当前最优报价比较。 3. 输出决策ACCEPT / COUNTER / REJECT并给出还价话术。 4. 以 JSON 格式输出字段包括 decision、utility、counter_offer、message。这套提示词没有任何“你是一位资深专家”之类的角色扮演但实测比那些花哨版本稳得多。原因很简单模型需要的是可计算的决策依据不是情绪氛围。热搜里那些“提示词工程”“AI 编程提示词”的讨论很多都绕在措辞上但真正决定效果的是你有没有把意图结构化成模型能算的东西。4. 实操过程从零搭一个“懂你要什么”的谈判代理4.1 环境与工具选型Claude、本地模型怎么选先说工具。我目前主力用 Claude 系列模型做谈判代理原因是它在长上下文里保持指令遵循的能力比较稳尤其是你塞进去一整套 YAML 偏好结构之后它不容易“忘记”。如果你用 Claude Code 或者 VS Code 里的相关插件配置流程和普通 API 调用差不多核心是把偏好结构作为系统提示的一部分固定下来。本地模型我也试过通过 LM Studio 之类的工具把本地模型接进来。好处是数据不出本地适合处理敏感报价代价是指令遵循能力参差偏好结构稍微复杂一点就容易跑偏。我的建议是偏好结构简单、对隐私要求高用本地模型偏好结构复杂、需要多轮动态调整用 Claude 这类云端模型。两者可以混用比如本地模型做初筛云端模型做关键轮次谈判。注意不管你用哪个模型都要把偏好结构放在系统提示里而不是每轮对话里重复贴。重复贴会挤占上下文还容易让模型把偏好当成“临时信息”而降低权重。4.2 第一步把需求方的模糊描述变成偏好草稿这一步最费时间但最不能省。我的做法是拿一张白纸问需求方三类问题红线问题什么情况下你直接不谈了取舍问题价格降 5% 但交期延后 3 天你接受吗反复问直到权重稳定情境问题什么情况下你会改变上面的取舍把答案记下来先写成自然语言草稿再翻译成 YAML。翻译的时候有个小技巧每个偏好都要能回答“怎么衡量”。比如“质量好”没法衡量但“质保期 12 个月”可以。凡是不能衡量的要么拆成可衡量的子项要么挪到硬约束。4.3 第二步用历史数据校准权重权重不能全靠问还要用数据校准。我朋友那批传感器我翻了他过去半年的采购记录发现他实际成交价平均比初始报价低 12%交期平均 10 天。这说明他对交期的真实容忍度比他自己说的“两周”要宽价格敏感度比他自己以为的高。我把这些数据反馈到权重里价格权重从 0.35 调到 0.40交期从 0.35 调到 0.30代理的谈判策略立刻更贴近他的真实行为。这一步很多人跳过结果代理谈出来的结果“理论上最优但需求方不满意”。原因就是权重是“说的”而不是“做的”。用历史成交数据反推权重是让代理真正懂你的关键一步。4.4 第三步跑一轮模拟谈判观察代理的取舍逻辑正式上线前我一定会跑模拟。方法是自己扮演供应商故意给出几种典型报价纯低价但交期长、价格高但交期短、价格交期都中等但账期好。然后看代理的决策是否符合预期。我记录过一轮模拟的决策日志大概是这样的轮次对方报价加权效用代理决策是否符合预期1单价 450交期 10 天低于阈值REJECT是触碰硬约束2单价 415交期 13 天0.82COUNTER是3单价 418交期 9 天账期 30 天0.88ACCEPT是4单价 410交期 20 天0.71COUNTER是交期超硬约束这张表能帮你快速发现偏好结构的问题。比如如果第 3 轮代理拒绝了说明你的权重分配和你的直觉不一致需要回去调。模拟跑 3 到 5 轮基本就能把结构调稳。4.5 第四步上线后的动态调整机制代理上线不等于结束。真实谈判里对方的策略会变你的偏好也可能变。我通常会留一个“偏好热更新”的口子把偏好结构存在一个配置文件里代理每轮开始前重新读取。这样你发现代理太强硬或者太软改一下权重就能立刻生效不用重启整个流程。另外我会记录每一轮的决策日志包括对方报价、加权效用、代理决策、最终结果。跑一段时间后回看你会发现某些权重明显偏离实际比如账期权重给高了导致代理老是在账期上纠缠其实你根本不在意。这种基于真实数据的复盘比任何提示词技巧都管用。5. 常见问题与排查技巧实录5.1 代理谈着谈着就“忘了”偏好怎么办这是最高频的问题。表现是前几轮还按权重走后面突然开始乱让步。原因通常是偏好结构在上下文里被稀释了。解决办法有三个一是把偏好放在系统提示最前面并且用分隔符明确标出二是每轮决策前让代理先复述一遍当前权重强制它“想起来”三是把偏好结构做成外部工具调用代理每轮主动查询而不是靠记忆。我实测下来第二种最省事效果也稳。就是在提示词里加一句“在给出决策前先用一句话总结当前生效的权重排序”。这句话看起来多余但它能显著降低代理“跑偏”的概率。5.2 权重定了但代理还是不会取舍问题出在哪大概率是权重没有和具体的报价字段对应上。比如你写了“价格权重 0.4”但代理收到的报价里价格是“含税价”还是“不含税价”没定义清楚它就没法算。我的经验是每一个权重项都要在偏好结构里明确对应的数据字段和计算方式。价格是含税还是不含税、交期是自然日还是工作日、账期是开票后还是收货后这些细节不写清楚权重就是空中楼阁。5.3 对方报价触碰硬约束但代理还在还价这是硬约束判定逻辑写错了。常见原因是把硬约束写成了“建议”而不是“规则”。代理读到“单价最好不超过 420”它会理解成可以商量读到“单价 420否则 REJECT”它才会严格执行。所以硬约束的措辞必须是命令式的、带动作的不能有任何模糊空间。5.4 本地模型和云端模型表现差异大怎么统一差异主要来自指令遵循能力。我的做法是给本地模型更简单、更结构化的偏好输入减少自然语言描述多用 YAML 和枚举值。同时把决策逻辑拆得更细比如把“计算加权效用”拆成明确的步骤让本地模型一步步执行而不是让它自己“理解”。如果还是不稳就在本地模型前面加一层规则引擎硬约束和简单权重计算用代码做只把话术生成交给模型。5.5 常见问题速查表问题现象可能原因排查动作解决方向代理中途乱让步偏好被上下文稀释检查偏好是否在系统提示每轮复述权重不会取舍权重未对应数据字段检查字段定义明确含税/工作日等口径触碰红线还还价硬约束写成建议检查措辞改为命令式带动作本地模型跑偏指令遵循弱对比云端表现简化输入加规则引擎谈出来的结果不满意权重与实际不符对比历史成交数据用数据校准权重最后分享一个我踩过的坑早期我图省事把偏好写在对话历史里结果聊到第十轮模型开始把最早的偏好当成“背景信息”而不是“当前规则”。后来我改成每轮开头用固定格式重申一次偏好问题就没了。这个改动很小但效果立竿见影。5.6 一个容易被忽略的点偏好是会变的我见过太多人把偏好当成一次性配置配完就不管了。但真实世界里你的偏好会随市场、库存、现金流变化。比如月底现金流紧账期权重就该上调旺季临近交期权重就该上调。所以我在代理里留了一个“偏好版本”的概念每次调整都记一笔方便回溯“为什么那轮谈成那样”。这个习惯让我在后来的复盘中能清楚看到每一次策略调整带来的结果变化也让代理越来越贴近真实需求。说到底“AI 代理替你谈成交易”这件事模型能力只是入场券真正决定成败的是你有没有把“你真正想要什么”这件事拆到代理能算、能排、能取舍的程度。偏好排序做扎实了提示词只是最后一公里的传输带偏好没做扎实再花哨的提示词也只是让代理更流利地谈崩。