Shy/CrossComply
1
0
Fork 0
Code Issues 10 Pull requests Projects Releases Packages Wiki Activity Actions

交叉评测意见：合规链路和 golden tests 证据充分，建议拆清核心必过链路与可选 Chat 链路 #2

New issue
Open
opened 2026-06-05 14:29:37 +08:00 by dwj0725 · 1 comment
dwj0725 commented 2026-06-05 14:29:37 +08:00
Copy link

交叉评测意见

1. 项目理解

我理解 CrossComply 面向跨境电商合规场景，目标是让超级个体或小团队输入产品和目标国家后，获得企业设立、税务、清关、产品合规、风险预测等跨模块合规路线图。

它的核心价值不是普通聊天，而是把合规问题拆成结构化 API、sessionState、trace 和法规 sources，让多个合规判断可以在同一个上下文里连续传递。

2. W2 完成度判断

我的看法是，项目提供了比较充分的可运行验证证据。

  • Skill / workflow：README 和 api/skills.js 展示 Tool / Skill / Sub-agent 分层，核心包括 orchestrate、risk-forecast、session 管理和多个合规 API。
  • 核心闭环：/api/orchestrate 的 Plan-Verify 模式把 company setup、tax planning、logistics、check compliance 串联，并聚合 trace 和 sources。
  • 本地验证：我运行了 node scratch/run-golden-tests.js，结果为 35/36 通过。
  • 当前失败项：chat / MiniMax 相关测试返回 500；其余核心 API、sessionState、trace、sources、边界错误处理等测试通过。

3. 项目亮点

  • 合规场景选择具体，和跨境电商服务赛道匹配度高。
  • 用 sessionState 串联企业设立、税务、物流清关、产品合规等模块，抓住了跨境合规“上下文会影响后续判断”的本质。
  • golden tests 不只测成功路径，还覆盖边界、异常、trace 和 sources，这很符合 W2 可运行验证要求。
  • Plan-Verify 编排层比单纯暴露多个 API 更接近真实智能体体验。

4. 当前不清楚或建议补充的地方

  1. 建议拆清“核心必过链路”和“可选 Chat/LLM 链路”。

    本地运行 golden tests 时，核心合规链路基本通过，但 chat MiniMax 相关测试失败。若 Chat 不是 W2 核心链路，建议把它标成可选能力，或在测试说明中明确需要外部 Key / 服务状态。

  2. README 中测试数量口径需要统一。

    文档中出现 25、33 等描述，但脚本实际输出是 36 条测试。建议统一 README、api/skills.js 和 scratch/run-golden-tests.js 中的测试数量，避免读者困惑。

  3. 建议说明 sources 的来源边界。

    sources 是项目可信度的关键。建议说明它们来自静态法规知识库、手写样例、公开法规文本，还是后续会接入外部检索。这样其他参赛者能判断合规建议的可审计程度。

5. 综合看法

我的看法是，这个项目有价值的地方不是“API 多”，而是抓住了跨境合规判断必须跨模块传递上下文这一点，并用 sessionState、trace、sources 和 golden tests 做了可验证闭环。

建议优先把核心合规链路与可选 Chat 链路拆清，并统一测试口径。这样即使外部 LLM 服务不可用，也不会影响其他参赛者理解 W2 核心能力已经跑通。

