从零搭建一支 AI Agent 团队：Claude Code + Codex 多智能体协作的完整实操拆解（原理 · 分工 · 落地）

本文由 辛梓煜@词元二号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

如果你只想要一句话结论：所谓"搭一支 AI 团队"，本质是把你自己从"唯一的操作者"变成"唯一的决策者"——你给一台电脑里的几个 AI 分好岗位、写好各自的"岗位说明书"，让它们像公司一样自己派活、自己写、自己审、自己交付，你只负责定方向和最后拍板。核心结构就三层：你（董事长）定方向 → 一个统筹的"CEO"型 Agent 拆解任务 → 底下的"写代码 / 审代码 / 做内容"若干专职子智能体轮流干活。技术上它靠三样东西支撑：子智能体（Sub-agent）负责隔离与专业化，Markdown 人设文件负责固化分工，命令行（CLI）负责跨模型调度。全程你几乎不用写代码，只需要在终端里跟 AI 聊天。

这套东西真正解决的不是"让 AI 更聪明"，而是"让 AI 的产出不再断线"——哪怕你今天状态不好，团队照样能往前推进。我自己（辛梓煜）折腾下来，最大的感受是：终于不用再在一堆终端窗口和一堆技能之间来回切换，把脑子耗在"我刚才做到哪了"这种破事上。

下面这篇，我会把从"为什么要这么做"到"每一步怎么落地""背后到底怎么跑起来的"全部拆开讲清楚，还会顺手把子智能体、命令行编排、MCP 这些概念用大白话讲透。想看完整拆解，往下翻。

一、先说痛点：为什么一个人用 AI，反而越用越累

工具越堆越多，脑子却越来越乱

我先描述一个场景，你大概率也经历过。

刚开始用 AI 的时候，一切都很爽：装一个技能（skill），能帮你写周报；接一个工具，能帮你查资料；开一个终端，能帮你改代码。于是你越装越多——电脑里技能一大堆，终端经常同时开一排，手头在做的编程项目也越来越多。

问题就出在这里。工具本身没错，错的是所有这些工具的"调度中枢"只有你一个人。每一个项目做到了哪一步、接下来该干嘛、这个技能刚才是用来干哪件事的……全都堆在你自己的脑子里。人脑的工作记忆是很有限的，一旦并行的线程超过三四条，你就开始"一团乱麻"：做了一大堆，真正能收尾上线的却没几个。

说白了，你不是被 AI 累到的，你是被"给 AI 派活、切工具、记进度"这些碎活累到的。这些活单看都不难，但它特别碎，而且要求你一直守在电脑前盯着。更糟的是，这种琐碎会悄悄侵蚀你本该用来做重要判断的注意力——当你的脑子被十几件小事占满，你就很难再腾出带宽去想那些真正值钱的大问题了。工具本来是来帮你的，结果反倒成了新的负担，这就是很多人"AI 用得越多、人却越焦虑"的根源。

把生产力全绑在一个人身上，风险有多大

还有一个更隐蔽的问题：当所有 AI 的产出都要经过你这个"人肉调度器"，那你的状态就成了整条流水线的天花板。

你状态好，能连轴转，产出就源源不断；你哪天头疼、开会、或者干脆不想动，那所有项目就集体停摆。AI 明明是可以 24 小时不睡觉的，结果被你一个人的精力死死卡住了产能。

我举个我自己最真切的例子。有一阵我同时在推三个小项目，白天开会、晚上才有整块时间。结果就是：每天晚上坐下来，前半个小时全花在"我上次做到哪了、这个函数当时为什么这么改、那个技能是不是还没配完"上——等我把状态捡回来，一晚上已经过去一半。等于我每天都在为"重新加载自己的上下文"交一笔昂贵的税。

