关于L0生成阶段只提取text对话的质疑?

[abc19899]

我是一个程序员, 在L0生成阶段, 只提取了type=text内容, 我觉得很多时候工具链也是很重要的. 它包含了一个功能是如何实现的, 比如写代码前, llm通过大量探索, 找到了正确的知识. 除了知识可以被总结为经验外, 如何搜索知识本身也应该是一个经验, 它只存在工具链调用中. 另外工具链也包含者一个错误的教训是怎们产生的, 比如llm在调用shell时多次出错, 出错的工程也应该是经验.
另外, 以下是opus4.8 给出的评价:

Q: 你评价一下这个 只读取 text的过滤机制 在 总结对话 的效果怎么样?  
A: 这是个很好的设计权衡问题。我的总体判断是:text-only 过滤在「chat 模式(沉淀用户画像)」下是明智且高性价比的,但在「code 模式(团队工作记忆)」下是明显的盲区。 分开看。

它做对了什么(优点)
1. 信噪比优先,这在记忆场景是对的。 记忆的目标是「让下一个 Agent 少走弯路」,核心是沉淀用户是谁、要什么、定过什么结论。toolcall 参数、tool_result(常是大段 JSON / 日志 / 文件内容)、thinking 都是过程性噪声,对"理解人"贡献很低。全量塞进去反而稀释信号、拖垂 embedding 质量、浪费 LLM 提取的上下文预算。

2. 过滤 thinking 尤其正确。 thinking 是模型的试探性推理,充满自我怀疑、被中途推翻的假设、错误的中间结论。它不代表最终结论。把它当对话内容去提炼 L1,极易把"想过但否定了的东西"误记成事实——这是记忆污染的高发区。丢弃是稳妥的。

3. 实现简单、跨框架稳定。 只认 type==="text" 是各家消息格式的最大公约数,不用适配每个框架的 tool/thinking 结构,鲁棒性好。

它的代价(缺点,主要在"总结对话"上)
1. 任务执行类对话会丢主线。 在 coding / agent 场景,"到底做了什么"的信息大量藏在 toolcall 里:读了哪些文件、跑了什么命令、改了什么、测试结果如何。text-only 只能看到用户的指令和 assistant 的自然语言旁白。如果 assistant 习惯"少说多做"(直接调工具、只回一句"好了"),那 L0 会很稀疏甚至空洞,L1 根本总结不出 work_task / work_artifact。这对 README 里主打的团队工作记忆(code 模式)是结构性短板。

2. 因果链断裂。 典型链路:用户"帮我查 X"→ 工具返回 Y → assistant"根据结果,建议 Z"。中间的 Y 被丢了。如果 assistant 的 text 用了指代("根据上面的结果…"),脱离工具输出后这句话会语义不完整,而 L1 提示词又恰恰要求"独立完整、跳出对话仍成立"——这类记忆要么提不出,要么提得含糊。

3. 一刀切丢 thinking 偶尔误伤。 thinking 里有时藏着用户偏好的真实推断或决策理由。全丢会损失极少数高价值信号——不过考虑到污染风险,这个取舍我认为可以接受。

(下面还是opus4.8的回答, 排版不方便, 直接从md复制了)

场景适配结论

对话类型	text-only 效果	原因
闲聊 / 咨询 / 个人助理（chat 模式）	好	价值信号本就在自然语言里，过滤纯降噪，抗污染
任务执行 / coding / 多工具（code 模式）	偏弱	关键「做了什么」的信息在 tool 调用里，被整体丢弃

总体判断：text-only 过滤是「为 chat 场景优化」的降噪设计——在个人偏好沉淀上简单有效、抗污染；但它把工具执行的过程信息一并舍弃，使得团队 / coding 场景的对话总结出现明显盲区。

为什么 chat 场景合适

• 信噪比优先：记忆目标是沉淀「用户是谁、要什么、定过什么结论」，toolcall / tool_result / thinking 都是过程性噪声，全量纳入会稀释信号、拖垮 embedding 质量、浪费提取上下文预算。
• 过滤 thinking 尤其正确：thinking 充满试探性、被中途推翻的假设与错误中间结论，不代表最终结论；纳入极易把「想过但否定的东西」误记为事实，是记忆污染高发区。
• 实现简单、跨框架稳定：只认 type === "text" 是各家消息格式的最大公约数，鲁棒性好。

为什么 code 场景偏弱

• 任务主线丢失：coding / agent 场景里「到底做了什么」大量藏在 toolcall（读了哪些文件、跑了什么命令、改了什么、测试结果）。text-only 只能看到用户指令和 assistant 的自然语言旁白。若 assistant「少说多做」，L0 会稀疏甚至空洞，L1 无法总结出 work_task / work_artifact。
• 因果链断裂：用户「帮我查 X」→ 工具返回 Y → assistant「根据结果建议 Z」，中间的 Y 被丢；若 assistant 用指代（「根据上面的结果…」），脱离工具输出后语义不完整，而 L1 又要求「独立完整、跳出对话仍成立」，这类记忆要么提不出、要么含糊。

---

如果要改进

不建议走极端（全量纳入会引回噪声），而是做摘要式、结构化纳入：

1. tool 轻量元数据：保留「调用了什么工具 + 关键参数 + 结果一句话摘要」，而不是全量 JSON。这样 L1 能总结出「改了 auth 模块」「跑通了测试」，又不爆上下文。
2. 按模式差异化捕获：chat 模式维持 text-only；code 模式额外捕获 tool 摘要，喂给 work memory 提取。
3. thinking 仍丢弃，但可考虑仅在提取 episodic（事件）时，对 thinking 里的「最终决策理由」做一次轻量抽取——会增加复杂度，优先级低。

---

一句话评价:这是一个"为 chat 场景优化"的降噪设计——在个人偏好沉淀上简单有效、抗污染;但它把工具执行的过程信息一并舍弃,使得团队/coding 场景的对话总结出现明显盲区。要补齐,方向是"tool 结果摘要化纳入 + 按 chat/code 模式差异化捕获",而非放开全量或继续一刀切。