Custom Agent 是否需要个性化上下文压缩

[sfsflm]

想探讨上下文压缩是否需要针对不同智能体做定制的问题
1：是否需要？
2：如果需要，哪些需要支持自定义呢？
（1）压缩配置中的阈值是否都需要支持自定义
（2）压缩提示词是否需要支持自定义，如果需要的话，是整个summary_prompt都自定义配置，还是采取BASE基础压缩模板 + 个性化压缩要求 的方式呢？

[WillemJiang]

先给结论，再分别展开。核心判断：部分需要——机制（压缩算法/skill 抢救/trim 策略）应保持全局共享，真正需要 per-agent 的是「是否/何时触发」和「摘要强调什么」这两类"旋钮"。

现状（代码层面的事实）

• 压缩配置 SummarizationConfig（packages/harness/deerflow/config/summarization_config.py）目前是全局唯一的，对应 config.yaml 顶层一个 summarization: 段，由 get_app_config().summarization 读取，对所有 agent（lead + 每个自定义 agent）一视同仁。
• 它已经支持了几乎所有可调项：enabled / model_name（独立轻量摘要模型）/ trigger（messages·tokens·fraction，可单个或列表，任一命中即触发）/ keep（保留策略）/ trim_tokens_to_summarize / summary_prompt（整段自定义，缺省回退 LangChain 默认）/ preserve_recent_skill_*（skill 跨压缩抢救）。
• 自定义 agent 的配置在 {base_dir}/users/{user_id}/agents/{name}/config.yaml，由 AgentConfig（agents_config.py）承载，目前字段是 name / description / model / tool_groups / skills。注意：load_agent_config 会显式丢弃未知字段（known_fields = AgentConfig.model_fields），所以即使现在往 agent 的 config.yaml 写 summarization:，也会被静默丢弃——要做 per-agent 必须先扩 AgentConfig。

Q1：是否需要？

需要，但是选择性的，原因是不同 agent 的"上下文经济学"差异很大：

• 需要更激进压缩：深度研究 / 写代码类 agent —— tool 历史、task() 子 agent 结果、大文件 read_file 多，很快逼近 token 上限，靠 trigger 提前压缩收益明显。
• 需要更晚/更保守压缩：严格指令型、参考型、数据录入型 agent —— 摘要是有损且不可逆的操作（压缩后原始 messages 从 checkpoint 消失），丢细节会直接伤害这类 agent 的价值。这类 agent 真正想要的是"几乎别压缩"。

所以需求是真实的。但要点明一个边界：因为压缩写回的是线程共享的 checkpoint，per-agent 配置在"一个线程长期被同一个 agent 使用"时最有意义；如果用户在线程里中途切换 agent，A agent 的激进压缩会永久影响 B agent 看到的历史。这点要在设计里承认（当前 run 的 agent 决定压缩策略，但摘要一旦写入即为线程共享）。

Q2(1)：阈值是否都需要支持自定义？

不建议把每个阈值都做成 per-agent——那是配置面爆炸。 建议"分层覆盖 + 回退全局默认"，与 AgentConfig 现有的 model / tool_groups / skills per-agent 覆盖模式保持一致：

• 应当 per-agent 可覆盖（真正改变行为）：enabled、trigger、keep、model_name。
• 建议保持全局（操作/质量旋钮，agent 人格无关）：trim_tokens_to_summarize、preserve_recentl_names。价值低，徒增心智负担。

落地方式：给 AgentConfig 增加一个可选字段，比如 summarization: SummarizationOverrides | No _create_summarization_middleware（lead_agent/agent.py:79）里用"agent 覆盖 → 全局app_config.summarization"合并后再构造中间件。agent 本身按 agent_name 在构建期解析，与 model/tool_groups/skills 的解析时机一致，不破坏"agent 缓存复用"假设。

Q2(2)：summary_prompt —— 整体自定义 vs BASE + 个性化要求？

强烈推荐 BASE 模板 + 个性化要求，而不是整段替换。 三个理由，都和代码里既有的隐性契约有关：

1. BASE prompt 背负着代码依赖的契约。summarization_middleware.py:187 执行的是 self.summary_prompt.format(messages=formatted_messages)——也就是说自定义 prompt 必须保留 {messages} 占位符，否则运行时直接 KeyError。整段替换很容易踩这个坑，且没有校验。此外输出还得落在 keep/trim 预算内、语义上能 都是 BASE 已经处理好的不变量。
2. per-agent 的个性化本质是"强调什么 / 用什么风格"（例如"保留所有代码片段""保留精确数值""聚焦用户偏好"），天然就是一条附加指令，追加到 BASE 之后即可——这和 DeerFlow 现在注入 skills / SOUL.md 的"基础模板 + 追加上下文"是同一个范式，风格统一。
3. 可维护性：BASE 改进（更好的预算控制、更好的消息裁剪）所有 agent 自动继承；整段替换则让每个 agent 冻结在旧版 prompt 上。

具体建议：

• 保留 summary_prompt 作为"整段覆盖"的逃生口（已有），面向极少数确实需要重写契约的高级用户。
• 新增更轻量的 per-agent summary_focus（或 summary_instructions）字段，文本注入 BASE promp/focus> 块）。90% 的 agent 用默认；进阶用户加一行 focus；极少数才用整段 summary_prompt。

一句话总结

▎ 需要做 per-agent，但只暴露 enabled/trigger/keep/model_name 这几个"行为旋钮"（覆盖式回退 性化 summary_focus 而非整段替换，以保住 {messages} 占位符与预算/语义契约。实现上扩展AgentConfig（当前会丢未知字段）并在 _create_summarization_middleware 处合并配置即可，与现有 model/tool_groups/skills 的 per-agent 覆盖模式一致。