人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载gbrain 的 Executive AssistantEA模式把邮件分诊、会议准备、日程调度从机械的收件箱操作升级为由大脑brain上下文驱动的智能工作流代理在读邮件之前先查发送者的大脑页面开会之前先加载每位参会者的关系历史安排日程时以 open-loop 引擎维护的谁欠我什么、我欠谁什么为真实数据源。读完本文你将掌握该模式的四个可落地工作流邮件分诊、会议准备、收件箱后的脑页更新、日程调度提醒理解其底层 open-loop 引擎的实现机制确定性线程状态机与 LLM 承诺提取器并得到一份可逐条执行的验证清单。模式目标从机械分诊到有上下文的判断本模式的核心主张是每一次与人的交互都应该被这段关系的完整历史所告知原文称之为 powered by brain context — so every interaction is informed by the full history of the relationship。没有本模式时代理机械地分诊邮件你有 12 封未读、用千篇一律的 LinkedIn 简介准备会议、在不了解关系上下文的情况下安排日程。有了本模式后代理在读邮件之前就知道每个发送者是谁在每次会议前呈现你们共同的过往历史并根据关系的温度relationship temperature和未结线程open threads来推动日程安排。这种差异不是体验层面的润色而是判断依据的结构性变化——分诊、简报、提醒的每条信息都来自大脑页面与 open-loop 行而非代理的临时猜测。架构基础本模式依赖的四个原生组件本模式的实现不要求手搓收件采集或线程跟踪它站在 gbrain 四个既有原生组件之上Google 连接器将 Gmail/Calendar/Contacts 摄入大脑全程只读gmail.readonly、calendar.readonly、contacts.readonly令牌只存在于本地凭据保险库~/.gbrain/credentials.json0600 权限采用自带 OAuthBYO OAuth模式。完整接入流程见 docs/guides/google-connect.md。Open-loop 引擎在 Google 源之上维护真实的循环行loop rows支撑gbrain waiting命令与open_loopsMCP 操作。下文中工作流里的context.open_threads正是由这些行支撑——每个实体卡片entity card按线程携带direction、due、loop_id字段。机制细节见 docs/guides/open-loops.md。google-loops 技能日常操作契约连接、gbrain waiting摘要、循环关闭/静音、故障排查集中在 skills/google-loops/SKILL.md。已内置的半个模式gbrain 已经把本模式的晨间简报一半打包为briefing技能skills/briefing/把任务准备一半打包为daily-task-prep技能skills/daily-task-prep/。本文下面的工作流用于扩展或定制这两个技能已经内置的行为而不是重复造轮子。值得注意daily-task-prep技能明确要求当存在 google 源时gbrain waiting --json是未接线程与未答复事项的真实数据源——它携带带对手方、截止日期和证据的循环行优先于散文式启发这与 EA 模式open-loop 行优于推断的原则完全一致。工作流 1邮件分诊Email Triage邮件分诊的黄金法则是先加载大脑上下文再读邮件正文。完整工作流如下来自原文档语义保持原样# WORKFLOW 1: Email Triage on email_batch(emails): # Step 0: Load the open-loop state FIRST — who is already waiting on you # (real loop rows: deterministic thread detector commitment extractor) waiting gbrain waiting --json # or the open_loops op over MCP # Refuses on stale google sources by design — run the sync it names first for email in emails: # Step 1: Search sender BEFORE reading the email body # Brain context makes triage 10x better sender_page gbrain search {email.sender_name} if sender_page: context gbrain get sender_slug # Now you know: who they are, relationship history, # what they care about, open threads # context.open_threads entries are backed by loop rows and # carry direction (owed_by_me/owed_to_me), due, loop_id # Step 2: Read the email WITH brain context loaded # Classification is now informed, not mechanical # Step 3: Classify with context if context.relationship inner_circle or sender in waiting.counterparties: priority urgent # theyre already waiting on the user elif context.is_known_entity: priority normal else: priority noise # unknown sender, no brain page # Step 4: Draft reply with relationship context if needs_reply(email): draft compose_reply( email, contextcontext, # their brain page open_threadscontext.open_threads, # loop-backed: whats owed, by whom, due when relationshipcontext.relationship # tone calibration ) # After the user sends a reply, the loop closes itself on the next # sync (closed_by: reply_detected); commitments close via # gbrain loops done loop_id关键操作点Step 0 的gbrain waiting --json这是整个模式的排名真相源默认跨大脑内所有源读取open-loop 行存在于 google 源而非default源默认作用域的读取会误报一切正常。它会在每个 google 源超过 24 小时无成功同步时拒绝输出并打印确切修复命令gbrain sync --source id因为过时但自信的输出比没有更糟——这是刻意设计详见 docs/guides/open-loops.md 的 surfaces 一节。Step 1 的先搜发送者原文档强调这是反直觉但至关重要的步骤——在看到主题行之前你就知道对方是谁、你们在共同推进什么、他们关心什么。分诊逻辑inner_circle关系或正在等你的对手方 →urgent已知实体 →normal无大脑页面的未知发送者 → 几乎总是noise见下文陷阱第 2 条。回信后的闭环用户发出回复后线程循环会在下一次同步时自行关闭closed_by: reply_detected承诺类循环则通过gbrain loops done loop_id手动关闭。工作流 2会议准备Meeting Prep会议准备是 EA 模式中杠杆率最高的工作流——用户走进每一场会议时已经对每位参会者完成了简报。完整流程# WORKFLOW 2: Meeting Prep on upcoming_meeting(meeting): briefing {} for attendee in meeting.attendees: # Search brain for each attendee results gbrain search {attendee.name} if results: page gbrain get attendee_slug briefing[attendee] { compiled_truth: page.compiled_truth, last_interaction: page.timeline[0], # most recent open_threads: page.open_threads, relationship_temperature: page.relationship, relevant_deals: gbrain call get_links {slug: attendee_slug}, } else: briefing[attendee] No brain page -- consider enriching # Surface: shared history, what to follow up on, what to watch for # Last time you discussed the Series B timeline. alice-example was # concerned about burn rate. Heres the latest from her company page.要点每位参会者的简报五件套compiled_truth编译真相、timeline[0]最近一次交互、open_threads未结线程、relationship关系温度、get_links相关交易/页面。覆盖缺口显式化没有大脑页面的参会者简报中明确写出 No brain page — consider enriching而不是假装认识对方。与内置技能的一致性briefing技能的 Phase 1 Todays meetings 采用完全相同的手法先gbrain search attendee name找到页面再gbrain get slug加载编译真相、近期时间线与关系上下文daily-task-prep技能则为每场会议产出参会者带大脑上下文 背景近期互动、未结线程 准备要点的上下文卡片。会议本身的摄入与实体传播由 skills/meeting-ingestion/SKILL.md 保证——这正是上次讨论 Series B 时 alice 担心 burn rate这类时间线数据的来源。工作流 3收件箱清空后的大脑更新Post-Inbox Brain Updates这是大脑复利的关键步骤也是大多数代理跳过的一步每封邮件都是信号清空收件箱而不更新脑页信息就丢了。完整流程# WORKFLOW 3: Post-Inbox Brain Updates on inbox_cleared(): for email in processed_emails: if email.contained_new_information: # Update the senders brain page with new signal gbrain timeline-add sender_slug {date} \ Email re: {subject}. Key info: {extracted_signal} \ --source email from {sender} re {subject}, {date} # Update any mentioned entity pages too for entity in email.mentioned_entities: gbrain timeline-add entity_slug {date} \ {what_was_said_about_them} \ --source email from {sender}, {date}操作要点只对包含新信息的邮件做更新email.contained_new_information作为筛选条件避免噪声刷屏。发送者页面和邮件中提及的其他实体页面都要更新——后者确保alice 的公司页里有她公司的最新动态这类跨实体引用成立。每个timeline-add都带--source溯源信息哪封邮件、哪个发送者、什么日期符合 gbrain 的证据纪律。工作流 4日程调度提醒Scheduling Nudges日程提醒不是拍脑袋而是以 loop 引擎的排名输出为数据源逐条核对每位参会者的页面状态。完整流程# WORKFLOW 4: Scheduling Nudges on schedule_request(meeting): # The ranked source of truth for who is owed what is the loop engine: waiting gbrain waiting --json # top counterparties, due dates, evidence for attendee in meeting.attendees: page gbrain get attendee_slug if page.last_interaction 6_weeks_ago: nudge(You havent met with {attendee} in {weeks} weeks) for thread in page.open_threads: # loop-backed entries if thread.direction owed_by_me: nudge(You owe {attendee}: {thread.summary} (due {thread.due})) else: nudge({attendee} owes you: {thread.summary} — worth raising in the meeting) if page.relationship_temperature cooling: nudge(Relationship with {attendee} may need attention) # When a nudge is resolved in the meeting, close it: # gbrain loops done thread.loop_id要点谁欠什么的排名真相源是 loop 引擎gbrain waiting --json排名靠前的对手方、截止日期、证据引文不是散文式推断。三种提醒各对应一类页面数据时间间隔6 周未见面来自page.last_interaction依赖会议页面已按正确的实体传播摄入方向性债务owed_by_me/owed_to_me来自 loop-backed 的open_threads带due日期关系温度cooling来自page.relationship。提醒在会议中解决后用gbrain loops done thread.loop_id关闭对应循环。底层原理open-loop 引擎如何支撑context.open_threads工作流中的waiting.counterparties、context.open_threads、direction/due/loop_id不是占位概念而是 docs/guides/open-loops.md 中 open-loop 引擎open_loops表的真实数据。它由两个检测器构成1. 确定性线程状态机src/core/google/loop-detect.ts零 LLM、免费、始终开启。对每条已同步的 Gmail 线程最后一条实质消息是对方的、你在收件人To:中、未答复 ≥24h →unanswered_inbound对方在等你。最后一条实质消息是你的、含问句、未答复 ≥72h →unanswered_outbound你在等对方。回复到达 → 循环自行关闭closed_by: reply_detected。循环靠状态转换关闭从不删除——审计轨迹保留。从源码看loop-detect.ts该检测器与google-render.ts导出的isNoiseSender、isCalendarSystemMail协同工作噪声发送者、列表邮件List-Unsubscribe、纯日历系统邮件永远不开环。特别地Google Calendar 的系统通知Invitation:、Accepted:、Declined:、Canceled event:等由日历代表人类发出、来自同事真实地址因此用 iCalendarMETHODRFC 5546 的REQUEST/REPLY/CANCEL等结构识别而非按发件人识别——它们既不开启也不关闭循环邀请不是回复让它翻转回合会静默回答真实的 outbound 循环但照常摄入为可搜索页面并喂给日历/会议上下文。精度规则由 test/google-loop-detect.test.ts 的标记化 fixture 语料固定——每个误报类别在修复前都要先有对应 fixture。2. LLM 承诺提取器src/core/google/loops-extract.ts每条近期线程一次模型调用google 源默认开启。提取带方向的承诺我周五前把 deck 发你 →commitment_owed_by_me对手方、截止日期、逐字引用与待决决策。每个条目有三个投影open_loops行本身一条facts行kindcommitmentfence-first、去重让entity/context_pack/recall通过既有读路径看到一条类型化边线程页 → 人物页owes_to/awaiting_reply_from供关系检索遍历。护栏包括注入加固模型只见线程最新 12k 字符、全有或全无的解析屏障、只提取最近 30 天邮件、以及开关gbrain config set loops.extraction_enabled false。结构性资格门槛loopExtractionEligibility先于提取器运行让批量邮件既不为模型调用付费、也不挤占真实往来详见 docs/guides/open-loops.md邮件形态是否进入提取SPAM/TRASH否无论谁写的账户主人写了实质消息SENT标签或已知主人地址日历 RSVP 等噪声不计是覆盖以下所有规则纯噪声发送者 / 纯日历通知否CATEGORY_PROMOTIONS/SOCIAL/FORUMS否除非主人参与List-Unsubscribe批量邮件否除非主人参与CATEGORY_UPDATES是—— 发票、合同、文档请求都在这里普通人际往来是主人参与是承重规则你自己的外发消息正是承诺所在所以写在批量标签线程回复里的我周五前发给你依然可被提取。所有规则都是结构性的Gmail 标签、List-Unsubscribe、日历部件、谁写的不做发件人/域名/主题/正文匹配因此无需维护厂商名单。关闭语义与排名线程循环在回复到达时确定性关闭承诺循环由gbrain loops done手动关闭或因过时自动关闭逾期 14 天且 14 天无活动或 90 天无任何活动 →stale。已关闭就是已关闭——只有真正更新的线程活动才能重开例行重扫永远不会复活你手动关闭的循环。对手方按未结循环数、截止日期临近度、最旧循环年龄和大脑内关联度backlink 数确定性排名——同样数据、同样顺序可审计、可复现。MCP 与命令面open_loops、loops_close、loops_mute、loops_unmute是 MCP 操作命令行面为gbrain waiting [--top N] [--json] [--stale-ok]、gbrain loops list|show|done|drop|mute sender|mute thread|unmute sender|unmute thread。远程调用open_loops时执行 fail-closed 证据脱敏计数、对手方、摘要、截止日期可见逐字引文、深链和可注入的text摘要仅限可信本地远程读写还需解析源作用域以匹配调用方的授权。日常操作契约、[SHOW USER]协议和成本诚实说明承诺提取会把最近 ≤30 天、每轮 ≤50 线程的邮件文本发送给已配置的 chat provider见 skills/google-loops/SKILL.md。五个陷阱Tricky Spots原文档总结了五个实践中最容易踩的坑前两条直接决定分诊质量先搜发送者再读邮件。反直觉但至关重要——大脑上下文优先加载意味着你在看到主题行之前就知道对方是谁、你们在共同做什么、他们关心什么。分诊因此是有信息的判断而非机械操作。没有大脑页面的未知发送者几乎总是噪声。如果gbrain search对某发送者一无所获他大概率不重要——除非邮件内容另有信号否则直接归为低优先级。会议准备是杠杆率最高的 EA 工作流。差异在于你 3 点有个会与你 3 点和 alice-example 有个会——上次你们讨论了 Series B她当时担心 burn rate。收件箱后的大脑更新是复利所在。每封邮件都是信号清空收件箱却不更新脑页信息就永久丢失——这是大多数代理跳过的步骤。日程提醒依赖时间线数据。你和 charlie-example 已经 6 周没见面只有在会议页面已按正确的实体传播摄入后才有依据见 skills/meeting-ingestion/SKILL.md。如何验证How to Verify原文档给出 5 条可逐项执行的验收步骤用于确认代理真的在按大脑上下文工作而非假装为明天的日历运行会议准备。对每位参会者确认代理在生成简报之前先执行了gbrain search并加载了其大脑页面。分诊 5 封邮件。确认代理在分类每封邮件之前先在大脑中搜索了每个发送者。清空收件箱后用gbrain get slug检查 2 个发送者的大脑页面确认已从邮件中添加了新的时间线条目。检查一条日程建议确认提醒中引用了参会者的大脑页面数据最近交互日期、未结线程。从一位有大脑页面的联系人发送一封测试邮件确认分诊回复引用了其关系上下文而不只是邮件内容。从哪里开始按依赖顺序走一遍即可跑通整个模式接入 Google 源gbrain google setup一键走完凭据 → 授权 → 源注册 → 首次预算同步 → 首个gbrain waiting摘要无头/SSH 环境自动切到 paste-back 模式多账户用--account email重复。完整流程、错误目录client_json_wrong_type、access_denied_test_user、invalid_grant_testing_expiry等 20 类型化错误及修复见 docs/guides/google-connect.md。运行循环引擎gbrain waiting --json查看排名后的谁在等你用gbrain loops done id关闭已处理项、gbrain loops mute sender email静音噪声发送者静音对两个检测器同时生效防止 LLM 通道为已静音发送者重建承诺。让内置技能开工briefing技能产出带[Source: slug, updated DATE]引文的每日简报含gbrain waiting --json折叠进 ACTION ITEMS 的真实循环行daily-task-prep技能产出按优先级的晨间准备在此基础上用本文的四个工作流做定制扩展。本模式是 GBRAIN_SKILLPACK.md 的一部分其完整生态连接器、循环引擎、会议摄入、简报与任务准备技能都在本仓库内可查证——从 src/core/google/ 的检测器实现到 test/google-loop-detect.test.ts、test/loops-extract-eligibility.test.ts、test/ops-loops.test.ts 的测试印证再到各技能 SKILL.md 的日常操作契约形成了一条从文档到实现再到验证的完整证据链。赞分享人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载相关推荐基于 awesome-codex-skills 的 Executive Review 会议准备实战Notion 上下文检索与 Codex 研究增强指南基于 awesome codex skills 的 Executive Review 会议准备实战Notion 上下文检索与 Codex 研究增强指南 季度高AI 技能AI 插件工作流自动化人工智能Executive AI Assistant 使用与启动指南Executive AI Assistant 使用与启动指南 1. 项目介绍 Executive AI AssistantEAIA是一个AI助手旨在完成执OpenProject 会议模块 FAQ 完全指南动态会议、经典会议迁移、日历订阅与邮件通知OpenProject 会议模块 FAQ 完全指南动态会议、经典会议迁移、日历订阅与邮件通知 导读 本文围绕 OpenProject 官方用户手册中的 Mee后端前端项目管理企业应用协同办公创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gbrain Executive Assistant 模式：用大脑上下文驱动的邮件分诊、会议准备与日程调度
人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载gbrain 的 Executive AssistantEA模式把邮件分诊、会议准备、日程调度从机械的收件箱操作升级为由大脑brain上下文驱动的智能工作流代理在读邮件之前先查发送者的大脑页面开会之前先加载每位参会者的关系历史安排日程时以 open-loop 引擎维护的谁欠我什么、我欠谁什么为真实数据源。读完本文你将掌握该模式的四个可落地工作流邮件分诊、会议准备、收件箱后的脑页更新、日程调度提醒理解其底层 open-loop 引擎的实现机制确定性线程状态机与 LLM 承诺提取器并得到一份可逐条执行的验证清单。模式目标从机械分诊到有上下文的判断本模式的核心主张是每一次与人的交互都应该被这段关系的完整历史所告知原文称之为 powered by brain context — so every interaction is informed by the full history of the relationship。没有本模式时代理机械地分诊邮件你有 12 封未读、用千篇一律的 LinkedIn 简介准备会议、在不了解关系上下文的情况下安排日程。有了本模式后代理在读邮件之前就知道每个发送者是谁在每次会议前呈现你们共同的过往历史并根据关系的温度relationship temperature和未结线程open threads来推动日程安排。这种差异不是体验层面的润色而是判断依据的结构性变化——分诊、简报、提醒的每条信息都来自大脑页面与 open-loop 行而非代理的临时猜测。架构基础本模式依赖的四个原生组件本模式的实现不要求手搓收件采集或线程跟踪它站在 gbrain 四个既有原生组件之上Google 连接器将 Gmail/Calendar/Contacts 摄入大脑全程只读gmail.readonly、calendar.readonly、contacts.readonly令牌只存在于本地凭据保险库~/.gbrain/credentials.json0600 权限采用自带 OAuthBYO OAuth模式。完整接入流程见 docs/guides/google-connect.md。Open-loop 引擎在 Google 源之上维护真实的循环行loop rows支撑gbrain waiting命令与open_loopsMCP 操作。下文中工作流里的context.open_threads正是由这些行支撑——每个实体卡片entity card按线程携带direction、due、loop_id字段。机制细节见 docs/guides/open-loops.md。google-loops 技能日常操作契约连接、gbrain waiting摘要、循环关闭/静音、故障排查集中在 skills/google-loops/SKILL.md。已内置的半个模式gbrain 已经把本模式的晨间简报一半打包为briefing技能skills/briefing/把任务准备一半打包为daily-task-prep技能skills/daily-task-prep/。本文下面的工作流用于扩展或定制这两个技能已经内置的行为而不是重复造轮子。值得注意daily-task-prep技能明确要求当存在 google 源时gbrain waiting --json是未接线程与未答复事项的真实数据源——它携带带对手方、截止日期和证据的循环行优先于散文式启发这与 EA 模式open-loop 行优于推断的原则完全一致。工作流 1邮件分诊Email Triage邮件分诊的黄金法则是先加载大脑上下文再读邮件正文。完整工作流如下来自原文档语义保持原样# WORKFLOW 1: Email Triage on email_batch(emails): # Step 0: Load the open-loop state FIRST — who is already waiting on you # (real loop rows: deterministic thread detector commitment extractor) waiting gbrain waiting --json # or the open_loops op over MCP # Refuses on stale google sources by design — run the sync it names first for email in emails: # Step 1: Search sender BEFORE reading the email body # Brain context makes triage 10x better sender_page gbrain search {email.sender_name} if sender_page: context gbrain get sender_slug # Now you know: who they are, relationship history, # what they care about, open threads # context.open_threads entries are backed by loop rows and # carry direction (owed_by_me/owed_to_me), due, loop_id # Step 2: Read the email WITH brain context loaded # Classification is now informed, not mechanical # Step 3: Classify with context if context.relationship inner_circle or sender in waiting.counterparties: priority urgent # theyre already waiting on the user elif context.is_known_entity: priority normal else: priority noise # unknown sender, no brain page # Step 4: Draft reply with relationship context if needs_reply(email): draft compose_reply( email, contextcontext, # their brain page open_threadscontext.open_threads, # loop-backed: whats owed, by whom, due when relationshipcontext.relationship # tone calibration ) # After the user sends a reply, the loop closes itself on the next # sync (closed_by: reply_detected); commitments close via # gbrain loops done loop_id关键操作点Step 0 的gbrain waiting --json这是整个模式的排名真相源默认跨大脑内所有源读取open-loop 行存在于 google 源而非default源默认作用域的读取会误报一切正常。它会在每个 google 源超过 24 小时无成功同步时拒绝输出并打印确切修复命令gbrain sync --source id因为过时但自信的输出比没有更糟——这是刻意设计详见 docs/guides/open-loops.md 的 surfaces 一节。Step 1 的先搜发送者原文档强调这是反直觉但至关重要的步骤——在看到主题行之前你就知道对方是谁、你们在共同推进什么、他们关心什么。分诊逻辑inner_circle关系或正在等你的对手方 →urgent已知实体 →normal无大脑页面的未知发送者 → 几乎总是noise见下文陷阱第 2 条。回信后的闭环用户发出回复后线程循环会在下一次同步时自行关闭closed_by: reply_detected承诺类循环则通过gbrain loops done loop_id手动关闭。工作流 2会议准备Meeting Prep会议准备是 EA 模式中杠杆率最高的工作流——用户走进每一场会议时已经对每位参会者完成了简报。完整流程# WORKFLOW 2: Meeting Prep on upcoming_meeting(meeting): briefing {} for attendee in meeting.attendees: # Search brain for each attendee results gbrain search {attendee.name} if results: page gbrain get attendee_slug briefing[attendee] { compiled_truth: page.compiled_truth, last_interaction: page.timeline[0], # most recent open_threads: page.open_threads, relationship_temperature: page.relationship, relevant_deals: gbrain call get_links {slug: attendee_slug}, } else: briefing[attendee] No brain page -- consider enriching # Surface: shared history, what to follow up on, what to watch for # Last time you discussed the Series B timeline. alice-example was # concerned about burn rate. Heres the latest from her company page.要点每位参会者的简报五件套compiled_truth编译真相、timeline[0]最近一次交互、open_threads未结线程、relationship关系温度、get_links相关交易/页面。覆盖缺口显式化没有大脑页面的参会者简报中明确写出 No brain page — consider enriching而不是假装认识对方。与内置技能的一致性briefing技能的 Phase 1 Todays meetings 采用完全相同的手法先gbrain search attendee name找到页面再gbrain get slug加载编译真相、近期时间线与关系上下文daily-task-prep技能则为每场会议产出参会者带大脑上下文 背景近期互动、未结线程 准备要点的上下文卡片。会议本身的摄入与实体传播由 skills/meeting-ingestion/SKILL.md 保证——这正是上次讨论 Series B 时 alice 担心 burn rate这类时间线数据的来源。工作流 3收件箱清空后的大脑更新Post-Inbox Brain Updates这是大脑复利的关键步骤也是大多数代理跳过的一步每封邮件都是信号清空收件箱而不更新脑页信息就丢了。完整流程# WORKFLOW 3: Post-Inbox Brain Updates on inbox_cleared(): for email in processed_emails: if email.contained_new_information: # Update the senders brain page with new signal gbrain timeline-add sender_slug {date} \ Email re: {subject}. Key info: {extracted_signal} \ --source email from {sender} re {subject}, {date} # Update any mentioned entity pages too for entity in email.mentioned_entities: gbrain timeline-add entity_slug {date} \ {what_was_said_about_them} \ --source email from {sender}, {date}操作要点只对包含新信息的邮件做更新email.contained_new_information作为筛选条件避免噪声刷屏。发送者页面和邮件中提及的其他实体页面都要更新——后者确保alice 的公司页里有她公司的最新动态这类跨实体引用成立。每个timeline-add都带--source溯源信息哪封邮件、哪个发送者、什么日期符合 gbrain 的证据纪律。工作流 4日程调度提醒Scheduling Nudges日程提醒不是拍脑袋而是以 loop 引擎的排名输出为数据源逐条核对每位参会者的页面状态。完整流程# WORKFLOW 4: Scheduling Nudges on schedule_request(meeting): # The ranked source of truth for who is owed what is the loop engine: waiting gbrain waiting --json # top counterparties, due dates, evidence for attendee in meeting.attendees: page gbrain get attendee_slug if page.last_interaction 6_weeks_ago: nudge(You havent met with {attendee} in {weeks} weeks) for thread in page.open_threads: # loop-backed entries if thread.direction owed_by_me: nudge(You owe {attendee}: {thread.summary} (due {thread.due})) else: nudge({attendee} owes you: {thread.summary} — worth raising in the meeting) if page.relationship_temperature cooling: nudge(Relationship with {attendee} may need attention) # When a nudge is resolved in the meeting, close it: # gbrain loops done thread.loop_id要点谁欠什么的排名真相源是 loop 引擎gbrain waiting --json排名靠前的对手方、截止日期、证据引文不是散文式推断。三种提醒各对应一类页面数据时间间隔6 周未见面来自page.last_interaction依赖会议页面已按正确的实体传播摄入方向性债务owed_by_me/owed_to_me来自 loop-backed 的open_threads带due日期关系温度cooling来自page.relationship。提醒在会议中解决后用gbrain loops done thread.loop_id关闭对应循环。底层原理open-loop 引擎如何支撑context.open_threads工作流中的waiting.counterparties、context.open_threads、direction/due/loop_id不是占位概念而是 docs/guides/open-loops.md 中 open-loop 引擎open_loops表的真实数据。它由两个检测器构成1. 确定性线程状态机src/core/google/loop-detect.ts零 LLM、免费、始终开启。对每条已同步的 Gmail 线程最后一条实质消息是对方的、你在收件人To:中、未答复 ≥24h →unanswered_inbound对方在等你。最后一条实质消息是你的、含问句、未答复 ≥72h →unanswered_outbound你在等对方。回复到达 → 循环自行关闭closed_by: reply_detected。循环靠状态转换关闭从不删除——审计轨迹保留。从源码看loop-detect.ts该检测器与google-render.ts导出的isNoiseSender、isCalendarSystemMail协同工作噪声发送者、列表邮件List-Unsubscribe、纯日历系统邮件永远不开环。特别地Google Calendar 的系统通知Invitation:、Accepted:、Declined:、Canceled event:等由日历代表人类发出、来自同事真实地址因此用 iCalendarMETHODRFC 5546 的REQUEST/REPLY/CANCEL等结构识别而非按发件人识别——它们既不开启也不关闭循环邀请不是回复让它翻转回合会静默回答真实的 outbound 循环但照常摄入为可搜索页面并喂给日历/会议上下文。精度规则由 test/google-loop-detect.test.ts 的标记化 fixture 语料固定——每个误报类别在修复前都要先有对应 fixture。2. LLM 承诺提取器src/core/google/loops-extract.ts每条近期线程一次模型调用google 源默认开启。提取带方向的承诺我周五前把 deck 发你 →commitment_owed_by_me对手方、截止日期、逐字引用与待决决策。每个条目有三个投影open_loops行本身一条facts行kindcommitmentfence-first、去重让entity/context_pack/recall通过既有读路径看到一条类型化边线程页 → 人物页owes_to/awaiting_reply_from供关系检索遍历。护栏包括注入加固模型只见线程最新 12k 字符、全有或全无的解析屏障、只提取最近 30 天邮件、以及开关gbrain config set loops.extraction_enabled false。结构性资格门槛loopExtractionEligibility先于提取器运行让批量邮件既不为模型调用付费、也不挤占真实往来详见 docs/guides/open-loops.md邮件形态是否进入提取SPAM/TRASH否无论谁写的账户主人写了实质消息SENT标签或已知主人地址日历 RSVP 等噪声不计是覆盖以下所有规则纯噪声发送者 / 纯日历通知否CATEGORY_PROMOTIONS/SOCIAL/FORUMS否除非主人参与List-Unsubscribe批量邮件否除非主人参与CATEGORY_UPDATES是—— 发票、合同、文档请求都在这里普通人际往来是主人参与是承重规则你自己的外发消息正是承诺所在所以写在批量标签线程回复里的我周五前发给你依然可被提取。所有规则都是结构性的Gmail 标签、List-Unsubscribe、日历部件、谁写的不做发件人/域名/主题/正文匹配因此无需维护厂商名单。关闭语义与排名线程循环在回复到达时确定性关闭承诺循环由gbrain loops done手动关闭或因过时自动关闭逾期 14 天且 14 天无活动或 90 天无任何活动 →stale。已关闭就是已关闭——只有真正更新的线程活动才能重开例行重扫永远不会复活你手动关闭的循环。对手方按未结循环数、截止日期临近度、最旧循环年龄和大脑内关联度backlink 数确定性排名——同样数据、同样顺序可审计、可复现。MCP 与命令面open_loops、loops_close、loops_mute、loops_unmute是 MCP 操作命令行面为gbrain waiting [--top N] [--json] [--stale-ok]、gbrain loops list|show|done|drop|mute sender|mute thread|unmute sender|unmute thread。远程调用open_loops时执行 fail-closed 证据脱敏计数、对手方、摘要、截止日期可见逐字引文、深链和可注入的text摘要仅限可信本地远程读写还需解析源作用域以匹配调用方的授权。日常操作契约、[SHOW USER]协议和成本诚实说明承诺提取会把最近 ≤30 天、每轮 ≤50 线程的邮件文本发送给已配置的 chat provider见 skills/google-loops/SKILL.md。五个陷阱Tricky Spots原文档总结了五个实践中最容易踩的坑前两条直接决定分诊质量先搜发送者再读邮件。反直觉但至关重要——大脑上下文优先加载意味着你在看到主题行之前就知道对方是谁、你们在共同做什么、他们关心什么。分诊因此是有信息的判断而非机械操作。没有大脑页面的未知发送者几乎总是噪声。如果gbrain search对某发送者一无所获他大概率不重要——除非邮件内容另有信号否则直接归为低优先级。会议准备是杠杆率最高的 EA 工作流。差异在于你 3 点有个会与你 3 点和 alice-example 有个会——上次你们讨论了 Series B她当时担心 burn rate。收件箱后的大脑更新是复利所在。每封邮件都是信号清空收件箱却不更新脑页信息就永久丢失——这是大多数代理跳过的步骤。日程提醒依赖时间线数据。你和 charlie-example 已经 6 周没见面只有在会议页面已按正确的实体传播摄入后才有依据见 skills/meeting-ingestion/SKILL.md。如何验证How to Verify原文档给出 5 条可逐项执行的验收步骤用于确认代理真的在按大脑上下文工作而非假装为明天的日历运行会议准备。对每位参会者确认代理在生成简报之前先执行了gbrain search并加载了其大脑页面。分诊 5 封邮件。确认代理在分类每封邮件之前先在大脑中搜索了每个发送者。清空收件箱后用gbrain get slug检查 2 个发送者的大脑页面确认已从邮件中添加了新的时间线条目。检查一条日程建议确认提醒中引用了参会者的大脑页面数据最近交互日期、未结线程。从一位有大脑页面的联系人发送一封测试邮件确认分诊回复引用了其关系上下文而不只是邮件内容。从哪里开始按依赖顺序走一遍即可跑通整个模式接入 Google 源gbrain google setup一键走完凭据 → 授权 → 源注册 → 首次预算同步 → 首个gbrain waiting摘要无头/SSH 环境自动切到 paste-back 模式多账户用--account email重复。完整流程、错误目录client_json_wrong_type、access_denied_test_user、invalid_grant_testing_expiry等 20 类型化错误及修复见 docs/guides/google-connect.md。运行循环引擎gbrain waiting --json查看排名后的谁在等你用gbrain loops done id关闭已处理项、gbrain loops mute sender email静音噪声发送者静音对两个检测器同时生效防止 LLM 通道为已静音发送者重建承诺。让内置技能开工briefing技能产出带[Source: slug, updated DATE]引文的每日简报含gbrain waiting --json折叠进 ACTION ITEMS 的真实循环行daily-task-prep技能产出按优先级的晨间准备在此基础上用本文的四个工作流做定制扩展。本模式是 GBRAIN_SKILLPACK.md 的一部分其完整生态连接器、循环引擎、会议摄入、简报与任务准备技能都在本仓库内可查证——从 src/core/google/ 的检测器实现到 test/google-loop-detect.test.ts、test/loops-extract-eligibility.test.ts、test/ops-loops.test.ts 的测试印证再到各技能 SKILL.md 的日常操作契约形成了一条从文档到实现再到验证的完整证据链。赞分享人工智能RAGAgent 记忆MCP 服务知识管理【免费下载链接】gbrainGarrys Opinionated OpenClaw/Hermes Agent Brain项目地址https://gitcode.com/gh_mirrors/gb/gbrain点击查看免费下载相关推荐基于 awesome-codex-skills 的 Executive Review 会议准备实战Notion 上下文检索与 Codex 研究增强指南基于 awesome codex skills 的 Executive Review 会议准备实战Notion 上下文检索与 Codex 研究增强指南 季度高AI 技能AI 插件工作流自动化人工智能Executive AI Assistant 使用与启动指南Executive AI Assistant 使用与启动指南 1. 项目介绍 Executive AI AssistantEAIA是一个AI助手旨在完成执OpenProject 会议模块 FAQ 完全指南动态会议、经典会议迁移、日历订阅与邮件通知OpenProject 会议模块 FAQ 完全指南动态会议、经典会议迁移、日历订阅与邮件通知 导读 本文围绕 OpenProject 官方用户手册中的 Mee后端前端项目管理企业应用协同办公创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考