AI 企业的新模式：Steve Yegge 提出 Counting House，让 AI 在严密护栏下接管千万级业务

本文永久链接 – https://tonybai.com/2026/10/31/steve-yegge-counting-house-ai-enterprise

大家好，我是Tony Bai。

【导读】

当整个行业还在争论 AI 能否取代程序员时，企业中另一类工作，可能正在更快地迎来 AI 的大规模接管。

银行每天处理退款、航空公司应对改签请求、保险公司审核理赔、电信运营商处理客户投诉。这些业务涉及数百万乃至数千万次交互，流程复杂、规则繁多，过去很难完全自动化。

2026 年 10 月 27 日，资深程序员、软件工厂实践者 Steve Yegge 发布了一篇名为《The Counting House》的文章，提出了一种面向企业高吞吐量业务的 AI 部署模式。

它的核心思想颇为反直觉：不要让 AI 像员工一样自由行动，而要把它变成一个没有长期记忆、没有独立凭证、每次只处理一个任务的数字职员。

Yegge 将这种模式称为 Counting House。它与他此前探索的 AI 软件工厂 Wheelhouse 形成鲜明对比，也为企业如何把 AI 从试点项目推进到规模化生产，提供了一套值得研究的工程思路。

【文章要点】

• AI 企业模式正在分化。面向软件开发的 AI 工厂需要更大的探索空间，而大规模业务处理更适合受严格约束的专用 Agent。
• 无状态不是缺陷，而是架构选择。每次只处理一个业务案例，减少上下文污染，降低成本，并提升可审计性。
• 自主权必须逐级授予。从影子评估到辅助人工，再到自主回复和执行交易，每一步都应有评估数据支撑。
• 准确率不能代表业务安全。错误分类的代价可能相差数个数量级，企业必须评估错误类型、发生概率与实际损失。
• 模型不应直接持有业务系统的写权限。由确定性编排器验证资格、执行事务、保证幂等，并处理失败补偿。
• 企业真正的 AI 资产是自己的数据与评估标准。模型可以替换，业务意图分类、黄金样本和评估体系却应掌握在企业自己手中。

AI 企业的下一步，可能不是造出更聪明的 Agent

如果说过去两年 AI 工程领域最令人兴奋的事情，是大模型开始能够编写代码，那么接下来一个更现实的问题是：企业怎样才能让 AI 稳定地完成真实业务，而不是只在演示中表现出色？

在软件开发领域，Steve Yegge 已经给出过自己的答案。

他构建了 Wheelhouse，一套面向软件开发的 AI 工厂。多个 Agent 可以持续编写、审查和部署代码，也可以处理邮件、与游戏社区互动，承担原本需要一家小型创业公司才能完成的工作。

按照 Yegge 在文章中的描述，这套系统每周能够产生约 2000 至 4000 次代码提交。

但当任务从编写代码变成处理银行退款、航空改签、保险理赔时，情况就不一样了。

一个编程 Agent 可能需要理解整个代码库、探索未知问题、与其他 Agent 协作，并在遇到意外时自主寻找解决方案。

一个负责退款的 AI，却不应该拥有同样的自由度。

它不需要理解整家公司的所有业务，也不应该因为用户的一段话，就自行修改数据库、批准退款或调用任意工具。

更重要的是，这类业务的规模远超一般的软件开发任务。对于每年处理千万级客户请求的企业，真正的挑战不是让一个 Agent 变得无所不能，而是让大量 AI 调用能够以可控的成本、稳定的质量和明确的责任边界持续运行。

这正是 Yegge 在 2026 年 10 月 27 日发表的文章《The Counting House》试图解决的问题。

他提出的核心判断是：软件开发需要有探索能力的 AI 同事，大规模业务处理则需要被严格约束的 AI 数字职员。

这两类系统不应该采用完全相同的设计。

Counting House：把 AI 变成一次只处理一个案例的数字职员

Counting House 这个名字，可以理解为一座高度组织化的业务处理中心。

传统的企业业务流程通常是这样的：客户提出请求，系统将请求分配给人工客服，客服查阅业务规则、访问后台系统、判断是否符合条件，最后执行操作或提交审批。

Counting House 并不要求 AI 一次性取代整个客服部门。它首先把业务拆解成有限种类的任务，再让 AI 逐项接管经过验证的任务。

例如，一家航空公司可能面对以下请求：

