Engram v3.13.2 里程碑评估报告

评估日期: 2026-05-22 版本: v3.13.2 评估方式: 内部自评 + 5 家外部 AI 独立评测
目录

一、综合评分

6.9
外部平均分
7.5
内部自评
-0.6
校准偏差
32
问题总数
维度CursorOpusCodexGPTDeepSeek平均自评偏差
文档质量8.27.08.07.08.57.7
代码架构6.45.05.55.54.55.47-1.6
MCP 实现8.07.07.06.87.07.2
测试质量7.67.08.27.26.07.27准确
安全隐私7.17.06.06.45.06.38-1.7
产品定位7.25.07.67.58.07.17准确
综合7.36.57.17.06.46.97.5-0.6
最大自评盲区:安全维度高估 1.7 分(自评 8 → 外部 6.3),架构维度高估 1.6 分(自评 7 → 外部 5.4)。 根因:安全上犯了"实现了就以为安全了"的认知错误;架构上犯了"作者熟悉就以为清晰"的专家盲区。

二、逐项回应

五家评测共提出 32 项独立问题/建议,按结论分类统计:

24
接受(含降级/部分)
6
暂缓
2
不接受

2.1 代码架构(外部平均 5.4 / 自评 7)

A. core.py 4277 行必须拆分 接受

提出者:全部 5 家 | 置信度:最高

理由:全票一致。单文件承载 CRUD + 搜索 + 冲突检测 + 上下文生成 + HTML 页面 + 导入导出 + 迁移,违反单一职责。外部贡献者和 AI 修改代码的回归成本持续上升。

方案:拆为 8 模块(storage / retrieval / conflicts / context / reconcile / reports / compat / facade),无行为变化,每拆一块 327 测试全绿。

B. print(stderr) → logging 模块 接受

提出者:Opus / Codex / GPT / DeepSeek(4/5)

21 处 print(..., file=sys.stderr) 是 Python 反模式。MCP stdio server 裸写 stderr 有协议污染风险。伴随拆分同步完成。

C. generate_review_page 414 行 HTML 在数据层 接受

提出者:Opus / GPT / DeepSeek

表现层逻辑(HTML+CSS+JS f-string 拼接)在核心类里是最明显的 code smell。归入 reports.py 拆分阶段。

D. schema 版本字符串比较 bug 接受(降级)

提出者:Opus

"10.0" < "2.0" 在字符串比较中为 true。当前版本 "2.0" 短期无风险,storage.py 拆分时顺手修复。

E. 引入 Pydantic / dataclass 暂缓

提出者:Codex / GPT / DeepSeek

当前 dict + 327 测试维持住了。Pydantic 会增加核心依赖(当前仅 mcp + portalocker),违反轻量级定位。拆分完成后再评估。

F. 异常层次结构 暂缓

提出者:DeepSeek

对单一维护者够用。等有第二个贡献者或 MCP 层统一返回值后一起引入。

G. 常量迁移到独立 constants.py 不接受

提出者:DeepSeek

常量已集中在 core.py 顶部 50 行。拆分后常量自然跟随模块(如 SEARCH_RELEVANCE_THRESHOLD 进 retrieval.py),不需要额外间接层。

H. _read_json 中 sys 未导入 需验证

提出者:GPT / DeepSeek

具体的代码 bug 断言,需实际检查。如属实则立即修复。

2.2 安全与隐私(外部平均 6.3 / 自评 8)

自评偏差最大的维度(高估 1.7 分)。以下每一项都需要认真对待。

I. SECURITY.md 写 Fernet,代码是 AES-GCM 紧急修复

提出者:全部 5 家 | 置信度:最高

安全文档把自己的加密原语说错,对主打隐私的项目是致命的信任伤害。

J. 加密静默失效 — ENGRAM_SECRET 设了但 cryptography 未装 紧急修复

提出者:DeepSeek(独有发现)

用户设了密钥以为安全,实际明文存储——"最危险的安全反模式"。应改为 raise RuntimeError 拒绝启动。

K. SSE token 非恒定时间比较 接受

提出者:Opus / Codex / GPT(3/5)

auth_header[7:] != self.token 存在 timing attack 面。改用 secrets.compare_digest,一行修复。

L. PBKDF2 100k 轮偏低 部分接受

提出者:Opus / Codex / GPT / DeepSeek(4/5)

提升到 600k 轮(OWASP 建议)。不引入 Argon2(避免新依赖)。用 enc:v2: 前缀处理兼容迁移。

M. "100% 本地 / 零网络" 叙事需精确化 接受

提出者:Opus / Codex / GPT / DeepSeek(4/5)

改为三层表述:(1) Core: 零网络 (2) Reader: 仅 localhost (3) SSE: 可选自托管+TLS

N. 导入导出路径参数无校验 部分接受

提出者:Opus / Codex / GPT / DeepSeek(4/5)

