构建企业级智能体 AI：Intel 提出五条实战经验

在企业场景中，智能体 AI 的价值远不止一个更强的聊天机器人——它意味着由软件代理端到端执行跨人员、跨业务流程、跨数据与系统的任务。Intel 近日基于数千次智能体 AI 工作负载实验，归纳出五条面向企业 IT 与平台负责人的实战经验，核心观点是：智能体 AI 是一个系统问题，而不是单纯的推理问题。

为什么智能体 AI 是「系统问题」

智能体被定义为「目标驱动的自动化企业工作流」：它会规划多步任务、调用工具、读取结果、在失败时重试。这意味着企业级智能体的运行依赖完整链路——任务编排、数据访问、工具执行、延迟管理、治理与可扩展基础设施——而不仅仅是 LLM 推理。Intel 指出，现有的大多数智能体评测工具过于聚焦 LLM 本身，缺少对整体系统性能的衡量，难以回答平台真正关心的问题：系统是否按预期运行？能稳定支撑多少智能体？应如何扩容？

衡量平台表现的六个关键指标

文章建议企业从单一 LLM 指标转向面向工作流的六项度量：

• 任务成功率（Task success rate）
• 单任务成本（Cost per task）
• 单任务耗时（Time per task）
• 任务吞吐（Task throughput）
• 智能体密度（Agent density，每 vCPU 承载的智能体数）
• 延迟（Latency）

这六项共同回答容量、效率与体验问题，比单纯看 LLM 评测分数更贴近生产实际。

在 Terminal-Bench 之上扩展基准

为更深入地刻画智能体工作负载的性能瓶颈，Intel 在开源智能体评测工具 Terminal-Bench 的基础上扩展了 profiling、遥测与回放能力，并采用「确定性 record-replay」方式记录 LLM 响应、再在多次运行中完全相同地回放，从而将智能体性能与 LLM 自身波动解耦，得到更可比的对比结果。基准任务覆盖编译、测试、数据库操作、布尔逻辑、解释、光线追踪、压缩、线性代数、视频转码与机器学习训练等多类负载，以贴近真实企业环境。

三条核心部署原则

按「智能体密度」而非智能体数量规划容量

容量规划的第一条规则是用「每 vCPU 的智能体数（agent density）」来归一化智能体数量，作为饱和度的领先信号。例如 8 vCPU 上的 10 个智能体，与 16 vCPU 上的 20 个智能体，在密度相同时表现类似。这一指标让架构师可以在不同实例规格、代际处理器间进行可移植对比。交互式 Copilot、面向用户的助手应采用较低密度以保证响应时间；而 IT 类批处理工作流通常可承受更高密度，从而在 SLA 与 TCO 之间取得平衡。

用 P95 任务延迟替代平均 CPU 利用率

智能体的工作模式具有「突发性」：在等待模型响应与短促高强度计算之间反复切换。平均 CPU 利用率往往看起来正常，但实际可能已经出现排队与用户感知变慢。文章建议以 P95 任务延迟作为主要告警指标，再结合持续任务耗时确认问题，这种新型可观测性更适合智能体负载。

默认横向扩展，按需纵向扩展

横向扩展（scale-out）通过增加系统数量来提升总智能体容量，纵向扩展（scale-up）则通过增加单系统核数或内存来适配单智能体的重负载。Intel 的实验数据表明，智能体通常半独立、每次突发负载适中，因此横向扩展往往是更优默认选择：性能更好、可用性更高、成本往往更低，且更易维持目标 agents-per-vCPU 比。纵向扩展则适用于需要更重并行计算、共享状态难以拆分、内存局部性重要或受许可约束的场景。

业务视角：先在哪些流程落地

文章最后从业务角度给出建议：能在生产环境取得成果的组织，往往是把自动化层包裹在那些已有明确规则与可衡量服务等级的流程上——例如代码生成、回归测试集群、工单分诊、市场分析与安全审查。智能体 AI 的理想使用者并非追逐新颖性的试验者，而是需要缩短交付周期、提升生产力、保障服务质量并执行治理策略的「可问责的业务负责人」。

（原文中关于治理与策略部分的论述因摘录截断而未完，整体结论强调：企业应将智能体 AI 视为需要系统化规划与持续运营的工程能力，而非一次性模型集成。）