这两天 AI 圈有一场争论值得技术人停下来看一眼：一边是前 OpenAI 研究员公开看空大模型公司，认为训练成本、推理成本和开源追赶会让这轮商业模式走到尽头；另一边是 Dwarkesh 的回应——AGI 会自己找工作。这句话听起来像概念炒作，但拆开看，它其实在说：大模型的价值不在于“卖模型”，而在于“能不能直接干活、干完活自动结算”。
这篇文章不站队，只做三件事：把两边的论点拆成可验证的事实，把“AGI 找工作”翻译成工程问题，再给一套从本地部署到 API 接入再到批量任务的落地路径。无论你是做大模型应用开发、模型部署，还是关心 Agent 方向成本控制，都可以顺着这条链路跑一遍，确认哪些说法是真实的，哪些还停留在预期里。
先给结论：这场争论短期内不会影响你看得见摸得着的技术选型。但“AGI 会自己找工作”一旦落地，它对工程架构的要求会非常具体——模型需要有工具调用能力，服务需要稳定暴露 API，任务需要支持批量执行，资源占用需要可观测。这些才是真正值得提前准备的东西。
1. 核心议题速览
| 维度 | 说明 |
|---|---|
| 争议焦点 | 大模型公司是否具有长期商业价值 |
| 看空方观点 | 前 OpenAI 研究员，理由集中在训练/推理成本、API 降价、开源模型追赶 |
| 反驳方观点 | AGI 会自己找工作，价值从“卖模型订阅”转向“按任务结算” |
| 本质技术问题 | 大模型能否从聊天工具演变为可自主拆解、执行、验证任务的 Agent |
| 本文关注的技术链路 | 本地部署 -> API 接入 -> 批量任务 -> 资源监控 |
| 适合读者 | AI 应用开发、模型部署、成本优化、Agent 方向工程师 |
这场争论表面上讨论的是投资逻辑，实际上讨论的是技术路线：大模型公司的护城河到底是“模型参数”，还是“模型与真实工作流之间的连接能力”？从工程角度看，后者更值得押注。因为模型能力会被开源追赶，但一个已经跑通的任务闭环，替换成本远高于替换一个模型权重。
所以这篇文章把重点放在“怎么把模型变成能干活的服务”上。先看争论双方到底在争什么，再落到技术实操。
2. 这场争论到底在争什么
2.1 看空大模型公司的三条核心理由
看空方最核心的判断是：大模型公司的成本结构撑不起当前估值。训练一次前沿模型需要数万张 GPU 和数月时间，推理阶段每次请求也要消耗大量算力。如果用户付费意愿跟不上算力消耗，商业模型就很难闭环。
第二点是 API 价格战。过去两年主流模型 API 的价格下降速度非常快，尤其是在开源模型能力追上来之后，闭源模型不再拥有绝对的定价权。价格下降对开发者是好事，但对靠卖 API 算收入的公司来说，意味着单用户价值在缩水。
第三点是开源模型的追赶。7B、14B 量级的开源模型在通用对话、文本处理、代码生成上已经能做到接近商用模型的体验。很多企业和开发者开始优先尝试本地部署，这直接削弱了“必须订阅闭源模型”的刚性需求。
这三条理由放在一起，结论指向一个方向：如果把大模型公司当成“卖模型的公司”，它的长期利润率确实需要打问号。
2.2 反驳方：AGI 会自己找工作
Dwarkesh 的回应则换了一个坐标系：不要只看“卖模型”的生意，要看 AGI 能不能直接创造劳动力价值。“AGI 会自己找工作”的意思是，未来的 AI 不是一个被动的 API，而是一个能主动接任务、调用工具、完成交付并产生经济回报的 Agent。
这个论点成立的前提是：模型必须从“生成文字”进化到“完成任务”。任务意味着目标、步骤、工具、验证和交付。比如你让它“查一下这周服务器日志里的错误并汇总成报告”，它需要先调用日志查询工具，再分析结果，最后生成报告。这个过程不是一次对话，而是一个包含多个步骤的工作流。
如果这个闭环能稳定跑通，AI 的价值就不受“订阅费”限制，而是可以直接按任务结算。到那时，大模型公司卖的不是模型，而是能够完成任务的劳动力。这是两种完全不同的商业模式，也是反驳方认为看空逻辑不成立的根本原因。
2.3 技术人应该怎么看待这场争论
作为工程师，不需要急着站队，但可以从这场争论里提炼出技术方向：模型能力会持续增强，但真正的应用瓶颈在于如何把模型接入真实系统。
争论双方都没有否认 AGI 长期存在，只是对商业路径判断不同。对开发者来说，这意味着两件事：第一，模型选型要保留可替换性，不要被某一家绑定；第二，要把精力放在任务编排、工具调用、批量执行这些通用工程能力上，这些能力不管哪个模型胜出都能复用。
换句话说，这场争论真正值得关注的问题是：你的系统是否已经具备让模型“干活”的基础设施？如果没有，现在开始搭，比争论 AGI 什么时候到来更有意义。
3. 把“AGI 会自己找工作”拆成工程问题
3.1 模型能力只是起点
“AGI 会自己找工作”听上去是单一模型的能力，但工程上它需要一整套系统支撑。模型本身负责理解自然语言、生成计划、产生输出，真正让“找工作”成立的是任务执行环境：模型能看到什么、能调用什么、能操作什么。
一个常见的误区是：把模型当数据库用，问什么答什么。但在任务场景里，模型需要知道接下来该做什么，需要被允许调用外部工具，需要把大任务拆成小步骤。这些能力不是模型参数变大就自动出现的，而是要靠应用层设计。
所以在工程上，“AGI 找工作”的第一步，是定义清楚模型能访问的工具边界。比如是否允许读取文件、是否允许执行代码、是否允许调用搜索接口。工具边界越清晰，Agent 的稳定性越高。
3.2 工具调用与函数调用
工具调用的技术基础是 Function Calling。主流模型 API 都支持在请求里声明一组工具，模型在回答时会返回一个结构化的调用指令，应用层再根据指令去执行真正的函数。
这个能力对“找工作”至关重要。没有工具调用，模型只能输出建议；有了工具调用，模型才能替你操作真实系统。比如你告诉模型“检查一下磁盘剩余空间”，模型不直接算，而是返回一个调用disk_usage()的指令，你的代码执行这个函数，再把结果回传给模型。
从工程角度，这意味着服务端要维护一份工具清单、统一参数格式、处理调用失败的情况。模型本身只是决策大脑，执行手脚在你的应用层。这也是为什么同一个模型在不同 Agent 框架里表现差异很大——差异不在模型，在工具层的工程实现。
3.3 Agent 闭环的四个环节
一个能“自己找工作”的 Agent，完整工作流通常包含四个环节：
第一是任务理解。把用户模糊的需求解析成明确的目标和约束条件。第二是任务规划。把大目标拆成多个小步骤，决定先后顺序。第三是工具调用。针对每个步骤调用合适的 API、脚本或外部服务。第四是结果验证。检查工具返回结果是否符合预期，失败则重试或调整方案。
这四个环节里，前三步已经有很多开源框架实现了，但第四步“结果验证”往往是工程上最容易被忽略的。没有验证机制，Agent 会在错误结果上继续执行，导致错误被放大。
所以，如果你想往 Agent 方向走，建议优先设计验证环节：每个步骤的结果怎么判断成功、失败重试多少次、重试是否需要换策略。这比堆模型参数更能提升实际效果。
4. AGI 落地前提：本地部署大模型能力
4.1 为什么需要本地部署
“AGI 会自己找工作”如果落地到企业场景，首先遇到的就是数据边界问题。很多数据不能出内网，模型必须本地部署。其次是成本问题，如果每天的调用量大，长期使用云端 API 的费用会显著高于本地推理。
本地部署大模型还有两个隐藏优势：延迟可控和离线可用。内网环境下推理延迟通常比公网 API 更稳定，而且可以规避网络抖动带来的偶发超时。对于批量任务场景，本地部署还能避免并发配额限制。
当然，本地部署不是没有代价。硬件投入、运维成本、模型更新维护都需要人力。以下给出的是通用部署流程，模型文件、GPU 驱动和推理框架请以实际环境为准。
4.2 本地部署通用流程
以当前常见的开源模型部署工具 Ollama 为例，部署流程大致如下：
# 安装 Ollama（具体安装方式以官方文档为准） curl -fsSL https://ollama.com/install.sh | sh # 下载一个 7B 量级的开源模型 ollama pull qwen2.5:7b # 启动服务 ollama serve启动后，默认服务地址是http://127.0.0.1:11434，这个地址同时提供兼容 OpenAI 格式的 API 接口，可以直接被 LangChain、Dify 等工具调用。
如果你已经有其他推理框架，部署思路类似：启动一个本地服务，暴露 HTTP 接口，加载模型权重。关键不在于选哪个框架，而在于确认服务端口、接口格式和模型名称三个参数。
# 验证服务是否启动成功 curl http://127.0.0.1:11434/v1/models如果返回 JSON 列表，说明服务已经正常运行。接下来就可以用 API 方式调用本地模型了。
5. 大模型 API 与模型服务接入实践
5.1 API 服务地址与兼容性
本地部署完成后，模型服务就是一个标准的 HTTP 服务。大多数推理框架会提供/v1/chat/completions接口，与 OpenAI API 格式保持一致。这样做的最大好处是：应用层不需要针对不同模型写不同调用代码，换模型只需要改地址和模型名。
接口调用需要确认三个核心参数：API 地址、模型名称、请求体格式。请求体通常包含model字段，指定使用哪个模型；messages字段，传入对话历史；temperature字段，控制输出随机性。
{ "model": "qwen2.5:7b", "messages": [ { "role": "user", "content": "把下面的任务拆成可执行步骤：检查服务器日志并输出错误汇总" } ], "temperature": 0.2 }5.2 使用 Python 调用 OpenAI 兼容接口
当服务端地址可访问、接口格式确认后，就可以用 Python 发起请求。以下是调用本地模型服务的示例：
import requests url = "http://127.0.0.1:11434/v1/chat/completions" payload = { "model": "qwen2.5:7b", "messages": [ {"role": "user", "content": "把这句话翻译成英文：磁盘空间不足，需要清理日志文件。"} ], "temperature": 0.2 } response = requests.post(url, json=payload, timeout=120) print(response.json()["choices"][0]["message"]["content"])这段代码的作用是验证本地服务能正常响应请求。如果返回结果正常，说明本地推理链路已经打通，后续可以把 URL 和模型名统一抽到配置文件里。
5.3 从单次调用到可用服务
单次调用成功只是第一步。实际工程中要处理超时、重试、并发、日志和监控。建议把 API 地址、模型名、超时时间、重试次数统一放到配置文件中：
model: name: "qwen2.5:7b" api_url: "http://127.0.0.1:11434/v1/chat/completions" timeout: 120 max_retries: 3 temperature: 0.2这样切换模型时只需改配置文件，不需要改业务代码。对于“AGI 找工作”场景，稳定的 API 服务是所有上层应用的基础。
6. 批量任务与 Agent 自动化设计
6.1 批量任务的典型场景
大模型在批量任务场景中能显著提效。典型场景包括：批量文档摘要、批量翻译、批量日志分析、批量代码审查、批量数据清洗。这些任务的特点是输入数量大、单条任务逻辑相对固定、对实时性要求不高。
批量任务和单次调用的区别在于：批量任务必须考虑失败恢复、并发控制和输出管理。如果 1000 条任务跑到第 800 条时失败，不能从头开始，而应该从断点继续。
6.2 批量任务脚本示例
下面是一个通用的批量任务脚本模板，实际使用时需要根据输入来源和输出格式调整：
import time import requests API_URL = "http://127.0.0.1:11434/v1/chat/completions" MODEL_NAME = "qwen2.5:7b" MAX_RETRIES = 3 def run_task(prompt, task_id): payload = { "model": MODEL_NAME, "messages": [{"role": "user", "content": prompt}], "temperature": 0.3 } for attempt in range(MAX_RETRIES): try: resp = requests.post(API_URL, json=payload, timeout=120) resp.raise_for_status() content = resp.json()["choices"][0]["message"]["content"] print(f"[{task_id}] 成功，第 {attempt + 1} 次尝试") return content except Exception as e: print(f"[{task_id}] 失败（第 {attempt + 1} 次）：{e}") time.sleep(2) return None # 从列表读取任务 tasks = [ "总结下面这段文字：...", "把这段代码改成异步实现：...", ] for idx, task in enumerate(tasks): result = run_task(task, idx) time.sleep(1) # 控制请求频率这段脚本有几个关键点：每次请求都带任务 ID 用于日志追踪；失败自动重试且指数退避；每条任务完成后短暂 sleep 避免请求过密。批量任务跑得慢没关系，跑得稳更重要。
6.3 批量任务工程化要点
批量任务要工程化，还需要考虑队列和日志。简单场景可以用 Python 列表遍历，更复杂的大规模场景建议引入消息队列，把任务分发做成分批消费，避免单机内存堆积。
日志设计也非常重要。建议给每条任务写一行结构化日志，包含任务 ID、状态、耗时、失败原因。这样即使跑挂，也能定位到具体是哪一条任务、什么原因失败、是否已经成功写入结果。
另外，批量任务必须支持断点续跑。最简单的做法是：处理前把输入记录读到内存，每条任务处理成功后把索引写入进度文件，下次启动时跳过已完成部分。这个设计在数据量大时能节省大量时间。
7. 资源占用与性能观察
7.1 显存和内存观察
本地部署大模型，最关心的就是资源占用。启动服务后，可以用nvidia-smi实时查看显存使用情况：
nvidia-smi -l 2这条命令每 2 秒刷新一次，可以观察到模型加载后的显存占用、GPU 利用率和温度。如果服务启动后显存不足，进程会被系统杀掉或回退到 CPU 推理，推理速度会明显下降。
以 7B 量级的量化模型为例，常见部署场景下显存占用通常在 6G 到 10G 之间，但这不是固定值，需要以实际模型版本、量化位数和上下文长度为准。显存占用需以本机实测为准，不要只看模型参数大小。
7.2 影响推理性能的因素
推理性能受四个因素影响最大：模型大小、量化方式、上下文长度和并发数。模型越大，单次推理越慢；量化位数越低，显存占用越少，但输出质量可能有轻微下降；上下文越长，每次请求需要处理的 token 越多，延迟越高。
并发数需要谨慎控制。本地 GPU 的算力是固定的，并发太高会导致请求排队，单条延迟反而增加。建议先用单并发测试基准延迟，再逐步增加并发，找到延迟和吞吐量的平衡点。
CPU 推理和 GPU 推理的差异也要清楚。CPU 推理在小模型上勉强可用，但延迟明显偏高；GPU 推理适合对延迟敏感的应用。如果只是离线批量任务，CPU 也可以接受，但整体吞吐量要提前压测。
7.3 如何控制成本
成本优化可以从三个方向入手：第一个是选择合适大小的模型，不要大材小用；第二个是控制上下文长度，只传必要信息；第三个是减少无效重试，优化提示词避免模型频繁答偏。
另外，批量任务可以利用本地 GPU 空闲时段集中执行。比如下班后启动批量脚本，第二天查看结果，这样可以错开办公时段的资源竞争。“AGI 找工作”也一样，任务执行时间越灵活，资源利用率越高，摊薄下来的成本越低。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 启动后页面或接口无法访问 | 端口被占用或服务未启动 | 检查日志和curl http://127.0.0.1:11434/v1/models | 更换端口或重启服务 |
| 模型文件缺失或加载失败 | 模型下载不完整或路径错误 | 查看启动日志，确认模型名称和路径 | 重新 pull 模型，检查磁盘空间 |
| GPU 显存不足导致进程退出 | 模型过大或上下文太长 | nvidia-smi观察显存占用 | 换小模型、降低量化位数、缩短上下文 |
| CUDA 或驱动不匹配 | 推理框架与驱动版本不兼容 | nvidia-smi和框架版本检查 | 升级驱动或更换推理框架版本 |
| 请求超时 | 单次推理时间过长或并发过高 | 查看服务日志和平均延迟 | 调大超时时间，降低并发数 |
| API 调用返回错误 | 请求参数或接口地址不正确 | 对比官方接口文档和返回信息 | 修正模型名、消息格式或地址 |
| 批量任务中途失败 | 单条任务触发异常 | 检查任务 ID 对应的日志 | 增加重试机制，做断点续跑 |
| 输出质量不稳定 | 提示词不清晰或温度参数过高 | 先小样本人工检查输出 | 优化提示词，降低 temperature |
排查问题的基础是先看日志。本地推理服务的日志通常会输出模型加载时间、请求处理时长和错误信息。遇到问题不要反复猜测，先截取日志，再对照表格逐步排查。
9. 最佳实践与合规边界
9.1 工程化建议
第一次跑通链路时，先用小模型、小批量、短上下文测试，避免因为参数过大导致环境问题掩盖了逻辑问题。建议保留一套最小可运行配置，包括固定的模型版本、固定的 API 地址和一份可复现的启动脚本。
任务目录规划也很重要。建议把模型文件、输入素材、输出结果、日志分别放在独立目录，不要混在一起。批量任务要加日志和失败重试，接口服务要限制访问范围，不要把本地推理服务直接暴露到公网。
9.2 合规与授权
本地部署模型时，要注意模型本身的开源许可证和商用限制。不同模型对商用场景有不同约束，使用前应确认授权范围。
如果输入数据包含个人隐私、商业敏感信息或版权素材，必须确认处理方式符合相关法规和企业内部数据安全要求。“AGI 会自己找工作”在真实业务中会接触到大量数据，数据过滤、脱敏和审计缺一不可。
9.3 安全边界
模型服务暴露在网络上时，需要设置访问控制，避免被未授权调用消耗算力。API Key 要妥善保管，不要硬编码在代码仓库里。批量任务涉及人脸、声音、版权素材时必须确认授权，发布或商用前要做效果复核。
要明确一点：模型输出可能存在事实错误，不能不加验证直接用于生产。“AGI 找工作”的能力越强，越需要安全护栏——这不是限制它，而是保证它在可控范围内创造价值。
10. 总结与下一步
这场“前 OpenAI 研究员看空大模型公司”和“AGI 会自己找工作”的争论，短期很难有定论。但从技术角度看，值得立刻动手的确定性方向有三个：本地部署能力、API 接入能力、批量任务工程化能力。
建议先默认选一个 7B 量级的开源模型，在本地跑通对话接口，再用批量脚本处理一批真实业务数据，最后观察显存占用和单条耗时。这一步做完，你对“AGI 能不能自己找工作”的判断，会比任何争论都更有依据。
最容易踩的坑是跳过小规模实验，直接上大模型和长上下文，导致显存不足、接口超时，最后把问题归咎于模型能力。正确的顺序永远是：小模型跑通 -> 换大模型 -> 加批量 -> 加监控。这套路径可以一直复用，不管未来是候选模型还是 Agent 框架更新，底层能力不会白搭。
如果你正在构建基于大模型的应用，建议把这篇文章里的 API 地址、批量脚本、资源监控命令存成一份自己的部署清单。AGI 什么时候来不好说，但工程能力早一天就绪，后面切换任何模型都会更快。
