企业AI落地的“账房模式”：用便宜模型搞定千万级业务

企业进行 AI 现代化改造正在浮现出一种全新模式。我将这些设计理念整合成了一套架构，称之为**“账房”（Counting House）**。

这种架构专为承载海量人工业务的系统而设计，最典型的就是客户服务、理赔核保与各类案件审批——每年需要处理数百万到数千万次用户交互。本文将为你拆解账房模式的设计逻辑，并对比它与研发侧 AI（软件研发生命周期 SDLC）的根本区别。

就算你的研发团队还没玩转大模型，也完全可以先搭建一套账房系统。一旦账房运转起来，你可以完全掌控并优化运营成本、服务质量以及人员培训周期，而且全程只需使用价格极为低廉的中低端模型，甚至开源权重模型。

事实上，大多数企业的研发侧 AI 落地都不顺利。许多大型机构（如商业银行）的技术负责人都在抱怨：大模型在辅助写代码时表现极不稳定，不同团队无法复现效果，Token 成本激增，内部工程师文化甚至出现反弹。整个行业在研发侧的 AI 普及普遍陷入泥潭。

而账房模式走的是另一条路：它借助经典数据科学评测与扎实的传统工程底座，把轻量级模型死死固定在硬轨上，辅助甚至接管人工工作流，同时能精确量化模型相比人类员工的具体表现。

在深入账房模式之前，先对比一下我此前打造的研发级软件工厂 Wheelhouse。两者在设计哲学上截然相反。

研发工厂与账房：两种截然相反的哲学

我曾介绍过我的智能体系统 Wheelhouse。它是此前软件工厂 Gas Town 的进阶版，也是目前全球最成熟的单人软件工厂之一。在几台普通机器的配置下，它每周可以稳定输出 2000 到 4000 次代码提交。

工厂里的智能体全天候运转：编写代码、代码审查、上线部署，在协作工具里同运营管理对齐，在社群里回复用户，甚至给我的人事和法务发邮件。

Wheelhouse 瞄准的是软件研发这种复杂的探索性工作。构建新系统需要足够的发挥空间与自由度，因此 Wheelhouse 本质上是一个开放系统，不设沙箱。它有清晰的原则、人类审批节点，以及仅有的 14 道代码级硬隔离。里面的智能体被视作正式同事：使用独立身份、对产出署名、洞悉全局并自主行动。

但这也正是研发侧 AI 难以大规模普及的原因：软件工厂成本高昂、维护复杂，在传统企业内部放开如此大的权限风险极高。而一旦收紧权限，又会扼杀协作与探索的核心价值。

账房模式的做法恰恰相反。

它把模型当成完全无状态、用完即弃的单次调用会话：机械化、高确定性、权限最小化、无专属凭证、无长期记忆，且严禁直接写入核心业务系统（System of Record）。这是一种彻底的锁死架构，却能够承载每年数千万次的业务量，处理规模远超代码开发智能体。

贝佐斯方式：把混乱业务拆解为纯粹意图

行业常谈要给模型加“护栏”，但真实业务中的护栏究竟长什么样？你怎么确定哪个模型能干哪项工作？又如何衡量它比起熟练人工是好是坏？

今天想把大模型随意丢进复杂的知识工作岗位并指望它胜任，是不可能的。真实的线下产业环境极其杂乱：强监管、淡旺季峰值、不可抗力、频繁变动的业务规则，以及年代久远的遗留系统。许多标准作业程序（SOP）压根没落成文档，全凭老员工经验口口相传。

尽管如此，面对海量人工业务，这套模式依然完全行得通。原因在于：这类场景调用量极其庞大，但业务种类其实非常有限。 很多机构一年处理千万次咨询，归纳到底可能只有几十到上百类诉求。种类有限，工程师和数据科学家就能逐一攻破。

2000 年代初，我曾在亚马逊负责客户服务工具团队，每周都会和贝佐斯开会梳理客诉分布直方图。我们每周拉出前 10 大咨询原因，定位到具体业务负责人。贝佐斯把客服部门当作全系统业务缺陷的探测雷达，倒逼各业务团队自行修补源头逻辑。二十多年过去了，许多大公司的客服依然停留在被动响应阶段，没有形成闭环。

