人工智能

Taxbit Assist：基于 Amazon Bedrock AgentCore 的扎根式、角色感知 AI 智能体

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

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

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

该助手必须做对的事

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

  • 扎根且有引用 – 我们的用户要做出申报决策。每个答案都必须能追溯到用户可以打开并阅读的来源，而当助手不知道某事时，它必须如实说明。
  • 角色与组织感知 – 助手不应引导支持用户走仅限管理员的工作流，也不应把他们送到他们无法打开的页面。
  • 不提供税务建议 – 解释 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 应用。下图展示了解决方案架构。

Architecture diagram showing the request flow from dashboard user through AgentCore Runtime, including guardrails screening, knowledge base retrieval, Claude Sonnet reasoning, permission checks, and response streaming to CloudWatch.

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

该工作流由以下步骤组成：

  1. 用户在 Taxbit 仪表盘中提问。流式聊天 API 将问题连同用户的已验证身份（电子邮件、组织 ID 和仪表盘角色）转发给 AgentCore runtime。
  2. 运行时使用 Amazon Bedrock Guardrails筛查传入消息。个人可识别信息（PII）会被就地掩码。如果消息被阻止，模型将永远不会被调用。
  3. 智能体从 Amazon Bedrock Knowledge Bases 知识库中检索候选段落，然后在服务器端对它们重新排序。该知识库使用 Amazon Bedrock 的全托管检索增强生成（RAG）能力，底层由 Amazon S3 Vectors, Amazon Simple Storage Service（Amazon S3）的一项能力提供支持。
  4. Amazon Bedrock 模型对检索到的段落进行推理，并在推荐任何工作流之前验证用户是否有权访问相关功能和角色。有关按 AWS 区域划分的模型可用性，请参阅 按 AWS 区域支持的模型.
  5. 答案会带着来源链接流式返回仪表盘。AgentCore memory 在多个轮次之间延续对话。
  6. 每个请求都会向 Amazon CloudWatch发出 OpenTelemetry 追踪数据，这些数据为我们的评估工具提供输入。

智能体运行时

该智能体是一个小型 Python 应用：一个系统提示、一个模型和八个工具。它以 ARM64 容器镜像的形式发布，由 AgentCore runtime 从 Amazon Elastic Container Registry（Amazon ECR） 拉取，并按需扩展。

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

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

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

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

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

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

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

Amazon Bedrock 提示缓存可降低延迟和令牌成本。系统提示对每个请求都逐字节完全相同，并以缓存检查点结尾，因此静态前缀可在用户之间缓存。每个请求的上下文则通过用户消息传递。

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

我们的大部分工程工作都投入到了知识库中：一个由 Amazon S3 Vectors 支持的 Amazon Bedrock 知识库，使用 Cohere Embed English v3 生成嵌入，产生 1,024 维 float32 向量，并通过余弦距离进行比较。所有这些都由托管服务完成，因此我们无需运维任何向量数据库。

数据摄取

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

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

Pipeline diagram showing content from published, code-derived, and curated sources flowing through Lambda scrapers into S3, then through a post-chunking transform into the knowledge base.

图 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 个令牌（标题 80 个字符，范围 300 个字符）。由于 Cohere Embed English v3 每个输入最多接受 512 个令牌，块正文上限为 384，以便标题和正文一起适配该窗口。一次生产探测发现，我们约 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 能解析到客户可以打开的内容。代码派生和精选内容为答案提供依据，但不会产生客户无法访问的链接。

安全与数据处理

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

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

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

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

在实时流量上衡量质量

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

Evaluation diagram showing CloudWatch traces fanning out to AgentCore evaluations, a quality judge, a tax-advice classifier, and human review in Slack, with approved corrections feeding back into the knowledge base.

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

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

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

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

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

部署与运维

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

结果与影响

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

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

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

我们会做出哪些不同选择

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

下一步计划

目前，该助手基于产品知识进行回答。下一步是打造一个能够回答诸如“我有多少收款人缺少税务文档？”这类问题的助手，它通过同样绑定身份、经过权限校验的工具模式，查询客户自己的报告数据。用户提出问题，模型决定使用哪个工具以及哪些筛选条件，但经过身份验证的调用方决定该工具可以读取谁的数据，因此模型无法更改这一点。

结论

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

如需了解更多信息，请参阅 Amazon Bedrock AgentCore, Amazon Bedrock Knowledge Bases, Amazon Bedrock Guardrails以及 GitHub 上的 Strands Agents SDK.

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

关于作者