AI热榜 上午 8:42，一名开发者打开笔记本电脑，映入眼帘的是环境构建失败、测试报错，还有一条等待发布的代码分支。
过去，她可能需要花费大量时间逐一排查日志、比对代码提交记录、追溯仓库历史；而如今，她只需向 AI 编码智能体下达一句简单指令： “修复失败的测试。
找出 bug、提交补丁、重跑测试并汇总改动内容。
” 敲几下键盘，喝上一口茶的时间，智能体就返回了已通过测试的补丁，并附上简洁的说明。
对用户而言，效果如同瞬时魔法：输入需求，输出结果。
但在系统内部，实现这一结果的过程一点也不简单。
仅一条提示词就可以触发请求解析、任务创建、策略检查、代码库检索、上下文拼接、Token（词元）编码、模型调用、工具验证、沙箱路由、文件编辑、测试运行、遥测采集与最终结果核验。
模型调用固然关键，但它只是工作负载的一环，真正体现工程能力的是对任务图的协调与编排。
智能体 AI 会进行规划、检索、执行、校验、重试和反馈。
随着 AI 从孤立的提示-响应交互模式转向持续工作流模式，性能的衡量维度也从 Token 转向完整的任务交付。
模型调用已不再等同于全部工作负载 长期以来，AI 基础设施主要以模型执行为衡量标准：预填充(prefill)、解码(decode)、每秒生成 Token 数、首 Token 延迟、吞吐量、批处理效率、内存占用以及加速器利用率。
这些指标依然重要，但随着智能体 AI 的兴起，系统的关键路径已不再局限于模型执行本身。
传统的推理请求有明确的边界：从提示词到结果输出。
而智能体工作流可能涉及任务规划、上下文检索、状态管理、工具与 API 调用、沙箱运行、结果验证、遥测采集以及重试。
最终输出可能是一个答案、一段代码变更、一条数据库查询、一次工具调用，或是一个搜集更多信息的决策。
简而言之，智能体 AI 让推理演变为一个分布式系统问题。
GPU 对于高强度模型执行仍然不可或缺，但围绕 GPU 展开的工作正日益成为系统性能的决定性因素：哪些任务在运行、在哪里运行、伴随哪些上下文、允许使用哪些工具，结果是否满足用户需求。
这个周边的技术栈为模型增加了多个层级，其中大量协调工作都由 CPU 承担，包括编排、内存与检索、工具调用、运行时与沙箱、策略系统以及可观测性等。
模型则提供智能、推理和生成能力，而外围系统能将这些能力转化为可执行的行动。
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接