默认限制为 ~/.engram/ 子目录;超出范围返回警告但不硬拒绝(本地信任模型)。

O. CORS 默认 * 且无认证 接受

提出者:DeepSeek(独有发现)

SSE 模式 host ≠ 127.0.0.1 且无 token 时,拒绝启动。CORS 默认限制为 localhost。

P. restricted_fields 扩展到其他类型 暂缓

提出者:Codex / GPT

Profile 是唯一含 PII 的地方。Lessons/decisions 本身就是要注入给 AI 的,过滤会损害核心价值。

Q. 密文未记录 KDF 参数 接受(降级)

提出者:GPT / DeepSeek

当前 enc:v1: 前缀已预留版本化空间。升级时用 enc:v2: 标记,解密按前缀选参数。

R. HSM 支持 不接受

提出者:DeepSeek

Engram 是个人开发者工具,不是企业安全基础设施。HSM 完全超出目标用户场景。

2.3 MCP 协议实现(外部平均 7.2)

S. *_json 参数改结构化 schema 接受

提出者:Cursor / Codex / GPT / DeepSeek(4/5)

用 FastMCP 支持的 Python type hints 替代字符串参数。先改 Tier-1 的 10 个工具,再改 Tier-2。

T. 返回值格式不统一 部分接受

提出者:Codex / GPT / DeepSeek(3/5)

成功时 JSON 结构化;错误保持自然语言(LLM 理解更好),但包一层 {"ok": false, "error": "..."}。不做完整 envelope。

U. 只读能力应作为 MCP Resources 接受(降级)

提出者:DeepSeek(独有发现)

MCP 规范正确。但 FastMCP 对 Resources 的 LLM 集成不够成熟,Claude Code/Cursor 体验不统一。等生态成熟后迁移。

V. 43 个工具偏多 部分接受

提出者:全部 5 家

Tier-1 默认 10 个已解决核心问题。不大幅合并(损失语义清晰度),但给 Tier-2 加分组标签和 "When NOT to use" 指引。

W. ENGRAM_TOOLS 更细粒度模式 暂缓

提出者:GPT

core / all 两档覆盖 95% 场景。等用户反馈后再加细分。

X. 工具缺行为注解 接受(降级)

提出者:GPT

先在 docstring 补充行为说明,后续 MCP 规范支持时正式标注。

Y. _apply_tool_tier 依赖 FastMCP 私有 API 接受(降级)

提出者:Cursor / Codex

当前唯一方案。Pin FastMCP 版本,等公开 API 后迁移。

Z. _apply_tool_tier 注释与行为矛盾 紧急修复

提出者:Opus / GPT / Codex

注释写 "Keep all tools by default" 但默认值是 "core"。一行修复。

2.4 测试与质量保障(外部平均 7.2 / 自评 7)

AA. mcp_server.py 覆盖率 38% 接受

提出者:Opus(实测) / Codex / GPT / DeepSeek

新增 test_mcp_tools.py,覆盖 Tier-1 全部 + Tier-2 高频 5 个。

AB. 缺 MCP stdio E2E 测试 接受

提出者:全部 5 家

新增 test_mcp_e2e.py:子进程启动 server → list_tools → 调用核心工具 → 验证返回。

AC. 缺覆盖率门禁 接受(降级)

提出者:GPT / DeepSeek

先加覆盖率报告(不设门禁),拆分完成后再设阈值。

AD. 缺并发写压力测试 暂缓

提出者:Codex / GPT

单用户单进程场景,portalocker 已保证互斥。不是当前真实场景。

AE. 加密测试只有 7 个 接受

提出者:DeepSeek

补充:错误密钥、损坏密文、cryptography 缺失、PBKDF2 升级兼容。

AF. 缺安全压力测试 接受(降级)

提出者:Codex / GPT / DeepSeek

reports.py 拆分后补充 XSS payload fixture。

AG. benchmark 不在 pytest 范围 接受(降级)

提出者:Codex

设计为独立脚本(需 API key)。可加为 nightly 可选 job。

2.5 文档质量(外部平均 7.7)

AH. FAQ 安装路径不一致 紧急修复

提出者:Cursor / Codex / GPT(3/5)

AI. README 未说明 ENGRAM_TOOLS 默认行为 紧急修复

提出者:Opus / Codex / GPT(3/5)

AJ. stale days 90 vs 代码 30 紧急修复

提出者:Codex / GPT

AK. 缺 architecture.md 接受(降级)

提出者:GPT

core.py 拆分完成后再写(否则写完就过时了)。

AL. README 表格渲染问题 需验证

提出者:GPT

AM. "automatically" 措辞过度承诺 接受

提出者:GPT

2.6 产品差异化与市场定位(外部平均 7.1)

AN. 赛道拥挤(OMEGA 等竞品)部分接受

提出者:Opus(独有深度分析)

