30 秒看懂
Arize 的 Aparna Dhinakaran 描述了 AI 使用者之间不断扩大的差距：一边是偶尔使用 AI 的人，另一边是由少数前沿团队运行的数千个智能体。随着软件工作的重心从编写代码转向调度智能体工厂，AI 工程师的职责也在变化：工程师不再只构建一个功能，而要搭建能构建、评估、发布、监控并改进功能的闭环。 她以 Arize 的 Signal 为例，介绍一种持续运行的智能体：它会读取追踪记录、记住反复出现的问题，并提出修复方案。要让它可靠运行，需要明确触发条件、隔离的运行环境、持久记忆，以及经过人类判断校准的评估。她最后指出，工程师既要追踪自己构建的智能体，也要追踪负责构建它们的编码智能体，让生产环境遥测数据推动持续改进。
- 1前沿群体正在迅速拉开差距Aparna 借用 Andrej Karpathy 的漏斗图来说明这种差距：数十亿人试用过 LLM，真正运行智能体集群的前沿群体却只有少数人。她提出的挑战是，如何帮助更多工程师加入这类实践。
- 2构建闭环，而不只是功能工作内容正从编写功能、查看代码差异，扩展到构建代码审查智能体、评估非确定性任务，以及让智能体检查遥测数据并寻找规律。工程师要设计一套能反复执行这些步骤的系统。
- 3Signal 把追踪记录变成持续任务Arize 的 Signal 会读取追踪记录，寻找反复出现的问题；获得代码仓库访问权限后，还能创建 pull request。它也会记住不同运行中的问题，包括那些随着证据增加而变得更值得关注的问题。
- 4隔离每次运行，只保留有用信息每次运行都会在沙箱中收集追踪记录、外部遥测数据、代码仓库访问权限和所需凭据，并通过代理控制信息进出。发现和追踪记录可以保留；运行结束后则清理沙箱、撤销凭据并移除临时的仓库访问权限。
- 5用人类判断检验评估器Signal 创建的 pull request 也会接受评估。Dhinakaran 建议先建立 gold dataset，将评估器结果与人工结果比较，并在发布前校准评判标准；之后，这些评估既能在线上运行，也能离线运行。
- 6追踪构建智能体的智能体生产环境追踪应覆盖面向用户的智能体，也应覆盖 Claude Code、Cursor 或 Codex 这类编码智能体。结合在线评估后，这些追踪数据就能形成反馈，帮助团队发现缺口并改进系统。
要点建议
- AI 工程师越来越需要围绕功能构建一整套系统：负责构建、评估、发布、监控和改进功能的闭环。
- 适合智能体读取的遥测数据既能为持续运行的智能体提供证据，也能触发它们开始工作。
- 安全的智能体运行需要限定上下文，并在隔离沙箱中提供所需访问权限；运行结束后要撤销凭据并清理工作区。
- 在不同运行之间保留持久发现和追踪记录，同时让执行环境可以替换，也可以在故障后恢复。
- 依据人类判断评估智能体的工作，并在依赖评估分数之前验证评估器本身。
- 除了产品智能体，也要追踪编码智能体，了解智能体工厂在生产环境中的运行情况。
按章节阅读整理后的全文
如今的 AI 工程师做什么？
Aparna 开场讨论 AI 工程师定义的变化，以及普通 AI 使用者与大规模运行智能体的前沿团队之间不断扩大的差距。她提出，怎样让更多人走向这一前沿。
欢迎来到 AI Engineer。既然我们身处纽约，我想重新聊聊 AI 工程师究竟做什么。似乎每年都会有一个新答案，这个定义一直在变化。
准备这场演讲时，Andrej Karpathy 发了一条推文，谈到前沿群体和其他人之间不断扩大的差距：前者运行着数千个持续工作的智能体。他的漏斗从超过 60 亿接触或使用过 LLM 的人开始。其中约 10 亿到 20 亿是偶尔使用免费版本的人；约 2,000 万专业人士用 AI 把几周的工作压缩到几天；而获得前沿技术的人里，可能只有 5,000 人在运行数千个智能体组成的集群。
看到这个漏斗时，人们首先会问：我在漏斗的哪一层？它也勾勒出一条路径，让更多人在未来几年加入运行数千个智能体的群体。
从写代码到调度智能体工厂
随着抽象层从编程语言上移到本地和云端智能体，工作要求也随之扩展。工程师正从构建功能转向协调由智能体组成的系统。
这属于持续了几十年的一场转变：抽象层不断上移，而且过去几年速度更快了。我们从高级编程语言，走到复制粘贴代码，再到本地智能体和云端智能体。现在，人们期待我们在组织内部运行智能体团队或工厂。
这改变了 AI 工程师的工作。工作不再只是编写一个 AI 功能，而是构建能够编写并改进它的闭环。工程师不必再逐一阅读代码差异、亲自完成每次审查，而是配置智能体审查代码，并用评估来判断非确定性任务。工程师也不再只盯着软件指标，而要安排智能体读取可观测性数据、寻找规律。
围绕功能构建闭环
如今的职责包括配置代码审查智能体、为非确定性工作设计评估，以及让系统读取可观测性数据。在 Arize，Signal 展示了如何用智能体执行这一闭环。
我们一直在讨论的闭环包括构建、评估、发布、监控和改进。如今，AI 工程师要负责搭建能执行这些步骤的闭环。在 Arize，我们构建了 Signal 来运行这个闭环：它读取追踪记录和遥测数据，识别规律；如果能访问代码仓库，还可以提出修复方案或创建 pull request。
Signal 读取追踪记录并记住问题
Signal 按设定频率读取一定数量的追踪记录，寻找潜在问题。它的记忆能让它重新审视过去的发现，并根据新增遥测数据判断问题的重要性是否变化。
Signal 是一个持续运行的智能体。最简单的形式是按设定频率读取一定数量的追踪记录，寻找问题。它也需要记忆：以前见过这个问题吗？某个问题过去被认为影响较小，但随着数据不断增加，现在是否显得很严重？Signal 从追踪记录入手，并利用过往信息持续判断问题。
为智能体设计遥测数据
智能体正成为可观测性数据的主要使用者，而这些数据也可以触发智能体。运行可以按计划开始，也可以由用户投诉等事件或某项指标触发。
我们很早就意识到，遥测数据的使用者正在变化。可观测性数据不再只是供人检查，也不只是由人检查、再让智能体跟进。我们需要调整遥测数据的形式，让智能体自己也能读取。这样一来，数据本身还可以触发持续运行的智能体。
如果要构建一座由持续运行的智能体组成的工厂，首先要决定用什么唤醒它们。Signal 可以按计划运行，例如每三或六小时读取最近一段时间的追踪记录并寻找问题。它也可以由事件触发，比如 Slack 上收到用户投诉，或由某项指标触发。这些都是启动一次运行的不同方式。
一次智能体运行包含什么
每次运行都会在沙箱中收集追踪上下文和其他所需数据，再由代理控制信息进出。系统会记录结果和执行追踪，方便团队检查智能体做了什么。
智能体启动后，我们要定义一次运行包含哪些内容。我们会提供追踪上下文和相关的第三方信息，包括应用性能日志和指标，也会提供代码仓库访问权限以及运行所需的密钥。所有这些都会放进为本次运行创建的沙箱。
沙箱只能通过代理收发信息。沙箱内发生的一切都会留下追踪记录。包括智能体发现的问题在内，所有输出都会保存到记忆中。智能体从触发信号和上下文开始，在隔离环境里完成工作，并留下可供我们检查的记录。
运行结束时，有些内容会刻意保留下来。如果智能体发现了问题，我们会保存这些发现，让下一次运行不必从头开始。我们也会保留它调用了什么，以及是否创建了 pull request 等追踪记录。运行期间学到的技能如果有用，也可以保存到代码仓库。
另一些内容则应该清理：沙箱会销毁，短期凭据会撤销，代码仓库的访问权限也会移除。这样，智能体能保留有用发现和证据，同时不会留下临时环境或权限。
让智能体具备持久性并兼容不同模型
发现、追踪记录和有用技能可以在运行结束后保留，临时工作区和凭据则会清理。将状态保存在外部可以恢复失败的运行；更换模型或运行框架也不必重建整个系统。
我们还把 Signal 设计成可以恢复运行。如果沙箱或运行框架在执行中途出故障，智能体不必从头开始。运行状态会保存在沙箱之外，因此我们可以启动新的沙箱和运行框架，从失败的步骤继续。
Signal 支持不同的模型和运行框架。它最初使用 Claude Code，现在也支持 Cursor 和 Codex，之后希望支持其他主流和开源运行框架。我们也想更换模型：评估能帮助我们比较智能体的质量和成本，判断价格更低的方案能否依然严格地发现问题。
编写评估，并检验评判者
评估可以检查 Signal 提出的修改，但标准必须符合人类判断。Dhinakaran 介绍了如何建立 gold dataset，并在依赖评估器进行离线或在线测试前，先用人工判断验证它。
这又回到了 AI 工程师需要做的事：学会编写评估。Signal 每次发现问题并创建 pull request 后，都会评估智能体提出的修改。评估可以从一个数据集和一段提示开始，用来检查输出有没有引入回归。但评估标准必须符合人类判断。
工程师构建运行闭环的系统时，应该投入大量时间和智能体一起查看追踪记录，找出常见错误。此时，明确什么才算好尤其重要。评估可以把标准说清楚，也能让系统有办法判断非确定性的工作。
团队经常会问，怎样才能信任一个评估器。在 Arize，我们会评估评估器：建立 gold dataset，运行评估，把结果与人类判断比较，再不断调整，直到评判结果足够符合人的判断，才发布新的评估器。之后，这些评估既能在线下使用，也能在线上使用。
如今，AI 工程师越来越多的工作就是这些。构建好一个持续运行的智能体后，要先在发布前运行评估。投入生产后，则要追踪所有环节：既包括用户直接使用的智能体，也包括 Claude Code、Cursor 和 Codex 这类帮助构建它们的编码智能体。这样才能看清智能体工厂内部发生了什么。
在生产环境追踪智能体
生产闭环会追踪已部署的智能体和编码智能体，再在线评估它们的追踪数据。这些证据会反馈给能发现问题的智能体，帮助团队找出系统需要改进之处。
这些追踪记录还可以在线评估，也可以离线评估。新的生产追踪数据和评估结果会成为智能体可读取的数据，用来发现问题。系统把数据收集、评估和定位缺口的智能体连在一起，产品就能持续改进。
缩小实验室与企业之间的差距
企业数据比实验室中受约束的问题更混乱，AI 工程师可以帮助弥合这道差距。Dhinakaran 最后回到一个核心观点：系统应持续追踪、评估和改进产品，而不能只停留在单个功能上。
AI 实验室里的成果与许多企业能做到的事情之间仍有很大差距。企业数据往往比实验室里受约束、可测试的问题更混乱。AI 工程师可以通过追踪所构建的智能体、评估它们，并创建能从遥测数据中学习的系统来弥合差距。工作不再只是构建单个功能，而是构建能够改进产品的系统。
这就是我对如今 AI 工程师工作内容的回答：构建能帮助智能体持续改进产品的系统。谢谢大家。
同频道的其他文章
19:43EN → 简体中文
AI Engineer· 2026年10月26日Jack Wotherspoon 谈如何打造一支托管智能体团队Jack Wotherspoon · Google DeepMindGoogle DeepMind 的 Jack Wotherspoon 介绍 Gemini Managed Agents：团队只需一次 API 调用，就能让编程和研究智能体在云端沙箱中运行。他还讲解了持久化环境、可复用技能、由代理注入的凭据、定时触发器，以及多个专用智能体如何协同工作。
20:55EN → 简体中文AI Engineer· 2026年10月26日Jesse Hall：语音智能体要为对话而优化，而非只看排行榜Jesse Hall · LiveKitLiveKit 的 Jesse Hall 解释了为什么语音智能体必须像实时系统一样接受评测：听清用户、允许打断、在工具调用期间继续对话，并在用户真正听到声音之前控制延迟。
18:27EN → 简体中文AI Engineer· 2026年10月26日Daksh Gupta：如何打造更好的 AI 代码审查智能体Daksh Gupta · GreptileGreptile 联合创始人 Daksh Gupta 解释了为什么仅靠 webhook 和编程智能体，无法做好 PR 审查；他还介绍了如何通过定向提示词、事故数据、模型反转、代码库上下文、浏览器测试和按任务路由模型来改进审查质量。
17:56EN → 简体中文AI Engineer· 2026年10月25日Bridgewater 如何让 AI 分析师严守权限边界Nikhil Benesch, Aaron Linsky · turbopufferAaron Linsky 和 Nikhil Benesch 解释了企业知识库搜索如何在遵守文档权限的同时兼顾召回率与速度。他们将向量索引与原生过滤结合，在约 120 毫秒内搜索数亿个向量。
35:19EN → 简体中文AI Engineer· 2026年10月25日SallyAnn DeLucia：如何编写你的第一个 AI 评估SallyAnn DeLucia · Arize AI从智能体的真实追踪记录中提炼具体的通过与失败标准，再构建一个能测试、能与人工判断对齐，并能在生产环境运行的大模型裁判。
20:58EN → 简体中文AI Engineer· 2026年10月25日Vinoo Ganesh 谈如何让金融 AI 为每个数字提供出处Vinoo Ganesh · KeplerKepler 首席执行官 Vinoo Ganesh 解释了为什么金融 AI 应负责检索和引用数据，而数学计算应交给确定性软件。他的设计把可追溯性、检索质量和租户安全都纳入答案本身。