老金开源了个支持含CC、Codex等4个平台的编程治理框架

30 阅读12分钟

先通知一下,我的 Claude Code & OpenClaw 中文教程 更新了,Github上可见,飞书尚未同步最新版。。
版本教程截止:Claude Code v2.1.119 + OpenClaw v2026.4.24,地址在文末,一般我自己的介绍地址都在文末。

言归正传今天想给大家讲的内容。
感觉大家现在使用AI,好像都是这样的情况。
让 AI 写个东西或者改一个系统,最怕的不是它不会写。
最怕的是它写得太快。
一眨眼改了 8 个文件,你问它为什么动这个文件。
它说得头头是道,但你再看一眼项目,心里开始发凉。
乱七八糟的文件一堆,完全在瞎写。

这就是我做 Meta_Kim 的原因。
不是为了再造一个 AI 编程工具。
而是给这些 AI 编程工具,补一层会分工、会审查、会记住教训的元架构。

元架构理论的所有内容可查看 my.feishu.cn/wiki/PlRHwu…

Image

真正的痛点,不是模型不够强

现在很多人用 AI ,表面看模型已经很强了。
强到你给它一个明确的小任务,它能干得很漂亮。
但项目不是一个按钮,也不是一个孤立函数。

真实项目里,麻烦通常长这样:
登录模块一改,权限也要跟着看。
权限一动,测试就要补。
测试一补,旧逻辑不能破。
旧逻辑不破,还得把这次经验留下来。

这就不是写代码的问题了,这是组织问题。

一个人再聪明,没有分工、没有交接、没有 review(代码审查),最后也会越改越乱。
没有 verification(结果验证),坑就藏到下次才爆。
AI 也一样。

老金我以前最烦的就是这个点。
AI 写得很快,但你不敢完全交给它。
你看着它跑,怕它乱改。
你不看着它跑,又怕它把坑藏到下次才爆。

现在就不会了,任何提示词输入,它会先给你强化。

Image

最后,任何的关键操作,都有Hook拦截。

Image

这就尴尬了,本来是想省时间,最后变成你给 AI 当项目经理。

所以我做的不是工具,是元架构

元架构这个词听起来有点大。

我换个说法。
普通 AI 编程工具更像在回答:谁来写代码。
Meta_Kim 先问的是:写代码之前,这件事该怎么组织。
分为5种路由,你的任何问题,在这里都能被涵盖。

Image

它不急着动手,会先问几件事:
这到底是小改动,还是跨模块任务?
现有 agent 够不够?
谁负责规划,谁负责执行,谁负责审查?
失败了怎么修,修完怎么验证?
这次学到的东西,下次怎么用上?

Image

它还有协议和状态双重保障,让任务必然合规的完成,这个是代码层的,需要在项目内执行。

Image

这就是我说的元架构,它管的是 AI 之间的职责、边界、节奏和治理。

我在 WaytoAgi 直播里讲过这件事

这套东西不是突然拍脑袋想出来的,先做了测试,后写了论文,最后又把方法论落地到Github项目上,并在WaytoAgi 做过一场直播,题目就很直白:为什么很多人用 AI,越用越乱。

回放入口在这里。
waytoagi.feishu.cn/wiki/KGbewc…

Image

1是我的理论
2是直播回放和信息总结
3是AJ(WaytoAgi社区发起人),做的一个开源分享,利用元架构做的小红书爆款生成器。

Image

她的开源地址在这里:github.com/AAAAAAAJ/me…

那场直播我讲的核心,不是某个工具怎么装。
而是一个更底层的问题:AI 已经能改完整项目了,还要不要用单兵模式管它。

我自己的答案是:不能。

单兵 AI 很适合小任务,比如改文案、补一个样式、写一个独立脚本。
但一旦进入复杂项目,单兵会天然遇到四个问题。

1、跨文件任务,改完 A 忘了 B。
2、跨模块任务,不知道谁先谁后。
3、审查流程,容易自己夸自己。
4、经验沉淀,下次又从零开始。

这四个问题看起来像技术问题。
其实都是治理问题。

对的,还能让我掐会儿腰的是,我这次直播收到了很多的希望再来一期。
看起来对我这个研究主题感兴趣的人不少。

Image

为什么我一定要以 Agent 为单位

这里是很多人容易误会的地方。
我不是为了看起来更高级,才把 AI 拆成一堆 agent。
我真正看重的是三个隔离。

第一是记忆隔离。
安全审查 agent 应该记住安全规则和常见漏洞。
而不是把前端命名、文章语气、临时试错全塞进同一个脑子里。

第二是上下文隔离。
主窗口应该像老板办公室,只保留目标、决策和关键结论。
搜索、读文件、试错、验证,在对应岗位的 agent 里完成。
主窗口不会被过程噪音污染。

第三是技能隔离。
每个 agent 不是“另一个聊天框”。
它更像一个岗位:产品、架构、前端、后端、测试、安全、文档、研究。
岗位不同,技能清单、判断标准、交付物就不同。

所以 Meta_Kim 做的不是让一群 AI 在群里聊天。
它做的是编排成功以后,判断每个节点到底需要什么人。
这个人要会什么技能、负责什么结果、不能碰什么边界。

Image

这跟真实公司很像。
一个项目来了,老板不会把所有事丢给一个人。
他会先看:产品拆需求,架构定边界,前端后端测试安全按顺序进场。
AI 也是一样。

元架构的核心,是把 AI 拆成可治理单元

Meta_Kim 里有一个很关键的概念:最小可治理单元。

