1、业务介绍在介绍项目之前我先简单介绍一下分销业务。分销就是商家提供商品和佣金达人通过内容带货平台完成撮合、归因和结算。交易做起来以后又会吸引商家投入更多供给和佣金带动更多达人和内容形成一个持续增长的业务飞轮。过去几年分销从跑通基础链路、扩大供给规模逐步进入经营提效阶段。但随着商品和达人规模快速增长怎么把大规模供给更有效地转化成内容和交易成为新的核心问题。在实习期间我主要完整参与了商达智能撮合系统的项目建设以及一些稳定性方面的建设。2、项目背景对于商达智能撮合系统这个项目是我来实习了之后团队这边正在准备推进的一个项目所以我完整经历了这个项目从需求分析、方案设计再到开发上线的全流程。首先我们看到 2025 年分销的商达规模一直在增长从 Q1 到 Q4达人规模和分销 GMV 都保持在比较高的水平。但规模起来以后达人活跃和动销并没有同步增长。所以我们当时往下看了一层发现问题逐渐从“有没有足够多的供给和达人”变成了“这些供给和达人怎么更有效地撮合起来”。商家这边有商品也愿意出佣金但佣金怎么设置、应该重点经营哪些达人缺少比较好的判断依据达人这边也是一样选品广场商品很多但真正适合自己的商品并不好找。所以 2026 年开始我们主要围绕商达撮合这个问题从商家经营和达人选品两个方向开始做。3、整个项目的挑战但真正要把商达撮合做起来不是简单接一个模型就能解决我们主要有三个技术挑战。第一商家设置商品 CPS 时决策怎么收敛。CPS 概念Cost Per Sale直译“按成交付费”在快手分销这个场景里说白了就是佣金比例。通俗说就是商家出佣金达人带货成交了才给钱。核心在于那个“按成交付费”——没成交就不给钱。达人不是拿固定广告费而是拿销售分成。CPS 同时受到达人产能、商家历史效能和市场水位影响不同模型会有不同判断需要把这些结果最终收敛到一起。第二选品广场给达人推荐商品时计算怎么规模化。面对 400W 商品不可能全部交给模型推理需要先通过工程手段把候选空间压下来再做精排。第三推荐结果怎么校准。CPS 和商品推荐上线后还需要把商家的采纳、达人的选品以及最终成交结果沉淀回来持续修正后面的策略。所以我的项目主要就围绕这三个挑战分别是三个解法多模型协同 统一仲裁、分层召回 模型精排以及反馈回流 策略迭代。一、Multi-Agent CPS 协同决策我第一个要讲的是 CPS 决策这块。核心问题其实就一句话CPS 这个佣金值它不是一个维度能决定的而且模型给出的结果我也不敢直接拿去用。我的做法是把复杂决策拆成三个专业 Agent 各算各的再让一个仲裁 Agent 统一收敛最后加一层 Java 安全阀兜底。这样既解决了单一模型覆盖不全的问题也解决了模型输出不可信的问题。4.1 S — Situation背景与问题先讲背景。分销业务里商家上架商品要设 CPS就是给达人的佣金比例。这个值很要命——设低了达人没动力帮你带货设高了商家的利润就被吃掉了。过去商家基本靠经验拍脑袋或者看一眼竞品抄一下没有系统依据。但真要让系统来算我发现这个 CPS 背后其实是三个完全不同的判断维度达人产能这商品找什么样的达人带达人现在处于什么阶段带不带得动商家历史效能这个商家过去跟哪些等级的达人合作是真正出过单的效率怎么样市场水位同类目、同价格带的竞品佣金普遍给到了多少。这三个维度分析方法完全不一样。一个是看达人漏斗转化的一个是看历史归因的一个是看市场分位的。你让一个模型同时把这三件事都做好它就会互相干扰判断依据混在一起。更麻烦的是LLM 本身有不确定性它会幻觉、会越界、会输出格式错误。而 CPS 是直接关系到钱的决策模型说多少就是多少的话一旦出错就是真金白银的损失。4.2 T — Task目标一句话“目标是把一个复杂的、多维的、模型不可信的 CPS 决策变成一条稳定、可解释、可执行、可兜底的决策链路。”拆成三个具体目标决策收敛多模型结果能合并成一个统一 CPS 建议而不是各说各话。可解释商家能看到“为什么建议这个佣金”不能是黑盒。安全落地模型结果经过工程校验才能进业务异常结果必须被拦截。4.3 Action动作核心部分分三层我的方案是三层架构。第一层三个 Sub-Agent 各管一摊“我先讲第一层多模型独立决策。我没有让一个模型直接输出 CPS而是把它拆成了三个专业 Agent。第一个叫达人价值感知。它看的是 CPS 分桶数据、达人选品的覆盖率、从选品到发布的转化率、还有发布覆盖率。它要做的事是找到达人产能的拐点诊断现在卡在哪儿然后给出一个它认为合适的目标 CPS同时附上理由和置信度。说白了它回答的问题是——这个商品找谁带、带不带得动。第二个叫历史效能匹配。它看的是商家和达人的历史合作结构、达人的等级分布、每个等级贡献的 GMV、还有作品数、效率指数。它要做的是识别出这个商家历史上真正核心的贡献达人群体是哪些然后把他们的表现跟行业的 P50、P75 去对齐。它回答的问题是——这个商家过去谁带有效佣金该给到哪个档位。第三个叫市场竞对穿透。它看的是类目、价格带、商家类型、内容场域、还有销量水平。它要做的是算出来这个商品在同类目里的 P25、P50、P75 分位然后判断现在是蓝海还是红海。它回答的问题是——行业普遍给多少我给多少才有竞争力。为什么我拆这三个因为这三个维度是正交的各管一个独立的问题方法论也各不相同。拆开之后每个 Agent 的判断依据是干净的出问题的时候我也能定位到是哪一个 Agent 算错了而不是一个黑盒整体重来。”“为什么用 Agent 不用写死规则”补这句“这三个维度里有大量非结构化的判断比如‘这个达人现在是不是处在产能拐点’‘这个类目到底算蓝海还是红海’这种东西你用规则写写不完也维护不起用 LLM 的语义理解能力正合适。但反过来一个 LLM 同时理解三个领域判断会互相污染所以我拆成三个各自独立。”为什么是这三个必背深挖必问达人产能 → 回答“找谁带、带不带的动”历史效能 → 回答“这个商家过去谁带有效”市场水位 → 回答“行业给到多少、我给多少才有竞争力”三个维度正交拆开各自方法论清晰合起来覆盖 CPS 决策的主要因素。第二层统一仲裁中央决策 Agent 收敛“第二层是统一仲裁。三个 Agent 各自给了推荐值和置信度但它们可能打架。所以我加了一个中央决策 Agent专门做收敛。这个收敛不是简单求平均它分五步第一步结果理解与校验——先看哪些模型的结果是有效的缺失的怎么处理明显异常的给它降权第二步置信度评估——这里我要强调一下置信度不是模型自己报自己有多自信而是仲裁层重新算的综合四个客观指标样本量够不够、方差稳不稳定、达人覆盖度高不高、数据完不完整第三步动态权重——权重就是置信度归一化谁置信度高谁权重就大公式很简单置信度除以所有置信度的总和第四步加权融合——用这个权重把三个推荐值加权得到一个基础值第五步也是最关键的一步业务规则校验和冲突消解——融合出来的值还要再过一遍业务规则比如商家生命周期权重、采纳率红线、绝对收入保底、蓝海机会、还有阶梯调整。这一步才是和纯数学加权最大的区别。我举个例可能某个 Agent 置信度很高但它推荐的 CPS 会踩到商家的采纳率红线那业务规则这层就会把它修正过来。所以最终值是‘数据说话 业务兜底’两层决定的。”其中“蓝海机会”的意思是即使三个 Agent 加权融合出来的 CPS 数值偏保守如果业务规则判断这是一个蓝海市场机会也会在规则层给一个向上的修正——鼓励商家在竞争还没起来的时候用略高的佣金先把达人资源占住吃到先发红利。简单说加权融合给的是“市场当下该是多少”蓝海机会这条规则给的是“未来机会要不要提前押注”。两者结合才让 CPS 建议不是纯静态计算而是带了一点战略前瞻。仲裁的五步流程这是你区别于随便加权平均的关键务必讲清楚 结果理解与校验识别哪些模型结果有效、缺失的怎么处理、异常的降权。 置信度评估综合四个维度评估每个 Agent 的置信度——样本量、方差/稳定性、达人覆盖度、数据完整度。 动态权重计算核心公式 Agent Weight Confidence / ΣConfidence置信度高的权重自动大。 加权融合CPS* Σ Weightᵢ × CPSᵢ。 业务规则校验 冲突消解这是和纯数学加权最大的区别——融合后再过一次业务规则商家生命周期权重、采纳率红线、绝对收入保底、蓝海机会、阶梯调整再做冲突消解和异常兜底。输出统一 CPS 建议 完整决策过程reason / process_reason。第三层Java 安全阀工程兜底具体链路是这样的三个 Sub-Agent 各自输出 → 中央仲裁 Agent 收敛融合 →输出统一的 CPS 建议标准 JSON→Java 安全阀对这个最终结果做校验→ 通过才落库执行“第三层是工程安全阀。模型结果哪怕经过了仲裁我也不会让它直接落业务。后端还有一层校验把模型的判断能力和系统的执行约束彻底解耦。安全阀具体干五件事第一JSON 解析——校验字段完整性和类型合法性防止模型返回格式错误第二调整校验——检查isAdjustCps这个标志位防止模型在商家根本不该调佣金的场景乱建议第三边界校验这里有三个硬约束推荐值不能超过 10%不能低于当前值单次涨幅不能超过 2%。这三个数是结合商家接受度定出来的经验阈值第四任务防重——用状态去重保证幂等第五异常拦截——非法结果直接丢弃不落库。校验都通过之后结果才落到任务表里状态标成 PENDING待商家确认进入后面的异步任务编排。”CPS 决策任务从创建到结束状态大致这样流转待执行 → PENDING → ACCEPTED商家采纳 ├──→ IGNORED商家忽略 └──→ EXPIRED超时过期状态含义待执行CREATED / 可叫 INIT任务已创建、已落库模型还没算完PENDING结果已生成、已校验、已落库等商家确认ACCEPTED商家采纳佣金按建议生效IGNORED商家看了没采纳维持原状EXPIRED商家超时没处理建议过期3. 单次涨幅 ≤ 2%步长限制防止一次性暴涨。假设模型算出目标应该是 12%但当前是 6%如果直接一步跳到 12%商家心理上接受不了会觉得自己被系统坑了或者干脆不采纳。所以用阶梯调整——每次最多涨 2%分几次慢慢到位商家有适应期也降低了一次性错误带来的损失风险。那几个具体阈值各自的作用简历里写了三个硬约束它们不是随便定的每个都对应一个真实风险1. 推荐值 ≤ 10%上限防止模型给出离谱的高佣金。比如模型幻觉了输出一个 50% 甚至 100% 的佣金商家真采纳了利润全被佣金吃光甚至亏本。10% 是结合行业水位和商家承受能力定的天花板超过直接拦。2. 推荐值 ≥ 当前值下限防止模型建议商家“降佣金”。降佣看起来省了钱但会直接导致达人流失——达人发现这个商品佣金变低了就不带了商家反而损失流量和销量。所以在 CPS 决策这个场景里默认只能往上调或维持不能往下调。这条是保护商家经营稳定性的。那如果商家本来就设置高呢“你问得对这里要分场景看。CPS 智能决策这条链路业务定位是帮商家提升商品竞争力所以默认方向是往上调——给商家一个更有竞争力的佣金建议去吸引达人。那如果商家本来就设高了怎么办这种情况我们不通过‘自动建议降佣’去处理而是走风险提示系统识别到商家当前佣金已经高于行业水位比如超过 P75会提示商家‘你的佣金偏高可能侵蚀利润建议下调’但降不降、降多少由商家自己决定系统不替他做降佣这个动作。为什么降佣要这么谨慎因为降佣会直接影响正在带货的达人收益达人一旦发现佣金降了可能就流失了这个动作风险很高。而‘提示’让商家自己权衡既保护了商家的知情权也避免了系统误判导致达人流失的责任。所以安全阀里那条‘推荐值不低于当前值’本质是约束自动决策链路的——这条链路只做‘提竞争’的事不做‘降佣’的事降佣走的是另一条人工决策路径。3. 单次涨幅 ≤ 2%步长限制防止一次性暴涨。假设模型算出目标应该是 12%但当前是 6%如果直接一步跳到 12%商家心理上接受不了会觉得自己被系统坑了或者干脆不采纳。所以用阶梯调整——每次最多涨 2%分几次慢慢到位商家有适应期也降低了一次性错误带来的损失风险。CPS 异步任务编排“CPS 任务怎么落地执行的”补这一段“这一块我讲的是工程落地层。前面三个 Sub-Agent 加仲裁是‘判断’判断完之后结果怎么可靠地、可控地落下来这是另一件事。因为模型推理是异步的、慢的、还可能失败所以我把 CPS 决策做成了异步任务用 MQ 解耦再用幂等、限流、状态机和扫描这几样东西保证任务不丢、不重复、不失控。”为什么必须异步先讲清动机“先说为什么要异步。CPS 决策不是用户点一下就要马上返回的场景它是商家在后台批量操作触发的——比如商家一次要对几十上百个商品做佣金建议。而这一条链路上要调三个 Sub-Agent 加一个仲裁全是模型推理RT 高、还可能超时、被限流。如果同步做商家点一下就要等几十秒还随时可能因为模型抖动直接失败。所以必须把‘商家触发’和‘模型计算’解耦商家操作秒级受理模型计算放到后台异步跑。”具体怎么做核心按技术点讲1. 任务受理 落库同步部分“商家触发 CPS 决策后页面是秒级返回‘已提交’的商家不用盯着等可以先去干别的。后面是异步计算三个 Sub-Agent 并行分析、仲裁收敛、安全阀校验。校验通过后结果写回任务表状态从‘待执行’流转成 PENDING。这个状态流转到 PENDING 的那一刻就是结果可用的信号。系统会在这个节点发一条任务完成事件通过 MQ 解耦后消费端调内部消息推送给商家推一条通知告诉他‘CPS 建议已生成点击查看’。但通知是辅助不是保证。真正保证商家能拿到结果的是任务状态——商家任何时间进页面刷新查一下任务状态只要已经是 PENDING结果就一定在。所以即使通知丢了商家也能看到结果。设计原则就是通知负责让商家更快知道状态机负责保证结果一定可拿。如果被追问“通知怎么实现”就这一句“任务状态转 PENDING 后发一条完成事件到 MQ消费端监听到后调内部消息推送服务给商家发站内通知失败有重试。但通知是尽力而为丢了不影响正确性正确性靠任务状态机兜底。”要不要做个倒计时给商家看我当时的判断是不做百分比进度条做阶段状态提示 预估时长区间。原因是 CPS 决策的耗时大头在模型推理而模型 RT 是不可预测的三个 Agent 又是并行调用根本没法线性地算出一个可靠的百分比。硬造一个进度条就是给商家一个假的确定性一旦卡住反而引发焦虑和投诉。“商家触发后我直接返回‘已提交’告诉他结果算好了会在页面展示不用盯着等。因为 CPS 决策是商家的低频操作不是实时交互他提交完通常会去干别的事。结果就绪的感知靠两件事兜底一是任务状态——从待执行转成 PENDING 就代表算完了商家下次进页面刷新就能看到二是完成通知——任务算完会触发通知提醒商家来看。我没做进度条。原因是模型推理耗时不可预测硬做百分比是假进度反而引发焦虑而这种低频场景‘稍后查看 通知’已经能满足需求没必要为一个非实时操作投入进度展示这种重交互。”2. 一商品一 MQ消息怎么拆“到异步执行的时候我不是把一批商品打包成一条消息发出去而是一个商品一条 MQ 消息。这么拆有三个原因第一故障隔离。如果一个商品处理挂了它只影响自己这一条不会拖累整批第二独立重试。哪个商品失败我能精确地只重试它而不是整批重来第三并行消费。不同商品的消息可以被多个 Consumer 并行处理吞吐上得去也方便削峰。”a. 同步受理阶段拆商品、逐条发消息“商家触发时同步段先落一条主任务然后把这次要处理的商品列表拆开每个商品发一条独立的 MQ 消息。商家秒级返回消息就陆续进了队列。”b. 消息体长什么样关键面试会问“每条消息的 body 很轻只带两个关键 IDtaskId主任务 ID用于聚合和追踪itemId商品 ID商品详情这些重数据不放在消息里消费端拿到 itemId 之后自己再查避免消息体过大也保证消费时数据是最新的。”这个设计点很重要消息只传 ID不传大对象这是消息设计的基本原则。c. 消费端怎么处理一条消息“消费端监听这个 topic每条消息对应一个商品独立处理拿到 itemId查商品详情和该商家、该商品的相关数据组装这个商品的三个 Sub-Agent 输入并行调三个 Sub-Agent仲裁收敛安全阀校验结果写回这个商品的任务明细状态流转。一条消息走完就是一个商品的 CPS 决策闭环。”d. 为什么消息体只放 ID深挖加分点“消息只放 taskId 和 itemId不放完整业务数据有两个原因第一消息体要小。一批几百上千个商品如果每条消息都塞满详情消息总量会很大占带宽和存储投递也慢。第二数据要新鲜。商品信息是变的库存、下架、佣金都可能变消费端拿到消息那一刻再去查保证用的是最新数据而不是消息投递那一刻的旧快照。”e. 批量发消息的性能问题大概率被问“商家一次选几百个商品怎么发这几百条消息用 MQ 的批量发送能力循环组装消息体攒一批批量投递而不是一条一条发、每条都等 ACK。这样发送端吞吐上得去商家受理响应也快。批量发不影响‘一商品一消息’的设计——只是投递时打包逻辑上还是每个商品一条消息。”f. 消费失败、重复、顺序怎么处理串联前面的口径“一条消息失败只重试这一条不连累其他商品。重复消息靠消费端的幂等去重以 taskId itemId 做唯一键。顺序我无所谓——因为每个商品的 CPS 决策是独立的A 商品先算完还是 B 商品先算完结果互不影响所以不需要保证消息顺序这反而让消费端可以放心并行扩容。”3. Redis 批次级幂等防重复“幂等我分两层。幂等我分两层。第一层批次级用 Redis以批次 ID 做 key第一次 setnx 占位后续同样的批次直接拦掉防的是商家重复提交、上游重复调用保证一批任务只被创建一次。第二层商品级因为 MQ 是至少一次投递同一条消息可能被投递两次所以消费端用 taskId itemId 做唯一键处理过的商品直接跳过保证一个商品只被算一次。4. Consumer 动态限流防打爆模型除了幂等还有一个独立的限流机制。因为下游模型服务有并发上限Consumer 无脑调模型会把它打爆。所以我做了动态限流阈值不写死根据模型服务当前的 RT、错误率、积压情况动态调整压力大就降消费速率缓解了就放量。它解决的是‘别把模型打爆’和幂等解决‘别重复处理’是两件事。5. 状态机任务的生命周期“任务处理完之后状态会流转。我设计的状态是CREATED → PENDING → ACCEPTED / IGNORED / EXPIREDACCEPTED是商家采纳了这个佣金建议IGNORED是商家看了但没采纳EXPIRED是这个建议过期了——因为市场水位会变佣金建议是有时效的商家如果一直不处理过了一定窗口期这个建议就不能再用了得标记成过期不能无限期挂在那。用状态机的好处是任务走到哪一步、是成功还是失败还是过期都清清楚楚不会出现‘半成品’状态。”6. 任务扫描 监控告警兜底“最后是兜底。异步链路最怕的是消息丢了、消费失败了、状态没更新任务卡在 PENDING 没人管。所以我加了定时扫描周期性去扫那些超时还挂在 PENDING 的任务发现异常就主动处理配合消费进度追踪和完成通知兜底。监控这边盯着 MQ 积压、消费延迟、任务超时这几个指标一有异常就告警。正常链路靠消息驱动异常链路靠扫描兜底两条腿保证任务最终能收敛。”收一句“这一层做完CPS 决策就从‘模型能算出来’变成了‘算出来能可靠落地’。商家触发秒级返回后台异步稳定执行任务可追踪、可恢复、可告警。这也是模型能力工程化的关键一步。”深挖清单背熟Q1为什么不用同步非要异步因为 CPS 是商家批量操作触发的一次几十上百个商品每个都要走三个 Sub-Agent 加仲裁的模型推理RT 高还容易超时。同步会阻塞商家操作模型一抖就整个失败。异步把受理和计算解耦商家秒级返回计算后台跑。Q2为什么一商品一 MQ不能一批打包发三个原因故障隔离单商品失败不拖累整批、独立重试精确重试失败项、并行消费多 Consumer 并行提吞吐。打包发的话一个失败可能整批重来而且削峰能力差。Q3Redis 批次级幂等具体怎么做的key 是什么key 用批次 ID第一次触发就 setnx 占位重复触发直接拦截。防的是商家重复点击和上游重复投递保证一批任务只被创建一次。Q4幂等为什么分“批次级”和“商品级”两层批次级是入口去重防止整批被重复触发商品级是消费端去重防止单个商品被重复消费处理。两层防的是不同的重复来源缺一层都会出问题。Q5“动态限流”的动态体现在哪固定限流不行吗固定限流太死——阈值定低了浪费模型能力定高了又把模型打爆。动态限流是根据模型服务当前的 RT、错误率、积压情况实时调整消费速率压力大就降速缓解了就放量自适应当下负载。Q6状态机为什么要有 EXPIRED 这个状态因为佣金建议是有时效的市场水位一直在变。商家如果长时间不处理这个建议就过期了不能再沿用。EXPIRED 状态保证任务不会无限期卡在 PENDING也有利于后续分析和告警。Q7过期任务扫描和前面的补偿任务是啥关系是同一个兜底思路。正常链路靠消息事件驱动但如果消息丢了、消费失败、状态没更新任务就会卡住。定时扫描就是去发现这些“卡住”的任务主动处理或告警。补偿是发现缺了补上扫描是发现异常了处理两者配合保证最终一致。Q8消息真丢了怎么办怎么保证不丢几层保障MQ 消费端 ACK 重试状态机记录任务进度定时扫描兜底超时未处理的主动捞起来重新推进。不可能百分百不丢但要保证丢了能发现、能恢复最终收敛。Q9可追踪、可恢复具体体现在哪可追踪任务有唯一 ID状态机记录每一步走到哪进度有记录监控盯着积压和延迟。可恢复失败任务可独立重试卡住任务可被扫描发现并重新推进完成有通知兜底。4.4 Result结果“最终的结果是形成了一套稳定、可解释、可执行的 CPS 决策链路。商家看到的不是一个黑盒数字而是有理由、有置信度、经过安全校验的佣金建议。更重要的是机制层面模型即使输出异常也进不了业务执行链路从根上把模型的不确定性拦在了外面。这是这个方案最核心的价值——不是让模型更聪明而是让模型可用、可控。”采纳率数据怎么样“这块我目前更多是在做能力建设和样本沉淀还没有到能对外报‘采纳率提升 X%’的程度。但我可以讲几个已经观察到的定性结论一是采纳率在不同类目、不同商家类型之间差异很大所以后面策略是按分场景去调的二是我们发现市场竞对 Agent 在某些类目下推荐值偏激进商家接受度偏低这类问题通过决策留痕是可以精确定位到具体 Agent 的——这个‘能定位到是谁算错了’的能力本身就是这套链路最大的价值。”深挖清单1、为什么用 Agent 不用单个 LLM“我先澄清一个点Agent 不是比 LLM 更高级的东西Agent 的底座就是 LLM。所谓 Agent本质上是一个 LLM 专属的输入数据 专属的职责边界 固定的输出契约封装成一个有明确分工的单元。所以问题不是‘用 LLM 还是用 Agent’而是‘用一个LLM 把三件事全干了还是用三个各自聚焦的 LLM 单元各干一件事再收敛’。我选的是后者。”2、三个 Agent 怎么实现“实现上每个 Agent 就是一次独立的模型调用但它有几个东西是专门定制的。”1. 每个 Agent 有独立的 System Prompt职责边界“三个 Agent 的 system prompt 是完全分开写的。达人价值感知这个 Agent 的 prompt我只让它关注达人漏斗——选品覆盖率、选品到发布的转化、发布覆盖率让它从‘达人产能拐点’这个角度去判断明确告诉它‘你只回答达人能不能带得动不要考虑商家和市场’。历史效能匹配的 prompt我只让它看商家×达人历史合作数据、等级分布、GMV 贡献告诉它‘你只回答这个商家过去谁带有效’。市场竞对穿透的 prompt我只让它看类目、价格带、竞品佣金水位告诉它‘你只回答市场给多少、竞争激不激烈’。每个 prompt 都把它的职责边界卡死这是最核心的一步。”2. 每个 Agent 有独立的输入数据喂的数据不一样“输入也是各自准备好的。达人 Agent 喂的是 CPS 分桶、达人漏斗数据效能 Agent 喂的是商家历史合作结构、达人等级、GMV市场 Agent 喂的是类目价格带的竞品水位。三个 Agent 拿到的上下文是互不重叠的这样它们不会被无关信息带偏。”3. 每个 Agent 有固定的输出契约结构化输出“输出我也做了约束三个 Agent 必须返回统一的结构推荐值、理由、置信度。这样后面的仲裁层才能统一处理。如果它们输出格式不对会被拦下来重试或降级。”3、三个 Agent 是用什么框架实现吗“没有用 LangChain、AutoGen 这种重型 Agent 框架是后端自研的一套轻量编排。”为什么不用框架先讲动机体现选型思考“我当时评估过两个方向。一个是引入现成的 Agent 框架。但我们的场景其实很固定——就是三个 Sub-Agent 并行算一个仲裁 Agent 收敛拓扑不复杂没有需要动态编排、工具调用、记忆管理这些重型框架的核心能力。更关键的是我们整个服务端是 Java 技术栈模型调用走的是公司内部 KRPC 协议。LangChain 这类框架是 Python 生态的硬接进来要跨语言调用、要额外维护一套 Python 服务依赖和复杂度都上去了收益却很小。所以我们选了自研轻量编排把该管的东西管住不该引入的复杂度不引入。”自研编排具体长什么样核心“实现上我把每个 Agent 封装成一个独立的调用单元它有几个固定组成部分第一专属的 prompt 模板带版本号记录 prompt_version第二输入组装每个 Agent 需要的数据在调用前单独拼好第三输出解析和校验模型返回后先做结构化解析校验字段完整性和类型第四超时、重试、降级这些工程保障每个 Agent 单元都自带。编排层是工作流式的流程很清晰任务触发 → 并行调三个 Sub-Agent → 收集三个结果 → 调中央仲裁 Agent → 安全阀校验 → 落库。三个 Sub-Agent 之间没有依赖所以并行调用压延迟串行的只有仲裁那一步。”自研但没漏掉框架该有的能力关键加分点“虽然是自研但我没有把框架该解决的问题丢掉。框架核心解决的其实是三件事我都在自研层做了一是可观测——每个 Agent 的输入、输出、prompt 版本、耗时都有记录出问题能追踪二是可灰度——prompt 和权重都能通过 Kconf 配置中心灰度发布不用改代码上线三是可降级——单个 Agent 失败不影响整体仲裁层能用剩余结果继续收敛。所以这套东西不重但该有的工程能力都齐了。”收一句“本质上是‘按需选型’——场景简单就不上重型框架但把框架该提供的可观测、可灰度、可降级这些能力用更轻的方式自己补齐了。”Q1为什么不直接让一个 LLM 输出 CPS“理论上一个 LLM 当然能同时分析达人、商家、市场但工程上我不这么做有四个原因。”原因一上下文污染判断依据会互相干扰“一个 LLM 同时看三份异构数据它在判断市场水位的时候脑子里还装着达人漏斗的数据判断就容易被别的维度带偏。比如市场其实偏红海但它看到达人产能数据不错就可能给出一个偏激进的建议。三个维度搅在一起你分不清它最终是听了谁的。”原因二没法归因出了问题定位不了“假设最终 CPS 建议出了问题——商家采纳率特别低。如果是单模型我只能说‘这个模型整体不行’然后重训黑盒。但拆成三个 Agent我能通过决策留痕看到是哪一个 Agent 给了激进的建议、是哪一个置信度虚高精确到具体 Agent 去调它的 prompt 或权重。这个可归因性是单模型给不了的。”原因三不能独立调优牵一发动全身“业务上达人维度、市场维度的策略经常要单独调。比如我发现市场 Agent 在某个类目下判断偏激进了我只想改市场这一个。单模型的话改一次 prompt 会影响所有维度拆开之后我单独调市场 Agent 的 prompt其他两个完全不受影响。这个独立演进能力是后续策略迭代的基础。”原因四单点失败变成局部失败“单模型如果一次调用超时或者输出格式错误整个 CPS 决策就废了。拆成三个 Agent 并行其中一个失败了仲裁层还能用剩下两个的结果继续收敛做降级处理。系统的鲁棒性更好。”“所以总结就是三个 Agent 本质是三个聚焦的 LLM 单元各自有独立的 prompt、输入、输出契约。用三个而不是一个核心收益是可归因、可独立调优、可降级。而它们各自‘判断不了全局’的短板正好由第二层的中央仲裁 Agent 来补——仲裁层负责把三个局部判断收敛成一个全局决策。”Q2三个 Agent 结果冲突了怎么办答靠仲裁的置信度评估 动态权重。置信度高的 Agent 权重大天然占主导如果置信度接近再叠加业务规则比如采纳率红线、绝对收入保底来最终拍板必要时走阶梯调整策略避免一次性大幅跳变。Q3置信度是怎么算的会不会模型自己乱报高置信度答置信度不是我让模型“自己说自己有多信”而是仲裁层重新评估的综合样本量、方差/稳定性、达人覆盖度、数据完整度四个客观指标。模型自己报的置信度只作为参考输入之一不直接当作权重。Q4为什么安全阀要卡“单次涨幅 ≤2%”这么具体的数答CPS 是商家的经营决策一次性涨太多商家接受不了、也容易造成商家流失分步阶梯调整更平滑商家有适应期。2% 是结合业务采纳情况定出来的经验阈值通过配置中心可以灰度调整。Q5模型幻觉具体是什么样安全阀怎么拦答比如模型返回一个 500% 的佣金、或者 JSON 字段缺失、或者类型不对数字变成字符串、或者在商家不该调佣金的场景也返回isAdjustCpstrue。安全阀在解析和边界校验阶段就能拦下来非法结果直接丢弃不落库。Q6如果三个 Agent 置信度都很低怎么办答置信度整体偏低说明数据支撑不足比如新商品、样本少这时候不应该硬给一个激进建议。仲裁层会倾向于保守策略——维持当前值或小步调整而不是强行输出一个高置信度结果。Q7为什么用 Multi-Agent 而不是直接训练一个回归模型答CPS 决策涉及大量非结构化信息达人产能拐点、市场蓝海红海判断这些不是简单的数值特征能完全表达的用 LLM 的语义理解能力更合适。但 LLM 不可控所以用 Multi-Agent 拆解 工程安全阀来补它的短板。等将来积累足够的高质量决策样本可以再往自动校准方向演进呼应第 4 点。Q8这一层的耗时和成本怎么控制答整个决策是异步的MQ 异步任务不阻塞商家在线请求三个 Agent 是并行调用的再汇总到仲裁串行部分只有仲裁这一步。成本上CPS 决策是商家操作触发的低频场景不是每次用户访问都算单次成本可控。Q9你怎么知道这个权重公式是对的答权重公式是置信度归一化Confidence / ΣConfidence这是初始的、可解释的基线最终效果通过第 4 点的反馈回流来验证——采纳率、GMV 等指标反过来调整 Agent 权重和阈值。也就是说公式本身简单透明但它不是拍死的会被业务结果持续校准。Q10Agent 和普通 LLM 调用到底区别在哪“区别在‘封装’。普通 LLM 调用是一问一答Agent 是给它一个明确的职责、专属的数据、固定的输出格式让它像一个专职员工一样只干一件事。底座还是 LLM但加了角色约束和输出契约。”Q11你用了 LangChain / AutoGen 这些框架吗“它们核心解决的是工具调用、多步推理、记忆管理、动态编排这些复杂场景。我们的场景用不到这些能力所以没引入。但我会关注它们的设计思路比如 Agent 的角色定义、工具抽象这些理念我在自研编排里有借鉴。”“没有引入重型框架。我们的场景相对固定三个 Agent 就是三路并行调用加上仲裁层编排逻辑不复杂用轻量工作流就够。重型 Agent 框架反而会引入额外的复杂度和依赖这里用不上。”这是诚实且加分的答法——不硬套框架Q12三个 Agent 的 prompt 是固定死的吗“不是。prompt 有版本管理记录 prompt_version。后面通过反馈回流发现问题时会针对性调整某个 Agent 的 prompt再通过灰度验证。这就是第 4 点里讲的策略迭代的一部分。”Q13三个 Agent 是并行还是串行“并行。它们之间没有依赖关系各自独立算结果一起进仲裁层。串行的只有仲裁那一步。并行是为了压延迟。”Q14如果两个 Agent 结论相反怎么办“靠仲裁层的置信度评估和动态权重。置信度高的占主导。如果置信度接近再叠加业务规则拍板必要时走阶梯调整不会让 CPS 剧烈跳变。”Q15自研编排和框架比有什么劣势“劣势主要在通用性和扩展性——如果将来 Agent 数量变多、要支持动态工具调用、复杂多步推理自研的扩展成本会上升那时候可能就要引入框架了。所以这个选型是看当前阶段不是一劳永逸。这也是为什么我把它做得模块化方便以后演进。”Q16你这个编排是怎么调度多个 Agent 的“是一个轻量的工作流一个编排器串起整个流程。触发后并行调用三个 Sub-Agent用线程池或异步等待它们的结果收集齐了再调仲裁 Agent。每一步的结果和状态都有记录。”Q17为什么要自己写直接用 Spring 的异步能力不行吗“底层就是用了 Spring 的异步和线程池。我说的‘自研编排’是指在这之上封装了一套 Agent 单元抽象和工作流编排逻辑——prompt 管理、输入组装、输出校验、超时重试、降级这些。不是从零写一个调度框架而是用现有基础设施把 Agent 的工程化能力补