记忆系统需要压缩管道

双层记忆的思路是：关键信息放 bootstrap（每次对话都带上），其余放语义搜索按需检索。策略清晰，但缺了维护机制。

实际运行中会遇到两个退化：

  • bootstrap 文件越塞越大——因为你总觉得"这条也挺关键"，结果 token 成本线性增长
  • 日志越积越多——语义搜索的噪音增大，检索质量持续下降

解法是加一条压缩管道：

  • 每天用 cron 自动扫描当天的 raw log
  • 按 10:1 的比例压缩，只提取可执行的 insight，格式统一为："遇到 X 问题 → 用 Y 方案解决（具体命令）"
  • 流水账、重复记录、过程细节全部归档，不参与检索
  • 压缩产出写入 insights/ 目录，语义搜索只索引这个目录

在此基础上再加一层过期机制，按优先级区分保留时长：

  • P0：永不过期（核心规则、系统约束）
  • P1：保留 90 天（项目级决策、架构选型）
  • P2：保留 30 天（临时记录、调试日志）

优先级由 Agent 自己判断。没有这条管道，双层架构就是一个会慢性膨胀的系统——不是能不能用的问题，是几周后 token 消耗和检索质量会逼你做一次痛苦的重构。

工具层不只是"能调用"，还要能运营

基础工具通常包括 exec、browser、file、message、memory 五类，再加 cron 做定时任务。但实际用起来，工具层还需要三样东西。

持久化任务系统

Agent 执行复杂任务时，最常见的事故是：跑到一半，context 被压缩，任务进度直接丢失。

解法是用文件系统做持久化——在 .issues/active/ 目录下，每个任务对应一个 markdown 文件，记录目标和当前进展。context 丢了没关系，文件还在。如果需要 spawn sub-agent 执行子任务，强制要求"双向更新"：每完成一步写回 issue 文件，不依赖 session 记忆。这个设计很实用，等于给 Agent 装了一个不会被 context window 吞掉的外部记事本。

门禁层

exec 开到 full 模式像敞开大门，sandbox 模式又太受限。中间方案是写一个 gate 门禁脚本：删除操作、交易操作、核心文件修改——这些高风险动作在执行前必须过门禁检查，不通过就拦截。这不是限制 Agent 的能力，而是给危险操作加一道确认环节。对一人公司来说尤其重要，因为没有同事帮你兜底。

cron 要设计成协同系统

一个定时任务不叫自动化，多个 cron 互相咬合才是。实际运行中通常需要这几个协同运转：

  • issue-dispatcher：每 30 分钟扫描待办任务并分发执行
  • todo-scanner：每天扫描代码中的 TODO 注释，自动转为 issue
  • memory-compounding：凌晨执行日志压缩（就是前面说的压缩管道）
  • anomaly-detector：持续检测异常并尝试自修复

这些串起来，Agent 才是一个能自己跑的系统，而不是一个定时查邮件的 bot。

写在最后

骨架搭起来确实是第一步，但从"能跑"到"能一直跑不烂掉"，中间隔着的就是这些运营管道。记忆压缩解决的是成本和质量退化问题，持久化任务解决的是 context 丢失问题，门禁层解决的是安全边界问题，cron 协同解决的是"真正自主运行"的问题。如果你正在搭建自己的 Agent，建议骨架跑通后立刻补上压缩管道和持久化任务系统——这两个是最先会咬你一口的。