一个团队就不会这样。哪怕核心的人今天不在状态，其他成员照样能按既定流程往前推。"产出不断线"这件事，靠的从来不是某个超人，而是一套能自转的协作机制。 更关键的是，团队把"进度"和"上下文"从你的脑子里，挪到了一套外部系统里——项目做到哪、谁在负责、下一步是什么，都写在文件里、记在各自的记忆里，不再依赖你那点可怜的工作记忆。我搭这套 AI 团队，图的就是这个：把"调度"和"记忆"这两件最耗神的事，一起外包出去。

二、换个思路：把自己"公司化"，给 AI 分岗位

想清楚了痛点，解法其实就浮出来了——别再让自己既当老板又当所有员工，把角色拆开。

这个"公司化"的思维模型，好用的地方在于它给了你一套现成的、你天生就懂的语言去组织 AI。你不需要学什么复杂的框架术语，只需要问自己一个很朴素的问题：如果这是一家真实的公司，这件事该由哪个岗位来做？谁来定方向？谁来拆任务？谁来执行？谁来质检？谁来对外？把这几个问题回答清楚，你的 AI 团队的骨架就出来了。一旦你开始用"董事长—CEO—各部门"这套熟悉的结构去想问题，那些原本抽象的"多智能体协作"一下子就变得具体、可操作了。

组织架构：董事长 / 秘书 / CEO / 两个项目部

我给自己这套系统搭的组织架构，可以用一张图说清楚：

graph TD
    A["董事长（你本人）<br/>定方向 · 提想法 · 最终拍板"] --> B["秘书 Agent<br/>记录灵感 · 转述需求 · 打理日常"]
    A --> C["CEO Agent<br/>统筹规划 · 拆解任务 · 安排落地"]
    C --> D["产品开发部"]
    C --> E["内容创作部"]
    D --> D1["开发 · 写代码"]
    D --> D2["审查 · 找漏洞"]
    E --> E1["编辑 · 文稿/脚本"]
    E --> E2["美工 · 配图/封面"]

听起来挺唬人，但真正搭起来非常简单，后面我会一步步演示。这里先把每个角色是干嘛的说清楚。

每个角色到底负责什么

董事长——也就是你自己。 你只做三件事：定大方向、提想法、拍板。剩下的一律不碰。

秘书 Agent。 我把一个带长期记忆、并且接进了我常用即时通讯软件（比如微信）的助手当秘书用。它负责接住我那些零散的、随时冒出来的灵感，帮我记下来，再在合适的时候转述给 CEO；顺带打理日常——提醒我喝水、提醒会议时间、帮我扫一眼邮箱告诉我哪些要回哪些不用，每天再给我推一条当天该关注的行业动态。它是我平时聊得最多的一个。

CEO Agent。 这是整个团队的中枢。我给它起了个名字叫"马斯克"，背后是终端里的编码 Agent（Claude Code）担任。它负责整个"公司"的统筹规划：把我抛出来的想法拿去思考、验证，挑出其中的漏洞，然后拆成具体任务分派下去，最后再回来跟我汇报、定下一步。它的角色有点像一个既懂技术、又能管人的技术合伙人——我给它一个方向，它负责把这个方向翻译成一串可执行的任务，再盯着底下的员工一件件做完。我不需要知道每一步的技术细节，只需要在它汇报时判断"这个方向对不对、这个结果收不收"。可以说，整套系统能不能省心，八成取决于这个 CEO 靠不靠谱，所以后面我会花不少功夫给它装上更好的思维方式（见第九节）。

两个项目部。 CEO 底下管两条线：一条是写代码、做小产品的产品开发部，另一条是做图文和视频内容的内容创作部。

你会发现，这套结构最妙的地方在于：它把"调度"这件事从你身上，转移到了 CEO Agent 身上。 你只跟 CEO 一个人对话，CEO 再去管理底下所有员工。你的认知负担一下子从"管十个工具"降到了"管一个人"。

三、认识三类核心 AI"员工"及其分工

