老金开源了个支持含CC、Codex等4个平台的编程治理框架
先通知一下，我的 Claude Code & OpenClaw 中文教程 更新了，Github上可见，飞书尚未同步最新版。。
版本教程截止：Claude Code v2.1.119 + OpenClaw v2026.4.24，地址在文末，一般我自己的介绍地址都在文末。
言归正传今天想给大家讲的内容。
感觉大家现在使用AI，好像都是这样的情况。
让 AI 写个东西或者改一个系统，最怕的不是它不会写。
最怕的是它写得太快。
一眨眼改了 8 个文件，你问它为什么动这个文件。
它说得头头是道，但你再看一眼项目，心里开始发凉。
乱七八糟的文件一堆，完全在瞎写。
这就是我做 Meta_Kim 的原因。
不是为了再造一个 AI 编程工具。
而是给这些 AI 编程工具，补一层会分工、会审查、会记住教训的元架构。
元架构理论的所有内容可查看
真正的痛点，不是模型不够强
现在很多人用 AI ，表面看模型已经很强了。
强到你给它一个明确的小任务，它能干得很漂亮。
但项目不是一个按钮，也不是一个孤立函数。
真实项目里，麻烦通常长这样：
登录模块一改，权限也要跟着看。
权限一动，测试就要补。
测试一补，旧逻辑不能破。
旧逻辑不破，还得把这次经验留下来。
这就不是写代码的问题了，这是组织问题。
一个人再聪明，没有分工、没有交接、没有 review（代码审查），最后也会越改越乱。
没有 verification（结果验证），坑就藏到下次才爆。
AI 也一样。
老金我以前最烦的就是这个点。
AI 写得很快，但你不敢完全交给它。
你看着它跑，怕它乱改。
你不看着它跑，又怕它把坑藏到下次才爆。
现在就不会了，任何提示词输入，它会先给你强化。
最后，任何的关键操作，都有Hook拦截。
这就尴尬了，本来是想省时间，最后变成你给 AI 当项目经理。
所以我做的不是工具，是元架构
元架构这个词听起来有点大。
我换个说法。
普通 AI 编程工具更像在回答：谁来写代码。
Meta_Kim 先问的是：写代码之前，这件事该怎么组织。
分为5种路由，你的任何问题，在这里都能被涵盖。
它不急着动手，会先问几件事：
这到底是小改动，还是跨模块任务？
现有 agent 够不够？
谁负责规划，谁负责执行，谁负责审查？
失败了怎么修，修完怎么验证？
这次学到的东西，下次怎么用上？
它还有协议和状态双重保障，让任务必然合规的完成，这个是代码层的，需要在项目内执行。
这就是我说的元架构，它管的是 AI 之间的职责、边界、节奏和治理。
我在 WaytoAgi 直播里讲过这件事
这套东西不是突然拍脑袋想出来的，先做了测试，后写了论文，最后又把方法论落地到Github项目上，并在WaytoAgi 做过一场直播，题目就很直白：为什么很多人用 AI，越用越乱。
回放入口在这里。
1是我的理论，2是直播回放和信息总结，3是AJ（WaytoAgi社区发起人），做的一个开源分享，利用元架构做的小红书爆款生成器。
她的开源地址在这里：https://github.com/AAAAAAAJ/meta-task-decomposition
那场直播我讲的核心，不是某个工具怎么装。
而是一个更底层的问题：AI 已经能改完整项目了，还要不要用单兵模式管它。
我自己的答案是：不能。
单兵 AI 很适合小任务，比如改文案、补一个样式、写一个独立脚本。
但一旦进入复杂项目，单兵会天然遇到四个问题。
1、跨文件任务，改完 A 忘了 B。
2、跨模块任务，不知道谁先谁后。
3、审查流程，容易自己夸自己。
4、经验沉淀，下次又从零开始。
这四个问题看起来像技术问题。
其实都是治理问题。
对的，还能让我掐会儿腰的是，我这次直播收到了很大的希望再来一期。
看起来对我这个研究主题感兴趣的人不少。
为什么我一定要以 Agent 为单位
这里是很多人容易误会的地方。
我不是为了看起来更高级，才把 AI 拆成一堆 agent。
我真正看重的是三个隔离。
第一是记忆隔离。
安全审查 agent 应该记住安全规则和常见漏洞。
而不是把前端命名、文章语气、临时试错全塞进同一个脑子里。
第二是上下文隔离。
主窗口应该像老板办公室，只保留目标、决策和关键结论。
搜索、读文件、试错、验证，在对应岗位的 agent 里完成。
主窗口不会被过程噪音污染。
第三是技能隔离。
每个 agent 不是“另一个聊天框”。
它更像一个岗位：产品、架构、前端、后端、测试、安全、文档、研究。
岗位不同，技能清单、判断标准、交付物就不同。
所以 Meta_Kim 做的不是让一群 AI 在群里聊天。
它做的是编排成功以后，判断每个节点到底需要什么人。
这个人要会什么技能、负责什么结果、不能碰什么边界。
这跟真实公司很像。
一个项目来了，老板不会把所有事丢给一个人。
他会先看：产品拆需求，架构定边界，前端后端测试安全按顺序进场。
AI 也是一样。
元架构的核心，是把 AI 拆成可治理单元
Meta_Kim 里有一个很关键的概念：最小可治理单元。
不是随便起个名字叫 frontend-agent，就算一个好 agent。
一个真正能长期用的 agent，至少要满足五件事。
它能独立完成一类工作，颗粒度小到不会什么都管。
边界清楚到知道自己不该碰什么。
能被替换、能复用，坏一个不拖垮全局。
虽然我不懂代码，但我做管理十几年，把我的管理经验映射了进去。
又和程序员碰了一下，他给我的结论和我的理念不谋而合。
函数太大，会失控。
模块太碎，会互相依赖到没法动。
Agent 也是一样。
所以 Meta_Kim 不是疯狂堆 Agent。
它要解决的是：拆到什么颗粒度，既能干活，又能被治理。
它不是固定小队，而是先判断每个节点缺什么人
很多多 Agent 系统，一上来就给你几个固定角色。
产品、前端、后端、测试。
看起来很整齐。
但真实项目没这么听话。
同样是“改项目”，有时要安全审查，有时要迁移数据库，有时只是改一个 CLI 参数。
还有些任务，得先读论文、改提示词，再轮得到代码。
固定小队的问题是：人看起来有了，但不一定对题。
Meta_Kim 的思路是反过来。
先把任务编排成节点，再看每个节点需要什么岗位和技能。
有对应 agent 就派，没有就标记能力缺口。
复杂到需要新岗位时，再设计新 agent。
这就是我说的组织镜像。
不是把公司结构硬塞进 AI。
而是把岗位、技能、分工、审查、回滚、复盘，映射成 AI 可以跑的流程。
它现在已经能投到四个平台
截至 2026-04-28，我本地当前 Meta_Kim 仓库版本是 2.0.19。
README 和 CHANGELOG 里已经把四个平台都纳入主线：
Claude Code、Codex、OpenClaw、Cursor。
但这里要说清楚，四个平台不是完全一样。
Claude Code 承载最完整，也是我拿来做元框架映射的主框架，因为相对其他平台，我最熟悉的就是CC，我也认为它的框架是最牛X的。
Codex 的 custom agents 和 subagents 很强，最近做了一些测试，修复了很多BUG。
Openclaw和Cursor没经过大量测试，可能会有很多BUG。。。
原则上，所有支持Agent架构的平台都支持，大家可以帮我提交下自己所用的平台映射。
Meta_Kim 用 canonical/ 做统一主源，再同步到不同的平台。
同一套治理逻辑投影到不同工具里，平台落地，元架构统一原则。
我不是只讲理论，还写了论文
对的，我很早就先写了论文，到今天为止，已经是500多的阅读，和400多的下载量。
这是我这学渣这辈子第一次写论文，看起来和网站上同类比起来，蛮受欢迎的。
论文地址在这里：https://zenodo.org/records/18957649
这篇论文支撑的是 Meta_Kim 背后的方法论。
核心就是四层：
拆，组，发牌，意图放大。
其实就是一句话：别让 AI 直接冲，先让 AI 把活组织明白。
普通用户到底怎么用，先记住4步
如果你只是让 AI 改一句文案，别用 Meta_Kim。
小题大做。
它会很消耗token，但对应会帮你想很多事儿。
我实际用下来，一个minimax2.7+元，可以约等于没有元的sonnet4.6所执行结果。
这不光是我这么说，其他人使用下来的感受也相同。
但如果你已经开始让 AI 改一个真实项目。
比如登录、权限、支付、数据迁移、组件重构。
别急着让它开写。
先走这 4 步。
1、先分类：这是小改动，还是跨模块任务。
2、再找人：现有 agent 够不够，不够就暴露能力缺口。
3、再分工：谁规划，谁执行，谁审查，谁验证。
4、最后沉淀：这次踩过的坑，下次要自动记住。
你可以用类似这样的方法进行开始：
/meta-theory
我要重构登录和权限模块。
先判断这个任务需要哪些角色和工作流。
不要直接改文件。
先给我执行计划、风险点和验证方式。
/meta-theory 作为调用技能的入口，能稳定传递给主Agent，主Agent会开始进行组织。
这一步很关键，因为复杂任务里，方向错了，写得越快越危险。
如果你不确定项目需不需要治理，可以先这样问：
/meta-theory
帮我检查这个项目里哪些任务适合多 Agent 治理。
只输出报告，不要改文件。
如果你已经让 AI 改完一轮，也可以这样收尾：
/meta-theory
帮我审查这轮改动。
重点看职责边界、回归风险、验证是否充分。
如果有经验教训，告诉我应该沉淀到哪里。
这三个用法，比安装多少工具都重要。
因为它改变的是使用习惯。
安装说明
现在最快的方式，是直接跑：
npx --yes github:KimYx0207/Meta_Kim meta-kim
你也可以用下载到本地的方式：
git clone https://github.com/KimYx0207/Meta_Kim.git
cd Meta_Kim
npm install
node setup.mjs
你最常用的可能会是更新 = =
在设定好文件目录，安装完成之后，可以直接在指定位置打开文件夹，创建项目。
装完想看写了哪些东西：
npm run meta:status
想做检查：
npm run meta:doctor
不想用了，卸载：
npm run meta:uninstall
这块我专门做了安装清单。
不是装完一堆配置散在系统里，最后你不知道谁写的。
能装、能查，也要能退。
工具要先像工具，再谈方法论。
然后呢，它除了各个平台自己的memory系统外，我又合并了graphify和Mcp memory service。
Graphify是代码知识图谱，它最高能压缩71倍的token消耗，以及确保项目准确性。
另外一个是全局跨平台记忆，老金我在很早以前就介绍过。
安装完成后，默认地址是：http://localhost:8000/
老金我已经做了全自动hook，你从对话开始到结束的每一步，它都会形成记忆。
你在关闭某个项目后，再次打开不需要说任何前提，可以直接让他继续。
是的，你会发现我的依赖项目非常多，因为我的是框架，理论上可以容纳很多项目，自动在其上面进行知识沉淀和改造。
简单点说，就是拿来吧你~ ，开玩笑，感谢各大优秀的开源作者，让AI发展的更迅速，更优质。
我想推广的其实是一个新动作
写到最后，老金我反而觉得 Meta_Kim 最重要的不是项目本身，而是它逼我们换一个动作。
以前我们比谁的模型更聪明。
接下来会比谁的系统更会协作。
模型越强，越不能让它乱冲。
强模型加无治理，只是更快地制造混乱。
Meta_Kim 想做的，就是把这层治理补上。
项目地址，你可以在这查看完整的Readme说明和版本更新Changelog说明：
https://github.com/KimYx0207/Meta_Kim
如果你已经开始把 AI 用进真实项目。
建议先别急着让它写代码，先让它组队。