📢 转载信息
原文作者：Kosti Vasilakakis, Ranjit Rajan, Abdullahi Olaoye, Abhishek Sawarkar, Sagar Murthy, and Chris Smith
本文由 NVIDIA 的 Ranjit Rajan、Abdullahi Olaoye 和 Abhishek Sawarkar 联合撰写。
AI 的下一个前沿领域不仅仅是更智能的聊天助手，而是能够在整个系统中进行推理、规划和执行的自主智能体。要实现这一目标，企业开发者需要从原型转向可扩展且安全的生产级 AI 智能体。随着企业问题的日益复杂，这种挑战愈发严峻，这需要架构能够让多个专业智能体协作以完成复杂的任务。
在开发中构建 AI 智能体与大规模部署它们有着根本的不同。开发者在原型与生产之间面临着巨大的鸿沟，在性能优化、资源扩展、安全实施和操作监控等方面举步维艰。典型的方法会让团队在多个不连贯的工具和框架之间手忙脚乱，从而难以在开发到部署过程中保持一致性并获得最佳性能。这时，Strands Agents、Amazon Bedrock AgentCore 和 NVIDIA NeMo Agent Toolkit 的强大组合就大放异彩了。您可以将这些工具协同使用，设计复杂的多智能体系统，进行编排，并在生产环境中安全地扩展它们，同时具备内置的可观测性、智能体评估、性能分析和性能优化功能。本文演示了如何使用这一集成解决方案，从初始开发到生产部署，在 Amazon Web Services (AWS) 上构建、评估、优化和部署 AI 智能体。
企业级智能体基础
开源的 Strands Agents 框架通过其模型驱动的方法简化了 AI 智能体的开发。开发者使用以下三个组件来创建智能体：
- 基础模型 (FMs)：如 Amazon Nova、Anthropic 的 Claude 和 Meta 的 Llama。
- 工具：内置超过 20 个工具，还支持使用 Python 装饰器创建自定义工具。
- 提示词 (Prompts)：用于指导智能体行为。
该框架内置了与 AWS 服务（如 Amazon Bedrock 和 Amazon Simple Storage Service (Amazon S3)）的集成，支持本地测试、持续集成和持续开发 (CI/CD) 工作流程、多种部署选项以及 OpenTelemetry 可观测性。
Amazon Bedrock AgentCore 是一个智能体平台，用于安全、大规模地构建、部署和运行有效的智能体。它拥有可组合的、完全托管的服务：
- 运行时 (Runtime)：用于安全、无服务器的智能体部署。
- 内存 (Memory)：用于短期和长期上下文保留。
- 网关 (Gateway)：通过将 API 和 AWS Lambda 函数转换为智能体兼容的工具，并连接到现有的 Model Context Protocol (MCP) 服务器，实现安全工具访问。
- 身份 (Identity)：用于安全地进行智能体身份和访问管理。
- 代码解释器 (Code Interpreter)：用于沙箱环境中安全的 कोड 执行。
- 浏览器 (Browser)：用于快速、安全的 Web 交互。
- 可观测性 (Observability)：提供全面的操作洞察，用于跟踪、调试和监控智能体性能。
- 评估 (Evaluations)：根据真实行为持续检查智能体质量。
- 策略 (Policy)：确保智能体保持在定义的边界内。
这些服务被设计为可以独立或协同工作，它们抽象了构建、部署和操作复杂智能体的复杂性，同时支持开源框架或模型，提供企业级的安全性和可靠性。
使用 NeMo Agent Toolkit 进行智能体评估、性能分析和优化
NVIDIA NeMo Agent Toolkit 是一个开源框架，旨在帮助开发者构建、分析和优化 AI 智能体，无论其底层框架如何。其框架无关的方法意味着它可以与 Strands Agents、LangChain、LlamaIndex、CrewAI 和自定义企业框架无缝协作。此外，不同框架在 NeMo Agent Toolkit 中连接时可以相互操作。
该工具包的性能分析器 (profiler) 提供了完整的智能体工作流程分析，跟踪单个智能体和工具的 token 使用量、计时、工作流程特定延迟、吞吐量和运行时间，从而实现有针对性的性能改进。它建立在工具包的评估套件之上，包括用于 检索增强生成 (RAG) 的特定评估器（如答案准确性、上下文相关性、响应依据性和智能体轨迹），并支持用于专业用例的自定义评估器，从而实现有针对性的性能优化。自动超参数优化器 通过系统地搜索参数空间来发现最佳设置，例如 temperature、top_p 和 max_tokens，同时最大化准确性、依据性和上下文相关性，同时最小化 token 使用量和延迟，并优化其他自定义指标。这种自动化方法会分析您的完整智能体工作流程，识别瓶颈，并发现手动调整可能会遗漏的最佳参数组合。该工具包的智能 GPU 尺寸计算器 通过模拟智能体延迟和并发场景，并预测生产部署所需的精确 GPU 基础设施，减轻了猜测的负担。
该工具包的可观测性集成与流行的监控服务（包括 Arize Phoenix、Weights & Biases Weave、Langfuse 和支持 OpenTelemetry 的系统，如 Amazon Bedrock AgentCore 可观测性）相连，为持续优化和维护创建了持续的反馈循环。
实际实施
此示例演示了一个基于知识的智能体，它从 Web URL 中检索和综合信息以回答用户查询。该解决方案使用集成了 NeMo Agent Toolkit 的 Strands Agents 构建，并容器化以便快速部署在 Amazon Bedrock AgentCore Runtime 中，并利用 AgentCore 服务的优势，例如 AgentCore 可观测性。此外，开发者还可以灵活地与 Amazon Bedrock 中的完全托管模型、部署在 Amazon SageMaker AI 中的模型、Amazon Elastic Kubernetes Service (Amazon EKS) 中的容器化模型或其他模型 API 端点集成。整体架构旨在实现简化的工作流程，从智能体定义和优化到容器化和可扩展部署。
下图说明了使用 Strands Agents 构建、并集成 NeMo Agent Toolkit 部署在 Amazon Bedrock AgentCore 中的智能体架构。
智能体开发和评估
首先在 Strands Agents 中定义您的智能体和工作流程，然后使用 NeMo Agent Toolkit 封装它，以配置组件，例如用于推理和工具的大型语言模型 (LLM)。有关详细的设置指南，请参阅 GitHub 上的 Strands Agents 和 NeMo Agent Toolkit 集成示例。配置环境后，通过使用示例提示词从命令行运行单个工作流程来验证您的智能体逻辑：
nat run --config_file examples/frameworks/strands_demo/configs/config.yml --input "How do I use the Strands Agents API?"以下是截断的终端输出：
Workflow Result: ['The Strands Agents API is a flexible system for managing prompts, including both system prompts and user messages. System prompts provide high-level instructions to the model about its role, capabilities, and constraints, while user messages are your queries or requests to the agent. The API supports multiple techniques for prompting, including text prompts, multi-modal prompts, and direct tool calls. For guidance on how to write safe and responsible prompts, please refer to the Safety & Security - Prompt Engineering documentation.'] 为了模拟真实场景，而不是执行单个工作流程并退出，您可以使用 serve 命令启动一个能够处理并发请求的长期运行的 API 服务器：
nat serve --config_file examples/frameworks/strands_demo/configs/config.yml
以下是截断的终端输出：
INFO: Application startup complete. INFO: Uvicorn running on http://localhost:8000 (Press CTRL+C to quit) 智能体现在本地运行在 8080 端口。要与智能体交互，请打开一个新的终端并执行以下 cURL 命令。这将生成与先前 nat run 步骤相似的输出，但智能体将作为持久化服务持续运行，而不是执行一次性操作后退出。这模拟了 Amazon Bedrock AgentCore 将智能体作为容器化服务运行的生产环境：
curl -X 'POST' 'http://localhost:8080/invocations' -H 'accept: application/json' -H 'Content-Type: application/json' -d '{"inputs" : "How do I use the Strands Agents API?"}'以下是截断的终端输出：
{"value":"The Strands Agents API provides a flexible system for managing prompts, including both system prompts and user messages. System prompts provide high-level instructions to the model about its role, capabilities, and constraints, while user messages are your queries or requests to the agent. The SDK supports multiple techniques for prompting, including text prompts, multi-modal prompts, and direct tool calls. For guidance on how to write safe and responsible prompts, please refer to the Safety & Security - Prompt Engineering documentation."} 智能体性能分析和工作流程性能监控
智能体运行后，下一步是建立性能基线。为了说明可获得的洞察深度，在此示例中，我们在由 NVIDIA A100 Tensor Core GPU（8xA100 80 GB GPU）驱动的 NVIDIA A100 Tensor Core GPU 驱动的 Amazon Elastic Compute Cloud (Amazon EC2) P4de.24xlarge 实例上使用了自托管的 Llama 3.3 70B Instruct NIM，运行在 Amazon EKS 上。我们使用 nat eval 命令来评估智能体并生成分析：
nat eval --config_file examples/frameworks/strands_demo/configs/eval_config.yml
以下是截断的终端输出：
Evaluating Trajectory: 100%|████████████████████████████████████████████████████████████████████| 10/10 [00:10<00:00, 1.00s/it] 2025-11-24 16:59:18 - INFO - nat.profiler.profile_runner:127 - Wrote combined data to: .tmp/nat/examples/frameworks/strands_demo/eval/all_requests_profiler_traces.json 2025-11-24 16:59:18 - INFO - nat.profiler.profile_runner:146 - Wrote merged standardized DataFrame to .tmp/nat/examples/frameworks/strands_demo/eval/standardized_data_all.csv 2025-11-24 16:59:18 - INFO - nat.profiler.profile_runner:200 - Wrote inference optimization results to: .tmp/nat/examples/frameworks/strands_demo/eval/inference_optimization.json 2025-11-24 16:59:28 - INFO - nat.profiler.profile_runner:224 - Nested stack analysis complete 2025-11-24 16:59:28 - INFO - nat.profiler.profile_runner:235 - Concurrency spike analysis complete 2025-11-24 16:59:28 - INFO - nat.profiler.profile_runner:264 - Wrote workflow profiling report to: .tmp/nat/examples/frameworks/strands_demo/eval/workflow_profiling_report.txt 2025-11-24 16:59:28 - INFO - nat.profiler.profile_runner:271 - Wrote workflow profiling metrics to: .tmp/nat/examples/frameworks/strands_demo/eval/workflow_profiling_metrics.json 2025-11-24 16:59:28 - INFO - nat.eval.evaluate:345 - Workflow output written to .tmp/nat/examples/frameworks/strands_demo/eval/workflow_output.json 2025-11-24 16:59:28 - INFO - nat.eval.evaluate:356 - Evaluation results written to .tmp/nat/examples/frameworks/strands_demo/eval/rag_relevance_output.json 2025-11-24 16:59:28 - INFO - nat.eval.evaluate:356 - Evaluation results written to .tmp/nat/examples/frameworks/strands_demo/eval/rag_groundedness_output.json 2025-11-24 16:59:28 - INFO - nat.eval.evaluate:356 - Evaluation results written to .tmp/nat/examples/frameworks/strands_demo/eval/rag_accuracy_output.json 2025-11-24 16:59:28 - INFO - nat.eval.evaluate:356 - Evaluation results written to .tmp/nat/examples/frameworks/strands_demo/eval/trajectory_accuracy_output.json 2025-11-24 16:59:28 - INFO - nat.eval.utils.output_uploader:62 - No S3 config provided; skipping upload. 该命令生成详细的工件，其中包括每个评估指标（如准确性、依据性、相关性和轨迹准确性）的 JSON 文件，显示 0-1 的分数、推理轨迹、检索到的上下文和聚合平均值。工件中生成的其他信息包括工作流程输出、标准化表格、性能分析跟踪以及延迟和 token 效率的紧凑摘要。这种多指标扫描提供了关于智能体质量和行为的整体视图。评估突出显示，尽管智能体在依据性得分方面表现一致——意味着答案可靠地得到了来源的支持——但检索相关性仍有改进空间。性能分析跟踪输出包含工作流程特定的延迟、吞吐量和运行时间（在 90%、95% 和 99% 置信区间下）。该命令生成一个智能体流程的甘特图和嵌套堆栈分析，以精确地确定瓶颈所在，如以下图表所示。它还报告并发峰值和 token 效率，因此您可以确切了解扩展如何影响提示词和完成用量。
在性能分析期间，nat 生成了八个并发的智能体工作流程（如图中橙色条所示），这是评估期间的默认并发配置。工作流程的 p90 延迟约为 58.9 秒。关键是，数据显示响应生成是主要的瓶颈，最长的 LLM 部分大约需要 61.4 秒。同时，非 LLM 开销保持在最低水平。HTTP 请求平均仅需 0.7–1.2 秒，知识库访问可以忽略不计。利用这种粒度级别的洞察，您现在可以识别并优化智能体工作流程中的特定瓶颈。
智能体性能优化
性能分析后，请调整智能体的参数，以平衡质量、性能和成本。手动调整 LLM 设置（如 temperature 和 top_p）通常是一种猜测游戏。NeMo Agent Toolkit 将此转变为一门数据驱动的科学。您可以使用内置的优化器对参数搜索空间进行系统性的扫描：
nat optimize --config_file examples/frameworks/strands_demo/configs/optimizer_config.yml
以下是截断的终端输出：
Evaluating Trajectory: 100%|██████████████████████████████████████████████████████████████| 10/10 [00:10<00:00, 1.00it/s] 2025-10-31 16:50:41 - INFO - nat.profiler.profile_runner:127 - Wrote combined data to: ./tmp/nat/strands_demo/eval/all_requests_profiler_traces.json 2025-10-31 16:50:41 - INFO - nat.profiler.profile_runner:146 - Wrote merged standardized DataFrame to: ./tmp/nat/strands_demo/eval/standardized_data_all.csv 2025-10-31 16:50:41 - INFO - nat.profiler.profile_runner:208 - Wrote inference optimization results to: ./tmp/nat/strands_demo/eval/inference_optimization.json 2025-10-31 16:50:41 - INFO - nat.eval.evaluate:337 - Workflow output written to ./tmp/nat/strands_demo/eval/workflow_output.json 2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/token_efficiency_output.json 2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/llm_latency_output.json 2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_relevance_output.json 2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_groundedness_output.json 2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_accuracy_output.json 2025-10-31 16:50:41 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/trajectory_accuracy_output.json 2025-10-31 16:50:41 - INFO - nat.eval.utils.output_uploader:61 - No S3 config provided; skipping upload. Evaluating Regex-Ex_Accuracy: 100%|████████████████████████████████████████████████████████| 10/10 [00:21<00:00, 2.15s/it] 2025-10-31 16:50:44 - INFO - nat.profiler.profile_runner:127 - Wrote combined data to: ./tmp/nat/strands_demo/eval/all_requests_profiler_traces.json 2025-10-31 16:50:44 - INFO - nat.profiler.profile_runner:146 - Wrote merged standardized DataFrame to: ./tmp/nat/strands_demo/eval/standardized_data_all.csv 2025-10-31 16:50:45 - INFO - nat.profiler.profile_runner:208 - Wrote inference optimization results to: ./tmp/nat/strands_demo/eval/inference_optimization.json 2025-10-31 16:50:46 - INFO - nat.eval.evaluate:337 - Workflow output written to ./tmp/nat/strands_demo/eval/workflow_output.json 2025-10-31 16:50:47 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/token_efficiency_output.json 2025-10-31 16:50:48 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/llm_latency_output.json 2025-10-31 16:50:49 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_relevance_output.json 2025-10-31 16:50:50 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_groundedness_output.json 2025-10-31 16:50:51 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/trajectory_accuracy_output.json 2025-10-31 16:50:52 - INFO - nat.eval.evaluate:348 - Evaluation results written to ./tmp/nat/strands_demo/eval/rag_accuracy_output.json 2025-10-31 16:50:53 - INFO - nat.eval.utils.output_uploader:61 - No S3 config provided; skipping upload. [I 2025-10-31 16:50:53,361] Trial 19 finished with values: [0.6616666666666667, 1.0, 0.38000000000000007, 0.26800000000000006, 2.1433333333333333, 2578.222222222222] and parameters: {'llm_sim_llm.top_p': 0.8999999999999999, 'llm_sim_llm.temperature': 0.38000000000000006, 'llm_sim_llm.max_tokens': 5632}. 2025-10-31 16:50:53 - INFO - nat.profiler.parameter_optimization.parameter_optimizer:120 - Numeric optimization finished 2025-10-31 16:50:53 - INFO - nat.profiler.parameter_optimization.parameter_optimizer:162 - Generating Pareto front visualizations... 2025-10-31 16:50:53 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:320 - Creating Pareto front visualizations... 2025-10-31 16:50:53 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:330 - Total trials: 20 2025-10-31 16:50:53 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:331 - Pareto optimal trials: 14 2025-10-31 16:50:54 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:345 - Parallel coordinates plot saved to: ./tmp/nat/strands_demo/optimizer/plots/pareto_parallel_coordinates.png 2025-10-31 16:50:56 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:374 - Pairwise matrix plot saved to: ./tmp/nat/strands_demo/optimizer/plots/pareto_pairwise_matrix.png 2025-10-31 16:50:56 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:387 - Visualization complete! 2025-10-31 16:50:56 - INFO - nat.profiler.parameter_optimization.pareto_visualizer:389 - Plots saved to: ./tmp/nat/strands_demo/optimizer/plots 2025-10-31 16:50:56 - INFO - nat.profiler.parameter_optimization.parameter_optimizer:171 - Pareto visualizations saved to: ./tmp/nat/strands_demo/optimizer/plots 2025-10-31 16:50:56 - INFO - nat.profiler.parameter_optimization.optimizer_runtime:88 - All optimization phases complete. 该命令启动了一个跨关键 LLM 参数（如 temperature、top_p 和 max_tokens）的自动化扫描，如配置文件（在此例中为 optimizer_config.yml）中定义。优化器运行 20 个试验，每个试验重复 3 次，使用加权评估指标自动发现最佳模型设置。优化器运行 20 个试验可能需要 15-20 分钟。
该工具包根据加权的多目标分数评估每个参数集，旨在最大化质量（例如，准确性、依据性或工具使用），同时最小化Token 成本和延迟。完成后，它会生成详细的性能工件和汇总表，以便您可以快速识别和选择生产的最佳配置。以下是超参数优化器配置：
llms:
nim_llm:
_type: nim
model_name: meta/llama-3.3-70b-instruct
temperature: 0.5
top_p: 0.9
max_tokens: 4096 # Enable optimization for these parameters
optimizable_params:
- temperature
- top_p
- max_tokens
# Define search spaces
search_space:
temperature:
low: 0.1
high: 0.7
step: 0.2 # Tests: 0.1, 0.3, 0.5, 0.7
top_p:
low: 0.7
high: 1.0
step: 0.1 # Tests: 0.7, 0.8, 0.9, 1.0
max_tokens:
low: 4096
high: 8192
step: 512 # Tests: 4096, 4608, 5120, 5632, 6144, 6656, 7168, 7680, 8192
在此示例中，NeMo Agent Toolkit Optimize 系统地评估了参数配置，并确定了 temperature ≈ 0.7、top_p ≈ 1.0 和 max_tokens ≈ 6k (6144) 是最佳配置，在 20 次试验中产生了最高的准确性。与使用 8192 最大 max_tokens 设置相比，此配置在提高了 35% 准确性的同时，还实现了 20% 的 token 效率提升——最大限度地提高了这些生产部署的性能和成本效益。
优化器生成了配对的 Pareto 曲线，如以下配对矩阵比较图所示。紧随矩阵比较图的是并行坐标图，它显示了在准确性、依据性和相关性方面实现了高质量分数 (0.8-1.0) 的最佳试验（红线），同时在 token 使用量和延迟下降到 0.6-0.8 的归一化尺度时，牺牲了一些效率。配对矩阵证实了质量指标之间存在很强的相关性，并显示所有试验中的实际 token 消耗都紧密集中在 2,500-3,100 个 token 左右。这些结果表明，通过提示词工程，可能还有进一步提高准确性和 token 效率的空间。开发团队可以使用 NeMo Agent Toolkit 的提示词优化功能来实现这一点，从而在最大化性能的同时降低成本。
下图显示了配对矩阵比较：
下图显示了并行坐标图：
调整生产 GPU 基础设施规模
优化智能体并确定运行时或推理配置后，您可以将重点转移到评估模型部署基础设施上。如果您在 EC2 GPU 驱动实例集群上自托管模型部署，那么将智能体投入生产中最困难的方面之一是预测支持目标用例和并发用户所需的精确计算资源，同时不超出预算或导致超时。NeMo Agent Toolkit GPU 尺寸计算器通过利用智能体的实际性能分析来确定满足特定服务等级目标 (SLO) 的最佳集群规模，从而解决了这一挑战，实现了在性能和成本之间权衡的精确调整。要生成尺寸分析配置文件，您需要在各种并发级别（例如，1-32 个并发用户）下运行尺寸计算器：
nat sizing calc --config_file examples/frameworks/strands_demo/configs/sizing_config.yml --calc_output_dir /tmp/strands_demo/sizing_calc_run1/ --concurrencies 1,2,4,8,12,20,24,28,32 --num_passes 2在 Amazon EKS 上运行的 NVIDIA A100 Tensor Core GPU 驱动的 EC2 P4de.24xlarge 实例上对 Llama 3.3 70B Instruct NIM 执行此操作后，产生了以下容量分析：
Per concurrency results: Alerts!: W = Workflow interrupted, L = LLM latency outlier, R = Workflow runtime outlier | Alerts | Concurrency | p95 LLM Latency | p95 WF Runtime | Total Runtime | |--------|--------------|-----------------|----------------|---------------| | | 1 | 11.8317 | 21.3647 | 33.2416 | | | 2 | 19.3583 | 26.2694 | 36.931 | | | 4 | 25.728 | 32.4711 | 61.13 | | | 8 | 38.314 | 57.1838 | 89.8716 | | | 12 | 55.1766 | 72.0581 | 130.691 | | | 20 | 103.68 | 131.003 | 202.791 | | !R | 24 | 135.785 | 189.656 | 221.721 | | !R | 28 | 125.729 | 146.322 | 245.654 | | | 32 | 169.057 | 233.785 | 293.562 | 如以下图表所示，计算出的并发性与延迟和端到端运行时间几乎呈线性关系，P95 LLM 延迟和工作流程运行时表现出近乎完美的趋势拟合 (R² ≈ 0.977/0.983)。每个额外的并发请求都会引入可预测的延迟惩罚，这表明... [内容被截断]
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区