为代码生成工作流应用 Amazon Bedrock Guardrails 的最佳实践
标题：将 Amazon Bedrock Guardrails 应用于代码生成工作流的最佳实践
本文是 Amazon Bedrock Guardrails 最佳实践系列文章的续篇。上一篇请参阅《像专家一样构建安全的生成式 AI 应用：Amazon Bedrock Guardrails 最佳实践》。AI 驱动的编程助手和代码生成工作流——例如 Claude Code、Kiro 和 OpenAI Codex——正在改变开发者编写软件的方式。这些工具通过流式响应实时生成代码，在长时间的会话中往往能输出数千个字符。随着企业大规模采用这些助手进行生成式 AI 代码工作流，在需要时检测并阻止不安全的代码模式变得至关重要。Amazon Bedrock Guardrails 提供了一系列安全机制，例如用于内容审核的内容过滤器、用于防范越狱、提示注入和提示泄露的提示攻击防御措施，以及用于编辑和屏蔽个人身份信息（PII）的敏感信息过滤器等，帮助检测和过滤不安全、不合规的代码内容。然而，带有智能体循环的编码工作流具有独特的吞吐量特征，包括长时间的流式输出、并发的开发者会话，以及重复的上下文评估。如果配置不当，将这些 Guardrails 应用于具有这些特征的工作流，可能会导致限流错误、成本增加以及延迟不理想等问题。本文会解释如何为使用编程助手的代码生成工作流配置 Amazon Bedrock Guardrails，以克服这些限制。按照这些最佳实践，你可以构建一个高效的蓝图，在确保安全覆盖的同时做好容量规划。为什么代码生成工作流需要安全护栏？Amazon Bedrock Guardrails 提供了全面的安全机制，可以从用户输入和模型响应中检测并过滤有害、不合规的内容，帮助构建安全的生成式 AI 应用。
在代码生成工作流中应用 Amazon Bedrock Guardrails 的最佳实践
虽然这些防护措施可以配置并应用于多种应用场景，但有几类防护专门用于防止有害代码模式，包括：
- 检测提示注入攻击 – 阻止试图诱导模型生成恶意代码或绕过指令的企图。
- 过滤敏感信息 – 帮助屏蔽或脱敏敏感信息，例如个人身份信息（PII）、用户输入和模型响应中的自定义正则表达式；还能在生成代码中硬编码的 AWS 访问密钥、数据库连接字符串或私钥出现之前，将其拦截。
- 内容审核 – 检测并过滤用户提示和模型响应中的有害内容，包括违反组织可接受使用政策的内容。
- 阻止拒绝主题 – 定义自定义主题，作为阻止与禁止活动相关对话的依据，例如生成绕过身份验证机制的代码或协助未授权访问模式。
当 AI 生成的代码进入生产系统时，这些防护措施必不可少。
一个场景：防护措施失效时
某个客户的系统团队刚向 15 名开发者推出了 Amazon Bedrock 上的 Claude Code。他们配置了包含三项防护措施的护栏：提示注入检测（帮助防止注入）、敏感信息过滤器（用于脱敏或屏蔽泄漏的凭证）以及内容过滤器（用于阻止不安全代码模式）。在最初两名开发者参与的试点中，一切运行完美。
试点成功后，15 名开发者同时开始编码会话。几分钟内，团队就开始报告错误：Amazon Bedrock 模型推理返回 ThrottlingException 响应。代码补全中途卡住。开发者们很沮丧，他们的 Slack 频道瞬间炸开了锅。
发生了什么？每个开发者的会话平均每个函数会产生大约 5,000 个字符的代码。在默认流式配置下，Amazon Bedrock 每 50 个字符就会评估一次护栏，即每个函数、每个开发者将触发 100 次 API 调用。乘以 15 个并发会话，系统每秒产生 1,500 次评估请求。
更糟糕的是，由于他们启用了 3 个防护策略，每次评估会消耗 3 个文本单元（而不是 1 个），吞吐量消耗直接翻了三倍。根本原因不在于配额不足，而是架构设计不合理。他们把原本为简短对话交互设计的模式，套用到了一个高吞吐的代码生成流水线上。本文提供了解决这个问题的架构方案。
文本单元：防护栏的计费基础
在深入架构之前，需要先理解防护栏（Guardrails）的消耗是如何计算的——这是后续所有优化的关键。一个文本单元定义为文本中的 1000 个字符。调用 ApplyGuardrail API 时，如果传输了 1000 个字符的文本并经过 3 个防护策略评估，就会产生 3 个文本单元的消耗。关键在于，消耗是乘数累积的——既随内容长度增长，也随启用的防护策略数量增长。对于代码生成工作流（输出通常比较冗长，每个函数可能数千个字符），这种乘法关系是容量规划中的关键因素。
配置了内容过滤器、禁止话题和敏感信息过滤器的防护栏，其计量基于每个防护策略或过滤器所处理的文本单元数量。请注意：内容过滤器无论启用了多少个类别（仇恨、侮辱、色情、暴力、不当行为、提示攻击），每 1000 个字符都只按一个文本单元计费。例如，即使你启用全部六个内容过滤类别，依然只算一个文本单元，而不是六个。乘法关系适用于不同类型策略之间（内容过滤器、禁止话题、敏感信息过滤器），而不是同一策略类型内部的不同类别之间。
挑战：代码生成工作流可能触发限流
传统的对话式 AI 工作流通常涉及简短、离散的用户提示和模型响应。
将 Amazon Bedrock Guardrails 应用于代码生成工作流的最佳实践
代码生成工作流在某些方面与通用对话 AI 截然不同，这些差异直接影响防护（Guardrail）架构的设计。下面的表格说明了为什么代码生成工作流对防护的要求格外苛刻：
| 特性 | 对话式 AI | 代码生成 |
|---|---|---|
| 输出长度 | 100–500 字符 | 5,000–50,000+ 字符 |
| 会话时长 | 单轮或少数几轮 | 多轮扩展对话 |
| 并发用户 | 通常是异步 | 团队同时编码 |
| 上下文复用 | 极少 | 每轮都重新发送系统提示、工具定义和之前的代码 |
| 中间输出 | 极少 | 大量思维链推理 |
这些差异意味着，如果采用内联扫描方式——即防护在生成过程中实时评估每个流式输出块——会产生大量评估请求，但实际带来的安全价值却不成比例。
最佳实践：代码生成工作流的架构模式
针对上述挑战，我们推荐一套架构模式，用以优化代码生成工作流中的防护使用。每种模式聚焦于问题的一个侧面——从降低评估频率到仅选择性扫描高风险内容。你可以根据自身工作负载特性和安全要求，单独或组合应用这些模式。