YC 如何进行 AI-Native 组织改造：Agent 能力要向所有人开放

YC 一直走在 AI-Native 组织改造的前沿。

过去一年多，YC 的合伙人、Optimizely 创始人 Pete Koomen 在内部主导搭建了一套覆盖全员的 Agent 系统。

在一年时间里，演化成了 350+ 工具的内部注册表、一个全员可见的 Agent 对话系统，甚至每晚还会自动阅读当天所有对话、改进自身技能。在某些具体能力上，已经超过了任何一位合伙人单独的水平。

Pete 在最近的一期播客中，详细拆解了这套系统的构建经验、关键设计决策。除此之外，他也聊了很多关于如何构建好一个 AI Native 组织的心得。

在搭这套系统的过程中，Pete 形成了一个更大的判断：

真正的 AI-Native 组织和「把 AI 当 Copilot 用」的组织有本质差异。Copilot 是 2023–2024 年的做法，AI 辅助你完成具体任务，流程、决策、知识沉淀仍然在人的头脑里。真正的 AI-Native 做法是把 AI 作为整个组织运转的建设层，并且系统性地记录所有 artifacts，包括会议录音、Agent 对话记录、决策文档，让这些成为 Agent 可以学习、检索、利用的原材料。

同时，它还需要两个前提：Trust by default（默认信任）和Egalitarian（平等主义）。AI 能力必须向每个人开放，所有 Agent 对话默认对全员可见。这与大多数 command and control 式的企业是相反的，但只有这样，Agent 才能拿到足够广的上下文。

以下是对谈精华，在不改变原意的前提下，Founder Park 进行了编辑。

⬆️关注 Founder Park，最及时最干货的创业分享

Founder Park 正在持续寻找值得被看见的 AI 团队与项目。

我们将通过「AI 产品市集」、内容报道、社群分发等方式，帮你触达早期用户、获得真实反馈，以及建立关键连接。

如果你正在做 AI 相关的事，欢迎和我们聊聊。

01从给财务搭建 Agent 开始，一开始就放开权限

Gary：YC 这两三年一直在投资AI 公司，但很多人不知道，YC 内部也在用同样的东西来改造自己的组织。Pete 一直在主导这件事。从头说起吧，是什么契机让你开始做这个？

Pete：大概一年多前，我和几个工程师在跟财务团队合作，讨论要给他们建什么工具，记账分录（journal entries）、记录融资轮次（priced rounds），这些让 YC 运转的日常流程。

我同时看到两件事在发生。一方面，我们有个传统循环：财务团队向工程师描述复杂的工作流，工程师把它翻译成确定性软件，交回去，如此反复。这感觉极其低效。另一方面，这正好是 agentic coding 工具起来的时候，Windsurf、Cursor 已经很成熟，Claude Code 也差不多那时候推出。我在自己的机器上用这些工具，感觉像开了挂。然后回头看公司内部还在用老方法，这个鸿沟越来越大。

所以原始的想法就是：为什么不直接给财务团队构建能运行 Agent 的工具？让他们用英语提示词来表达工作流，而不是让工程师去写 Ruby 代码。

这个想法成为了整个 YC AI 基础设施建设的原始动力。Pete 与工程师 Jared 等人开始着手构建 YC 自己的 Agent harness，最初仅仅是一个针对财务场景的专用系统，但很快演变为一个通用的 Agent 基础设施层。

Gary：但最早其实不是编程 Agent，是 LLM 写 SQL 查询。我记得第一个版本就是这个，效果好到我很惊讶，非技术的人居然能直接提问。

Pete：对。我们搭了一个简单的 Agent 循环加工具注册表，第一个真正的 unlock 是 Jared 建的工具，给 Agent 执行只读 SQL 查询的能力。其实是两个工具：一个是查数据库，另一个是读模型文件（model files）。

Gary：Jared 说他觉得自己在「违规」。

Pete：确实。一开始我们的策略是给 Agent 非常有限的、范围严格的工具集。Jared 一直觉得不够强大，做不了他想做的事。然后有一天晚上他偷偷推了一个 PR：直接给 Agent 开放了整个生产数据库的完整只读权限。

Gary：然后它就起效了。

