Skip to content

[Discussion] Design Concerns about Context Compression (s06) and Task System (s07) / 关于s06 与 s07 一些异见与讨论,欢迎交流 #174

@CHRisXman

Description

@CHRisXman

关于 s06 上下文压缩 / On s06 Context Compression

micro_compact 的实现过于粗暴,对所有 tool_result 一视同仁地替换为占位符。这种粒度忽略了重要结果的保留需求,比如 subagent 返回的阶段性结论。建议引入重要性标记机制。
compact 工具缺少明确的触发提示,LLM 难以判断何时需要主动压缩。建议在系统层面提供 token 计数等元信息,让 agent 有状态感知。

The micro_compact approach is overly aggressive, treating all tool results equally. This granularity ignores the need to preserve important results, such as subagent conclusions. A priority/preservation mechanism would be more robust.
The compact tool lacks clear triggering cues, making it hard for LLMs to know when to compress. Suggest exposing metadata like token count at the system level for better situational awareness.


关于 s07 任务系统 / On s07 Task System

DAG 模式不符合 LLM 的认知特点。LLM 天然是线性思维,强行引入"与或非"逻辑判断会显著增加任务管理出错概率,且 DAG 一旦出错极难回滚。
多 agent 场景下,DAG 应该由编排系统维护,LLM 退化为执行单元。
Subagent 场景更不需要显式依赖管理,主 agent 只需等待结果即可。
这个设计更像传统工程思维,而非 agentic 范式。
建议回归扁平列表 + 隐式依赖的简单模式。
“少即是多”。

The DAG pattern doesn't align with LLM cognition. LLMs naturally think linearly; introducing AND/OR/NOT logic significantly increases error rates in task management, and DAG errors are hard to rollback.
In multi-agent scenarios, DAG should be managed by orchestration systems, with LLMs acting as execution units. Subagent flows need no explicit dependency management—just wait for results.
This design reflects traditional engineering thinking rather than an agentic paradigm. Suggest returning to flat lists with implicit dependencies for simplicity.
"Less is more".

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions