内容怎么进 brain：gbrain 在你不知情时替你挡住的脏东西

你开始往 brain 里塞东西了——手写的笔记、定时抓来的新闻、转写好的会议录音。很快会冒出一个疑问：这些来源良莠不齐，抓网页抓到 CAPTCHA 拦截页怎么办？一篇三万字的网页把向量库撑爆怎么办？每次加一种新内容类型，是不是都得改引擎底层？

gbrain 对「内容入口」的处理，最值得一个使用者记住的只有一句话：所有路最终汇到一处，入库前先过一道廉价的质检，真正聪明的能力写在你能改的技能文件里、不在引擎里。

一、千条路，一个关口

不管内容从哪来——命令行手动加、文件导入、webhook 推送、还是定时 recipe 抓取的推文——它们最终都收束到同一个写入函数 importFromContent¹。这像城市的自来水：无论水库、河水、地下水，进你家前都过同一道水厂。

为什么要这样设计？因为去重、可读性校验、隐私剥离、schema 写入这些「必须每次都做对」的事，如果分散在十个入口，就总有漏网的。收束到一处，质检逻辑只写一次、只维护一处。你作为使用者不需要知道这些，但你能感受到的结果就是：从任何渠道进来的内容，享受的是同一套把关。

二、入库前，它先替你挡掉垃圾

想象你让 agent 自动抓全网新闻进 brain。抓回来的不全是干净文章——有反爬拦截页、有排版炸裂的网页、有三万字的长文。gbrain 在写入前跑一个叫 assessContentSanity 的廉价质检（成本固定，不随页面变大而变），三档处置²：

• 高置信垃圾（CAPTCHA 页、Cloudflare 拦截页这类）—直接 quarantine 或拒绝，根本不进检索。
• 标记很脏但仍可读（markup 比例过高）—正常写入、照样能搜，但打个 content_flag 脏标记，提醒你「这页可能排版稀烂、结果仅供参考」。
• 超长超大—照写，但标 embed_skip，跳过向量化，免得一篇巨文把向量库撑爆、拖累所有检索速度。

使用者几乎感知不到这套机制，但它解决的是真实痛点：脏数据如果在入库前没收口，就会悄悄污染你之后的每一次检索结果。gbrain 把这道关放在你视线之外。

三、引擎很瘦，本事写在技能里

这里有个反直觉、但影响你长期使用成本的设计哲学：gbrain 的引擎（harness）刻意做得越瘦越好，真正的能力都写在「技能」里³。

技能是一份 markdown 文件，教模型「怎么做一件事」的流程，而不是替它「做什么」。比如你想加一条「新抓来的公告自动分类」的本事，你不是去改引擎代码，而是写一份 SKILL.md 描述流程。引擎只提供通用工具（读写 brain、搜索、抽取），具体任务怎么干由技能决定。

为什么这对你有关系？因为你的场景会一直变。今天抓新闻，明天接邮件，后天分析财报。如果每种能力都焊死在引擎里，你每加一样就得动底层；而「瘦引擎 + 胖技能」意味着能力可以像写笔记一样长出来，不用碰核心。一个想造类似工具的人，这条取舍最该抄：把不可复用的智能留在可编辑的技能层，把稳定的基础设施压到最薄。

四、agent 怎么知道该用哪个技能

当你用 agent 操作 brain，它每次接到任务，先读一张叫 RESOLVER.md 的路由表，把你的意图映射到对应的技能文件[^路由表（resolver）]。比如你说「整理一下我的 resolver」，它就知道自己该调哪个技能。对使用者而言，这层是透明的——你只管下指令，路由的事 agent 自己查表解决。

五、这一课带走的

• 所有内容入口汇到 importFromContent 一处，统一的把关。
• 入库前 assessContentSanity 替你挡垃圾、标脏页、跳过超大页的向量化——你不用操心脏数据污染检索。
• 引擎保持瘦，新能力写成技能文件就能加，不用改核心。
• 想自动抓新闻/公告，底层都走这条窄腰，一处质检全局受益（抓取守护进程的细节属于维护者视角，使用者知道「都收口到一处」即可）。

练习题

参考出处