Pete：效果惊人。这其实预示了后来 OpenClaw 的经验，真正阻碍这些工具发挥威力的，不是技术能力，而是我们对安全和隐私的过度担忧。当你把担忧放下一点，你会发现这些东西强大得不可思议。

这就是那种工作与生活之间诡异的割裂，在家里用 Claude Code 或 OpenClaw 什么都能做，到了公司就被塞进一个狭窄的框里。我们一直在试图缩小这个差距。

02成本下降带来的不是需求减少，而是需求爆发

Gary：为什么一个 SQL 查询工具能产生这么大的效果？听起来很简单。

Pete：因为YC 有一个特殊优势，所有自研软件都跑在同一个 Postgres 数据库上。公司表、创始人表、财务交易表、内部 CRM 笔记，全在一个地方。别的公司把这些功能外包给各种第三方 SaaS，我们全是自己建的。

我现在可以问 Agent：「给我看过去四个 batch 里投了太空相关公司的所有投资人。」当所有上下文在一个地方，再加上一点 schema 说明，Agent 就能回答关于我们业务的任何问题。

Gary：最酷的不是让回答问题变容易了，是我们开始问以前根本不会问的问题。以前用 BI 工具，问一个这样的问题要好几小时写 SQL，所以除非特别重要你根本不会去问。如果需要去敲数据科学团队的门、排他们的工作队列，你问的问题就会少得多。

Pete：完全正确。这是杰文斯悖论的又一个实例，当你把团队间的来回沟通成本降为零，提问的数量和复杂度都会爆炸。杰文斯悖论说的是：当某种资源的使用效率提高时，人们反而会消耗更多这种资源。对 YC 来说，SQL 查询的门槛降低之后，不仅已有问题变得更容易回答，更重要的是人们开始提出以前根本不敢提的问题。成本下降带来的不是需求减少，而是需求爆发。

现在外面看这个的人，大部分还活在那个老世界里。2026 年了还是这样，有点不可思议。但也意味着前面还有很长的路可以走，这让人兴奋。

Gary：如果你的公司不像 YC 这样有统一数据库，怎么办？

Pete：我觉得正在发生的事情跟当年 Google 做 BigTable 类似，从 schema + join 变成一张针对检索优化的大宽表。你需要把数据反规范化（denormalize），放到一个针对 Agent 理解和检索优化的格式里。

Gary：这正是我用 Gbrain（Gary 自己开发的一套 agent）做的事。我把来自多个系统的数据整合进去，内置了 RAG、Graph RAG、RRF 混合重排序……所有关于检索的经验现在都在为 Agent 服务。当你给 Agent 一个灵魂，给它数据，让它知道你是谁、你关心什么，它就获得了疯狂的翅膀。它能看到你看不到的角落，你问一个问题它甚至会重新解读你的意图，给你一个坦率说需要一个非常了解你的人才能给出的答案。

你可以用 MCP 包一层，但老实说我直觉上觉得，这些模型用 MCP 和 CLI 都很强，但用 CLI 似乎更强一点。总之核心是：你得做反规范化，把它放到一个专门为 Agent 优化的格式里。

03上下文放在一个地方，要有工具注册表

Gary：YC 的 Agent 系统的架构是什么样的？

Pete：核心架构极其简单：一个 Agent 循环（agent loop）、一个工具注册表（tool registry）、一个模型路由器（model router）。其中，工具注册表是最核心的组件，它会把 YC 各团队构建的业务工具集中管理，将 Agent 的通用能力与 YC 的具体业务逻辑连接起来。

Gary：聊聊工具注册表。如果你在任何其他组织，会最优先建什么？

Pete：两件事：第一是把所有重要上下文放到一个地方，第二就是内部工具注册表（tool registry）。

工具注册表是让 Agent 在工作中真正有用的东西。一开始我们只有大约 20 个工具。但每次遇到一个可以用 Agent 改善的工作场景，就加一个工具。现在已经超过 350 个了，我刚查过。每个团队都在加自己的工具。

我可以管理我的 office hours，财务团队可以记账入账，活动团队可以管理 events，所有 YC 重要的工作都有对应工具。这些工具不仅在我们内部 Agent 系统里可用，也可以在每个人自己机器上跑的 Claude Code 里用。

