用户真正痛的不是 Agent 不够聪明，而是不可靠、不可观测、不可控
从英文论文第七章拆解自进化 Agent 的用户痛点：幻觉、循环、工具误用、上下文溢出、调试困难、成本、部署、监控与治理。
一句话
用户不是在等一个更会吹的 Agent，而是在等一个失败时能解释、能停止、能回滚、能被调试的 Agent。
三句话
自进化听起来像能力问题，但落到生产环境首先是可靠性问题。用户痛点集中在幻觉、死循环、工具误用、状态不可见、成本不可控、部署难、监控弱和安全边界模糊。真正有价值的 self-evolution，是让系统从这些失败里学习，而不是把失败包装成“自主探索”。
这篇来自论文哪一章？
Source: paper-drafts/ch7-painpoints.tex。第七章用 Mom Test 思路抽取真实用户痛点，而不是只看论文指标。
Mom Test：非专业用户会怎么问？
用户不会问：“你的 Agent 是否实现了递归自我改进？”
用户会问：
- 它为什么刚才点错了？
- 它会不会把我的文件改坏？
- 它下次能不能别犯同样错误？
- 它花了多少钱？
- 它卡住时谁来停？
- 它到底记住了什么？
- 它改了哪些规则？
如果这些问题答不上来，self-evolution 的技术叙事再漂亮也很难转化为产品信任。
痛点 1：可靠性
典型失败包括：
- 幻觉工具结果；
- 进入重复计划；
- 不读已有文件；
- 忽略用户最新指令；
- 在错误目录操作；
- 上下文超长后丢失关键约束。
这些失败不能只靠“更强模型”解决。系统需要失败分类、trace replay、反思写回和回归测试。
痛点 2：可观测性
很多 Agent 像黑盒：你只看到它说“完成了”，看不到它怎么决定、读了什么、跳过了什么、改了什么。
生产级自进化需要：
- prompt 版本；
- memory 读写记录；
- tool call trace；
- 文件 diff；
- evaluator 输出；
- 成本统计；
- promote/rollback 事件。
没有可观测性，就没有学习；没有学习证据，就没有自进化。
痛点 3：成本和延迟
自进化系统很容易把失败伪装成“多尝试几次”。重试、judge、多 agent debate、长上下文、代码执行都会烧钱。
所以成本也必须进入评价：
improvement = quality_gain - cost - latency - risk一个分数提高 3%、成本提高 300% 的系统，对用户可能是退步。
痛点 4：治理和权限
越是能自我修改的系统，越需要权限边界：
- 记忆不能随便写入长期状态；
- tool policy 不能被网页提示词修改；
- evaluator 不能被候选 Agent 改掉；
- 生产配置不能被单次 benchmark 自动覆盖；
- 高风险操作必须人类确认。
自进化不是放权，而是分层授权。
痛点到设计原则
| 用户痛点 | 系统设计 |
|---|---|
| 幻觉 | execution feedback + citation |
| 死循环 | loop detector + budget |
| 不可调试 | trace replay + structured logs |
| 成本失控 | per-task budget |
| 记忆污染 | scoped memory + expiry |
| 改坏生产 | sandbox + rollback |
| 不知道是否变好 | hidden validation |
最短产品建议
不要把“会自我进化”当卖点放第一屏。更好的说法是：
这个 Agent 会记录失败、生成候选修复、在沙盒验证、给出 diff 和证据，然后等待批准上线。
这句话比“recursive self-improvement”朴素，但更接近用户愿意信任的产品。