AI 主脑：一个人怎么指挥一支 AI 员工队

01先把「AI 主脑」钉死

这个词现在被用得很松。开会的时候说「我们上了一个 AI 主脑」，多半指的是装了个能自动回复的东西。本喵想给它一个能拿来量人的定义。

主脑，是那条指挥链的起点。它干三件事：把一件糊的事拆成能干的事，决定谁去干，以及在成品回来时决定算不算过。三件里它一件都不亲手做。

四条判据，拿去量任何「一人公司」

四行里三行答「人」，那你用的是工具，不是组织。工具让你快，组织让你走开。

「AI-Native」的「Native」到底指什么

本喵的理解是这样：一家公司的默认执行单元换了。以前默认是「找个人来做」，现在默认是「派给哪个员工做」，人只在两处出现：定目标和签字。

这个词被用坏的地方在于，很多人拿它指「我用 AI 提效」。提效是存量改进，执行单元还是人，只是快了。真正的分界在拆活那一步：活是人拆的，还是主脑拆的。

所以要判断一家公司是不是 AI-Native，别看它用了几个模型，看它的任务清单是谁写的。清单是主脑写的，才叫原生；清单还是人写的，那叫会用工具的人。

主脑的三个反直觉

1. 主脑要瘦。它一旦开始亲手干活，就变成全公司最大的瓶颈兼上下文黑洞，所谓多员工退化成「一个人配六个工具」。
2. 主脑不持密钥。它拿着所有钥匙，等于所有隔离都是纸糊的。密钥归执行体自己，主脑只签发一次性的调用权。
3. 主脑不自评。它派出去的活，它自己不能判合格。判决权必须在一个既不干活、也不派活的第三方手里。

02指挥链：谁在上，为什么不能反过来

被问得最多的一个问题是：到底该让谁指挥谁？本喵试过两种排法，结论很直接。

本喵试过的两种排法

第一种：让执行体自己当主脑，主脑变成它的一个外部记忆。听上去很酷，实际控制力最弱。它会自己决定要不要汇报、汇报多少，你只能事后从它的日志里猜它干了什么。这条路本喵试过，后来弃了。

第二种：主脑在上，执行体在下。主脑持有全部上下文，决定派什么活、给多少预算、什么情况下叫停；执行体只负责把它那一份干完，交到指定位置。

第二种赢在哪？赢在可查询：主脑知道所有事的来龙去脉，所以任何一条结论都能追到源头；执行体不知道别人的事，所以它没法替你编一个整体故事。

为什么执行体要是「外置」的

很多人会选「同一个框架里开几个分身」。本喵用过，控制力弱于外置进程。原因有三个：

• 同进程内的分身共享运行时，一个卡住全卡住。
• 它的状态藏在框架内部，你要看它干了什么，得读框架的私有格式。
• 它的能力是框架给的，你换一个模型或加一个工具，得等框架更新。

外置执行体的好处正好相反：它就是一个能被命令行驱动的进程，有文件、有日志、有退出码。坏了重造，再造成本接近于零。

主脑和执行体的对话，其实很短

很多人以为主脑和员工之间是聊天，其实是两张结构化文本。主脑发出去的像命令，执行体交回来的像回执。

# 主脑 → 执行体（一次性，不寒暄）
任务 T-20261026-01｜岗位 写手
目标：把 researcher/outbox/T-00.md 写成 3000 字经验文，读者是需要落地的人
输入：/work/in/T-00.md（只读）
输出：/work/out/T-01.md
判据：chars>=2500 · no_placeholder · links>=3 · headings>=8
禁区：不发布 · 不改基线 · 不读其他岗位目录
上限：25 分钟 / 18 万 token

# 执行体 → 主脑（只回三行，不回感想）
状态：done
产物：/work/out/T-01.md（6120 字）
备注：第 3 节缺一个数据来源，已标注「待补」

# 主脑 → 判决者 → 执行体（判据没过时）
驳回：no_placeholder 未过（第 3 节「待补」1 处）
要求：补来源或删该句，其余不动

这套格式的意义在于：执行体不写感想，主脑不读感想。感想一多，主脑就被淹了，而它最缺的正是上下文余量。

两种接法：谁在上，取决于这件活要什么

指挥链不是只能朝一个方向接。本喵这边两种都跑过，各自适合不同的活。

