从 2024 年到 2025 年AI 行业出现了一个非常割裂的现象一边是大模型公司的估值持续走高GPU 采购动辄百亿级另一边是大量技术人开始私下讨论“大模型公司到底靠什么赚钱”。前 OpenAI 研究员公开看空大模型公司认为烧钱模式不可持续而知名 AI 评论人 Dwarkesh 却发文反驳抛出一个听起来更激进的观点AGI 会自己找工作。两个人的立场看似矛盾实际上是在争论同一个问题——当模型能力足够强时商业世界的成本逻辑是否还成立这篇文章不站队而是把这场辩论拆开来看大模型公司被看空的理由到底是什么AGI“自己找工作”在技术上意味着什么以及作为一个正在做 AI 应用开发的工程师你如何判断自己该押注哪一边。文章会用代码示例演示 Agent 的“自主找工作”能力边界并从工程视角给出可执行的判断框架。1. 这场争论到底在争什么先还原一下背景。这位前 OpenAI 研究员的看空逻辑并不是说“AI 没价值”而是认为大模型公司作为一种商业组织可能在 AGI 真正到来之前就撑不住。他的核心担忧拆解下来有三条训练与推理成本不可控。大模型每次迭代都要重新训练GPU 集群消耗的算力以几个月为单位成倍增长推理成本虽然在下滑但用户量和调用量也在快速增长。商业模式没有建立起护城河。人与人之间对“模型能力”差距的感知在缩小各家模型的知识水平趋同API 价格战越来越激烈没有谁拥有真正不可替代的定价权。AI 公司的人才密度与组织结构不匹配。顶级研究员和工程师的薪资极高但产出高度依赖少数核心成员这种组织结构的稳定性在长期扩张中很容易出问题。Dwarkesh 的反驳则站在另一个时间尺度上。他提出的“AGI 会自己找工作”强调的不是模型现在能干什么而是当模型能力超过人类平均执行水平之后会发生什么。到那个阶段AI 不再只是一个“被调用”的工具而是一个可以自主领取任务、自主完成工作、自主产生经济价值的独立主体。如果这一点成立那么原来用于评估“软件公司”的财务模型就不再适用因为劳动的供给端变了价值创造的机制也变了。这两方的争论点本质上不是“AI 行不行”而是你用什么时间尺度来评估你用什么商业模式来评估你相信技术进步的速度还是相信商业消耗的速度下面我把两边的论据展开你会发现它们其实在讨论同一件事的不同切面。2. 大模型公司为什么会被“看空”大模型公司的成本结构非常特殊它和传统的 SaaS 公司完全不一样。传统 SaaS 的边际成本很低客户增加一万个服务器成本可能只增加 10%然后这 10% 的成本换来的是更稳定的订阅收入。但大模型公司不是这样每一次模型调用都在产生真实的推理成本用户越多算力账单越高而用户付费的意愿并不一定同步增长。2.1 训练成本是“一次性豪赌”训练一个前沿大模型的成本行业公开数据已经从几千万美元一路涨到上亿美元。这里面包含数据采集、清洗、标注、集群搭建、实验调参、多次失败重跑等大量隐性开销。更关键的是训练成本本身是一个概率事件你可能花了一个亿最终得到的模型只是“更好一点”但不一定“好到值得再花一个亿”。这种投入产出比的不确定性让大模型公司的财务模型天然带有风险投资的特点而不是稳定经营企业的特点。2.2 推理成本是“规模诅咒”推理成本的问题正好反过来。训练成本是一次性投入推理成本是长期消耗。当你的模型用户量涨到千万级别每个用户每天调用几十次每次调用背后都是 GPU 在跑。早期的 API 定价能给公司带来利润是因为当时模型参数量小、计算量低。到了千亿参数时代推理成本虽然因为工程优化在下降但模型复杂度提升带来的计算量增长会抵消掉一部分优化红利。这也是为什么所有大模型公司都在疯狂做模型压缩、量化、蒸馏、KV Cache 优化。它们本质上是在和推理成本赛跑。跑赢了商业模型还成立跑不赢就只能靠融资续命。2.3 收入端的天花板再来看收入。大模型公司目前的收入来源主要有三类收入类型业态特征存在的问题C 端订阅制与用户直接对话按订阅收费用户付费意愿有限产品功能同质化留存率波动B 端 API 调用按 Token 计费面向开发者价格战激烈客户对成本敏感迁移成本低企业私有化部署协助企业建设大模型应用定制成本高难以标准化毛利率波动这三类收入的共同问题在于它们都需要依赖“外部人类客户”来产生收入。而如果 AGI 真的到了能自己干活的水平最直接的增量价值一定不是“卖给人类更多 API”而是“替人类完成过去必须雇人才干得了的工作”。这两条路线的商业想象力完全不是一个量级。从材料看更稳妥的判断是看空方的论据在“现阶段财务报表”的尺度上基本成立大模型公司确实面临比传统软件公司更高的资本消耗和更低的毛利率但反驳方的论据在“能力拐点之后”的尺度上也有道理因为一旦模型能力跨过某个临界点整个估值逻辑都会重写。3. “AGI 会自己找工作”——这个判断到底在说什么“AGI 会自己找工作”这句话听起来像科幻但在技术演进层面它其实可以被拆成三个可验证的层次。3.1 第一层AI 能替代“具体岗位的执行环节”这是最接近现实的一层。现在的大模型已经能写代码、写文档、做翻译、做数据分析、画图、做视频脚本。很多岗位的日常工作已经被拆解成一个个可自动化的任务然后交给模型去完成。这一层对应的商业模式是“AI 替代人力”也就是过去需要三个人干一周的活现在一个人加一个模型干一天。这一层已经在大规模发生。市场上大量 AI 应用公司做的就是这个事客服机器人替代客服、代码助手替代初级程序员、营销文案生成替代文案岗位。这些产品本质上就是在帮 AI“找工作”。3.2 第二层AI 能自主完成“一个完整的工作流程”这一层对应的是 Agent 技术。一个真正意义上的 Agent不是只会回答你一个问题而是能够接收一个目标拆解成步骤调用工具完成任务并且在失败时自我修正。比起“替代岗位的执行环节”这一层更接近“替代一个岗位上的人”。打个比方第一层的 AI 像一个熟练的实习生你告诉它每一步做什么它能做第二层的 AI 像一个项目助理你告诉它最终目标是什么它自己规划路径、协调资源、交付结果。3.3 第三层AI 能自己发现“有经济价值的工作”这是“自己找工作”最激进的含义也是 Dwarkesh 反驳里真正有冲击力的部分。当 AI 不仅能完成已经存在的工作描述还能自己观察环境、发现需求、提出方案并执行时它就不再是一个“被雇佣的工具”而是一个“未被雇佣的劳动者”。举个例子。一个传统的电商公司要分析用户流失需要数据分析师先提数、再可视化、再写报告。这个流程是“人定义任务AI 执行任务”。而到了第三层AI 可以自己去接数据分析师的岗位描述自己去看数据库里的数据自己发现“最近 30 天新用户留存率下降了 15%”然后自己生成一份分析报告再自己用邮件发给你。它是自己发现了这件事有价值而不是等你告诉它。这一层现在还远没有实现但它决定了 AGI 时代“工作”的定义。如果这个判断成立那么大模型公司的价值就不仅仅是“卖模型”而是成为所有“数字劳动者”的运营平台。3.4 关键判断技术拐点在哪争论双方其实都认可“AGI 会到来”分歧在于“拐点之前钱够不够烧”。Dwarekash 的意思是当技术能力越过临界点AI 自己创造的经济价值会远超它的运营成本届时“大模型公司会被看空”这个命题就不成立了。而看空方认为临界点到来之前公司可能已经烧完钱了。从技术演进的角度看我倾向于认为这场争论的真正价值不是预测未来而是提醒我们所有关于大模型商业价值的讨论都必须同时回答两个问题——模型能力何时达到雇佣标准以及运营成本何时降到可承受范围。只看能力不看成本或者只看成本不看能力都会得出片面的结论。4. 从技术机制看Agent 如何“找到工作”讨论到这里必须落到技术层面。因为“AGI 自己找工作”不是一句口号它依赖一套具体的工程链条。现在离“全自主 AGI”还有距离但构建一个“能完成任务闭环的最小 Agent”已经完全可以实现。4.1 从 ChatBot 到 Agent核心变化是“工具调用”传统 ChatBot 的形式是用户提问 → 模型回答。模型只是一个知识库和信息生成器它不改变现实世界。Agent 的形式是用户给目标 → 模型规划 → 模型调用工具 → 工具返回结果 → 模型继续决策 → 最终输出成果。模型不再只是“说话”而是在“做事”。实现“做事”的关键是大模型的 Function Calling函数调用能力。简单来说模型在收到任务后会先从预设的函数列表里挑选一个合适的函数生成调用参数然后由外部系统执行这个函数再把结果返回给模型继续处理。来看一个最小实现。假设我们要做一个“自动查天气并提醒带伞”的 Agent需要定义一个查天气的工具函数然后让模型在需要时调用它。# 文件路径minimal_agent/weather_tool.py import json import openai # OpenAI 兼容的 API 客户端支持大模型本地部署或第三方兼容服务 client openai.OpenAI( base_urlhttps://your-api-endpoint, api_keyyour-api-key ) tools [ { type: function, function: { name: get_weather, description: 查询指定城市的实时天气和温度, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京 } }, required: [city] } } } ] # 模拟工具执行结果 def execute_tool(name, args): if name get_weather: city args.get(city) # 在真实项目中这里会调用天气 API这里返回模拟数据 return json.dumps({ city: city, weather: 小雨, temperature: 18, advice: 建议携带雨伞 }) return json.dumps({error: unknown tool}) messages [ {role: system, content: 你是一个生活助手会在需要时查询天气。}, {role: user, content: 北京今天需要带伞吗} ] response client.chat.completions.create( modelyour-model-name, messagesmessages, toolstools, tool_choiceauto ) assistant_message response.choices[0].message print(assistant_message)这段代码的核心逻辑是先声明模型可以使用的工具清单tools里面描述了一个get_weather函数的名称、用途和参数结构。用户提出需求后模型会在分析后决定是否调用工具。如果模型决定调用工具返回的assistant_message中会包含tool_calls字段里面有函数名和参数。外部系统拿到这些参数后调用真实的业务函数返回结果。这个例子虽然小但它展示了 Agent 与传统 ChatBot 的本质差异模型可以主动选择工具去获取现实世界的信息而不是只凭训练数据来回答。4.2 让 Agent 形成“感知→规划→行动”循环单次工具调用还不是 Agent。一个完整的最小 Agent 需要一个循环接收任务描述。将任务拆解为子步骤。在每一步调用合适的工具。检查工具返回结果。如果结果满足要求输出最终答案如果不满足继续调整策略。下面是一个简化版的 Agent 循环实现# 文件路径minimal_agent/agent_loop.py import json import openai client openai.OpenAI( base_urlhttps://your-api-endpoint, api_keyyour-api-key ) tools [ { type: function, function: { name: search_docs, description: 在知识库中搜索相关资料, parameters: { type: object, properties: { keyword: {type: string, description: 搜索关键词} }, required: [keyword] } } }, { type: function, function: { name: write_file, description: 将内容写入指定文件, parameters: { type: object, properties: { path: {type: string, description: 文件路径}, content: {type: string, description: 文件内容} }, required: [path, content] } } } ] def execute_tool(name, args): if name search_docs: # 实际项目中这里会检索向量数据库 return json.dumps({result: 找到 3 篇相关文档包含部署说明}) if name write_file: with open(args[path], w, encodingutf-8) as f: f.write(args[content]) return json.dumps({status: written}) return json.dumps({error: unknown tool}) def run_agent(task: str, max_steps: int 5): messages [ {role: system, content: 你是企业知识库机器人你会搜索资料并整理成文档。}, {role: user, content: task} ] for step in range(max_steps): response client.chat.completions.create( modelyour-model-name, messagesmessages, toolstools, tool_choiceauto ) msg response.choices[0].message messages.append(msg) if not msg.tool_calls: # 模型已经不需要再调用工具直接输出最终结果 print(最终回答, msg.content) return for tool_call in msg.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) result execute_tool(fn_name, fn_args) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) print(达到最大步骤数停止。) if __name__ __main__: run_agent(请搜索大模型私有化部署相关资料并整理成 deployment.md)这个循环的意义在于模型不再是一次性生成答案而是会自我检查“我还缺什么信息应该调哪个工具获取获取之后下一步做什么”。这正是“AI 找工作”的最小技术雏形——它已经能独立完成一个包含多个环节的任务而不是单纯回答问题。4.3 当前 Agent 技术的能力边界必须实话实说现在的 Agent 还存在三个显著局限长链路任务不稳定。步骤越多模型犯错的概率越高。一个 10 步以内的任务当前模型可以做得很好一旦任务超过 30 步失败率明显上升。幻觉问题没有根治。Agent 在调用工具之前可能会“编造”它认为正确但其实不存在的信息这会导致整个任务链路建立在错误基础上。自我纠错能力有限。当工具返回的结果不符合预期时模型不一定能正确识别“这结果是错的”有时候会反复重试同一个失败策略白白消耗时间和算力。所以工程上更稳妥的做法是把 Agent 的任务边界限定在“信息获取、文档生成、代码生成、数据整理”这类低风险场景并加入人工审核节点。至于“AI 完全自主处理商务谈判、签署合同”这类高价值高风险任务短期还不适合交给 Agent。5. 从商业逻辑再看这场争论技术机制讲清楚了再回头审视“看空大模型公司”和“AGI 会自己找工作”这两派你会发现它们的真正分歧点其实有三个5.1 分歧一能力拐点何时到来看空方认为现在的模型能力不足以支撑“替代完整岗位”顶多是“增强人的工作效率”。在这个前提下大模型公司的收入只能来自“提高效率”而客户为“效率提升”付费的意愿是有上限的。反驳方认为模型能力的提升还在加速期一旦到达替代完整岗位的临界点整个需求曲线都会变化。到那个阶段问题不是“客户愿不愿意付费”而是“哪里有足够的模型产能来满足需求”。从目前的技术进展看Agent 技术在编程、客服、数据整理等场景已经接近“替代完整岗位”的临界点但在需要复杂决策、创造力、人际协调的场景还有很大距离。所以两派的判断都有道理只是选择了不同的场景来作为论据。5.2 分歧二成本下降速度能否跑赢烧钱速度大模型行业的核心经济问题是推理成本的下降速度能否跑赢用户增长和模型复杂度增长带来的总成本上升。实际工程中这个问题是可以量化的。如果你正在开发 AI 应用建议直接在项目里加一行日志记录每次调用的 Token 消耗和成本# 文件路径cost_tracker.py import time class UsageTracker: def __init__(self): self.total_prompt_tokens 0 self.total_completion_tokens 0 self.total_cost 0.0 def record(self, usage, price_per_million_prompt0.5, price_per_million_completion1.5): prompt_tokens usage.prompt_tokens completion_tokens usage.completion_tokens cost (prompt_tokens / 1_000_000) * price_per_million_prompt \ (completion_tokens / 1_000_000) * price_per_million_completion self.total_prompt_tokens prompt_tokens self.total_completion_tokens completion_tokens self.total_cost cost return cost def summary(self): return { prompt_tokens: self.total_prompt_tokens, completion_tokens: self.total_completion_tokens, total_cost: round(self.total_cost, 4) }我在实际项目中遇到过一种情况客户非常满意一个 AI 客服机器人的效果但上线一周后发现日均调用量达到 50 万次一个月的推理成本比原先人工客服团队的月薪还高。这就是典型的“技术效果好但商业模式不成立”。所以任何 AI 应用在做技术选型之前都建议先估算单位任务成本而不是先关注模型能力上限。5.3 分歧三AGI 时代的“需求”从哪来传统企业软件的逻辑是先有企业需求再有软件产品。AGI 时代的逻辑如果按 Dwarkesh 的说法演变会变成先有能够自驱完成任务的 Agent然后 Agent 自己发现企业需求、自己完成任务、自己产生价值。这个逻辑在劳动力市场上是成立的。企业雇人的本质是购买“完成任务的能力”而不是购买“一个人的时间”。一旦 AI 具备了完成任务的能力并且成本低于雇佣人力企业自然会转向 AI。这不是需求消失了而是完成需求的方式变了。所以“AGI 会自己找工作”更准确的表述是当 AI 具备替代人类执行完整工作的能力时它自然会被市场雇佣因为企业对“完成任务”的需求不会消失只会寻找更低成本的供给方。6. 给开发者的判断框架与行动建议这场辩论对普通开发者最重要的意义不是让你判断谁能赢而是给你一个判断“我该做什么 AI 项目”的框架。6.1 四个问题判断 AI 项目价值在做任何 AI 相关项目之前先回答这四组问题判断维度具体问题如果答案是否定的说明什么能力匹配度当前模型在这个任务上的成功率是否达到可用水平比如 90% 以上说明项目还太早需要等模型能力提升成本承受力单次任务成本是否低于人工成本的 50% 以上说明商业模式可能不成立容错率任务出错后造成的影响是否在可接受范围说明需要引入人工审核环节数据壁垒你是否拥有模型本身没有的私有数据或业务逻辑说明你只是套壳护城河很浅以这个框架来看“大模型公司”的商业争论你就能理解为什么看空方有道理很多大模型公司的应用都停留在“能力匹配度”满足但“成本承受力”不满足的状态用户觉得好用但公司赚不到钱。6.2 工程层面的五条建议结合我一线的观察这里给出五条比较实在的建议不要迷信“大而全”的 Agent。把任务拆成多个小工具单个小工具的成功率可以做到很高然后通过工作流把它们串起来。一个由 5 个高成功率小步骤组成的工作流比一个 5 步全自主大 Agent 的稳定性好得多。先把“人工审核”设计进流程。在 Agent 输出的关键节点设置审批环节。很多企业不敢用 AI 不是能力不够而是没有兜底机制。Token 成本要写入业务指标。每一个 AI 功能上线时除了看准确率还要看单位成本。建议用上文的 UsageTracker 做一个成本看板。私有数据是真正的护城河。模型能力会趋向同质化但你的业务数据和领域知识不会。与其花时间调提示词不如把知识库做好。保持“可回退”能力。任何 AI 系统都要有一个开关让业务可以随时退回人工方案。这个开关在出问题时不只是保命还能让你更敢上线新能力。6.3 对普通开发者来说当前阶段最值得做什么从这场辩论中可以提炼出一个务实判断短期内你不太可能等到一个“完全自主的 AGI”来替你完成所有工作但你现在就可以把那些“重复性高、规则清晰、容错率尚可”的工作交给 Agent 去尝试。我比较推荐的切入方向是编程助手让 Agent 帮你写测试用例、生成代码注释、做代码 review 的预检查。文档生成让 Agent 从会议纪要里自动生成周报、任务计划。知识库问答让 Agent 对接企业内部文档自动回答新员工问题。数据报表让 Agent 定时抓取数据生成日报周报。这些方向的特点是模型能力已经足够支撑成本可控不影响核心业务而且能让你积累 Agent 工程化经验。等到 AGI 真的来了这些经验就是你最值钱的竞争力。7. 总结与后续学习方向回到开头那场争论。前 OpenAI 研究员看空大模型公司Dwarkesh 发文反驳说 AGI 会自己找工作——两个人其实是在不同的时间尺度和不同的商业假设下看同一个主题。看空方用今天的财务报表质疑明天的估值反驳方用明天的技术能力预测后天的市场结构。作为开发者你不需要马上站队但你需要理解双方的论证逻辑因为它直接决定你下一阶段选择什么技术方向、进入什么领域、做什么产品。这篇文章真正想讲清楚的一个点可以浓缩成一句话大模型公司的估值之争本质是“成本曲线”和“能力拐点”赛跑而这场赛跑的中间产物——Agent 技术的工程化能力恰好是当下开发者最值得投入的方向。无论最后谁赢会用 Agent 提升工作流效率的人都不会吃亏。后续如果你想继续深入建议按下面几条线学习模型层了解 Function Calling、多模态理解、推理能力的最新进展。工程层学习 Agent 工作流框架结合你熟悉的后端语言做工具调用集成。成本层学会测量和优化 Token 消耗、模型压缩、缓存策略。产品层找到一个具体的业务场景动手把一个最小 Agent 跑通再逐步增加任务复杂度。至于“AGI 会不会自己找工作”这个问题短期内没有答案。但有一点是确定的谁能让 AI 在工作中创造实际价值谁就拥有了下一阶段的入场券。