英伟达首席执行官黄仁勋预计,软件工程师将来会管理数百个AI智能体,由工程师分派任务、评判结果,而不必亲手编写每一行代码。这是一种预测,并非对当下普通工程师工作的描述。现有的智能体工具已经能够跨软件系统执行任务,但要让它们的工作成果可靠,仍然离不开前期准备、精确的指令和人工审核。
从编写代码到指挥工作
在黄仁勋设想的工作流程中,工程师负责确定架构、编写规格说明、把项目拆分为任务并设定质量标准。智能体完成分派的工作,工程师则检查各部分是否符合计划。这一转变的重点不在于取代工程师,而在于改变工程师投入注意力的地方:构想、工具之间的衔接,以及对已完成工作的判断。
黄仁勋用一个假设的年度预算,说明他认为一个组织可能为一名工程师配置多少AI算力。token是AI模型处理文本的单位,而token支出是为这些算力付费的一种方式。
| 黄仁勋举例中的项目 | 年度金额 |
|---|---|
| 工程师年薪 | $50万 |
| 他认为过低的AI token支出 | $5,000 |
| 他建议的AI token支出 | 至少$25万 |
这些数字来自黄仁勋的假设情景,并不是经过验证、每个工程团队都需要的预算。他更宏观的观点是,充裕的智能体算力可能改变人们眼中哪些项目具备可行性。但在实践中,更多的算力本身并不能带来完善的规格说明,也无法提供评估产出的可靠方法。

▲ 任务分派与结果检查
现有智能体能说明什么,又不能说明什么
OpenClaw展示了将AI助手接入日常工作的一种现有方式。它是一款可在macOS、Windows和Linux上运行的开源本地助手,能够跨会话保留记忆,并连接各类即时通讯服务。它还可以操作系统,处理文件、表单、命令和多步骤任务。这些能力表明,智能体可以在聊天窗口之外采取行动;但这并不能证明数百个智能体能够在无人监督的情况下完成复杂的工程项目。
一位创业者曾表示,他借助Claude和智能体,在一次90分钟的操作中替换了一整套企业软件及其相关工作负载。然而,执行时间只是此类项目的一部分。数据准备、应用程序接口(API)配置,以及负责搬运和预处理数据的管道基础设施,可能需要在自动化运行开始之前花费数周乃至数月。开发者可能还需要反复修改指令、等待多轮迭代、调试边界情况,并修订生成的代码,之后才能投入生产环境。
对于考虑引入智能体的团队来说,有用的区分在于:运行自动化任务所花的时间,与让该任务得以实现并检查其结果所花的时间。不应把一次短暂的运行误认为工程投入的全貌。
熟悉的软件成为审核界面
黄仁勋认为,智能体可能会增加而非取代对现有软件的使用。目前许多工具的使用频率受限于人类用户;而成群的智能体可以代替人去查询数据库、在设计应用中工作。软件使用量的这种增长只是一种预测。眼下的工程问题是:如何把智能体接入人们已在使用的工具,并检查它们交回的成果。
例如,负责设计工作的智能体可以使用某款专业应用,而工程师就在同一款应用中审核结果。黄仁勋举出Synopsys、Cadence和Blender等工具,认为智能体的产出可以在这些地方与成熟的专业工作流程相衔接。SQL是一种用于查询数据库的语言,也为智能体处理现有信息提供了另一条途径。
Model Context Protocol(MCP)是一种将AI模型与外部工具连接起来的方式。与Blender、Unreal Engine、Godot和Unity的连接,预示着智能体将在熟悉的工作环境中创建或修改3D资产和场景。关键的交接环节是把生成结果交还给能够对照项目需求进行检查的人。

▲ 在设计环境中审核
围绕工具构建工作流程
模型的选择只是这套体系的一部分。专有模型可以承担通用任务,而开放权重模型——即权重公开、可供他人使用和调整的模型——为专业化工作提供了另一条路径。路由系统可以把不同任务分配给不同模型。长时间运行的后台智能体可以使用GitHub Actions的运行时长或专用硬件等服务器资源,不过这些基础设施同样需要测试和监督。
切实可行的起点是一个定义清晰的任务,而不是智能体数量的目标。先明确架构和成功标准,准备好数据和工具连接,再预留迭代的时间。在工作成果实际使用的应用中审核产出。黄仁勋的愿景指向工程师协调远多于今天的自动化工作;如今的工具已能实现这一愿景的一部分,而把握方向和保证质量的责任仍在工程师身上。