15. 没做好的地方，和重做会怎么改#

三类一张表#

项目文档里明确写了「不覆盖」的#

真实平台 OAuth、下单 / 支付 / 物流、精细汇率对账、多模态图像检索、反爬风控、库存一致性、隐私合规。这些一开始就没打算做，面试时直接说是定位，不用解释成遗憾。

同一段文字还写着「不做训练 / 微调」，但后来训练做了三件（第 17 章）。文档没有跟着改，面试时以第 17 章为准。

怎么组织回答#

先说一条最大的，说清根因和改法，再说「还有几条小的，要不要展开」。不要一口气报十条，面试官记不住，也显得项目很糙。

出处：CLAUDE.md:29（不覆盖列表）

最大的遗憾是哪一条？

商品没有材质、重量这类结构化属性。它同时卡住了硬约束过滤、运费估算和评测里的一条红线。重做会在清洗阶段先把属性抽出来。

这些不足影响线上用户了吗？

影响最大的是「不要塑料」这种约束会漏判，和搜手机出配件。前者只能靠标题关键词，后者已经放到收尾那次模型调用里判了。

为什么不先把数据补好再做 Agent？

项目重点是 Agent 主线和基础设施，数据用的是公开数据集。属性抽取要跑一遍全库，成本不小，当时排在后面。

再给你一个月先做哪个？

先做属性抽取写进向量库 payload，材质、重量、整机还是配件一次解决三个问题。

现在有的#

• 确认卡写进 trade_confirmations 表，刷新页面、重启进程都还在。

• 商品信息按 id 从本轮候选表取，模型不传标题和价格，避免记错要写进数据库的钱。

• 幂等键由「用户 + 会话 + 商品和数量」派生，同一轮重试不会成两单。

• 订单只能在 CONFIRMED 状态取消，取消前要先查订单。

缺的和重做怎么补#

出处：app/tools/create_order.py:1（模块说明写明「mock 交易域」、决议只走 HTTP）、app/trade/usecases.py:41（幂等键）

模型能不能绕过确认卡直接下单？

不能。工具没有「已确认」这个参数，落库的接口只有页面按钮会调，写权限也由 PermissionEngine 单独放行。这是第 04 章讲的机制。

接了支付以后，回调重复怎么办？

支付流水号在订单表做唯一约束，重复回调查到已处理就直接返回成功。

库存超卖怎么防？

两种做法：数据库里 UPDATE ... WHERE stock >= n 靠行锁；或者 Redis 用 Lua 原子扣减，再异步同步到数据库。

确认卡 30 分钟有效期怎么定的？

经验值，代码里没有推导依据。重做会按用户从看到卡到点按钮的实际分布定。

重量为什么永远是默认值#

候选商品结构里有 weight_kg 字段，但从数据到候选的整条路上没有任何地方给它赋值，永远是空。运费估算拿到空就用 0.5 公斤。一个行李箱和一副耳机算出来一样的运费。

做对了的一点#

关税先判「发货国是否等于收货国」，国内单直接免税。不然 Amazon 美国发货寄到美国也会被收一笔进口税。

出处：app/recall/fx.py:4（静态汇率表）、app/recall/duty.py:21（税率表）、:40（默认 7%）、:116（国内单先判）、app/recall/shipping.py:38（默认 0.5 公斤）、app/tools/schemas.py:71（weight_kg 默认空）

汇率过时会有多大影响？

主流货币一年波动多在个位数百分比，比价结论一般不会反转。但项目定位就说了不做精细汇率对账，面试时直接承认。

接了汇率 API，它挂了怎么办？

缓存上一次成功的值继续用，并在结果里标「汇率时间」。现在的静态表就是最后的退路。

重量先验从哪来？

两个来源：品类知识库里每个品类的典型重量；或者从标题抽「500g」「2kg」这类数字。抽不到再用品类默认。

为什么关税命不中给 7% 而不是 0？

