← 返回全部项目

Agent Runtime · 个人全栈项目

Lodestar · OpenClaw / Hermes Agent Runtime

从聊天界面升级为能安全执行文件、命令、浏览器和长任务的本地工作伙伴

GitHub · RuntimeGitHub · Protocol
个人项目持续开发研发型 AI 产品经理TauriTypeScriptRustPythonMCPWebSocket
01支持 200K Token 上下文
02沉淀 15+ 可复用技能
03审批、回放与恢复闭环

Runtime flow / 运行时链路

从任务进入，到中断后恢复

用任务分车道、上下文与记忆、工具审批和持久化投递建立本地 Agent 的执行边界。
  1. 01

    任务分车道

    根据隔离、并行与当前上下文需求选择 Fresh、Fork 或 In-Process 执行。

  2. 02

    上下文与记忆

    组装任务上下文，按层压缩并读写短期、长期和项目记忆，控制污染与成本。

  3. 03

    审批与执行

    文件、命令、浏览器和 MCP 工具经过沙箱、权限检查与逐级审批后执行。

  4. 04

    回放与恢复

    通过 Checkpoint、订阅、幂等投递和重放恢复长任务进度与结果所有权。

边界说明这是个人项目的产品与实现架构；模型、框架及部分工具来自开源生态，公开仓库用于验证 Runtime 与 Protocol 边界。

背景与问题

多数 AI 助手停留在聊天层面：上下文变长后遗忘、复杂任务容易跑偏、执行操作缺少安全边界，任务中断后也无法可靠恢复。

我的角色

以研发型 AI 产品经理与个人核心实践者身份，主导用户场景、任务模型、上下文策略、记忆分层、权限边界、安全机制、恢复体验与桌面端核心实现；底层框架、模型和部分工具能力来自开源生态，不归为个人原创成果，也不把个人项目成果归入时空城产品。

约束与取舍

  • 单一长上下文还是任务分车道：把全部信息放入一个上下文实现简单，但成本、污染和失败恢复问题会随任务变长放大。最终选择 Fresh / Fork / In-Process 三种车道，承担更复杂的状态管理以换取隔离和可恢复性。
  • 工具默认放行还是逐级审批：默认放行体验更快，却不适合文件、命令和浏览器执行。最终采用沙箱与命令审批，牺牲部分首次操作效率以换取可审计边界。
  • 内存态推送还是持久化投递：只靠实时连接实现简单，但进程或网络中断会丢失长任务进度。最终增加订阅、重放和恢复机制，接受额外的幂等与所有权设计成本。

产品方案

设计主 Agent 与 Fresh / Fork / In-Process 三车道 SubAgent；通过写集冲突检测支持并行调度，建立四级上下文压缩与五层记忆。使用工具沙箱、命令审批、AES-GCM 与注入防护约束执行边界，并提供 Gateway 的订阅、重放和投递恢复机制。

结果与证据

  • 支持 200K Token 上下文配置与 15+ 可复用技能。
  • 形成工具审批、执行回放、进度订阅和中断恢复的完整产品边界。
  • 交付 Tauri 2 桌面端与 Python/Rust 类型化控制核心，公开 Runtime 与 Protocol 仓库作为实现证据。

局限与下一步

当前可靠性验证主要来自个人测试和开发样例，尚未形成可公开复现的大规模任务集，因此不展示准确率、完成率或可用性百分比。下一步将增加固定任务集、失败注入和恢复耗时测试，同时继续降低首次权限配置成本。