工具注册表本质上是一个 Resolver（解析器），它告诉 Agent「我能做什么」。Agent 接到任务后，先查 Resolver 决定调用哪个工具，再去执行。

Gary：在工具之上还有一层 Skills。这部分我来说说我的经验，因为在 OpenClaw 里走了同样的路。

如果说工具（tools）是具体的操作接口，那么技能（skills）是对工具的更高层封装，一种可复用的、有明确语义的能力单元。我有一个叫 Skillify 的元技能（meta skill），做完某件新事、觉得结果不错，就说「skillify it」，Agent 就会把操作封装成可复用技能，注册到 Resolver 里，以后像调方法一样随时调用。Hermes Agent 也有类似的东西，他们叫别的名字，但本质一样。

但最重要的不是 Skillify 本身，是之后一步：我有个叫 check resolvable 的元技能，每次 Skillify 之后都会调用，让 Agent 检查所有现有技能，评估新技能是否与已有技能重复，并建议如何整合。它检查两件事，DRY（Don't Repeat Yourself）：有 10 个做同一件事的技能是坏的，有一个带参数的技能是好的。MECE（Mutually Exclusive，Collectively Exhaustive）：说出来有点丢人，这是麦肯锡做 slide deck 的术语，但模型天然理解这些概念。如果你有一个 DRY + MECE 的 Resolver 表，那就是最优解。

Pete：这些概念在各种 Agent harness 里被反复独立发现，Claude Code 有 skill registry，我们有 tool registry，OpenClaw 有 resolver。感觉就像 Unix 早期发现栈和堆一样，我们正在定义 Agentic 系统的基础原语。你在各种不同的地方，可能是 Claude Code、可能是我们自己的 harness、可能是 OpenClaw、可能是 Hermes，这些东西就是一遍又一遍地出现。

04Dream Cycle，Agent 每晚都在自我进化

Gary：你们也在做自动化的技能自我改进循环了？这是 OpenClaw 的 Dream Cycle，也是 Karpathy 的 auto-research，Codex 现在也加了 SLG（Self-Learning Goal）。到处在独立出现。

Pete：对。我们有一个通用 Agent，每天晚上会自动读取所有员工当天的 Agent 对话，寻找它本可以做得更好的地方，寻找如果提前知道就能更高效的上下文信息。运作逻辑是：白天员工使用 Agent 完成工作、产生大量对话记录；夜间 Dream Cycle Agent 读取这些记录、识别技能不足之处；次日相关技能的提示词被自动优化，系统整体能力提升。

我来举一个具体例子。我们有一个共享技能叫「两句话描述」（Two-Sentence Description），帮创始人把公司用两句话说清楚。

Gary：得解释一下这是什么，两句话描述是用简洁的自然语言说清楚公司做什么、为什么值得关注？听起来容易但出人意料地难。连最有经验的创始人都会忘记，因为他们有完美的上下文。而且奇怪的是，几乎没有人主动去做这件事。

其实 YC 本身就是一个 context engineering 的过程，我们一直在教人：你脑子里有完美的上下文，但好的沟通是在别人脑中复制同样的上下文。第一句，我能不能知道这到底是什么东西？如果我都不知道它是什么，连问题都问不出来，那我大概就在想什么时候吃午饭了。第二句，它为什么值得我注意？如果同一个房间里有五家公司做类似的事，而你没让我理解你为什么不同。

Pete：两句话描述是一种简单的原子能力，每个 YC 合伙人都反复练习过无数次的东西。Tom（YC 一位合伙人）最初手写了一个提示词教 Agent 怎么做。后来发生了件很酷的事，其他几位合伙人在一次 group office hours 上让 Spring Batch 的创始人当场练习两句话描述，给即时反馈。合伙人脑子里关于「怎么做好这件事」的隐性知识，在那次会议的来回交流中被显性化了，现在活在了那段会议转录的上下文里。

我们把会议转录交给 Agent，说：根据你从这里学到的，改进两句话描述技能。改进后效果肉眼可见地更好。这个技能现在比我们任何一个人单独做都要好。