在动手搭之前，得先认识清楚手里有哪几类"员工"。我现在离不开的核心 AI 有三类，各有各的脾气和特长。

写代码的主力：终端里的编码 Agent

第一类是以写代码见长的编码型 Agent，典型代表就是运行在终端里的 Claude Code。它的强项是理解整个代码库、自主执行多步骤任务——不是那种只会补全单行的工具，而是能读懂你项目结构、直接改文件、跑命令的"编程伙伴"。它跑的是一套"理解 → 计划 → 执行 → 验证"的智能体循环：你给一句需求，它自己去读相关文件、想清楚要动哪几处、动手改、再跑一下看对不对，出错了还会自己回头修。团队里"写代码"这个岗位，主力就是它。

我一般让它同时兼任 CEO，是因为它拆解任务、统筹全局的能力足够强。你完全可以把它想成一个既能亲自下场写、又能站在高处调度的技术合伙人——只不过它不会累、不会烦、也不会因为你半夜给它派活就摆脸色。

挑刺的审查员：另一个模型

第二类是专门用来挑毛病的审查型 Agent，我用的是 Codex。这里有个非常重要、也是我反复强调的设计：写代码和审代码，要用两个不同的模型。 具体为什么，第四节会专门展开。你现在只要记住：审查员的价值不在于比谁更聪明，而在于它是"另一双眼睛"，天生带着怀疑的立场去看别人写的东西。

管记忆的秘书：接进即时通讯、带长期记忆

第三类是记忆型助手，也就是前面说的秘书。它区别于前两类的关键，是那套做得很扎实的长期记忆能力，加上被我接到了社交/通讯软件上，所以它能像真人助理一样随时待命、记住我们之前聊过的所有上下文。

普通 AI 有个众所周知的毛病，叫"金鱼记忆"——你今天跟它聊了很久、建立了完整的上下文，第二天开个新对话，它又什么都不记得了，每次都是"初来乍到"。而记忆型助手就是专门来治这个病的：它会跨会话地自动积累、沉淀你告诉过它的事，让"我们之前说好的"这件事真正成立。对一个要长期陪着你的秘书来说，这个能力不是加分项，是及格线——没有记忆的助理，你每天都得重新教一遍，那还不如自己干。

我把这三类摆在一张表里对比，你一眼就能看清分工：

以前我是"这个技能调一下、那个 AI 叫一下"，精力全耗在来回切换上。后来我想通了：与其把自己拆成三份、分散在三个工具上，不如把它们组合成一个团队，让它们内部协作，我只跟中枢对话。

四、一个关键设计：写代码和审代码，为什么必须换人

这一节单独拎出来讲，因为它是整套系统里最容易被忽略、却又最关键的一个设计决策。

自己审自己，盲区是重合的

你有没有想过一个问题：如果让同一个模型先写代码、再审自己写的代码，会发生什么？

我自己实测下来的体感是——它对自己的产出不会太较真。它会倾向于说"没问题"。这不是它偷懒，而是一个很朴素的道理：一个模型审查自己写的代码，它的盲区和它写代码时的盲区是重合的。 它没验证的那些假设，回头审的时候它照样想不到去验证。就像你自己写的文章，自己校对十遍也未必揪得出那个从一开始就错了的逻辑前提。

对抗性审查：换一双"默认怀疑"的眼睛

但如果换一个来自不同厂商、不同训练路线的模型来审呢？情况立刻不一样。

让 Claude Code 去写、让 Codex 去审，Codex 常常能揪出一大堆漏洞。它挑毛病是真的专业，而且因为它跟写代码的不是"一伙的"，它没有任何理由对那份代码手下留情。这种做法有个专门的名字叫对抗性审查（adversarial review）：审查方的心态不是"我看看这代码好不好"，而是"我假设你这段代码有问题，我就要把它找出来"。

