hanlei/trademaker
1
0
Fork 0
Code Issues 4 Pull requests Projects Releases Packages Wiki Activity Actions

【S3W3 交叉评测】TradeMaster：身份授权、数据可信度与多步骤 Agent 编排建议 #2

New issue
Open
opened 2026-08-06 10:52:20 +08:00 by Michael · 1 comment
Michael commented 2026-08-06 10:52:20 +08:00
Copy link

1. 项目理解

我理解 TradeMaster 是一个面向外贸销售人员和中小外贸企业的 AI 业务助理平台。

项目试图覆盖从寻找潜在买家、分析公司背景、生成开发信，到处理客户询盘、发送和跟踪邮件、维护客户 Pipeline 及跟进提醒的完整外贸业务流程。

当前产品已经不是单一聊天机器人，而是由 Flask Web 应用、Function Calling 工具、外部数据源、SQLite 数据存储、邮件系统、询盘流程和客户管理模块共同组成的业务工作台。

2. 项目亮点

  • 外贸业务覆盖面较完整，已经形成“找客户—沟通—询盘—跟进—客户管理”的连续流程。
  • 买家搜索、公司分析、开发信、询盘处理、邮件发送和 CRM 均有实际代码模块。
  • 使用 Blueprint、SQLite WAL、SSE、模型多 Provider 切换和独立 Skill 目录，工程结构比较清楚。
  • 项目已经意识到邮箱真实性、退信、大企业供应商门户和 SMTP 投递状态等真实外贸问题。
  • 提供了较完整的 Demo 脚本、知识库、测试模块和部署配置。

3. 当前问题和疑点

3.1 登录接口尚未形成服务端身份授权

当前登录接口只返回用户信息，没有签发 Session、JWT 或其他身份凭证。

前端把用户信息保存在 localStorage，后续接口直接提交 user_email。联系人、仪表盘、会话、询盘和邮件接口均信任客户端传入的邮箱，没有验证调用者是否属于该账号。

此外：

  • SMTP 配置接口无需登录即可修改全局邮箱授权码；
  • SMTP 发送接口无需登录即可发出真实邮件；
  • 已发送邮件接口在指定账号没有数据时，会返回全部邮件记录。

建议引入统一认证中间件，由服务端从 Session 或 Token 获取当前用户，禁止客户端自行声明身份，并对所有用户数据实施强制隔离。

3.2 邮箱和商业事实的可信度规则与代码存在冲突

系统提示词强调“禁止编造邮箱”，但 LLM 买家搜索降级逻辑要求每家公司必须返回邮箱，并允许生成 purchasing@、info@、sales@ 等常见地址。

这些模型生成结果还被标记为“AI Trade Database”，容易被误认为已验证的数据。

开发信和询盘回复的降级模板还会默认宣称：

  • 十年以上出口经验；
  • 产品具有 CE、RoHS 和 FCC 认证。

如果用户没有提供这些事实，不应自动写入真实商务邮件。

建议为所有公司、邮箱、认证、价格和资历增加来源及验证状态；模型推测结果只能作为待核查线索，不能直接进入可发送流程。

3.3 当前多 Agent 协作实际是单次关键词路由

当前系统根据第一个匹配关键词选择一个 Agent，并在整个任务中固定该 Agent 的工具集合。

例如：

“搜索德国 LED 进口商并给他们写开发信”

会被路由到买家搜索 Agent，但该 Agent 没有 draft_email 工具，因此无法执行文档中描述的“搜索完成后切换邮件 Agent”。

建议先把用户请求拆成结构化子任务，再依次执行：

  1. 搜索买家；
  2. 验证和筛选结果；
  3. 用户确认目标客户；
  4. 生成开发信；
  5. 用户确认后发送或保存。

不一定需要启动多个独立模型，但必须支持真正的跨步骤任务规划和状态传递。

3.4 展会和市场情报需要来源及有效期

当前展会日期、规模、认证费用、市场规模和增长率主要以硬编码方式保存，没有来源链接和核验时间。

展会匹配也没有过滤已经结束的活动，因此可能向用户推荐过期展会。

建议每条情报增加：

  • 原始来源；
  • 核验日期；
  • 生效和失效时间；
  • 当前状态；
  • 是否允许作为确定事实展示。

3.5 需要统一当前项目说明和验证入口

README、架构文档、Demo 文档、API 文档和代码对 Agent 数量、工具数量、数据源及会话存储的描述并不一致。

建议以当前代码为准更新仓库首页，并提供一个可直接执行的验证命令。当前完整 pytest 会因测试脚本在导入阶段退出而无法正常收集，也建议改为标准 pytest fixture 或独立 integration test 脚本。

