北京
上午8:42，开发者打开笔记本电脑，看到红色构建、失败的测试和等待中的发布分支。她没有自己翻日志、查提交、翻仓库历史，而是给AI编程智能体下了一个简单指令：“修复失败的测试。找到bug、打补丁、跑测试，总结改了什么。” 几秒钟后，智能体返回了测试通过的补丁和简洁的说明。对使用者来说，这像魔法：输入意图，输出结果。但系统内部，这个结果一点也不简单。 这1条指令触发了13个环节：请求解析、任务创建、策略检查、仓库搜索、上下文组装、token化、模型调用、工具校验、沙箱路由、文件编辑、测试运行、遥测采集和最终验证。模型调用是关键，但只是工作负载的一部分。真正的成就是协调整张任务图。 智能体AI要规划、检索、行动、检查、重试和汇报。当AI从孤立的提示-响应交互转向持续工作流时，性能单元也从token转向完成的任务。 多年来，AI基础设施主要用模型执行指标来衡量：prefill、decode、每秒token数、首个token延迟、吞吐量、批处理效率、内存使用和加速器利用率。这些指标仍然重要，但智能体AI拓宽了关键路径。 传统推理请求是有边界的：提示进，响应出。智能体工作流则可能要做规划、检索上下文、管理状态、调用工具和API、在沙箱中运行、验证结果、采集遥测并重试。输出可能是一个答案、一份代码diff、一条数据库查询、一次工具调用，或者决定继续收集更多证据。 总而言之，智能体AI把推理变成了分布式系统问题。GPU仍然是重模型执行的关键，但周围的环节——上下文、工具、沙箱、验证、遥测——越来越决定最终表现。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
