用「元架构」治理 AI：为什么你越用越乱，以及怎么让 AI 真正进入协作
很多人用 AI 的体验是：工具装了一堆，模型换了好几个，提示词也写得越来越长，但复杂任务依然「第一次能跑，改不动，一改就变，场景一变就全乱」。游戏研发公司合伙人、有 15 年创业经验的老金，在 WaytoAGI 社区分享了他的一套解法——「元架构」。他把管理一家公司的逻辑完整映射到 AI 协作上，提出「元」是系统里最小的可治理单元，并开源了基于 Claude Code 的 Meta_Kim 项目。这篇文章适合那些已经会用 AI 写代码、做内容，但觉得复杂任务难以组织、难以验收、难以复用的进阶用户。
为什么 AI 越用越乱：问题出在「组织」而不是「工具」
老金开篇就点明，拉开 AI 使用差距的，不是工具、参数或现成的工作流，而是一个更底层的能力——「组织复杂问题的能力」。他观察到大多数人的典型困境：第一次能跑，但改不动；翻来覆去改，模型一直在改、一直在浪费 token，问题却原封不动；一改就变，场景一变就全乱。
他把这些问题的根源归结为四个字：边界污染。很多人把所有东西全塞进一个 agent 里，加了一些技能之后，原本能处理好的任务反而崩了——因为不同职责串在了一起。此外还有「裸奔运行」（只有执行，不知道什么时候该做什么事）和「刻舟求剑」（只求单一结果，不知道怎么复用）。
老金强调，这套方法论不是凭空想出来的，而是「一边做项目、一边搭系统、一边拆流程、一边和 AI 协作，一边反复翻车，最后硬生生逼出来的」。他特别提到，自己不是程序员，不懂代码，英语连四级都没过，但这并不妨碍他构建这套体系。
什么是「元」：最小的可治理单元
「元」是整套架构的核心概念。老金的定义是：系统里最小的独立的可治理的单元。他强调「可治理」三个字，而不是「最小」——这是他踩过坑之后得出的结论。
元有五个基本属性：独立的边界（一件事只能由一个人负责，两个人同时负责必然出错）、可被验证（提供的结果必须是他会的、可验证的）、可被复用（相同类型的任务可以重复使用）、节点可替换（看编排怎么定义）、以及最根本的——它是系统里最小的独立可治理单元。
「元」的定义会随视角变化。老金举例：一个小策划认为手头负责的文档是最小单元；策划经理认为管理的策划人员是最小单元；项目管理者则认为策划经理、美术经理、系统经理各自是一个元。「当你的等级提升以后，你所定义的元的概念会产生变化。」
他特别警告两个极端：一是拆得太细，细到夸克级别，结果资料数以万计时根本找不到东西，无法关联；二是「一锅炖」，把所有东西混在一起。正确的做法是取两者中间——可治理的最小单元。
如何判断一个东西算不算「元」？老金给出四个问题：
- 单独拿出来时，能不能说明清楚它负责什么？
- 出问题时能不能定位到它？
- 替换它时，知不知道它关联了哪些东西？
- 下次相近任务时能不能复用？
「前两个答不出来，说明它不是一个元；后两个答不出来，说明它还不够成熟。」
元架构的三层结构：基础设施员、编排员、执行人
老金把元架构分为三个层级，并类比公司体系来解释。
基础设施员：负责 AI 相关的知识，如 RAG（知识库）、工具使用（tools）、功能使用（func）、MCP、skill、prompt 等——本质上都是 context（上下文）。老金的项目里有 6 个基础设施员，分别承担不同职责。
编排员：负责分析用户需求，把想法拆清晰，确定做事的步骤和需要的人员，然后传递给基础设施员。老金说：「许愿的意思就是我根本不知道怎么做，编排员能负责把你的想法拆清晰，这是他的首要责任。」
执行人（agent）：根据编排员的安排执行具体任务，如搜索、执行结果、画画、写东西等。
整个运作机制就像一家公司：CEO 提出抽象目标（「今年的增长要到 50%」），经理拆解部门职责，部门经理继续往下拆，找到合适的人来执行。在 AI 体系里，编排员把用户需求拆成多个节点，基础设施员保证每个执行员能力合格，共同完成任务。
老金强调，这套架构的关键是「把现实的管理体系映射到 AI 上面」。他特别指出，扁平化架构并不好——他跑过数据验证这一点。「扁平化代表这个人又得管决策、又得管执行，他才能成立。」而他的架构拆的是决策、派活和编排。
闭环与节奏编排：让系统动态运转
老金认为，比单纯生成更关键的是「组织能力」。他提出一个四环节闭环，适用于任何事：需求 → 制作 → 验收 → 反馈。
- 需求：要做什么，必须拆分到制作人员可以落地的地步
- 制作：怎么做，需要什么技能
- 验收：需求发起方来验证做得对不对
- 反馈：本质是新的需求，是进化方向
「当你把这一系列的能力学会了以后，你可以复用。」
更精彩的部分是「节奏编排」——这套灵感来自游戏设计，而非 AI 或组织架构。老金称之为「隐形的骨架」：流程必须有，但不定义成具体事项。他引入了「发牌」机制，包括留白、跳过、插队、补救、沉默等动态决策。
- 留白：项目执行中冒出问题但不确定在哪，先记下来，不打断当前工作
- 跳过：原本定了某些流程，但 AI 发现已有现成函数时可以直接跳过
- 插队：突然发现支付相关的紧急任务，立即处理，其他事往后推
老金说，这套节奏编排是他上周才加进来的，「非常有意义」。它解决的核心问题是：动态管控流程是否正确，有没有减少用户的不确定性，提高下一步的清晰度，有没有打断当前任务。他还设置了一个「注意力成本」机制——当连续出牌大于等于 3 张时，强制休息，让人来做判断。
意图放大：一句话驱动整个组织
老金最终想达成的效果是「意图放大」：一个人发起一句话，通过元架构实现结构化协作。他在自己的个人主页上设置了游戏部、AI 部、行政部、留学部、原部门等多个虚拟部门，通过定时任务让它们自动生成内容，比如 AI 音乐工具发布报告。
「当有一天我发了一个『我今天需要公司在增长方面做一些事』，四个部门同时收到以后，会同时从各自部门往增长方面想办法，产出的东西都是往增长方向做的。」
落地元架构需要四步：拆（拆成最小作战单位，明确目标、场景、执行方式）、排（把这些小方块排起来）、验（判断结果对不对）、进化（把错误纠正后塞进下次不犯的路径）。
老金特别强调：「真正的系统不止会执行，还会组织、会判断、会出牌。」他认为，架构师才是以后玩 AI 的一个非常厉害的角色。
现场问答
SUB agent 和 agent team 有什么区别？分别在什么场景使用？
老金认为两者没有本质区别，关键看任务是线性还是并行。「如果你是并行，你就变成了一个 agent team。」SUB agent 适合既定任务的分类处理，比如 AJ 举例的生成 500 张图，按植物类、动物类、场景类等分成 6 个 SUB agent 并行处理。而 agent team 适合需要复杂协同编排、自己定义角色的场景。老金补充，他的项目里有一个只有 170 多行提示词的组件，能自动判断该用 SUB agent 还是 agent team，不需要用户自己定义。
agent 协作时通信异常或挂掉，怎么恢复和追溯？
「直接输，重新来就行了，直接输。」用自然语言让它重新执行即可。追溯问题则通过第二层的代码知识图谱实现可视化，每个环节的验证结果都有记录，通过「协议」和「门」两个状态来记录任务状态。老金补充，不是每件小事都会进化，而是同一件事在当前 system 下发生三次以上，才会成为进化目标。
简单的项目用这个会不会太重？
「会，非常非常消耗 token，因为他想的过程非常多，验证环节非常多。你不想动脑子，那就消耗钱嘛。」老金建议，每个环节都是一个「元」，用户可以根据自己的需求做删减。「因为我是面向大众的，所以会做得非常臃肿，得满足更多场景。」
每个元如何定义？怎么算完成？
以写策划案为例：「我得告诉他上面要写版本号、中间要写名字、下边要有签字，格式必须是设计目标、设计原则、功能说明、流程图。我会把一系列条件告诉你，你按着给我填。」这就是「协议」——交付的契约。检查时按协议逐项核对即可。
Claude 订阅能用这个项目吗？
老金说，任意支持 agent 的项目都可以用，只需要反向映射。「这个东西本来就是最原始的一套东西，你只要去自己映射一遍就好了。」他目前只映射了 Claude Code、Codex、Cursor 和 OpenClaw 四个平台，其他平台需要自己映射。
要点回顾
- 「元」是系统里最小的独立可治理单元，不是拆得越细越好，而是找到「可治理」的平衡点；判断标准是四个问题：能否说明职责、能否定位问题、能否知道关联、能否复用。
- 元架构分三层：基础设施员（负责 AI 知识）、编排员（拆解需求、分配任务）、执行人（具体干活），类比公司体系：CEO 提目标，经理拆任务，员工执行。
- 闭环四环节：需求 → 制作 → 验收 → 反馈，反馈是新的需求，驱动系统进化。
- 节奏编排是动态管控的关键：留白、跳过、插队三张牌，加上注意力成本机制（连续出牌 ≥3 张强制休息），让流程不被固定工作流锁死。
- 意图放大是终极目标：一句话驱动多个虚拟部门并行产出，实现「许愿」效果。
- 落地四步：拆（最小作战单位）→ 排（编排）→ 验（验证）→ 进化（形成进化体系）。
- Meta_Kim 项目：基于 Claude Code 架构，支持任何 agent 平台，但简单项目慎用，非常消耗 token；老金个人推荐 Minimax 2.7，性价比高，「加上这套东西可以顶一个 Claude 4.0 的 sonnet」。
- 学习建议：重点不是项目本身，而是理解文档里的元架构原理，以及它如何与 AI 映射。「我知道这件事怎么做」和「我知道 AI 能做什么」两件事必须并行成立。
直播回放约 107 分钟
播放器来自飞书妙记 · 在新窗口打开