Gary：这就是超级智能在组织内部诞生的方式。听起来是个小事，但你把任何组织的运营拆开看，就是无数个这样的「原子操作」。

Jack Dorsey 在 Block 做的事情其实也是同一个逻辑，他试图把 Block 变成一个围绕「帮全世界的人互相支付」的小型 AGI。而我们刚才走过的就是这个微观机制：有人写了一个提示词，更多人使用它，使用过程产生了大量 artifacts，这些 artifacts 被用来 metaprompt、在每日 Dream Cycle 中自动改进这个技能，最终这个技能超越了任何单个人的能力。你把组织里做的每一件事都这样处理，你就有了一个超级组织。不是理论，现在每个人都可以做到。

05所有 Agent 对话对 YC 全职员工可见

Pete：真正的 AI-Native 组织与「把 AI 当 copilot 用」的组织之间存在本质差异。Copilot 是 2023-2024 年的做法：AI 辅助你完成某项具体任务，但流程、决策、知识沉淀仍然在人的头脑中。真正的 AI-Native 做法是把 AI 作为整个组织运转的建设层（building layer），并且系统性地记录所有 artifacts，包括会议录音、Agent 对话记录、决策文档，让这些成为 Agent 可以学习、检索、利用的原材料。

Gary：有一个微妙但重要的设计决策是，默认情况下，所有 Agent 对话对 YC 全职员工可见。

Pete：对。每个 Agent 对话自动广播到一个内部 Slack 频道，任何人能加入查看。说实话这个决定不是轻松做出来的。我们讨论了很多，「那所有人都能看到所有东西，这样可以吗？」

Gary：最终我很高兴我们选择了开放。

Pete：这个透明度同时解决了好几个问题。第一，知识传播，任何人都能观察别人的用法来学习。我记得你开始大量使用时，你的用法非常有创意，很多人看了之后说「哇，我没想到还能这么用」。

第二，它让你可以在内部安全上更宽松。这些 Agent 在拥有广泛上下文访问权限时最强大，但这跟大多数组织的做法相反。通过默认公开广播，你建立了一种社会性控制。人们知道自己的操作是可见的，在高信任环境里这足以保护私密信息，不需要严格的技术访问控制。

第三，降低新员工门槛。以前新人可能需要六个月上手。现在他们可以通过阅读他人的对话记录快速了解 YC 的工作方式，不是靠占用资深合伙人的时间，而是通过 AI 自动完成的「学徒制」。你刚来不好意思问的蠢问题，问 Agent 毫无心理压力。我自己用编程 Agent 的第一个感受就是：那些我不好意思问人的蠢问题，问 Agent 完全没有心理负担。在组织层面同样如此，更多问题被问出来，人们上手速度快得多。

Gary：这就是 shared organizational brain，是我们能做到的最接近「连接彼此大脑」的东西。如果你把它定位为「让组织中每个人都能借助同事的集体技能和直觉来提升自己」，它的价值就变得极为清晰。

我记得 Anthropic CEO Dario 的那篇文章提到，AI 进步的很多阻碍不是技术性的，而是社会文化性的。两年前录会议还让人觉得奇怪、侵入性的，现在基本默认所有会议都在录了。这不是技术问题，是社会文化的变迁。当所有的会议、对话、工作过程都被记录下来，这些记录就成了 Agent 可以学习的原材料。

Gary：这揭示了超级智能组织必须具备的两个文化特质。我本来不会猜到它们是必要条件，但现在确信了。

第一，Egalitarian（平等主义），AI 能力必须向组织中每个人开放，不只是领导层。如果只有高层才能访问这些工具，组织就无法实现真正的智能化。

第二，Trust by default（默认信任），你必须愿意向员工开放上下文和数据，而不是将信息锁定在权限层级中。

这两者都不是大多数组织的默认状态。大多数企业是 command and control，信息按需分配，这与 AI Agent 需要广泛上下文才能发挥最大价值的特性根本矛盾。

Pete：这种环境在创业公司里最容易实现，小团队、目标一致、高度信任。另外你得愿意花钱，$10,000 到 $100,000 一年在 token 上。

