电商评价分析 Agent：从数据汇总、报告生成到发送回写的完整闭环
从两张钉钉 AI 表格统一事实，到生成日报、发布文档、发送群消息，再到发送成功后的状态回写：这是一个真正能长期运行的评价分析 Agent。
本文目录 0 节 · 点击展开
OPENCLAW PROJECT / 电商评价分析实践
我把散落的评价，
做成了一个会完成闭环的 Agent。
它不是读取几条差评后写一段总结，而是把两张钉钉 AI 表格统一成事实包，生成日报或周期对比，发布文档、发送到群，并且只在消息真正送达后回写状态。
读取、统一、生成、表达、发送、回写。
01 source.normal ready
02 source.append ready
03 fact.package verified
04 delivery.gate waiting
公开版本已去掉真实店铺、订单号、评价原文、手机号、Webhook、表格地址和内部配置。
THE REAL PROBLEM
它不是一个
“评价总结 Prompt”
一句“读取今天的评价并发到群里”，背后其实藏着数据口径、任务模式、外部发送和状态副作用。
看起来的需求 “读取今天的评价，分析有哪些问题，然后发到群里。”
首次评价和追加评价在两张表里，字段和时间口径都不同。
情绪、问题类型和责任归因已经由上游字段给出，Agent 不能凭文案重新分类。
日报只处理尚未通知的记录，周期对比则必须忽略通知状态。
群消息未送达时，绝不能提前把评价标记为“已通知”。
两张表的 recordId 必须按来源隔离，不能混在一起更新。
事实层
找表、读字段、筛选、去重、统计，生成可验证 JSON。
确定什么是真的表达层
只基于事实包组织 Markdown，让运营快速看懂重点。
决定怎么说清楚交付层
报告落盘、在线文档、群消息，以及发送成功后的状态回写。
控制副作用何时发生NORMALIZE THE DATA
两张表，
先变成一种评价。
Agent 不应该理解两套混乱字段。脚本先把不同来源翻译成同一套内部语言。
评价收集明细
- 内容
- 评价内容
- 统计时间
- 评价时间
- 来源标记
- 首次评价
追加评价收集明细
- 内容
- 追加评价内容
- 统计时间
- 首次评价时间
- 参考时间
- 追加评价时间
review_source评价来自哪张表
review_time实际参与筛选和统计的时间
first_review_time首次评价时间
append_review_time追加评价时间，仅供参考
评价内容两张表统一后的文本字段
只用于避免重复统计，不判断哪条记录更新，也不删除源表数据。
SOURCE OF TRUTH
报告写得再好，
也不能越过事实包。
事实包是 Python 与 Agent 之间唯一允许通过的业务边界。
REVIEW_REPORT_CONTEXT_JSON_START
{
"mode": "daily",
"stats": { "total": 128, "followup": 11 },
"source_stats": { "normal": 103, "append": 25 },
"records": [ "..." ],
"writeback_record_ids": { "sources": { "..." } }
}
REVIEW_REPORT_CONTEXT_JSON_END日志不能混进事实
Agent 只解析两个标记之间的 JSON，stderr、调试信息和工具记录全部被挡在外面。
模型不能补原因
不存在于事实包里的订单、批次、质检和供应链信息，不能为了“完整”而补写。
统计与表达分开
Python 完成数量、占比、排行和明细；Agent 只负责把这些事实组织清楚。
DAILY RUN
一次日报，
到底怎么跑完？
每一步都必须写清输入、产出和失败边界，而不是让 Agent 在一个长 Prompt 里自由行动。
定位两张表并读取字段
分别解析首次评价和追加评价字段映射，确认当前模式所需字段。
筛选本次待处理评价
日报只读取通知状态不为“已通知 / 无需通知”的记录，最大回扫 30 天。
标准化、去重、生成事实包
统一来源和时间字段，排除 unknown，生成统计、明细与分来源回写 ids。
生成并保存最终报告
只基于事实包生成 Markdown，再通过报告写入脚本保存到 report 目录。
发布文档、发送消息、成功后回写
先确认报告已经送达，再按本次事实包里的来源分组 record ids 修改通知状态。
进入日报关注范围与状态回写。
中性评价不会混进重点差评内容。
不统计、不回写，保留原状态等待上游分析。
DELIVERY GATE
发送成功，
才允许回写。
这是整套系统最重要的可靠性设计，也是一次性 AI 总结与长期业务系统之间的分界线。
文档和群消息准备发送。
按来源表回写
只使用本次事实包中的 record ids：非正面写“已通知”，正面写“无需通知”。
任务完成保持原状态
不执行任何业务状态回写，让这些评价下一次仍能被查询和重新发送。
等待重试回写阶段故意变得很窄
- 只能使用本次事实包生成的 record ids
- 禁止重新查询评价记录
- 禁止重新生成一份 daily 事实包
- 必须按来源表分组，不能混用两张表的 recordId
如果报告已发送但回写失败，系统会追加风险提示：下次日报可能重复处理这批评价。
TWO OPERATING MODES
日报和周期对比，
不是同一个任务。
它们共用数据标准化和事实包机制，但筛选口径、报告结构和副作用边界保持独立。
今天有哪些新评价需要关注？
- 只处理尚未通知的记录
- 最大回扫 30 天
- 发送成功后回写状态
- 不展示商品或链接集中度
两个时间段之间发生了什么变化？
- 必须提供两个完整日期区间
- 不受每日通知状态影响
- 分析商品、链接和问题趋势
- 不回写每日通知状态
我故意不让 Agent 做的事
避免覆盖上游口径，让同一条评价在不同报告里保持一致。
关注口径与重点差评口径保持分离。
推测不能伪装成订单、批次或质检事实。
未送达的评价不能从后续日报中静默消失。
保证当前报告和更新对象仍是同一批数据。
每个 id 只能回到自己的来源表中更新。