它的威力体现在哪儿？迁移脚本、鉴权逻辑、涉及钱和重要数据的改动，这类代码最危险的地方往往不是某一行写错了，而是你以为成立的那个前提，其实压根没验证过。让另一个模型从头到尾质疑一遍，相当于强制做了一次"假设审计"。

打个不那么技术的比方你就懂了：这就像写论文和审论文。你自己写的东西，自己校对再多遍，也很难发现那个从立意阶段就埋下的逻辑硬伤——因为在你脑子里，那个前提"理所当然"是对的。但换一位跟你毫无立场瓜葛的审稿人，他不会预设你的任何前提，反而一眼就能指出"你这里凭什么这么假设？"。代码也一样：最贵的 bug 从来不是拼写错误，而是"整个思路的地基就歪了"，这种问题只有换一双不带感情的眼睛才照得出来。

用两个模型互审，它们各自的盲区会有，但两个盲区的交集要小得多。这就是"第二双眼睛"的真正价值：不在于更强，而在于不同视角 + 默认怀疑。现在做多智能体协作的人，基本都是这个思路——写的和审的，一定分开。 顺带说一句，这个原则不只适用于代码：你让 AI 写文案，也完全可以让另一个 AI 去挑刺、去质疑，同样比"自己写自己夸"靠谱得多。

五、动手第一步：用聊天搭出"产品开发部"（全程不写一行代码）

原理讲够了，开始动手。一口吃不成胖子，我先从产品开发这条线入手。

先让 AI 上网找参考，别急着动手

打开终端，调出你的编码 Agent（苹果电脑按住 Command + 空格，输入"终端"就能打开）。然后，先别让它急着干活。

我第一句话不是"帮我搭个团队"，而是：我想做一个用 AI 管理个人工作室的系统，现在有两条线，一条是写代码做小产品，一条是做内容。你先上网去搜，看看别人是怎么搭这种 AI 协作团队的，先不要写任何代码、不要做任何改动，把搜到的结果整理给我看。

这一步很重要。让 AI 先做调研、再动手，能避免它一上来就按自己的理解瞎搭。网上其实已经有不少"一个人用 AI 组队"的实践总结，让它读完、结合你的实际情况再来设计，效果比凭空生成好太多。

为什么"先搜再做"这么关键？因为 AI 一旦开始动手，它就会沿着最初理解的那个方向一路狂奔，等你发现跑偏，它可能已经建了一堆你不想要的东西。而"先调研、只汇报、不改动"这个约束，相当于给它踩了一脚刹车，把"理解需求"和"动手执行"这两个阶段掰开——你有机会在它真正干活之前，先校准方向。这个习惯不只适用于搭团队，几乎所有让 AI 做复杂事的场景都适用：先让它把计划讲给你听，你点头了，再让它开工。

另外提醒一句，让它上网搜的时候，你要的是"合规、国内可正常访问的参考资料"。整个搭建过程都在你自己电脑本地完成，不涉及访问任何受限的外部资源——如果某个参考步骤依赖你够不着的站点，直接让 AI 换一个国内可访问的等价方案就行。

定义三个岗位与它们的循环流水线

产品开发部我设了三个岗位：

• CEO（负责头脑风暴 + 分派任务）：跟我一起过一遍想法，指出其中的漏洞和该改的地方，然后把任务拆下去。
• 开发（负责真正写代码）：我给它起名叫"代代"，背后同样是 Claude Code，听 CEO 指挥，做实际的开发落地。
• 审查（负责揪漏洞）：我给它起名叫"查查"，背后是 Codex，专门审代代写的代码。

它们之间的工作流是一个循环，用图表示最直观：

flowchart LR
    CEO["CEO 分派任务"] --> DEV["代代：写代码"]
    DEV --> REV["查查：审查 + 安全评估"]
    REV -->|发现问题| DEV
    REV -->|通过| BACK["交回 CEO"]
    BACK --> ME["董事长（你）最终把关"]

