一键导入
scheduler-design
Consolidation 触发机制:自动触发通过 Factory 配置内联,手动触发通过 StelloAgent API;全局 reflection 由应用层在 SDK 之上自行实现。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Consolidation 触发机制:自动触发通过 Factory 配置内联,手动触发通过 StelloAgent API;全局 reflection 由应用层在 SDK 之上自行实现。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
StelloAgent 创建配置教程。完整说明 createStelloAgent 的每个配置项,包含 sessionDefaults、storage、tools、skills、forkProfiles、session 层接入、orchestration 等。
Engine 职责定义:per-session-round 生命周期管理器。驱动 tool call 循环,管理单个 Session 的多轮对话。不感知树结构,不感知调度。
Fork 机制完整说明。覆盖 ForkProfile 与 EngineForkOptions 的字段对齐、四层 fallback 合成链(sessionDefaults → parent → profile → forkOptions)、systemPrompt 合成三种模式、skills 三态语义、持久化边界(SerializableSessionConfig 只固化 systemPrompt/skills)。任何涉及 fork / profile / stello_create_session / 配置合成 的工作都应读这个。
Stello 框架内所有 LLM 调用位置的消息结构速查。覆盖 Session 对话、compress、consolidate;应用层 reflection 调用由 orchestrator 自行决定。
Server 层设计:传输层架构决策、StelloAgent 映射原则、连接态管理模式。存储层见 server-storage,Engine 细节见 engine-design。
@stello-ai/server 的 PG 持久化层设计决策和实现模式。触发条件:修改或引用 server 存储层。
| name | scheduler-design |
| description | Consolidation 触发机制:自动触发通过 Factory 配置内联,手动触发通过 StelloAgent API;全局 reflection 由应用层在 SDK 之上自行实现。 |
Consolidation 的触发机制有两条路径:
consolidateEveryNTurns 配置项,由 Factory 内联处理agent.consolidateSession(sessionId)跨 Session 的 reflection 由应用层在 agent.listSessionDigests / agent.putInsight 之上自行实现,详见 skill session-usage。
在 orchestration 配置中设置 consolidateEveryNTurns,每 N 轮对话后自动触发 consolidation(fire-and-forget):
orchestration: {
consolidateEveryNTurns: 5,
}
这是框架提供的唯一自动触发策略。逻辑内联在 Factory 的 hook 中,无独立调度器组件。
await agent.consolidateSession(sessionId)
应用层可在任意时机调用,例如 session 结束时、定时任务、用户操作后。
async function reflect() {
const digests = await agent.listSessionDigests({ status: 'active' })
// 调任意 LLM、用任意 schema 解析 ...
for (const [id, content] of Object.entries(insightsByTarget)) {
await agent.putInsight(id, content)
}
}
可在 hooks.onRoundEnd / hooks.onSessionFork 内 fire-and-forget 触发,或绑定到外部 cron / 用户操作。框架不假设调用频率与策略——这部分被有意外推到应用层。
调度被有意压到最小:
listSessionDigests / putInsight 之上自行实现,框架不持有跨 Session 状态