Kun 会话轨迹紧凑存储:始终在线的请求生命周期元数据与内容寻址提示清单设计

发布时间:2026/10/10 5:21:31
Kun 会话轨迹紧凑存储:始终在线的请求生命周期元数据与内容寻址提示清单设计 人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载Kun 是一款 Local-first 的 AI Agent 工作区其模型请求诊断此前局限于右侧检查器并以原始请求/响应载荷独立持久化导致长会话存储膨胀且难以理解。本文基于 Kun 仓库中add-conversation-trajectory-view变更包的紧凑轨迹存储规范完整讲解其“始终在线的请求生命周期元数据 可选的、内容寻址的提示清单”存储模型并结合 紧凑轨迹存储规范、方案提案、设计文档 与对应源码实现说明 Kun 如何在低存储成本下持久化每一次模型调用的身份、时序、用量与失败信息并在重启、预算回收、遗留数据兼容等场景下保持可靠性与可查询性。读完本文你将掌握该存储模型的九大需求约束、核心数据结构轨迹记录、提示清单、内容寻址 Blob、预算与恢复策略以及对应查询 API 的契约与底层实现。背景为什么模型请求诊断需要“紧凑”存储Kun 此前通过LlmDebugRecorder记录精确的模型传输过程并把完成的记录按线程写入 JSONL 文件渲染在 workbench 的 Agent Perspective 右面板中。会话正文assistant 文本/推理、工具调用与结果、压缩条目、用量事件、附件已经存在于 Session store 中并通过线程时间线与 SSE 路径到达。问题在于把完整请求历史与原始响应再次写入 trace JSONL对长会话而言存储扩展性差见 设计文档。因此该变更包的目标是让每一次对话都有紧凑的请求生命周期元数据无论是否开启完整内容捕获用稳定 ID 关联 Provider 尝试、逻辑模型步骤、Session 条目与工具生命周期通过提示清单与去重压缩 Blob 重建可选的精确提示细节而不复制响应/工具/附件正文暴露有界的轨迹分页、摘要与详情 API并提供以文件系统为权威的回退将右面板的 Agent Perspective 入口迁移为居中会话视图同时保留其语义解析与详情能力。非目标包括持久化 token/chunk 级增量、原始 HTTP 交换、附件字节或完整工具输出提示 diff、轨迹导出、时间轴缩放、请求对比以及把 SQLite 变成权威存储。核心架构把“生命周期元数据”与“内容捕获”解耦设计文档明确了两条分离的持久化路径紧凑生命周期保留Always-on模型观察器总是为每个逻辑 round 创建记录并为每次实际传输尝试创建一条记录。记录获得稳定的roundId、requestId、turnId、step、attempt值并在开始、首个内容、终态三个时刻写入检查点。可选内容保留线程现有的捕获开关只控制提示清单/Blob 的创建与有界的内存线诊断绝不抑制元数据。源码中LlmDebugRecorder在每次beginAttempt时即创建ModelRequestTraceRecord其captureMode字段区分full与metadata当捕获关闭时请求体与响应头被emptyHeaders()/emptyBody()占位见 llm-debug-recorder-recorder.ts 与 llm-debug-recorder-trajectory.ts。这取代了原先“要么全捕获要么什么都不存”的记录器策略在保留时序/错误/用量信息的同时让敏感提示的捕获保持显式可控。需求一始终在线的紧凑请求生命周期规范第一条要求对每个逻辑模型 round 与每次实际 Provider 尝试无论是否捕获完整内容Kun 都必须持久化紧凑生命周期元数据。对应场景捕获关闭的请求线程禁用完整内容捕获并发送模型请求时Kun 仍持久化稳定的 round/request/turn/step/attempt 身份、provider/model/purpose、状态、时序、用量、错误与条目关系只是不含提示与原始响应正文。Provider 重试一个逻辑模型步骤执行多次 Provider 尝试时每次尝试拥有唯一 request ID 与尝试序号同时共享逻辑 round 与 step 身份。源码侧LlmDebugRecorder.beginAttempt生成的记录包含roundId、step、purpose、captureMode、attempt、attemptReason、transport、endpointFormat、provider、model等字段finish阶段对所有pending记录依据响应捕获错误、输出错误、stopReason 依次归一为capture_error/failed/completed/cancelled并逐条调用persistentMetadataRecord写入持久层。persistentMetadataRecord专门把 request/response/decoded 中的正文与头全部清空只保留方法、URL含脱敏标记、状态码与错误信息——这正是“紧凑”二字在实现层面的直接体现。需求二有界生命周期写入与重启恢复Kun 只持久化生命周期开始、首个内容、终态以及每两秒至多一次轻量进度检查点绝不把普通流增量写成轨迹记录。源码中captureChunk在收到首个内容块isFirstContentChunk覆盖文本、推理、工具调用、图像生成完成等时写入firstTokenAt检查点此后每次捕获块时判断now - state.lastCheckpointAt 2_000才再次持久化见 llm-debug-recorder-recorder.ts。规范中“Runtime exits mid-request”场景要求重启后若存在从未到达终态的记录则该请求被暴露为interrupted且超过 24 小时的检查点被移除。实现上interruptedRecord()会为这类记录补写interrupted状态、finishedAt、durationMs与默认错误文案查询侧listThread会把持久化中pending且不在活跃集合内的记录自动投影为interruptedRecord。需求三规范会话引用——以 Session 条目为响应与工具的唯一真源轨迹元数据引用规范的 user、assistant、reasoning、tool、compaction、attachment 记录而不是复制其完整内容。工具调用与结果共享 call ID 时轨迹投影只暴露一条工具生命周期记录包含条目引用、开始/结束时序、状态与有界预览。在 trajectory-query-service.ts 的projectItems中可以看到具体实现tool_call条目通过resultByCall以callId为键关联对应的tool_result生成kind: tool的记录只保存argumentsItemId、resultItemId、argumentPreview2 KiB 内、resultPreview、isError与attachmentIdsassistant_text/assistant_reasoning被聚合为assistant记录并携带itemIds数组user_message、model_context、runtime_context_source、compaction分别投影为user/context/compacted等记录。设计文档明确指出把响应与工具正文复制进轨迹存储的方案被拒绝因为它会在长会话中重复最大体积的数据并造成删除/压缩行为不一致。需求四内容寻址提示清单Prompt Manifest当开启完整内容捕获时Kun 会为每个请求创建一个提示清单包含有序的条目/消息引用、Session 边界、附件元数据以及 System Prompt、工具 schema、请求配置、回退片段经过脱敏后的SHA-256 Blob 引用。关键场景重复提示组件多个请求使用相同的 System Prompt 或工具 schema 字节时它们共享一个不可变的 Brotli 压缩 Blob而不是重复存储内容。超大内容单个脱敏 Blob 超过 8 MiB 时Kun 存储有界的头/尾表示附带原始大小、内容哈希与显式截断状态。实现位于 trajectory-content-store.tscaptureRequest先对正文做脱敏redactModelTraceValuesredactBrowserUseDebugContent再由promptParts把请求拆分为system、tools、config、message四类片段每个片段经putBlob计算 SHA-256createHash(sha256)以blobId.br为文件名按wx模式写入文件已存在即视为去重命中用 Node 内置brotliCompress质量参数 5压缩。超限内容保留头 512 KiB 与尾 64 KiB中间插入显式截断标记TRAJECTORY_BLOB_HEAD_BYTES/TRAJECTORY_BLOB_TAIL_BYTES/TRAJECTORY_MAX_BLOB_BYTES均在源码顶部定义。清单本身trajectory.ts 的PromptManifestSchema记录blobs数组、messageItemIds、attachmentIds、retainedBytesBlob 引用含blobId、kind、codec: br、rawSize、compressedSize、truncated。选择 Node Brotli 而非引入 Zstd 原生依赖是为了让打包版 Kun 与独立 TUI 共用同一内置编解码器清单记录 codec 以支持未来扩展。查询投影时projectRequests若清单存在则从system/tools/config三类非 message Blob 拼接出promptFingerprint据此生成“Initial System Prompt / System Prompt Updated”系统记录实现提示变更的可视化optionsAvailable、systemBlobId、toolsBlobId、configBlobId等字段也随之填充。需求五敏感与二进制内容排除轨迹持久化在哈希或写入之前移除凭据且不得保留原始 HTTP 头/帧、授权值、cookies、附件正文、图片/Base64 载荷或完整工具输出。场景当配置的凭据出现在 URL、头、请求选项或回退片段中时元数据日志、清单、Blob、索引、DTO 与警告日志中都不能出现该凭据值。源码中实现了多层防线URL 脱敏sanitizeModelTraceUrl在写入记录前同步执行头脱敏sanitizeModelTraceHeaders移除/标记含敏感值的头名持久化记录中headers一律为空值脱敏redactModelTraceValues在捕获正文前替换secretValues浏览器动作脱敏redactBrowserUseDebugContent/redactBrowserUseActionForPersistence专门处理browser_use工具清单侧sanitizePromptValue对authorization、api_key、access_token、refresh_token、password、cookie、secret、private_key、credential等键名正则sensitiveKey直接替换为[REDACTED]对data:...;base64,前缀或疑似大 Base64 字符串替换为[BINARY OMITTED]。需求六明细保留预算Retention BudgetsKun 将保留的详细内容上限设为每线程 64 MiB、全局 512 MiB内联预览 16 KiB、搜索预览 2 KiB当明细被回收时生命周期元数据必须保留。场景添加内容将超过全局预算时逐出最近最少使用的非活跃明细元数据保持可查询受影响记录报告evicted明细状态。对应常量在 trajectory-content-store.ts 顶部TRAJECTORY_MAX_THREAD_DETAIL_BYTES 64 * 1024 * 1024、TRAJECTORY_MAX_TOTAL_DETAIL_BYTES 512 * 1024 * 1024、TRAJECTORY_INLINE_PREVIEW_BYTES 16 * 1024、TRAJECTORY_SEARCH_PREVIEW_BYTES 2 * 1024。实现上enforceThreadBudget按清单createdAt从旧到新删除清单文件直至低于线程预算enforceGlobalBudget类似地在全局层面回收回收后统一执行collectUnreferencedBlobs做标记-清除mark-and-sweep式的 Blob 垃圾回收。设计文档特别强调Blob GC 以权威清单为参照而不是信任崩溃后可能失真的可变引用计数。被删除清单对应的记录在查询时以evicted明细状态呈现而时序、用量、错误与 Session 引用仍完整可查。需求七权威文件系统与可重建索引轨迹日志、清单与 Blob 是权威的文件系统数据任何 SQLite 轨迹索引都必须是可重建的查询 API 在无索引时通过有界文件系统回退继续工作。场景混合 SQLite 绑定或轨迹表不可用时轨迹分页、摘要、过滤与有界搜索继续基于紧凑文件系统数据运行并给出降级警告。当前仓库实现中ModelRequestTraceStore承担按线程的 JSONL 持久化与分页游标读取TrajectoryContentStore负责清单与 Blob 文件二者共同构成权威文件系统层TrajectoryQueryService直接通过recorder.listThread内部走ModelRequestTraceStore与sessions.loadItems读取数据投影轨迹记录不依赖任何索引表。设计文档把“索引可重建 文件系统回退”列为显式决策并将 SQLite 原生绑定失败列为风险项要求在实现与测试中验证扫描回退路径。需求八轨迹查询 API 契约Kun 暴露带认证、线程隔离的轨迹分页、摘要与分段详情路由使用版本化 DTO、不透明游标并安全处理未知或缺失数据。场景客户端请求的详情 ID 不属于路由线程时Kun 返回 not found 且不泄露该记录。路由实现位于 trajectory.tsGET /v1/threads/{id}/trajectory解析limit默认 100最大 200、cursor不透明游标、filterall/llm/tool/error、q查询串最长 512 字符摘要路由返回TrajectorySummary包含 requestCount、toolCount、runningCount、failedCount、输入/输出/推理 token、缓存命中率、平均首 token 延迟、平均 token/秒、总时长、成本USD/CNY与价值估算等聚合指标详情路由按section参数overview/input/output/usage/timing/raw/arguments/result/system-prompt/tools/diff/options/rendered/source/schema解析指定分段。所有 DTO 由 contracts/trajectory.ts 中的 Zod schemaTrajectoryPageSchema、TrajectorySummarySchema、TrajectoryDetailSchema等版本化校验。分页游标编码为{ v: 1, startedAt, id }的 base64url 形式按“时间倒序 ID 字典序”确定下一页边界过滤器语义为llm请求assistant、tool、errorfailed/cancelled/interrupted。serviceFor先校验线程存在并检查轨迹记录器可用性线程归属校验在TrajectoryQueryService.detail中通过在线程记录集合内查找实现——找不到即返回notFound实现“不泄露跨线程记录”的要求。需求九遗留兼容与删除语义Kun无破坏性迁移地读取遗留的 schema-v1 模型请求 trace并在线程删除时移除该线程的轨迹元数据、清单、遗留 trace 与无引用 Blob。场景会话只有 schema-v1 trace 记录时轨迹 API 投影出可恢复的遗留元数据并把新字段标记为不可用而不会让会话失败。实现层面ModelRequestTraceStore兼容读取既有 schema-v1 文件projectRequests中当记录无manifestId且captureMode非 metadata、请求体仍有原始字节时detailState判定为legacy其余无捕获的为not_capturedtrajectoryStatus将transport_error、capture_error、failed、not_started统一归并为failed。删除路径上LlmDebugRecorder.deleteThread同步清理活跃 round、内存记录并并行调用ModelRequestTraceStore.deleteThread与TrajectoryContentStore.deleteThread后者递归删除线程清单目录后执行collectUnreferencedBlobs回收不再被任何清单引用的.br文件。设计文档的迁移计划六步与此一致先引入新契约与兼容读取器 → 开始写紧凑记录与可选清单遗留文件不动→ 添加查询 API 与渲染端客户端并切换入口 → 停止持久化原始载荷追加保留有界实时诊断→ 线程删除时清理新旧产物并尽力回收 Blob → 因 Session 数据未变、遗留设置与记录仍可解析回滚始终可行。从存储到视图轨迹数据如何驱动 UI紧凑存储之上是 会话轨迹视图规范标题栏提供chat | trajectory居中视图切换切换时保持 composer 与聊天组件挂载不改变活动线程、草稿、模型、权限模式与聊天滚动位置。轨迹视图把请求元数据与 Session 条目投影为稳定的 Turn/Step 分组按时间顺序渲染并支持向后分页十万条记录时仅挂载可见 overscan 窗口使用tanstack/react-virtual处理变高行。三车道时间线输入/模型/工具、all/llm/tool/error过滤、有界搜索、折叠控制、实时/等宽显示模式与全会话摘要指标均由查询 API 的filter/q/summary支撑记录检查器区分 unavailable、truncated、evicted、failed、cancelled、interrupted 六种明细状态并在捕获关闭时明确提示“内容未捕获”。每线程的过滤、查询、选择、折叠、滚动、检查器宽度与时间线模式状态被隔离由有界 Zustand store 承载仅在账本位于实时边缘时自动跟随新记录离开实时边缘则保持滚动位置并提供返回实时边缘的新记录计数。原先的 Agent Perspective 右面板贡献被移除持久化的遗留布局标识归一化为无面板确保旧布局恢复时不会出现重复检查器。总结一份“元数据权威、内容可选、索引可弃”的轨迹存储设计综合规范、设计与源码Kun 的紧凑轨迹存储形成了如下闭环始终在线的生命周期元数据保证每次请求尝试都可追溯规范 Session 引用避免复制会话正文这一最大数据源内容寻址的提示清单 Brotli 去重 Blob让精确提示重建按需且去重多层脱敏与二进制排除守住凭据与隐私边界线程 64 MiB / 全局 512 MiB 预算与 mark-and-sweep GC约束存储增长且永不驱逐元数据文件系统权威 可重建索引 有界回退保证可靠性版本化 DTO 与不透明游标保证查询契约稳定遗留 schema-v1 兼容与线程删除清理保证平滑迁移。若要继续深入可依次阅读 紧凑轨迹存储规范、设计文档、轨迹契约、内容存储实现、查询服务实现 以及对应的 路由实现 与测试用例如 trajectory.test.ts、trajectory-content-store.test.ts、trajectory-query-service.test.ts。赞分享人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载相关推荐douyin-downloader一条链接跑通抖音批量下载的 Python 工具douyin downloader一条链接跑通抖音批量下载的 Python 工具 假设你要存档某位创作者的全部作品手动打开主页一条条等视频加载、点保存拿人工智能AI Agent自主智能体桌面应用MCP ClientsWin11Debloat 免费精简 Windows 11一次跑通的系统去臃肿完整教程Win11Debloat 免费精简 Windows 11一次跑通的系统去臃肿完整教程 开机少等十几秒、右键菜单秒开、后台不再往外卖数据——这些都能靠免费开源的人工智能AI Agent自主智能体桌面应用MCP ClientsUnicity Astrid OS 发行版分发机制Distro 清单、内容寻址存储与 Capsule 全生命周期管理Unicity Astrid OS 发行版分发机制Distro 清单、内容寻址存储与 Capsule 全生命周期管理 本篇以 Astrid 官方参考书《Dis文档教程上一篇窗口放大工具终极对决Magpie凭什么成为Windows首选下一篇obfuscator插件开发指南如何为你的二进制混淆工具扩展自定义变换创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询