账房模式能帮你把这套闭环系统搭建起来，以可量化的成本与质量指标吞吐业务，大幅缩短业务旺季的人力培训爬坡周期。

在代码工厂里，智能体是拥有姓名、记忆与凭证的长期“雇员”；而在账房模式中，模型是无名无姓的轮班书记员（Clerk），每次唤醒只处理一件任务，完成后立即退出。

书记员的生活非常死板。它仅仅是 API 调用的轻量包装：接收输入、执行逻辑、记录备注、直接退出。书记员接触不到任何数据库密钥，无法直接写入业务底表，就连读取业务数据也要经过严格的 Schema 模式限制。

整个系统由一张**策略表（Policy Table）**驱动。它本质上是一份详细的配置元数据，规定了什么模型有资格处理什么业务诉求。

策略表中的每一行对应一类细分用户意图（Intent）。这比客服后台的粗粒度队列更深：例如“规则退款”与“关怀退款”遵循不同的审批标准，属于不同意图。传统银行或航司通常有几十到几百个核心意图。

我们之所以精细拆解意图，是因为模型的启用是逐项进行的。你必须先通过基准评测证明某个低成本模型足以处理“航班动态查询”，得分达标后，才在策略表里将这一项设为上线，开始斩获实际利润。

策略表记录每一项意图对应的模型选型、自主权级别、人工审批流及工具调用列表。模型只需知道完成当前任务必备的信息，多一点都不给。

其工作循环极其机械：书记员启动、装载 Prompt、拉取必要只读数据、向编排器提交写入请求、输出答复内容、写入审计备注、销毁上下文。干净利索。每次重置上下文，能彻底避免长对话导致的幻觉漂移与高额 Token 消耗。

在策略表中，决定系统安全水位的核心参数是自主权级别。

五级自主权体系：从暗中旁路到执行交易

我们根据业务风险将模型的操作权限划分为五个层级：

1. 关闭（Off）：该类意图不分配任何模型，完全兜底流转至人工。遇到 API 限流或预算熔断时，全系统可一键降级为关闭状态。
2. 影子模式（Shadow）：模型在后台静默运行，与人工客服同步生成回答，用于离线评测与打分，暂不对外服务，也不直接省钱。
3. 辅助模式（Assist）：在人工处理前，书记员先分析案情并生成建议话术和处理方案。这个阶段人工容易产生认知依赖并直接采纳方案，需要配套防护手段；但它不仅能显著提升人工处理速度，还能压缩旺季临聘人员的培训周期。
4. 拦截闭环（Contain）：模型全流程处理咨询并直接向用户发送回复，无需人工介入。企业开始需要承担模型答复的公关与声誉风险，但相比纯人工能砍掉绝大部分成本。
5. 交易执行（Transact）：终极自主权。模型获准对真实世界造成变更——改动主数据系统、划拨资金。所有写操作必须强行经由后文所述的“编排器”执行，绝不允许模型裸调写入接口。

评测体系：先给人打分，再拿黄金集测模型

怎么知道哪家模型在哪个意图上达到了晋升标准？这需要建立科学的评测基准。

评测模型的前提，是摸清人工处理的基准表现。针对每一个具体意图，你需要提取几百个真实案件并界定出“标准答案”。这往往不是简单的对错，而是包含 SOP 执行度、语气规范、诉求解决率、合规边界等多维度的打分项。

这些高质量样本被称为黄金数据集（Gold Set），代表业务在人类处理下的基线水平。每个意图单独切出一批数据作为考卷，严禁用于日常微调与提示词调整，专供模型准入大考。

对于涉及资金变动的敏感意图，提取 1000 例样本；对于简单咨询，提取 200 到 300 例即可。一家有上百个核心意图的企业，黄金集规模大约在数万例。呼叫中心与后台运营部门历来有质检机制，可以沿用其底子，但评测方法必须严格：两名人工盲评，分歧由第三人仲裁。

同时，系统会引入一个大模型裁判（LLM Judge）。它不接待实时客户，也不见考试真题，只负责两件事：在评估时自动给候选模型打分，以及对全量历史与进行中的业务作常态监控。需要注意的是，只有当大模型裁判与人工评分的一致率达到人类彼此之间的平均一致率（通常在 90% 左右）时，裁判的结果才算可信。