给 0 会让跨境商品显得便宜，用户到手才发现要补税。宁可估高一点。

现在的处理#

• 「不要 X」进排除关键词，命中标题就淘汰。

• 「喜欢 X」进偏好关键词，命中只加分，不淘汰。

• 正向没有硬淘汰档：数据没有可靠的材质字段，只保留命中的会误杀一大片。

评测上的后果#

评测集里有一条「不能出现塑料制品」的红线细则。标题不写材质时，judge 和系统都判不出来。这条细则的分数在 0 和几十分之间来回跳，和改动无关，所以决定不当回归指标。

重做方案#

出处：app/tools/planner.py:343（正向不做硬淘汰的原因）、:381（材质、颜色填排除关键词）、app/recall/category_kb.py:8（品类知识库有「该看哪些维度」，没有商品级取值）

为什么不训一个材质分类器？

没有标注数据，而且材质值域开放，分类器不如直接让模型抽取。抽取一次写进库，线上零成本。

标题关键词误杀怎么办？

只做排除不做保留，误杀范围就限制在「标题明确写了塑料」的商品。漏掉的比误杀的多，这是有意的取舍。

这算算法的问题还是数据的问题？

数据的问题。算法层能做的是不假装能过滤，在结果里如实说「按标题匹配」。

抽取错了怎么发现？

抽样人工核对，加上线上用户反馈。抽取结果带置信度，低置信度的不参与过滤。

现状#

• 全库 138 万点。Amazon 占比具体数字待补，代码注释原话是「占绝大多数」。

• 平台参数是枚举：all、amazon、walmart、shein、lazada、shopee。没有 eBay。

• 「all」等于本轮启用的全部平台合到一起搜，不做平台配额。

为什么决定不修#

跨平台比价靠的是主环同一轮发多条搜索，每条指定一个平台，框架并发执行。这样每个平台都有自己的召回结果，比价在这一步已经成立。「all」只是用户没说平台时的默认。

重做方案#

建库时按平台平衡采样，或者检索时按平台分桶各取前 k 条再合并。代价是各平台的相似度分数不可比，合并后要重排。

出处：app/recall/qdrant_store.py:280（「库里 amazon 占绝大多数」）、app/tools/item_search.py:142（eBay 剔除原因）、:146（平台枚举）、:368（「all」= 启用平台集合）

用户没说平台，其它平台怎么露面？

提示词里有一段并行策略，告诉模型跨平台时同一轮发多条搜索、每条指定平台。这是模型的决定，不是机制保证。

为什么不建库时就平衡采样？

其它平台的数据量本来就少，平衡采样等于把 Amazon 砍掉大半，召回质量会掉。分桶取前 k 条更合适。

分桶合并后怎么排？

各平台的向量分数不可比，合并后过一遍 reranker 统一打分，第 11 章讲过。

eBay 不能只用标题和价格进库吗？

可以，但描述全空、卖家名掩码，向量只靠标题，质量会明显差一截。当时判断不值得。

数据有多脏#

整机和配件在同一个类目；有电视被标成游戏机类目。商品卡里刻意不显示类目，因为显示出来只会误导用户。

两个失败方案#

现在的做法#

收尾工具那次模型调用本来就要逐件读标题写推荐理由。让它同时输出「和本轮品类明显不符的商品 id」，排版时剔掉。多出来的成本接近零。搜索结果展示头 5 条标题，也是为了让主环有机会自己察觉跑偏。

出处：app/tools/shopping_summary.py:84（类目值域乱）、:199（为什么放收尾判）、:210（off_intent 字段）、app/tools/item_picker.py:179（分数交叠的实测数据）、app/tools/item_search.py:108（展示 5 条的原因）

交给模型判，会不会误杀真商品？

会有。但它是在读完标题、写完理由之后判，信息比任何规则都全。实测里它自发写出过「这是配件」，所以才把这个判断正式化。

