AI 原生公司：一个人如何管理一支 Agent 队伍
核心要点
- 差距不在模型，在"工作怎么接线"：同样的权重、上下文窗口和 API，有人提效 2 倍、有人 100 倍，差别在于工作是怎么组织起来的，而不是用了哪个模型。
- 组织的四条映射：skill 文件 = 员工，resolver / 路由表 = 组织架构图，归档与执行规则 = 公司流程，触发测试与 Eval = 绩效考核。过去要靠招人、定岗、写 SOP、培训、考核才能搭起来的结构，现在很大一部分可以编码进 Markdown 与软件。
- 把计算放在正确的一侧：隐空间（latent space）交给模型——品味、判断、语义理解；确定性空间交给传统软件——存储、精确计算、状态管理、约束校验。多数 AI 应用的失败源于把任务放错了边。
- 公司不是三本书，是一座图书馆：决定 Agent 是天才还是金鱼的，不是图书馆里有没有那条信息，而是谁来决定此刻该摊开哪三本书——这就是上下文工程。公司大脑 = 图书馆 + 图书管理员，RAG 只是底层原语。
- 记忆必须配卫生管理：没人打理的知识库会变成"搜索功能很好的垃圾场"，自信地给出过期事实，坏 skill 把坏流程永久固化。每条事实要有出处，冲突要触发校验，需要人机混合的"图书管理员"持续修剪、合并、纠错。
- 永远不做一次性工作（never do one-off work）：结果满意时任务还没完，最后一步是 skillify——把成功过程沉淀成含指令、判断标准、所需上下文、工具用法、已知失败案例的可复用技能。同一件事第二次还要从头解释，说明第一次没有产生组织资产。
- 模型是租来的，能力是自己的：模型质量随厂商、版本、价格、可用性变化；公司自己的记忆、流程与积累的上下文才是能拥有的资产。
原文 英文原文：The AI-Native Company: When One Person Can Manage an Entire Workforce of Agents 讲者 Garry Tan（Y Combinator），由雷哥AI 解决方案整理转载；原视频
AI 原生公司：一个人如何管理一支 Agent 队伍
AI 真正的承诺不是让人写代码更快，而是让个人和组织有机会重新设计工作的基本结构。核心问题已经不再是"AI 能帮我做什么"，而是：如果一家公司从第一天起就围绕 AI 设计，它会长成什么样？
一、从提效到换一种工作方式
讲者 2013 年在 YC 做合伙人时兼建 YC 内部社交网络，全力投入时每天产出约 14 行有效逻辑代码——去掉注释、脚手架和重复内容后，这在当时是软件工程师的正常水平。如今他全职管理 YC、写代码时间更少，估计产出提升了约 400 倍。
代码行数显然不是好的生产力度量：AI 生成的代码可能冗长，很多是脚手架。但即使打一个极其苛刻的折扣，仍有 8 倍；温和估计则是几十倍。
具体是 8x、80x 还是 400x 并不重要。重要的是：提效 2 倍的人和提效 100 倍的人，可能用的是同一个模型、同样的权重、同样的上下文窗口、同样的 API。差别主要不在模型，而在工作是怎么接线的。
YC 在自己的创业公司里看到同样的模式：2025 冬季批次约四分之一公司的代码库 95% 由 AI 生成。这本身不能证明是 AI 代码带来了增长，但 YC 观察到——增长最快的创始人不把 AI 当自动补全，而是当成一支可以分派、训练、评估、改进的劳动力。
改变增长曲线的公司不是单纯用了更好的工具，而是把工作设计成了另一种样子。
二、Skill 文件即员工，路由规则即管理
一旦把 AI 理解为劳动力，Agent 工程里的很多概念就开始对应到组织里熟悉的部分：
| Agent 工程概念 | 组织对应物 | 职责 |
|---|---|---|
| Skill 文件 | 员工 | 定义一项能力，把一份具体工作说清楚到可以被执行 |
| Resolver / 路由表 | 组织架构图 | 任务来了谁接、用哪些资源、下一步流向哪里 |
| 归档与执行规则 | 公司内部流程 | 每种情况该加载什么信息、按什么程序走 |
| 触发测试与 Eval | 绩效考核 | 验证任务路由是否正确、每个技能是否真的产出了预期结果 |
历史上，建组织意味着招人、定岗、写流程文档、培训团队、管理绩效。这个结构中相当大的一部分，现在可以编码进 Markdown 文件和软件里。
当一个人坐下来用 Claude Code、Codex 或其他 agentic 系统工作时，他不再只是在写软件——他是在招聘、培训和管理一支由指令、技能、工具和上下文构成的劳动力。
因此，AI 原生公司不是在既有工作流上挂一个 AI 功能的传统公司，而是从一开始就把大量工作编码成可复用技能：Agent 在工程、销售、支持、运营、财务各条线上执行这些技能，工程师负责维护技能系统，并承担 Agent 还无法可靠完成的那部分工作。
人均产出的新量级
| 公司 | 业务 | 数据 |
|---|---|---|
| Emergent | AI 应用构建器 | 公开发布到九位数 ARR 用了 8 个月；跨过 1500 万美元 ARR 时只有 15 人 |
| Retell AI | — | 约 6000 万美元规模，团队约 40 人 |
这些数字会随时间变化，但方向清楚：原生围绕 AI 构建的公司，可以达到过去极其罕见的人均产出水平。
转变不限于工程师
随着 YC 自身变得更 AI 原生，媒体、活动、财务岗的同事也在建 skill 文件和定时任务。一位从不认为自己是程序员的财务同事，把大约一百个 Excel 工作簿整合成了一个内部应用——她没有变成传统意义上的软件开发者，她变成了 Agent 的管理者。
这才是更大的机会 目标不是造出几个 400 倍的工程师，而是建一个人人都能以极大杠杆运作的组织。
三、把计算放在正确的一侧
构建这样的系统，需要清楚区分两种截然不同的计算：
| 隐空间（latent space） | 确定性空间（deterministic space） | |
|---|---|---|
| 领域 | 大语言模型 | 传统软件 |
| 擅长 | 品味、判断、语义理解、猜测模糊需求背后的真实意图 | 数据存储、精确计算、状态管理、约束校验、可重复逻辑 |
| 性质 | 天然非确定性 | 确定、可靠、可审计 |
| 由什么引导 | 提示词、规则、skill 文件 | 代码、数据库 |
失败根源 AI 应用的很多失败，都源于把任务放到了这条边界的错误一侧。
案例：800 人活动排座位。 目标是让每个人左右两边的邻座都是对他特别有价值的人。
- 理解每位参会者的背景、兴趣和潜在连接 → 隐空间问题，模型能做。
- 但 800 个座位的坐标、占用状态和约束条件，不该只活在模型的上下文窗口里 → 属于确定性程序。
> 最强的架构不是要求模型做所有事，而是让模型像人一样理解，让软件像机器一样计算**。**
四、公司不是三本书，是一座图书馆
人类工作记忆极其有限——认知心理学经典的"7±2"说的就是人一次能同时握住多少信息单元。清单、组织架构图、文件柜、管理系统，某种意义上都是为这个局限配的外部义肢。
一个 AI Agent 可以在上下文里装下上百万 token——约一千页。可以想象成：Agent 同时摊开三本《哈利·波特》，在其中任意位置定位一个细节，并在几秒内跨三本书综合信息。 相比人脑同时把玩几个条目，这已经是完全不同的运作模式。
但三本书既很多，又很少。一家真实的公司不是三本书，而是一座图书馆——包含它历史上的每一封邮件、每次会议、每个决策、每条理由、每次客户对话、每份项目记录和每篇复盘。
决定 Agent 是天才还是金鱼的问题 不是图书馆里有没有那条正确的信息，而是——谁来决定此刻这张桌子上该摊开哪三本书。
这就是上下文工程（context engineering）的本质。
公司大脑 = 图书馆 + 图书管理员。 检索增强生成（RAG）只是底层原语，难的是围绕它的这些问题：
- 什么信息一开始就值得被记录？
- 它该如何被富化、打标、建立关联？
- 什么该放进高频访问的热记忆，什么留在冷存储？
- 两条事实冲突时，谁说了算？
- 过期、错误、重复的记录如何被识别和清除？
> 检索本身相对容易，构建一个值得被检索的东西才是真正的产品。
五、从助理到同事
讲者把自己的知识系统称为 GBrain：它作为 Agent 的检索与上下文层，决定一个大型个人/组织档案库中哪些部分该为当前任务加载。
他的个人系统起初相当于一屋子书，如今已增长到约 22 万页，大部分由 Agent 从邮件、会议、二十年的笔记和积累的个人经验中生成。
当一位创始人发来一封关于危机的邮件时，他的 Agent 能检索出所有相关的历史对话、找出遇到过类似问题的被投公司、并浮现出当时真正奏效的做法——这一切在他读完这封新邮件之前就完成了。
助理 vs 同事 助理响应一个孤立的请求；同事理解围绕这个请求的历史。
公司大脑的失败模式
| 失败模式 | 后果 |
|---|---|
| 没人策展的知识库 | 变成"搜索功能很好的垃圾场" |
| 过期事实未清理 | 系统会以完全的自信给出错误答案 |
| 坏的 skill 文件 | 把一个坏流程编码下来并无限重复 |
| 信息互相冲突 | 输出既不可信也无法审计 |
关键能力不是记忆，而是记忆 + 卫生（memory + hygiene）
- 每条事实都应有出处（provenance）
- 新信息与已有知识冲突时应触发校验
- 需要一个**半人半 Agent 的"图书管理员"**持续修剪、合并、纠错、重组
把公司大脑当作生产基础设施来对待，它的价值会复利增长；把它当垃圾场，它会产出一个"自信地错、且没人能追溯错在哪"的 Agent。
六、永远不做一次性工作
AI 原生组织变强靠一条简单但苛刻的纪律：never do one-off work。
Agent 第一次执行某项任务时，产出可能像一个没经验的实习生。人可以批评、要求返工、引导它做到满意。但结果满意时，任务还没有完成。最后一步是把它 skillify——把这个成功过程变成一个可复用技能，包含：
- 指令（instructions）
- 判断标准（judgment criteria）
- 所需上下文（required context）
- 工具用法（tool usage）
- 已知失败案例（known failure cases）
> 如果同一件事第二次还要从头解释一遍，说明第一次没有创造出组织资产。
持续把经验转化为技能的组织，每完成一次任务就变聪明一点；不这么做的组织，无论底层模型多强，每天早上醒来都会失忆。
模型是租来的，能力是自己的 模型质量是租来的——它随厂商、版本、价格和可用性变化。一家公司自己的记忆、流程和积累的上下文，才是它能够拥有的资产。
七、AI 原生公司的形态
今天从零开始建一家公司，可以采用与传统企业非常不同的结构：
- 核心团队保持小规模，并让每个人都能指挥 Agent
- 为重复性工作建立清晰、可测试、持续改进的 skill 文件
- 让创始人贴近代码、产品和一线信息
- 建公司大脑，让知识从第一周就开始复利
- 丰富的图书馆 + 主动的图书管理员，为每个任务选出正确的上下文
- 分离隐空间判断与确定性计算
- 把每一个有价值的已完成任务转化为可复用的组织能力
> 具体工具是次要的。 同样的原则可以用 OpenClaw、Codex 或其他 Agent 框架实现。关键是把技能当员工、把知识库当组织记忆、把上下文管理当作工作的基本组成部分。
八、Abundance is shipped software
很多人面对 AI 的第一反应是问"现有工作会怎么样"。这个担忧可以理解，但只盯着"替代"会忽略另一半图景：个人现在能够触及的知识与执行能力，过去只属于大型机构。
讲者提到一位朋友的儿子患有一种罕见癫痫。为了理解这个病，这位父亲组建了一个8 万个 Markdown 文件的仓库——一套只服务于一个孩子的知识系统。他没有实验室、没有经费、没有机构许可，就把自己推向了人类对这个特定疾病认知的前沿。他有的只是一台笔记本、一座图书馆，和一个能找到正确材料的图书管理员。
这不是煽情的支线故事，而是全文所述的同一套架构——图书馆、图书管理员，以及在正确的时刻摊开正确的三本书——只不过指向了某个人最在乎的东西。
人们长期以来面对难题时会说："要是能雇到那个专家就好了"、"这个代码库烂到没法修"、"这份档案太大读不完"、"这个数据集太乱清洗不了"。我们正在进入一个这些判断很多都不再成立的世界。
> AI 原生公司的目的不只是"用更少的人做更多的事"，更深层的目的是——让那些过去因成本、规模或专业门槛而根本无法启动的项目成为可能。
Abundance 不是一份政策白皮书，它是已交付的软件（shipped software）。
我们需要建的不只是 AI 原生公司本身，还有它下面那一层：记忆、上下文、技能，以及一座让每个未来任务都比上一个更容易的复利图书馆。
人类第一次可能真的有能力"把海煮沸"（boil the ocean）。
附一：全文架构总览图（修订版）
下图按原文八节内容重画，补齐了传播版总结图漏掉的部分：隐空间与确定性空间并列、图书管理员的卫生管理角色、Eval 自动校验、全员皆 Agent 管理者、人类工程师定位。
| 图上分层 | 原文出处 |
|---|---|
| 全员皆 Agent 管理者（工程/销售/支持/运营/财务） | 二、转变不限于工程师；「目标是建一个人人都能以极大杠杆运作的组织」 |
| 任务路由器 = 组织架构图 | 二、Resolver / 路由表 = 组织架构图 |
| 隐空间（数字员工）‖ 确定性空间（传统软件），中间标「放错一侧 = 失败根源」 | 三、把计算放在正确的一侧；800 人排座位案例 |
| 公司图书馆 ↔ 图书管理员（出处溯源/冲突校验/去重合并/冷热分层） | 四、公司大脑 = 图书馆 + 图书管理员；五、memory + hygiene |
| 上下文引擎：正确的员工·正确的信息·正确的时刻 | 四、上下文工程的本质 |
| 工作结果 → Eval 自动校验 + 人工抽检 → Skillify → 企业资产 → 回流路由器 | 二、触发测试与 Eval = 绩效考核；六、never do one-off work |
| 基础模型画成灰色虚线、悬在体系外 | 六、模型是租来的，能力是自己的 |
| 人类工程师：维护技能系统 + 兜底 Agent 尚不可靠的部分 | 二、工程师负责维护技能系统 |
附二：流传版总结图与评估
下图是流传的一张中文总结图，把全文骨架画成了一个闭环。
抓准的部分
| 图上元素 | 原文对应 |
|---|---|
| 任务路由器 + 数字员工 = Agent + Skill | "skill 文件是员工，resolver / 路由表是组织架构图" |
| 公司图书馆 + 上下文引擎 | "公司大脑 = 图书馆 + 图书管理员"，即上下文工程 |
| 满意 → Skillify → 企业资产 → 回流路由器 | never do one-off work，把成功沉淀为可复用技能 |
| 基础模型画成灰色虚线、标注"外部租用" | "Model quality is rented" |
| 底部"模型是租来的，能力是自己的" | 几乎是原文那句的直译 |
把基础模型画成灰色虚线、悬在体系外是这张图最好的一笔——原文的价值判断（模型可替换、非资产）被翻译成了视觉语言。Skillify 那条绿色回流线也对：全文的核心不是"AI 干活"，而是"干完的活变成资产"。
漏掉或走样的地方
1. 「把计算放在正确的一侧」整节缺失——最大的问题 原文用一整节 + 800 人排座位的例子讲隐空间与确定性空间必须分开，并明说"很多 AI 应用的失败源于把任务放错了边"。图里所有工作都由"数字员工"完成，没有确定性软件这一侧。 建议：在数字员工旁并列一个「确定性系统：数据 / 计算 / 状态 / 约束」框，与 Agent 双向箭头。
2. 图书馆只有进出，没有"卫生管理" 原文花大篇幅讲失败模式（垃圾场、过期事实、坏 skill 固化坏流程），对策是 memory + hygiene：出处、冲突校验、持续裁剪合并。图上"公司图书馆"是个被动书架，缺少图书管理员这个主动角色（溯源 / 去重 / 纠错 / 冷热分层）。
3. 「结果满意?」被画成了人工拍板 原文的四条映射里，触发测试与 Eval = 绩效考核，是自动化的。图里 Evals 被塞进"企业资产"清单，但判断节点写"结果满意?"，读起来像每次都要老板过目——这与"一个人管一支队伍"的规模化主张冲突。改成"Eval 自动校验 + 人工抽检"更忠实。
4. 丢了"人人都是 Agent 管理者" 原文特意举了 YC 媒体、活动、财务岗都在写 skill 文件，以及那位财务同事把 100 个 Excel 合成一个应用；并明说"目标不是造几个 400x 工程师，而是让每个人都有杠杆"。图顶部只有"创始人 / 小团队"，观感变成了"一个创始人 + 一堆 Agent"。
5. 次要：人类工程师角色缺席 原文里工程师有明确定位——维护技能系统 + 兜底 Agent 还做不可靠的部分。图里人类只在最顶端出现一次，之后全自动。
结论
覆盖度约七成，且覆盖的是最好讲的七成（组织类比 + 复利闭环）；漏掉的两节恰好是落地时最容易翻车的（计算放错边、知识库腐烂）。作为传播用的一页纸没问题，当作落地蓝图用则偏乐观——上述五条修订已在附一的重画版本中补齐。
Related Documents
- 英文原文：The AI-Native Company: When One Person Can Manage an Entire Workforce of Agents
- 运营一个 AI 原生的工程组织（Anthropic）
- LLM Wiki：构建个人知识库的一种模式（Karpathy）
- Claude Code 团队如何使用 Skills
- AI 技术博客索引
- 架构总览图源文件：ai-output/temporary/pictures/20260805-120351_gpt-image-2_A-clean-professional-Chinese-language-bu_1.png