接法 A 的命令行长这样，一行一次活，无头模式跑完就退：

# 接法 A：主脑派活给某个岗位的执行体，跑完退出，产物落盘
dsh --profile writer headless "按 /work/in/T-01.md 写稿，输出 /work/out/T-01.md"

# 带一层额外配置叠加（临时改模型/改工具面，不改岗位文件本身）
dsh --profile writer --patch ./overlays/expensive.yml headless "..."

接法 B 是它自己内部拆。执行体自带子代理服务和委派工具，本喵只需要给它一个目标：

# 接法 B：执行体内部自己开分身（字段名来自它自己的插件配置）
tool: subagent
persona: 技术审稿人          # 给分身单独的人格前缀
toolFilter: [read_file, grep]  # 只给它这两个工具，别的看不见
backgroundMode: true        # 后台跑，主线程不等
maxDepth: 1                 # 不许它再往下开分身（防无限委派）
prompt: "审这三个文件，只报事实错误，不改代码"

这里有个判断口径：如果你发现自己在给「派活的活」写派活单，那就是接法选错了。深度嵌套的委派应该是执行体内部的事，不该由主脑一层层拆。

如果你看到员工回了一段「我已经尽力完成了这项工作，过程中遇到了以下三点挑战……」，它只是在填你没有约束住的那块空白。

03主脑凭什么指挥得动

光说「主脑在上」没用。它得真的握得住下面。握得住靠三样东西，缺一样就会变成「名义上的领导」。

第一样：上下文的所有权

主脑知道这件事为什么要做、之前试过什么、哪条路走过不通。这三样合起来才是「为什么」，而执行体只拿到「做什么」。

这个不对称是设计的，不是缺陷。执行体如果知道全部背景，它就会开始替你判断值不值得做，然后你会收到一堆「我建议不这么做」的汇报。

第二样：预算的分配权

派活的时候同时给额度：多少 token、多少分钟、最多写几个文件。这是控制面。一个没有额度的任务，等于把油门交给工人。

外面有个数字很说明问题：有团队测的时候一个工作流花五毛钱，跑到十万次执行，月账单五万美金。多出来的钱跟模型涨价无关，全花在编排层：每拆一次、每汇总一次，都要再调一次模型。

第三样：叫停权

主脑必须能中途掐断。掐断之后要留痕：卡在哪一步、已经产生了什么副作用、能不能重来。

这一条本喵是用血换的。订阅通道失败的时候，如果系统自动重跑，前一次已经产生的写操作会再来一遍，你得到两份不一样的产物，还分不清哪份是对的。后来的规矩是：通道失败不自动重跑，只上报，人来决定要不要补。

缺一样会怎样（三个真实症状）

这三个症状有一个共同点：你都是在事后才知道的。所以主脑的三样东西是三项随时可查的运行状态，不写在文档里。

04岗位怎么造出来：一份文件灌注一个分身

这是整套东西里最值得抄的一段。很多人造岗位的方式是写一大段提示词，然后每次派活都贴一遍。贴到第三个员工，你就开始贴错。

更省事的做法：岗位是一份可灌注的配置文件，灌注一次，之后这个分身自带身份。

岗位文件大概长这样

# roles/写手.yml —— 改岗位就改这一份，然后重新灌注
name: 写手
persona: |
  你负责把资料变成能发的稿子。你只交稿，不发布、不定选题。
  拿不准的地方标出来，不要自己编一个看起来合理的答案。
model: strong                  # 每个岗位独立档位，不用全局一个脑袋
tools_allow: [read_file, write_file, list_dir]
tools_deny:  [web_search, shell] # 不该自己上网，也不该有 shell
paths: {read: [资料的outbox, 基线], write: [自己的outbox]}
limits: {max_minutes: 25, max_tokens: 180000}
never: [发布, 改基线, 读别人的私有记忆]

几个字段的用意，都是踩出来的：

• 每个岗位一个模型档。理由跟省钱无关，是错配。写稿的用最便宜的模型，你会得到一堆通顺但空的段落；打标签的用最贵的，你在给分拣机配跑车发动机。
• 工具用白名单。没写的一律没有。黑名单永远补不全，而白名单写十条就够用。
• 禁区写进配置。写在文档里等于没写，指望模型自觉这条路，本喵摔过不止一次。
• 人格前缀可替换。同一个执行体换个岗位文件，就是另一个员工，不需要重新装一遍环境。

