1. 电商商品运营为什么需要 Harness Engineering做电商商品运营的朋友大概率都经历过这种场景每天打开后台几万个 SKU 躺在那里哪些该补货、哪些该清仓、哪些值得加大投放全靠运营同学凭经验拍脑袋。等到发现某个品类起量了竞品已经吃掉了大半流量。问题不在于没有数据而在于数据到决策之间缺少一条自动化的链路。AI Agent 能解决“分析”这一环但真正落地时会发现模型会调了Prompt 也写了可每天跑起来还是散装的——今天手动喂一批商品数据明天换个脚本跑选品后天模型换了 Key 又要改一遍配置。这就是 Harness Engineering 要解决的问题不是训练一个更聪明的模型而是给 Agent 搭一套可复用、可观测、可迭代的“骨架”让选品和运营任务能稳定地跑起来。具体到电商场景这套骨架要覆盖三件事。第一是统一入口商品数据、竞品数据、趋势数据从不同来源进来Agent 需要一个稳定的调用通道。第二是可复制配置选品规则、评分权重、触发条件都写在配置文件里而不是散落在代码中。第三是可验证结果每次跑完能明确知道选出了什么、为什么选它、下一步该做什么。这篇文章会交付一套可以直接抄的config.toml骨架配合 TaoToken 的统一 Key 和 API 通道把商品运营里的自动化选品任务跑通。适合已经有基础 Python 能力、想把 Agent 真正用到电商业务里的运营和开发同学。下面从接入配置开始一步步走到验证请求和排障。2. TaoToken 前置统一 Key 与 API 通道接入在搭 Harness 之前先把模型调用这一层固定下来。电商选品 Agent 通常要跑多个任务商品标题理解、卖点提取、竞品对比、趋势判断每个任务可能用不同模型。如果每个模型都单独配 Key、单独改 base_url配置会迅速失控。TaoToken 在这里的角色是统一通道一个 Key 走所有模型调用base_url 固定切换模型只改模型名。对 Harness Engineering 来说这意味着配置文件里只需要维护一份凭证Agent 的每个子任务通过参数选择模型即可。接入前你需要准备两样东西TaoToken 的 API Key以及确认要用的模型名。Key 在控制台生成地址是 https://taotoken.net/api-keys 。生成后不要写死在代码里放到环境变量或.env文件中config.toml里只引用变量名。API 的基础地址是https://taotoken.net/api兼容 OpenAI 风格的调用方式。也就是说你原来用openaiSDK 写的代码只需要改base_url和api_key两个参数就能切过来。这一点对 Harness 很关键Agent 的底层调用逻辑不用重写配置层换一下就行。如果你还没决定用哪个模型跑选品任务可以先去模型对话页面试一下不同模型对商品文案和趋势判断的表现地址是 https://taotoken.net/models 。试好之后再写进配置避免配好了发现模型不适合。对于长期跑编码类任务或者要搭 Agent 工作流的场景Coding Plan 会更划算地址是 https://taotoken.net/coding-plan 。选品 Agent 里如果有大量结构化输出和规则判断用包月方案比按量调用更可控。3. 可复制的 config.toml 骨架下面这份配置是整套 Harness 的核心。它的设计思路是把“模型通道”“选品规则”“任务编排”三层分开改规则不用动代码换模型不用改规则。# config.toml - 电商选品 Agent Harness 配置骨架 [llm] # TaoToken 统一通道所有模型调用走这里 base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY # 从环境变量读取不写明文 timeout 60 max_retries 3 [llm.models] # 不同子任务用不同模型按需替换模型名 analyzer gpt-4o-mini # 商品理解、卖点提取 reasoner gpt-4o # 趋势判断、选品决策 summarizer gpt-4o-mini # 结果汇总 [selection] # 选品规则运营可以直接改这里 min_monthly_sales 300 # 月销量门槛 min_gross_margin 0.25 # 最低毛利率 max_return_rate 0.08 # 退货率上限 min_rating 4.2 # 最低评分 exclude_categories [危险品, 临期食品] [selection.weights] # 潜力评分权重总和为 1 sales_growth 0.35 margin 0.25 competition 0.20 trend 0.20 [agent] # Agent 编排参数 batch_size 50 # 每批处理商品数 concurrency 4 # 并发调用数 output_dir ./output log_level INFO [agent.tasks] # 任务开关调试时按需关闭 enable_trend_analysis true enable_competitor_check true enable_pricing_suggest true [observability] # 可观测性每次运行落盘方便回溯 save_raw_response true save_decision_trace true trace_file ./output/decision_trace.jsonl几个关键点说明一下。api_key_env指向环境变量这样 Key 不会进版本库。[llm.models]里把分析、推理、汇总分开配是因为选品决策对推理能力要求高而商品标题清洗用轻量模型就够混用会浪费成本。[selection.weights]是运营最常调的部分权重一变选出来的商品排序就变不需要改任何代码。[observability]这一段是 Harness Engineering 和普通脚本的分水岭。普通脚本跑完就完了出了问题不知道哪一步错了。这里把原始响应和决策链路都落盘后面排障时能直接看到 Agent 在哪一步做了错误判断。配置写好后用 Python 读取import os import tomllib from openai import OpenAI with open(config.toml, rb) as f: cfg tomllib.load(f) client OpenAI( base_urlcfg[llm][base_url], api_keyos.environ[cfg[llm][api_key_env]], timeoutcfg[llm][timeout], )到这里通道就通了。接下来把选品任务接上去。4. 自动化选品任务的编排与执行选品任务拆成四步商品数据清洗、卖点与趋势分析、潜力评分、结果输出。每一步都通过config.toml里的模型配置调用不硬编码模型名。import json from datetime import datetime def analyze_product(client, cfg, product): 单商品分析提取卖点 判断趋势 model cfg[llm][models][analyzer] prompt f你是电商选品分析师。根据以下商品信息输出 JSON 商品名{product[title]} 类目{product[category]} 月销量{product[monthly_sales]} 毛利率{product[gross_margin]} 退货率{product[return_rate]} 评分{product[rating]} 输出字段selling_points(数组), risk_flags(数组), trend_signal(rising/stable/falling) resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], response_format{type: json_object}, ) return json.loads(resp.choices[0].message.content) def score_product(cfg, product, analysis): 按配置权重计算潜力分 w cfg[selection][weights] # 各维度归一化到 0-1示例用简单映射实际按业务调整 sales_score min(product[monthly_sales] / 1000, 1.0) margin_score min(product[gross_margin] / 0.5, 1.0) competition_score 1.0 - min(product.get(competitor_count, 0) / 100, 1.0) trend_score {rising: 1.0, stable: 0.5, falling: 0.1}[analysis[trend_signal]] return ( sales_score * w[sales_growth] margin_score * w[margin] competition_score * w[competition] trend_score * w[trend] ) def run_selection(client, cfg, products): results [] for p in products: # 规则过滤 if p[monthly_sales] cfg[selection][min_monthly_sales]: continue if p[gross_margin] cfg[selection][min_gross_margin]: continue if p[return_rate] cfg[selection][max_return_rate]: continue if p[category] in cfg[selection][exclude_categories]: continue analysis analyze_product(client, cfg, p) score score_product(cfg, p, analysis) results.append({ product_id: p[id], title: p[title], score: round(score, 4), trend: analysis[trend_signal], selling_points: analysis[selling_points], risk_flags: analysis[risk_flags], }) results.sort(keylambda x: x[score], reverseTrue) return results跑一批模拟数据验证products [ {id: P001, title: 便携榨汁杯, category: 厨房小电, monthly_sales: 820, gross_margin: 0.42, return_rate: 0.03, rating: 4.6, competitor_count: 35}, {id: P002, title: 折叠收纳箱, category: 家居, monthly_sales: 150, gross_margin: 0.30, return_rate: 0.05, rating: 4.3, competitor_count: 80}, ] results run_selection(client, cfg, products) print(json.dumps(results, ensure_asciiFalse, indent2))预期输出是 P001 排在前面因为它的销量、毛利、趋势都更好P002 因为月销量低于 300 被规则直接过滤掉。这一步跑通说明配置、通道、编排三层都对齐了。5. 验证请求与成功结果验证分两层先确认通道通再确认业务逻辑对。通道验证用一个最小请求resp client.chat.completions.create( modelcfg[llm][models][analyzer], messages[{role: user, content: 回复 OK}], ) print(resp.choices[0].message.content)如果返回OK说明 Key、base_url、模型名三者都对。如果报 401检查环境变量是否加载如果报 404检查模型名是否拼错。业务验证看输出结构。成功的选品结果应该满足每条记录有score、trend、selling_points、risk_flags四个字段score在 0 到 1 之间被规则过滤的商品不出现在结果里。你可以故意放一个monthly_sales低于门槛的商品进去确认它被过滤这样能验证规则层生效。可观测性验证看./output/decision_trace.jsonl。每次运行应该追加一行包含时间戳、商品 ID、评分、模型名。如果这个文件没生成检查[observability]里的路径是否存在以及save_decision_trace是否为 true。实测下来这套结构跑 50 个商品大约 40 秒并发调到 4 之后能压到 15 秒左右。如果发现某批商品全部被过滤先看min_monthly_sales是不是设太高这是最常见的配置问题。6. 本篇常见错排查报错一KeyError: TAOTOKEN_API_KEY环境变量没加载。检查.env文件是否被读取或者直接在终端export TAOTOKEN_API_KEY你的key再跑。不要图省事把 Key 写进config.toml一旦提交到仓库就麻烦了。报错二openai.BadRequestError: model not found模型名写错了。[llm.models]里的模型名要和 TaoToken 支持的名称一致。去模型对话页面确认一下当前可用的模型名地址是 https://taotoken.net/models 。报错三返回的 JSON 解析失败模型没按格式输出。两个办法一是确认用了支持response_format的模型二是在 prompt 里把字段名和类型写得更死比如明确写“selling_points 必须是字符串数组不要嵌套对象”。报错四选品结果为空先看规则过滤。把min_monthly_sales、min_gross_margin临时调低看是否有商品通过。如果调低后有了说明是门槛设太高如果还是没有检查商品数据里的字段名是否和代码里一致比如monthly_sales写成了month_sales。报错五并发跑的时候部分请求超时concurrency调太高。先降到 2确认稳定后再往上加。同时把max_retries设成 3让偶发的网络抖动自动重试。报错六decision_trace.jsonl不生成output_dir目录不存在。代码里加一句os.makedirs(cfg[agent][output_dir], exist_okTrue)或者手动建目录。排障时优先看decision_trace.jsonl里面记录了每一步的输入输出比在代码里打 print 高效得多。这也是 Harness Engineering 强调可观测性的原因问题不是靠猜是靠日志定位。7. 把 Harness 用到长期运营里跑通一次选品只是起点。真正有价值的是把这套 Harness 变成日常运营的一部分每天早上自动拉取商品数据、跑一遍选品、把结果推到运营群运营只需要看排序和风险标记。要做到这一点把run_selection包成一个定时任务用 cron 或调度平台每天触发。配置里的[selection]和[selection.weights]就是运营的调参面板改完重启任务即可生效不需要开发介入。如果你打算把选品 Agent 扩展到竞品监控、动态定价、库存预警建议每个任务单独一个config.toml段落共用同一个 TaoToken 通道。这样新增任务只是加配置不动核心代码。长期跑下来Coding Plan 会比按量调用更省心尤其是任务数量上来之后地址是 https://taotoken.net/coding-plan 。最后提醒一句选品决策最终要人来拍板。Agent 的价值是把候选集从几万个缩到几十个并给出可解释的理由。把selling_points和risk_flags展示给运营让他们在 Agent 的基础上做最终判断这才是人机协作的正确姿势。