4. 优先改进建议

建议优先完成以下三项：

  1. 增加真实的服务端身份认证和数据隔离，首先保护 SMTP、邮件、联系人和会话接口。
  2. 删除所有自动编造邮箱、认证资质和企业经历的降级逻辑，建立来源与验证状态字段。
  3. 将一次关键词路由升级为多步骤任务计划，使搜索、筛选、写信和跟进能够在同一任务中连续执行。

完成以上三项后，再补充知识库来源、过期数据过滤和统一文档口径。

5. 综合评价

TradeMaster 已经形成了较完整的外贸业务应用，功能体量、工程模块和业务场景都比较丰富。

当前最重要的提升方向不是继续增加更多功能，而是确保用户身份、客户数据和邮件能力得到真正保护，并保证系统不会把模型推测内容包装成可直接用于真实业务的事实。

在授权机制、数据可信度和多步骤任务编排得到修正后，项目会更接近一个可以安全用于真实外贸流程的 Agent，而不仅是功能丰富的演示平台。

## 1. 项目理解 我理解 TradeMaster 是一个面向外贸销售人员和中小外贸企业的 AI 业务助理平台。 项目试图覆盖从寻找潜在买家、分析公司背景、生成开发信，到处理客户询盘、发送和跟踪邮件、维护客户 Pipeline 及跟进提醒的完整外贸业务流程。 当前产品已经不是单一聊天机器人，而是由 Flask Web 应用、Function Calling 工具、外部数据源、SQLite 数据存储、邮件系统、询盘流程和客户管理模块共同组成的业务工作台。 ## 2. 项目亮点 - 外贸业务覆盖面较完整，已经形成“找客户—沟通—询盘—跟进—客户管理”的连续流程。 - 买家搜索、公司分析、开发信、询盘处理、邮件发送和 CRM 均有实际代码模块。 - 使用 Blueprint、SQLite WAL、SSE、模型多 Provider 切换和独立 Skill 目录，工程结构比较清楚。 - 项目已经意识到邮箱真实性、退信、大企业供应商门户和 SMTP 投递状态等真实外贸问题。 - 提供了较完整的 Demo 脚本、知识库、测试模块和部署配置。 ## 3. 当前问题和疑点 ### 3.1 登录接口尚未形成服务端身份授权 当前登录接口只返回用户信息，没有签发 Session、JWT 或其他身份凭证。 前端把用户信息保存在 localStorage，后续接口直接提交 user_email。联系人、仪表盘、会话、询盘和邮件接口均信任客户端传入的邮箱，没有验证调用者是否属于该账号。 此外： - SMTP 配置接口无需登录即可修改全局邮箱授权码； - SMTP 发送接口无需登录即可发出真实邮件； - 已发送邮件接口在指定账号没有数据时，会返回全部邮件记录。 建议引入统一认证中间件，由服务端从 Session 或 Token 获取当前用户，禁止客户端自行声明身份，并对所有用户数据实施强制隔离。 ### 3.2 邮箱和商业事实的可信度规则与代码存在冲突 系统提示词强调“禁止编造邮箱”，但 LLM 买家搜索降级逻辑要求每家公司必须返回邮箱，并允许生成 purchasing@、info@、sales@ 等常见地址。 这些模型生成结果还被标记为“AI Trade Database”，容易被误认为已验证的数据。 开发信和询盘回复的降级模板还会默认宣称： - 十年以上出口经验； - 产品具有 CE、RoHS 和 FCC 认证。 如果用户没有提供这些事实，不应自动写入真实商务邮件。 建议为所有公司、邮箱、认证、价格和资历增加来源及验证状态；模型推测结果只能作为待核查线索，不能直接进入可发送流程。 ### 3.3 当前多 Agent 协作实际是单次关键词路由 当前系统根据第一个匹配关键词选择一个 Agent，并在整个任务中固定该 Agent 的工具集合。 例如： “搜索德国 LED 进口商并给他们写开发信” 会被路由到买家搜索 Agent，但该 Agent 没有 draft_email 工具，因此无法执行文档中描述的“搜索完成后切换邮件 Agent”。 建议先把用户请求拆成结构化子任务，再依次执行： 1. 搜索买家； 2. 验证和筛选结果； 3. 用户确认目标客户； 4. 生成开发信； 5. 用户确认后发送或保存。 不一定需要启动多个独立模型，但必须支持真正的跨步骤任务规划和状态传递。 ### 3.4 展会和市场情报需要来源及有效期 当前展会日期、规模、认证费用、市场规模和增长率主要以硬编码方式保存，没有来源链接和核验时间。 展会匹配也没有过滤已经结束的活动，因此可能向用户推荐过期展会。 建议每条情报增加： - 原始来源； - 核验日期； - 生效和失效时间； - 当前状态； - 是否允许作为确定事实展示。 ### 3.5 需要统一当前项目说明和验证入口 README、架构文档、Demo 文档、API 文档和代码对 Agent 数量、工具数量、数据源及会话存储的描述并不一致。 建议以当前代码为准更新仓库首页，并提供一个可直接执行的验证命令。当前完整 pytest 会因测试脚本在导入阶段退出而无法正常收集，也建议改为标准 pytest fixture 或独立 integration test 脚本。 ## 4. 优先改进建议 建议优先完成以下三项： 1. 增加真实的服务端身份认证和数据隔离，首先保护 SMTP、邮件、联系人和会话接口。 2. 删除所有自动编造邮箱、认证资质和企业经历的降级逻辑，建立来源与验证状态字段。 3. 将一次关键词路由升级为多步骤任务计划，使搜索、筛选、写信和跟进能够在同一任务中连续执行。 完成以上三项后，再补充知识库来源、过期数据过滤和统一文档口径。 ## 5. 综合评价 TradeMaster 已经形成了较完整的外贸业务应用，功能体量、工程模块和业务场景都比较丰富。 当前最重要的提升方向不是继续增加更多功能，而是确保用户身份、客户数据和邮件能力得到真正保护，并保证系统不会把模型推测内容包装成可直接用于真实业务的事实。 在授权机制、数据可信度和多步骤任务编排得到修正后，项目会更接近一个可以安全用于真实外贸流程的 Agent，而不仅是功能丰富的演示平台。
hanlei commented 2026-08-07 12:50:38 +08:00
Owner
Copy link

