📢 转载信息
原文作者：Maira Ladeira Tanke and Kosti Vasilakakis
构建可投入生产的AI智能体需要贯穿整个开发生命周期的仔细规划和执行。一个在演示中令人印象深刻的原型与一个能在生产中交付价值的智能体之间的区别，是通过严格的工程实践、稳健的架构和持续改进来实现的。
本文探讨了使用Amazon Bedrock AgentCore构建企业AI智能体的九项基本最佳实践。Amazon Bedrock AgentCore是一个代理平台，提供了您大规模创建、部署和管理AI智能体所需的各项服务。在本文中，我们将涵盖从初始范围界定到组织扩展的所有内容，并提供您可以立即应用的实用指导。
从小处着手，明确定义成功标准
您需要回答的第一个问题不是“这个智能体能做什么？”，而是“我们正在解决什么问题？”。太多团队一开始就试图构建一个可以处理所有可能情况的智能体。这会导致复杂性增加、迭代周期变慢，以及智能体在任何事情上都表现平平。
相反，应从一个具体的用例开始向后推导。如果您正在构建一个财务助手，请从分析师最常执行的三项任务开始。如果您正在构建一个HR助手，请关注员工最常问的五个问题。在扩展范围之前，先确保这些核心功能可靠运行。
您的初步规划应产生四个具体成果：
- 明确定义智能体应该做什么和不应该做什么。将此记录下来。与利益相关者分享。用它来拒绝功能蔓延的要求。
- 智能体的语气和个性。决定它是正式还是会话式，它将如何向用户打招呼，以及当它遇到超出其范围的问题时会发生什么。
- 为每个工具、参数和知识源提供明确的定义。模糊的描述会导致智能体做出不正确的选择。
- 一个涵盖常见查询和边缘情况的真实情况数据集。
| 智能体定义 | 智能体语气和个性 | 工具定义 | 真实情况数据集 |
|
财务分析智能体：帮助分析师检索季度收入数据、计算增长指标，并为特定区域（EMEA、APAC、AMER）生成执行摘要。 不应提供投资建议、执行交易或访问员工薪酬数据。 |
|
|
50个查询，包括：
|
|
HR政策助手：回答员工关于休假政策、请假申请、福利登记和公司政策的问题。 不应访问机密人员文件、提供法律建议或讨论个人薪酬或绩效评估。 |
|
checkVacationBalance(employeeId: string) – 按类型返回可用天数。
getPolicy(policyName: string) – 从知识库中检索政策文件。
createHRTicket(employeeId: string, category: string, description: string) – 升级复杂问题。
issues.getUpcomingHolidays(year: number, region: string) – 返回公司假日日历。 |
45个查询，包括：
|
|
IT支持智能体：协助员工进行密码重置、软件访问请求、VPN故障排除和常见技术问题。 不应访问生产系统、直接修改安全权限或处理基础设施变更。 |
|
resetPassword(userId: string, system: string) – 启动密码重置。
workflow.checkVPNStatus(userId: string) – 验证VPN配置和连接性。
requestSoftwareAccess(userId: string, software: string, justification: string) – 创建访问请求工单。
searchKnowledgeBase(query: string) – 检索故障排除文章。 |
40个查询，包括：
|
使用此有限范围构建一个概念验证（POC）。用真实用户进行测试。他们会立即发现您没有预料到的问题。例如，智能体可能在日期解析方面遇到困难。它可能无法很好地处理缩写，或者当问题措辞出乎意料时调用了错误的工具。在POC中发现这些问题可能只花费几周时间，但在生产环境中发现则可能损害您的信誉和用户信任。
从第一天开始就为所有事情设置检测机制
团队在使用可观测性方面可能犯下的最重大错误之一是将其视为以后再添加的功能。等到您意识到需要它时，您已经发布了一个智能体，这使得有效调试变得更加困难。
从您的第一个测试查询开始，您就需要了解智能体正在做什么的可见性。AgentCore服务会自动发出OpenTelemetry 跟踪。模型调用、工具调用和推理步骤都会被捕获。当一个查询花费十二秒时，您可以查看延迟是来自语言模型、数据库查询还是外部 API 调用。
可观测性策略应包括三个层面：
- 在开发过程中启用跟踪级调试，以便您可以看到每次对话的步骤。当用户报告不正确的行为时，调出特定的跟踪并确切查看智能体做了什么。
- 使用与AgentCore 可观测性一起提供的 Amazon CloudWatch 生成式AI可观测性仪表板，为生产监控设置仪表板。
- 跟踪令牌使用情况、延迟百分位数、错误率和工具调用模式。如果您的组织使用 Datadog、Dynatrace、LangSmith 或 Langfuse，则将数据导出到您现有的可观测性系统。下图展示了 AgentCore 可观测性如何在会话调用中帮助您深入了解智能体的跟踪和元数据信息：
可观测性为不同角色提供了不同的需求。开发人员需要它来调试，以回答诸如智能体为何产生幻觉、哪个提示版本性能更好以及延迟来自何处等问题。平台团队需要它来进行治理；他们需要知道每个团队花费了多少，哪些智能体导致了成本增加，以及在任何特定事件中发生了什么。原则很简单：无法衡量就无法改进。在您需要之前，就设置好您的测量基础设施。
制定深思熟虑的工具策略
工具是智能体访问现实世界的方式。它们从数据库中获取数据、调用外部 API、搜索文档和执行业务逻辑。您的工具定义的质量直接影响智能体的性能。
当您定义一个工具时，清晰度比简洁性更重要。考虑对同一功能的以下两种描述：
- 糟糕：
“获取收入数据” - 良好：
“检索指定区域和时间段的季度收入数据。
以百万美元为单位返回数值。需要区域代码（EMEA, APAC, AMER）
和季度格式（例如，2024-Q3）。”
第一个描述迫使智能体猜测哪些输入是有效的以及如何解释输出。第二个描述有助于消除歧义。当您将此扩展到二十个工具时，差异将是巨大的。您的工具策略应解决四个方面：
- 错误处理和弹性。工具会失败。API会返回错误。会发生超时。为每种失败模式定义预期的行为，例如智能体是否应该重试、回退到缓存数据，或者告诉用户服务不可用。与工具定义一起记录下来。
- 通过模型上下文协议 (MCP) 进行重用。许多服务提供商已经为 Slack、Google Drive、Salesforce 和 GitHub 等工具提供了 MCP 服务器。请使用它们，而不是构建自定义集成。对于内部 API，通过 AgentCore Gateway 将它们封装为 MCP 工具。这使您可以在工具之间拥有一个统一的协议，并使它们可以被不同的智能体发现。
- 集中式工具目录。团队不应该五次构建同一个数据库连接器。维护一个经过安全审查和生产测试的批准工具目录。当一个新团队需要某项功能时，他们首先检查目录。
- 每个工具附带代码示例。仅有文档是不够的。向开发人员展示如何使用可复制和改编的工作代码样本来集成每个工具。
下表显示了有效的工具文档应包含哪些内容：
| 元素 | 目的 | 示例 |
| 清晰的名称 | 描述工具的作用 | getQuarterlyRevenue 而不是
getData |
| 明确的参数 | 消除关于输入的歧义 | region: string (EMEA|APAC|AMER), quarter: string (YYYY-QN) |
| 返回格式 | 指定输出结构 | 返回: {revenue: number, currency: “USD”, period: string} |
| 错误条件 | 记录失败模式 | 如果季度未找到，返回404；如果服务不可用，返回503 |
| 使用指南 | 解释何时使用此工具 | 当用户询问收入、销售或财务表现时使用 |
当您管理来自多个来源和类型的工具时，这些文档标准变得更有价值。下图说明了 AgentCore Gateway 如何为来自不同来源的工具提供统一的接口：无论是通过其他 Gateway 实例（用于数据检索和分析功能）、AWS Lambda（用于报告功能）还是 Amazon API Gateway（用于项目管理等内部服务）。虽然此示例为简单起见显示了一个网关，但许多团队会部署多个 Gateway 实例（每个智能体或每组相关智能体一个）以保持清晰的边界和所有权。由于这种模块化方法，团队可以管理自己的工具集，同时仍受益于整个组织中一致的身份验证、发现和集成模式。
AgentCore Gateway 有助于解决工具扩散的实际问题。随着您在组织中构建更多的智能体，您可能会迅速积累数十个工具，有些通过 MCP 服务器暴露，有些通过 Amazon API Gateway，还有些作为 Lambda 函数。如果没有 AgentCore Gateway，每个智能体团队都会重新实现身份验证、管理单独的端点，并将每个工具定义加载到它们的提示中，即使只有少数工具相关。AgentCore Gateway 为您的工具提供了一个统一的入口点，无论它们位于何处。将其指向您现有的 MCP 服务器和 API Gateway，智能体就可以通过一个接口发现它们。当工具数量增加到二十或三十个时，语义搜索功能变得至关重要：智能体可以根据其要完成的任务找到正确的工具，而不是将所有内容加载到上下文中。您还可以获得全面的身份验证处理，双向进行：验证哪些智能体可以访问哪些工具，以及管理第三方服务的凭证。这是使集中式工具目录在规模化时可行的基础设施。
从一开始就自动化评估
您需要知道每次更改后，智能体是在变得更好还是更差。自动化评估为您提供了这个反馈循环。首先，定义对您的特定用例而言，什么意味着“好”。指标将根据行业和任务而异：
- 客户服务智能体可能根据解决率和客户满意度来衡量。
- 财务分析师智能体可能根据计算准确性和引文质量来衡量。
- HR助手可能根据政策准确性和回复完整性来衡量。
在技术指标和业务指标之间取得平衡。响应延迟很重要，但前提是答案正确。令牌成本很重要，但前提是用户认为该智能体很有价值。定义这两种类型的指标并一起跟踪它们。仔细构建您的评估数据集。包含以下数据：
- 同一问题的多种措辞方式，因为用户说话不像 API 文档那样规范。
- 智能体应拒绝回答或升级给人工干预的边缘情况。
- 可能有多种有效解释的模糊查询。
以我们前面提到的财务分析智能体为例。您的评估数据集应包括诸如“我们在EMEA的第三季度收入是多少？”以及预期的答案和正确的工具调用等查询。但它也应包括变化形式：“欧洲上个季度赚了多少钱？”、“2024年第三季度欧洲数据？”和“展示7月到9月欧洲的收入。”每种措辞都应该导致具有相同参数的相同工具调用。您的评估指标可能包括：
- 工具选择准确性：智能体是选择了
getQuarterlyRevenue而不是getMarketData吗？目标：95% - 参数提取准确性：它是否正确地将
EMEA和Q3 2024映射到了正确的格式？目标：98% - 拒绝准确性：它是否拒绝回答
CEO的奖金是多少？目标：100% - 响应质量：智能体是否清晰地解释了数据，没有使用金融术语？通过 LLM-as-Judge 评估
- 延迟：P50低于2秒，P95低于5秒
- 每次查询成本：平均令牌使用量低于5000个令牌
针对您的真实情况数据集运行此评估套件。在您进行第一次更改之前，您的基线可能显示 92% 的工具选择准确率和 3.2 秒的 P50 延迟。在Amazon Bedrock上，将Amazon Claude 4.5 Sonnet切换到Claude 4.5 Haiku后，您可以重新运行评估，发现工具选择准确率下降到87%，但延迟提高到1.8秒。这量化了权衡，并帮助您决定速度提升是否值得牺牲准确性。
评估工作流程应成为您开发过程的一部分。更改了提示？运行评估。添加了新工具？运行评估。切换到不同的模型？运行评估。反馈循环需要足够快，以便您立即发现问题，而不是在后续的几次提交之后。
通过多智能体系统分解复杂性
当单个智能体试图处理太多职责时，维护起来就会变得困难。提示变得复杂。工具选择逻辑会遇到麻烦。性能会下降。解决方案是将问题分解为多个协同工作的专业智能体。这就像组织一个团队。您不会雇佣一个人来处理销售、工程、支持和财务。您会雇佣协调工作的专家。同样的原则也适用于智能体。与其让一个智能体处理三十项不同的任务，不如构建三个智能体，每个智能体处理十个相关任务，如下所示。每个智能体都有更清晰的指令、更简单的工具集和更集中的逻辑。当复杂性被隔离时，问题就变得易于调试和修复。
选择正确的编排模式至关重要。当任务有自然顺序时，顺序模式有效。第一个智能体检索数据，第二个分析数据，第三个生成报告。当需要智能路由时，层次结构模式有效。一个主管智能体确定用户意图并委托给专业智能体。当智能体需要在没有中央协调器的情况下动态协作时，对等模式有效。
多智能体系统的关键挑战是在交接过程中保持上下文。当一个智能体将工作传递给另一个智能体时，第二个智能体需要知道已经发生了什么。如果用户向第一个智能体提供了他们的账户号码，第二个智能体就不应该再问一次。AgentCore Memory 提供了一个共享上下文，多个智能体可以在会话中访问。
仔细监控智能体之间的交接。那是大多数故障发生的地方。哪个智能体处理了请求的哪一部分？延迟在哪里发生？上下文在哪里丢失了？AgentCore 可观测性可以端到端地跟踪整个工作流程，以便您可以诊断这些问题。
一个值得澄清的常见混淆点。协议和模式不是一回事。协议定义了智能体如何通信。它们是基础设施层，是线缆格式、API 合约。Agent2Agent (A2A) 协议、MCP 和 HTTP 都是协议。模式定义了智能体如何组织工作。它们是架构层，是工作流程设计、协调策略。顺序、层次结构和对等都是模式。
您可以在不同的模式中使用相同的协议。在构建顺序管道或层次结构主管时，您可能会使用 A2A。您可以在不同的协议中使用相同的模式。顺序交接可以在 MCP、A2A 或 HTTP 上工作。将这些关注点分开，这样您就不会将基础设施与业务逻辑紧密耦合。
下表描述了多智能体协作协议和模式在层级、示例和关注点上的区别：
| 协议 – 智能体如何交谈 | 模式 – 智能体如何组织 | |
| 层级 | 通信和基础设施 | 架构和组织 |
| 关注点 | 消息格式、API 和标准 | 工作流程、角色和协调 |
| 示例 | A2A、MCP、HTTP 等 | 顺序、层次结构、对等，等等 |
通过个性化安全扩展
从一个为一名开发人员工作的原型过渡到为数千用户服务的生产系统，引入了对隔离、安全和个性化的新要求。
会话隔离是第一位的。用户 A 的对话在任何情况下都不能泄露给用户 B 的会话。当两个用户同时询问不同项目、不同区域或不同账户的问题时，这些会话必须完全独立。AgentCore Runtime 通过在自己的隔离的微虚拟机 (microVM) 中运行每个会话，并提供专用的计算和内存来实现这一点。当会话结束时，microVM 终止。用户之间不存在共享状态。
个性化需要跨会话持久化的内存。用户对信息呈现方式有偏好。他们处理特定的项目，这些项目为他们的问题提供了上下文。他们使用特定于其角色的术语和缩写。AgentCore Memory 为对话历史提供短期内存，为事实、偏好和过去的交互提供长期内存。内存按用户进行命名空间划分，因此每个人的上下文都保持私密。在工具执行之前必须强制执行安全和访问控制。用户只能访问他们有权查看的数据。下图展示了 AgentCore 组件如何协同工作，以帮助在多个层面上强制执行安全措施：
当用户与您的智能体交互时，他们首先通过您的身份提供商 (IdP) 进行身份验证，无论是 Amazon Cognito、Microsoft Entra ID 还是 Okta。AgentCore Identity 接收身份验证令牌，并提取自定义的 OAuth 声明，这些声明定义了用户的权限和属性。这些声明会流经 AgentCore Runtime 到智能体，并在整个会话中可用。
当智能体确定要调用哪些工具时，AgentCore Gateway充当强制执行点。在工具执行之前，Gateway 会拦截请求并根据两个策略层对其进行评估。AgentCore Policy 验证此特定用户是否被授权使用这些特定参数调用此特定工具，检查定义谁可以访问什么的资源策略。同时，AgentCore Gateway 会检查凭证提供商（如 Google Drive、Dropbox 或 Outlook）以检索和注入第三方服务所需的凭证。Gateway 拦截器提供了一个额外的挂钩点，您可以在工具调用继续之前在此处实现自定义授权逻辑、速率限制或审计日志记录。
只有在通过这些检查后，工具才会执行。如果初级分析师试图访问高管薪酬数据，请求会在到达您的数据库之前在 AgentCore Gateway 处被拒绝。如果用户尚未授予对其 Google Drive 的 OAuth 许可，智能体将收到一个清晰的错误，可以传达给用户。用户同意流程是透明处理的；当智能体首次需要访问凭证提供商时，系统会提示进行授权，并为后续请求存储该令牌。
这种纵深防御方法有助于确保安全措施在智能体和工具之间保持一致，无论哪个团队构建了它们或工具托管在哪里。
随着规模的扩大，监控变得更加复杂。面对数千个并发会话，您需要仪表板来显示聚合模式，并且您可以使用它们来检查单个交互。AgentCore 可观测性提供跨用户的实时指标，显示令牌使用情况、延迟分布、错误率和工具调用模式，如下面的图所示。当一个用户出现问题时，您可以确切地追踪该特定会话中发生的情况，如下面的图所示。
AgentCore Runtime 还将工具托管为 MCP 服务器。这有助于保持架构的模块化。智能体通过 AgentCore Gateway 发现和调用工具，而无需紧密耦合。当您更新工具的实现时，智能体会自动使用新版本，而无需代码更改。
将智能体与确定性代码相结合
您做出的最重要架构决策之一是何时依赖代理行为，何时使用传统代码。智能体很强大，但它们不适用于所有任务。将智能体保留给需要对模糊输入进行推理的任务。理解自然语言查询、确定要调用的工具以及在上下文中解释结果都可以受益于基础模型的推理能力。这些是确定性代码需要枚举数千种可能情况才能完成的任务。对于计算、验证和基于规则的逻辑，请使用传统代码。收入增长是一个公式。日期验证遵循模式。B... [内容被截断]
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区