Yoav Naveh，Reindeer 联合创始人兼联席首席执行官——访谈系列

Yoav Naveh是 Reindeer 的联合创始人兼联席首席执行官，拥有创建科技公司、扩大企业规模以及投资创业者的丰富经验。在创立 Reindeer 之前，他创建了 ConvertMedia，之后继续在 Taboola 工作，并通过 INT3 进行投资。如今，他致力于帮助企业摆脱孤立的 AI 部署模式，转而采用能够处理复杂运营工作、从人类专业经验中学习，并在业务流程变化时依然保持可靠的智能体。

Reindeer开发面向企业的 AI 智能体，服务于财务、供应链、物流和共享服务等领域的核心运营。其平台将工作流执行与专家反馈、评估和人工审批相结合，使智能体能够适应例外情况和不断变化的政策。在这次访谈中，Naveh 谈到了工程投入过重的部署模式的局限、如何将组织知识转化为智能体的上下文，以及随着时间推移降低人力总投入所需的治理和衡量方式。

在创建 ConvertMedia、推动 Taboola 业务规模扩大，并通过 INT3 投资其他创业者之后，是什么问题促使你重新投身创业？这又如何影响了你共同创立 Reindeer 的决定？

AI 市场太令人振奋，我们不愿袖手旁观。我和我的联合创始人 Yair 对一个差距产生了浓厚兴趣：我们个人使用 AI 时，它已经非常实用；但对企业而言，要大规模采用 AI 仍然十分困难。技术进步极其迅速，但大多数组织仍在努力将 AI 的潜力转化为有意义的运营变革。

AI 将改变企业的运营方式，但要实现这一点，光有更好的技术还不够。领导者还必须愿意重新思考工作的开展方式，并找到切实可行的方法，将 AI 引入日常运营，同时避免增加新的复杂层级。

这一挑战促使我们创立了 Reindeer。我们打造了一个平台，帮助企业从部署第一个智能体起步，逐步扩展到一整个智能体群，让它们从人类反馈中学习并不断改进。我们的目标是弥合 AI 潜力与现实应用之间的差距，帮助企业将核心运营转变为由智能体驱动的 AI 劳动力，而不必重建每个智能体，也不必不断维护它们。

你曾指出，前沿部署工程模式可能会使企业 AI 沦为劳动密集型服务业务。嵌入式工程在哪些方面能创造持久价值？又会在什么情况下变成一种依赖，阻碍客户扩大规模？

前沿部署工程师对于复杂集成以及让首批智能体投入生产很有价值。问题在于，当工作流程本身发生变化时，前沿部署工程师可能会变成长期必需的人力，企业必须依靠他们才能让这些智能体继续运行并完成工作。规模扩大时尤其如此。部署 5 个智能体时，前沿部署工程模式行得通；但当智能体达到 100 个时，这种模式就会难以为继。

如果每增加一个工作流或遇到一个意外情况都需要投入更多工程资源，那你扩大的就不是软件规模，而是昂贵的人力规模。

大多数采用前沿部署工程师的公司都声称，工程师最终会转去做其他工作。企业在签署要求配备前沿部署工程师的合同之前，应要求对方证明这一点。我们已经看到，随着业务流程演变，RPA 会变得多么脆弱。我们不应认为手工构建的智能体会有所不同。

企业工作流往往包含未记录的例外情况，不同团队之间也存在相互冲突的做法。Reindeer 如何掌握工作实际是如何完成的，同时区分有价值的组织知识与不应自动化的习惯？

大多数企业拥有海量组织知识，却没有任何书面记录。这些知识只存在于员工脑中。我们的智能体从有限的知识起步，通过处理实际案例学习；遇到陌生情况时，会向领域专家寻求指导。

但从员工身上学习，并不意味着盲目照搬他们的行为。我们的系统会区分个别例外和反复出现的模式，并提出更广泛的变更建议，供人类审批。

我们的目标不是自动化每一种习惯，而是在不要求工程师事先预见所有情况的前提下，将有价值的组织知识转化为可靠的智能。

大多数智能体公司会先记录流程，再通过访谈和仔细分析过往数据来编写流程代码。但实际上，学习流程最有效的方式，正是每当新团队成员加入时所发生的事：他们不会去记住一整年的数据，也不会背下长达 3,000 页的标准操作规程（SOP）。他们会先学习几项技能，看几个示例，然后开始工作；遇到不明白的事情时就提出问题，并逐步积累知识。这就是我们构建的流程。