感谢评审老师专业、细致的审阅。以下针对各项问题和建议逐条回应。

一、登录接口尚未形成服务端身份授权（3.1）

回复：已修复。

认证机制：

  • 新增 auth_middleware.py：JWT 令牌机制（HS256，7天过期），提供
    create_token、decode_token、@login_required、@optional_login 四个接口
  • auth_bp.py：/api/register 和 /api/login 成功后返回 token 字段
  • config.py：启动时强制校验 SECRET_KEY 环境变量，缺失则拒绝启动

全端点鉴权覆盖：

  • email_bp.py：SMTP 配置读写、SMTP 发送、邮件历史等全线加 @login_required + @rate_limit
  • contact_bp.py：添加/列表/更新/删除/统计全部加 @login_required
  • dashboard_bp.py：仪表盘/工作流/偏好设置/一键获客全部加 @login_required
  • inquiry_bp.py：询盘处理/待处理/提醒全部加 @login_required
  • evaluate_bp.py：四个评价接口全部加 @login_required
  • 仅 /api/chat、/api/health、/api/doll 等只读或娱乐端点保持公开

数据隔离：

  • @login_required 从 Authorization: Bearer 中提取 g.user_email，各端点统一使用
  • 移除了曾存在的 body user_email fallback，彻底杜绝客户端自行声明身份
  • 新增跨用户隔离安全测试，验证用户 A 读取不到用户 B 的联系人和仪表盘数据
  • SMTP 密码已加密存储（Fernet），读取需经过身份验证

测试覆盖：

  • tests/test_security.py：16
    个安全测试全部通过（认证绕过7个、越权访问2个、JWT令牌3个、密码加密2个、安全响应头2个）

二、邮箱和商业事实的可信度规则与代码存在冲突（3.2）

回复：已修复。评审指出三个问题，均已解决。

  1. LLM prompt 要求"每家公司必须返回邮箱"：
  • search_companies_llm() 的 prompt 已从 "always include an email field" 改为 "NEVER guess or fabricate
    emails. An empty email is better than a wrong one."
  • email 字段允许返回空字符串，不再强制填满
  1. 降级模板虚构商业资质：
  • 开发信降级模板中 "We have over 10 years of export experience" 已替换为 "We specialize in manufacturing
    and exporting high-quality products"
  • 不在未获用户确认的前提下宣称任何资质或经验年限
  1. 推测邮箱未阻断发送：
  • send_email() 中强化了 email_verified 标记逻辑
  • 检测到 purchasing@、info@ 等推测邮箱时，设置 email_verified: false
  • 前端收到该标记后应阻断一键发送，需用户显式确认

已完成的溯源基础：

  • data_sources.py：所有数据源结果统一携带 source、source_url、fetched_at、confidence 四字段
  • LLM 生成的公司标注 confidence: 0.50、source: "LLM-generated"
  • DATA_SOURCE_STATUS 字典实时追踪各数据源状态（ok/degraded/failed），降级时标注警告