为什么不在挑货那一步判？

挑货是纯确定性打分，没有模型。要判「这是不是配件」必须读懂标题，只有模型能做。

重做重新分类用什么？

清洗阶段用模型按标题做「整机 / 配件」二分类，再结合价格分布交叉验证。结果写进 payload，检索时直接过滤。

这个问题怎么发现的？

评测集里的手机和相机两条 query 出了坏结果，逐条看候选才定位到类目字段。

两条入口共用一个实现#

两条路都调同一个 compare_items，输出结构一样，不会出现两套逻辑。

三条 id 检查#

只收本会话展示过的商品 id；会话归属校验；商品信息从候选表按 id 取，前端不传标题和价格。

重做#

接口返回后，把对比结论作为一条助手消息追加进会话状态文件。下一轮模型就能引用「刚才比的那件」。

出处：app/api/orders.py:190（compare_endpoint，文档字符串写明「不走 AgentLoop」和原因）

用户下一轮说「刚才比的那个便宜的」怎么办？

现在模型看不到那次对比，只能靠候选表里的商品猜。这就是要重做写回会话的原因。

为什么不直接往会话里塞一条隐藏的用户消息？

可以，但用户消息会触发一整轮主环，几十秒往返又回来了。写一条助手消息更轻。

这种「按钮直达」的模式还用在哪？

找相似商品也是 HTTP 直达。原则是：用户意图已经完全确定的操作，不经过 Agent 规划。

怎么防止拿别人会话的商品 id？

会话归属校验先过，再查本会话的候选表，不在表里的 id 直接拒绝。

文件里存什么#

整个 AgentState 序列化成 JSON：消息、框架压缩后的摘要、会话级偏好。消息表只给前端侧栏回看，不参与恢复。

为什么不从消息表回放#

消息表是给人看的投影，工具结果已经被排版过。用它重建模型上下文，要把工具结果反推回原始结构，容易错。第 02 章讲过，以前有 5 份产物和一条回放腿，后来都删了，只留这一份。

现在缺什么、重做怎么补#

出处：app/agent/orchestrator.py:12（读坏即空开局、不回放消息表）、:93（恢复是加成不是前提）、:104（解析失败记 warning）、:113（先写临时文件再改名）、:121（写失败只记日志）

用户刷新页面会丢上下文吗？

不会。每轮结束都写文件，刷新后下一轮从文件恢复。丢的只有正在跑的那一轮。

为什么不每轮都存数据库？

文件是几十 KB 的整块 JSON，写文件最简单，单机部署够用。多副本时再改成数据库，这是没做完的部分。

写到一半进程被杀会怎样？

临时文件留一半，正式文件还是上一轮的完整版。改名是原子操作，所以正式文件不会是残片。

50 轮以后文件会不会太大？

框架在上下文超过阈值时会压缩成摘要，摘要也在这份文件里，第 07 章讲过。

第一条为什么会发生#

前端用一个布尔值「这是不是重连」决定要不要发任务请求。首连的 onclose 里，只要状态还没到结束，就以「重连」身份再连一次。而重连分支的设计前提是「任务已经在后台跑」，这个前提在首连早断时不成立。

出处：frontend/src/hooks/useShoppingXTask.ts:429（重连不发请求）、:427（状态设为 running）、:592（onclose 以重连身份再连）、app/api/server.py:928（ping 分支）、app/api/connection.py:50（一会话一条连接）

为什么说没复现？

这是读代码推出来的，触发条件是握手成功后、服务端发 ws_ready 前断线，本地很难碰到。面试时如实说是代码审查发现，没有线上记录。

换成 SSE 会不会更简单？

会。浏览器发回后端的消息只有澄清回答一种，走 HTTP 就够。第 15 章的答法是「SSE 也能满足」。

慢客户端拖慢 Agent 怎么解？

