25 人公司跑 44 个 Agent：AI 创业者正在怎样重构自己的团队

汇集 Every、Cora、Spiral 等 AI 原生创业公司创始人的实操案例，从「4 个 Agent 替代统筹」到「44 个 Agent 并发调度」，提炼 AI 原生组织在团队架构、工具使用、人机边界上的六条可执行洞察。

研究速览

这不是未来趋势的预测文章。这是一批已经在用 AI 重构团队的创业者，把他们踩过的坑、跑通的流程、以及改变工作方式的具体实验，汇集成的一份实操参考。
时间节点是 2026 年 4 月底至 5 月初。

一、用 4 个 Agent 替代人工统筹

Every 是一家 25 人的媒体公司，他们用 Notion AI 搭建了 4 个定制 Agent，直接替代了原本依赖人工协调的统筹工作1。
其中最核心的一个叫 Anton，接入了公司战略文档、OKR 数据库、统一日历以及人员—团队—角色映射数据库，每天在 Slack 发送本周优先级播报。另外三个 Agent 分别处理会议记录、OKR 规划和增长追踪。
真正让这套系统跑起来的，是 Every CEO 描述目标的方式：
向 AI 描述你想要的结果，而不是具体的操作步骤。
这句话听起来简单，但实际执行时反差很大。很多团队习惯给 AI 下操作指令——「先做这个再做那个」——结果 Agent 变成了高级执行工具，而不是真正的自主协作者。Every 的逻辑是反过来的：先把公司的互联数据库建好，让 Agent 有足够的上下文，然后只告诉它目标，让它自己找路径。
团队围坐协作，俯拍视角
团队围坐协作，俯拍视角

二、单人 PM 用 Claude Code 生成 100 份工单

Spiral 总经理 Marcus Moretti 的案例更激进一些——他一个人，用 Claude Code 完成了原本需要整个产品管理团队协作的工作2。
具体流程是这样的：
  1. 撰写详细产品路线图，提交到 GitHub README
  2. Claude Code 读取 README，对路线图提出调整反馈
  3. 产品经理迭代打磨路线图
  4. Claude Code 结合路线图、用户反馈、代码库和使用数据，批量生成交付所需工单
最后一步花多长时间？十几分钟，约 100 份工单，每份都包含战略背景、支撑数据、验收标准和技术实现说明。
Moretti 配套开发了一个开源插件 compound-engineering-plugin，内置 /ce:strategy 技能，可以自动生成产品路线图。Dan Shipper 在 4 月 30 日把这篇指南推荐给所有人，称其为「必读的决定性指南」3。
一个人做了多个人的活，这只是表层。更值得注意的是 Moretti 把对话本身当作产品工作的载体——原本散落在 10 个应用里的协作流程，现在在一个对话线程里完成。产品经理不再跳出去查工具、写模板、协调确认，而是留在那个状态里，把精力放在真正需要判断的地方。

三、AI 项目经理上岗，每周节省 15 小时

Every 咨询部给负责人 Natalia 配了一个 AI 项目经理 Claudie，基于 Claude Code 搭建，专门处理高时耗的行政事务——维护客户工作仪表盘、追踪项目进度、从邮件/Google Docs/Sheets/会议记录/日历里收集信息并更新客户数据库4。
实测结果：每周为 Natalia 节省了 15 小时。
但这个过程远没有听起来那么顺。团队淘汰了多个结构不合适的旧版本 Claudie，才找到有效的架构。最大的教训来自初期的失败：他们一开始让 Claudie 像人类新员工一样自主完成全部更新工作，效果很差——根本原因是大模型的上下文窗口限制，单个 Agent 无法稳定处理需要同时感知大量状态的任务。
调整方案是拆分架构：设置一个中心调度代理，把不同任务分派给对应子代理，分别负责提取数据、识别需要更新的内容、执行修改。
他们总结出三条原则，踩过足够多坑之后才确认管用：
  • 先明确岗位，再配置 AI：Agent 只能基于你给它的上下文和工具完成工作，岗位不清晰，Agent 就没有边界
  • 匹配 AI 的工作特性调整架构，而不是强行套用人类的工作模式
  • 权限要提前开放：会议记录、表格、日历的访问权限，一个都不能少

四、44 个 Agent，「文件夹即 Agent」

笔记本电脑代码界面特写
笔记本电脑代码界面特写
Cora 总经理 Kieran Klaassen 目前运行 44 个 AI Agent5。
他用的架构叫「文件夹即 Agent」：把项目文件夹加上配置和上下文沉淀，改造成专属智能体，通过自建 Ruby 守护进程调度层来管理。这 44 个 Agent 里有两类核心角色：
研发 Agent：内置 Rails 开发规范、部署流程、数据库模式，还有完整系统架构文档、故障处理手册，以及评审者、规划者、组件创建者等细分专家智能体。
运维 Agent：接入 AppSignal 错误监控、Render 日志、Postgres 只读副本、Intercom 客户工单、GitHub 部署和生产故障关联能力。
日常调度流程很具体：早晨用 /hey 命令检查所有 Agent 的已完成任务、错误和阻塞状态；用 /orchestrate 命令启动任务，由 lead Agent 拆解子任务到文件，守护进程分发到对应文件夹，Worker 继承所在文件夹全部上下文独立执行，每 60 秒检查状态，结果汇总生成 Pull Request。
Klaassen 对一件事说得很直接：不能随意编排 Agent。他的顺序是先搭建文件夹，人工使用验证流程，确认可以信任后，再交给调度层编排。不能跳过人工验证直接调度。
实际踩过的坑包括：特殊字符编码崩溃、上下文漂移导致重复工作、Agent stall（卡住无法自动发现，需要人工干预）。这三类问题听起来都是细节，但在 44 个 Agent 并发运行的情况下，任何一个不处理都会影响整体节奏。