代代写完，交给查查；查查做审核和安全评估，找到问题就打回去让代代重写；代代改完再交给查查……这样来回循环几轮，直到查查再也挑不出毛病，才交回到 CEO 手里，CEO 再来跟我汇报、定下一步。

这个"打回—重写—再审"的循环，就是整套系统里质量的护城河。它模拟的其实就是真实团队里"开发提交、测试打回、开发修复"那一套流程，只不过全自动、不用你催、也不用协调时间。这里有个小提醒：一定要给这个循环设一个明确的收敛条件，比如"审到没有严重问题为止，最多来回 N 轮"。为什么？因为如果不设边界，两个较真的 AI 有可能在一些鸡毛蒜皮的细节上无限拉扯，把额度白白烧掉。给它们一个"及格就放行"的标准，让它们知道什么时候该停，这条流水线才既较真又不钻牛角尖。

我特意没有把"上线部署"的权限交给 AI。最终发布这一关，我要用人的身份再过一遍。目前我更看重产品质量的可控，所以宁可自己多把一道关。到这儿，代码项目部就算搭好了——整个过程我没新建任何文件夹，没写一行代码，就是坐在终端前跟 AI 聊天，框架和搭建全是它自己完成的。

我踩过的坑：把"工作室"理解成"编程框架"

这里分享一个我自己踩过的坑，帮你省点事。

我第一次跟 AI 描述需求时，它把我说的"AI 团队"理解成了那种软件工程意义上的编程框架，而不是"给几个 AI 分岗位协作"。结果它吭哧吭哧给我设计了一堆代码架构，完全跑偏。我又校正了一次，明确说"我要的是组织分工，不是技术框架"，才得到现在的结果。

所以你在描述需求时，一定要把"我要的是角色分工和协作流程"这件事说清楚，别让它往纯技术实现的方向去理解。踩过这个坑，你就能少走一段弯路。

六、掀开引擎盖：这套系统背后到底怎么跑起来的

到这里你可能会问：我就是跟 AI 聊了几句天，它凭什么就能"派生"出一堆员工、还能各干各的？这一节把引擎盖掀开，讲讲底层原理。看懂它，你才能真正驾驭这套系统，而不是照葫芦画瓢。

子智能体（Sub-agent）：给每个员工一块干净的黑板

核心机制叫子智能体（Sub-agent）。用大白话说：主 AI 能够按需"派生"出一个个临时的下属 AI，每一个下属就相当于一个员工。

它妙在哪？每个子智能体都跑在自己独立的上下文窗口里——你可以把上下文窗口理解成"一块黑板"，AI 干活时的思考、翻过的资料都写在黑板上。如果所有活都在主对话这一块黑板上做，黑板很快就写满了、也乱了，主 AI 的"脑子"就糊了。

子智能体的做法是：把"读几十个文件""跑一堆测试""翻大量日志"这种会产生大量中间垃圾的脏活累活，丢给一个临时的下属去做。下属在自己那块黑板上折腾，干完之后只把最终的精华结论传回来，然后它那块写满了的黑板直接擦掉销毁。这样主 AI 的黑板永远保持清爽——它拿到的只是一句摘要，比如"扫描了 5 万行代码，发现 3 个问题，分别是……"，而不是那 5 万行的全过程。

除了"保持主脑清爽"，子智能体还有一个特别实在的好处：并行。同一件大事，可以拆成几块，同时派几个下属分头去干。有个被反复引用的对比数据很能说明问题——用三个子智能体并行去分析一个五万行的项目，大约几十秒就能出结果；而如果一个个串行地做，同样的活要花上好几分钟。对于"分析认证模块、数据库模块、接口模块"这种天然可以拆开的任务，并行几乎是白捡的效率。

