AI思考4月
总结一下最近优化AI系统的几个重要经验
AI自我认知系统
总结一个核心原则：要优化一个系统，先要维护一个系统的最新认知，AI需要知道自己是什么，人也需要知道系统最新情况，才能去优化。
在实际工作中，会有非常高比重的时间，在优化AI系统本身，虽然有记忆系统，但发现很多细节不牢靠，比如说改个端口，路径之类的，虽然说了要所有地方都改，全量扫描之类的，实际上经常出现隐藏在角落里的文件没改。因为记忆系统根本也不会存这种细节。我思考了一下，这种东西，本也不应该存在记忆系统，只会让记忆系统无端膨胀。另外还有个痛点，AI系统在不断迭代，AI系统自身的信息是一个很庞杂的东西了，有多少agent，skill，plugin这些都是基础，更重要的是互相间的依赖关系，哪个配置项被哪些文件引用等，如果没有一个好的自我认知系统维护，改也是乱改。还有，版本管理虽然早就做了，但是并不方便AI提取和人来阅读。
做的思路也简单，分成五层数据源，不存记忆，专门独立维护：
纯事实层，专门保存有哪些 Agent/Skill/Plugin，入口路径、端口、脚本位置等等，随时整体覆盖来更新
语义知识层，每个组件干啥的知识卡，影响矩阵：改X会影响Y，配置台账：配置项→引用文件清单，validate 校验，让AI 写入时有约束。
历史记录层，每次修改自动追加changelog，不覆盖。
运行时探测层，运行时检查自身各个服务，插件是否在正常运行，包括配置是否正常，改了自我后有没有及时更新等。
视图层，一个自动合成的md文件，给AI和人类直接读。
meta安全模式
和自我认知系统强相关，涉及到AI系统自身的修改优化，一旦乱来，改出问题，搞崩了opencode，就只能cursor来救（你别说，cursor修起来还又快又好。。。），于是设计了一个meta安全模式：
除了语义判断，当检测到要改任何我定义的保护路径，强制进入这个模式，进入后使用专门的模版，强制读自我认知系统里的组件知识卡和影响矩阵，并且列文件清单和评估影响范围，影响超过3个组件就暂停要求确认。
然后，执行层加入一些防bash卡死的手段。
然后，最重要的是一个专门的meta验证系统，验证会额外进行路由一致性和触发表完整性验证，并针对做的改动，分析代码，自动推断”这次改动应该产生哪些可观测效果”，写入文件。然后派发真实任务，用写的追踪工具捕获 plugin hook 的真实调用，而非 AI 自报（这点很重要，相信让AI直接做测试的小伙伴都有感触，AI有时候会掩盖问题，或者说倾向快速结束任务）。最后产出四种结果，通过，失败，无法确定，通过但有警告，供我判断。
记忆管理
记忆分区，随着记忆库逐渐变大，rag虽然还没出什么问题，但考虑未来，全部记忆都是全局记忆，AI取记忆噪音会太大，人维护起来也不方便，所以重构了一下，从全局的原则/经验/反模式/对话/决策等分区方法，改为保留全局，但额外细分场景，不同场景不同的内部分区方式，例如设计，代码，调研等场景，都分开，里面的分区方法都独立，例如调研里面，分区是调研专属的：调研原则，调研结论，信源质量库，调研方法，调研反模式。其他同理，每个特定场景分区方法都不一样，通用的是原则和反模式这两个都有。然后取记忆的时候，根据不同agent的职能，取全局+特定场景的记忆即可，未来，可以随时细分，随时增加新的场景，这样可以有效控制记忆的规模。当然，这里的原则是全局记忆始终需要保持精简，全局记忆是所有场景都需要的才放进来，例如，设计，代码都需要的某个记忆，宁愿设计代码场景里分别存一份，也不要放全局。
工作记忆重构
之前专门维护了一个自己的工作记忆，多个对话维护一个md，不够好，重构了一下，改为用一个state.json文件作为唯一真相源，AI 改工作记忆必须通过 12 个增量 action原子修改（加任务 / 完成任务 / 加待办…），每个操作需要明确 item_id，AI操作也必须引用ID，而不是原来的语义匹配（不稳定）。原本的md降为只读投影，不能编辑。
结构也变了，从原本md的简单分区改为更完善的三层结构：
全局层，系统资产 + Hot Knowledge（跨项目稳定信息）
项目层（还是放全局，只是按项目分），进行中 / 近期完成 / 待决 / 长期 backlog / 摘要
临时层，针对session的临时笔记，退出就丢
流程代码化
当AI系统逐渐复杂，靠md文档所规范的，可靠性越来越低，本质其实是信息太多，大模型注意力被分散。所以一方面，要时时精简系统，保持agent.md文件简洁，跟记忆分区类似，能放到子agent文档的就放子agent。我体感用下来最好保持200行以内，最好100行左右，再多效果就下降，很多规范根本没用。
另一方面最重要的是，将所有可以固定的东西，都代码化，而不是依靠大模型语义识别来控制，也不要靠记忆库。由于大模型的特性，我们是没有办法真正控制，大模型是怎么做的，但我们可以通过代码化的方式，更强硬地控制流程。我们可以控制大模型的上游，也就是脚本进行提示词注入，我们可以监控中游，也就是多agent协作过程中的交互节点，及时打断，我们也可以控制下游的产出，如果不符合要求，直接用替换产出为拦截文案的方法强制让AI”清醒”一点。另外，维护一份通用的审计机制，来保证每次漏调，补调都可追溯。
最新感触
涉及到系统自身的优化，每一步都要保证自己清楚AI在干嘛，做的修改是为了什么，而不是听着AI说的很有道理，就直接开始做，一定反复确认，做之前可以额外思考一下，是否可以精简，分步实现，拆细一些，实现一步测试一步，这个测试不是指跑通，而是**要使用一段时间，**否则就会变成屎山代码。
感觉harness已经到深水区，感受就是最近读了大量东西，做了大量判断，前面”偷得懒”，欠下的技术债，会被AI快速放大，快速讨债。这也是好事，多次重构的经验教训，逼得我不得不每个修改都精心设计，探讨多轮，仔细审核，不停追问。要时时克制自己打出”同意”二字。
同样，越来越感受到，AI是人的放大器，做AI系统，就是一场大型设计和大型工程，想要超过基模的”均值”，投入的心血，注入的个人特色，所依靠的积累，一点都不少。我预测未来大段时间内，甚至到agi时代来临后的一小段时间内，都是”人”的竞争，而并不是AI。
当下最应该做的事情的思考，本质就一句话，基模能力提升到agi时代之前，始终都有意义的事情。
能够随模型能力提升获益的harness，例如独有的思考模式，流程
独有的审美，品味，判断力调校，不追求100%达到与自身一样（也不可能），而是追求80%即可，剩下20%，利用AI独有的优势来填补甚至超越，例如并行迭代，多角色协作等
保持身心健康，见到新的时代