【Agent Harness实战】我给我的Agent系统请了八个“保洁阿姨”，让AI自己整理自己
我给我的Agent系统请了八个“保洁阿姨”，让AI自己整理自己
之前聊了流马的记忆、技能、工具、门禁…… 但有一个问题我一直没正面回答：
系统跑久了，技能图谱会乱、知识碎片会散、记忆会膨胀、失败模式会堆积。谁来收拾？
指望开发者手动整理？那还不如不搞自动化。
指望LLM主动整理？它连自己昨天说过什么都不记得。
所以，我决定请一批“保洁阿姨”——专门负责后台整理的 Batch Agent。她们不参与前台任务，只在系统空闲时默默打扫。而且最妙的是，我只写了一套框架，就生出了八个不同职能的阿姨。
一、整理这件事，为什么不能靠“一个Prompt”搞定？
你可能会说：“让LLM定期总结一下技能图谱，给个优化建议，不就行了？”
试过，不行。因为这不是“一个任务”，而是八个完全不同维度的整理需求：
- 两个技能太像了，要不要合并？（技能合并）
- 昨天那个报错，根本原因是什么？（失败模式挖掘）
- 这两个实体其实是一个东西吧？（实体解析）
- 这个技能最近成功率暴跌，是不是该修了？（技能健康巡检）
- 知识碎片堆了上百条，哪些该提炼成正式知识？（知识碎片提炼）
- 历史记忆太多，哪些可以压缩归档？（记忆整合）
- 技能之间有些没被发现的关联，能自动推荐吗？（链路推荐）
- 这些整理模板本身效果怎么样？（模板效果分析）
如果用一个大Prompt让LLM一次搞定全部，结果一定是：什么都会一点，什么都做不精。而且每次调用都把所有数据喂进去，Token费用直接爆炸。
二、“模板即角色”——八个阿姨，一套框架
流马的做法是：不同整理任务 = 同一个框架 + 不同配置 + 不同模板。
框架只做五件事：
- 等时机（定时触发 / 事件触发 / 手动触发）
- 攒素材（滑动窗口收集相关数据）
- 喂模板（把数据填入对应角色模板，发给LLM）
- 收结果（解析LLM返回的JSON）
- 写入库（把结果写回技能图谱或知识库）
八个角色的差异只有两点：模板文件（告诉LLM分析什么）+ 结果处理器（分析完了怎么存）。其余全部复用。
这意味着：加一个新角色，只需要写一个模板文件、加一行配置、写一个结果处理函数。不改框架代码，不加新模块，不重新编译。
举个例子。假设产品经理说：“能不能每周检查一下技能描述是不是过时了？”
我的操作：
- 写一个模板文件
description_stale_check.md，告诉LLM“对比技能描述和最近使用情况，判断是否过时” - 在配置文件里加一行
- name: description_stale_check_agent, schedule: "每周一早6点" - 写一个结果处理器：LLM判断过时且置信度>0.8 → 自动更新技能描述
搞定。十分钟上线一个新整理角色。
三、这八个阿姨具体干什么？
阿姨1号：技能合并专家
每2小时巡逻一次。发现两个技能语义太像（比如“Python数据分析”和“Pandas数据处理”），自动分析相似度，建议合并策略。置信度>0.85的直接合并，中等置信度的送进“人工确认队列”。
阿姨2号：知识碎片提炼
把CA Agent标记的“失败记录”提炼成结构化的经验知识。比如“数据清洗时缺失值超30%会导致均值填充偏差”这种碎片，自动加上根因分析、泛化场景、关联技能，升级为正式知识节点。
阿姨3号：实体解析
新抽取的实体（比如“张三”），自动去知识图谱里找同名或相似的实体，判断是不是同一个人。是同一个？自动合并。不确定？标记冲突，等人工裁决。
阿姨4号：失败模式挖掘
每30分钟拉取最近的失败事件，按错误码分组统计，识别趋势。“这个错误最近3小时出现了15次，而且还在增长”——自动生成告警节点，挂到相关技能上。
阿姨5号：技能健康巡检
每5分钟扫描一遍技能图谱。成功率低于60%？标记为D级。依赖链断裂？记录问题。自动生成健康报告，高优先级的直接送进人工确认队列。
阿姨6号：记忆整合压缩
每天凌晨3点执行。把7天前的旧对话摘要压缩归档，重复内容去重，低访问条目评估是否保留。不是简单删，而是“该归档的归档，该提炼的提炼，该删的删”。
阿姨7号：链路推荐
每30分钟分析一次技能之间的“潜在关系”。两个技能经常被一起调用？标签高度相似？自动推荐建立关联链接。置信度高的直接加上，中等的送审。
阿姨8号：模板效果分析
统计每个整理模板的成功率、平均置信度、失败原因。“skill_merge模板最近解析失败率上升了15%，原因是LLM输出的JSON格式变了”——这种洞察自动生成报告，供开发者优化模板。
四、架构收益：让系统学会“自己整理自己”
| 维度 | 没有Batch Agent | 有Batch Agent |
|---|---|---|
| 技能图谱维护 | 靠开发者手动合并、更新 | 自动合并、自动巡检、自动建议 |
| 失败经验复用 | 失败就失败了，下次还犯 | 自动挖掘模式、提炼知识、关联技能 |
| 实体一致性 | 同名不同人、同人不同名，混乱 | 自动解析、合并、标记冲突 |
| 记忆管理 | 无限膨胀，Token费用飞涨 | 自动压缩归档，冷热分离 |
| 系统智能性 | 静态，只会执行不会进化 | 持续自我优化，越用越聪明 |
五、风险与兜底
这套设计有个核心原则：高置信度的自动执行，中低置信度的必须人工确认。
- LLM判断合并置信度0.9？自动合并。
- 0.7？送人工确认队列。
- 0.5？丢弃。
记忆压缩也一样：先标记删除，观察7天，再物理删除。绝不直接删数据。
六、最后说句人话
流马的Batch Agent，本质上是给AI系统装了一套“新陈代谢系统”。
生物体靠新陈代谢排出废物、修复损伤、更新细胞。AI系统也需要同样的机制——技能会过时、知识会冗余、记忆会膨胀、错误会重复。没有新陈代谢的系统，跑得越久越臃肿，最终一定会腐化。
这八个“保洁阿姨”，就是流马的新陈代谢。她们不参与前台任务，不抢Agent的风头，但她们在后台默默保证：这个系统，不会腐烂。
我这套系统叫Gliding Horse（流马），所有代码都在 GitHub 上：https://github.com/doiito/gliding_horse
这个系列写到第14篇了。从最开始的JSON-LD选型，到CPU缓存记忆，到丰田安灯绳，到硬核门禁，到八大保洁阿姨…… 每一篇都是我在构建流马过程中真实踩过的坑和做过的选择。如果你也在思考AI Agent的工程化落地，希望这个系列能帮你少走一些弯路。