1. 这两份报告到底讲了什么为什么值得聊A16Z 这家机构在科技投资圈的分量不用我多说他们每年出的 AI 报告基本就是行业风向标。最近他们连着发了两份报告一份聚焦生成式 AI 的企业级落地另一份专门讲 AI Agent 的现状与未来。我把这两份报告翻来覆去读了几遍又结合自己这两年做 AI 应用开发的实际经验发现里面有不少结论跟圈子里流行的认知是拧着来的。先说清楚这两份报告的核心内容。第一份报告主要讲的是企业侧 AI 的采用率、预算分配和实际回报。第二份报告则把镜头对准了 Agent 这个赛道从技术架构、商业模式到落地场景都做了梳理。两份报告加起来覆盖了从底层算力到上层应用的完整链条涉及的关键词包括 A16Z、AI、Agent、Token、算力这几个核心概念。为什么我觉得这两份报告值得拿出来单独聊因为市面上关于 AI 的讨论太容易走极端了。要么是“AI 马上要取代所有人”的焦虑贩卖要么是“AI 就是个高级玩具”的轻视。A16Z 这两份报告的价值在于它们用实打实的数据和案例把很多被情绪掩盖的真相给挖了出来。比如企业到底愿意为 AI 花多少钱、Agent 的真实完成率是多少、Token 成本下降对商业模式意味着什么这些问题的答案跟很多人的直觉完全相反。我写这篇东西的目的很简单把报告里那些反常识的点拎出来结合我自己踩过的坑和实际观察给正在做 AI 产品、搞 Agent 开发或者单纯想搞清楚这个行业走向的朋友一些参考。不管你是刚入门的开发者还是已经在带团队做 AI 落地的负责人这些内容应该都能帮你少走点弯路。2. 反常识真相之一企业 AI 预算的流向跟你想的不一样2.1 预算大头不在模型训练而在推理和集成很多人一提到企业搞 AI第一反应就是“他们在训练自己的大模型”。A16Z 的报告直接把这个幻觉打碎了。数据显示企业 AI 预算里真正花在模型训练上的比例低得可怜大部分钱流向了推理部署和系统集成。这个结论我第一次看到的时候也愣了一下但仔细想想完全合理。训练一个像样的基础模型光是算力成本就是千万美元级别更别说还要养一个几十人的算法团队。对绝大多数企业来说这笔账根本算不过来。他们真正需要的是把现成的模型能力接进自己的业务流程里解决具体的业务问题。比如一个电商公司它不需要自己训一个模型来理解商品描述它需要的是把现有的语言模型接进客服系统、商品推荐系统和库存管理系统。推理成本这块报告里给了一个很具体的数字企业花在推理上的钱是训练的三到五倍。这个比例背后是实实在在的业务需求。训练是一次性的投入推理是每天每时每刻都在发生的消耗。一个中等规模的客服系统每天处理几万次对话每次对话消耗几百到几千个 Token一个月下来的推理成本相当可观。系统集成这块更是个无底洞。把 AI 能力接进现有的 ERP、CRM、数据库需要大量的工程工作。数据格式的转换、API 的对接、权限的管理、异常的处理每一项都是实打实的工作量。我去年帮一个客户做 AI 工单分类系统光是跟他们的老系统做对接就花了整个项目一半的时间。模型调用本身反而简单几行代码就搞定了。2.2 中小企业的 AI 采用率被严重低估另一个反常识的点是中小企业的 AI 采用速度。圈子里有个流行的说法是“AI 是大公司的游戏中小企业玩不起”。A16Z 的数据显示这个判断是错的。中小企业的 AI 采用率在过去一年里涨得非常快而且他们用的方式跟大公司完全不同。大公司倾向于自建平台、定制模型、搞一套完整的 AI 中台。中小企业没这个资源他们直接买现成的 SaaS 工具或者用 API 拼一个轻量级的解决方案。我认识一个做外贸的朋友公司就十几个人他们用 AI 来做客户邮件的自动分类和回复建议一个月花在 API 上的钱不到两百美元但效率提升非常明显。这个现象背后的逻辑其实很简单AI 能力的获取门槛在快速下降。以前你要用 AI得自己搭环境、训模型、调参数。现在你注册一个账号拿一个 API Key几行代码就能跑起来。门槛低了采用速度自然就快了。报告里提到员工规模在五十人以下的企业AI 工具的渗透率已经超过了百分之四十这个数字比很多人的预期要高得多。2.3 自建模型的 ROI 远低于调用现成 API报告里还有一个让我印象深刻的结论对于绝大多数企业来说自建模型的投入产出比远低于直接调用现成 API。这个结论可能会让一些技术团队不太舒服但数据摆在那里。自建模型的好处是可控性强、数据隐私有保障、可以针对特定场景做优化。但代价是什么呢你需要养一个算法团队需要买算力需要做持续的维护和迭代。这些成本加起来对于年营收在几千万到几个亿的企业来说很难在合理的时间内收回。调用现成 API 的好处是成本低、上手快、模型能力还在持续提升。你不需要关心底层的基础设施只需要关注业务逻辑。当然数据隐私是个问题但对于很多场景来说这个问题的严重性被高估了。你完全可以通过数据脱敏、私有部署等方式来缓解。我个人的经验是除非你的业务场景非常特殊通用模型完全搞不定否则自建模型基本是个亏本买卖。有那个资源和精力不如把业务逻辑做深做透把 AI 能力真正用起来。3. 反常识真相之二Agent 的完成率远比宣传的低3.1 Agent 的真实任务完成率只有三到五成A16Z 的第二份报告里最让我震惊的数据是 Agent 的任务完成率。市面上很多 Agent 产品的宣传给人的感觉是“你只要说一句话它就能帮你搞定一切”。但报告里的实测数据显示在复杂的多步骤任务上Agent 的端到端完成率只有百分之三十到五十。这个数字意味着什么意味着你让 Agent 帮你订一张机票它有一半的概率会搞砸。可能是日期搞错了可能是航班选错了可能是支付环节卡住了。对于简单的单步任务比如查个天气、设个提醒完成率能到百分之八九十。但一旦任务涉及多个步骤、多个系统、多个判断完成率就断崖式下跌。我自己做 Agent 开发的时候对这个深有体会。你写一个 Agent 来帮用户处理退款申请它需要理解用户的诉求、查询订单信息、判断是否符合退款条件、执行退款操作、通知用户。这五个步骤里每一步都有出错的可能。理解错了用户的意图、查错了订单、判断逻辑有漏洞、退款接口调用失败、通知没发出去。五个步骤每个步骤百分之九十的准确率乘起来就只剩百分之五十九了。3.2 多 Agent 协作听起来很美做起来很坑报告里还专门讨论了多 Agent 协作这个方向。现在圈子里很流行“多 AI 协作”的概念让多个 Agent 各司其职、互相配合来完成复杂任务。这个想法听起来很优雅但实际落地的时候坑非常多。最大的问题是通信成本。多个 Agent 之间需要传递信息、协调行动、处理冲突。每一次通信都是一次 Token 消耗都是一次潜在的误解。我试过一个由三个 Agent 组成的客服系统一个负责理解用户意图一个负责查询知识库一个负责生成回复。结果发现光是三个 Agent 之间的协调逻辑就写了上千行代码而且经常出现“理解 Agent 觉得用户想退货查询 Agent 查成了换货回复 Agent 按退货写了回复”这种混乱情况。报告里给的建议是在 Agent 技术还不够成熟的阶段优先考虑单 Agent 加工具调用的方案。一个 Agent 负责核心决策需要什么能力就调用什么工具。这样架构简单、调试方便、出错也容易定位。多 Agent 协作可以作为长期方向来探索但不适合作为当前的主力方案。3.3 Agent 的可靠性问题本质上是工程问题很多人把 Agent 的可靠性问题归结为“模型不够聪明”。A16Z 的报告给出了不同的视角Agent 的可靠性问题很大程度上是工程问题不是模型问题。什么意思呢就是很多 Agent 失败的原因不是模型理解错了而是工程实现上有缺陷。比如没有做输入校验、没有做异常处理、没有做状态管理、没有做重试机制。这些在传统软件工程里都是基本功但在 Agent 开发里经常被忽略。我举个例子。你让 Agent 去调用一个 API 获取数据如果这个 API 偶尔会超时你的 Agent 有没有做重试如果 API 返回了非预期的格式你的 Agent 有没有做容错如果 API 需要认证而 Token 过期了你的 Agent 有没有做刷新这些问题的答案如果都是“没有”那 Agent 的失败率当然高。报告里提到那些完成率比较高的 Agent 产品在工程实现上都下了很大功夫。它们有完善的错误处理机制、有状态持久化、有操作日志、有人工兜底方案。这些工作不性感但决定了 Agent 能不能真正用起来。4. 反常识真相之三Token 成本下降不等于应用成本下降4.1 Token 单价确实在降但用量涨得更快A16Z 的报告里有一个很明确的趋势Token 的单价在过去两年里下降了超过百分之九十。这个降幅非常惊人从每百万 Token 几十美元降到了几美元甚至更低。很多人的直觉是Token 便宜了AI 应用的成本就应该大幅下降。但实际情况是很多 AI 应用的总成本并没有降有些甚至还在涨。原因很简单Token 单价降了但用量涨得更快。以前你不敢让模型处理长文本因为太贵了。现在便宜了你把整本手册、整个知识库都塞进去。以前你不敢让 Agent 做多轮推理现在便宜了你让它反复思考、反复验证。用量一涨总成本就上去了。我自己的项目就有这个体会。最开始做文档问答的时候每次只检索最相关的三段文本送给模型Token 消耗很少。后来觉得效果不够好改成送十段文本Token 消耗直接翻了三倍多。再后来加了多轮推理和结果验证Token 消耗又翻了一倍。虽然单价降了但总账单反而比以前高了。4.2 算力成本只是冰山一角报告里还提醒了一个容易被忽略的点算力成本只是 AI 应用总成本的一部分而且往往不是最大的那部分。真正的大头在数据准备、系统集成、运维监控和人力投入上。数据准备这块你需要清洗数据、标注数据、构建向量库、维护索引。这些工作都需要人来做而且不是一次性的需要持续投入。系统集成这块你需要对接各种内部系统、处理各种边界情况、保证系统的稳定性。运维监控这块你需要监控 API 的调用情况、处理异常、优化性能。人力投入这块你需要产品经理、工程师、运营人员来维护整个系统。我算过一笔账一个中等规模的 AI 应用算力成本大概占总成本的百分之二十到三十剩下的百分之七十到八十都是工程和人力成本。所以光盯着 Token 单价看很容易得出错误的结论。4.3 成本优化的关键在架构设计不在砍 Token既然 Token 成本不是大头那成本优化的重点就不应该放在“怎么少用 Token”上而应该放在架构设计上。报告里给了一些很实用的建议。第一个建议是缓存。很多 AI 应用的请求是重复的或者高度相似的。把常见的请求结果缓存起来可以大幅减少 API 调用。我做过一个项目加了缓存之后API 调用量直接降了百分之四十。第二个建议是分级处理。不是所有请求都需要用最贵的模型。简单的分类、提取任务用小模型复杂的推理、生成任务用大模型。根据请求的复杂度动态选择模型可以在保证效果的同时控制成本。第三个建议是异步处理。不是所有请求都需要实时响应。把一些非紧急的任务放到队列里异步处理可以更好地利用算力资源也可以选择更便宜的时段来执行。这些优化手段的效果往往比抠 Token 用量要好得多。而且它们不会牺牲用户体验有些甚至能提升响应速度。5. 反常识真相之四AI 编程工具的实际效率提升被高估了5.1 代码生成快了但调试和集成没快A16Z 的报告里提到了 AI 编程工具的普及情况。现在几乎所有的开发者都在用 AI 辅助编程从代码补全到整段生成工具越来越强大。但报告里有一个数据很有意思开发者自己感知到的效率提升和实际的项目交付效率提升之间存在明显的差距。开发者感觉自己的编码速度提升了百分之五十甚至更多但项目的整体交付周期只缩短了百分之十到二十。这个差距从哪里来的答案是调试和集成。AI 生成的代码第一眼看起来往往很合理但仔细一跑就发现各种问题。边界条件没处理、异常情况没考虑、和现有代码的风格不一致、依赖的库版本不对。这些问题需要开发者花大量时间去调试和修复。我自己的经验是AI 生成的代码花在调试上的时间往往是写代码本身的两三倍。集成的问题更麻烦。AI 生成的代码往往是孤立的片段把它接进现有的系统里需要考虑接口兼容、数据格式、错误处理、性能影响。这些工作 AI 帮不上太多忙还是得靠人来做。5.2 提示词工程的门槛被低估了报告里还提到一个现象很多团队在引入 AI 编程工具后发现效果没有预期好原因往往出在提示词上。写一个好的提示词让 AI 生成高质量的代码本身就是一个需要学习和练习的技能。好的提示词需要包含哪些要素首先是清晰的上下文告诉 AI 这个代码是干什么用的、在什么环境里运行、有什么约束条件。其次是明确的输入输出说清楚函数的参数和返回值是什么格式。然后是具体的示例给一两个输入输出的例子让 AI 理解你的意图。最后是边界条件告诉 AI 需要处理哪些异常情况。我见过很多开发者写提示词的时候就一句话“帮我写一个排序函数”然后抱怨 AI 生成的代码不好用。这就像你跟一个新人说“帮我做个网站”然后抱怨他做出来的东西不符合你的预期。提示词的质量很大程度上决定了 AI 输出的质量。5.3 AI 编程工具最适合的场景是“填空”而不是“创作”报告里还有一个很实用的结论AI 编程工具最适合的场景是“填空”而不是“创作”。什么意思呢就是当你已经有了清晰的架构设计、明确的函数签名、详细的注释说明让 AI 来填充具体的实现效果最好。当你让 AI 从零开始设计一个模块、创造一个功能效果往往不理想。这个结论跟我的经验完全吻合。我现在的做法是先自己把接口定义好、把注释写清楚、把测试用例列出来然后让 AI 去实现具体的逻辑。这样生成的代码质量高、调试时间短、集成也顺利。反过来如果我让 AI 自己去设计一个模块它往往会过度设计或者设计不足改起来比自己写还费劲。所以 AI 编程工具的正确用法是把它当成一个执行力很强但需要明确指令的助手而不是一个能替你思考的架构师。6. 这些反常识真相背后的共同逻辑6.1 AI 的能力边界比宣传的窄但比怀疑的宽把这几份报告里的反常识点串起来看会发现一个共同的逻辑AI 的能力边界比市场上宣传的要窄但比很多怀疑者认为的要宽。宣传里说 AI 什么都能干Agent 能替你完成一切任务AI 编程能替代程序员。这些说法夸大了 AI 的能力。但另一边很多人觉得 AI 就是个玩具、Agent 根本不靠谱、AI 编程就是噱头。这些说法又低估了 AI 的能力。真实的情况在中间。AI 在特定场景下非常强大比如文本分类、信息提取、代码补全、内容生成。但在需要多步推理、跨系统协作、处理模糊需求的场景下AI 的表现还不稳定。Agent 在简单任务上很好用在复杂任务上还需要人的兜底。AI 编程能提升效率但不能替代开发者的核心能力。理解这个边界很重要。它决定了你应该把 AI 用在什么地方、期望它达到什么效果、需要做什么样的兜底准备。6.2 工程能力比模型能力更决定成败另一个共同逻辑是在当前的 AI 应用开发中工程能力比模型能力更决定成败。模型能力是基础但把模型能力转化为可用的产品靠的是工程。同样的模型不同的工程实现效果可以差很远。有的团队做的 Agent 完成率能到百分之七十有的只有百分之三十。差距不在模型上在工程上。有没有做输入校验、有没有做异常处理、有没有做状态管理、有没有做人工兜底这些工程细节决定了最终的用户体验。这个逻辑对开发者的启示是不要只盯着模型的能力提升也要花时间打磨工程实现。一个好的工程架构可以让中等能力的模型发挥出上等效果。一个糟糕的工程实现会让最先进的模型也变得不可用。6.3 成本结构决定了商业模式最后一个共同逻辑是AI 应用的成本结构决定了什么样的商业模式能跑通。算力成本只是小头工程和人力成本才是大头。这意味着AI 应用的商业模式不能只靠“卖 Token 差价”来赚钱。那些能跑通的 AI 产品往往是在某个垂直场景里做深做透通过提升效率、降低人力成本来创造价值。它们卖的不是 AI 能力本身而是 AI 能力带来的业务结果。比如一个 AI 客服产品它卖的不是对话能力而是“帮你减少多少客服人力、提升多少客户满意度”。理解成本结构才能设计出合理的定价模式和商业策略。光看 Token 单价来定价很容易亏本。7. 实操建议怎么把这些认知用到实际工作里7.1 做 AI 应用前先算清楚三笔账基于上面的分析我建议在做任何 AI 应用之前先算清楚三笔账。第一笔是算力账。你的应用每天会产生多少次模型调用每次调用大概消耗多少 Token按当前的单价算下来一个月的算力成本是多少这笔账要算得细一点把峰值和均值都考虑进去。第二笔是工程账。你需要多少工程师来开发和维护这个系统需要多长时间来搭建和调试后续的迭代和优化需要多少投入这笔账往往比算力账大得多但很多人会忽略。第三笔是价值账。你的 AI 应用能带来多少业务价值是减少了人力成本、提升了转化率、还是改善了用户体验这个价值能不能量化能不能覆盖前两笔账的成本这三笔账算清楚了你才知道这个项目值不值得做、应该怎么做、期望什么样的回报。7.2 Agent 开发优先做单 Agent 加工具调用如果你正在做 Agent 相关的开发我的建议是优先考虑单 Agent 加工具调用的架构。一个 Agent 负责核心的决策和调度需要什么能力就调用什么工具。这样架构简单、调试方便、出错容易定位。具体怎么做首先把任务拆解清楚明确 Agent 需要完成哪些步骤。然后为每个步骤定义清晰的工具接口输入是什么、输出是什么、异常怎么处理。接着写 Agent 的核心逻辑让它根据当前状态决定调用哪个工具。最后加上完善的错误处理和人工兜底机制。多 Agent 协作可以作为长期探索方向但在当前阶段单 Agent 加工具调用的方案更可靠、更容易落地。7.3 成本优化从架构入手别只盯着 Token成本优化这块我的经验是从架构入手别只盯着 Token 用量。缓存、分级处理、异步处理这三个手段的效果往往比抠 Token 好得多。缓存这块把常见的请求结果存起来下次遇到相同或相似的请求直接返回。分级处理这块简单的任务用小模型复杂的任务用大模型根据请求的复杂度动态选择。异步处理这块非紧急的任务放到队列里慢慢处理避开高峰期也可以选择更便宜的时段。这些优化手段需要一些工程投入但回报很可观。我做过的一个项目加了缓存和分级处理之后API 成本降了将近一半响应速度还提升了。7.4 AI 编程工具的正确打开方式如果你在用 AI 编程工具我的建议是把它当成“填空”工具而不是“创作”工具。先自己把架构设计好、接口定义好、注释写清楚然后让 AI 去填充具体的实现。具体操作上我会先写函数的签名和文档注释说明这个函数是干什么的、参数是什么、返回值是什么、有什么约束。然后写几个测试用例覆盖正常情况和边界情况。接着让 AI 根据这些信息生成实现代码。最后跑测试根据结果让 AI 调整。这样用下来AI 生成的代码质量高、调试时间短、集成也顺利。反过来如果让 AI 从零开始设计往往要来回改很多次反而更费时间。8. 几个常见问题的快问快答8.1 Agent 的完成率低是不是说明 Agent 没前途不是。完成率低说明当前的 Agent 技术还不够成熟需要工程上的补足和场景上的选择。在简单任务上Agent 已经很好用了。在复杂任务上Agent 需要人的兜底和配合。随着模型能力的提升和工程实践的积累Agent 的完成率会逐步提高。这个方向是有前途的只是需要耐心和务实。8.2 Token 价格还会继续降吗大概率会。模型效率在提升推理成本在下降竞争也在加剧。但降幅可能会放缓而且 Token 成本在总成本里的占比本来就不高。所以不要把商业模式的希望寄托在 Token 降价上还是要从业务价值出发来设计产品。8.3 小团队做 AI 应用应该自建模型还是调 API除非你的场景非常特殊通用模型完全搞不定否则调 API 是更务实的选择。自建模型的成本太高小团队很难承担。把有限的资源用在业务逻辑和用户体验上回报会更高。8.4 AI 编程工具会让程序员失业吗短期内不会。AI 编程工具提升的是编码效率但软件开发的核心工作——理解需求、设计架构、调试问题、保证质量——还是需要人来完成。AI 改变的是程序员的工作方式不是取代程序员。会用 AI 的程序员效率会更高竞争力会更强。8.5 怎么判断一个 AI 应用值不值得做算清楚三笔账算力账、工程账、价值账。如果价值账能覆盖前两笔账而且有合理的利润空间就值得做。如果算下来发现成本太高、价值不明确就要慎重考虑。不要因为“AI 很火”就盲目投入也不要因为“AI 不成熟”就完全放弃。关键是找到那个能力边界和商业价值的交集。9. 我个人的一些体会做 AI 应用这两年最大的体会就是这个行业变化太快但有些基本逻辑是不变的。模型能力在快速提升但工程实现的重要性没有降低。Token 价格在下降但成本控制的重点不在 Token 上。Agent 的概念很火但落地的时候还是要从简单场景做起。A16Z 这两份报告的价值不在于给出了什么惊人的预测而在于用数据把很多被情绪掩盖的真相摆了出来。企业 AI 预算的流向、Agent 的真实完成率、Token 成本的结构、AI 编程的实际效果这些问题的答案跟很多人的直觉不一样。理解这些真相能帮我们做出更务实的决策。最后分享一个小技巧。如果你在评估一个 AI 应用的方向不妨先做一个最小可行的原型用真实的数据跑一遍看看效果和成本到底怎么样。不要光看报告、光听分享自己动手试一次得到的认知会比看十篇文章都深刻。AI 这个领域实践出真知。 
长河君 · 2026/10/26 20:47:49 · 阅读 1.2k A16Z报告揭示AI与Agent的四大反常识真相
1. 这两份报告到底讲了什么为什么值得聊A16Z 这家机构在科技投资圈的分量不用我多说他们每年出的 AI 报告基本就是行业风向标。最近他们连着发了两份报告一份聚焦生成式 AI 的企业级落地另一份专门讲 AI Agent 的现状与未来。我把这两份报告翻来覆去读了几遍又结合自己这两年做 AI 应用开发的实际经验发现里面有不少结论跟圈子里流行的认知是拧着来的。先说清楚这两份报告的核心内容。第一份报告主要讲的是企业侧 AI 的采用率、预算分配和实际回报。第二份报告则把镜头对准了 Agent 这个赛道从技术架构、商业模式到落地场景都做了梳理。两份报告加起来覆盖了从底层算力到上层应用的完整链条涉及的关键词包括 A16Z、AI、Agent、Token、算力这几个核心概念。为什么我觉得这两份报告值得拿出来单独聊因为市面上关于 AI 的讨论太容易走极端了。要么是“AI 马上要取代所有人”的焦虑贩卖要么是“AI 就是个高级玩具”的轻视。A16Z 这两份报告的价值在于它们用实打实的数据和案例把很多被情绪掩盖的真相给挖了出来。比如企业到底愿意为 AI 花多少钱、Agent 的真实完成率是多少、Token 成本下降对商业模式意味着什么这些问题的答案跟很多人的直觉完全相反。我写这篇东西的目的很简单把报告里那些反常识的点拎出来结合我自己踩过的坑和实际观察给正在做 AI 产品、搞 Agent 开发或者单纯想搞清楚这个行业走向的朋友一些参考。不管你是刚入门的开发者还是已经在带团队做 AI 落地的负责人这些内容应该都能帮你少走点弯路。2. 反常识真相之一企业 AI 预算的流向跟你想的不一样2.1 预算大头不在模型训练而在推理和集成很多人一提到企业搞 AI第一反应就是“他们在训练自己的大模型”。A16Z 的报告直接把这个幻觉打碎了。数据显示企业 AI 预算里真正花在模型训练上的比例低得可怜大部分钱流向了推理部署和系统集成。这个结论我第一次看到的时候也愣了一下但仔细想想完全合理。训练一个像样的基础模型光是算力成本就是千万美元级别更别说还要养一个几十人的算法团队。对绝大多数企业来说这笔账根本算不过来。他们真正需要的是把现成的模型能力接进自己的业务流程里解决具体的业务问题。比如一个电商公司它不需要自己训一个模型来理解商品描述它需要的是把现有的语言模型接进客服系统、商品推荐系统和库存管理系统。推理成本这块报告里给了一个很具体的数字企业花在推理上的钱是训练的三到五倍。这个比例背后是实实在在的业务需求。训练是一次性的投入推理是每天每时每刻都在发生的消耗。一个中等规模的客服系统每天处理几万次对话每次对话消耗几百到几千个 Token一个月下来的推理成本相当可观。系统集成这块更是个无底洞。把 AI 能力接进现有的 ERP、CRM、数据库需要大量的工程工作。数据格式的转换、API 的对接、权限的管理、异常的处理每一项都是实打实的工作量。我去年帮一个客户做 AI 工单分类系统光是跟他们的老系统做对接就花了整个项目一半的时间。模型调用本身反而简单几行代码就搞定了。2.2 中小企业的 AI 采用率被严重低估另一个反常识的点是中小企业的 AI 采用速度。圈子里有个流行的说法是“AI 是大公司的游戏中小企业玩不起”。A16Z 的数据显示这个判断是错的。中小企业的 AI 采用率在过去一年里涨得非常快而且他们用的方式跟大公司完全不同。大公司倾向于自建平台、定制模型、搞一套完整的 AI 中台。中小企业没这个资源他们直接买现成的 SaaS 工具或者用 API 拼一个轻量级的解决方案。我认识一个做外贸的朋友公司就十几个人他们用 AI 来做客户邮件的自动分类和回复建议一个月花在 API 上的钱不到两百美元但效率提升非常明显。这个现象背后的逻辑其实很简单AI 能力的获取门槛在快速下降。以前你要用 AI得自己搭环境、训模型、调参数。现在你注册一个账号拿一个 API Key几行代码就能跑起来。门槛低了采用速度自然就快了。报告里提到员工规模在五十人以下的企业AI 工具的渗透率已经超过了百分之四十这个数字比很多人的预期要高得多。2.3 自建模型的 ROI 远低于调用现成 API报告里还有一个让我印象深刻的结论对于绝大多数企业来说自建模型的投入产出比远低于直接调用现成 API。这个结论可能会让一些技术团队不太舒服但数据摆在那里。自建模型的好处是可控性强、数据隐私有保障、可以针对特定场景做优化。但代价是什么呢你需要养一个算法团队需要买算力需要做持续的维护和迭代。这些成本加起来对于年营收在几千万到几个亿的企业来说很难在合理的时间内收回。调用现成 API 的好处是成本低、上手快、模型能力还在持续提升。你不需要关心底层的基础设施只需要关注业务逻辑。当然数据隐私是个问题但对于很多场景来说这个问题的严重性被高估了。你完全可以通过数据脱敏、私有部署等方式来缓解。我个人的经验是除非你的业务场景非常特殊通用模型完全搞不定否则自建模型基本是个亏本买卖。有那个资源和精力不如把业务逻辑做深做透把 AI 能力真正用起来。3. 反常识真相之二Agent 的完成率远比宣传的低3.1 Agent 的真实任务完成率只有三到五成A16Z 的第二份报告里最让我震惊的数据是 Agent 的任务完成率。市面上很多 Agent 产品的宣传给人的感觉是“你只要说一句话它就能帮你搞定一切”。但报告里的实测数据显示在复杂的多步骤任务上Agent 的端到端完成率只有百分之三十到五十。这个数字意味着什么意味着你让 Agent 帮你订一张机票它有一半的概率会搞砸。可能是日期搞错了可能是航班选错了可能是支付环节卡住了。对于简单的单步任务比如查个天气、设个提醒完成率能到百分之八九十。但一旦任务涉及多个步骤、多个系统、多个判断完成率就断崖式下跌。我自己做 Agent 开发的时候对这个深有体会。你写一个 Agent 来帮用户处理退款申请它需要理解用户的诉求、查询订单信息、判断是否符合退款条件、执行退款操作、通知用户。这五个步骤里每一步都有出错的可能。理解错了用户的意图、查错了订单、判断逻辑有漏洞、退款接口调用失败、通知没发出去。五个步骤每个步骤百分之九十的准确率乘起来就只剩百分之五十九了。3.2 多 Agent 协作听起来很美做起来很坑报告里还专门讨论了多 Agent 协作这个方向。现在圈子里很流行“多 AI 协作”的概念让多个 Agent 各司其职、互相配合来完成复杂任务。这个想法听起来很优雅但实际落地的时候坑非常多。最大的问题是通信成本。多个 Agent 之间需要传递信息、协调行动、处理冲突。每一次通信都是一次 Token 消耗都是一次潜在的误解。我试过一个由三个 Agent 组成的客服系统一个负责理解用户意图一个负责查询知识库一个负责生成回复。结果发现光是三个 Agent 之间的协调逻辑就写了上千行代码而且经常出现“理解 Agent 觉得用户想退货查询 Agent 查成了换货回复 Agent 按退货写了回复”这种混乱情况。报告里给的建议是在 Agent 技术还不够成熟的阶段优先考虑单 Agent 加工具调用的方案。一个 Agent 负责核心决策需要什么能力就调用什么工具。这样架构简单、调试方便、出错也容易定位。多 Agent 协作可以作为长期方向来探索但不适合作为当前的主力方案。3.3 Agent 的可靠性问题本质上是工程问题很多人把 Agent 的可靠性问题归结为“模型不够聪明”。A16Z 的报告给出了不同的视角Agent 的可靠性问题很大程度上是工程问题不是模型问题。什么意思呢就是很多 Agent 失败的原因不是模型理解错了而是工程实现上有缺陷。比如没有做输入校验、没有做异常处理、没有做状态管理、没有做重试机制。这些在传统软件工程里都是基本功但在 Agent 开发里经常被忽略。我举个例子。你让 Agent 去调用一个 API 获取数据如果这个 API 偶尔会超时你的 Agent 有没有做重试如果 API 返回了非预期的格式你的 Agent 有没有做容错如果 API 需要认证而 Token 过期了你的 Agent 有没有做刷新这些问题的答案如果都是“没有”那 Agent 的失败率当然高。报告里提到那些完成率比较高的 Agent 产品在工程实现上都下了很大功夫。它们有完善的错误处理机制、有状态持久化、有操作日志、有人工兜底方案。这些工作不性感但决定了 Agent 能不能真正用起来。4. 反常识真相之三Token 成本下降不等于应用成本下降4.1 Token 单价确实在降但用量涨得更快A16Z 的报告里有一个很明确的趋势Token 的单价在过去两年里下降了超过百分之九十。这个降幅非常惊人从每百万 Token 几十美元降到了几美元甚至更低。很多人的直觉是Token 便宜了AI 应用的成本就应该大幅下降。但实际情况是很多 AI 应用的总成本并没有降有些甚至还在涨。原因很简单Token 单价降了但用量涨得更快。以前你不敢让模型处理长文本因为太贵了。现在便宜了你把整本手册、整个知识库都塞进去。以前你不敢让 Agent 做多轮推理现在便宜了你让它反复思考、反复验证。用量一涨总成本就上去了。我自己的项目就有这个体会。最开始做文档问答的时候每次只检索最相关的三段文本送给模型Token 消耗很少。后来觉得效果不够好改成送十段文本Token 消耗直接翻了三倍多。再后来加了多轮推理和结果验证Token 消耗又翻了一倍。虽然单价降了但总账单反而比以前高了。4.2 算力成本只是冰山一角报告里还提醒了一个容易被忽略的点算力成本只是 AI 应用总成本的一部分而且往往不是最大的那部分。真正的大头在数据准备、系统集成、运维监控和人力投入上。数据准备这块你需要清洗数据、标注数据、构建向量库、维护索引。这些工作都需要人来做而且不是一次性的需要持续投入。系统集成这块你需要对接各种内部系统、处理各种边界情况、保证系统的稳定性。运维监控这块你需要监控 API 的调用情况、处理异常、优化性能。人力投入这块你需要产品经理、工程师、运营人员来维护整个系统。我算过一笔账一个中等规模的 AI 应用算力成本大概占总成本的百分之二十到三十剩下的百分之七十到八十都是工程和人力成本。所以光盯着 Token 单价看很容易得出错误的结论。4.3 成本优化的关键在架构设计不在砍 Token既然 Token 成本不是大头那成本优化的重点就不应该放在“怎么少用 Token”上而应该放在架构设计上。报告里给了一些很实用的建议。第一个建议是缓存。很多 AI 应用的请求是重复的或者高度相似的。把常见的请求结果缓存起来可以大幅减少 API 调用。我做过一个项目加了缓存之后API 调用量直接降了百分之四十。第二个建议是分级处理。不是所有请求都需要用最贵的模型。简单的分类、提取任务用小模型复杂的推理、生成任务用大模型。根据请求的复杂度动态选择模型可以在保证效果的同时控制成本。第三个建议是异步处理。不是所有请求都需要实时响应。把一些非紧急的任务放到队列里异步处理可以更好地利用算力资源也可以选择更便宜的时段来执行。这些优化手段的效果往往比抠 Token 用量要好得多。而且它们不会牺牲用户体验有些甚至能提升响应速度。5. 反常识真相之四AI 编程工具的实际效率提升被高估了5.1 代码生成快了但调试和集成没快A16Z 的报告里提到了 AI 编程工具的普及情况。现在几乎所有的开发者都在用 AI 辅助编程从代码补全到整段生成工具越来越强大。但报告里有一个数据很有意思开发者自己感知到的效率提升和实际的项目交付效率提升之间存在明显的差距。开发者感觉自己的编码速度提升了百分之五十甚至更多但项目的整体交付周期只缩短了百分之十到二十。这个差距从哪里来的答案是调试和集成。AI 生成的代码第一眼看起来往往很合理但仔细一跑就发现各种问题。边界条件没处理、异常情况没考虑、和现有代码的风格不一致、依赖的库版本不对。这些问题需要开发者花大量时间去调试和修复。我自己的经验是AI 生成的代码花在调试上的时间往往是写代码本身的两三倍。集成的问题更麻烦。AI 生成的代码往往是孤立的片段把它接进现有的系统里需要考虑接口兼容、数据格式、错误处理、性能影响。这些工作 AI 帮不上太多忙还是得靠人来做。5.2 提示词工程的门槛被低估了报告里还提到一个现象很多团队在引入 AI 编程工具后发现效果没有预期好原因往往出在提示词上。写一个好的提示词让 AI 生成高质量的代码本身就是一个需要学习和练习的技能。好的提示词需要包含哪些要素首先是清晰的上下文告诉 AI 这个代码是干什么用的、在什么环境里运行、有什么约束条件。其次是明确的输入输出说清楚函数的参数和返回值是什么格式。然后是具体的示例给一两个输入输出的例子让 AI 理解你的意图。最后是边界条件告诉 AI 需要处理哪些异常情况。我见过很多开发者写提示词的时候就一句话“帮我写一个排序函数”然后抱怨 AI 生成的代码不好用。这就像你跟一个新人说“帮我做个网站”然后抱怨他做出来的东西不符合你的预期。提示词的质量很大程度上决定了 AI 输出的质量。5.3 AI 编程工具最适合的场景是“填空”而不是“创作”报告里还有一个很实用的结论AI 编程工具最适合的场景是“填空”而不是“创作”。什么意思呢就是当你已经有了清晰的架构设计、明确的函数签名、详细的注释说明让 AI 来填充具体的实现效果最好。当你让 AI 从零开始设计一个模块、创造一个功能效果往往不理想。这个结论跟我的经验完全吻合。我现在的做法是先自己把接口定义好、把注释写清楚、把测试用例列出来然后让 AI 去实现具体的逻辑。这样生成的代码质量高、调试时间短、集成也顺利。反过来如果我让 AI 自己去设计一个模块它往往会过度设计或者设计不足改起来比自己写还费劲。所以 AI 编程工具的正确用法是把它当成一个执行力很强但需要明确指令的助手而不是一个能替你思考的架构师。6. 这些反常识真相背后的共同逻辑6.1 AI 的能力边界比宣传的窄但比怀疑的宽把这几份报告里的反常识点串起来看会发现一个共同的逻辑AI 的能力边界比市场上宣传的要窄但比很多怀疑者认为的要宽。宣传里说 AI 什么都能干Agent 能替你完成一切任务AI 编程能替代程序员。这些说法夸大了 AI 的能力。但另一边很多人觉得 AI 就是个玩具、Agent 根本不靠谱、AI 编程就是噱头。这些说法又低估了 AI 的能力。真实的情况在中间。AI 在特定场景下非常强大比如文本分类、信息提取、代码补全、内容生成。但在需要多步推理、跨系统协作、处理模糊需求的场景下AI 的表现还不稳定。Agent 在简单任务上很好用在复杂任务上还需要人的兜底。AI 编程能提升效率但不能替代开发者的核心能力。理解这个边界很重要。它决定了你应该把 AI 用在什么地方、期望它达到什么效果、需要做什么样的兜底准备。6.2 工程能力比模型能力更决定成败另一个共同逻辑是在当前的 AI 应用开发中工程能力比模型能力更决定成败。模型能力是基础但把模型能力转化为可用的产品靠的是工程。同样的模型不同的工程实现效果可以差很远。有的团队做的 Agent 完成率能到百分之七十有的只有百分之三十。差距不在模型上在工程上。有没有做输入校验、有没有做异常处理、有没有做状态管理、有没有做人工兜底这些工程细节决定了最终的用户体验。这个逻辑对开发者的启示是不要只盯着模型的能力提升也要花时间打磨工程实现。一个好的工程架构可以让中等能力的模型发挥出上等效果。一个糟糕的工程实现会让最先进的模型也变得不可用。6.3 成本结构决定了商业模式最后一个共同逻辑是AI 应用的成本结构决定了什么样的商业模式能跑通。算力成本只是小头工程和人力成本才是大头。这意味着AI 应用的商业模式不能只靠“卖 Token 差价”来赚钱。那些能跑通的 AI 产品往往是在某个垂直场景里做深做透通过提升效率、降低人力成本来创造价值。它们卖的不是 AI 能力本身而是 AI 能力带来的业务结果。比如一个 AI 客服产品它卖的不是对话能力而是“帮你减少多少客服人力、提升多少客户满意度”。理解成本结构才能设计出合理的定价模式和商业策略。光看 Token 单价来定价很容易亏本。7. 实操建议怎么把这些认知用到实际工作里7.1 做 AI 应用前先算清楚三笔账基于上面的分析我建议在做任何 AI 应用之前先算清楚三笔账。第一笔是算力账。你的应用每天会产生多少次模型调用每次调用大概消耗多少 Token按当前的单价算下来一个月的算力成本是多少这笔账要算得细一点把峰值和均值都考虑进去。第二笔是工程账。你需要多少工程师来开发和维护这个系统需要多长时间来搭建和调试后续的迭代和优化需要多少投入这笔账往往比算力账大得多但很多人会忽略。第三笔是价值账。你的 AI 应用能带来多少业务价值是减少了人力成本、提升了转化率、还是改善了用户体验这个价值能不能量化能不能覆盖前两笔账的成本这三笔账算清楚了你才知道这个项目值不值得做、应该怎么做、期望什么样的回报。7.2 Agent 开发优先做单 Agent 加工具调用如果你正在做 Agent 相关的开发我的建议是优先考虑单 Agent 加工具调用的架构。一个 Agent 负责核心的决策和调度需要什么能力就调用什么工具。这样架构简单、调试方便、出错容易定位。具体怎么做首先把任务拆解清楚明确 Agent 需要完成哪些步骤。然后为每个步骤定义清晰的工具接口输入是什么、输出是什么、异常怎么处理。接着写 Agent 的核心逻辑让它根据当前状态决定调用哪个工具。最后加上完善的错误处理和人工兜底机制。多 Agent 协作可以作为长期探索方向但在当前阶段单 Agent 加工具调用的方案更可靠、更容易落地。7.3 成本优化从架构入手别只盯着 Token成本优化这块我的经验是从架构入手别只盯着 Token 用量。缓存、分级处理、异步处理这三个手段的效果往往比抠 Token 好得多。缓存这块把常见的请求结果存起来下次遇到相同或相似的请求直接返回。分级处理这块简单的任务用小模型复杂的任务用大模型根据请求的复杂度动态选择。异步处理这块非紧急的任务放到队列里慢慢处理避开高峰期也可以选择更便宜的时段。这些优化手段需要一些工程投入但回报很可观。我做过的一个项目加了缓存和分级处理之后API 成本降了将近一半响应速度还提升了。7.4 AI 编程工具的正确打开方式如果你在用 AI 编程工具我的建议是把它当成“填空”工具而不是“创作”工具。先自己把架构设计好、接口定义好、注释写清楚然后让 AI 去填充具体的实现。具体操作上我会先写函数的签名和文档注释说明这个函数是干什么的、参数是什么、返回值是什么、有什么约束。然后写几个测试用例覆盖正常情况和边界情况。接着让 AI 根据这些信息生成实现代码。最后跑测试根据结果让 AI 调整。这样用下来AI 生成的代码质量高、调试时间短、集成也顺利。反过来如果让 AI 从零开始设计往往要来回改很多次反而更费时间。8. 几个常见问题的快问快答8.1 Agent 的完成率低是不是说明 Agent 没前途不是。完成率低说明当前的 Agent 技术还不够成熟需要工程上的补足和场景上的选择。在简单任务上Agent 已经很好用了。在复杂任务上Agent 需要人的兜底和配合。随着模型能力的提升和工程实践的积累Agent 的完成率会逐步提高。这个方向是有前途的只是需要耐心和务实。8.2 Token 价格还会继续降吗大概率会。模型效率在提升推理成本在下降竞争也在加剧。但降幅可能会放缓而且 Token 成本在总成本里的占比本来就不高。所以不要把商业模式的希望寄托在 Token 降价上还是要从业务价值出发来设计产品。8.3 小团队做 AI 应用应该自建模型还是调 API除非你的场景非常特殊通用模型完全搞不定否则调 API 是更务实的选择。自建模型的成本太高小团队很难承担。把有限的资源用在业务逻辑和用户体验上回报会更高。8.4 AI 编程工具会让程序员失业吗短期内不会。AI 编程工具提升的是编码效率但软件开发的核心工作——理解需求、设计架构、调试问题、保证质量——还是需要人来完成。AI 改变的是程序员的工作方式不是取代程序员。会用 AI 的程序员效率会更高竞争力会更强。8.5 怎么判断一个 AI 应用值不值得做算清楚三笔账算力账、工程账、价值账。如果价值账能覆盖前两笔账而且有合理的利润空间就值得做。如果算下来发现成本太高、价值不明确就要慎重考虑。不要因为“AI 很火”就盲目投入也不要因为“AI 不成熟”就完全放弃。关键是找到那个能力边界和商业价值的交集。9. 我个人的一些体会做 AI 应用这两年最大的体会就是这个行业变化太快但有些基本逻辑是不变的。模型能力在快速提升但工程实现的重要性没有降低。Token 价格在下降但成本控制的重点不在 Token 上。Agent 的概念很火但落地的时候还是要从简单场景做起。A16Z 这两份报告的价值不在于给出了什么惊人的预测而在于用数据把很多被情绪掩盖的真相摆了出来。企业 AI 预算的流向、Agent 的真实完成率、Token 成本的结构、AI 编程的实际效果这些问题的答案跟很多人的直觉不一样。理解这些真相能帮我们做出更务实的决策。最后分享一个小技巧。如果你在评估一个 AI 应用的方向不妨先做一个最小可行的原型用真实的数据跑一遍看看效果和成本到底怎么样。不要光看报告、光听分享自己动手试一次得到的认知会比看十篇文章都深刻。AI 这个领域实践出真知。