智能体 AI 也为企业提供了重新构想流程的机会，而不只是照现状将其自动化。仅由人类组成的团队、基于规则的自动化和传统软件，都曾根据各自的局限塑造流程。通过让智能体与专家共同学习，Reindeer 帮助企业重新思考流程应当如何运作，包括保留哪些做法、淘汰哪些做法，以及智能体和人分别在哪些方面能发挥最大价值。

你提到 Reindeer 的智能体会在生产环境中持续学习，具体会发生什么变化：模型权重、记忆、工作流逻辑，还是明确的政策？能否举例说明某个例外情况如何让智能体学会以不同方式处理未来的案例？

发生变化的是智能体的上下文和技能：工作流逻辑、政策，以及何时应用各项政策的指示。

以发票智能体为例。它收到一张金额比采购订单高出 4% 的发票，却找不到适用于这种情况的政策。智能体没有处理这张发票，而是将其升级交由专家处理。专家解释说，这家供应商已获准享有燃油附加费例外。智能体处理了这个案例，并将相关说明作为仅适用于该供应商的上下文保存下来。

如果其他供应商再次出现同类例外，而且其他专家也以相同方式处理，系统就会提出政策变更建议，例如：“合同允许时，燃油附加费不超过 5% 即可接受。”该建议须经过测试并获得人工批准，智能体才能应用。一个专家的答复解决一个案例；多个案例中反复出现的模式，则可能成为新规则。

员工针对某位客户或某笔交易作出的决定，可能是恰当的，却未必适合作为通用规则。你们如何判断反馈应当仅作为一次性例外处理，还是应转化为拟议的政策变更？

我们会把解决单个案例与改变智能体今后的运行方式区分开来。

员工可能会批准针对某位客户的例外，但这并不意味着同样的例外应普遍适用。我甚至认为，两名不同的员工可能会对同一位客户的例外作出不同处理。我们的系统会评估具体情况，识别反复出现的模式，协调相互矛盾的意见，并查找可能与现行政策冲突之处。

当有证据支持更广泛的变更时，我们会通过自己的评估平台运行智能体——可以说，这是智能体的“楚门秀”——并提出更新方案，供人工审批。

我们的目标是向人类学习，而不是盲目照搬人类的决定。否则，你只是在自动化错误。

智能体可能在近期案例中有所改进，却在此前能够正确处理的情形中变得不那么可靠。拟议的变更在投入生产前必须通过哪些测试和审批流程？你们又如何发现并撤销回归问题？

缺乏治理的持续学习很危险，因此每项拟议变更都必须通过三道保障：回归测试、人工审批，以及用于控制智能体何时可自主行动的置信度阈值。

测试是第一步，但这比听起来更难，因为运营工作没有固定的标准答案。我们会根据专家反馈选取有代表性的案例，制定比较输出结果的标准，并用这些案例分别测试当前智能体和拟议版本。对于发送电子邮件等会产生副作用的操作，我们会在根据过往运行记录构建的模拟器中执行；不再符合现行政策的测试案例则会弃用。我们能够衡量变更的实际效果；智能体必须相信自己身处真实世界，其行动也确实会产生实际影响——例如向 SAP 中插入一条记录，或向客户发送一封电子邮件。只有这样，才能为每个智能体建立真正有效的评估框架。

随后，人工经理会审查变更、相关证据和测试结果，并可批准、修改或拒绝该变更。在获得批准之前，智能体的运行方式不会发生任何变化。

变更上线后，置信度阈值会为业务提供保障。只有当智能体的置信度达到阈值时，它才会自主行动；低于阈值的情况都会交由专家处理。运营团队可以自行调整这一阈值，因此可以先采取谨慎的设置，再随着智能体逐渐积累可靠的运行记录，赋予它更大的自主权。

如果变更后质量下降，系统会自动收紧审核阈值，让更多案例转交专家处理；专家的反馈则会通过提出该变更的同一闭环流程揭示问题。每次政策变更都有版本记录、明确的责任归属和日志，因此团队可以查看变更内容、审批人及变更原因，并回退到先前版本。

减少工程团队的工作量，仍可能让运营团队承担大量工作，包括审核例外情况和纠正智能体。你们如何衡量 Reindeer 是否减少了所需的人力总投入，而不是把这些工作转移给了另一支团队？

现实情况是，大多数公司已经有一支团队在手动完成这些工作。我们的目标不是把这部分工作转给另一支团队，而是随着时间推移逐步减少工作量。我们会从现有团队中选出经验最丰富的员工，让他们能够教会智能体如何处理例外并独立作出更好的决策。

