last30days Amazon 评论抽取预算修复实战把富化车道从收尾阶段提前到检索时刻的完整实现解析【免费下载链接】last30days-skillAI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary项目地址: https://gitcode.com/GitHub_Trending/la/last30days-skill关联实现计划docs/plans/2026-08-14-fix-amazon-review-budget-plan.md2026-08-14状态 Implemented导读本文深入解析 last30days 技能中一次典型的多源研究引擎预算修复在一次实测的 Bentgo 主题全源运行里Amazon 评论富化车道因在管线收尾阶段才启动只剩 11 秒面包屑预算导致 3 次 Bright Data 拉取全部超时、积分被消耗却拿不到一条评论文本。修复方案没有采用看似合理的把剩余预算垫高到下限策略而是从根上改变了评审富化的启动时机——在 Amazon 搜索返回后立刻并行拉起评论并引入低于有效下限即整条跳过的预算语义与PARTIAL状态上报。读完本文你将掌握这套可量化的墙钟预算公式、调度位点改造、降级状态契约以及对应的回归测试设计。一、问题现场一次实测运行暴露的预算数学错误该计划记录的问题来自 2026-08-14 的一次 Bentgo 主题运行症状链路非常清晰搜索阶段正常多源全量运行里Amazon 搜索列表正常返回12 个产品含星级与评分数量富化车道几乎空转日志显示pulling up to 50 reviews for 3 products (budget 11s)随后lane deadline 11s hit; dropped 3 straggling pull(s)积分被白白烧掉Bright Data 三次都以 11s 超时告终零条评论文本返回但信用点数照扣对照实验证明问题不在拉取质量单独只跑 Amazon 的重跑拿到了完整的 180s 预算124s 内完成评论正常落地。根因被定位到预算计算公式见 amazon.py 中的_remaining_lane_budgetremaining FOREGROUND_CONTRACT - elapsed - RENDER_MARGIN即评审车道的可用预算为min(LANE_DEADLINE180, max(0, FOREGROUND_CONTRACT300 - elapsed - RENDER_MARGIN20))。问题在于富化排在所有其他源之后执行当检索阶段累计耗掉约 269s 后才轮到 Amazon 富化时300 - 269 - 20 11预算只剩 11 秒——一个注定失败的数字。二、为什么下限垫高的修法是错的第一直觉是给公式加一个下限max(120, leftover)。计划文档明确否决了这条路理由非常硬核——它会杀死整份报告而非单单一个源若在 elapsed269 时把预算垫高到 120s本次运行总时长会涨到约 389–449 秒宿主host对 Bash 调用的前台合约是300 秒见 SKILL.md 中约定的timeout 300000即 300000ms 5 分钟超时会让整份研究简报失败损失远大于丢失一个源的评论富化。因此正确的判断是这次实测失败的本质是评论车道何时启动而不是拉取质量。既然 Amazon 单独运行时 124s 内就能完成全部拉取那么在完整运行中搜索早就返回了产品列表评论却要干等所有其他源以及 Phase 2/2b 跑完最后才拿到 11 秒。修复应当让富化尽早并行启动而不是在收尾处与整个 300s 合约做无谓搏斗。三、修复设计五条原则计划给出了五条互相咬合的构建原则在搜索返回后立刻启动富化enrich_with_reviews从收尾阶段挪进_retrieve_stream的 Amazon 分支内与其他源的 future 并行执行传入真实的elapsed time.monotonic() - run_started把run_started线程化传入 retrieve。30–90s 的搜索结束后剩余预算为 190–250s再钳制到 180sAmazon 单独运行时行为保持不变。finalize 只做缺失才补_finalize_items_by_source保持仅当top_comments未设置时才补拉enrich_source_items在top_comments已设置时是 no-op。不要把 finalize 变成唯一启动点也不要在 collect 循环内联富化——那会把其他源串行阻塞 124s。低于有效下限 → 预算记 0整条跳过不要发起注定失败的 11s 拉取。Bright Data 侧cli_timeout max(5, timeout-10)预算 11s 会变成 CLI 超时 1s却仍花 3 个积分。建议常量MIN_USEFUL_REVIEW_BUDGET 90。面包屑时间意味着跳过而不是用极短超时硬试。跳过或全掉时上报PARTIALAmazonsource_status记为 PARTIALdetail 为review lane timed out/review lane skipped (budget 0s)搜索成功的产品列表保留不把整个源翻成timeout。页脚footer已能在 state ! ok 时显示 ⚠不要改 render.py。边界保持depthquick仍然零拉取mockTrue仍然跳过不加环境变量旋钮不抬高LANE_DEADLINE或FOREGROUND_CONTRACT。四、amazon.py 实现预算数学与降级状态4.1 关键常量一览实现落在 amazon.py这些常量共同决定了预算语义常量值语义SEARCH_TIMEOUT90s单次amazon_product_search超时REVIEW_TIMEOUT180s单次amazon_product_reviews超时上限LANE_DEADLINE180s整条并行评论车道的墙钟上限FOREGROUND_CONTRACT300s引擎前台合约对应宿主 Bash 300sRENDER_MARGIN20s渲染前预留的余量MIN_USEFUL_REVIEW_BUDGET90s有效预算下限低于则整条跳过MAX_REVIEWS50单次拉取评论条数上限是上限不是配额DEPTH_CONFIGquick 0 / default 3 / deep 5各深度拉取的产品数MIN_DRIFT_SAMPLE5窗口内评分样本少于 5 则漂移箭头不诚实RECENT_WINDOW_DAYS30近 30 天窗口4.2 核心函数_remaining_lane_budget新版预算函数amazon.py L534-L545在剩余时间低于下限时直接返回 0def _remaining_lane_budget(elapsed: float) - int: remaining FOREGROUND_CONTRACT - elapsed - RENDER_MARGIN if remaining MIN_USEFUL_REVIEW_BUDGET: return 0 return int(min(LANE_DEADLINE, remaining))对照实测数字elapsed269 →300-269-2011 90→ 返回 0车道直接跳过elapsed40 → 剩余 240钳制到LANE_DEADLINE180elapsed100 → 剩余 180同样拿到满额预算。4.3enrich_with_reviews改为返回状态明细enrich_with_reviewsamazon.py L548签名改为返回(products, status_detail)二元组status_detail 三态None—— 正常成功review lane skipped (budget 0s)—— 预算低于下限车道未运行review lane timed out—— 所有并行拉取都被截止时间丢弃。值得注意的一个细节是线程池不使用with上下文管理每个 future 提交后已经在跑future.cancel()永远不可能成功而shutdown(waitTrue)会阻塞在刚刚被截止时间宣判丢弃的那个慢拉取上让截止时间形同虚设。代码用pool.shutdown(waitFalse, cancel_futuresTrue)amazon.py L633让被丢弃的线程在后台自行结束主运行继续前进。被丢弃的产品仍保留搜索记录的统计值、以quiet状态渲染而不是从报告中消失——丢失一个头部产品的近窗口读数比把它整个删掉更好。4.4 为什么放弃原地补拉enrich_source_itemsamazon.py L645保留为收尾补缺函数但它具备幂等性当metadata[top_comments]已存在时直接 no-op。这使它既可以服务于旧路径兼容又不会在检索阶段已经富化过的情况下重复烧 Bright Data 积分。五、pipeline.py 实现调度位点与时钟穿透5.1run_started作为墙钟原点在 pipeline.py L2014-L2017主运行函数创建墙钟原点run_started time.monotonic()run_started被新增为_retrieve_stream、_retrieve_stream_impl、_retry_thin_sources的参数并透传_retrieve_stream包装层不消费它仅转发到 impl见 pipeline.py L4209所有调用点均传入该值。这样才能在每个子查询流内部、任何一个源成功返回时都能计算出相对整次运行的真实 elapsed。5.2 Amazon 分支搜索后立即富化在_retrieve_stream_impl的 Amazon 分支pipeline.py L4775-L4819中行为序列是确定 keyword 与 domain支持LAST30DAYS_AMAZON_DOMAIN配置与_amazon_query内部参数search_products搜索并parse_search_response解析产品若来自 thin retry 则直接返回见下计算elapsed time.monotonic() - run_started立即调用amazon.enrich_with_reviews(...)此时其他源的 future 仍在并行执行若富化返回降级状态review_status非空则在该源的 artifact 上附加_source_outcome {state: PARTIAL, detail: ..., attempted: True}pipeline.py L4810-L4817。该 artifact 随后由_retrieve_stream中的_resolve_stream_outcome和主循环的 outcome 消费逻辑pipeline.py L2460-L2478转换为source_status上的正式SourceOutcome保留 PARTIAL 状态与 detail 文案。5.3 薄结果重试不重复富化_retry_thin_sourcespipeline.py L3991在 Phase 2b 薄源重试时传递skip_amazon_enrichmentTruepipeline.py L4082避免对 Phase 1 已富化过的 ASIN 产生重复的 Bright Data 拉取。finalize 会对真正的新产品补拉而已有top_comments的产品被enrich_source_items自动跳过两层幂等互相兜底。5.4 finalize 退化为 attach-if-missing_finalize_items_by_source的 Amazon 分支pipeline.py L3099-L3116在注释中明确了新角色评论富化现在在检索阶段就已发生到达这里的条目应当已经带top_commentsfinalize 路径含 fixture 回放合并只为 fixture replay、run_started未传入等边缘情况补缺。六、状态契约与不改页脚的边界纪律降级状态通过既有机制向上暴露PARTIAL定义于 schema.py引用自 health 模块的常量体系artifact 上的_source_outcome是引擎内既有的 typed outcome 契约_outcome_artifact、_legacy_artifact_outcome同款finalize 时由_finalize_source_statuspipeline.py L3497与最终证据集同步渲染层的_render_source_outcome_noterender.py L2553已能对 state ! ok 的源输出诊断说明因此本修复刻意不改 render.py / 页脚。计划文档还划定了严格的 out-of-scope不改页脚、不动 X 搜索与 Grok 鉴权、不加 env 旋钮、不重排整张源调度表延后处理。这是典型的修一处、保全局纪律——Amazon 的评论预算问题是调度时序问题不是全局调度重构问题。七、测试验证针对 Bentgo 回归的测试网计划将既有测试重新定向并新增了针对性的回归测试全部位于 tests/test_amazon.py无网络、无子进程既有测试重定向test_lane_budget_shrinks_as_the_run_clock_advances—— 现在验证下限行为elapsed200 及以后返回 0而非原来的小数值test_dropped_straggler_keeps_its_product_with_search_stats—— 改用 patch 过的短LANE_DEADLINE触发丢弃场景不再依赖面包屑预算test_exhausted_wall_clock_skips_the_lane_entirely—— 不变。新增回归测试test_lane_budget_floor_prevents_doomed_pulls—— 断言 elapsed269 返回 0elapsed190恰好 90返回 90elapsed19189返回 0test_amazon.py L836-L848test_lane_budget_constants_are_sane—— 守卫常量漂移MIN_USEFUL_REVIEW_BUDGET90、LANE_DEADLINE180、下限必须小于车道截止test_amazon.py L850-L854test_crumb_budget_skips_not_fires_doomed_pulls——Bentgo bug 的直接回归测试elapsed269 时 fetcher 绝不被调用、产品保留搜索统计、状态为review lane skipped (budget 0s)test_amazon.py L397-L421test_early_elapsed_gets_full_budget—— elapsed40 时fetch_reviews收到 180s 超时test_amazon.py L423-L450test_all_pulls_dropped_reports_timed_out_status—— 全部拉取被丢弃时返回review lane timed out状态test_amazon.py L452-L472。八、从这次修复可迁移的经验预算的下限要么有效要么干脆为零对按时长计费的拉取型后端极小超时如 1s CLI timeout与不发起是等价成本、不等价收益——前者烧积分且必然失败。低于业务有效阈值时跳过并显式降级远胜硬试一把。富化预算应花在能并行的最早时刻把 enrich 塞到依赖数据搜索结果就绪的瞬间与其他源重叠执行而不是排队等全量检索完成后再串行跑。其前提是能把真实 elapsed 穿透到该位点——这正是run_started参数化的价值。不要用垫高单源预算对抗宿主级合约300s 的 Bash 合约约束的是整次运行单源超预算的后果是整份报告的失败优先级高于任何单个源的完整性。降级要精确搜索成功只富化失败应报PARTIAL且保留 listings而不是把整个源翻成timeout可操作的 detail 文案review lane skipped (budget 0s)让用户与doctor都能看懂发生了什么。以上修复的全部设计意图、边界与验证均已落在 docs/plans/2026-08-14-fix-amazon-review-budget-plan.md实现以 amazon.py、pipeline.py 为落地载体行为契约由 test_amazon.py 固化——任何后续修改若让11s 打火或0 预算强试回归都会立刻被测试网拦截。【免费下载链接】last30days-skillAI agent skill that researches any topic across Reddit, X, YouTube, HN, Polymarket, and the web - then synthesizes a grounded summary项目地址: https://gitcode.com/GitHub_Trending/la/last30days-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考