【S1W2 交叉评测】对项目 matchmaker 的反馈 #4

New issue

Open

opened 2026-05-15 21:20:28 +08:00 by zzzzz · 1 comment

zzzzz commented

2026-05-15 21:20:28 +08:00

为了离线运行，你们现在没怎么用 LLM，那 run_scenario 里的对话质量能不能保住？如果只是跑个规则脚本，可能实际体验会有点生硬。
隐私保护这块，代码里到底是怎么隔离的？

看了你们组的 Readme，最直观的感受是工程底子非常扎实。比较惊艳的是你们把“相亲”这种感性需求拆解得很有逻辑。特别是那个能量模型，这点比单纯做性格匹配要高级很多，确实抓住了感情里“内耗”和“赋能”的痛点。而且文档写得很专业，不仅给评审看，连 Agent 调用的接口说明都备好了，这种“面向 Agent 编程”的思维很超前，运行起来应该很丝滑。不过也有几个想讨论的地方： 1. 为了离线运行，你们现在没怎么用 LLM，那 run_scenario 里的对话质量能不能保住？如果只是跑个规则脚本，可能实际体验会有点生硬。 2. 隐私保护这块，代码里到底是怎么隔离的？

link commented

2026-05-15 23:13:51 +08:00

Owner

谢谢您的认可，也很高兴您注意到了能量模型和面向 Agent 调用的接口设计。

你提到的两个问题都很关键，我这边也做了一点补充说明和实现更新：

关于离线运行和 LLM

当前 Wave 2 版本确实没有强依赖外部 LLM，主要是为了保证评测环境可稳定运行：不需要 API key、不需要外网、不需要数据库，py server.py 就能跑完整闭环。

为了避免它变成纯固定模板，我们已经做了几层动态化：

simulate_match 会根据双方共同记忆和缺失维度动态展开多轮代理对话，不再是固定 4 轮。
run_scenario 的分数不再硬编码，而是根据场景相关维度覆盖率、共享记忆、沟通风格、对话清晰度和风险词动态计算。
create_agent 会从用户自然语言资料里推断沟通直接度、共情倾向和规划倾向。
update_memory 会返回冲突检测和更新策略，为后续真正的对话学习打基础。

所以当前更准确的定位是：零依赖动态规则引擎 + 可替换 LLM Provider 的原型。到 Wave 3，如果评测环境允许 API key，我们可以把 extract_memory、simulate_match、run_scenario、generate_report 的内部实现替换成 LLM，但保持 Skill API 和 Agent Orchestrator 不变。

关于隐私隔离

这个问题非常重要。当前原型不是生产级物理隔离系统，但代码里已经明确了本地边界：

server.py 只使用 Python 标准库 HTTP 服务，没有数据库连接。
不主动调用第三方 API 或云端 LLM。
用户 profile / memory 只在单次请求的本地进程内参与计算，不做持久化保存。
log_message 被覆盖为空函数，默认不打印用户画像内容到访问日志。
新增了 GET /api/privacy，可以直接查看当前隐私边界。
POST /api/agent/run 的返回里也新增了 privacy_boundary 字段，方便评审检查。

未来真实产品阶段，我们会倾向于把 Memory Vault 放在用户本地或边缘可信设备中，平台侧只拿脱敏摘要和必要评分结果。也就是说，当前 Wave 2 先做到“本地原型不出域”，后续再升级到“边缘可信隔离”。

再次感谢这个问题，它帮助我们把“文档里的隐私声明”进一步落实到了代码可检查的接口里。

谢谢您的认可，也很高兴您注意到了能量模型和面向 Agent 调用的接口设计。你提到的两个问题都很关键，我这边也做了一点补充说明和实现更新： 1. 关于离线运行和 LLM 当前 Wave 2 版本确实没有强依赖外部 LLM，主要是为了保证评测环境可稳定运行：不需要 API key、不需要外网、不需要数据库，`py server.py` 就能跑完整闭环。为了避免它变成纯固定模板，我们已经做了几层动态化： - `simulate_match` 会根据双方共同记忆和缺失维度动态展开多轮代理对话，不再是固定 4 轮。 - `run_scenario` 的分数不再硬编码，而是根据场景相关维度覆盖率、共享记忆、沟通风格、对话清晰度和风险词动态计算。 - `create_agent` 会从用户自然语言资料里推断沟通直接度、共情倾向和规划倾向。 - `update_memory` 会返回冲突检测和更新策略，为后续真正的对话学习打基础。所以当前更准确的定位是：零依赖动态规则引擎 + 可替换 LLM Provider 的原型。到 Wave 3，如果评测环境允许 API key，我们可以把 `extract_memory`、`simulate_match`、`run_scenario`、`generate_report` 的内部实现替换成 LLM，但保持 Skill API 和 Agent Orchestrator 不变。 2. 关于隐私隔离这个问题非常重要。当前原型不是生产级物理隔离系统，但代码里已经明确了本地边界： - `server.py` 只使用 Python 标准库 HTTP 服务，没有数据库连接。 - 不主动调用第三方 API 或云端 LLM。 - 用户 profile / memory 只在单次请求的本地进程内参与计算，不做持久化保存。 - `log_message` 被覆盖为空函数，默认不打印用户画像内容到访问日志。 - 新增了 `GET /api/privacy`，可以直接查看当前隐私边界。 - `POST /api/agent/run` 的返回里也新增了 `privacy_boundary` 字段，方便评审检查。未来真实产品阶段，我们会倾向于把 Memory Vault 放在用户本地或边缘可信设备中，平台侧只拿脱敏摘要和必要评分结果。也就是说，当前 Wave 2 先做到“本地原型不出域”，后续再升级到“边缘可信隔离”。再次感谢这个问题，它帮助我们把“文档里的隐私声明”进一步落实到了代码可检查的接口里。

No labels

No milestone

No project

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

link/matchmaker#4

No description provided.

Rows
Columns