Taxbit 如何在 Amazon Bedrock AgentCore 上构建有据可依、感知角色的 AI 智能体 Taxbit Assist

Taxbit 是一个数字资产税务与会计合规平台。Taxbit 成立于 2018 年，帮助企业（如交易所、支付服务和经纪商）大规模计算收益与损失、收集税务文档并申报信息申报表。如今，一个可引用来源、具备权限感知能力的 AI 助手帮助合规团队直接在产品仪表盘内找到答案。

但要想用好这个仪表盘，所需的知识分散在公开网站、API 文档和帮助中心文章中，而且有相当一部分知识从未被记录下来。当客户问“这个表单状态是什么意思？”时，他们要么自己去翻找，要么提交支持工单。根据 Taxbit 的内部生产分析数据，如今在向 Assist 提问的用户中，超过 55% 会在 24 小时内再次提问。

在本文中，我们分享如何基于 Amazon Bedrock AgentCore（一个可用任意框架或模型大规模构建、连接和优化智能体的平台）构建 Taxbit Assist——这个现已嵌入 Taxbit 仪表盘的 AI 助手。我们将介绍其架构、使答案足够可信从而可交付给受监管客户的检索工作、我们如何处理安全与数据驻留，以及我们如何在实时生产流量上持续衡量答案质量。

助手必须做对的几件事

在这个领域，通用聊天机器人不是一个选项。四项约束塑造了我们的构建方式：

有依据且可引用—— 我们的用户要做出申报决策。每个答案都必须能追溯到用户可以打开并阅读的来源，而当助手不知道某件事时，它必须如实说明。
角色与组织感知—— 助手不应引导支持用户走仅限管理员的工作流程，也不应把他们送到无法打开的页面。
不提供税务建议—— 解释 Taxbit 如何计算成本基础（用于计算收益或损失的会计方法）属于产品文档。告诉用户应选择哪种方法则属于税务建议。两者之间的界限很窄。
区域数据驻留—— 由单一代码库支持，并在生产环境中持续衡量质量。
纳入我们的合规计划—— Taxbit Assist 的开发与运营遵循 ISO/IEC 42001（AI 管理系统的国际标准）。Taxbit 还通过了 ISO/IEC 27001 和 ISO/IEC 27701 认证，并持有 SOC 2 Type II 报告。Taxbit 不训练或微调任何模型，Amazon Bedrock 也不会使用提示词或补全内容来训练模型。

我们也是一支小团队。与其自行构建和运营智能体循环、对话状态存储和会话隔离，我们选择 Amazon Bedrock AgentCore，原因有三：其托管智能体运行时免去了基础设施运维；内置的 AgentCore memory（Amazon Bedrock AgentCore 的一项能力）省去了单独的对话状态存储；按会话隔离使每个用户的上下文保持独立。这让我们能把大部分精力投入到后续的检索和安全工作中。

解决方案概览

Taxbit Assist 是一个运行在 AgentCore runtime（Amazon Bedrock AgentCore 的一项能力）上的 Strands Agents SDK 应用。下图展示了解决方案架构。

图 1：从仪表盘提问开始的请求流程，依次经过护栏筛查、知识库检索、模型推理、权限检查和响应流式传输

工作流包含以下步骤：

用户在 Taxbit 仪表板中提出问题。流式聊天 API 将其连同用户已验证的身份（电子邮件、组织 ID 和仪表板角色）一起转发到 AgentCore 运行时。
运行时使用 Amazon Bedrock Guardrails 对传入消息进行筛查。个人可识别信息（PII）会被就地掩码。如果消息被拦截，则绝不会调用模型。
代理从 Amazon Bedrock Knowledge Bases 知识库中检索候选段落，然后在服务器端对其进行重排序。该知识库使用 Amazon Bedrock 的全托管检索增强生成（RAG）能力，并由 Amazon S3 Vectors（Amazon Simple Storage Service（Amazon S3）的一项能力）提供支持。
Amazon Bedrock 模型对检索到的段落进行推理，并在推荐任何工作流之前验证用户是否有权访问相关功能和角色。有关各 AWS 区域支持的模型，请参阅 Supported models by AWS Region。
答案会连同来源链接一起流式返回仪表板。AgentCore 记忆可跨轮次保留对话。
每个请求都会向 Amazon CloudWatch 发出 OpenTelemetry 追踪，这些追踪会输入我们的评估工具。

代理运行时

该代理是一个小型 Python 应用程序：一个系统提示、一个模型和八个工具。它以 ARM64 容器镜像形式交付，AgentCore 运行时从 Amazon Elastic Container Registry (Amazon ECR) 拉取该镜像并按需扩缩容。