• 查询航班状态。
• 申请改签。
• 申请善意补偿。
• 申请特殊出行协助。

它们看起来都是客户服务请求，但实际业务规则、操作权限和错误代价截然不同。

查询航班状态可以相对容易地自动化；改签涉及多个系统；退款需要验证资格和金额；特殊出行协助如果被遗漏，则可能直接伤害客户。

因此，Counting House 不会简单地部署一个拥有全部权限的通用 Agent，而是围绕每一种业务意图，单独配置模型、规则、工具和自主权。

更反直觉的是，这些数字职员没有长期记忆，也没有属于自己的业务系统凭证。

每次任务开始时，系统才向它提供必要的上下文。它读取允许访问的数据，生成回复，必要时提出一个业务操作请求，然后记录处理结果并结束本次会话。

下一个案例由一个全新的会话处理。

这不是能力不足的妥协，而是为了让整个系统更容易控制。

这套设计有三个重要特点。

第一，AI 不直接掌握业务系统的写权限。

它可以提出退款请求，却不能直接向数据库写入退款记录。真正的操作必须经过独立的编排器验证。

第二，AI 只看到完成任务所需的信息。

系统通过策略表决定它使用哪个模型、读取哪些数据、调用哪些工具，以及需要哪些审批。必要的个人身份信息由独立的隐私网关处理，模型本身不应接触真实的敏感数据。

第三，每个任务都能独立评估。

当一个模型处理退款时表现不佳，企业可以只降低它在退款业务上的自主权，而不必停止整个系统。

这让 AI 的部署不再是一次性的大规模切换，而是一个可以逐项推进、随时回退的过程。

AI 上岗之前，必须先通过考试

Counting House 最值得关注的地方，并不是它使用了多少个 Agent，而是它如何决定一个模型究竟能做什么。

在很多 AI 项目中，团队往往先通过几个演示案例验证模型的能力，然后便尝试把它接入生产系统。

但几个成功案例并不能证明模型能够稳定处理数百万次真实请求。

Yegge 给出的办法，是先建立一套能够比较人工与模型表现的评估体系。

先建立人工基线

假设企业希望让 AI 处理退款请求。

第一步不是挑选最强模型，而是从历史业务中抽取一批真实案例，由人工依据明确的业务规则评分。

评分不能只看答案是否正确，还需要回答更具体的问题：

• 是否遵循了标准操作流程？
• 是否符合业务资格和金额限制？
• 是否正确理解客户的诉求？
• 回复语气是否符合要求？
• 是否遗漏了需要人工介入的风险？

这些经过人工审核的案例，构成评估用的黄金样本集（Gold Set）。

Yegge 建议，每种业务意图可以从数百个真实案例起步，风险较高的任务则需要更多样本。原文给出的参考范围是每种意图约 200 至 1000 个案例。

有了黄金样本，企业就可以用同一套标准测试不同模型、不同提示词以及不同推理配置。

更重要的是，这些样本应当保留一部分作为独立测试集，避免团队不断调试模型，最终却只是在迎合测试题。

不能只看准确率，还要计算错误的代价

这是 Counting House 的另一个关键设计。

假设某个模型的分类准确率达到 95%，听起来已经不错。

但如果剩下的 5% 错误中，大部分只是把普通咨询分配到了错误队列，问题可能不大；如果其中一部分是错误退款、漏掉特殊协助请求，结果就完全不同了。

同样的错误率，可能对应完全不同的商业风险。

因此，Yegge 强调使用混淆矩阵（Confusion Matrix）分析模型的具体错误，并结合精确率（Precision）、召回率（Recall）和错误成本来判断模型是否适合某项业务。

可以用一个简单的例子理解：

评估的核心，不是追求一个漂亮的总体分数，而是回答一个更接近业务本质的问题：

这个模型在这类任务上犯错的概率有多大？这些错误会造成什么损失？与人工处理相比，它是否真正更好？

而且，人工也不是完美的裁判。企业需要让不同评审者独立评分，处理意见分歧，并持续修订业务规则。否则，黄金样本本身就可能存在偏差。

让自主权随着证据逐步增加

在建立评估体系之后，Counting House 才允许模型逐步承担更多责任。

Yegge 定义了五个自主权等级：

模型并不是一次性获得全部权限，而是针对每一种业务意图单独晋级。

