AI工程师的职责变了：从写代码到构建智能体工厂

引言：Karpathy的漏斗与AI工程师的重新定义

在AI Engineer New York大会上，Arize AI联合创始人Aparna Dhinakaran抛出了一个尖锐的问题：AI工程师现在到底做什么？这个问题之所以值得重新审视，是因为Andrej Karpathy在会前周末的一条推文恰好点破了现状——全球60多亿人接触过LLM，但真正在前沿运行数千个始终在线智能体的用户，可能只有5000人左右。

Dhinakaran将这条推文视为一张路线图：未来几年内，如何让更多人从「与LLM对话」进化到「运营智能体团队」？她给出的答案是，AI工程师的角色正在发生根本性转变——从亲手写功能，转向构建让智能体写功能的系统。

始终在线智能体（always-on agents） 指不依赖单次对话触发、而是持续或周期性运行、自主感知环境并采取行动的智能体。与聊天式 LLM 不同，它们通常具备事件或节奏触发、外部记忆、工具与仓库权限、失败恢复等机制，能够长时间在无人值守下完成监控、诊断、修复等任务。Karpathy 所说的「漏斗」正是指：接触 LLM 的人以十亿计，但真正能同时运营数千个此类智能体的用户仅约五千人。这一断层既反映了工程复杂度，也解释了为何 AI 工程师的核心工作正在从写功能转向搭建让智能体可靠运行的循环系统。

从「做事」到「造循环」：AI工程师的四层跃迁

Dhinakaran用一组对比清晰地勾勒了这种转变：

• 过去写AI功能，现在构建写功能的循环
• 过去读diff做代码评审，现在搭建系统和智能体来做评审
• 过去设置指标和遥测，现在让智能体读取可观测性数据并发现模式
• 过去手动优化，现在设计一个能自动优化的闭环

她反复强调的循环是「构建—评估—发布—监控—改进」。传统意义上，AI工程师负责执行其中每一步；而新的定义下，工程师的核心产出是这个循环本身。这一观点与业界对「AI工程师」岗位演化的观察一致：抽象层级不断抬高，从写高级语言到复制粘贴代码，再到调用本地或云端智能体，如今的目标是运行一支智能体团队。

Signal实战：一个始终在线的智能体如何运转

Arize AI在产品中推出的Signal，是这场演讲中最具象的案例。Signal是一个始终在线的智能体，它读取所有trace和遥测数据，识别模式，并在有仓库权限时直接提交修复或PR。

触发与沙箱机制

Signal的启动方式可配置：按固定节奏（如每三到六小时）拉取最近一批trace，也可以由Slack消息、用户投诉或指标异常事件触发。一旦被唤醒，系统会构建一个沙箱，把trace上下文、第三方APM日志与指标、仓库访问权限、所需密钥全部放入其中。沙箱只有一个代理出入口，内部一切操作都被追踪。

沙箱（Sandbox） 是一种隔离的运行环境，用于安全地执行不可信或高风险的代码与操作。在智能体场景中，沙箱把智能体所需的上下文、工具、凭证和网络访问封装在受限边界内，只保留单一代理出入口，从而既能防止智能体误操作或恶意行为影响生产系统，又便于完整记录所有动作形成可审计的 trace。沙箱通常与短生命周期设计结合：任务结束即销毁，凭证与权限随之失效，下次运行重建新实例。这种模式让始终在线的智能体可以反复执行写代码、提 PR 等高权限操作，而不会累积长期的安全暴露面。

记忆与持久性设计

每次运行结束后，沙箱被销毁、凭证和仓库权限被移除，但发现的issue、智能体自身的trace、以及运行中学到的技能会被保存到外部记忆中。下一次启动时，智能体不必从零开始。Dhinakaran特别提到「持久性」（durability）设计：如果沙箱或harness中途失败，智能体能从失败步骤恢复，而不是重跑整个流程。

模型与Harness无关性

Signal最初基于Claude Code构建，现在已支持Cursor和Codex，目标是覆盖所有主流甚至开源的harness，并支持多个模型。这种设计出于两个考量：一是每次启动都能评估智能体质量，二是控制成本——用更强模型可能产出更好的PR，但团队需要验证降级后能否维持issue检测的 rigor。

Harness 指包裹大模型、驱动智能体完成任务的运行时框架，负责工具调用、上下文管理、循环控制、错误恢复等编排逻辑，Claude Code、Cursor、Codex 都属于此类。把模型与 harness 解耦，意味着同一智能体逻辑可以切换底层模型或运行时，而不必重写业务代码。这种无关性带来三个好处：一是可以在不同组合上横向评估智能体质量，二是能按任务难度灵活选用更强或更便宜的模型以控制成本，三是避免被单一供应商锁定，保持基础设施的可替换与可降本空间。代价是需要额外的适配层和统一的观测接口。

评估器本身也需要被评估

Dhinakaran认为，AI工程师应该把更多时间花在写eval上。但一个更棘手的问题随之而来：团队如何信任评估器？她的回答是「评估评估器」——构建黄金标准数据集，用人工输出验证eval结果，确保judge与人类判断一致后才发布新的评估器。这些eval既用于离线测试，也用于生产环境的在线评估。

这引出了她对AI工程师核心能力的新定义：定义「什么是好的」。当智能体承担了越来越多执行工作，人类工程师的价值越来越集中在判断标准的建立与校准上。

LLM-as-a-judge 是用大模型对智能体输出进行打分或判定的评估范式，常用于开放式、难以用规则匹配的任务。它的核心风险是 judge 本身可能存在偏差、漂移或不稳定，因此需要「评估评估器」：先用人工标注构建黄金标准数据集，再测量 judge 与人类判断的一致率（如准确率、Cohen's kappa 等），一致率达标后才允许新评估器上线。离线 eval 用于发布前回归测试，在线 eval 则持续抽样生产流量进行监控。二者结合，才能让评估体系本身成为可信的度量工具，而不是又一个黑箱。

追踪一切：从智能体到「造智能体的智能体」

演讲的收尾部分，Dhinakaran把追踪的范围推到了更底层：不仅要追踪你构建的智能体，还要追踪构建这些智能体的编码智能体——Claude Code、Cursor、Codex的调用链路都应被记录。这些trace进入生产后成为在线评估的数据源，再反馈给智能体去发现新问题。

这就形成了一个完整的数据飞轮：收集数据、评估数据、在数据上运行智能体、发现问题、改进系统。她承认，实验室环境与真实企业之间存在明显差距，企业数据远比实验室里受控可测的数据混乱，而AI工程师正是弥合这道鸿沟的角色。

编辑观点：角色定义背后的组织含义

Dhinakaran的演讲本质上在描述一种「AI工程师即系统架构师」的转向。当智能体工厂成为常态，工程师的绩效将不再以写了多少功能衡量，而是以循环的自动化程度和评估体系的可靠性衡量。这对团队提出了新要求：需要有人专门维护黄金数据集，需要可观测性基础设施支持智能体消费而非仅人类消费，需要接受「评估器也需要被评估」的元工作。

一个值得关注的细节是，Dhinakaran提到Signal的设计原则来自「第一性原理」思考，且刻意保持模型与harness无关。这暗示了一个判断：未来的智能体基础设施应当是可替换、可对比、可降本的，而非绑定单一供应商。对于正在搭建内部智能体体系的企业，这或许是最具操作性的建议。