发送放到独立队列，Agent 只往队列里放。队列满了先丢掉进度类事件，保留结果类事件。

两个标签页应该都收到吗？

应该。按会话存一个连接列表，广播给所有连接。现在是后连的顶掉先连的。

断路器#

• 用连续失败计数，不用失败率。一次购物只调几次外部服务，滑动窗口样本太少，失败率会被一两次抖动放大。

• 状态读写都在同步段，单线程 asyncio 下计数不会错。

• 半开期没有限制成单探测。修法：半开时发一个令牌，拿到令牌的请求才能探测，其余直接拒绝。

幂等键#

漏洞：同一会话里真想买第二份，键完全一样，会被合并成一笔。修法是前端每张确认卡生成一个请求 id 并持久化，幂等键加上它。

出处：app/utils/circuit_breaker.py:15（连续失败计数的理由）、:19（半开未限单探测，注释自认）、app/trade/usecases.py:41（幂等键组成）

半开放多个探测，最坏会怎样？

下游还没恢复时多打过去一两个请求，多一两次失败。对低频外呼没有实际影响，所以当时没改。

幂等键存在哪里？

订单表上做唯一约束。重复请求插入失败，查出已有订单直接返回。

客户端请求 id 丢了怎么办？

确认卡本身在服务端有记录，请求 id 可以跟卡一起存。刷新页面后从卡里取回。

为什么不用 Redis 做幂等？

订单本来就要写数据库，唯一约束是免费的。多一个 Redis 只是多一处会不一致的地方。

另外线上 Redis 是单机、没有从库、没有配 maxmemory。这三条依据是对 docker/ 目录搜索无结果，容器有没有被手工改过配置没有核对。

怎么讲这些#

说明是代码审查得出的判断，没跑过 EXPLAIN、没做过压测。当前流量下都不是瓶颈，所以排在后面。面试官要的是你看得出来，不是你全改了。

出处：app/db/models.py:218、:222、app/api/accounts.py:145、app/recall/search_cache.py:46、:218、:232

随机主键真的有影响吗？

写入量小时几乎没有。量大了随机插入会让 B+ 树页分裂、缓存命中下降。改成有序 id 是常规做法。

TTL 不加随机会怎样？

同一批缓存同时过期，请求一起打到向量库。加几十秒随机量就能错开。

锁不比较值，最坏后果？

误删别人持有的锁，多一次并发重建，多查一次向量库。这把锁只为省一次查询，后果可接受。

Redis 挂了系统会怎样？

各处都有降级：缓存失效直接查库，令牌桶和断路器放行。第 14 章讲过，但停 Redis 的演练没有做过。

三个数字取自第 17 章引用的提交正文，本地没有评测原始文件。

收藏加分权重#

挑货打分里有一项「收藏推断的偏好命中」，权重默认 0.2，代码注释写的是弱正向。同一个词至少出现在 2 件收藏里才算偏好。0.2 是拍的初值，没有用评测集扫过。

怎么标定#

固定评测集，权重从 0 到 0.5 扫几个点，看端到端得分曲线。没有峰就说明这一项没用，直接删。

出处：app/tools/item_picker.py:165（PICK_W_AFFINITY 默认 0.2）、:784（弱正向加分）、app/memory/affinity.py:34（至少 2 件证据）、docs/handbook/11、12（训练结果）

离线涨了线上不换，训练是不是白做？

不是。结论是「训练目标要从线上用途倒推」，这个教训直接决定了重做怎么选目标。模型和数据都留着。

训练目标怎么和线上用途对上？

先写清线上这一步的输入输出和判定标准，再用同一个标准做离线评测集。离线指标和线上指标是同一个，才算对上。

为什么权重没标定就上线？

它是弱加分，最坏只影响并列商品的顺序。先上线收集收藏数据，有数据了再标定。

GPU 充足会先做哪个？

planner。它决定意图拆解，上游错了下游全错。reward 加上域判定项再训一轮。