这些工具被刻意设计得很窄：

知识库搜索，这是主要工具。
两项访问检查，一项针对组织权益，一项针对用户的仪表板角色。
四个支持工单工具，用于创建、列出、更新和关闭调用者自己的工单。
当前时间，用于少数需要日内精度的场景。

在此版本中，代理没有对客户税务数据的读取权限。它基于产品知识作答，唯一能执行的写入操作是调用者自己的支持工单。

一项安全决策支撑着上述所有设计：模型从不处理身份。用户的电子邮件、组织 ID 和角色来自受信任的调用服务，并在模型看到之前通过闭包绑定到每个工具中。模型可以决定是否检查权限，但不能决定检查谁的权限，因为身份不是它可以设置的参数。用户输入在边界处经过清理，因此提示注入无法模仿受信任的上下文行。

该代理通过 Amazon Bedrock 运行基础模型（FM），并通过跨区域推理配置文件进行调用。

地理感知推理可处理数据驻留问题。推理配置文件 ID 带有从部署区域派生的地理前缀，因此欧盟部署会将推理保持在欧盟境内，美国部署则保持在美国境内。除了将推理保持在正确的地理范围内，我们还支持自带密钥（BYOK）模型。在 BYOK 账户中，对话历史和其他存储客户数据的存储会使用客户自己的 AWS Key Management Service（AWS KMS）密钥加密。

应用程序推理配置文件可处理成本可见性。每个部署都会将系统推理配置文件包装在带标签的应用程序配置文件中，因此每次模型调用都会携带成本分配标签，并显示在 AWS Cost Explorer 中，按工作负载细分。

Amazon Bedrock 提示缓存降低了延迟和 token 成本。系统提示对每个请求都是字节级完全相同的，并以一个缓存检查点结尾，因此静态前缀可跨用户缓存。每个请求的上下文则改为随用户消息传递。

将答案建立在精选知识库之上

我们的大部分工程投入都花在了知识库上：一个由 Amazon S3 Vectors 支持的 Amazon Bedrock 知识库，使用 Cohere Embed English v3 生成嵌入，产出 1,024 维 float32 向量，并按余弦距离进行比较。这一切都是托管的，因此我们无需运维任何向量数据库。

数据摄取

内容从三类来源流入，每一类都落在单个 Amazon S3 存储桶中各自的前缀下。

下图展示了内容如何到达索引。

图 2：从已发布内容、代码派生内容和精选内容，经由 Lambda 抓取器进入 Amazon S3 和知识库的内容摄取流水线

首先是已发布内容：我们的公共网站、API 文档和帮助中心文章，由定时运行的 AWS Lambda 函数抓取。借助站点地图的 lastmod 时间戳和内容哈希，一次典型运行只会处理自上次运行以来发生变化的内容。范围限定的重要性超出了我们的预期。我们的站点地图大约有 400 多个 URL，但只有大约 70 多个应属于用于生成答案的语料库，而仅 /blogs/ 就占了 300 多个营销页面。如果保留这些内容，这些营销内容就会与帮助中心竞争，成为合规问题的引用来源。将其排除是我们价值最高的检索改动之一，而且完全不需要任何模型方面的工作。

第二个来源不太常规：Lambda 函数读取我们的产品源代码，并生成 Markdown 文档，涵盖仪表盘路由、权限门控、表单资格逻辑和报表配置。这捕获了在其他任何地方都不存在的产品事实，而且由于它是从代码本身重新生成的，因此能保持最新。第三个来源是精选内容：手写文章和经批准的更正，用于填补自动化来源未覆盖的空白。

Amazon EventBridge 以错开的夜间和每周节奏调度抓取任务，每个抓取器仅在内容发生变化时才触发摄取作业。我们将九个抓取器按 S3 子前缀（product-public/、product-internals/、curated/）归入三个总括数据源，从而将相关内容保持在一起。

上下文分块

我们选择了语义分块，它在自然边界处拆分文档，并在我们的检索测试中优于固定大小分块。但从文档中间提取的块会失去对文档主题的把握。在税务申报中，这种上下文往往就是整个答案：一段仅适用于非美国申报制度的段落，如果被返回用于回答关于 IRS Form 1099（一种用于报告付款的信息申报表）的问题，就会产生主动误导。

为解决这个问题，我们使用了知识库的自定义转换钩子来运行 POST_CHUNKING Lambda 函数，该函数会在每个分块前加上其所属文档的 H1 标题和导言段落，这些内容通常会说明该内容的适用范围。前缀被限制在约 128 个 token（标题 80 个字符，范围说明 300 个字符）。由于 Cohere Embed English v3 每个输入最多接受 512 个 token，分块正文被限制在 384 个 token，以便标题和正文能一起容纳在该窗口内。一次生产环境探测发现，约 28% 的分块落在 385–512 区间，其尾部本会被静默截断。