三、多 Agent 协作实际是单次关键词路由（3.3）

回复：已修复。

评审的判断完全正确。原 detect_intent() 仅返回第一个匹配关键词对应的
Agent，工具集合在整个对话中不变。本轮重构如下：

  1. agents.py 新增 detect_intents()：
  • 返回所有匹配意图的排序列表
  • 例如"搜索德国LED进口商并给他们写开发信"会返回 [(buyer_agent, "搜索"), (email_agent, "开发信")]
  1. agents.py 新增 get_task_agents()：
  • 将意图列表拆解为结构化的子任务计划，每个子任务绑定 Agent 和步骤号
  1. 多意图时自动切换为 coordinator：
  • 当检测到多个意图时，Agent 循环使用 coordinator（拥有全部工具）
  • 通过更新的 MULTI_AGENT_PROMPT 驱动 LLM 按步骤切换角色和工具子集
  • 每个 Agent 可用工具在 Prompt 中明确列出
  1. 动态迭代上限：
  • 多步骤任务的最大迭代次数按意图数缩放（MAX_ITERATIONS * len(intents)）
  1. 可观测性增强：
  • 响应中注入 task_plan 和 agent_meta（含 agent_id、selected_tools、stop_reason、total_iterations）

四、展会和市场情报需要来源及有效期（3.4）

回复：已修复。

  1. 新增 _parse_tradeshow_date_range()：解析展会日期字符串，提取 start_date 和 end_date
  2. 新增 _enrich_tradeshow()：为每条展会数据注入
    source、source_url、last_verified、start_date、end_date、status、product_category
  3. 自动过滤已过期展会：find_tradeshows() 默认排除 status='ended' 的展会
  4. 新增 include_expired=True 参数供查看历史记录

五、统一项目说明和验证入口（3.5）

回复：已完成。

  1. README.md 完全重写：包含 12 个工具功能表、完整架构图、30+ 端点 API 表（标注 Auth
    列）、数据源置信度表、环境变量表、安全说明
  2. demo_walkthrough.py 提供 8 步可复现演示链路
  3. 当前 74 个测试全部通过（58 个原有 + 16 个安全测试）
  4. test_all_features.py 依赖外部 LLM API，已作为集成测试独立运行

六、综合评价回应

评审的结论——"当前最重要的提升方向不是继续增加功能，而是确保用户身份、客户数据和邮件能力得到真正保护，并保
证系统不会把模型推测内容包装成可直接用于真实业务的事实"——我们完全认同。

两轮安全加固后的项目状态：

  • 认证和授权：JWT + 全线 @login_required + 跨用户数据隔离
  • 数据可信度：全员溯源字段 + LLM 结果标记 + 禁止编造邮箱和资质
  • 任务编排：从单关键词路由升级为多步骤子任务计划
  • 知识库：展会数据有了来源、有效期、状态，自动过滤过期内容
  • 测试：74 个测试覆盖认证、越权、加密、数据源

项目已从功能丰富的演示平台向可安全用于真实外贸流程的 Agent 迈出了关键一步。感谢评审老师的指导。

提交记录：github.com/Jack-lei-prog/trademaker
部署地址：http://106.53.100.252