FDE 模式的问题在于，它往往把工作从成本相对较低的运营员工转移给成本高昂的工程师。这并没有解决人力问题，只会让问题变得更昂贵。Reindeer 不会让工程师介入这一环节。相反，我们以智能体随着时间推移能够独立解决多少工作，以及整个流程所需的人工干预减少了多少，来衡量成功。

我们会追踪三项指标：智能体在无需人工介入的情况下独立完成整个流程的案件占比、每个案件需要专家介入的次数，以及智能体与人员处理每个案件的总耗时。如果第三项指标没有下降，我们就只是在转移工作，而非减少工作量。

能否以 Hellmann Worldwide Logistics 或 Papaya Global 的一个部署案例为例，说明从上线到持续运营期间发生了哪些变化？准确率、异常率、周转时间以及所需的人工介入程度分别有什么变化？

Hellmann Worldwide Logistics 是一个很好的例子，展示了智能体如何随着时间推移改善实际运营。其定价团队此前要花大量时间，手动处理来自电子邮件、电子表格和其他文档的运输请求，生成报价往往需要数天。

我们先用大约 20 份样本请求来了解工作流程并训练智能体。随后，Hellmann 的定价专家开始直接使用系统，提供反馈并帮助它处理各种例外情况。在测试期间，我们持续追踪准确率和处理速度；智能体投入生产后，也继续监测其表现。

如今，常规请求会自动处理，更复杂的案件则会升级交由团队处理。尤为重要的是，智能体在信息缺失时会识别出来，而不是自行假设，从而让员工能够在真正需要运用专业知识的环节介入。

结果是报价周转时间缩短了，手动录入数据的工作减少，员工也有更多时间面向客户开展工作。Hellmann 的报价赢单率也有所提高。我们的目标不是让流程完全不需要人工参与，而是持续减少需要人工介入的常规工作量。

你们对这种方法的局限性有哪些认识？工作流程具备哪些特征时，说明它已适合采用自适应智能体？又有哪些特征表明，企业应该先重新设计流程，或继续使用传统自动化？

并非每个流程都需要 AI 智能体。最适合的场景是重复性强、业务量大的工作流程，且需要结合上下文作出判断；尤其是信息分散在多个系统中、员工经常需要处理例外情况的流程。

从我们的部署案例中得到的最明确启示是，企业内部正在兴起一种新的职能，就像 CRM 兴起时出现了营收运营职能，Cloud 兴起时出现了开发运维职能一样。当企业从使用少数几个智能体发展到管理一大群智能体时，就需要由个人或团队来管理这些智能体，如同部门负责人管理一支员工队伍：他们要对智能体的 KPI 和投资回报率负责，决定哪些工作应交由智能体处理、哪些不应交由智能体处理，并批准智能体如何变更。已经开始建立这一职能的企业进展最快，也最有望胜出。

做法彼此冲突，并不是等待观望的理由。在几乎所有运营环节，专家之间都会有意见分歧；我们的系统旨在揭示这些矛盾，并将其转化为政策提案。解决这些分歧是该职能负责人的工作之一，这也是应该在扩大智能体规模之前设立这一职能的另一个原因。

这种方法本身也有局限。核心运营不会实现完全自动化，我们也不以此为目标。智能体会逐步扩大覆盖范围，而高风险案件则会有意保留由人员处理。

随着基础模型和智能体构建工具不断改进，你预计企业部署中的哪些环节会逐渐变成标准化商品？Reindeer 又在哪些方面建立了优势，使其随着每次生产环境部署而不断增强？

随着基础模型变得更便宜、更快、能力更强，它们之间的差异将越来越小，也更容易相互替换。构建基础智能体并将其接入企业系统，也已经变得越来越容易。

但构建一个智能体，并不等于让它能在复杂的业务环境中长期可靠地运行。

真正的竞争优势在于掌握企业实际运营方式的专有知识，而这种运营方式始终在变化。每个生产环境中的案件都为我们的智能体提供了学习机会，使其能够解决未来出现的例外情况并减少人工介入。

模型会越来越便宜，智能体也会越来越容易构建。

最终胜出的企业，将消除维持这些智能体长期正常运行并保持其适用性所需的高成本人工工程基础设施。

感谢这次精彩的访谈。希望进一步了解自适应企业 AI 智能体、运营自动化和人工引导学习的读者，请访问 Reindeer。