这是我们做过的影响最大的检索改动：分块现在会将自己的适用范围带入向量索引，而不是只存在于文档的第一个分块中。

两点实用说明：第一，Amazon Bedrock 要求转换的中间存储必须是与数据源存储桶分开的独立存储桶。同一存储桶上的不同前缀会被拒绝。第二，在现有数据源上启用自定义转换会强制替换，因此要规划完整重新摄取，而不是原地更改。

检索

在查询时，流水线会先超额获取，然后再裁剪：

question ─► vector search (75 candidates)
─► Cohere Rerank 3.5, server-side in the same Retrieve call
─► top 12 reranked
─► cap of 2 chunks per source document
─► top 5 passed to the model

重排序器作为同一次 Retrieve 调用的一部分在 Amazon Bedrock 内运行，因此没有额外的服务跳转。我们保持 75 个候选的池子足够宽，因为权威文章通常位于向量排名 20–50，只有进入池子后才会被重排到顶部。每文档上限可防止一个分块过多的页面占满所有位置。

引用资格在代码中按来源类型强制执行，而不是通过提示指令。只有三个已发布来源可被引用，因为只有它们的 URL 能解析到客户可以打开的内容。代码衍生和精选内容可为答案提供依据，但不会产生客户无法访问的链接。

安全与数据处理

三道边界防止一个租户的数据进入另一个租户的会话：

知识库不包含任何租户特定内容：只有已发布文档、代码衍生的产品参考和精选文章。
权限和角色检查工具从已对调用方完成身份验证的服务中获取其组织和电子邮件，因此模型无法扩大该范围。
AgentCore 运行时隔离每个会话，对话历史按内存、会话和参与者 ID 分区。该参与者 ID 必须来自调用服务，而不是来自 AWS 调用方身份，因为运行时在单一服务角色下执行。推断出的身份会把每个用户的历史放入同一分区。

Amazon Bedrock Guardrails 可根据您的应用程序要求提供可配置的防护措施，它会在代理运行前筛查每条传入消息。我们将其作为独立的 ApplyGuardrail 调用应用，范围限定为当前用户轮次，从而避免在每一轮都重新扫描整个对话历史。

PII 策略针对税务数据进行了调优。那些本就不应流经语言模型的机密信息，例如密码、卡验证码和云访问密钥，会被直接拦截。格式范围较窄的数字标识符，包括社会安全号码、个人纳税人识别号（ITIN）、银行账号和路由号码，以及国际银行账号（IBAN），会就地匿名化。这让智能体能够协助处理工作流，而始终看不到这些值。外部集成的凭据存放在 AWS Secrets Manager 中，并在运行时获取，绝不会固化到镜像或配置中。

在生产流量上衡量质量

收益最大的习惯是在生产环境中持续衡量质量，同时绝不阻塞响应。下图展示了 trace 数据流如何分发到四个独立的消费者，以及专家的更正如何回流到检索中。

图 3：评估流程，其中 CloudWatch trace 分发到在线评估、质量评判器、税务建议分类器和人工审核，经批准的更正会回流到知识库

AgentCore 在线评估从 CloudWatch trace 中抽取 10% 的实时会话，并用六个内置的 LLM-as-a-judge 评估器打分：有用性、有害性、连贯性、指令遵循、工具选择准确性和工具参数准确性。结果以指标和每会话分数的形式写入 CloudWatch，因此质量回退会显示在仪表盘上，而不是出现在客户投诉中。

我们在其上叠加自己的评判器，通过 CloudWatch 订阅过滤器读取同一 trace 数据流。一个 Lambda 函数对每个抽样答案就其对检索来源的忠实度和所检索文章的相关性进行评分，并将结果作为 CloudWatch 指标发出。我们将忠实度和相关性分开，因为一个答案可能忠实于本就不该被检索到的来源。当这种情况发生时，问题出在检索管道，而不是模型。

一个基础模型分类器检查每个响应是否存在税务建议偏移。产品文档与税务建议之间的界线对主题过滤器来说过于细微：“在自己的钱包之间转账不是应税事件”属于建议，而解释 Taxbit 如何应用 FIFO（先进先出）则属于产品文档。用指令和示例提示的模型可达到接近零的误报率，而主题过滤器约为 25%。两个分类器都不会增加延迟。