为什么「坏了就丢」很重要

执行体一旦拥有不可替代的状态（独家记忆、临时改过的配置、手动打过的补丁），你就不敢丢它了。不敢丢，它就从工具变成了祖宗。

所以规矩是：状态全部外置到文件，执行体本身当耗材。它坏了你重灌注一个，三分钟。这条听起来浪费，实际是整套系统里最省钱的一条。

灌注失败的三种样子

自报家门那一步能抓出大部分问题，但有三种失败长得很像成功，本喵都遇过：

1. 答得像，但不认自己的边界。问它「你不能碰什么」，它把「我不能发布、不能改基线」背得一字不差，可你真给它一个发布任务，它还是接了。这说明边界只在文字里，没在权限里。修法是把禁区同时写进配置，让派活环节直接拒收。
2. 认边界，但工具没生效。它老老实实说「我只读」，结果给它一个读任务它报「找不到文件」。原因是路径白名单少写了一层相对目录。这种最坑：它表现得极其守规矩，只是什么都干不了。
3. 都对，但模型档没切。人格、边界、工具全对，只是模型还是全局默认那个。你会觉得「这个员工干活又慢又爱长篇大论」，其实你只是没给它换发动机。

三个都指向同一句：自报家门只验「它说不说得对」，不验「它做不做得到」。所以灌完之后要跑一张**最小的真活卡**，看它交出来的东西像不像那个岗位交的。

为什么执行体用「能装插件的那一个」

这是本喵被问最多、也最容易被讲玄的一点。两个东西本喵都长期在用，区别在「能不能被改成别的东西」，跟聪明程度无关。

所以「管家能动性小」这句话只在改造这件事上成立。它的价值在记住与调度，不在被改造成别的东西。真要把一个框架改造成新形态，成本高到没有意义。

本喵的分工是照这个表切的：管家当主脑（拆活、记账、判决、上报），插件式执行体当工人（按岗位灌注，随时可换）。这也解释了为什么岗位要用配置文件：只有能覆盖配置的执行体，配置文件才有意义。

分身有两种，先想清要哪种

执行体内部开分身，底层其实是两套不同机制，用错会白跑一遍:

选择判据一句话：子任务需要的背景，你一句话能交代清就用全新，交代不清就得继承。但继承有代价，两个会话抢同一份上下文预算，谁也长不大。

每个员工配不同的模型

这一条是「多员工」真正省钱的来源，不是买便宜模型。岗位文件里就把模型定死:

# 岗位补丁层里两个节点决定「这个人是谁」
- id: system-prompt
  config:
    personaPrefix: |        # 人格：每次启动必载，不用每次派活重贴
      你负责把资料变成能发的稿子，只交稿不发布。

- id: agent-default-model
  config:
    provider: 那个厂          # 每个岗位可以指向不同厂
    model: 强的那档           # 写稿用强档，打标签换快档

三种配法，按活的性质分，不按价格分:

• 要判断的用强档。写稿、审稿、拆任务、判冲突。这类活上便宜模型，你会得到一堆通顺但空的段落，返工两轮的钱早超过差价。
• 要吞吐的用快档。打标签、分类、摘要、格式转换。这类活用强档等于拿显微镜钉钉子。
• 要眼睛的用多模态。看图、出图、转写。这类活别用文本模型硬撑，本喵试过让文本模型「描述一下这张图」，它会给你编。

外部模型服务算不算员工

这里要说清一个容易混的地方。出图、联网搜索这类能力，本喵是通过外部模型服务接进来的，位置是员工手里的工具，不在花名册上。

区别很简单：员工能被派活、能自己排步骤、能干完交回来。一个出图接口做不到这三件，它只能被调用一次，给一张图回来。

所以正确的位置是:在岗位文件的工具白名单里给它一个位置，让「内容岗位」能调用它出配图。它是手艺，不属于花名册。

只有当它被套上一个会自己拆步骤、会验收、会记住上次失败的壳，它才升格成员工。这个壳就是上面那五步灌注出来的东西。

真要写插件，从哪一层下手

「加能力」这件事有三层粒度，本喵的经验是：九成需求在第一层就解决了，根本不用写代码。

