跳转至

别再把上下文当聊天记录

Ch01.456 别再把上下文当聊天记录

📊 Level ⭐⭐ | 7.8KB | entities/别再把上下文当聊天记录.md

-> 原文存档 从微信文章 别再把上下文当聊天记录 提取。

核心内容

source_url: https://mp.weixin.qq.com/s/ajurJ3Vayd9qLIwh9M3Fnw

主要章节

  • 赌注：相信模型能管理自己的上下文

  • 真正的工程难点：会话剪枝

  • 子智能体上下文管理

  • 设计在哪里收敛

  • 参考阅读：

深度分析

「上下文不是聊天记录」这个论点的核心洞见在于：LLM 的上下文窗口并不是一个「记忆空间」，而是一个「工作空间」。聊天记录的形式（role / content 交替、时序排列）只是一个历史实现细节，并不对应 LLM 处理信息的最佳方式。会话剪枝（Session Pruning）的真正难点不是「保留哪些消息」，而是「保留哪些信息对当前子任务最有效」。 「赌注：相信模型能管理自己的上下文」这个表述背后有一个深刻的设计哲学转变：传统软件开发中，开发者控制所有状态；在 Agent 系统中，开发者需要把状态管理权委托给模型，但同时提供足够的结构化约束。这个平衡点极其难找——给模型太多自由会导致不可预测行为，给太少又会让模型失去真正的推理能力。 子智能体上下文管理是一个尚未被很好解决的工程问题。当一个复杂任务被分解为多个子 Agent 并行执行时，每个子 Agent 都需要自己的上下文切片，而这些切片之间如何保持信息一致性、如何处理交叉依赖（一个子 Agent 的输出是另一个子 Agent 的输入），目前的解决方案都还相当粗糙。

实践启示

Agent 系统设计者：不要把上下文当黑箱，不要假设「给模型越多的上下文越好」。正确的做法是：明确任务的上下文需求窗口（需要在多少 token 内完成），设计上下文注入策略（在何时注入何种信息），并在 Harness 层实现上下文预算控制。 会话管理实现者：在实现会话剪枝时，应该基于信息贡献度而非时间顺序来决定保留/丢弃哪些消息。可以利用嵌入相似度、注意力权重分析或小模型代理等方法来评估每条消息的信息价值，而非简单粗暴地保留最近 N 条消息。 多 Agent 系统架构师：子 Agent 之间的上下文共享应该通过结构化的「上下文边界」（Context Boundary）来实现，而不是通过把所有子 Agent 的上下文简单拼接在一起。每个子 Agent 应该只看到它完成任务所必须的最少上下文。

ai agent platforms topic map（已删除）

相关实体