这段时间技术圈里有个很有意思的交锋一位前 OpenAI 研究员公开表达了对大模型公司的看空态度认为训练成本、竞争格局和商业化落地之间存在巨大鸿沟而 DwarkeshDwarkesh Patel 的播客则发文反驳提出一个更激进的观点——如果 AGI 真的到来它自己会去找工作根本不需要人类帮它设计商业模式。这个话题看起来是“投资观点之争”但骨子里是一个技术路线问题大模型的商业化到底是靠“卖 API 调用次数”还是靠“交付完成的任务”如果你正在做大模型应用开发、Agent 设计或者在企业里评估 AI 投入回报这场争论其实和你密切相关。我的判断是双方都有道理但都只讲了一半。看空者看到了当前大模型公司“高投入、低毛利、模型同质化”的尴尬看多者看到了 Agent 化之后“从卖工具到卖劳动力”的商业模式跃迁。真实的演进路径既不是“大模型公司很快完蛋”也不是“AGI 明天就自己投简历”而是“模型能力正在变成一种可以执行复杂任务的数字生产力”。这篇文章我会拆解两派逻辑并用一个最小求职 Agent 的例子带你看看“AI 自己找工作”在工程上离现实还有多远。1. 这场争论到底是什么两派观点的核心分歧1.1 看空者的核心逻辑大模型公司是“昂贵的矿场”看空大模型公司的理由过去一年里反复出现主要围绕这三点模型层竞争激烈差异化越来越小。从各大厂商发布的模型能力看基础大模型在常规任务上的差距正在缩小。用户从 GPT 换成 Claude或者从 Claude 换成国产开源模型迁移成本并没有想象中那么高。训练和推理成本居高不下。大模型每次迭代都需要超大规模算力而 API 单价却在不断下降。成本下降比收入增速更快导致毛利承压。客户付费意愿集中在“降本增效”上而现实中的很多 POC概念验证无法落地。企业买了大模型 API却发现自己还要做大量 RAG、Agent 编排、权限控制等工作最终价值并不完全属于模型厂商。这套逻辑用一句话概括大模型公司像是一个昂贵的矿场挖出来的“智能矿石”正在迅速贬值而真正赚钱的是下游用矿石盖房子的人。1.2 看多者的核心逻辑AGI 会自己找到经济位置Dwarkesh 的反驳更有意思。他说的“AGI 会自己找工作”不是一句玩笑而是一个经济学推论如果 AI 智能水平足够高它可以自主完成“寻找需求 - 学习技能 - 执行任务 - 获取报酬”这一整套循环那它就不再是“工具”而是“劳动力”。在这个前提下大模型公司的价值下限不是 API 收入而是“拥有未来劳动力”的股权价值。这个观点把争论从“大模型公司能不能赚钱”拉高到了“智能本身值多少钱”。它背后的假设是模型能力继续提升后Agent 可以自己写代码、自己测试、自己部署、自己接受付款甚至自己优化下一版模型。到那时大模型公司的护城河不是参数而是“能够自我改进的 AI 系统”。1.3 为什么技术人应该关心这场争论说实话大多数开发者不会去投资 OpenAI也不需要判断 AGI 哪年到来。但这场争论直接影响你做技术选型的判断方向如果你只把大模型当成“文本生成接口”你会担心被供应商锁定会焦虑模型降价太快。如果你把大模型当成“可调度的智能体”你会更关注 Function Calling、Agent 框架、长期记忆、工具生态这些工程能力。换句话说看空与看多之争本质是“模型层价值 vs 应用层价值”的路线之争。而技术人真正能把握的不是预测 AGI而是理解这套能力如何在具体业务里变成可交付的成果。2. “AGI 会自己找工作”的技术前提是什么“AI 自己找工作”听起来像个科幻段子但它背后其实有一套非常具体的技术栈。当前的大模型距离“自己找工作”还有很大距离但这个方向上的每一步都已经有了雏形。2.1 从“问答”到“执行”工具调用是关键跳跃传统的大模型使用方式是用户输入 Prompt模型输出文本。这种方式下模型只是一个“高级搜索引擎”或“写作助手”。要让模型“找工作”它必须能执行动作。比如搜索职位列表。写一封求职信。把简历投递到指定邮箱。记录哪些岗位已投递、哪些被拒绝。这些动作如果不通过 API 或工具调用模型根本无法完成。OpenAI 的 Function Calling、Anthropic 的 Tool Use以及开源的 ReAct 模式都是在解决同一个问题让模型在生成文本之外能够触发外部系统。2.2 从“单次调用”到“长程任务”Agent 的规划能力“找工作”不是一个单步任务而是多步任务分析自己的技能和意向岗位。搜索多个招聘渠道。筛选匹配职位。定制简历和求职信。投递并行跟进。根据反馈调整策略。每一步之间还有依赖关系和条件分支。这要求 AI 具备两层能力规划能力把大目标拆成子任务。记忆能力记住前面做过什么、结果如何并在后续决策中参考。现在的 Agent 框架比如 LangGraph、AutoGen、自研的状态机编排已经可以做到这种多步编排但可靠性还远未达到可信赖的程度。2.3 模型本身是否会“产生动机”另一层问题是模型会不会“自己”想找工作换句话说是动机从哪里来。当前的 LLM 没有真实需求它的“目标”完全来自用户 Prompt 或系统 Prompt。所谓“AI 自己找工作”在工程上其实是“人类为 AI 设定一个找工作目标AI 自主完成执行过程”。它不会半夜醒来突然想投简历它只会按既定的 reward 函数去优化。这带来一个关键启示就算未来 Agent 能自动投简历第一个为它设置目标的人或公司才是真正掌握价值的人。这也顺带解释了为什么看多者认为“拥有 Agent 的公司”会比“模型本身”更有价值。2.4 小结论“AGI 会自己找工作”不是一个纯粹的技术预言而是一个关于“AI 从工具变成主体”的隐喻。它成立的前提是模型具备稳定的规划能力、可靠的工具执行能力、持久记忆和可控的安全边界。今天这些能力还处在“能演示”到“能生产”之间的过渡带。3. 从“API 调用”到“数字员工”大模型商业模式的潜在大变化3.1 传统大模型商业模式为什么让投资者焦虑现阶段大模型公司最主流的变现方式是 API 按 Token 计费外加部分订阅和定制服务。这种模式的本质是“卖算力卖智能调用次数”。问题在于Token 单价持续下降用户单价被摊薄。大客户基本都会做多模型路由谁便宜用谁。企业级落地需要大量周边工程模型厂商不一定能吃到这部分利润。所以仅靠 API大模型公司的天花板确实有限。看空者正是揪住了这一点。3.2 Agent 化之后商业模式会变如果模型从“回答问题”变成“完成任务”计费方式就会从“按 Token 计费”变成“按任务结果计费”。举个例子传统方式企业集成招聘 API每千 Token 付 0.0X 元HR 自己看结果。Agent 方式企业给 Agent 一个目标“招聘 5 名 Java 工程师”Agent 自己筛简历、发笔试、约面试最后按录用人数付费。后者的付费意愿和客单价远高于前者。这就是“数字员工”的商业模式也是“AI 自己找工作”的镜像——如果 AI 可以自己找工作那它自然也可以被人包月雇佣。这个转变对大模型公司的影响是战略性的。它意味着模型厂商需要从“卖水人”变成“劳动力中介”或“任务执行平台”。真正的护城河不再是参数量而是任务执行成功率、生态覆盖面和信任体系。3.3 这对开发者意味着什么如果你是一名开发大模型应用的工程师这场商业模式争论其实在提醒你不要只做“模型包装”要往“任务交付”方向走。用 Function Calling 连接真实业务系统。用 Agent 编排完成“从需求到结果”的闭环。建立可观测性让每一步任务都能追踪、评审、回滚。即使未来基础模型厂商发生洗牌只要你能把模型能力变成可交付的任务你就始终掌握价值。3.4 小结论大模型公司未来的估值取决于它能否把“API 调用”升级为“任务交付”。而这次升级的技术基础就是 Agent 能力。Dwarkesh 的“AI 会自己找工作”本质上是在为这种新模式画一个极端版本的前景图。4. 环境准备与一个最小「求职 Agent」实验光讨论商业模式太虚我直接用一个最小实验来展示“让 AI 找工作”的工程雏形。这里不是真的投简历而是模拟一个 Agent 如何通过工具调用来完成“搜索职位 生成材料 投递申请”的闭环。4.1 环境准备Python 3.10 及以上。安装openaiSDK或任意兼容 OpenAI API 协议的 SDK比如使用国内大模型厂商的兼容接口。配置环境变量OPENAI_API_KEY。先安装依赖pip install openai python-dotenv然后准备一个简单的配置文件记录 Agent 的基本信息和目标# config.yaml agent: name: tech_writer_agent target_role: 技术内容创作者 target_skills: [大模型, Agent开发, 技术写作] max_steps: 5 job_sources: [internal_db] safety: dry_run: true # 安全开关true 表示只模拟不真实投递 allowed_actions: [search, generate, log]这个配置文件的作用是让整个实验在“模拟模式”下运行避免真的向外部系统发请求。实际项目中dry_run应该永远是生产环境的第一道防线。4.2 定义工具层为了让 Agent “找工作”我们需要给它定义几个可调用的工具。这里我用一个简单的 Python 示例模拟岗位库和投递动作# tools.py import json # 模拟企业内部岗位数据库 JOB_DB [ {id: 1, title: AI应用工程师, skills: [大模型, Python, Agent], city: 上海}, {id: 2, title: 技术内容运营, skills: [大模型, 技术写作], city: 远程}, {id: 3, title: NLP算法工程师, skills: [NLP, PyTorch], city: 北京}, ] def search_jobs(keywords: list[str]) - str: 根据关键词搜索岗位返回岗位列表。 result [] for job in JOB_DB: if any(k.lower() in .join(job[skills]).lower() for k in keywords): result.append(job) return json.dumps(result, ensure_asciiFalse) def generate_application(job_id: int, candidate_skills: list[str]) - str: 模拟生成简历和求职信。 job next((j for j in JOB_DB if j[id] job_id), None) if not job: return json.dumps({error: job not found}) letter { job_id: job_id, applicant_skills: candidate_skills, cover_letter: f尊敬的HR我擅长{, .join(candidate_skills)}希望申请{job[title]}岗位。, status: generated } return json.dumps(letter, ensure_asciiFalse) def submit_application(application: str) - str: 模拟提交申请dry_run 模式下只记录不发送。 return json.dumps({submitted: True, dry_run: True, application: application}, ensure_asciiFalse)这段代码定义了三个工具搜索岗位、生成申请材料、提交申请。实际项目中这三个函数会换成真实 API 调用例如接入招聘平台、HR 系统或内部人才库。4.3 构建 Agent 循环核心的 Agent 循环是一个简单的 ReAct 模式让模型根据当前状态选择工具执行后刷新状态直到任务完成或达到最大步数。# agent_loop.py import json from openai import OpenAI import yaml from tools import search_jobs, generate_application, submit_application client OpenAI() TOOLS [ { type: function, function: { name: search_jobs, description: 根据技能关键词搜索匹配岗位, parameters: { type: object, properties: { keywords: {type: array, items: {type: string}} }, required: [keywords] } } }, { type: function, function: { name: generate_application, description: 为指定岗位生成求职材料, parameters: { type: object, properties: { job_id: {type: integer}, candidate_skills: {type: array, items: {type: string}} }, required: [job_id, candidate_skills] } } }, { type: function, function: { name: submit_application, description: 提交求职申请dry_run 模式下只模拟, parameters: { type: object, properties: { application: {type: string} }, required: [application] } } } ] def run_agent(target_role, max_steps5): messages [ {role: system, content: f你是一个求职 Agent目标是找到「{target_role}」岗位。 f请使用工具完成搜索、生成申请、提交申请。每一步只调用一个工具。}, {role: user, content: 请开始帮我找工作。} ] for step in range(max_steps): response client.chat.completions.create( modelgpt-4o-mini, # 可根据实际使用的模型调整 messagesmessages, toolsTOOLS, tool_choiceauto ) msg response.choices[0].message messages.append(msg) if msg.tool_calls: for tool_call in msg.tool_calls: fn_name tool_call.function.name fn_args json.loads(tool_call.function.arguments) if fn_name search_jobs: result search_jobs(fn_args[keywords]) elif fn_name generate_application: result generate_application(fn_args[job_id], fn_args[candidate_skills]) elif fn_name submit_application: result submit_application(fn_args[application]) else: result json.dumps({error: unknown tool}) print(f[Step {step1}] 调用 {fn_name}, 参数: {fn_args}) print(f[Step {step1}] 返回: {result}\n) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) else: print(Agent 最终回复:, msg.content) break if __name__ __main__: with open(config.yaml, r, encodingutf-8) as f: cfg yaml.safe_load(f) run_agent(cfg[agent][target_role], cfg[agent][max_steps])这段代码的核心逻辑每次循环把当前对话和历史工具结果回传给模型。模型决定是调用工具还是直接回复。工具结果通过tool角色消息返回给模型。dry_run保证了所有投递动作都是模拟的不会真正向外部发送数据。4.4 运行实验在项目目录下执行export OPENAI_API_KEY你的API密钥 python agent_loop.py注意这里使用了 OpenAI Python SDK但如果你使用的是国内大模型厂商的兼容接口只需要改两处base_url和model名称。比如client OpenAI(base_urlhttps://你的兼容接口地址/v1, api_key你的密钥)这样就把实验迁移到了你本地方案或指定模型上。这正好对应了前面说的大模型应用开发中最重要的一点用兼容层避免被单一模型绑定。5. 运行结果与效果验证5.1 预期输出运行后你应该看到类似这样的输出[Step 1] 调用 search_jobs, 参数: {keywords: [大模型, 技术写作]} [Step 1] 返回: [{id: 2, title: 技术内容运营, skills: [大模型, 技术写作], city: 远程}] [Step 2] 调用 generate_application, 参数: {job_id: 2, candidate_skills: [大模型, Agent开发, 技术写作]} [Step 2] 返回: {job_id: 2, cover_letter: 尊敬的HR我擅长大模型, Agent开发, 技术写作希望申请技术内容运营岗位。, status: generated} [Step 3] 调用 submit_application, 参数: {application: {job_id: 2, ...}} [Step 3] 返回: {submitted: true, dry_run: true, application: ...} Agent 最终回复: 我已经为你找到了「技术内容运营」岗位并生成了求职信提交申请。模拟模式下未真实投递。5.2 如何判断实验成功判断标准有三个Agent 是否主动调用了工具而不是靠回答文本“假装”找工作。工具调用顺序是否符合逻辑先搜索后生成再提交。最终回复是否总结了已执行的动作并在dry_run模式下明确说明未真实投递。如果 Agent 一直不调用工具而是直接说“我建议你……”说明你的系统 Prompt 或模型配置有问题下一步先检查tool_choice是否设置为auto以及工具描述是否足够清晰。5.3 如果失败先查哪里如果 API 报model not found确认模型名和接口兼容性。如果工具调用返回格式错误检查json.loads是否失败以及模型是否输出了多余文字。如果 Agent 重复调用同一个工具步数限制可能不够或返回内容没有被正确加入对话。6. 真实工程化的鸿沟为什么“自己找工作”现在还不可靠上面的 demo 能跑通但这只是一个“玩具”。从玩具到真正部署一个求职 Agent中间隔着好几天鸿沟。6.1 工具接入的信任边界真实环境中“搜索岗位”“投递简历”要连外部系统。一旦涉及外部系统就要考虑认证和授权Agent 用什么身份访问不能让它拿到比人类员工更高的权限。操作白名单不是所有动作都应该允许 Agent 自动执行。投递前是否需要人工审批数据隐私简历是敏感数据不能随便发给第三方模型。操作审计每一步动作都要有日志方便追责和回滚。这些是工程问题不是模型能力问题。但它决定了 Agent 能不能从演示变成生产力。6.2 长程规划与记忆的可靠性当前模型在“多步任务”中依然存在以下问题中间某一步出错后面可能继续沿着错误路径走。上下文一长模型会“忘记”最开始的约束条件。很难判断当前结果是否真正完成子目标而不是“看起来完成”。解决思路不是指望模型变得更聪明而是用工程手段兜底设置状态机显式约束任务流转。使用数据库或向量库持久化关键状态。增加人类审核节点关键动作必须由人确认。为 Agent 的每一步设计独立的评估函数而不是只看最终结果。6.3 成本与延迟一个真实的求职 Agent一次完整流程可能需要十几次甚至几十次模型调用。如果每次都调用大模型成本会非常高。而且模型响应速度也影响体验。实践中通常会做两层优化本地部署小模型处理过滤、分类等简单任务。大模型只负责最复杂的决策点。使用缓存降低重复请求。这也解释了为什么“本地部署大模型”和“模型路由”技术越来越受关注。控制成本和延迟是 Agent 落地的前提。6.4 小结论“AI 自己找工作”在技术上可以搭出一个原型但离真正的生产力还差“可信、可控、可审计”这三座大山。Dwarkesh 的辩论价值在于提醒我们未来方向而工程师的日常则是在这三座大山上修路。7. 常见问题与排查方法问题现象可能原因排查方式解决方案Agent 全程不调用工具只输出文字建议系统 Prompt 不明确或模型版本不支持 Function Calling查看使用模型的 Function Calling 文档检查工具描述在 Prompt 中明确“必须使用工具完成”并验证tools参数格式工具调用参数解析失败模型输出 JSON 中包含多余字符打印原始tool_call.function.arguments使用json.loads附带异常处理增加 try-except或使用更宽容的 JSON 解析库Agent 重复调用同一工具陷入死循环工具返回结果没有正确加入 messages或模型未看到执行结果检查role: tool消息是否包含完整结果确保tool_call_id与原始调用匹配投入真实环境后外部系统收到垃圾请求没有做 dry_run或权限过宽检查安全配置和操作日志默认开启 dry_run增加人工审批节点限制允许调用的 API 列表API 调用超时或限流并发过高或模型响应慢查看 API 返回状态码和重试策略增加指数退避重试必要时切换模型或本地部署Agent 产生不符合业务规范的输出工具数据或 Prompt 中的约束不足检查工具返回示例加入 few-shot 示例在工具描述中给出输入输出示例并增加输出校验正则8. 给开发者和企业的实用建议8.1 不要赌 AGI 什么时候来先赌 Agent 能不能完成任务与其争论“AI 是否自己找工作”不如把问题转成在你当前的业务流程里有哪些多步任务可以交给 Agent 完成比如自动整理简历并生成筛选摘要。自动处理工单先分类、查知识库、再生成回复草稿。自动巡检系统日志定位异常并生成初步排查报告。这些场景的共同点是范围清晰、动作有限、可灰度、可回滚。从这些场景起步比直接做一个“全自动求职 Agent”要靠谱得多。8.2 建立 Agent 的可观测性Agent 系统比传统接口更难调试因为它有规划、工具调用、状态变化。强烈建议生产环境做到记录每次 Prompt、每次工具调用、每次模型回复。引入 trace_id 串联一次任务的完整链路。对关键动作如提交申请、发送邮件、修改数据设置人工确认点。我见过太多 Agent 项目上线后出问题不知道是哪个环节导致的。没有可观测性Agent 项目很难真正跑在生产环境。8.3 选型不要绑死单一模型大模型行业变化太快。今天某个模型很强明天可能就被追平。更稳妥的做法是用 OpenAI 兼容协议封装模型调用层。通过配置切换不同模型供应商甚至同时使用多个模型做路由。保持 Prompt 和工具定义尽量模型无关。这样做的好处是当模型价格下降或新模型出现时你可以低成本迁移而不是被厂商锁定。8.4 安全与合规始终是底线Agent 一旦可以调用外部系统风险等级完全不同。做“AI 自动投递”之前先想清楚哪些数据能传给模型哪些操作必须人工审批出现错误如何补救参考工业界的通用做法默认最小权限、默认 dry_run、关键操作双人复核。即使未来 AGI 自己找工作也得遵守人类社会的审批流。9. 总结与后续学习方向这场前 OpenAI 研究员与 Dwarkesh 的争论让我看到的核心问题不是“大模型公司会不会倒闭”而是“AI 的价值交付方式会不会从工具变成劳动力”。看空者提醒我们模型层的竞争和成本压力真实存在看多者提醒我们 Agent 化之后的商业想象力同样真实。两者并不矛盾它们只是处在不同时间尺度。对开发者来说最实用的策略是不要被“AGI 会自己找工作”这种宏大叙事带偏也不要因为“大模型是泡沫”就停止实践。真正值得投入的是 Agent 工程化能力——工具调用、状态管理、可观测性、权限控制、任务评测。这些能力无论未来模型换成哪一家都不会失效。如果你想继续深入可以从这几个方向入手学习 Function Calling 和 Tool Use 的标准写法。研究 ReAct 和 Plan-and-Execute 两种 Agent 模式的差异。使用 LangGraph 或自研状态机实现一个带人工审批的 Agent 流程。给 Agent 增加评估集用可量化的任务完成率来度量效果。最后提醒一句无论模型多聪明生产环境里的 Agent 都要先跑在沙箱里。能自己找工作的 AI 是未来但今天的工程师先要把“让 AI 不闯祸”这件事做好。