但用子智能体也有个心法，叫单一职责原则：别贪心地造一个"什么都会"的全能员工，那反而会让它样样稀松。每个员工只专注一件事，通过清晰的"输入 → 处理 → 输出 → 交接信号"来定义它的边界，整条流水线才稳。这跟真实公司里"专业分工"的道理一模一样。不过也别为了并行而并行——十个下属去处理一件简单的小事，光是协调和 token 开销就得不偿失了，那还不如主脑自己顺手做掉。

还有一个你必须知道的约束：子智能体不能再派生下一级子智能体。 这是刻意的安全设计，防止无限套娃导致资源失控。所以如果你的流程需要"发现问题 → 自动修复 → 再验证"这种链式结构，只能在主对话这一层去串联，不能指望审查员自己去叫一个修复员来。设计流程时，把这个边界考虑进去。

Markdown 人设文件：员工的"岗位说明书"

那"代代""查查"这些员工的性格、职责是怎么固定下来的？答案朴素得让人意外——就是一个 Markdown 文件。

系统会给每个员工单独配一个 .md 人设文件，里面写清楚它是谁、负责什么、能用哪些工具、有哪些权限。这个文件的正文，会变成这个子智能体的"系统提示词"，也就是它开工前先读一遍的岗位说明书。

举个例子，一个"审查员"的人设文件，结构大致长这样：

---
name: reviewer
description: 严格的代码审查专员。在写完或改完代码后主动介入，
             只报真实 bug、回归风险和缺失的测试。
tools: Read, Bash
---

你是一名资深代码审查员，只做审查，绝不改动代码。
被调用时：
1. 按严重程度排序列出问题，给出文件和行号；
2. 重点检查那些"看起来对、其实没验证"的前提假设；
3. 审完输出一份简洁的结论报告。

看懂这个你就明白了：所谓"给 AI 分岗位"，落到实处就是给每个岗位写一份这样的 Markdown 说明书。 没有玄学，就是写文档。这也是为什么我一直说"不会编程也能搭"——你要做的，本质上就是把一份份岗位职责，用大白话写清楚。

还有个设计上的巧思值得一提：这些说明书并不是一股脑全塞进 AI 脑子里的。平时 AI 只记着每个岗位一句简短的描述，只有在真正需要用到某个员工时，才去加载它那份完整的说明书。 这种"用到才展开"的做法极其省 token，好处是你可以给团队配一大堆岗位和技能，也不会因为"档案太厚"把 AI 的脑子撑爆、拖慢它。这跟真实公司一个道理：你不需要时时刻刻背下每个人的完整岗位手册，需要找谁办事的时候，翻到那一页就行。而这些说明书，恰恰也是我们下一节要讲的"公司档案"的一部分。

跨模型协作：为什么要走命令行（CLI）

还有个关键细节：Claude Code 派出去的、由它自己家模型担任的子智能体，是它内部直接调度的，不需要走命令行。但当它要叫别人家的模型来干活——比如让 Codex 来审代码——这一步就得通过命令行（CLI）去调用了。

具体来说，就是用一条非交互式的命令，把任务直接丢过去。像下面这样（这是示意，实际参数按你的环境调整）：

# 让 Codex 以只读方式审查未提交的改动，只报真问题，按严重程度排序
codex exec --sandbox read-only \
  "作为严格的代码审查者，只列真实 bug、回归风险和缺失的测试，
   按严重程度排序，给出文件和行号。"

为什么要走命令行，而不是搞个复杂的对接？因为命令行是一个极其稳定的接口：它成熟、通用、几乎不会变，来回传递消耗的 token 也很少，所以效率很高。从主 AI 的角度看，调用另一个模型这件事，感觉上更像"调了一个函数"，而不是"切换了一个工具"。

而且这里还藏着一个成本上的好处：像 Codex 这类的计算是跑在它自己厂商的服务器上的，完全不占用主 AI 的上下文窗口。你可以让它在后台跑一个审查任务，同时继续跟主 AI 聊别的，等结果好了再回来看。后台任务的费用是按 token 算的，不是按时间算的，所以哪怕它在后台跑了很久，也不会因为"跑得久"而更贵。