不是随便起个名字叫 frontend-agent,就算一个好 agent。
一个真正能长期用的 agent,至少要满足五件事。

它能独立完成一类工作,颗粒度小到不会什么都管。
边界清楚到知道自己不该碰什么。
能被替换、能复用,坏一个不拖垮全局。

Image

虽然我不懂代码,但我做管理十几年,把我的管理经验映射了进去。
又和程序员碰了一下,他给我的结论和我的理念不谋而合。

他跟我说,函数太大,会失控。
模块太碎,会互相依赖到没法动。

Agent 也是一样。
所以 Meta_Kim 不是疯狂堆 Agent。
它要解决的是:拆到什么颗粒度,既能干活,又能被治理。

它不是固定小队,而是先判断每个节点缺什么人

很多多 Agent 系统,一上来就给你几个固定角色。
产品、前端、后端、测试。
看起来很整齐。

但真实项目没这么听话。

同样是“改项目”,有时要安全审查,有时要迁移数据库,有时只是改一个 CLI 参数。
还有些任务,得先读论文、改提示词,再轮得到代码。

固定小队的问题是:人看起来有了,但不一定对题。

Meta_Kim 的思路是反过来。

先把任务编排成节点,再看每个节点需要什么岗位和技能。
有对应 agent 就派,没有就标记能力缺口。
复杂到需要新岗位时,再设计新 agent。

Image

这就是我说的 组织镜像。
不是把公司结构硬塞进 AI。
而是把岗位、技能、分工、审查、回滚、复盘,映射成 AI 可以跑的流程。

如果对你有帮助,记得关注一波~

它现在已经能投到四个平台

截至 2026/04/29,我本地当前 Meta_Kim 仓库版本是 2.0.19。
README 和 CHANGELOG 里已经把四个平台都纳入主线:
Claude Code、Codex、OpenClaw、Cursor。

但这里要说清楚,四个平台不是完全一样。

Claude Code 承载最完整,也是我拿来做元框架映射的主框架,因为相对其他平台,我最熟悉的就是CC,我也认为它的框架是最牛X的。
Codex 的 agents 很强,最近做了一些测试,修复了很多BUG。
Openclaw和Cursor没经过大量测试,可能会有很多BUG。。。

原则上,所有支持Agent架构的平台都支持,大家可以帮我提交下自己所用的平台映射。

Meta_Kim 用 canonical/ 做统一主源,再同步到不同的平台。
同一套治理逻辑投影到不同工具里,平台落地,元架构统一原则。

我不是只讲理论,还写了论文

对的,我很早就先写了论文,到今天为止,已经是500多的阅读,和400多的下载量。
这是我这学渣这辈子第一次写论文,看起来和网站上同类比起来,蛮受欢迎的。

论文地址在这里:zenodo.org/records/189…

Image

这篇论文支撑的是 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

你最常用的可能会是更新 = =

Image

在设定好文件目录,安装完成之后,可以直接在指定位置打开文件夹,创建项目。

Image

装完想看写了哪些东西:

npm run meta:status

想做检查:

npm run meta:doctor

Image

不想用了,卸载:

npm run meta:uninstall

这块我专门做了安装清单。
不是装完一堆配置散在系统里,最后你不知道谁写的。
能装、能查,也要能退。

工具要先像工具,再谈方法论。

然后呢,它除了各个平台自己的memory系统外,我又合并了graphify和Mcp memory service。

Graphify是代码知识图谱,它最高能压缩71倍的token消耗,以及确保项目准确性。

Image

另外一个是全局跨平台记忆,老金我在很早以前就介绍过。
安装完成后,默认地址是:http://localhost:8000/

老金我已经做了全自动hook,你从对话开始到结束的每一步,它都会形成记忆。
你在关闭某个项目后,再次打开不需要说任何前提,可以直接让他继续。

Image

是的,你会发现我的依赖项目非常多,因为我的是框架,理论上可以容纳很多项目,自动在其上面进行知识沉淀和改造。

简单点说,就是拿来吧你~ ,开玩笑,感谢各大优秀的开源作者,让AI发展的更迅速,更优质。

我想推广的其实是一个新动作

写到最后,老金我反而觉得 Meta_Kim 最重要的不是项目本身,而是它逼我们换一个动作。

以前我们比谁的模型更聪明。
接下来会比谁的系统更会协作。

模型越强,越不能让它乱冲。
强模型加无治理,只是更快地制造混乱。

Meta_Kim 想做的,就是把这层治理补上。

项目地址,你可以在这查看完整的Readme说明和版本更新Changelog说明:
github.com/KimYx0207/M…

如果你已经开始把 AI 用进真实项目。
建议先别急着让它写代码,先让它组队。


飞书**开源知识库(实时更新 交流群):
https://tffyvtlai4.feishu.cn/wiki/OhQ8wqntFihcI1kWVDlcNdpznFf

Claude Code & Openclaw 双顶流全中文从零开始的教程:不懂代码照样造网站,老金15万字Claude Code+OpenClaw教程免费开源

我的小破站(含我开源的项目):https://www.aiking.dev/


每次我都想提醒一下,这不是凡尔赛,是希望有想法的人勇敢冲。
我不会代码,我英语也不好,但是我做出来了很多东西。
我真心希望能影响更多的人来尝试新的技巧,迎接新的时代。

谢谢你读我的文章。
如果觉得不错,随手点个赞、在看、转发三连吧🙂
如果想第一时间收到推送,也可以给我个星标⭐~谢谢你看我的文章。