跳转到主要内容

内部工具代理:当你杠杆率最高的 AI 功能却零客户时

阅读需 2 分钟Tian PanTian Pan

你公司最具战略意义的 AI 投资,可能是一位工程师在某个周五下午编写的一个 Slack 机器人。它回答“如何获取分级环境凭据”、“哪个值班人员负责认证服务”或“部署卡住时的运行手册是什么”,它节省的工程小时数比整个面向客户的 AI 路线图还要多——而后者占据了你四分之三的模型开销、安全审查队列以及发布沟通带宽。

组织架构图并未反映出这一点。OKR 文档也没有反映这一点。没有人是它的产品经理(PM),也没有人是它的工程经理(EM)。这个机器人之所以能生存下来,是因为构建它的工程师仍在回复 GitHub 上的 issue,在每一个面向客户的功能因六周的安全审查和发布就绪检查清单(之所以存在是因为客户可能会流失)而推迟发布时,它的价值正在悄然复合增长。

这就是 2026 年 AI 领域反转的经济学。内部用户拥有简单 10 倍的安全边界、更高的单位小时投资回报率(ROI)天花板,以及不需要正式发布(GA)门槛的发布流水线。然而,中等规模的公司往往将它们视为“剩余产物”——即当面向客户的路线图留有余地(slack)时才去构建的东西。那些反转这种资源分配的公司所实现的生产力复合增长,是那些只顾追逐客户功能的公司所无法企及的。

数学逻辑是反过来的

从单位经济效益开始。一个处理工单的客户支持 Agent 大约能为你节省 5–15 美元的离岸代理时间成本。而一个解决“在哪里可以找到订单表的 schema”的内部工程 Agent 大约能为工程师节省两分钟——但满负荷计算下,工程师的时间成本为每小时 100–200 美元。此外,针对客户的工单拦截型 Agent 的乘数只是一个人类,而辅助开发者的内部 Agent 的乘数是公司里的每一位工程师,每一天,直到永远。

数据在大规模应用中证实了这一点。Slack 的内部 AI 机器人部署在 25 多个工程频道中,在一年内估计节省了 3,000+ 小时的工程时间。BBVA 报告称,在 11,000 名活跃用户和 4,800 个自定义内部工具中,每位员工每周节省两到五个小时。Salesforce 的内部 Slack 机器人推广声称每支团队每周可节省多达 20 小时,在外部用户接触到它之前,这在公司内部就转化为超过 640 万美元的生产力价值。

现在对比一下安全边界。你的客户可能是越狱攻击者、监管机构、记者、敌对的外国国民,或者是 13 岁的孩子。而你的员工签署了 NDA,拥有可撤销的 SSO 访问权限,受人力资源政策约束,并在已记录的日志企业语境中使用 Agent。威胁模型大约简单了一个数量级。在客户 Agent 上发生的提示注入是 P0 级事故;在内部 Agent 上的等效事件只是一条 Slack 消息说“嘿,刚才那个挺奇怪的”,然后工程师在周一把它修好。

发布流水线也是不对称的。面向客户的 AI 功能需要发布计划、市场沟通、产品营销经理(PMM)、法律审查、无障碍审计、本地化处理、计费集成、文档页面、状态页面条目以及 90 天的弃用政策。而相同功能的内部版本只需要一个 Slack 频道和一个 /help 命令。一位工程师可以在一周内发布内部版本。而客户版本则需要一个季度。

当单位小时价值更高、安全审查更便宜且发布更快时,数学逻辑告诉你应该以 10 倍于客户 Agent 的速度发布内部 Agent。然而,大多数公司正在反其道而行之。

为什么资源分配一直是错误的

客户功能是可见的。它们出现在路线图上、发布幻灯片中、新闻稿里、分析师简报以及季度业务回顾(QBR)的幻灯片中。内部功能则没有这样的表现舞台。首席财务官(CFO)从未要求演示过工程 Slack 机器人。首席执行官(CEO)在全员大会上从未点名表扬过部署助手 Agent。不存在“我们将内部开发者效率提高了 30%”这样的投资者叙事,因为投资者不会为此定价,尽管这是你明年将发布的每一个客户功能的投入要素。

这种不可见性创造了一个反复出现的失败模式。机器人最初只是一个黑客松项目,立即找到了内部用户的功能市场契合点(因为内部用户有真实的流程,并在机器人出错的一瞬间就会告诉你),然后进入平台期——因为构建它的工程师有日常工作,拥有该领域的团队并未明确,而本可以使其成为真正产品的资源默认被路由到了客户路线图中。

普华永道(PwC)的 AI Agent 调查发现,大约 33% 的领导者表示,证明内部 Agent 的 ROI 比面向客户的自动化更难。这并不是因为 ROI 较低;而是因为没有人授权组织去衡量它。客户收入存在于你的计费系统中;而节省的工程时间不存在于任何人的仪表板中,直到有人决定构建那个仪表板。这类难以衡量的类别被组织的报告系统所忽视。

此外还存在一种地位等级制度。构建面向消费者的 AI 是一个对简历有加持的项目;而构建内部 Slack 机器人则是绩效评估中“你这季度做了什么,有什么外部可见的东西吗?”这样的对话。除非组织明确奖励内部基础设施工作——通过晋升、人员编制和预算——否则绩效周期的引力会将每位高级工程师都拉向客户路线图。

捕获价值的纪律

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 9 分钟

对于你的 AI 功能,“自研还是购买” 是个错误的问题

一个 AI 功能是一个包含五个层级的技术栈,而不是一件可以简单制作或购买的单一事物。真正重要的决策是:哪个层级能累积你的差异化优势,而哪个层级又是竞争对手可以轻易买到的。

insider
ai-engineering
阅读需 9 分钟

在构建下一层 AI 技术栈之前,请先绘制 Wardley 地图

关于 AI 基础设施的‘自研还是外购’的争论,往往假设了一个并不存在的稳定格局。Wardley 地图揭示了你的技术栈中哪些层会在几个月内商品化,以及哪些组件(如领域评估和私有数据)正朝着相反的方向发展。

insider
ai-engineering
阅读需 10 分钟

你的 AI 路线图需要一个“停用”列

只管发布的路线图会在 AI 系统中悄悄积累负债,因为模型、提示词和评估集会按照你无法控制的节奏腐化。请添加一个“停用”列,并将功能下线视为一等交付物。

insider
ai-engineering
阅读需 9 分钟

资历倒置:为什么当 Agent 加速时,你的资深工程师反而变慢了

Agent 让代码生成变得廉价,却让审查变得昂贵。成本落在了唯一无法扩展的资源上:资深工程师的判断力。本文探讨了负载为何会向他们集中,以及如何重新平衡。

insider
ai-engineering
阅读需 11 分钟

我们已经有了:当 AI 功能在重新造你已有的代码轮子

在成熟的公司中,大多数 AI 功能其实是在重复代码库中已有的逻辑。解决方法是在开发前进行审计,并采用一种组合模式,让模型成为备选路径而非首选路径。

insider
ai-engineering