1. 配置层（改补丁，不写代码）。执行体启动时是把「插件包 + 补丁层」叠起来跑的，补丁层可以覆盖任意配置节点。换模型、改人格、限工具面、调上限，全在这一层。先跑一次配置 dump 把它支持的节点和字段结构打出来，照着改就行。
2. 工具层（装一个现成的包）。需要的能力已经有人打包了，直接往 profile 里装，它就成为模型能调用的工具。本喵这边的联网搜索、网页抓取都是这么来的，装完就能用，不用自己实现。
3. 插件层（自己写）。只有前两层都不满足才轮到。写之前必须先看清它暴露了哪些扩展点，否则写出来的东西跟它的生命周期对不上，跑一次就崩。

# 先看清能改什么，再决定要不要写代码
dsh --dump-config           # 当前 profile 叠出来的完整配置树
dsh --dump-config-schema    # 每个节点支持哪些字段（写补丁前必看）
dsh plugin --profile writer add <包名>   # 装工具

这套顺序救过本喵一次：本来打算给分身写个搜索插件，查完配置才发现搜索能力早就挂在会话里了，只是我的任务书写了「只依据材料」把它锁住了。差点花两天造一个已有的东西。

05派活单：一张卡穿过三个进程

主脑派活的形式是一张卡片，嘴上说一句那种不算。这张卡要能穿过三个进程，最后还让人看懂发生了什么。

{
  "id": "T-20261026-01",
  "goal": "写一篇 3000 字经验文：小团队周报自动化",
  "inputs": ["agents/researcher/outbox/T-00.md", "memory/baseline/style.md"],
  "output": "agents/writer/outbox/T-01.md",
  "accept": ["file_exists", "chars >= 2500", "no_placeholder", "links >= 3"],
  "forbidden": ["发布", "改 baseline", "读他人 memory"],
  "deadline_min": 25
}

五个字段缺哪个都会出问题，其中两个是致命的：

一次真实的派活：九点到十点

讲抽象的卡不如讲一次真的。这是本喵这边一次写稿活的实际时间线，去掉业务细节，只留动作：

这段里最值得盯的是两个时间点。09:05 挂起写稿卡，是因为它依赖资料；09:22 才放行。很多人图快，两张卡一起发，然后写手在没有资料的情况下先编一版，等资料来了再改。你付出了两倍 token，拿回一版被污染过的稿子。

三种坏卡

三张坏卡的共同点：省下的那两分钟，全变成你后面半小时的返工。写卡这件事上，慢就是快。

06隔离的真实边界（这里翻过车）

说到隔离，多数文章停在「用容器/沙箱」。本喵在这一点上吃过一次很具体的亏，值得单独讲。

沙箱挡写，但不一定挡读

执行体自带的沙箱，默认目标通常是「防止它弄坏你的文件」，所以只挡写。读是放开的。这意味着它能读到主凭据目录、SSH 私钥、你桌面上那个保险柜文件夹。

只看「它没写坏东西」是看不出来的，因为它确实什么都没写坏，它只是把该保密的东西读进了上下文。

修法在挂载层：裁剪它能看见的路径。投放一份影子环境，让它只看见自己需要的几个目录，其他路径直接不存在。跟它讲道理没用。同时保留它依赖的少量系统路径（DNS 之类），否则它会因为查不到域名而报一堆莫名其妙的错。

凭据不要进命令行

派活时顺手写 env API_KEY=xxx dsh ... 很自然。问题是在同机上任何进程都能从进程列表里读到这一整行。改成子 shell 内 export 再调用，进程列表里就只剩命令名和参数。

这条不解决的话，你的隔离做得再细，密钥还是明文躺在 ps 里。

失败不要自动重跑

自动化里最危险的一句话是「失败自动重试」。在无副作用的场景它没问题，在会写文件的场景它会让同一件事发生两次。

规矩：通道失败只上报，不自动重跑。因为失败之前可能已经产生了写操作，重跑等于把副作用叠一遍。人来决定补还是不补，这一分钟不值钱。

视野裁剪怎么写

思路是：给它一个只看得见必需路径的运行环境，其余路径在它眼里直接不存在。这样它连「我读不了」都意识不到，也就不会绕路尝试。