Gary：但如果你投入了、建好技能体系、以开放方式跟团队协作，你基本上在活在 2028 年。现在花 $100K 做的事，两年后只要 $10K，再一年后只要几百块。届时所有人都这样做，我们会说「这就是公司现在的样子」。所以现在有一个一次性的时间跳跃窗口，你可以跳过所有现存的巨头、所有 Fortune 500、所有已有的创业公司。

我在想 90 年代公司开始给员工买电脑时是不是有类似感觉，那些电脑很贵、不稳定，但先买的公司获得了对手无法比拟的优势。

Pete：更准确说法是它抬高了底线。每个人都变强了，特别是新人，他们通过这套系统自动获得了以前需要半年才能积累的上下文。不是替代人，是让每个人都更强。这也是为什么你应该现在创业，因为大量老组织里的掌权者掌握资源和资本，但不相信这些。他们把上下文锁死，觉得不安全。

06未来应该是 Agent 包裹着确定性工具

Gary：你之前写了那篇很火的文章 Horseless Carriages。核心观点是什么？

Pete：那是对大量 AI 软件设计方式的批评。说实话，我觉得现在大部分还是那样，没变。

我看到的模式是：公司在原有软件的某个角落嵌入一小块 AI，但整体仍然是大量确定性代码包着。我用的例子是 Gmail 的 AI 写邮件功能。核心问题是：AI 的 prompt context 和工作逻辑被开发者锁死在后台，用户无法访问、修改、自定义。经典的「开发者决定一切，保护用户免受复杂性」思维，本质上是把 AI 的控制权集中在开发者手中，而不是交给用户。

*「Horseless Carriages」这个比喻来自汽车发明初期，早期的汽车在外形上模仿马车，只是把马换成了发动机，而没有根据新技术的特性重新设计交通工具。Pete 用同样的逻辑审视今天的 AI 软件，认为大多数仍然是「在确定性软件里嵌一小块 AI」，本质上还是马车。

Gary：Safetyism，我讨厌这个。

Pete：你再看我在本地用 coding agent 的体验，什么都能做，有超能力。当 AI 越来越成熟，正确方向是 Agent 包裹确定性工具（agent wrapping deterministic tools），而不是确定性软件包裹 AI。AI 最大的潜力在于将软件的控制权从开发者转移到用户手中。我们在内部也在尽力朝这个方向暴露能力给员工，但还有很长的路要走。

Gary：Chat 作为界面也是这个逻辑。我以前觉得 Chat 不是 AI 的最终 UI，改主意了。反思之后，Chat 最接近人类语言，人类语言最接近思维的表达。你不能把它塞进框里，那限制我们太多。Chat 是清晰智能的最近跳板。而且 Chat 是多模态的，文字、语音、图片、文件都行。你越来越信任 Agent，不需要复杂 UI 审查每一步。

Pete：偶尔你确实需要某个特定视图，Agent 可以当场生成一个针对当前需求的单页 JavaScript 应用，用完即弃，这个技能文件可以随时再调用。这就是 just-in-time software（即时软件）。

Gary：我有切身体验。一月到二月我用 Rails 写了约五十万行代码，Gary's List，包括深度研究、语音提取、事实核查整套 agentic 框架。但这是 2013 年的建法，上次我写代码就是 web 2.0 时代。Claude Code 让你可以这样做，但你不必这样做。过去三天我用 Gbrain 重写了同样的能力，大概一万行 TypeScript 加两千行 Markdown。更重要的是它是动态的：我的主编可以用自然语言修改规则，我根本不用碰代码。那五十万行 Rails 僵化、改起来慢十倍。这就是 just-in-time software 的真实体现。

Pete：最好的 AI 软件往往是最小的，只在模型能力之上加最少量的预写代码，让模型做最多的工作。我最喜欢的例子是 Pi，一个极简的开源 Agent harness。代码量极小，但你可以用 Pi 修改和扩展 Pi 自身，这种「自我扩展」的软件形态很迷人。我怀疑未来越来越多商业软件会以这种形式出现，一个极小的起点，加上 Agent 按需扩展。

Gary：Claude Code 也是。每次 Boris 来 YC 分享，最让我印象深的就是他对简洁的执念，让产品尽可能地小。

转载原创文章请添加微信：founderparker