人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载导读gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain把个人/团队知识库变成了会自我维护的系统——而让自我维护真正运转起来的是一整套 20 项常驻定时任务编排。本篇以 docs/guides/cron-schedule.md 为核心骨架完整还原参考调度表、cron 落地命令、强制安静时段门控与跨时区处理并深入到gbrain dream夜间循环的三级裁剪级联triage cascade、oneshot 合成模式与排水池并发模型结合 triage-rescue.ts、synthesize.ts 等源码验证每一项配置旋钮的真实默认值与行为。读完你将能照抄出一套可上生产、可验证、不打扰用户的定时大脑维护方案。为什么要有一张调度表大脑的复利从定时开始原文档开篇就点明了这组任务的意义一个生产级大脑运行着 20 项周期任务让知识库保持鲜活、持续累积compounding。如果不做这件事大脑只会在你手动摄入数据时才更新——页面过期、实体信息单薄、引用断裂、Agent 基于旧上下文作答。而配好之后效果是闭环的邮件、社交媒体、日历、会议自动流入大脑单薄页面在夜间被自动充实断裂的引用被自动修复你醒来时大脑比入睡时更聪明。这正是 docs/guides/cron-schedule.md 想要传递的核心思想调度不是运维杂活而是大脑的存活机制。文章末尾的 Tricky Spots 第一条把它讲得很重dream cycle 不是可选的——没有它信号从每一次对话中泄漏出去有了它什么都不丢。这是一个会遗忘的 Agent 和一个会记住的 Agent 之间的区别。参考调度总表以下是原文档给出的生产环境参考调度表每个任务的 Brain Interaction 描述了它如何作用于大脑Recipe 列指向仓库中的配套食谱频率任务与大脑的交互食谱每 30 分钟邮件监控搜索发件人、更新人物页email-to-brain每 30 分钟X/Twitter 采集创建/更新媒体页、实体抽取x-to-brain工作日 3 次/天会议同步完整摄入 参会人传播meeting-sync每周日历同步每日文件 参会人丰富calendar-to-brain每日上午晨间简报检索日历参会人、交易状态、活跃线程briefing skill每周大脑维护gbrain doctor、embed stale、孤儿页检测maintain skill夜间Dream Cycle实体清扫、丰富薄弱点、修复引用见下文值得注意的原文档观点20 个任务听起来很多但别过度 cron详见 Tricky Spots 第 3 条。起步只需三件事邮件30 分钟、dream cycle夜间、大脑健康检查每周然后随集成食谱逐个增加。优先使用 gbrain 原生的调度面系统 cron 是最低公分母但 gbrain 自带多个调度面原文档明确要求能匹配就先用手边的gbrain dream—— 官方夜间维护循环lint、backlinks、extract、sync、embed、synthesize。直接调度它而不是下面手工搓 dream cycle 脚本。gbrain jobs/ minions—— 带重试、退避和审计轨迹的任务队列可提交 shell 任务或 LLM 子代理。详见 minion-orchestrator skill它区分确定性 shell 任务gbrain jobs submit shell ...与 LLM 子代理任务gbrain agent run ...并给出超过 ~2 分钟的操作必须走持久执行阶梯durable-execution ladder deadman 检查的路线约定。gbrain autopilot—— 常驻后台守护进程按自身节奏运行循环sync、extract、embed、backlinks、durible job 处理都在其中见 maintain skill 的 Autopilot check 小节。cron-schedulerskillskills/cron-scheduler/SKILL.md—— 教 Agent 管理其宿主的调度器契约包含调度错峰每 5 分钟槽位最多 1 个任务、无冲突、时区感知的安静时段门控带 user-awake 覆盖、薄任务提示读 skills/X/SKILL.md 并运行禁止内联 3000 字长提示、幂等性、结果落盘为报告reports/{job-name}/{YYYY-MM-DD-HHMM}.md。Bootstrap 会话触发的调度——gbrain bootstrap安装由 HEARTBEAT.md 驱动的、随会话活动触发的调度见 bootstrap.md。对于仅调度syncembed --stale这一具体场景主文档是 live-sync.md。cron-schedulerskill 还给出一个重要的多源大脑经验当gbrain sources list显示 2 个活跃源时用一条合并 cron 行替代 N 条按源条目——*/5 * * * * gbrain sync --all --parallel 4 --workers 4 --skip-failed并发预算大约是parallel × workers × 2 ≈ 32个连接每个按文件 worker 各自开一个 2 连接池要保持在 Postgresmax_connections之下。gbrain doctor在检测到 2 个活跃源时会以sync_consolidation检查的形式直接给出这条推荐行。反模式则包括所有任务挤在同一分钟:00、在 cron 里内联超长提示词、未先在 3–5 个条目上测试就跑全量、任务重跑产生不同输出非幂等、安静时段发通知、以及给每个源单独写gbrain sync --source id条目。实现在系统 cron 中落地原文档给出了一套可直接照抄的 crontab 实现注意cd到各采集器目录、重定向日志、用串联、用--json便于脚本解析# Email collector — 每 30 分钟 */30 * * * * cd /path/to/email-collector node email-collector.mjs collect node email-collector.mjs digest # X/Twitter collector — 每 30 分钟 */30 * * * * cd /path/to/x-collector node x-collector.mjs collect /tmp/x-collector.log 21 # Meeting sync — 工作日 10 点、16 点、21 点 0 10,16,21 * * 1-5 cd /path/to/meeting-sync node meeting-sync.mjs /tmp/meeting-sync.log 21 # Calendar sync — 周日 10 点 0 10 * * 0 cd /path/to/calendar-sync node calendar-sync.mjs --start $(date -v-7d %Y-%m-%d) --end $(date %Y-%m-%d) # Brain health — 每周一早上 6 点 0 6 * * 1 gbrain doctor --json /tmp/gbrain-health.log 21 gbrain embed --stale # Autopilot health gate — 每天 7 点。退出码就是信号 # 0 新鲜或未安装1 需要关注心跳过期、从未运行或已暂停2 守护进程自行退出轮换。 # 状态只读文件系统因此即使数据库宕机也能工作。 0 7 * * * gbrain autopilot --status /tmp/gbrain-autopilot-health.log 21 || your-notify gbrain autopilot needs attention # Dream cycle — 夜间 2 点 0 2 * * * /path/to/dream-cycle.sh逐行要点邮件采集拆两步collect负责抓取digest负责生成摘要两者都必须执行摘要依赖采集结果gbrain doctor --json gbrain embed --stale用保证只有健康检查通过才触发嵌入回填embed 只对缺失嵌入的 chunk 生效是 100 文件大同步或--no-embed运行的安全网gbrain autopilot --status的退出码是被设计成可用于门控的0/1/2 三态在 live-sync.md 与 maintain skill 中均有明确约定且--status只读文件系统、不连数据库——这正是它能在数据库故障期间依旧工作的原因--json会给出state、heartbeat_age_seconds、paused_reason、disabled_reason等完整报告。关于gbrain syncgbrain embed --stale这条链路的底层细节live-sync.md 补充了很有价值的前提gbrain 面向 SupabaseTransaction pooler端口 6543调优但engine.transaction()迁移、DDL、同步导入会路由到派生的direct连接db.ref.supabase.co:5432。该 direct 主机是 IPv6-only 的IPv4-only 主机不可达时会自动回退到 pooler 并打印一条 stderr 警告——但 pooler 约 2 分钟的语句超时可能截断超长迁移或批量导入。修复方式设置GBRAIN_DIRECT_DATABASE_URL为 Session pooler 字符串或启用 Supabase 的 IPv4 附加服务GBRAIN_DISABLE_DIRECT_POOL1可整体跳过 direct pool。验证方法跑一次gbrain sync比对gbrain stats的页面数与仓库中可同步文件数。同步本身是提交驱动、幂等且可恢复的它导入的是committed变更未提交的编辑与未跟踪文件会计入 drift 并打印N uncommitted file(s) not synced而非静默忽略并发运行安全同一提交两次同步因内容哈希一致而 no-op被杀掉的同步会从数据库检查点恢复bookmark 只在真正完成时前进。若你的工作流确实要写不提交的文件可用gbrain sync --working-tree单次或gbrain config set sync.include_working_tree true常驻配置dream cycle 等所有调用方都遵守——但先过一遍git status因为 untracked 意味着git status列出的所有未忽略的临时文件和密钥都会被纳入。安静时段门控强制原文档把这一节标为MANDATORY每个会发送通知的 cron 任务都必须先检查安静时段。门控是一个由你创建的小脚本gbrain 不附带它在每一个发通知的 cron 脚本顶部调用被扣下的输出进一个 holding 目录由晨间简报清空。不要从这里复制片段——完整门控脚本与模式以 Quiet Hours 为唯一权威主页。quiet-hours.md 给出的核心逻辑QUIET_START 23 // 当地 11 PM QUIET_END 8 // 当地 8 AM is_quiet(local_hour): return local_hour QUIET_START OR local_hour QUIET_END发送任何通知前必须① 确定用户当前时区来自配置或 heartbeat 状态② 将当前 UTC 时间转成当地时间③ 若在安静时段扣下消息、不发送。扣下时写入 holding 目录if is_quiet(): mkdir -p /tmp/cron-held/ write(/tmp/cron-held/{job-name}.md, output) exit // 不发送 else: send(output)晨间简报负责拾取morning_briefing(): held_files list(/tmp/cron-held/*.md) if held_files: briefing ## Overnight Updates\n\n for file in held_files: briefing read(file) delete(file)可用的 shell 实现quiet-hours-gate.sh#!/bin/bash # quiet-hours-gate.sh — run before any notification TIMEZONE${USER_TIMEZONE:-US/Pacific} LOCAL_HOUR$(TZ$TIMEZONE date %H) if [ $LOCAL_HOUR -ge 23 ] || [ $LOCAL_HOUR -lt 8 ]; then echo QUIET_HOURStrue exit 1 # 不发送 fi echo QUIET_HOURSfalse exit 0 # 可以发送在 cron 脚本中使用# 先检查安静时段 if ! bash scripts/quiet-hours-gate.sh; then mkdir -p /tmp/cron-held echo $OUTPUT /tmp/cron-held/$(basename $0 .sh).md exit 0 fi # 非安静时段——正常发送 send_notification $OUTPUT关于/tmp/cron-held/的一个现实提醒quiet-hours 文档 Tricky Spots 第 3 条/tmp在重启后不保留macOS 还会定期清理。如果一条扣下的消息绝不允许跨重启丢失改用持久目录如~/.local/state/cron-held/。另外gbrain 本身已原生理解安静时段的两处地方应优先使用自升级auto模式只在安静时段应用升级通过gbrain config set self_upgrade.quiet_hours {start:23,end:8,tz:US/Pacific}配置见 upgrades-auto-update.md其余自定义 cron、采集器、通知路径用上文 shell 模式兜底。cron-schedulerskill 还补充了 user-awake 覆盖规则默认安静时段为本地 11 PM–8 AM若用户正处于活跃状态user-awake 标志安静时段被挂起安静时段输出进 held 队列晨间联系时释放积压。旅行感知的时区处理原文档给出了 Agent 侧推断逻辑读取日历中的航班、酒店、出差中out-of-office块来推断用户当前所在地与时区所有呈现给用户的时间都用当地时区。// 示例用户飞往东京 // 太平洋时间下午 2 点 东京凌晨 3 点 安静时段 // 扣下通知并入晨间简报 get_user_timezone(): calendar gbrain search flight --type calendar --recent 7d if recent_flight: return infer_timezone(flight.destination) return config.default_timezone // fallback: US/Pacific旅行时在家乡的清醒时段会触发、但在目的地撞上睡眠时段的 cron 任务会被扣下并并入下一个晨间简报——零配置变更。quiet-hours.md提供了与之配套的操作状态结构userAwake、currentLocation、可选的homeLocationgarryAwake别名仅为兼容保留生产者应写userAwake并给出了何时应更新时区的信号日历显示用户飞往某地、用户提到身处不同城市、或用户活跃时段偏移凌晨 3 点 PT 还在回复 大概率在旅行。需要诚实地指出局限quiet-hours Tricky Spots 第 4 条基于日历的时区探测依赖用户日历中存在带位置数据的航班/酒店事件如果用户出行不建日历条目系统检测不到迁移。此时回退到活跃时段分析仍不确定就问用户。Dream Cycle最重要的 cron 任务原文档用一句话定义它的地位最重要的 cron 任务——在你睡觉时运行。gbrain 已内置直接调度gbrain dreamgbrain dream把维护循环的后半段lint、backlinks、extract、sync、embed、synthesize合并为一条命令。每晚调度它下面伪代码中的 Phase 4以及 Phase 2 的大部分卫生检查就被覆盖了。文中给出的伪代码是面向还要在其上叠加 LLM 驱动实体清扫与记忆整合的 Agent 的宿主侧变体。关于日期的归属有一个容易踩的细节夜间摘要落在你实际生活过的日历日上。循环按显式--datecycle.timezone配置 宿主 IANA 时区 UTC 的顺序分桶——因此一个在本地午夜之后运行的调度会落在你生活过的那一天而不是 UTC 日期。当宿主时钟区与你不同比如云端机器在 UTC时固定一次即可gbrain config set cycle.timezone America/Los_Angeles合成成本控制triage 级联synthesize 阶段是一个两阶段级联一个廉价的打分 triageutility 层模型每条新 transcript 一次调用为昂贵的逐 transcript 合成子代理把关。原文档给出的旋钮在 config.ts 的配置键清单中均有对应注册例如dream.triage.threshold、dream.triage.rescue_floor、dream.triage.rescue_min_segments、dream.triage.rescue_content_types、dream.triage.max_chars、dream.triage.max_tokens、dream.triage.max_ms、dream.triage.concurrency、dream.synthesize.mode、dream.synthesize.link_manifest、dream.synthesize.quote_verify、dream.synthesize.inline_concurrency、dream.synthesize.max_turns、dream.synthesize.max_submissions_per_source_per_daydream.triage.threshold默认 0.5——得分门槛是 transcript 通过闸门的两种方式中的第一种下文 verified-segment rescue 是第二种。得分会缓存因此重新调参即可瞬间重新闸控零新增 LLM 调用。太多常规内容被合成就调高真实信号被跳过就调低。models.dream.triage——triage 模型默认 utility 层 / Haiku 档。dream.triage.max_chars默认 24000下限 1000——发送给评审的每条 transcript 采样窗口头/中/尾。它不属于缓存有效性的一部分——修改后需gbrain dream retriage --force在新采样下重新评审。dream.triage.max_tokens默认 2048下限 256——评审输出预算。dream.triage.concurrency默认 4钳制 1–16——并发评审调用数。Verified-segment rescue埋没信号恢复$0得分落在[dream.triage.rescue_floor, threshold)区间内的 transcript只要满足两个条件仍可通过评审自己引用的片段中至少dream.triage.rescue_min_segments默认 2设为 0 即禁用个在 transcript 中验证为子串且其内容类型在dream.triage.rescue_content_types默认mixed,reflection,idea,strategy,people——绝不 rescue routine/technical中。零额外 LLM 调用、可作用于缓存裁决dream retriage读取同一道闸门因此 reconcile 扫描永远不会取消被 rescue 准入的任务。遥测字段details.triage.rescue_checked/rescue_fired。dream.synthesize.quote_verify默认开启——对新建 dream 页的机械式写后引用验证/修复被改写的引号会修复为逐字 transcript 片段或去掉引号绝不发明内容。关闭开关是事故逃生舱遥测落在details.synthesis.quote_verify。dream.synthesize.max_turns默认 16——agentic 子代理与 oneshot 回退的合成回合预算默认 oneshot 路径——见下节——是单次补全从不消耗回合。triage 映射把手预抽取的片段交给子代理因此中档默认模型models.dream.synthesizereasoning档 16 回合预算就是预期的配对——用 frontier 模型覆盖既不必要又拖慢队列。完整性来自 triage 覆盖每个文件都被评分减去max_ms预算下推迟的文件加上片段引导的提示词而不是模型大小。若写入页数偏低可调到 30 并检查details.synthesis.avg_turns是否存在上限压力。dream.triage.max_ms默认 5 分钟——每周期评审新文件的墙钟预算大的冷语料库跨几个周期完成 triage缓存文件免费。被推迟的文件标记为not yet triaged绝不静默拒绝。dream.synthesize.max_submissions_per_source_per_day默认 0 关——按源每日合成任务数的可选上限忙碌部署用 200/天是合理值。维护配方——修改阈值后、经历TRIAGE_VERSION提升后当前版本按峰值而非平均打分提升后首个周期会在max_ms预算内重新评审语料库并把其余推迟到后续周期或要排空排队的合成积压时gbrain dream retriage --dry-run # 会改什么零 LLM 调用 gbrain dream retriage --reconcile-queue # 重新评分 取消未通过闸门的排队任务 gbrain dream retriage --audit-rejects 20 # 用合成模型对 20 个被拒任务做二次意见源码层面的印证synthesize.ts 头部注释完整描述了该管道——discoverTranscripts → runTriagePass有界池受 dream.triage.max_ms 限制→ judgeSignificanceutility 模型在 max_chars 内的头/中/尾采样→ 得分 ≥ threshold 通过 / 得分在 [rescue_floor, threshold) 且内容类型在白名单且 ≥ rescue_min_segments 个片段验证为子串则 rescue 通过F2 救援$0仅闸控时刻→读取时——重调阈值或 rescue 旋钮 零重新评审。而 triage-rescue.ts 用常量给出了 rescue 的精确默认值DEFAULT_RESCUE_FLOOR 0.30、DEFAULT_RESCUE_MIN_SEGMENTS 2、DEFAULT_RESCUE_CONTENT_TYPES [mixed,reflection,idea,strategy,people]以及一个关键细节MIN_RESCUE_SEGMENT_NORM_CHARS 40——实质性片段至少 40 个归一化字符过短的验证引用一个名字、一句问候不算埋没信号的证据applyTriageRescue对任何畸形形状null 分数、缺失片段、非字符串引用都失败关闭fail-closed绝不抛异常passesTriageGate先做廉价的阈值判定否则进入 rescue 区间。文档所述双方式过闸与retriage 读取同一道闸门正是由passesTriageGate这一单一入口保证的文件注释里明确写着 one-gate rule任何消费者都从同一入口读取不能各自手搓score threshold检查。合成速度oneshot 模式 排水池triage 级联之上是执行旋钮dream.synthesize.mode默认oneshot——每个合成子代理如何运行。oneshot对一条已携带预检索LINK CANDIDATES清单和写入白名单的提示词做一次无工具补全然后以编程方式校验并写入页面slug 语法、白名单、transcript 哈希后缀、精确匹配 wikilink——任何写入前全部检查嵌入移出模型路径在阶段末尾由一次只覆盖本阶段写入页面的有界 pass 回填——绝不整库扫描。响应未通过任何检查时会在同一任务内自动回退到经典 agentic 循环——无工作丢失、无需重新提交。oneshot 尝试与其回退调用都是实际付费的 provider 工作都计入合成 token/花费遥测。典型效果每条 transcript 的 10 次 provider 往返上限默认 16 回合调高max_turns后更多→ 1 次。回退旋钮gbrain config set dream.synthesize.mode agentic。dream.synthesize.link_manifest默认开——零嵌入的预检索清单由 triage 裁决中缓存的实体 片段笔记构建。对两种模式都有益agentic 子代理不再把回合烧在低产搜索上oneshot 子代理提前拿到链接目标。dream.synthesize.inline_concurrency默认 1钳制 1–8——Postgres 上按运行排队的子任务队列的并发排水循环PGLite 总是串行排水。provider 上限仍由速率租约控制每条路径上的每次 provider 往返都持有一个租约槽因此这个旋钮只消除排队等待绝不过度驱动 API。如何读阶段报告details.synthesismode、oneshot_jobs/fallback_jobs/agentic_jobsfallback_reasons直方图——fallback 率上升意味着模型在违反输出契约先看首要原因再考虑回退 agenticlength包含输出用量到达请求上限的畸形响应即使 provider 的 stop reason 不明确queue_wait_ms_p50/p95与child_runtime_ms_p50/p95——缓慢但健康的排水可见不会与卡死混淆dead_jobs/degraded——任何子任务未完成的运行都不会盖章冷却cooldown因此下一次夜间运行会精确重试失败的 transcript所有子任务都死亡的运行会大声宣告阶段失败。当每一次尝试的页面写入都失败时合成子任务也会进入死信——completed从不意味着零页面写入。还有三个字段回答花了多少钱、落没落地spend——阶段实际花费cost_basis: inoutcache_read。子任务从minion_jobs的 token 数按配置的合成模型计价求和triage 来自 pass 自身的用量。total_usd只在两者都有定价时才非 null——未定价的模型读出来是 unknown 而非假0。details.triage以相同口径携带评审自己的tokens_in/tokens_out/cost_usd。children_zero_pages——完成但没写任何页面的子任务数。这个数字攀升意味着模型在产出合法但空洞的输出——而一片全绿的阶段状态会掩盖它。quote_verify——写后引用 pass 触碰了什么检查/修复/剥离的片段数、作为已存在而跳过的页面数、不平衡段落数以及仅告警的未接地数字/日期断言计数。每次调用的花费还会以阶段标签进入chat_usage_log账本编排器自己的调用在phase:synthesize下每个排干的子任务在自己的job:name下——两者永不重复计数。它做什么四阶段伪代码原文档给出了完整的 dream cycle 伪代码骨架值得完整保留它把会记住的 Agent翻译成了可执行步骤dream_cycle(): // Phase 1: 实体清扫 conversations get_todays_conversations() for message in conversations: entities detect_entities(message) for entity in entities: page gbrain search {entity.name} if not page: create_page(entity) // 新实体创建 丰富 elif page.is_thin(): enrich_page(entity) // 单薄页面补全 else: update_timeline(entity) // 已有页面追加今天的提及 // Phase 2: 修复断裂引用 pages gbrain list --type person --limit 100 for page in pages: for entry in page.timeline: if not entry.has_source_attribution(): fix_citation(entry) // 缺失时补 [Source: ...] if entry.has_tweet_url() and not entry.url_is_valid(): fix_url(entry) // 断裂的推文链接 // Phase 3: 整合记忆 patterns detect_patterns_across_conversations() for pattern in patterns: promote_to_memory(pattern) // 临时 → 持久知识 // Phase 4: 同步 gbrain sync --no-pull --no-embed gbrain embed --stale对照 maintain skillgbrain dream官方管线的实际阶段顺序是lint - backlinks - sync - synthesize - extract - patterns - embed - orphans可选阶段如 atoms/concepts/drift 插在中间。skill 补充了两个新阶段的实现细节Patterns 阶段在extract之后运行保证图状态新鲜。读取dream.patterns.lookback_days默认 30内的近期 reflections做一次 Sonnet pass 找出反复出现的主题当 ≥dream.patterns.min_evidence默认 3篇 reflection 支撑一个主题时写入wiki/personal/patterns/theme。完成一次运行会记录它消费的最新 reflectiondream.patterns.last_evidence_ts窗口内没有更新的 reflection 时重复运行以no_new_evidence跳过而不支付另一次模型 pass——gbrain dream --phase patterns --once可强制一次。冷却dream.synthesize.cooldown_hours默认 12意味着 autopilot 下每天至多约 2 次 synthesize 运行。完成时间戳dream.synthesize.last_completion_ts只在成功运行时写入跳过/失败不写。显式--input/--date/--from/--to调用绕过冷却。--dry-run语义运行打分 triage pass评审并缓存新文件裁决但跳过合成子代理。不是零 LLM 调用——要零调用预览请用gbrain dream retriage --dry-run。信任边界合成子代理运行在显式写路径白名单来自_brain-filing-rules.json的dream_synthesize_paths.globs之下即使提示注入成功也写不出白名单。PROTECTED_JOB_NAMES使 MCP 根本无法提交子代理任务。幂等与隐私transcript 以(file_path, content_hash)为键同内容重跑是 no-opdream.synthesize.exclude_patterns默认[medical, therapy]在任何 LLM 调用前过滤 transcript条目自动包裹为词边界正则medical匹配 medical advice 但不匹配 comedical。搭建 Dream Cycle按宿主分类的三种搭建方式原文档原文保留OpenClaw以 DREAMS.md 作为默认 skill 随附。light / deep / REM 三个阶段在安静时段自动运行。Hermes Agent/cron add 0 2 * * * Dream cycle: search todays sessions for entities I mentioned. For each person, company, or idea: check if a brain page exists (gbrain search), create or update it if thin. Fix any broken citations. Then consolidate: read MEMORY.md, promote important signals, remove stale entries. --name nightly-dream-cycleClaude Code / 自定义 Agent创建一个脚本#!/bin/bash # dream-cycle.sh # 检查安静时段应当在安静时段运行——这正是我们运行的时机 echo Dream cycle starting at $(date) # Phase 1: 实体清扫派生子代理 # 读取今天的对话日志抽取实体更新大脑 # Phase 2: 官方维护循环lint, backlinks, extract, sync, embed, synthesize gbrain dream # Phase 3: 呈现循环标记的任何问题 gbrain doctor --json | jq .checks[] | select(.statuswarn) echo Dream cycle complete at $(date)晨间简报与每周维护如何纳入调度参考调度表里的 Daily AM briefing 与 Weekly brain maintenance 分别由两个 skill 承担它们的输入正好是前面各环节的产出briefing skill 在动笔前有完整的 pre-briefing 上下文拉取gbrain salience --days 7情感/活动显著性扫描、gbrain anomalies对 30 天基线的统计异常、gbrain recall --query ... --json个人事实与偏好、gbrain recall --since-last-run --supersessions --pending --rollup --json热记忆脉冲隔夜解决的矛盾、top 提及、上次简报以来的新事实、待整合数以及有 Google 源时的gbrain waiting --json开环谁在等你。输出格式中每个事实都带[Source: slug, updated DATE]内联引用简报默认只读。--since-last-run会推进~/.gbrain/recall-cursors/source.json游标作为 cron 运行时务必显式传--source slug或设GBRAIN_SOURCE——cron 不会以仓库根目录为 cwd 启动。maintain skill 提供gbrain doctor --remediation-plan --jsongbrain doctor --remediate --yes --target-score 90 --max-usd 5的自治路径按依赖排序的修复计划--max-usd是硬成本上限防止合成循环在无人看管时烧掉 Anthropic 额度以及逐维度的手动走查stale 页、孤儿页、死链、缺失交叉引用、gbrain extract links --dir ~/brain、gbrain extract timeline --dir ~/brain、back-link 铁律、filing 违规、引用审计、标签一致性、gbrain features --json、嵌入新鲜度大刷新用nohup gbrain embed refresh /tmp/gbrain-embed.log 21 、RLS/模式/文件存储健康与开放线程。健康检查输出有标准化的## Brain Health Report — YYYY-MM-DD表格结构为大脑健康留下随时间可审计的轨迹。容易踩的坑Tricky Spots原文档总结了五点每一条都值得在生产前逐条对照Dream cycle 不是可选的。没有它信号从每一次对话中泄漏有了它什么都不丢——这是会忘记的 Agent与会记住的 Agent的分水岭。安静时段门控要挂在每个通知任务上。只要有一个任务跳过门控用户就会在凌晨 3 点被 ping——一次凌晨 3 点的打扰足以让用户禁用整个系统。别过度 cron。20 个任务听起来很多但起步只需邮件30 分钟、dream cycle夜间、大脑健康每周。随着集成食谱逐步增加。时区变化是自动的。不要因为用户出行就让他重配 cron——读日历、推断时区、调整投递。被扣下的消息必须被拾取。如果安静时段扣下了通知晨间简报必须包含它——否则信息就丢了。如何验证How to Verify原文档给出的五步验收清单是这套调度方案可落地的最后一块拼图安静时段把安静时段设为当前小时。跑一个发通知的 cron。验证输出去了/tmp/cron-held/而不是发到消息渠道。Dream cycle手动运行 dream cycle。检查单薄实体页被丰富、断裂引用被修复。邮件采集 cron等 30 分钟。检查data/digests/里出现新的 digest。晨间简报检查被扣消息出现在简报中。健康检查运行gbrain doctor --json。所有检查应通过。结合 live-sync.md 还可以再加两项调度链路的专项验证编辑一个 brain 文件、commit、push等下一个同步周期后用gbrain search 文本确认新内容出现返回旧内容即同步失败以及gbrain stats中页面数应等于仓库中可同步 markdown 文件数、已嵌入 chunk 数应接近总 chunk 数大缺口说明gbrain embed --stale没跟在 sync 后面。本指南是 GBrain Skillpack 的一部分。延伸阅读Quiet Hours、Live Sync、Operational Disciplines、cron-scheduler skill、minion-orchestrator skill。赞分享人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载相关推荐GoFr 内置 Cron 任务调度实战基于 using-cron-jobs 示例解析定时任务注册、调度与可观测性GoFr 内置 Cron 任务调度实战基于 using cron jobs 示例解析定时任务注册、调度与可观测性 导读 本篇文章以仓库中的 examples/后端微服务云原生可观测性Spring AI MCP Server SSE 端点无响应排查指南/sse 访问异常的快速修复路径Spring AI MCP Server SSE 端点无响应排查指南/sse 访问异常的快速修复路径 本文整理 Spring AI MCP Server 以人工智能大模型AI AgentRAG后端工具调用MCP 服务MCP ClientsEnable Screenshot vs 同类工具为什么它是最佳选择Enable Screenshot vs 同类工具为什么它是最佳选择 在数字生活中我们经常遇到无法截图的场景——银行APP的支付界面、视频平台的版权内容、移动开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 基于 gbrain 的智能体大脑定时调度实战：从 Cron 基线到 Dream Cycle 与安静时段门控
人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载导读gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain把个人/团队知识库变成了会自我维护的系统——而让自我维护真正运转起来的是一整套 20 项常驻定时任务编排。本篇以 docs/guides/cron-schedule.md 为核心骨架完整还原参考调度表、cron 落地命令、强制安静时段门控与跨时区处理并深入到gbrain dream夜间循环的三级裁剪级联triage cascade、oneshot 合成模式与排水池并发模型结合 triage-rescue.ts、synthesize.ts 等源码验证每一项配置旋钮的真实默认值与行为。读完你将能照抄出一套可上生产、可验证、不打扰用户的定时大脑维护方案。为什么要有一张调度表大脑的复利从定时开始原文档开篇就点明了这组任务的意义一个生产级大脑运行着 20 项周期任务让知识库保持鲜活、持续累积compounding。如果不做这件事大脑只会在你手动摄入数据时才更新——页面过期、实体信息单薄、引用断裂、Agent 基于旧上下文作答。而配好之后效果是闭环的邮件、社交媒体、日历、会议自动流入大脑单薄页面在夜间被自动充实断裂的引用被自动修复你醒来时大脑比入睡时更聪明。这正是 docs/guides/cron-schedule.md 想要传递的核心思想调度不是运维杂活而是大脑的存活机制。文章末尾的 Tricky Spots 第一条把它讲得很重dream cycle 不是可选的——没有它信号从每一次对话中泄漏出去有了它什么都不丢。这是一个会遗忘的 Agent 和一个会记住的 Agent 之间的区别。参考调度总表以下是原文档给出的生产环境参考调度表每个任务的 Brain Interaction 描述了它如何作用于大脑Recipe 列指向仓库中的配套食谱频率任务与大脑的交互食谱每 30 分钟邮件监控搜索发件人、更新人物页email-to-brain每 30 分钟X/Twitter 采集创建/更新媒体页、实体抽取x-to-brain工作日 3 次/天会议同步完整摄入 参会人传播meeting-sync每周日历同步每日文件 参会人丰富calendar-to-brain每日上午晨间简报检索日历参会人、交易状态、活跃线程briefing skill每周大脑维护gbrain doctor、embed stale、孤儿页检测maintain skill夜间Dream Cycle实体清扫、丰富薄弱点、修复引用见下文值得注意的原文档观点20 个任务听起来很多但别过度 cron详见 Tricky Spots 第 3 条。起步只需三件事邮件30 分钟、dream cycle夜间、大脑健康检查每周然后随集成食谱逐个增加。优先使用 gbrain 原生的调度面系统 cron 是最低公分母但 gbrain 自带多个调度面原文档明确要求能匹配就先用手边的gbrain dream—— 官方夜间维护循环lint、backlinks、extract、sync、embed、synthesize。直接调度它而不是下面手工搓 dream cycle 脚本。gbrain jobs/ minions—— 带重试、退避和审计轨迹的任务队列可提交 shell 任务或 LLM 子代理。详见 minion-orchestrator skill它区分确定性 shell 任务gbrain jobs submit shell ...与 LLM 子代理任务gbrain agent run ...并给出超过 ~2 分钟的操作必须走持久执行阶梯durable-execution ladder deadman 检查的路线约定。gbrain autopilot—— 常驻后台守护进程按自身节奏运行循环sync、extract、embed、backlinks、durible job 处理都在其中见 maintain skill 的 Autopilot check 小节。cron-schedulerskillskills/cron-scheduler/SKILL.md—— 教 Agent 管理其宿主的调度器契约包含调度错峰每 5 分钟槽位最多 1 个任务、无冲突、时区感知的安静时段门控带 user-awake 覆盖、薄任务提示读 skills/X/SKILL.md 并运行禁止内联 3000 字长提示、幂等性、结果落盘为报告reports/{job-name}/{YYYY-MM-DD-HHMM}.md。Bootstrap 会话触发的调度——gbrain bootstrap安装由 HEARTBEAT.md 驱动的、随会话活动触发的调度见 bootstrap.md。对于仅调度syncembed --stale这一具体场景主文档是 live-sync.md。cron-schedulerskill 还给出一个重要的多源大脑经验当gbrain sources list显示 2 个活跃源时用一条合并 cron 行替代 N 条按源条目——*/5 * * * * gbrain sync --all --parallel 4 --workers 4 --skip-failed并发预算大约是parallel × workers × 2 ≈ 32个连接每个按文件 worker 各自开一个 2 连接池要保持在 Postgresmax_connections之下。gbrain doctor在检测到 2 个活跃源时会以sync_consolidation检查的形式直接给出这条推荐行。反模式则包括所有任务挤在同一分钟:00、在 cron 里内联超长提示词、未先在 3–5 个条目上测试就跑全量、任务重跑产生不同输出非幂等、安静时段发通知、以及给每个源单独写gbrain sync --source id条目。实现在系统 cron 中落地原文档给出了一套可直接照抄的 crontab 实现注意cd到各采集器目录、重定向日志、用串联、用--json便于脚本解析# Email collector — 每 30 分钟 */30 * * * * cd /path/to/email-collector node email-collector.mjs collect node email-collector.mjs digest # X/Twitter collector — 每 30 分钟 */30 * * * * cd /path/to/x-collector node x-collector.mjs collect /tmp/x-collector.log 21 # Meeting sync — 工作日 10 点、16 点、21 点 0 10,16,21 * * 1-5 cd /path/to/meeting-sync node meeting-sync.mjs /tmp/meeting-sync.log 21 # Calendar sync — 周日 10 点 0 10 * * 0 cd /path/to/calendar-sync node calendar-sync.mjs --start $(date -v-7d %Y-%m-%d) --end $(date %Y-%m-%d) # Brain health — 每周一早上 6 点 0 6 * * 1 gbrain doctor --json /tmp/gbrain-health.log 21 gbrain embed --stale # Autopilot health gate — 每天 7 点。退出码就是信号 # 0 新鲜或未安装1 需要关注心跳过期、从未运行或已暂停2 守护进程自行退出轮换。 # 状态只读文件系统因此即使数据库宕机也能工作。 0 7 * * * gbrain autopilot --status /tmp/gbrain-autopilot-health.log 21 || your-notify gbrain autopilot needs attention # Dream cycle — 夜间 2 点 0 2 * * * /path/to/dream-cycle.sh逐行要点邮件采集拆两步collect负责抓取digest负责生成摘要两者都必须执行摘要依赖采集结果gbrain doctor --json gbrain embed --stale用保证只有健康检查通过才触发嵌入回填embed 只对缺失嵌入的 chunk 生效是 100 文件大同步或--no-embed运行的安全网gbrain autopilot --status的退出码是被设计成可用于门控的0/1/2 三态在 live-sync.md 与 maintain skill 中均有明确约定且--status只读文件系统、不连数据库——这正是它能在数据库故障期间依旧工作的原因--json会给出state、heartbeat_age_seconds、paused_reason、disabled_reason等完整报告。关于gbrain syncgbrain embed --stale这条链路的底层细节live-sync.md 补充了很有价值的前提gbrain 面向 SupabaseTransaction pooler端口 6543调优但engine.transaction()迁移、DDL、同步导入会路由到派生的direct连接db.ref.supabase.co:5432。该 direct 主机是 IPv6-only 的IPv4-only 主机不可达时会自动回退到 pooler 并打印一条 stderr 警告——但 pooler 约 2 分钟的语句超时可能截断超长迁移或批量导入。修复方式设置GBRAIN_DIRECT_DATABASE_URL为 Session pooler 字符串或启用 Supabase 的 IPv4 附加服务GBRAIN_DISABLE_DIRECT_POOL1可整体跳过 direct pool。验证方法跑一次gbrain sync比对gbrain stats的页面数与仓库中可同步文件数。同步本身是提交驱动、幂等且可恢复的它导入的是committed变更未提交的编辑与未跟踪文件会计入 drift 并打印N uncommitted file(s) not synced而非静默忽略并发运行安全同一提交两次同步因内容哈希一致而 no-op被杀掉的同步会从数据库检查点恢复bookmark 只在真正完成时前进。若你的工作流确实要写不提交的文件可用gbrain sync --working-tree单次或gbrain config set sync.include_working_tree true常驻配置dream cycle 等所有调用方都遵守——但先过一遍git status因为 untracked 意味着git status列出的所有未忽略的临时文件和密钥都会被纳入。安静时段门控强制原文档把这一节标为MANDATORY每个会发送通知的 cron 任务都必须先检查安静时段。门控是一个由你创建的小脚本gbrain 不附带它在每一个发通知的 cron 脚本顶部调用被扣下的输出进一个 holding 目录由晨间简报清空。不要从这里复制片段——完整门控脚本与模式以 Quiet Hours 为唯一权威主页。quiet-hours.md 给出的核心逻辑QUIET_START 23 // 当地 11 PM QUIET_END 8 // 当地 8 AM is_quiet(local_hour): return local_hour QUIET_START OR local_hour QUIET_END发送任何通知前必须① 确定用户当前时区来自配置或 heartbeat 状态② 将当前 UTC 时间转成当地时间③ 若在安静时段扣下消息、不发送。扣下时写入 holding 目录if is_quiet(): mkdir -p /tmp/cron-held/ write(/tmp/cron-held/{job-name}.md, output) exit // 不发送 else: send(output)晨间简报负责拾取morning_briefing(): held_files list(/tmp/cron-held/*.md) if held_files: briefing ## Overnight Updates\n\n for file in held_files: briefing read(file) delete(file)可用的 shell 实现quiet-hours-gate.sh#!/bin/bash # quiet-hours-gate.sh — run before any notification TIMEZONE${USER_TIMEZONE:-US/Pacific} LOCAL_HOUR$(TZ$TIMEZONE date %H) if [ $LOCAL_HOUR -ge 23 ] || [ $LOCAL_HOUR -lt 8 ]; then echo QUIET_HOURStrue exit 1 # 不发送 fi echo QUIET_HOURSfalse exit 0 # 可以发送在 cron 脚本中使用# 先检查安静时段 if ! bash scripts/quiet-hours-gate.sh; then mkdir -p /tmp/cron-held echo $OUTPUT /tmp/cron-held/$(basename $0 .sh).md exit 0 fi # 非安静时段——正常发送 send_notification $OUTPUT关于/tmp/cron-held/的一个现实提醒quiet-hours 文档 Tricky Spots 第 3 条/tmp在重启后不保留macOS 还会定期清理。如果一条扣下的消息绝不允许跨重启丢失改用持久目录如~/.local/state/cron-held/。另外gbrain 本身已原生理解安静时段的两处地方应优先使用自升级auto模式只在安静时段应用升级通过gbrain config set self_upgrade.quiet_hours {start:23,end:8,tz:US/Pacific}配置见 upgrades-auto-update.md其余自定义 cron、采集器、通知路径用上文 shell 模式兜底。cron-schedulerskill 还补充了 user-awake 覆盖规则默认安静时段为本地 11 PM–8 AM若用户正处于活跃状态user-awake 标志安静时段被挂起安静时段输出进 held 队列晨间联系时释放积压。旅行感知的时区处理原文档给出了 Agent 侧推断逻辑读取日历中的航班、酒店、出差中out-of-office块来推断用户当前所在地与时区所有呈现给用户的时间都用当地时区。// 示例用户飞往东京 // 太平洋时间下午 2 点 东京凌晨 3 点 安静时段 // 扣下通知并入晨间简报 get_user_timezone(): calendar gbrain search flight --type calendar --recent 7d if recent_flight: return infer_timezone(flight.destination) return config.default_timezone // fallback: US/Pacific旅行时在家乡的清醒时段会触发、但在目的地撞上睡眠时段的 cron 任务会被扣下并并入下一个晨间简报——零配置变更。quiet-hours.md提供了与之配套的操作状态结构userAwake、currentLocation、可选的homeLocationgarryAwake别名仅为兼容保留生产者应写userAwake并给出了何时应更新时区的信号日历显示用户飞往某地、用户提到身处不同城市、或用户活跃时段偏移凌晨 3 点 PT 还在回复 大概率在旅行。需要诚实地指出局限quiet-hours Tricky Spots 第 4 条基于日历的时区探测依赖用户日历中存在带位置数据的航班/酒店事件如果用户出行不建日历条目系统检测不到迁移。此时回退到活跃时段分析仍不确定就问用户。Dream Cycle最重要的 cron 任务原文档用一句话定义它的地位最重要的 cron 任务——在你睡觉时运行。gbrain 已内置直接调度gbrain dreamgbrain dream把维护循环的后半段lint、backlinks、extract、sync、embed、synthesize合并为一条命令。每晚调度它下面伪代码中的 Phase 4以及 Phase 2 的大部分卫生检查就被覆盖了。文中给出的伪代码是面向还要在其上叠加 LLM 驱动实体清扫与记忆整合的 Agent 的宿主侧变体。关于日期的归属有一个容易踩的细节夜间摘要落在你实际生活过的日历日上。循环按显式--datecycle.timezone配置 宿主 IANA 时区 UTC 的顺序分桶——因此一个在本地午夜之后运行的调度会落在你生活过的那一天而不是 UTC 日期。当宿主时钟区与你不同比如云端机器在 UTC时固定一次即可gbrain config set cycle.timezone America/Los_Angeles合成成本控制triage 级联synthesize 阶段是一个两阶段级联一个廉价的打分 triageutility 层模型每条新 transcript 一次调用为昂贵的逐 transcript 合成子代理把关。原文档给出的旋钮在 config.ts 的配置键清单中均有对应注册例如dream.triage.threshold、dream.triage.rescue_floor、dream.triage.rescue_min_segments、dream.triage.rescue_content_types、dream.triage.max_chars、dream.triage.max_tokens、dream.triage.max_ms、dream.triage.concurrency、dream.synthesize.mode、dream.synthesize.link_manifest、dream.synthesize.quote_verify、dream.synthesize.inline_concurrency、dream.synthesize.max_turns、dream.synthesize.max_submissions_per_source_per_daydream.triage.threshold默认 0.5——得分门槛是 transcript 通过闸门的两种方式中的第一种下文 verified-segment rescue 是第二种。得分会缓存因此重新调参即可瞬间重新闸控零新增 LLM 调用。太多常规内容被合成就调高真实信号被跳过就调低。models.dream.triage——triage 模型默认 utility 层 / Haiku 档。dream.triage.max_chars默认 24000下限 1000——发送给评审的每条 transcript 采样窗口头/中/尾。它不属于缓存有效性的一部分——修改后需gbrain dream retriage --force在新采样下重新评审。dream.triage.max_tokens默认 2048下限 256——评审输出预算。dream.triage.concurrency默认 4钳制 1–16——并发评审调用数。Verified-segment rescue埋没信号恢复$0得分落在[dream.triage.rescue_floor, threshold)区间内的 transcript只要满足两个条件仍可通过评审自己引用的片段中至少dream.triage.rescue_min_segments默认 2设为 0 即禁用个在 transcript 中验证为子串且其内容类型在dream.triage.rescue_content_types默认mixed,reflection,idea,strategy,people——绝不 rescue routine/technical中。零额外 LLM 调用、可作用于缓存裁决dream retriage读取同一道闸门因此 reconcile 扫描永远不会取消被 rescue 准入的任务。遥测字段details.triage.rescue_checked/rescue_fired。dream.synthesize.quote_verify默认开启——对新建 dream 页的机械式写后引用验证/修复被改写的引号会修复为逐字 transcript 片段或去掉引号绝不发明内容。关闭开关是事故逃生舱遥测落在details.synthesis.quote_verify。dream.synthesize.max_turns默认 16——agentic 子代理与 oneshot 回退的合成回合预算默认 oneshot 路径——见下节——是单次补全从不消耗回合。triage 映射把手预抽取的片段交给子代理因此中档默认模型models.dream.synthesizereasoning档 16 回合预算就是预期的配对——用 frontier 模型覆盖既不必要又拖慢队列。完整性来自 triage 覆盖每个文件都被评分减去max_ms预算下推迟的文件加上片段引导的提示词而不是模型大小。若写入页数偏低可调到 30 并检查details.synthesis.avg_turns是否存在上限压力。dream.triage.max_ms默认 5 分钟——每周期评审新文件的墙钟预算大的冷语料库跨几个周期完成 triage缓存文件免费。被推迟的文件标记为not yet triaged绝不静默拒绝。dream.synthesize.max_submissions_per_source_per_day默认 0 关——按源每日合成任务数的可选上限忙碌部署用 200/天是合理值。维护配方——修改阈值后、经历TRIAGE_VERSION提升后当前版本按峰值而非平均打分提升后首个周期会在max_ms预算内重新评审语料库并把其余推迟到后续周期或要排空排队的合成积压时gbrain dream retriage --dry-run # 会改什么零 LLM 调用 gbrain dream retriage --reconcile-queue # 重新评分 取消未通过闸门的排队任务 gbrain dream retriage --audit-rejects 20 # 用合成模型对 20 个被拒任务做二次意见源码层面的印证synthesize.ts 头部注释完整描述了该管道——discoverTranscripts → runTriagePass有界池受 dream.triage.max_ms 限制→ judgeSignificanceutility 模型在 max_chars 内的头/中/尾采样→ 得分 ≥ threshold 通过 / 得分在 [rescue_floor, threshold) 且内容类型在白名单且 ≥ rescue_min_segments 个片段验证为子串则 rescue 通过F2 救援$0仅闸控时刻→读取时——重调阈值或 rescue 旋钮 零重新评审。而 triage-rescue.ts 用常量给出了 rescue 的精确默认值DEFAULT_RESCUE_FLOOR 0.30、DEFAULT_RESCUE_MIN_SEGMENTS 2、DEFAULT_RESCUE_CONTENT_TYPES [mixed,reflection,idea,strategy,people]以及一个关键细节MIN_RESCUE_SEGMENT_NORM_CHARS 40——实质性片段至少 40 个归一化字符过短的验证引用一个名字、一句问候不算埋没信号的证据applyTriageRescue对任何畸形形状null 分数、缺失片段、非字符串引用都失败关闭fail-closed绝不抛异常passesTriageGate先做廉价的阈值判定否则进入 rescue 区间。文档所述双方式过闸与retriage 读取同一道闸门正是由passesTriageGate这一单一入口保证的文件注释里明确写着 one-gate rule任何消费者都从同一入口读取不能各自手搓score threshold检查。合成速度oneshot 模式 排水池triage 级联之上是执行旋钮dream.synthesize.mode默认oneshot——每个合成子代理如何运行。oneshot对一条已携带预检索LINK CANDIDATES清单和写入白名单的提示词做一次无工具补全然后以编程方式校验并写入页面slug 语法、白名单、transcript 哈希后缀、精确匹配 wikilink——任何写入前全部检查嵌入移出模型路径在阶段末尾由一次只覆盖本阶段写入页面的有界 pass 回填——绝不整库扫描。响应未通过任何检查时会在同一任务内自动回退到经典 agentic 循环——无工作丢失、无需重新提交。oneshot 尝试与其回退调用都是实际付费的 provider 工作都计入合成 token/花费遥测。典型效果每条 transcript 的 10 次 provider 往返上限默认 16 回合调高max_turns后更多→ 1 次。回退旋钮gbrain config set dream.synthesize.mode agentic。dream.synthesize.link_manifest默认开——零嵌入的预检索清单由 triage 裁决中缓存的实体 片段笔记构建。对两种模式都有益agentic 子代理不再把回合烧在低产搜索上oneshot 子代理提前拿到链接目标。dream.synthesize.inline_concurrency默认 1钳制 1–8——Postgres 上按运行排队的子任务队列的并发排水循环PGLite 总是串行排水。provider 上限仍由速率租约控制每条路径上的每次 provider 往返都持有一个租约槽因此这个旋钮只消除排队等待绝不过度驱动 API。如何读阶段报告details.synthesismode、oneshot_jobs/fallback_jobs/agentic_jobsfallback_reasons直方图——fallback 率上升意味着模型在违反输出契约先看首要原因再考虑回退 agenticlength包含输出用量到达请求上限的畸形响应即使 provider 的 stop reason 不明确queue_wait_ms_p50/p95与child_runtime_ms_p50/p95——缓慢但健康的排水可见不会与卡死混淆dead_jobs/degraded——任何子任务未完成的运行都不会盖章冷却cooldown因此下一次夜间运行会精确重试失败的 transcript所有子任务都死亡的运行会大声宣告阶段失败。当每一次尝试的页面写入都失败时合成子任务也会进入死信——completed从不意味着零页面写入。还有三个字段回答花了多少钱、落没落地spend——阶段实际花费cost_basis: inoutcache_read。子任务从minion_jobs的 token 数按配置的合成模型计价求和triage 来自 pass 自身的用量。total_usd只在两者都有定价时才非 null——未定价的模型读出来是 unknown 而非假0。details.triage以相同口径携带评审自己的tokens_in/tokens_out/cost_usd。children_zero_pages——完成但没写任何页面的子任务数。这个数字攀升意味着模型在产出合法但空洞的输出——而一片全绿的阶段状态会掩盖它。quote_verify——写后引用 pass 触碰了什么检查/修复/剥离的片段数、作为已存在而跳过的页面数、不平衡段落数以及仅告警的未接地数字/日期断言计数。每次调用的花费还会以阶段标签进入chat_usage_log账本编排器自己的调用在phase:synthesize下每个排干的子任务在自己的job:name下——两者永不重复计数。它做什么四阶段伪代码原文档给出了完整的 dream cycle 伪代码骨架值得完整保留它把会记住的 Agent翻译成了可执行步骤dream_cycle(): // Phase 1: 实体清扫 conversations get_todays_conversations() for message in conversations: entities detect_entities(message) for entity in entities: page gbrain search {entity.name} if not page: create_page(entity) // 新实体创建 丰富 elif page.is_thin(): enrich_page(entity) // 单薄页面补全 else: update_timeline(entity) // 已有页面追加今天的提及 // Phase 2: 修复断裂引用 pages gbrain list --type person --limit 100 for page in pages: for entry in page.timeline: if not entry.has_source_attribution(): fix_citation(entry) // 缺失时补 [Source: ...] if entry.has_tweet_url() and not entry.url_is_valid(): fix_url(entry) // 断裂的推文链接 // Phase 3: 整合记忆 patterns detect_patterns_across_conversations() for pattern in patterns: promote_to_memory(pattern) // 临时 → 持久知识 // Phase 4: 同步 gbrain sync --no-pull --no-embed gbrain embed --stale对照 maintain skillgbrain dream官方管线的实际阶段顺序是lint - backlinks - sync - synthesize - extract - patterns - embed - orphans可选阶段如 atoms/concepts/drift 插在中间。skill 补充了两个新阶段的实现细节Patterns 阶段在extract之后运行保证图状态新鲜。读取dream.patterns.lookback_days默认 30内的近期 reflections做一次 Sonnet pass 找出反复出现的主题当 ≥dream.patterns.min_evidence默认 3篇 reflection 支撑一个主题时写入wiki/personal/patterns/theme。完成一次运行会记录它消费的最新 reflectiondream.patterns.last_evidence_ts窗口内没有更新的 reflection 时重复运行以no_new_evidence跳过而不支付另一次模型 pass——gbrain dream --phase patterns --once可强制一次。冷却dream.synthesize.cooldown_hours默认 12意味着 autopilot 下每天至多约 2 次 synthesize 运行。完成时间戳dream.synthesize.last_completion_ts只在成功运行时写入跳过/失败不写。显式--input/--date/--from/--to调用绕过冷却。--dry-run语义运行打分 triage pass评审并缓存新文件裁决但跳过合成子代理。不是零 LLM 调用——要零调用预览请用gbrain dream retriage --dry-run。信任边界合成子代理运行在显式写路径白名单来自_brain-filing-rules.json的dream_synthesize_paths.globs之下即使提示注入成功也写不出白名单。PROTECTED_JOB_NAMES使 MCP 根本无法提交子代理任务。幂等与隐私transcript 以(file_path, content_hash)为键同内容重跑是 no-opdream.synthesize.exclude_patterns默认[medical, therapy]在任何 LLM 调用前过滤 transcript条目自动包裹为词边界正则medical匹配 medical advice 但不匹配 comedical。搭建 Dream Cycle按宿主分类的三种搭建方式原文档原文保留OpenClaw以 DREAMS.md 作为默认 skill 随附。light / deep / REM 三个阶段在安静时段自动运行。Hermes Agent/cron add 0 2 * * * Dream cycle: search todays sessions for entities I mentioned. For each person, company, or idea: check if a brain page exists (gbrain search), create or update it if thin. Fix any broken citations. Then consolidate: read MEMORY.md, promote important signals, remove stale entries. --name nightly-dream-cycleClaude Code / 自定义 Agent创建一个脚本#!/bin/bash # dream-cycle.sh # 检查安静时段应当在安静时段运行——这正是我们运行的时机 echo Dream cycle starting at $(date) # Phase 1: 实体清扫派生子代理 # 读取今天的对话日志抽取实体更新大脑 # Phase 2: 官方维护循环lint, backlinks, extract, sync, embed, synthesize gbrain dream # Phase 3: 呈现循环标记的任何问题 gbrain doctor --json | jq .checks[] | select(.statuswarn) echo Dream cycle complete at $(date)晨间简报与每周维护如何纳入调度参考调度表里的 Daily AM briefing 与 Weekly brain maintenance 分别由两个 skill 承担它们的输入正好是前面各环节的产出briefing skill 在动笔前有完整的 pre-briefing 上下文拉取gbrain salience --days 7情感/活动显著性扫描、gbrain anomalies对 30 天基线的统计异常、gbrain recall --query ... --json个人事实与偏好、gbrain recall --since-last-run --supersessions --pending --rollup --json热记忆脉冲隔夜解决的矛盾、top 提及、上次简报以来的新事实、待整合数以及有 Google 源时的gbrain waiting --json开环谁在等你。输出格式中每个事实都带[Source: slug, updated DATE]内联引用简报默认只读。--since-last-run会推进~/.gbrain/recall-cursors/source.json游标作为 cron 运行时务必显式传--source slug或设GBRAIN_SOURCE——cron 不会以仓库根目录为 cwd 启动。maintain skill 提供gbrain doctor --remediation-plan --jsongbrain doctor --remediate --yes --target-score 90 --max-usd 5的自治路径按依赖排序的修复计划--max-usd是硬成本上限防止合成循环在无人看管时烧掉 Anthropic 额度以及逐维度的手动走查stale 页、孤儿页、死链、缺失交叉引用、gbrain extract links --dir ~/brain、gbrain extract timeline --dir ~/brain、back-link 铁律、filing 违规、引用审计、标签一致性、gbrain features --json、嵌入新鲜度大刷新用nohup gbrain embed refresh /tmp/gbrain-embed.log 21 、RLS/模式/文件存储健康与开放线程。健康检查输出有标准化的## Brain Health Report — YYYY-MM-DD表格结构为大脑健康留下随时间可审计的轨迹。容易踩的坑Tricky Spots原文档总结了五点每一条都值得在生产前逐条对照Dream cycle 不是可选的。没有它信号从每一次对话中泄漏有了它什么都不丢——这是会忘记的 Agent与会记住的 Agent的分水岭。安静时段门控要挂在每个通知任务上。只要有一个任务跳过门控用户就会在凌晨 3 点被 ping——一次凌晨 3 点的打扰足以让用户禁用整个系统。别过度 cron。20 个任务听起来很多但起步只需邮件30 分钟、dream cycle夜间、大脑健康每周。随着集成食谱逐步增加。时区变化是自动的。不要因为用户出行就让他重配 cron——读日历、推断时区、调整投递。被扣下的消息必须被拾取。如果安静时段扣下了通知晨间简报必须包含它——否则信息就丢了。如何验证How to Verify原文档给出的五步验收清单是这套调度方案可落地的最后一块拼图安静时段把安静时段设为当前小时。跑一个发通知的 cron。验证输出去了/tmp/cron-held/而不是发到消息渠道。Dream cycle手动运行 dream cycle。检查单薄实体页被丰富、断裂引用被修复。邮件采集 cron等 30 分钟。检查data/digests/里出现新的 digest。晨间简报检查被扣消息出现在简报中。健康检查运行gbrain doctor --json。所有检查应通过。结合 live-sync.md 还可以再加两项调度链路的专项验证编辑一个 brain 文件、commit、push等下一个同步周期后用gbrain search 文本确认新内容出现返回旧内容即同步失败以及gbrain stats中页面数应等于仓库中可同步 markdown 文件数、已嵌入 chunk 数应接近总 chunk 数大缺口说明gbrain embed --stale没跟在 sync 后面。本指南是 GBrain Skillpack 的一部分。延伸阅读Quiet Hours、Live Sync、Operational Disciplines、cron-scheduler skill、minion-orchestrator skill。赞分享人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载相关推荐GoFr 内置 Cron 任务调度实战基于 using-cron-jobs 示例解析定时任务注册、调度与可观测性GoFr 内置 Cron 任务调度实战基于 using cron jobs 示例解析定时任务注册、调度与可观测性 导读 本篇文章以仓库中的 examples/后端微服务云原生可观测性Spring AI MCP Server SSE 端点无响应排查指南/sse 访问异常的快速修复路径Spring AI MCP Server SSE 端点无响应排查指南/sse 访问异常的快速修复路径 本文整理 Spring AI MCP Server 以人工智能大模型AI AgentRAG后端工具调用MCP 服务MCP ClientsEnable Screenshot vs 同类工具为什么它是最佳选择Enable Screenshot vs 同类工具为什么它是最佳选择 在数字生活中我们经常遇到无法截图的场景——银行APP的支付界面、视频平台的版权内容、移动开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考