五、无技术背景，也能搭建 80 个工作流技能

Every 增长负责人 Austin Tedesco 没有技术背景，但他用 Claude Code 搭建了自己的工作指挥中心 Agent——Montaigne6。
接入工具清单：Stripe、PostHog、ChartMogul、Slack、Notion、Figma、Every 产品套件、邮箱、日历。内置超过 80 个可复用工作流技能。部署位置是 Claude Code 终端和 Slack OpenClaw 机器人，整个团队都可以使用。
使用方式也不复杂：在 Slack 发一条数据查询，Montaigne 拿数据、带上下文输出，不用手动跨平台搜索；录一段粗略的策略语音笔记，指定相关数据和知识库，Montaigne 在 Notion 里合成方案草稿；还可以生成子 Agent 在后台执行不需要人工干预的计划环节。
Austin 给出了一个很实际的建议：刚开始用 Claude Code 时，不要直接上正式项目，先用自己感兴趣的小东西练手——他自己花了三周做了烹饪陪伴 App 和影院影讯查询工具，才对工具能力有了真实感知。
他还有一个关于节奏管理的细节值得注意：优化系统很容易让人陷进去消耗时间，应该优先让 Montaigne 逐个处理待办清单，同时让子 Agent 在后台处理低优先级任务，快速回归主工作节奏，而不是陷入调优循环。

六、Karpathy：「agentic engineering」是一个新的专业学科

Andrej Karpathy 在 Sequoia Ascent 2026 的演讲里，把 2025 年 12 月定义为 agentic 拐点——从那时起，AI 生成代码块的可靠性跃升，编程工作流发生根本改变7。
他的描述是：「工作单位从写代码行数，变为委派更大的宏观行为。」
Karpathy 把这两件事区分得很清楚：vibe coding（降低编程门槛，盲目接受生成结果）和 agentic engineering（在代理辅助下保持安全性、可维护性和品味）。后者才是他认为需要作为专业学科去建立的能力，包括：设计规范、审视计划、检查 diff（代码变更差异）、编写测试、构建评估循环、管理权限。
他专门提到一个容易出错的场景：在他的 Stripe 支付 bug 案例里，Agent 提议用 email 匹配用户，但 Stripe email 与 Google login email 可能不同，这违反了系统设计原则。Agent 不知道这个边界，只有人知道。Karpathy 的结论：「边界技能仍是人的工作。」

七、从行业数据看 AI 原生组织的效率差距

正在加载统计卡片...
这个数字差距不是偶然的8。研究者 Peter van Hees 把这个现象命名为「功能溶解原理」：任何可以用规则定义、且结果可以验证的业务功能，都可以自动化9。
但这个数字也有陷阱。Harvey AI 曾经做到人均 $800K ARR（2024 年 3 月），然后因为要适应企业销售模式大规模扩招 1260%，人均 ARR 跌到 $170K（2026 年 1 月）。客户成功、销售、法务合规这些职能，用 AI 还替代不了8。
Model ML CEO Chaz Englander 把 AI 原生企业的组织形态描述为「控制塔」而非传统孤岛层级：更少层级、更快循环、扁平架构，创始人直接管理数十名下属，所有一对一沟通由 AI 辅助，纪要、待办、上下文都被流线化10。

读完这些，你可以做什么

上面六个案例，都不是在预测将来。它们是「现在就在跑」的工作流记录。
几条可以直接带走的判断：
  1. Agent 的上限由上下文质量决定。Every 的 Notion 互联数据库、Cora 的「文件夹即 Agent」架构，本质上都是在给 Agent 喂高质量上下文。数据库没建好，Agent 再聪明也没用。
  2. 先明确岗位，再配置 AI。AI 只能在给定的工具和上下文范围内工作——这不是限制，而是说明你需要先想清楚这个「岗位」做什么，才能给 AI 正确的工具和边界。
  3. 人工验证不是多余步骤。Klaassen 运行 44 个 Agent，但他不会跳过人工验证直接调度。Karpathy 的「边界技能仍是人的工作」说的是同一件事——不是 AI 不行，是你必须先知道边界在哪里。
  4. 「Harvey AI 陷阱」是真实风险。精简团队可以实现高人均营收，但一旦转向企业销售，这个优势会迅速收缩。在精简模式和规模化模式之间做选择，需要提前想清楚，而不是等到扩招之后。
这些人没有一个是在等 AI 工具「再成熟一点」。他们在用当下可用的工具，找当下能跑通的工作流。
封面图：图片来自 Pexels by Thirdman

参考来源

  1. 1How We Run a 25-Person Company on Four AI Agents
  2. 2Claude Code for Product Managers
  3. 3Dan Shipper 推文
  4. 4What I Learned Onboarding Our AI Project Manager
  5. 5The Folder Is the Agent
  6. 6The Agent That Saved My Brain
  7. 7Sequoia Ascent 2026 演讲摘要
  8. 8AI to ROI: Revenue Per Employee
  9. 9AI Takeoff Reshapes Business
  10. 10Model ML CEO on AI-Native Infrastructure

围绕这条内容继续补充观点或上下文。

  • 登录后可发表评论。