夜雨聆风我用一天时间，把 7 个 Agent 从 1000 行瘦身到 273 行的真实记录
一、起因：我就是懒
我有 7 个 AI 助手。
不是想炫耀，是贪心。看到一个新的场景就想搭一个 Agent：写文章的、做分析的、教东西的、搞测试的……陆陆续续攒了 7 个。
但维护起来越来越痛苦。
每个助手都有一个叫 SOUL.md 的核心指令文件，加起来 1068 行。每次要改一个地方，得 7 个文件都改一遍。改完还要重启测试，烦到不想碰。
说实话——我就是懒，才想改的。
不是技术追求，不是方法论驱动，就是懒得维护了。我想让它们自己能搞定，别天天烦我。
二、改造前：它们很”死”
改造前是什么状态？
你叫它写一篇文章，它就真的只写一篇文章。不会问你”给谁看？发在哪？什么风格？”
你叫它分析一个方案，它就列一堆要点，不分轻重。不会结合你的实际情况判断哪个方向更靠谱。
像那种只会点头的实习生——你说啥他记啥，但永远差一步。
7 个助手，每一个都这样。
三、怎么改的
核心思路就一句话：把 1000 行的”死指令”，变成一套按需加载的”活规则”。
第一步：SOUL.md 瘦身
以前 SOUL.md 里什么都有——身份定义、回复规则、写作规范、记忆要求、技术栈说明……全部塞在一个文件里。
改了之后，SOUL.md 只保留最核心的东西：身份、原则、反幻觉规则。其他所有具体规范，拆到单独的文件里，用到才加载。
比如写方案的时候才加载方案规范，要交付了才加载交付检查清单。
第二步：Harness/Gate 机制
我把任务类型分了几类，每一类配一个”门”：
任务类型 | 门文件 | 作用 |
需要做方案 | gate-01-plan.md | 先确认需求再动手 |
需要对外交付 | gate-03-delivery.md | 交付前自检清单 |
需要找能力 | skill-routing.md | 自动匹配对应的技能 |
助手接到任务时，先看任务类型，自动加载对应的门文件。不会像以前一样，所有规则都压在脑子里。
第三步：批量改造 7 个实例
第一个助手花了半天设计这套结构。剩下 6 个——批量复制改参数。
每个实例的改造模式完全一样： 1. 瘦身 SOUL.md（只保留核心） 2. 加 1 个 Harness + 1-2 个规则文件 3. 配置文件指向路径
实例 | 改造前线数 | 改造后线数 | 减负 |
101 学姐助手 | 300 行 | 47 行 | -84% |
101 知识库助手 | 101 行 | 38 行 | -62% |
156 写作助手 | 107 行 | 29 行 | -73% |
156 分析助手 | 102 行 | 29 行 | -72% |
156 编程助手 | 98 行 | 29 行 | -70% |
156 通用助手 | 86 行 | 26 行 | -70% |
108 测试平台 | 73 行 | 31 行 | -58% |
总计 | 868 行 | 229 行 | -74% |
注：表格只计核心改造的 7 个，不含本机，全站总计 1068→273 行。
四、改造后：它们”活”了
改造后的第一个变化是：它们会帮我考虑问题了。
以前说”写一篇关于 Agent 改造的文章”，它就列提纲、写内容，完事。
现在它会先反问： - 这篇文章的目标读者是谁？ - 发在公众号还是小红书？ - 风格要技术向还是经验向？ - 要不要加数据表格？
它会主动想这些，不是因为我写了规则让它问——而是因为我拆掉了”死指令”，给它留出了判断空间。
第二个变化：我不用再 7 个文件一个个改了。改核心规则只需要改一处，其余自动继承。
五、不是越多越好，是越精越好
回到开头。
7 个助手听起来很多。但 1068 行的核心文件说明一个道理：你堆的规则越多，它越笨。
真正聪明的做法不是加规则，而是减规则。让每一个助手只记住它必须记住的，剩下的按需去找、去判断、去学习。
AI 助手不是越多越好，是越精越好。
如果你也在维护多个 Agent，可以试试这个思路：
1.SOUL.md 只放核心身份和原则，所有具体规范拆到单独文件
2.按任务类型设置”门”，写方案才加载方案规范
3.批量改造，第一个设计好框架，剩下的复制改参数
你可能发现自己也养了一堆”实习生”，该给它们减减负了。