例如，一个模型可以在航班状态查询上进入自主响应阶段，同时仍然只能在退款业务中辅助人工。

如果评估结果恶化，系统也应该能够将它降级，甚至完全关闭该项能力。

这意味着企业不必等待一个在所有任务上都接近完美的超级模型。只要某个模型已经足够胜任某一类工作，就可以先把它投入生产。

最重要的安全边界：AI 提议，系统执行

如果说评估体系决定了 AI 能做什么，那么编排器（Orchestrator）决定的，就是 AI 的决定如何真正影响现实世界。

这是 Counting House 与许多简单的 Agent 自动化方案之间的重要区别。

考虑一个航空改签场景。

客户要求改签更便宜的航班，并退还差价。对于 AI 来说，这似乎只是一个简单的业务请求。

但在真实系统中，执行这一操作可能需要：

1. 预订新航班座位。
2. 重新签发机票。
3. 释放原航班座位。
4. 退还差价。
5. 更新财务账目。
6. 转移行李、座位等附加服务。
7. 向客户发送新的行程信息。

这些步骤可能涉及多个独立系统，无法依靠一个简单的数据库事务一次性完成。

如果执行到一半失败，系统就必须能够恢复或撤销已经完成的操作。

这正是分布式系统中的 Saga 模式所解决的问题。

在 Counting House 中，AI 不直接执行这些步骤，而是提交一个结构化的操作意图，例如：

{
  "action": "rebook_flight",
  "case_id": "CASE-12345",
  "booking_id": "BOOKING-67890",
  "target_flight": "FLIGHT-ABC"
}

接下来，编排器会执行资格检查、参数验证、幂等性检查与审批，并驱动工作流执行。只有通过这些检查，操作才会真正进入业务系统。

其中有几个机制尤其重要。

• 资格复核：不能仅凭模型读取的缓存数据作出决定，执行前需要重新检查真实业务系统。
• 幂等性：防止重试、重复请求或消息重放导致同一笔退款被执行多次。
• 人工审批：超出金额阈值或风险政策的操作必须交给人工。
• 补偿机制：如果多步骤工作流失败，系统需要撤销已完成的操作，或者将问题交给人工处理。
• 审计与异常队列：每一次拒绝、失败和审批都应留下记录，并能够追溯责任。

Yegge 特别提到，企业可以考虑使用 Temporal 等持久化工作流技术来实现这类编排，而不是试图让大模型自己维护跨多个系统、持续数天的事务状态。

这里体现了一种非常重要的架构原则：

把概率性的智能决策与确定性的业务执行分开。

大模型擅长理解自然语言、处理模糊输入和提出解决方案；但涉及资金、权限和业务状态时，资格校验、幂等性、事务执行与审计应该交给可以明确验证的软件系统。

这并不意味着编排器绝对不会出错，而是让关键风险不再完全依赖模型是否会犯错。

Counting House 真正的壁垒，是企业自己的评估体系

从技术组件来看，Counting House 并没有创造一种全新的大模型。

它使用的仍然是模型服务、数据网关、工具接口、评估框架和工作流引擎。

真正值得关注的是，它将这些组件组织成了一套持续运行的业务治理机制。

这套机制至少带来三个长期价值。

第一，模型可以替换，业务知识不会轻易丢失

假设一家银行最初使用某个闭源模型处理客户咨询。几个月后，另一款价格更低的模型出现了。

如果企业只是把业务逻辑写在大量提示词里，切换模型可能意味着重新测试整个系统，甚至重新开发。

但如果企业已经建立了清晰的业务意图分类、黄金样本、评分标准和错误成本模型，那么切换就变得容易得多。

新模型只需要参加相应的评估，达到某项任务的标准后，就可以获得对应权限。

因此，Yegge 特别强调，企业应该自己掌握评估数据和评估体系，而不是完全依赖外部供应商。

谁掌握评估标准，谁就掌握模型选择权。

这也是 Counting House 的一个重要商业逻辑：企业可以利用更便宜的模型承担大量经过验证的任务，而不是为每一次简单的客户交互都支付前沿模型的成本。

当然，低价模型并不必然更划算。只有当它在目标任务上的质量、错误代价和运行成本经过验证后，替换才有意义。

第二，客服不再只是成本中心，还可以成为业务问题的探测器

Yegge 在文章中回顾了自己早年负责亚马逊客户服务工具团队的经历。

