W3评测：TradePilot AI（拿货搭子）— AI进货决策代理 #4
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
项目仓库: https://www.synnovator.com/Jyoti/tradepilot-ai-wave3
Demo地址: https://tradepilot-ai-site.vercel.app/
评测基准: 半决赛 Wave 3 Demo — Agents完整/有效/可运行，Skills整合，Demo具备交互能力
评测日期: 2026-05-24
一、项目理解
TradePilot AI是面向小商品采购和内容电商测款的AI进货决策代理。核心解决的问题是：小卖家/大学生创业者/社交电商商家在进货前需要评估"这个品值不值得拿样试"，避免盲目囤货。
核心流程：商品图片识别 → 进货信息采集 → 利润/风险测算 → 内容测款建议 → 产品库沉淀 → 候选产品PK → 测款复盘
目标用户画像清晰——不是泛化的"AI助手"，而是非常具体的小商品采购决策场景。
二、Agent 落地性
项目定义了7个"Agent"，但它们的实现本质是功能模块和UI组件，不是LLM驱动的自主Agent：
api/analyze-image.js+imageQualityUtils.jsreportUtils.js+priceEvidenceUtils.jscontentTemplates.js+douyinFallbackUtils.jsproductStorage.js+HistoryView.jsxPKView.jsx+ProductPKRadarChart.jsx+ProductPKBarChart.jsxReviewView.jsx+review.ts+ReviewMetricChart.jsx关键判断：这些"Agent"没有规划循环、没有工具使用、没有多步推理、没有自主决策。它们是过程式代码和UI组件，不是LLM驱动的自主Agent。仅商品识别调用了LLM（阿里百炼视觉模型），其余6个都是规则计算和模板渲染。
6/7有对应代码实现，但1/7（供应商沟通Agent）无独立组件。
三、Skill 落地性
7个Skill全部有对应代码实现，形成完整业务管线：
api/analyze-image.js+imageQualityUtils.jsOperateView.jsxreportUtils.js+priceEvidenceUtils.jscontentTemplates.js+douyinFallbackUtils.jsproductStorage.js+HistoryView.jsxPKView.jsx+ 雷达图+柱状图ReviewView.jsx+manualMarketEvidenceUtils.jsSkill集成特点：
priceEvidenceUtils.test.js、douyinFallbackUtils.test.js、manualMarketEvidenceUtils.test.js）四、Demo 交互能力
Demo在线可访问（Vercel部署），Guest模式无需注册即可体验全流程：
交互能力：
Demo-Guide.md为评委提供结构化评测指引，包含评测路径、预期结果、降级行为说明。
五、不足与建议
1. "Agent"实为功能模块，非自主AI Agent
问题：7个"Agent"实际是过程式代码和UI组件，不是LLM驱动的自主Agent——没有规划循环、没有工具使用、没有多步推理、没有自主决策。仅商品识别调用了LLM（单次视觉API调用），其余6个都是规则计算和模板渲染。进货决策是算法逻辑（利润率×权重+风险评分×权重），不是Agent推理。
影响：如果W3标准严格要求"LLM驱动的自主Agent"（有规划、工具使用、多步推理能力），则不满足"Agents需完整、有效、可运行"的核心标准。当前Agent更像是"功能模块"而非"Agent"。
建议：将进货决策Agent升级为真正的LLM Agent——Agent根据市场趋势数据、历史进货记录、用户偏好画像，自主推理并推荐进货方案，而非仅输出规则计算结果。内容测款Agent也可以升级：根据商品特征+目标平台+用户粉丝画像，LLM自主生成差异化的测款内容策略。
2. 供应商沟通Agent缺失
问题：WAVE3-PLAN.md定义了7个Agent，但供应商沟通Agent无独立组件或工具文件，似乎嵌入在报告输出中而非独立实现。
影响：7个Agent实际仅6个有代码实现，声明与实现不一致。
建议：补充供应商沟通Agent——至少实现自动生成询价/议价消息模板，或对接1688等B2B平台的供应商信息查询。
3. 数据持久化依赖localStorage
问题：产品库主要依赖localStorage，Supabase云同步为可选。localStorage受浏览器限制（通常5-10MB），清除浏览器数据即丢失全部产品库。
影响：多设备数据不同步，长期使用的用户可能丢失数据，数据持久化可靠性不足。
建议：默认使用Supabase云同步，localStorage作为离线缓存层。或至少在Guest模式下提示用户"数据仅保存在本地，清除浏览器将丢失"，并提供导出备份功能。
4. LLM依赖度低
问题：仅商品图片识别调用LLM（阿里百炼视觉模型），其余6个"Agent"都是规则计算和模板渲染。AI含量偏低。
影响：项目更接近"带AI识别的传统决策工具"而非"AI驱动的智能决策代理"。规则计算的进货决策在不同场景下可能不够灵活（如新兴品类无历史价格参考时）。
建议：在进货决策、测款建议、复盘分析中增加LLM驱动的智能推理。例如：利润测算时，LLM分析市场趋势和竞争格局补充定性判断；复盘时，LLM根据历史数据总结"哪些品类更容易测款成功"的经验规律。
六、综合评价
TradePilot AI是一个业务闭环完整、交互体验流畅的垂直场景应用。7个Skill全部有代码实现并形成连贯管线，从图片上传→识别→测算→测款→沉淀→PK→复盘，用户可以完成进货决策的完整工作流。Guest模式无需注册，降级路径设计合理（识别失败→手动填写，API不可用→本地降级），Demo-Guide.md为评委提供结构化指引。Vitest单元测试覆盖关键工具函数。产品定位精准——小商品采购决策是真实痛点。
但核心问题是"Agent"的命名与实现不一致。7个"Agent"实际是功能模块和UI组件，不是LLM驱动的自主Agent。仅商品识别调用了LLM（单次API调用），其余都是规则计算和模板渲染。如果W3标准严格要求Agent架构（规划循环+工具使用+多步推理），则Agent维度不达标；如果接受"功能模块=Agent"的宽松定义，则项目完成度较高。
非常感谢你对 TradePilot AI｜拿货搭子的详细评测。你的反馈非常有价值，尤其是关于“Agent 命名与实现方式”的判断，确实指出了我们项目早期表达中比较容易产生误解的地方。
针对你提到的核心问题，我们已经做了几轮针对性优化：
关于“Agent 实为功能模块，而非完全自主 Agent”
我们已经调整项目表述，不再简单把每个功能模块都称为独立自主 Agent，而是统一改为“1 个工作流式主 Agent + 多个 Skills 能力模块”的架构。TradePilot 主 Agent 负责围绕进货决策流程进行任务编排，多个 Skills 分别承担图片识别、进货判断、内容测款、供应商沟通、产品库、候选 PK、测款复盘和报告导出等具体能力。
目前它不是完全自主的多轮规划型 Agent，也不伪装成全自动采购代理，而是一个面向垂直场景的工作流式智能决策代理。后续如果继续升级，会考虑引入更明确的 Planning、Tool Calling、Memory 和多步执行循环。
关于供应商沟通 Agent / Skill 缺失
这一点我们已经补齐。项目新增了独立的
supplierCommunicationUtils.js和SupplierCommunicationPanel.jsx，可以根据商品信息、利润空间、MOQ 和风险提示生成询价、议价、打样确认、发货与售后确认话术，并支持一键复制。同时 HTML / PDF 报告中也同步加入了供应商沟通内容。该模块不接入 1688 API，也不伪造真实供应商数据，只作为用户拿样前的沟通辅助工具。关于数据持久化依赖 localStorage
项目已经补充了本地存储风险提示、JSON 备份导出、JSON 导入恢复和 CSV 导出功能。游客模式下会明确提示数据仅保存在当前浏览器，清除缓存或更换设备可能导致记录丢失；正式使用时可以选择 Supabase 云端同步。这样既保留了评测时的低门槛体验，也提高了长期使用的数据可靠性。
关于 LLM 依赖度低
我们已经新增 LLM 智能推理补充层，在保留原规则评分稳定性的基础上，让 LLM 参与进货决策解释、内容测款策略和测款复盘总结。LLM 不直接覆盖综合评分，也不伪造平台价格、销量、播放量或成交数据，而是用于补充定性判断、风险解释和下一步验证建议。若 LLM 接口不可用，系统会显示基础策略建议，不影响主流程。
关于外部 API 依赖和评测环境可用性
项目已经新增视觉 API 不可用时的演示 fallback 和手动填写兜底。当 DashScope / 百炼视觉接口不可用时，系统会明确提示当前为演示 fallback，不代表真实识别结果，并允许用户继续完成进货报告、产品库、PK、复盘和报告导出流程。价格分析部分也继续采用人工市场证据和搜索参考入口，不伪造真实平台数据。
关于测试和工程可靠性
我们已经补充 Vitest 测试用例，新增了价格证据、人工市场证据和抖音内容热度 fallback 相关测试文件，覆盖价格证据解析、证据完整度、风险判断、scoreAdjustment 范围限制等核心工具逻辑。目前 build、test、typecheck 均已通过。
关于数据模型和技术文档
我们已经新增
docs/Agent-Data-Model.md和docs/Technical-Architecture.md，补充 ProductInput、PurchaseDecisionResult、MarketEvidence、ProductRecord、ReviewData、AiInsightResult 等核心数据模型说明，并梳理 Agent / Skills 协作流程、数据流、API 接口、存储方式、fallback 机制和部署结构，方便评审和开发者理解项目实现。整体来看，你的评价帮助我们进一步明确了项目定位：TradePilot AI 当前更适合定义为“工作流式 AI 进货决策智能体”，而不是完全自主型 Agent。它的价值重点在于把小商品进货前的判断、测款、供应商沟通、产品沉淀和复盘串成一个可运行的垂直场景闭环。后续我们会继续向更强的 Agent 能力升级，例如引入更明确的工具调用、多步推理、历史记忆和用户偏好学习。再次感谢你的认真评测和建议！