感谢评审老师专业、细致的审阅。以下针对各项问题和建议逐条回应。 --- 一、登录接口尚未形成服务端身份授权（3.1） 回复：已修复。 认证机制： - 新增 auth_middleware.py：JWT 令牌机制（HS256，7天过期），提供 create_token、decode_token、@login_required、@optional_login 四个接口 - auth_bp.py：/api/register 和 /api/login 成功后返回 token 字段 - config.py：启动时强制校验 SECRET_KEY 环境变量，缺失则拒绝启动 全端点鉴权覆盖： - email_bp.py：SMTP 配置读写、SMTP 发送、邮件历史等全线加 @login_required + @rate_limit - contact_bp.py：添加/列表/更新/删除/统计全部加 @login_required - dashboard_bp.py：仪表盘/工作流/偏好设置/一键获客全部加 @login_required - inquiry_bp.py：询盘处理/待处理/提醒全部加 @login_required - evaluate_bp.py：四个评价接口全部加 @login_required - 仅 /api/chat、/api/health、/api/doll 等只读或娱乐端点保持公开 数据隔离： - @login_required 从 Authorization: Bearer <token> 中提取 g.user_email，各端点统一使用 - 移除了曾存在的 body user_email fallback，彻底杜绝客户端自行声明身份 - 新增跨用户隔离安全测试，验证用户 A 读取不到用户 B 的联系人和仪表盘数据 - SMTP 密码已加密存储（Fernet），读取需经过身份验证 测试覆盖： - tests/test_security.py：16 个安全测试全部通过（认证绕过7个、越权访问2个、JWT令牌3个、密码加密2个、安全响应头2个） --- 二、邮箱和商业事实的可信度规则与代码存在冲突（3.2） 回复：已修复。评审指出三个问题，均已解决。 1. LLM prompt 要求"每家公司必须返回邮箱"： - search_companies_llm() 的 prompt 已从 "always include an email field" 改为 "NEVER guess or fabricate emails. An empty email is better than a wrong one." - email 字段允许返回空字符串，不再强制填满 2. 降级模板虚构商业资质： - 开发信降级模板中 "We have over 10 years of export experience" 已替换为 "We specialize in manufacturing and exporting high-quality products" - 不在未获用户确认的前提下宣称任何资质或经验年限 3. 推测邮箱未阻断发送： - send_email() 中强化了 email_verified 标记逻辑 - 检测到 purchasing@、info@ 等推测邮箱时，设置 email_verified: false - 前端收到该标记后应阻断一键发送，需用户显式确认 已完成的溯源基础： - data_sources.py：所有数据源结果统一携带 source、source_url、fetched_at、confidence 四字段 - LLM 生成的公司标注 confidence: 0.50、source: "LLM-generated" - DATA_SOURCE_STATUS 字典实时追踪各数据源状态（ok/degraded/failed），降级时标注警告 --- 三、多 Agent 协作实际是单次关键词路由（3.3） 回复：已修复。 评审的判断完全正确。原 detect_intent() 仅返回第一个匹配关键词对应的 Agent，工具集合在整个对话中不变。本轮重构如下： 1. agents.py 新增 detect_intents()： - 返回所有匹配意图的排序列表 - 例如"搜索德国LED进口商并给他们写开发信"会返回 [(buyer_agent, "搜索"), (email_agent, "开发信")] 2. agents.py 新增 get_task_agents()： - 将意图列表拆解为结构化的子任务计划，每个子任务绑定 Agent 和步骤号 3. 多意图时自动切换为 coordinator： - 当检测到多个意图时，Agent 循环使用 coordinator（拥有全部工具） - 通过更新的 MULTI_AGENT_PROMPT 驱动 LLM 按步骤切换角色和工具子集 - 每个 Agent 可用工具在 Prompt 中明确列出 4. 动态迭代上限： - 多步骤任务的最大迭代次数按意图数缩放（MAX_ITERATIONS * len(intents)） 5. 可观测性增强： - 响应中注入 task_plan 和 agent_meta（含 agent_id、selected_tools、stop_reason、total_iterations） --- 四、展会和市场情报需要来源及有效期（3.4） 回复：已修复。 1. 新增 _parse_tradeshow_date_range()：解析展会日期字符串，提取 start_date 和 end_date 2. 新增 _enrich_tradeshow()：为每条展会数据注入 source、source_url、last_verified、start_date、end_date、status、product_category 3. 自动过滤已过期展会：find_tradeshows() 默认排除 status='ended' 的展会 4. 新增 include_expired=True 参数供查看历史记录 --- 五、统一项目说明和验证入口（3.5） 回复：已完成。 1. README.md 完全重写：包含 12 个工具功能表、完整架构图、30+ 端点 API 表（标注 Auth 列）、数据源置信度表、环境变量表、安全说明 2. demo_walkthrough.py 提供 8 步可复现演示链路 3. 当前 74 个测试全部通过（58 个原有 + 16 个安全测试） 4. test_all_features.py 依赖外部 LLM API，已作为集成测试独立运行 --- 六、综合评价回应 评审的结论——"当前最重要的提升方向不是继续增加功能，而是确保用户身份、客户数据和邮件能力得到真正保护，并保 证系统不会把模型推测内容包装成可直接用于真实业务的事实"——我们完全认同。 两轮安全加固后的项目状态： - 认证和授权：JWT + 全线 @login_required + 跨用户数据隔离 - 数据可信度：全员溯源字段 + LLM 结果标记 + 禁止编造邮箱和资质 - 任务编排：从单关键词路由升级为多步骤子任务计划 - 知识库：展会数据有了来源、有效期、状态，自动过滤过期内容 - 测试：74 个测试覆盖认证、越权、加密、数据源 项目已从功能丰富的演示平台向可安全用于真实外贸流程的 Agent 迈出了关键一步。感谢评审老师的指导。 --- 提交记录：github.com/Jack-lei-prog/trademaker 部署地址：http://106.53.100.252
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
hanlei/trademaker#2
No description provided.