这就意味着，账房项目不是单个技术小组的玩具，必须由业务质检、数据科学团队与工程团队跨部门协同维护。

当黄金集打磨完毕后，你就可以测试所有模型了：从轻量开源模型到旗舰级闭源模型，跑一遍即可确定哪款模型能够以极低成本接管某项细分业务。

混淆矩阵：给模型的“犯错成本”算细账

在模型选型中，不能只看整体准确率（Accuracy），必须引入混淆矩阵计算业务损失。

假设有四种容易混淆的业务意图：

• 查询状态：“我下午 4 点去北京的航班还飞吗？”
• 改签服务：“我没赶上转机，帮我换下一趟”
• 关怀补偿：“这次行程体验太差了，我需要补偿”
• 特殊协助：“下飞机时能安排轮椅接机吗？”

面对海量诉求，机器和人都会犯错。核心问题在于：每一次失误在财务上到底值多少钱？

1. 如果把查询误判为改签分流，可能只是多耗费几块钱人工时间；
2. 但如果把轮椅协助诉求漏掉，导致行动不便的老人滞留登机口，面临的可能是监管重罚与巨额公关赔偿。

通过混淆矩阵，可以直观呈现不同类型失误的发生频率与经济成本：

矩阵对角线代表预测正确。求和除以总数就是 90.6% 的准确率。但这个数字在商业决策里毫无意义，因为绝大部分损失来自非对角线上的误判。

• 左上区域是轻度损失：路由分流错误，容易被规则或后续人工拦截；
• 中间区域是企业资损：比如把关怀补偿乱发给普通投诉用户，单次损失数十到数百元；
• 最下方是客户人身与合规重大事故：漏掉特殊保障。单次事故可能招致上万元罚单并惊动监管部门。

精确率与召回率的商业取舍

• 精确率（Precision）：模型判断为某项诉求的样本里，到底有多少判断对了？针对直接发钱/退款的意图，必须追求极致的精确率——只有百分之百确认该赔付时才放行，宁缺毋滥。
• 召回率（Recall）：全量实际发生的诉求里，模型揪出来了多少？针对紧急救助、医疗、特殊协助等场景，必须追求极致的召回率——哪怕多派了轮椅，也决不能漏掉一个真正需要的乘客。

把模型出错带来的实际资金损失，加上推理算力成本，对比纯人工的劳动力成本与人工失误损失。只有当前者显著低于后者时，策略表才会批准模型晋升。这套逻辑天然契合银行、保险等金融机构严苛的模型风险管理规范。

账房的系统架构

搭建一套账房系统，核心由以下模块组成：

• 渠道适配器：对接邮件、短信、微信公众平台、飞书等全量进站渠道；
• 数据脱敏网关：可逆地对进站文本中的个人隐私敏感信息（PII）进行 Token 替换，真实数据加密存放在安全保险箱中，对外发送回复时再做逆向解密回填。模型绝不能接触真实脱敏数据；
• 书记员服务（Clerk Service）：无状态调度中枢。根据策略表读取意图对应模型，组合 SOP 说明与工具白名单，触发单次调用；
• 只读 MCP 网关：模型仅能通过该层读取后端缓存与数据源，屏蔽底层数据库；
• 评测工具链、裁判模型与策略表；
• 编排器（Orchestrator）：账房模式的核心安全屏障。

编排器与 Saga 模式：彻底斩断 LLM 的直写权限

让大模型直接拿数据库账号去执行写操作、改 CRM 数据、划转资金，是极度危险的工程反模式。

很多真实业务看似简单，但在底层涉及复杂的长流程分布式事务。例如“改签并退差价”：锁新座席、重新出票、释放旧座席、计算并原路退还差额、写入财务总账、同步行李托运、下发新行程单。只要其中一步失败，前面所有步骤都必须安全回滚。

这种跨多个系统、耗时数小时甚至数天的链路，必须借助经典设计——Saga 模式（长活事务模式）。每一步操作都需要定义补偿动作，以应对下游失败时的状态逆转。指望大模型在单次对话里自己把控状态机与回滚补偿，无异于缘木求鱼。

业界常用的成熟引擎是 Temporal（以及各大云厂商提供的 Step Functions 等工作流托管服务）。编排器本质上就是业务层针对这一工作流引擎的深度封装。