信息有价值,但核心差异不在检索性能而在跨工具身份共享。在竞品对比中加入 OMEGA 等,明确差异点。

AO. 检索能力相对落后 部分接受

提出者:Opus

200 条规模够用。短期不加向量检索(避免重依赖),中期提供 embedding hook 接口。

AP. 缺可视化 demo/GIF 接受

提出者:全部 5 家 | 置信度:最高

录制 60 秒跨工具 demo,嵌入 README 首屏。

AQ. ICP 铺太宽 接受

提出者:Cursor / Codex / GPT / DeepSeek(4/5)

主文只保留"多工具 AI coding power users",其他 persona 收入折叠区。

AR. piia-engram 包名品牌断裂 部分接受

提出者:Codex / GPT / DeepSeek(3/5)

短期 README 解释清楚,长期评估是否迁移。

AS. "身份层"需要可检验定义 接受

提出者:GPT

AT. 需要量化效果证据 接受(降级)

提出者:Cursor

Round 10 D4 测试完成后作为 README badge。

三、自评盲区分析

3.1 安全维度高估(偏差 -1.7 分)

根因:犯了"实现了就以为安全了"的认知错误。

教训:安全评估必须同时检查"做了什么"、"说了什么"(文档)、"没做什么"(失效路径)、"说过头了什么"(营销口径)。

3.2 架构维度高估(偏差 -1.6 分)

根因:典型的"专家盲区"——作者对 4277 行文件的心智地图完整,感觉"结构清晰"。外部评测者(模拟新贡献者)普遍感到不可维护。

教训:架构评估必须从"陌生人能否在 30 分钟内理解并安全修改"的角度出发。

3.3 产品定位的评测者分歧

Opus 给 5 分(赛道拥挤),其他四家给 7.2-8.0。Opus 做了最深的竞品扫描,发现了我们不知道的竞品。

教训:叙事自洽 ≠ 市场安全。需要持续监控竞品动态。

四、行动计划

Phase 1: 紧急修复(1-2 天)→ v3.14.0
#任务问题复杂度
1SECURITY.md: Fernet → AES-256-GCMI
2加密静默失效 → raise RuntimeErrorJ
3SSE token → secrets.compare_digestK
4_apply_tool_tier 注释修正Z
5README FAQ 安装路径统一AH
6README 加 ENGRAM_TOOLS 说明AI
7README stale days 90 → 30AJ
8"100% local" 叙事精确化M
9"automatically" 措辞修正AM
10SSE 安全加固(CORS + 无 token 警告)O
11验证 sys 导入问题H
Phase 2: core.py 拆分(3-5 天)
阶段拆出模块预估行数依赖
2astorage.py~200
2bretrieval.py + conflicts.py~400storage
2creports.py~500storage
2dreconcile.py~400storage
2econtext.py~200retrieval, storage
2fcompat.py~300storage

伴随完成:print→logging / schema 版本比较 / PBKDF2 600k 升级

Phase 3: MCP 加固 + 测试补全(3-5 天)
#任务问题
1test_mcp_tools.py: Tier-1 全部 + Tier-2 高频AA
2test_mcp_e2e.py: stdio 冒烟测试AB
3test_crypto.py 扩展到 20+AE
4*_json 参数结构化(Tier-1 先行)S
5返回值半结构化T
6路径参数校验N
7覆盖率报告AC
Phase 4: 产品与文档(2-3 天)
#任务问题
1录制 60 秒跨工具 demo GIFAP
2README ICP 收窄AQ
3"身份层"可检验定义AS
4竞品对比加入 OMEGA 等AN
5piia-engram 品牌解释AR
6docs/architecture.mdAK

五、决策记录

  1. core.py 拆分为 8 个模块 — 全票一致,最高优先级
  2. 不引入 Pydantic — 避免增加核心依赖
  3. 不引入 Argon2 — PBKDF2 600k 足够,避免新依赖
  4. 不大幅合并 MCP 工具 — Tier-1/Tier-2 分层已解决核心问题
  5. 不加向量检索 — 保持轻量级定位,预留 hook 接口
  6. 不迁移 PyPI 包名 — 短期解释清楚,长期再评估
  7. 质量评估双轨制 — 每个里程碑版本自评 + 外部评测

六、附录:各评测者特点与可信度

评测者评测方式特点最有价值发现
Cursor 2.5静态阅读最友好generate_context 副作用
Opus 4.7clone + 跑测试 + 覆盖率最严格OMEGA 竞品、38% 覆盖率、timing attack
Codex 5.5clone + 跑测试最实操拆分顺序、MCP 契约文档
GPT Pro静态 + MCP 规范最合规MCP Resources、sys bug、KDF 参数
DeepSeek静态阅读最关注安全加密静默失效、CORS 风险
可信度加权:Opus 和 Codex 实际运行了代码,发现比静态阅读更精准。建议未来评测优先选择能执行代码的评测者。