AegisBrain 为编程代理补记忆并分流生成任务

AI 编程助手换个会话就忘记架构约定，找回记忆又要翻大量日志；生成重复代码时，还在消耗高价模型的 token。作者为这两个问题做了 AegisBrain：把关键决策存进本地索引，再让云端强模型与本地模型分工。

这套方案的价值，在于把记忆检索、任务分流、代码验证和配置回滚串起来。作者给出了毫秒级检索和数百 token 的上下文开销，但这些数字能说明多大范围的问题，还得看测试条件。

找回项目约定，为什么要重读整段聊天

作者使用 Claude Code、Gemini CLI、Cursor 和 Antigravity 时，反复遇到上下文遗忘。他描述的典型情况是：新会话或上下文压缩后，助手需要遍历数 MB 的 JSONL 会话记录，消耗 40k–60k tokens，才能找回架构决策、规则和必须保持的约束。

AegisBrain 的做法，是提前把决策、代码定位信息和约束存入本地 SQLite。检索使用全文搜索扩展 FTS5，配合 Porter stemmer 做词干归一化，数据库运行在 WAL 模式。

助手通过 aegis recall 查询索引，再获得一份确定性的摘要。原文没有给出完整参数示例，也没有解释摘要的具体生成规则。

真正减少上下文开销的，是提前筛选并保存值得记住的信息。

作者将这项能力标为低于 25ms，在 NVMe 上报告约 18ms 的查询延迟；文末又列出本地 SSD 上约 18.2ms，对照未建索引的日志解析为 8,500ms 以上。注入 ACTIVE_CONTEXT.md 的内容约为 350 tokens，能力描述中的上限是低于 400 tokens，对照完整日志遍历的 50,000+ tokens。

这里需要区分：查询索引很快，不等于找回的上下文一定正确。原文没有交代记忆如何写入、过期决策如何清理，也没有给出检索命中率。这些环节会直接决定助手是否拿着旧约定继续工作。

哪些代码值得交给本地模型

作者把任务分成两种模式，避免所有工作都经过委派。

Quick Mode 面向单行修改、拼写修复和直接结对编程，由前沿模型直接处理，省掉任务转交的延迟。Arbitrage Mode 则面向大量样板代码和跨文件测试套件：前沿模型规定架构约束，本地 Tier 3 worker 负责生成代码草稿，通过 Ollama 或 Hermes CLI 执行。

文中列举的本地模型包括 Qwen 2.5 Coder 7B/14B 和 Hermes。DTO、重复代码和单元测试套件，是作者希望转移出去的主要工作。

这里的「token 套利」指的是任务分工：把需要判断的部分留给强模型，把重复生成放到本地。作者称本地生成免费，更准确的理解是省去对应的前沿模型 API 费用；硬件、运行时间和维护仍然有成本。

这个方向成立的前提，是任务能够被清楚描述，而且结果容易验收。原文没有给出两种模式的自动切换规则，也没有展示节省金额、草稿通过率或端到端耗时，所以暂时无法判断委派到多大规模才划算。

本地草稿进入工作区前，要过哪些关

便宜地生成代码只是前半程。作者要求候选草稿进入宿主工作区前，通过四道自动验证：

1. Karpathy Simplicity Doctrine 阻止推测性的包装层和多余抽象。
2. Unslop Filter 去掉聊天套话和模型生成的开场白。
3. AST Security Scanner 基于抽象语法树检查危险调用，例如 shell=True 和未经净化的命令插值。
4. Dual-Environment Verification 在隔离沙箱中编译并运行单元测试，通过后再应用到宿主环境。

四道关卡的可验证程度并不相同。编译和测试有明确结果；「多余抽象」如何判定，原文没有说明。AST 扫描能够针对已知危险模式设防，但扫描覆盖哪些语言、能否追踪跨函数的数据流，也没有交代。

AegisBrain 还在修改 GEMINI.md、CLAUDE.md、.cursorrules 等配置前创建恢复快照。执行 aegis restore 可以查看带时间戳的历史点，并单键回滚。作者宣称恢复后零残留，不过没有提供恢复边界和验证方式。

后台是运行在 127.0.0.1:8765 的异步本地 HTTP daemon，提供健康检查、调度，以及可选的 Telegram 远程状态查询桥接。作者报告其 RSS 内存约 35 MB，空闲 CPU 低于 0.1%。

这些机制让助手的操作可以检查，也可以撤回。

我的判断

我认可优先压缩有效记忆、再分配生成任务的思路。对长期维护的项目，明确保存架构约定，比每次期待助手从聊天记录里重新推断更可控。小修改直接完成、大批重复任务再委派，也符合减少调度成本的直觉。

但作者提供的是项目能力描述和局部性能数字，没有完整的对照实验。18.2ms 对 8,500ms+ 比较的是索引查询与未索引日志解析，输入范围和输出信息量未必相同，不能据此推导整个编程流程提速多少。

普通团队还可以先采用更简单的办法：把稳定约定写进项目文档，配合版本控制、现有检查脚本和测试。需要按任务动态检索大量历史决策时，本地索引才更有吸引力；需要频繁批量生成代码时，本地 worker 才可能抵消额外维护成本。

这套架构值得借鉴，但省钱与提效仍需端到端数据验证。

项目以 GPLv3 开源。原文没有说明各项关卡的实现细节，也没有证据证明它们已经覆盖一般团队的复杂仓库，因此更适合作为可评估的工程方案，而非已经验证的通用答案。

能拿来做什么

• 在前端或 Node 项目中，先整理一份简短的架构约定，记录目录职责、接口边界和不能破坏的规则，让新会话优先读取，并及时删除失效内容。
• 挑一类重复生成任务试验分工，例如 DTO 或多文件单元测试；让强模型先写清约束，再比较本地模型与直接生成的总耗时、返工量和 API 开销。
• 将草稿验收接入已有的编译与测试流程，并在隔离环境运行；修改 AI 助手配置前保留可恢复版本，同时实际验证一次恢复结果。