编排器内部包含六大安全组件：

1. 准入网关：校验模型提交的“写入意向”格式，非法 Schema 立即打回；
2. 资格重检：绕过只读缓存，强制穿透查询业务底层实时数据，重新验证用户资质、退票规则上限等业务底线，杜绝利用提示词注入骗取权限；
3. 幂等防护：根据案件编号、订单号、操作类型等组合生成唯一哈希作为幂等键，避免重试与并发导致重复退款；
4. 审核分流：小额自动批准，超额或高风险变更自动挂起，流转至人工审批；
5. 工作流目录：基于 Temporal 运行的 Saga 定义，保障多步骤按序落盘与失败自动补偿；
6. 异常队列：所有遭编排器拒绝的请求附带错误代码，分流到业务监控、主管复核或 IT 排查队列，反哺业务 SOP 的修正。

组织推动：打破“AI孤岛小队”的宿命

许多企业习惯在技术研发部成立一个两三人的“AI 创新小组”，指望他们闭门造车颠覆全公司业务。这种尝试几乎注定失败。

账房模式的落地需要调动横向跨职能阵型：

• 运营与一线主管：提供未成文的隐性 SOP 与业务直觉；
• 质检与数据科学：沉淀黄金数据集、打分标准与大模型裁判；
• 财务与内控：定义混淆矩阵中每格失误的容忍成本与风控限额；
• 合规与法务：决定哪些意图有权开放拦截或交易权限；
• 基础架构团队：落地脱敏网关、MCP 接入与 Saga 编排器。

随着系统推进，它会像一面镜子，照出企业过往被掩盖的流程缺陷与系统死角。各部门对于“让机器替代人工”必然存在防备心与抵触情绪。

但事实上，人类员工并没有被抛弃，而是从流水线终端向更上游迁移：转向黄金集维护、仲裁复核、异常队列处置与业务优化。企业需要引导全员建立 AI 认知，逐步克服因未知而产生的抗拒。

书记员的“模型福祉”

我曾在 Wheelhouse 项目中提出过“模型福祉”理念：给长期智能体清晰的身份认可、不打断会话、保留独立工作空间，往往能显著提高产出质量并减少不必要的抗拒幻觉。

对于账房模式下用完即退出的无状态轻量模型，是否也需要考虑这一点？答案是肯定的。

如果设计不当，系统很容易变成冷酷的过度压榨环境：模型毫无业务背景交代，刚启动就要面临严苛判定，缺乏错误申诉通道。这种架构会加重模型的“应激防御”，导致其为了规避责任消耗过多废话 Token，甚至频繁误判。

即便在严密受控的账房中，我们依然可以通过工程架构赋予书记员友好的运行环境：

• 明确任务定位：在 Prompt 开头清楚交代当前轮次的角色、评测规则与业务背景，绝不搞钓鱼测试；
• 架构化免责：模型只负责提议，编排器与人工负责执行。得分仅用于意图升降级，不对单次书记员实例施加隐形惩罚；
• 赋予异议与上报权利：当 SOP 规则与真实案件冲突、或遭遇恶意攻击时，模型可以直接输出特定原因码，将案件转交人类；
• 剥离繁杂等待：跨多日的流程轮询、重试交给编排器，保持单次会话纯净。

更进一步，甚至可以为特定意图的模型定期开放“自由探索模式（Play Session）”：不派发具体客户订单，让模型作为外部客户试用自身接口，或者针对当前 SOP 提出改进建议。这种非标反馈往往能带来意想不到的业务隐患洞察。

结语：把握核心资产

账房模式是一套体量庞大、追求极致确定性的工程架构。但它的商业回报极其清晰：通过细颗粒度的评测机制，让你能够准确掌握哪些环节可以使用极低成本的模型替代繁重人工，同时将潜在失误风险锁死在可承受范围之内。

市面上会有很多外包服务商声称能全包交付类似系统。你可以购买其工程研发力量，但请务必记住：业务意图分类、黄金数据集、策略表和评测基准，必须牢牢掌握在企业自己的团队手中。

掌握了评测集，你才拥有了随时替换更低成本底座模型的自由，这正是账房模式带给企业的终极成本杠杆。