跳转到主要内容QitOS 最强的一条设计主张，也许同时也是最简单的一条：
一次 run 应该只有一个 execution kernel。
在 QitOS 里，这意味着：
AgentModule 定义策略Engine 负责执行- parsers、toolsets、critics、memory 与 tracing 都附着在这条主链路上
我们会刻意避免为了 planning、benchmarking 或领域工作流再额外引入一层隐藏 runtime。
为什么这很重要
一旦框架里出现多个隐式 runtime，通常会有三个后果：
- examples 和生产型 agents 变得不可比
- benchmark 逻辑和日常 agent 逻辑逐渐漂移
- traces 不再能讲清楚完整的执行故事
QitOS 就是在刻意避免这三件事。
如果 benchmark runner、Claude Code 风格 agent 和安全审计 agent 全都共享同一个内核，那么：
- traces 可以直接横向比较
- 调试方法可以复用
- prompt / parser 实验更容易解释
- 长时运行行为会保持可检查，而不会退化成框架胶水
专门化应该放在哪里
QitOS 并不反对 specialization，但它希望 specialization 落在正确的位置：
- state 设计
- prompt policy
- parser 与 protocol 选择
- tool composition
reduce() 语义
这也是为什么领域化安全审计 agent 仍然可以是一个“普通的 QitOS agent”。
这对用户意味着什么
如果你正在基于 QitOS 设计 agent，默认问题通常不该是：
我是不是要额外做一个 orchestrator？
而应该更常问：
我能不能在同一个 kernel 之上，通过 state、prompt、parser、tools、history 或 memory 表达这件事？
这种约束会让系统更易学、更易测，也更易复现。
继续阅读