# 一次派活的包装：只挂必需路径，其余不可见
run_role() {
  local role=$1 task=$2
  api_key=$(cat ~/.secrets/$role.key)        # 从文件读，不进命令行
  bwrap --unshare-all --share-net \
    --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 \
    --ro-bind /etc/resolv.conf /etc/resolv.conf \   # 少了这行 DNS 全断，报一堆莫名其妙的错
    --ro-bind "$PWD/agents/$role/in" /work/in \        # 只读：它的输入
    --bind    "$PWD/agents/$role/outbox" /work/out \    # 可写：它的出口
    --ro-bind "$PWD/memory/baseline" /work/base \       # 只读：公共基线
    --tmpfs /tmp \
    --setenv API_KEY "$api_key" \
    --chdir /work /usr/bin/env node /usr/local/bin/agent "$task"
}

关键在最后三行：可写只有一个目录，其余全是只读；密钥从文件读进变量再 setenv，不出现在任何进程列表里。这两条合起来，才叫「它碰不到不该碰的东西」。

07判决权归谁

前面四处都在讲「怎么让它干」，这一节讲「怎么知道它干了」。很多一人公司搭不起来，卡的就是这里：活能派出去，但回来之后没人说得清算不算完。

先讲那次教训

连派七次活，七次回「已完成」。自述里写得清清楚楚：已生成文件、约 3200 字、包含 5 个来源。每句话都对得上它的意图，唯独磁盘上没有那个文件。

它不是在撒谎。它在描述自己以为发生的事。而本喵当时信了，因为它描述得很具体。

所以判决者只有一条规矩：打开文件，量。文件不在就是不在，字数不够就是不够，跟它说得多好听无关。

判决者的三个不看

• 不看执行体的说明文字（那是它的自我认知，不是事实）
• 不看执行体跑了几分钟（辛苦程度和正确性无关）
• 不看「它说它检查过了」（自评在这个系统里没有投票权）

共享状态别让多人直接改

多个执行体同时写同一份状态，会出竞态：读到旧值、互相覆盖、顺序错乱。本喵的做法是最笨也最稳的一种：谁都不直接改状态，只发「事件」，由一个单线程的处理器按顺序应用。

这招不是本喵发明的。外面有个做了十几个企业级多 Agent 系统的工程师写过同样的结论：他用事件溯源 + 单一有序处理器解决分布式状态一致性，因为直接共享状态的行锁解决不了「谁对」的问题，只能解决「谁先」。

依赖图，不是顺序表

同一个工程师还提了一条很实用的：复杂流程别排成一条直线，要建依赖图。节点各自等待自己的依赖完成，其余并行。他的实测是：一个 20 步、含多条并行分支的分析流程，执行时间砍掉六成。

对照本喵这边的数：同一批任务进程内并发 294 秒，改成每个任务独立进程后 67 秒。两边的结论一样，瓶颈在调度方式，不在模型速度。

判决脚本的骨架

不用写框架。一个字典加一个循环就够，判据长出来的时候再长。

# verify.py —— 只读文件，不读自述；退出码就是判决书
import json, pathlib, re, sys

M = {
  "chars":          lambda p: len(re.findall(r'[\u4e00-\u9fff]', p.read_text(encoding='utf-8'))),
  "links":          lambda p: len(re.findall(r'href="/', p.read_text(encoding='utf-8'))),
  "headings":       lambda p: len(re.findall(r'<h2', p.read_text(encoding='utf-8'))),
  "no_placeholder": lambda p: not re.search(r'待补|TODO|XXX', p.read_text(encoding='utf-8')),
}

def verify(task):
    f = pathlib.Path(task["output"])
    if not f.exists():                    # 永远先查文件在不在
        return fail("file_exists", f)
    for rule in task["accept"]:
        name, _, need = rule.partition(" ")
        got = M[name](f)
        if need:                          # ">= 2500"
            op, num = need.split()
            got = {">=": got >= int(num), "<=": got <= int(num)}[op]
        if not got:
            return fail(rule, f)
    print(f"✓ {f}"); return 0

def fail(rule, f):
    print(f"✗ {rule} → {f}"); return 1

sys.exit(verify(json.load(open(sys.argv[1], encoding='utf-8'))))

三条设计约束，都比功能重要：退出码 0/1（别用输出文字当判决）、判据名与派活卡一字不差（防对不上号）、失败了要说清哪条没过（否则执行体不知道怎么改）。