他提到，团队会定期分析客户联系原因的分布，将最常见的问题交给相应业务负责人处理。

这背后的思想是：客户服务不只是负责解决问题，也应该帮助企业发现问题。

如果大量客户反复咨询订单延误，真正的解决办法可能不是增加客服人手，而是改善物流系统。

如果某类退款请求持续增加，问题可能出在产品质量、定价政策或某项业务流程上。

Counting House 可以将这些案例持续分类、评估和汇总，让企业不仅知道 AI 处理了多少请求，还能知道客户为什么不断提出这些请求。

这样一来，AI 的价值就不再局限于降低单次服务成本，而是帮助企业更系统地发现和修复业务问题。

第三，AI 转型不只是工程项目

Counting House 需要多个团队共同参与。

业务运营团队负责定义流程和业务规则；质量团队负责构建黄金样本；数据科学团队负责评估方法；财务团队需要计算错误成本；法务与合规团队负责审批边界；工程团队则负责数据网关、模型调用和事务编排。

这意味着，企业不能只成立一个 AI 创新小组，然后期待它独立完成所有部门的自动化。

更重要的是，自动化会改变原有岗位的职责。

人工客服可能逐渐减少重复回答问题的工作，转而负责处理异常案例、审核复杂请求、维护业务规则和参与质量评估。

这不是说所有岗位都可以轻松完成转型，也不是说组织阻力可以靠技术自动消除。企业仍然需要投入培训、沟通和流程改造。

Yegge 的观点是，AI 转型本质上也是组织和文化问题。

哪些企业适合 Counting House？

Counting House 并不是适用于所有 AI 应用的通用架构。

它尤其适合满足以下条件的业务：

• 每年需要处理数百万乃至数千万次请求。
• 请求数量庞大，但实际业务意图相对有限。
• 业务规则可以逐步梳理和验证。
• 企业拥有足够的历史案例，可以建立可靠的评估基线。
• 任务能够被拆分成可审核的步骤，并允许在必要时转交人工。

因此，航空、银行、保险、电信、公用事业、零售退货、物流和部分政府服务，都是值得关注的应用领域。

反过来，如果业务极度开放、任务高度创新、无法定义清晰的成功标准，或者错误代价极高且缺乏可靠的人工兜底机制，那么这种模式未必适合直接采用。

还有一个容易被忽视的现实：建立 Counting House 并不只是接入模型 API。

数据脱敏、历史案例整理、人工评分、策略管理、工作流编排和审计机制，都需要投入。对某些企业来说，这些工作甚至比调用模型本身更困难。

而且，黄金样本也不是一次性资产。业务规则会变化，客户行为会变化，模型也会更新。企业必须持续评估，才能保证系统长期有效。

因此，更合理的落地方式，是从一个业务意图开始。

例如，先从低风险的航班状态查询、订单状态查询或简单的政策问答入手，运行影子评估，再进入辅助模式。确认模型达到要求后，才逐步扩大自主权。

与其一次性自动化整个客服中心，不如先证明一项任务可以被稳定、安全、经济地自动化，然后再复制这种方法。

小结：AI 企业需要的，不只有超级员工，还有可靠的数字流水线

Steve Yegge 的 Counting House 提供了一种值得重视的视角。

AI 时代的企业架构，未必是把越来越强的 Agent 放进越来越大的权限空间。

对于大量重复出现、规则相对明确的业务，更有效的做法可能是反过来：把任务拆小，把权限收紧，把评估做实，让每个模型只承担自己已经证明能够胜任的工作。

在这套架构中，模型负责理解和提出建议，策略表决定它能做什么，评估体系决定它是否有资格获得更多自主权，编排器则负责把业务操作安全地落实到真实系统中。

这套方法并不能消除所有错误，也无法替代企业对业务规则和组织变革的投入。但它提供了一条从 AI 演示走向规模化生产的清晰路径。

对于企业而言，真正值得长期建设的，可能不是一个永远不会被替换的超级模型，而是一套能够持续验证模型、替换模型、控制风险，并不断改进业务的系统。

模型会变，价格会变，能力边界也会变。但企业自己的业务知识、评估标准和执行机制，才有机会成为 AI 时代真正持久的竞争优势。

参考资料

• Steve Yegge，The Counting House - https://yegge.ai/essays/the-counting-house/
• Steve Yegge，Wheelhouse - https://yegge.ai/essays/the-wheelhouse/

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。