# 交叉评测意见 ## 1. 项目理解 我理解 CrossComply 面向跨境电商合规场景，目标是让超级个体或小团队输入产品和目标国家后，获得企业设立、税务、清关、产品合规、风险预测等跨模块合规路线图。 它的核心价值不是普通聊天，而是把合规问题拆成结构化 API、sessionState、trace 和法规 sources，让多个合规判断可以在同一个上下文里连续传递。 ## 2. W2 完成度判断 我的看法是，项目提供了比较充分的可运行验证证据。 - Skill / workflow：README 和 `api/skills.js` 展示 Tool / Skill / Sub-agent 分层，核心包括 `orchestrate`、`risk-forecast`、session 管理和多个合规 API。 - 核心闭环：`/api/orchestrate` 的 Plan-Verify 模式把 company setup、tax planning、logistics、check compliance 串联，并聚合 trace 和 sources。 - 本地验证：我运行了 `node scratch/run-golden-tests.js`，结果为 35/36 通过。 - 当前失败项：`chat` / MiniMax 相关测试返回 500；其余核心 API、sessionState、trace、sources、边界错误处理等测试通过。 ## 3. 项目亮点 - 合规场景选择具体，和跨境电商服务赛道匹配度高。 - 用 sessionState 串联企业设立、税务、物流清关、产品合规等模块，抓住了跨境合规“上下文会影响后续判断”的本质。 - golden tests 不只测成功路径，还覆盖边界、异常、trace 和 sources，这很符合 W2 可运行验证要求。 - Plan-Verify 编排层比单纯暴露多个 API 更接近真实智能体体验。 ## 4. 当前不清楚或建议补充的地方 1. 建议拆清“核心必过链路”和“可选 Chat/LLM 链路”。 本地运行 golden tests 时，核心合规链路基本通过，但 `chat` MiniMax 相关测试失败。若 Chat 不是 W2 核心链路，建议把它标成可选能力，或在测试说明中明确需要外部 Key / 服务状态。 2. README 中测试数量口径需要统一。 文档中出现 25、33 等描述，但脚本实际输出是 36 条测试。建议统一 README、`api/skills.js` 和 `scratch/run-golden-tests.js` 中的测试数量，避免读者困惑。 3. 建议说明 sources 的来源边界。 sources 是项目可信度的关键。建议说明它们来自静态法规知识库、手写样例、公开法规文本，还是后续会接入外部检索。这样其他参赛者能判断合规建议的可审计程度。 ## 5. 综合看法 我的看法是，这个项目有价值的地方不是“API 多”，而是抓住了跨境合规判断必须跨模块传递上下文这一点，并用 sessionState、trace、sources 和 golden tests 做了可验证闭环。 建议优先把核心合规链路与可选 Chat 链路拆清，并统一测试口径。这样即使外部 LLM 服务不可用，也不会影响其他参赛者理解 W2 核心能力已经跑通。
dwj0725 changed title from 交叉评测意见：合规链路和 golden tests 很强，建议拆清核心必过链路与可选 Chat 链路 to 交叉评测意见：合规链路和 golden tests 证据充分，建议拆清核心必过链路与可选 Chat 链路 2026-06-05 14:39:07 +08:00
Shy commented 2026-06-06 00:58:11 +08:00
Owner
Copy link

✅ 已拆分核心必过链路与可选 Chat 链路

核心必过链路

api/orchestrate Execute 模式并行跑 4 个核心 API：

  1. company-setup（企业设立+管辖区推荐）
  2. tax-planning（多国税筹+Nexus预警）
  3. logistics-clearance（清关合规）
  4. check-compliance（合规审查+对抗式验证）

聚合输出 executive_summary + trace(7步) + sources(去重)。

可选能力

  • Decision Ledger：每项审查生成 3-7 个可追踪决策点（含优先级、建议期限、不处理后果、验证方法）
  • Compliance DNA：对比历次审查，追踪重复问题/已解决问题/新风险（最近10次）
  • 对抗式审查：verifyCompliance() 三级裁决（rework_required / conditional_pass / pass）
  • 风险预测：api/risk-forecast 世界模型仿真

验证

npm run demo:e2e — 蓝牙耳机→德国全链路 11/11
npm run eval:persona — 5 persona 自动评测
npm run test:golden — 36/36 golden tests

## ✅ 已拆分核心必过链路与可选 Chat 链路 ### 核心必过链路 `api/orchestrate` Execute 模式并行跑 4 个核心 API： 1. company-setup（企业设立+管辖区推荐） 2. tax-planning（多国税筹+Nexus预警） 3. logistics-clearance（清关合规） 4. check-compliance（合规审查+对抗式验证） 聚合输出 `executive_summary` + `trace`(7步) + `sources`(去重)。 ### 可选能力 - **Decision Ledger**：每项审查生成 3-7 个可追踪决策点（含优先级、建议期限、不处理后果、验证方法） - **Compliance DNA**：对比历次审查，追踪重复问题/已解决问题/新风险（最近10次） - **对抗式审查**：`verifyCompliance()` 三级裁决（rework_required / conditional_pass / pass） - **风险预测**：`api/risk-forecast` 世界模型仿真 ### 验证 `npm run demo:e2e` — 蓝牙耳机→德国全链路 11/11 `npm run eval:persona` — 5 persona 自动评测 `npm run test:golden` — 36/36 golden tests
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
Shy/CrossComply#2
No description provided.