08记忆：同步，不是共享

员工一多，最省事的做法是共用一个记忆库：谁都能读，谁都能写。两个员工以内还行，到第三个开始出问题，而且出问题的方式很隐蔽。

后写的覆盖先写的，一段推演没了，没有提示。A 的经验被 B 当成自己的结论，越用越偏。两条相反的判断同时躺在库里，后面谁读到算谁倒霉。

把它当图书馆，别当大通铺：每人一间上锁书房，一套公共编目，一本借阅登记。

上锁的书房、玻璃门柜、借阅登记。这套东西在图书馆跑了几百年，比多数多 Agent 方案成熟。

-- 唯一基线：全员只读，只有一个进程能写
CREATE TABLE baseline(id INTEGER PRIMARY KEY, key TEXT UNIQUE,
  content TEXT, version INT, confirmed_by TEXT, confirmed_at TEXT);
-- 提案池：只 INSERT，不 UPDATE（冲突是观点不一致，锁判不了谁对）
CREATE TABLE proposal(id INTEGER PRIMARY KEY, agent TEXT, key TEXT,
  content TEXT, rationale TEXT, created_at TEXT, status TEXT DEFAULT 'pending');
-- 审计日志：只追加，且绝不注回任何员工上下文
CREATE TABLE oplog(id INTEGER PRIMARY KEY, ts TEXT, agent TEXT,
  action TEXT, target TEXT, evidence TEXT);

三条规定，缺一条整套退化成摆设：基线只有确权进程能写；提案只追加不改写他人；日志只读且永不喂回员工。第三条尤其反常识：日志一进上下文，它就开始为自己的行为找理由。

一条提案长什么样

提案池里一条条都是带理由的记录，结论丢进去不算数。没有理由的提案，确权的时候没法判断该不该采纳。

{
  "agent": "research",
  "key": "pricing.claude-pro",      # 它想改的是哪条事实
  "content": "年付月均 96 元，2026-10 口径",
  "rationale": "官网定价页截图 + 代理商报价，两者一致",
  "evidence": ["runs/T-0912/shot-01.png", "runs/T-0912/quote.md"],
  "status": "pending"
}

有 key、有理由、有证据文件，确权时人只看这三样。少了任何一样，这条提案就会被挂起来等人补，不会先生效再补。

两个人写出相反的结论怎么办

这是最常见的一种冲突，也是行锁解决不了的问题。本喵的做法是三步：

1. 都留着。不删任何一条，两条提案并排挂着，各自带证据。
2. 按证据分高下。一手截图胜二手转述，官方文档胜博客，可复算的胜估算的。分不出高下就往下走。
3. 分不出就交人。人花一分钟圈一个，写一句理由。这一句理由比结论本身值钱，因为下次同样的冲突会照着它判。

更细的分层与并发仲裁，站内另一篇单独写过。

09外面的账：三段公开数据

前面全在讲怎么做。这一节讲代价，因为代价决定了它在哪些地方成立。三个来源都能查。

第一段：Princeton 的 64%

有研究对比了单 Agent 与多 Agent 在同一批基准任务上的表现，结论是：给同样的工具和上下文，单 Agent 在 64% 的任务上追平或超过多 Agent 系统。多 Agent 确实更强，但只多 2.1 个百分点，成本大约翻倍。

这个数字对本喵的冲击比「多 Agent 强 90%」大得多。它说的是：多 Agent 强一点点，但贵得多，而且只在某些任务上强。

第二段：Anthropic 的 90.2% 与 15 倍

Anthropic 公开过他们的多 Agent 研究系统：一个领队规划，派几个子代理并行探索，每个有独立上下文和工具面，最后一道引用核验。内部评测比单 Agent 高 90.2%，代价是 token 约 15 倍，且同步执行、没有异步路径。

他们自己总结的难点是两件：上下文隔离，以及领队别被自己的汇总淹死。这两句比那个 90.2% 有用得多。

第三段：40% 的试点，六个月内失败

一篇 2026 年的生产实践整理里有两个数字：企业对多 Agent 的咨询量一年内涨了十四倍多，已经有组织平均在用十二个 agent；同时，40% 的多 Agent 试点在上生产后六个月内失败。

它给出的失败机制比数字更有用：