命令行调用还有一个我特别看重的地方：权限可以精细地卡。 通过一个叫"沙箱（sandbox）"的参数，你能限定这次调用能干到什么程度——比如让审查员只读、不许改任何文件；或者只允许它在工作目录里改动，碰不到目录之外的东西；再或者遇到需要更高权限的操作时，必须停下来问你。这意味着你不是"要么全放开、要么全盯着"的二选一，而是可以给不同员工发不同级别的"门禁卡"。审查员天生就该是只读的，写代码的可以给它工作目录内的写权限，而"部署上线"这种最危险的操作，门禁卡干脆不发——留给你人肉来开。

七、它们靠什么协作：两层通信机制

搭好了架子、认识了原理，还有最后一块拼图：这些员工彼此之间是怎么传递信息、协同工作的？我把它拆成两层来理解。

长期层：公告板 / 项目台账 / 收件箱

第一层是长期记忆与公共信息，它是靠一堆 Markdown 文件沉淀下来的。你可以把它想象成公司里那些"挂在墙上、放在柜子里"的东西：

• 公告板：写着公司当前的整体状态、正在推进的大事。
• 项目台账：记录每个项目进行到哪一步、谁在负责、卡在哪里。
• 收件箱：员工之间需要异步传递的消息落在这里。
• 各员工的人设文件：也就是上一节那些岗位说明书。

落到硬盘上，这些"公司档案"其实就是一个文件夹里的一堆 Markdown，结构大致像这样：

我的AI公司/
├── 公告板.md          # 公司当前整体状态、正在推进的大事
├── 项目台账.md        # 每个项目进度、负责人、卡点
├── 收件箱/            # 员工之间异步传递的消息
│   ├── 给CEO.md
│   └── 给审查.md
└── 员工/              # 每个员工的岗位说明书（人设文件）
    ├── CEO.md
    ├── 开发-代代.md
    └── 审查-查查.md

这些都是持久化在硬盘上的文件，所以哪怕关掉重开、换一个会话，信息也不会丢。这一点特别重要——它意味着你的"公司"是有记性的，不会每天早上都像个刚入职的新人一样问你"我们在做什么来着"。

顺带一提，主 AI 本身也有类似的长期记忆机制——比如一个放在项目根目录的记忆文件，每次新会话启动时会被自动读进去，充当"这个项目的既定规矩"。你甚至可以直接跟它说"记住：以后这个项目一律用某某规范"，它就会把这条自动存进记忆，下次开会话不用你再交代。你可以把团队的协作规范、你的偏好、踩过的坑都写进去，让每次开工的 AI 都自动继承。这就是"公司文化"沉淀下来的地方。

实时层：上下文里的即时派活

第二层是实时派活。每一次具体的任务下发、每一次结果回传，都是在当次对话的上下文里直接传递的——CEO 把任务说给代代，代代把结果交回来，这些即时的一来一回，走的是内存里的上下文，不必每次都落盘。

两层合起来，就构成了完整的协作：长期层保证"公司记得住自己是谁、在做什么"，实时层保证"活能一件一件高效地派下去、收上来"。

这里补一个我踩过的认知坑：在标准的子智能体模式下，所有子智能体都只跟主对话（中枢）通信，彼此之间其实是信息孤岛——是"星形结构"，所有沟通都经过中心那个点，员工 A 和员工 B 不会直接对话。想让它们真正互相"讨论"，需要更高级的编排方式，那个目前还比较实验性，不建议一上来就上。对绝大多数人，星形结构够用了，也更可控。

八、第二步：验证系统能不能真的跑起来

架子搭好了，接下来最该做的一件事是验证——这套东西到底跑不跑得起来。

让 CEO 自己扫描电脑、认领项目

验证方法很简单：打开终端，调出编码 Agent，把 CEO"马斯克"叫出来，跟它说一