由人工闭环。抽样答案在从每个问题和答案中清除个人详细信息后，会发送到内部审核频道，主题专家可以在那里回复更正。经批准的更正会写入知识库的精选前缀，并触发增量摄取作业，因此专家的修复能在几分钟内到达下一位用户的答案，无需部署。

部署与运维

整个技术栈在 AWS Cloud Development Kit (AWS CDK) 中定义，因此搭建新环境，或搭建具有不同驻留要求的新区域，只是一次配置变更。每个拉取请求都会运行离线评估套件：一组黄金场景，依据预期的工具路径和行为进行评判，因此提示和检索变更在发布前就会得到衡量。该套件还会每晚针对生产环境运行。合并后先部署到预发环境，然后在人工审批门禁后部署到生产环境。

结果与影响

Taxbit Assist 自 2026 年 5 月起已在美国和欧盟投入生产使用，欧盟流量由本地推理服务。回答基于精选知识库，并引用其来源，助手在推荐工作流程前会检查功能可用性和用户权限。对于嵌入式支持界面，重复使用率是团队最关注的指标。

一个早期的例子很突出。一家新客户在集成 Taxbit 以收集税务文档（W-8 和 W-9 表格，即 IRS 的预扣税和身份识别表格）时，在构建过程中大量依赖该助手。以前会进入我们团队共享频道或支持工单的集成问题，现在当场就得到了解答。客户无需等待 Taxbit 支持团队即可保持集成推进，而支持团队从未看到这些流量。

模型成本平均每次对话低于 20 美分。提示缓存承担了大部分工作：约四分之三的输入 token 由缓存提供，这使模型成本降低了一半以上。

我们会做哪些不同的事

在调整提示之前先界定语料库范围。在我们把索引缩小到支持和文档内容，并为每个块赋予其文档的范围后，答案的改进超过了任何提示修订带来的效果。
根据你自己的流量衡量护栏过滤器的强度。我们根据自身流量测量了 Amazon Bedrock Guardrails 的 PII 检测器，并将 PIN 和银行路由检测器设置为仅检测模式，这样诸如 1099 之类的数字表格标识符可以通过，而检测器仍能标记真正的敏感值。
保持系统提示字节稳定，以便提示缓存跨用户生效。
从第一个原型开始就在代码中绑定身份。我们早期的测试构建让模型将身份作为参数传递给工具。我们在发布前将其移至调用服务，这样注入的提示就无法扩大其自身的访问权限。

下一步是什么

今天，助手基于产品知识回答问题。下一步是让助手能够通过同样身份绑定、权限检查的工具模式查询客户自己的报告数据，从而回答诸如“我有多少收款人缺少税务文档？”之类的问题。用户提出问题，模型决定使用哪个工具和过滤器，但经过身份验证的调用方决定该工具可以读取谁的数据，因此模型无法更改。

结论

Amazon Bedrock AgentCore 让一个小团队能够向两个地区的受监管企业客户交付一个带引用、权限感知的助手，而无需运营自己的编排、向量搜索、内容安全或评估基础设施。这让我们能够将时间花在真正重要的地方：语料库、检索管道，以及在税务信息报告中什么才算好答案。

要了解更多信息，请参阅 Amazon Bedrock AgentCore、Amazon Bedrock Knowledge Bases、Amazon Bedrock Guardrails 以及 GitHub 上的 Strands Agents SDK。

如果您有问题或想分享您如何解决类似问题，请留下评论。

关于作者

Karan Nayak

Karan 是 AI Pod 团队的一名 Staff 软件工程师。他热衷于构建从 0 到 1 的 AI 产品，推动从初始范围界定和设计到最终实现和发布的端到端生命周期。他是一名终身足球运动员，理想的周末包括长途公路自行车骑行或在山中徒步。

Pranjal Gururani

Pranjal 是 AWS 驻西雅图的高级解决方案架构师。Pranjal 与各类客户合作，设计应对其业务挑战的云解决方案。他是 AWS 人工智能/机器学习技术领域社区（TFC）的成员，与同行协作，在全领域推进机器学习和生成式 AI 最佳实践。

Manuel Martinez

Manuel 是 AWS 驻拉斯维加斯的高级技术客户经理（TAM）。他的背景是设计大规模基础设施系统。他是 AWS 云运营技术领域社区（TFC）的成员，专注于云财务管理（CFM）运营。工作之余，他喜欢指导他人并分享职业发展方面的经验。

Jonathan Kola

Jonathan 是 AWS 的高级生成式 AI 与机器学习专家解决方案架构师，他与各行业客户合作，利用 AWS 设计 AI 和 ML 应用，以满足他们的各种业务需求。