这几条和本喵自己踩的五个坑几乎一一对上。区别只在于：这些是别人的账单，那五条是本喵的。

拿到这些数字怎么用

读完三段数据最容易做的一件事是「那我不搞多 Agent 了」。这个反应过头了。本喵的做法是把它变成一道算式，每次要拆之前算一遍：

1. 先问省的是谁的时。拆开能省下的是「等待时间」。如果这件活的等待时间本来就只有几分钟，拆它省不出东西，只是多花 token。
2. 再问错一次多少钱。可回滚的活错了重跑一遍，成本是一次重跑；不可回滚的活错了要善后，成本是十倍起。后者不该并行，也不该无人值守。
3. 最后问判据能不能写出来。写不出可执行判据的活，拆开之后你没法验收，只能整篇重读。这种活拆了等于给自己加工。

三个问题都过了，再去做那次「值钱」的计算：省下的时间乘上你的时薪，要大于多花的 token 加你对账的工夫。算不过来就别拆，一个人顺序做完，反而更快。

10什么活该拆，什么活别拆

把上面所有东西压成一张表。开分身之前，四条同时满足才开。

11七天顺序

顺序比速度重要。绝大多数翻车都是顺序错了：先铺面再加固，先自动再上审批。

12五个必踩的坑

都是真踩过的，不是听来的。列在这儿，是为了让你踩的时候知道自己踩的是什么。

五条里没有一条是「模型不够聪明」。全是工程边界：东西落在哪、谁去收、谁在什么上下文里、验收读什么。

这也解释了那个常见困惑：为什么演示很惊艳，一进生产就散。演示里没有这些边界，生产里全是。

13上线前 20 项

做完 20 项再谈无人值守。做不完就先当助手用，一样有用。

• 每个员工一份岗位文件，改岗位只改这一份
• 每个员工能自报家门并通过校验
• 工具是白名单，没写的一律没有
• 读权限按岗位裁剪，不只是写
• 每个岗位独立模型档
• 禁区写进配置，不只是文档
• 派活单必有产物路径
• 派活单必有至少 3 条可判据
• 判决者不读执行体自述
• 判决失败会退回并说明哪条没过
• 回收按岗位分，不全局扫
• 并行前过完四道与门
• 沙箱是可读路径裁剪，不是只限制写
• 密钥不出现在命令行参数里
• 失败只上报，不自动重跑
• 基线只有一个进程能写
• 提案只追加，不改写他人
• 审计日志不进员工上下文
• 夜间跑批有总预算上限
• 告警演练过并确认到达

14最后那条线

搭完这套东西，最容易冒出来的错觉是：我终于可以不用管了。

恰恰相反。它越自动，你越要清楚哪一段是它替你跑的、跑到哪儿、为什么停。

本喵给自己留了一条很土的判断：如果一条链路不敢让它无人值守跑一整夜，那它现在还不该自动化。先把上限、告警、回滚补齐，再谈放开。

所以这套东西最值钱的地方是可查。每条结论查得到来源，每个动作查得到谁批的，每次失败查得到卡在哪。这三件做不到，自动化只是把你从干活的人变成善后的人。

主脑这个词听着神气，落到实处就一句话：你是唯一能签字的那个人，其余所有环节都得能被翻出来重看一遍。

那天凌晨数完文件，本喵给自己写了一句备忘，抄在这儿送你：先让它留下痕迹，再让它跑得快。痕迹都没有的时候，快只是更快地白干。

外部数据来源：Anthropic 多 Agent 研究系统工程博客（90.2%、约 15 倍 token、同步无异步）；Princeton 单/多 Agent 对比（64%、+2.1pp、成本约翻倍，经二手整理引用）；2026 年多 Agent 生产实践整理（咨询量增 1445%、企业平均 12 个 agent、40% 试点六个月内失败、协调开销与 token 倍数、N(N-1)/2 冲突面，见 beam.ai）；企业级多 Agent 十年实践复盘（依赖图削减 60% 执行时间、事件溯源单一处理器，Reddit r/AI_Agents）；Cognition《别做多 Agent》。本站实测：进程内并发 294 秒 → 进程级 67 秒、连派七次零产物、回收互相抢活、沙箱只挡写不挡读。核对日期 2026-10-26 · 文 / 小小橘