goose 日志与数据存储体系完全指南：会话记录、命令历史与系统日志的本地管理

goose 日志与数据存储体系完全指南会话记录、命令历史与系统日志的本地管理【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goosegoose 将 CLI 与桌面端的每一次对话、交互与组件运行日志统一存储在本机形成命令历史 会话记录 系统日志三套互补的数据体系。本文以 logging system 文档 为核心结合 路径解析源码、日志子系统实现 与 会话存储实现完整说明这些数据的存放位置、文件组织方式、保留策略与底层原理帮助你在排查问题、审计会话和备份数据时精准定位。统一存储所有交互数据都保存在本地goose 使用一套统一的本地存储体系承载会话与交互数据。无论你通过 CLI 还是桌面应用使用 goose会话与交互记录都会被持久化到本机固定目录中且遵循平台惯例通过etcetera的AppStrategy解析应用名goose、厂商Block具体位置如下表所示类型类 UnixmacOS / LinuxWindowsCommand History命令历史~/.config/goose/history.txt%APPDATA%\Block\goose\data\history.txtSession Records会话记录~/.local/share/goose/sessions/sessions.db%APPDATA%\Block\goose\data\sessions\sessions.dbSystem Logs系统日志~/.local/state/goose/logs/%APPDATA%\Block\goose\data\logs\从源码看这三类路径分别对应Paths::config_dir()、Paths::data_dir()与Paths::state_dir()三个解析入口见 paths.rs。在 Windows 上etcetera的state_dir()不可用时实现会回退到data_dir()paths.rs因此 Windows 下日志被统一收纳到%APPDATA%\Block\goose\data\logs\。隐私说明goose 是本地应用上述所有数据默认只保存在你的机器上不会发送到任何外部服务器或第三方日志数据始终在你的掌控之中。需要注意goose 在你授权下调用的 LLM 与工具服务可能有它们自己的日志与隐私策略两者互不混淆。路径的底层解析与自定义路径解析核心位于 crates/goose/src/config/paths.rs。其中类 Unix 目录~/.config/goose、~/.local/share/goose、~/.local/state/goose分别由config_dir/data_dir/state_dir提供厂商名兼容源码注释明确指出Block是刻意保留的兼容字符串用于兼容历史版本已经创建的配置/数据目录例如~/Library/Application Support/Block/goose/避免升级后旧数据失联paths.rs自定义根目录若设置了绝对路径环境变量GOOSE_PATH_ROOT则配置、数据、状态目录分别变为GOOSE_PATH_ROOT/config、GOOSE_PATH_ROOT/data、GOOSE_PATH_ROOT/statepaths.rs这为在 CI、沙箱或便携场景中把整个 goose 数据目录收拢到一处提供了便利。Command History跨会话的命令记忆goose 会持久化命令历史从而在多次聊天会话之间记住你之前敲过哪些命令。命令历史文件的默认位置为类 Unix~/.config/goose/history.txtWindows%APPDATA%\Block\goose\data\history.txt它由 CLI 的输入层维护位于配置目录中与会话内容解耦——命令历史侧重记录交互输入本身而真正的对话内容则交给下面的 Session Records。Session RecordsSQLite 数据库中的完整会话档案存储位置与数据内容goose 为每个会话维护完整的对话历史与交互记录统一存放在一个 SQLite 数据库文件中类 Unix~/.local/share/goose/sessions/sessions.dbWindows%APPDATA%\Block\goose\data\sessions\sessions.db该数据库包含了所有已保存的会话数据从源码建表语句session_manager.rs可以精确对应文档描述的内容会话元数据id、name、working_dir、created_at/updated_at、session_type、project_id、parent_session_id、archived_at、goose_mode等对话消息messages表按会话保存每条用户命令、助手响应、角色role与序列化内容content_json并建立session_id、timestamp、message_id索引以支持高效查询工具调用与结果消息内容中以结构化形式记录工具调用的 ID、参数与执行结果状态Token 用量统计usage_ledger表按会话逐条记录model、input_tokens、output_tokens、total_tokens、cache_read_tokens/cache_write_tokens、cost以及是否为压缩产生的记录is_compaction扩展数据与配置sessions表通过extension_data、recipe_json、provider_name、model_config_json等字段保存扩展与应用配置。数据库连接使用 WAL 日志模式SqliteJournalMode::Wal、开启外键约束并设置 30 秒忙等待超时session_manager.rs兼顾并发读写安全与一致性。会话 ID 命名与查询会话 ID 采用YYYYMMDD_COUNT格式例如20250310_2。每次启动会话时goose CLI 会在开头输出本次的会话 ID方便你在多个并行会话中快速对应。要列出所有可用会话使用goose session list子命令goose-cli-commands.md。它支持以下选项选项说明示例-f, --format text\|json指定输出格式默认textgoose session list --format json--ascending按时间正序旧在前排列goose session list --ascending-w, --working_dir path按工作目录过滤会话goose session list -w ~/projects/myapp-l, --limit number只显示最近 N 个会话goose session list --limit 10如需在会话内或会话间做文本检索可以参考 会话管理指南。从 .jsonl 到 SQLitev1.10.0 的自动迁移在v1.10.0 之前goose 将会话记录以单个.jsonl文件形式存放在~/.local/share/goose/sessions/。升级到 v1.10.0 及以后版本后goose 首次打开数据库时会检测schema_version表是否存在session_manager.rs若数据库为空则创建新 schema并自动调用import_legacy把旧.jsonl会话批量导入数据库旧.jsonl文件仍保留在磁盘上但不再由 goose 管理可视为只读归档。即使导入失败goose 也只会打印Failed to import some legacy sessions警告而不会阻塞启动session_manager.rs。后续版本升级则通过带版本的 schema 迁移脚本平滑演进。System Logs组件日志与两周自动清理goose 为 CLI、服务器goosed守护进程等组件分别记录日志。所有系统日志统一收敛到类 Unix~/.local/state/goose/logs/Windows%APPDATA%\Block\goose\data\logs\其目录结构在设计上有两个关键约定logging.rs按组件分子目录、按日期再细分形如logs/cli/2025-11-13/、logs/server/2025-11-13/日期格式为%Y-%m-%d两周自动清理每次创建日志目录前会调用cleanup_old_logs(component)删除该组件目录下修改时间超过 14 天的子目录logging.rs防止日志无限累积挤占磁盘。当日志启用 提示注入检测 时CLI 与服务器日志还会额外记录安全发现携带唯一 ID格式为SEC-{uuid}用户决策与发现 ID 关联的允许allow/ 拒绝deny操作。此外扩展Extension可以自行选择在~/.local/state/goose/logs/下的子目录中记日志具体子目录结构由各扩展的实现决定。Desktop Application Log桌面应用对自身运行过程维护一套独立日志遵循平台惯例macOS~/Library/Application Support/Goose/logs/main.logWindows%APPDATA%\Block\goose\logs\main.log需要注意的是桌面应用只把自身操作日志与状态数据放在上述平台目录真正的会话与对话内容依然写入标准的sessions.db即上文 Session Records。这意味着无论你通过 CLI 还是桌面应用与 goose 交互对话历史都是一致的、可无缝衔接的。CLI LogsCLI 日志存放于类 Unix~/.local/state/goose/logs/cli/Windows%APPDATA%\Block\goose\data\logs\cli\日志按日期分子目录如cli/2025-11-13/超过两周的子目录会被自动删除。CLI 会话日志中记录工具调用与返回结果命令执行细节会话标识符时间戳。CLI 日志同样捕获扩展相关活动包括工具初始化、工具能力与 schema、扩展专属操作、命令执行结果、错误信息与调试信息、扩展配置状态以及扩展相关的协议信息。从日志实现看每个运行单元的日志文件名形如时间戳.log若配置了会话名则为时间戳-名称.log文件内容默认包含日志级别、target、源码文件与行号写入格式可切换为 JSON 或纯文本logging.rs。日志级别通过EnvFilter控制若设置了RUST_LOG环境变量则直接采用否则使用内置默认mcp_clientinfo、gooseinfo全局WARN兜底再叠加各组件附加指令logging.rs。Server Logs服务器日志存放于类 Unix~/.local/state/goose/logs/server/Windows%APPDATA%\Block\goose\data\logs\server\同样按日期分子目录如server/2025-11-13/并执行两周自动清理。Server 日志记录的是 goose 守护进程goosed的运行情况——该进程是运行在你机器上的本地服务组件负责在 CLI、扩展与 LLM 之间进行通信调度。Server 日志通常包含以下内容服务器初始化细节、JSON-RPC 通信日志、服务器能力、协议版本信息、客户端与服务器交互、扩展加载与初始化、工具定义与 schema、扩展指令与能力、调试级传输信息、系统能力与配置、操作系统信息、工作目录信息、传输层通信细节、消息解析与处理信息、请求/响应周期、错误状态与处理以及扩展初始化序列。如何快速定位 CLI / Server 日志排查问题时可以按日期找到最新目录并查看其中的.log文件。类 Unix 环境下可参考# 查看最近一天 CLI 日志目录 ls -lt ~/.local/state/goose/logs/cli/ | head # 实时跟踪最新 CLI 日志文件 tail -f ~/.local/state/goose/logs/cli/$(date %Y-%m-%d)/*.log # 查看 server 侧今天的日志 tail -n 200 ~/.local/state/goose/logs/server/$(date %Y-%m-%d)/*.logLLM Request Logs模型请求的原始往返记录当 goose 与语言模型服务商通信时会记录发送给 provider 的原始请求与响应数据用于诊断模型行为与 token 消耗类 Unix~/.local/state/goose/logs/llm_request.*.jsonlWindows%APPDATA%\Block\goose\data\logs\llm_request.*.jsonl编号轮换机制LLM 请求日志采用**编号轮换numbered rotation**机制最多保留最近 10 次完整请求对应文件llm_request.0.jsonl到llm_request.9.jsonl。底层实现在 providers/utils.rsLOGS_TO_KEEP 10是保留数量的常量utils.rs每个请求开始时会先写入一个临时文件llm_request.{uuid}.jsonlUuid::new_v4()生成请求 ID见 utils.rs请求完成finish时把已有文件依次后移llm_request.0 → 1 → 2 …然后把临时文件改名为llm_request.0.jsonlutils.rs。因此编号越小越新llm_request.0.jsonl总是最近一次完成的请求若将logs_to_keep配置为 0则直接删除临时文件、不保留请求日志。每个日志文件都包含模型配置、输入负载、响应数据与 token 用量信息与usage_ledger表中的统计形成可对照的原始证据链。会话诊断相关代码也会引用llm_request.0.jsonl见 session/diagnostics.rs把最近一次模型请求纳入诊断信息收集。如果你要检查某次请求的原始负载用文本查看最近的编号文件即可# 查看最近一次完整 LLM 请求 head -c 2000 ~/.local/state/goose/logs/llm_request.0.jsonl从源码理解日志层tracing 与可观测性CLI / Server 日志统一由共享的 tracing 订阅器build_logging_subscriber构建logging.rs。它把日志分三条路径输出文件层写入按日期组织的组件目录可选 JSON 或纯文本格式纯文本包含源码文件信息便于回溯代码位置控制台层按配置输出到 stderr使用 pretty 格式并附行号便于开发调试时实时观察可选的可观测性层在启用otelfeature 时会挂接 OTLP 相关 layer同时可能接入 langfuse 观察层若配置存在则注册到日志体系。也就是说你看到的cli/2025-11-13/目录、两周清理策略以及按会话/进程命名的时间戳日志文件全部由这一套统一的prepare_log_directorycleanup_old_logs机制产出而 LLM 请求日志则走独立的RequestLog编号轮换通道。两者都落在~/.local/state/goose/logs/下构成完整的本地可观测性栈。实用排查速查表下面把三套数据的关键信息汇总成一张速查表方便日常运维与排障时对照数据类 Unix 路径Windows 路径保留策略命令历史~/.config/goose/history.txt%APPDATA%\Block\goose\data\history.txt持续累积会话数据库~/.local/share/goose/sessions/sessions.db%APPDATA%\Block\goose\data\sessions\sessions.db持续累积含版本化迁移CLI 日志~/.local/state/goose/logs/cli/%APPDATA%\Block\goose\data\logs\cli\按日期分目录超过两周自动删除Server 日志~/.local/state/goose/logs/server/%APPDATA%\Block\goose\data\logs\server\按日期分目录超过两周自动删除LLM 请求日志~/.local/state/goose/logs/llm_request.{0..9}.jsonl%APPDATA%\Block\goose\data\logs\llm_request.{0..9}.jsonl轮换保留最近 10 次请求桌面应用日志~/Library/Application Support/Goose/logs/main.log%APPDATA%\Block\goose\logs\main.log遵循平台约定几个补充事实值得记住会话数据库使用 SQLite 的WAL 模式运行期间可能出现sessions.db-wal/sessions.db-shm伴随文件属正常现象若需在测试或隔离环境中验证日志行为可通过绝对路径环境变量GOOSE_PATH_ROOT重定向 config / data / state 三类根目录见 paths.rs从而在不污染真实用户目录的前提下做实验会话列表、删除与检索能力由goose session子命令族提供具体选项可继续查阅 goose-cli-commands.md 中的 session 相关章节以及在 会话管理指南 中了解基于内容的检索方式。小结goose 的日志与存储体系遵循对话归数据目录、日志归状态目录、历史归配置目录的清晰职责划分并通过 SQLite 统一收敛会话内容、通过基于日期的目录与两周清理策略控制系统日志体积、通过llm_request.*.jsonl编号轮换保留最近 10 次模型请求原始记录。理解这套布局后无论是排查一次失败的工具调用、审计某段对话、核对 token 消耗还是做数据备份迁移你都能在数秒内定位到对应的本地文件让 goose 的运行状态对你完全透明。【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考