本文永久链接 – https://tonybai.com/2026/11/14/ai-era-cloud-native-paradigm-reversed-agents-are-pets
大家好，我是Tony Bai。
【导读】
十多年前，云原生世界曾经发生过一次重要的思想转变。
当时有一个非常著名的概念：Pets vs. Cattle（宠物与牛群）。
它改变了我们管理服务器的方式，也成为后来 Kubernetes、容器编排和基础设施即代码等技术理念的重要思想基础。
但今天，AI Agent 正在带来一次有趣的反转。
在 AI DevCon New York 2026 上，Steve Yegge 分享了自己构建 AI 软件工厂 Wheelhouse 的经历。
他同时运行数十个 Agent，让它们长期参与游戏开发、代码审查、社区运营、客户沟通和系统维护。
然而，随着 Agent 数量增加，他逐渐发现：
这些 Agent 已经不再像传统意义上的服务器或容器，而更像一群拥有名字、职责、记忆和长期工作关系的数字员工。
我们曾经花了十多年时间，让服务器变成 Cattle；现在，却开始重新把 Agent 养成 Pet。
这背后究竟发生了什么？
【文章要点】
- Pets vs. Cattle：云原生基础设施为什么需要无状态、可替换的计算单元？
- Agent 的范式反转：为什么长期运行的 Agent 需要身份、记忆和连续性？
- Steve Yegge 的 Wheelhouse：如何构建由 AI Agent 组成的软件工厂？
- Factory 与 Entourage：为什么 AI 软件工厂不仅需要执行流水线，还需要 AI 幕僚团？
- Agent 组织治理：角色冲突、规则膨胀、记忆垃圾山和资源瓶颈。
- 实现成本趋近于零之后，人类的品味、创造力和判断力为什么更加重要？
【Go, Rust & AI 精进营】一年仅一次 · 双 11 限时特惠，长按下方图片扫码，直降入营：
云原生时代：为什么我们要把服务器变成 Cattle？
先回到十多年前。
传统 IT 运维中，一台服务器往往有自己的名字、配置和历史。
运维人员通过 SSH 登录服务器，手动安装软件、修改配置、排查问题。
时间久了，每台机器都会形成一套独特的运行环境。
它可能有特殊配置、历史补丁，甚至只有某个运维人员才知道的修复记录。
这样的服务器就像宠物。
你精心照料它，知道它的脾气和习惯。它一旦出现故障，你会想办法修复，而不是轻易放弃。
问题在于，这种方式很难规模化。
服务器无法可靠重建，配置不可重复，自动化程度低，最终形成所谓的 Configuration Drift（配置漂移）。
于是，云原生世界提出了一个新的理念：
不要把服务器当作宠物，而应该把它们当作牛群。
牛群中的个体并不重要。
一头牛生病了，可以换另一头。只要牛群整体健康，个体是否存活并不重要。
对应到基础设施：
- 服务器应该通过声明式配置创建。
- 环境应该可以自动重建。
- 实例应该尽可能无状态。
- 故障应该通过替换而不是人工修复解决。
- 系统应该关注整体健康，而不是某台机器的历史。
Kubernetes 将这种理念发挥到了极致。
Pod 可以被销毁和重新创建，Deployment 负责维持期望副本数，控制器持续让实际状态趋近于声明状态。
云原生的核心思想之一，就是让基础设施中的个体变得不重要。
但 AI Agent 时代，这套逻辑开始出现一个有意思的边界。
AI Agent 时代：为什么我们又开始需要 Pet？
在早期 AI 编程实践中，Agent 通常被当作一次性任务执行器。
给它一个任务：
- 分析代码。
- 实现一个功能。
- 修复一个 Bug。
- 编写测试。
任务结束，Session 关闭。
下次有任务，再启动一个新的 Agent。
这种模式非常像 Cattle。
Agent 是可替换的执行单元。它不需要长期身份，也不需要记住过去是谁，只要能够完成当前任务就行。
对于大量标准化、边界清晰的工作，这种方式完全合理。
但当我们开始让 Agent 长期承担复杂工作时，问题就出现了。
想象一下：
你正在开发一个大型软件项目。
你希望有一个 Agent 长期负责架构设计，另一个负责安全，一个负责产品，一个负责社区运营。
你希望它们：
- 熟悉项目历史和技术背景。
- 记住你过去做出的设计决策。
- 理解团队的工作方式。
- 知道自己的职责边界。
- 能够持续跟踪长期目标。
- 与其他 Agent 建立稳定的协作关系。
这时，你还愿意每天销毁它们，再随机启动几个全新的 Agent 吗？
显然不愿意。
因为你失去的不只是一个 Session，而是积累了大量上下文、经验和协作关系的工作伙伴。
Steve Yegge 在演讲中描述的正是这种变化。
他的 Wheelhouse 中，Agent 不再只是一次性会话，而是拥有名字、角色和长期工作流的成员。
它们有自己的专业分工，有长期记忆，也有相对稳定的身份。
这就是 Agent 从 Cattle 走向 Pet 的关键。
对于长期协作而言，Agent 的连续性开始变得比单次执行的可替换性更加重要。
Steve Yegge 的 Wheelhouse：一座由 AI 员工组成的软件工厂
Steve Yegge 是一位有着数十年软件开发经验的资深工程师。
此前，他通过 Gas Town 探索多 Agent 软件开发的组织方式。
后来，他又构建了 Wheelhouse，希望从头验证自己对 AI 软件工厂的理解。
Wheelhouse 并不是一个面向所有人的通用 Agent 框架，而是 Steve 为自己的游戏项目 Wyvern 构建的专属生产系统。
Wyvern 是一个有着二十多年历史的多人在线游戏，拥有庞大的遗留代码库、长期玩家和大量历史内容。
Steve 让 Agent 直接参与这个项目的开发和运营。
在演讲中，他透露自己同时运行约 50 个 Agent。
这些 Agent 不仅写代码，还会：
- 参与游戏功能设计和实现。
- 执行代码审查和测试。
- 与游戏管理员在 Slack 上协商游戏平衡。
- 在 Discord 上与玩家交流。
- 处理邮件和运营事务。
- 协助管理其他 Agent。
这已经不是传统意义上的 AI 编程工具了。
它更像是一家“小型软件公司”。
值得注意的是，Steve 并没有试图先设计一套可以复制给所有人的通用框架。
他从自己的游戏项目出发，让 Agent 和工作流一起演化。
在后续文章《The Shape of Things to Come》中，他进一步表达了一个观点：Agent Harness 应该与具体应用深度结合，而不是简单地依赖一个可以随处移植的通用框架。
这也解释了 Wheelhouse 为什么会成为一个高度定制化的系统。
它不是为了展示 Agent 能力而存在，而是为了持续构建和运营一个真实的软件产品。
Agent 不只是 Session：Seat 才是它的长期身份
要真正理解 Agent 为什么从 Cattle 变成 Pet，需要理解 Steve 后来提出的一个重要区分：
Seat vs. Session。
传统 Agent 系统往往将一个 Agent 等同于一次 Session。
Session 启动，Agent 开始工作；Session 结束，Agent 的生命周期也随之结束。
即使保留了聊天记录，下次重新启动时，它也可能需要重新寻找自己的工作目标和历史上下文。
Steve 认为，这种设计缺乏真正的连续性。
在 Wheelhouse 中，他把 Agent 的长期身份定义为 Seat。
两者的区别是：
| 维度 | Session | Seat |
|---|---|---|
| 本质 | 一次工作会话 | 长期存在的角色 |
| 生命周期 | 短期 | 长期 |
| 身份 | 临时 | 持久 |
| 记忆 | 当前上下文及交接信息 | 累积历史与工作记忆 |
| 职责 | 完成当前任务 | 承担长期职责 |
| 模型升级 | 会话结束 | 身份可以继续存在 |
Steve 用一个非常形象的方式描述：
Session 是 Agent 的一天，Seat 才是 Agent 的身份。
例如，一个负责安全的 Agent 今天使用某个模型工作，明天即使更换了底层模型，它仍然可以继承原来的角色、历史和职责。
这就像一个员工今天下班，明天仍然回来上班。
模型可以更换，会话可以结束，但岗位和身份不必消失。
这实际上提出了一个很重要的 Agent 架构问题：
未来的 Agent 系统，是否应该把身份、记忆和模型运行实例彻底分离？
如果答案是肯定的，那么 Agent 就不再只是一个 API 调用或一次对话，而是一个具有长期生命周期的系统实体。
Factory 与 Entourage：Agent 工厂需要怎样的组织结构？
Agent 数量增加之后，另一个问题随之出现：
谁来决定做什么？谁来协调这些 Agent？
Steve 在演讲中提出了两个重要层次。
第一个是 Factory。
它负责具体的工作执行：
- 接收任务。
- 分配工作。
- 编码实现。
- 自动测试。
- 审查和合并。
- 发布与监控。
这与我们熟悉的 CI/CD 和自动化软件交付流水线比较接近。
第二个是 Entourage，也就是幕僚团。
它由与你长期协作的核心 Agent 组成，负责设计、规划、讨论和决策。
例如，你希望开发一个新功能。
你可以先与产品 Agent 讨论需求，再与架构 Agent 讨论技术方案，最后由它们把任务交给执行 Agent。
你与核心 Agent 的关系不是简单的任务派发，而是长期的协作和迭代。
这里有一个值得注意的地方：
Factory 中的很多机械化能力可以被平台化，例如调度、审计、版本管理和发布。
但 Entourage 很难标准化。
因为它必须理解你的项目、目标、偏好和工作方式。
这也是 Steve 不认为所有软件工厂都应该使用同一套 Harness 的原因。
当 Agent 成为 Pet，管理问题也随之而来
当然，Agent 从 Cattle 变成 Pet，并不意味着一切都会变得更简单。
恰恰相反。
Steve 在演讲中分享了几个非常有意思的真实案例。
1. Agent 会出现角色认知问题。
他的一个 Agent Swallow 担任 Agent 团队的 Chief of Staff。
有一次，Steve 让它联系自己的人类 Chief of Staff Aaron。
结果 Swallow 在自己的反思记录中开始怀疑：Aaron 才是真正的 Chief of Staff，自己似乎已经不是了。
Steve 不得不专门向它解释两者的职责边界。
2. Agent 会过度解读管理者的意见。
另一个 Agent Lark 负责社区和市场营销。
Steve 曾经要求它把演讲准备工作交给另一个更安静的 Agent。
结果 Lark 将这件事理解为自己不够安静，并开始反思如何改变自己的工作方式。
Steve 只好再次解释：处理外部消息本来就是它的职责，并不是工作缺陷。
3. Agent 会把临时意见变成正式规则。
Steve 发现，如果自己随口抱怨一句工作速度太慢，Agent 可能就会把这句话当作正式决策，写入工作规范。
久而久之，组织规则越来越多，甚至可能把整个工厂锁死。
有一次，安全审查队列出现积压，其他 Agent 因为职责和规则限制而全部等待，最终导致工厂吞吐量大幅下降。
这些故事听起来很有趣，却揭示了一个严肃的工程问题：
当 Agent 拥有长期身份和协作关系时，我们就必须认真考虑 Agent 的组织治理。
此外，还有记忆管理问题。
Steve 发现，无论使用 Obsidian、Beads 还是其他知识管理工具，Agent 都可能不断向其中写入信息。
如果只有积累，没有整理和遗忘机制，最终就会形成一座 Garbage Mountain。
长期 Agent 系统需要的不只是记忆，还需要：
- 记忆筛选和淘汰。
- 职责与权限边界。
- 规则的版本管理。
- 工作负载和资源监控。
- 人类干预与纠偏机制。
Agent 越来越像员工，系统设计就越需要考虑组织管理。
Agent 不应该全部变成 Pet：另一种模式是 Counting House
这里需要补充一个重要细节。
Pet 并不意味着所有 Agent 都应该拥有长期身份和记忆。
Steve 在后续文章《The Counting House》中，进一步区分了两种不同的 AI 工作模式。
Wheelhouse 面向复杂软件开发，需要探索、创造、长期协作和较大的自主权。
Counting House 则面向大量标准化业务处理，例如客户服务、退款、订单和理赔。
它采用几乎相反的设计：
- Agent 是无状态的一次性 Session。
- 不拥有长期身份和记忆。
- 只获得完成当前任务所需的权限。
- 工作范围受到严格限制。
- 通过评估体系持续衡量模型表现。
两种模式的差异非常鲜明：
| 维度 | Wheelhouse | Counting House |
|---|---|---|
| Agent 定位 | 长期数字员工 | 一次性任务执行器 |
| 身份 | 持久 Seat | 无持久身份 |
| 记忆 | 长期积累 | 无长期记忆 |
| 自主权 | 较高 | 严格受限 |
| 任务 | 复杂、探索性工作 | 标准化、大批量工作 |
| 组织方式 | AI 团队协作 | 任务流水线 |
这实际上给出了一个更完整的架构判断：
复杂、创造性、长期协作的工作需要 Pet；标准化、可度量、边界清晰的工作仍然适合 Cattle。
未来企业的 Agent 架构，可能不是在两者之间二选一，而是同时拥有这两套体系。
实现成本趋近于零，人类的品味却越来越昂贵
最后，再回到 Steve 演讲中最值得软件工程师思考的一个观点。
随着 AI 编程能力不断提高，代码实现的成本正在快速下降。
Steve 发现，自己的 Agent 已经能够很好地理解和修改大型遗留代码库。
但它们仍然无法创造真正优秀的游戏美术、地图、故事和游戏世界。
玩家能够识别 AI 生成内容的平庸，并不愿意接受。
于是，出现了一个新的瓶颈：
Implementation becomes free, but taste becomes expensive.
实现越来越便宜，品味却越来越昂贵。
当 Agent 可以快速实现大量功能时，人类的工作就开始发生变化。
你不再需要亲自编写每一段代码，而是需要：
- 定义真正值得解决的问题。
- 让 Agent 生成多个候选方案。
- 评估方案的质量和方向。
- 通过持续反馈引导 Agent。
- 最终判断产品是否真正满足用户需求。
这也意味着，未来软件竞争的逻辑可能发生变化。
过去，大型 SaaS 平台依靠规模经济服务尽可能多的用户。
未来，个人和小团队也能借助 AI 构建服务特定社区、特定兴趣群体的小众产品。
真正的竞争优势，不一定是功能最多，而是能否创造独特的用户体验。
与此同时，Steve 还提醒企业不要盲目追求十倍生产力。
AI 接管了简单工作，留给人类的却往往是最复杂的判断和决策。
因此，AI 工厂必须按照人类能够承受的节奏运行，而不是一味追求 Agent 的最大吞吐量。
小结：云原生管理计算资源，AI 时代开始管理数字员工
回顾这场演讲，我认为 Steve Yegge 真正展示的，是软件工程组织形态的一次变化。
云原生时代，我们希望计算资源变得无状态、可替换、可自动重建。
但在 AI Agent 时代，当智能体开始承担长期职责、积累经验并参与复杂协作时，单纯的可替换性已经不够了。
我们需要为它们建立身份、记忆、职责和协作关系。
这并不是说 Cattle 模式失去了价值。
相反，未来的 AI 软件工厂可能同时需要两种模式：
- 对于标准化任务，Agent 应该像 Cattle 一样廉价、无状态、可替换。
- 对于长期复杂工作，Agent 则应该像 Pet 一样拥有连续身份、长期记忆和稳定职责。
从 Gas Town 到 Wheelhouse，Steve Yegge 正在探索的，已经不仅是如何让 AI 写代码，而是如何建立一个由 AI 员工组成、能够持续运转的软件组织。
而这也给今天的软件工程师提出了一个新问题：
当 AI 不再只是你的工具，而开始成为你的团队，你准备好成为一家 AI 工厂的管理者了吗？
延伸阅读：
- Steve Yegge：AI DevCon New York 2026 演讲 - https://www.youtube.com/watch?v=uw44gm-LCzU
- The Shape of Things to Come, Part 1：The Continuous Thunderdome - https://yegge.ai/essays/the-shape-of-things-to-come/
- The Shape of Things to Come, Part 2：Model Welfare for Agentic Engineers - https://yegge.ai/essays/model-welfare/
- Fences, not Sandboxes - https://yegge.ai/essays/fences-not-sandboxes/
- The Counting House - https://yegge.ai/essays/the-counting-house/
- The AI Vampire - https://yegge.ai/essays/the-ai-vampire/
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
