保险公司每天要处理成千上万份保单、宣誓书、批单和监管表格。这些文件往往“长得很像”：一份投保批单和一份监管宣誓书可能用着相近的术语，但一旦分错类别，带来的就是合规风险，或者理赔流程被卡住。靠人手动分，慢且容易在疲劳时出错；靠传统自动化方案，又常常在“长得像但用途不同”的文件上栽跟头。

AWS 在 2026 年 8 月发布的一篇工程博客，给了一个有意思的解法：用三个各有所长的智能体，把“看内容”和“看版式”两件事分开做，再让一个编排器把两边的判据交叉校验、给出带置信度的结论，并在拿不准时把样本交给人。他们在保险单据测试集上跑出了全类别 100% 的准确率，单文档平均 19.3 秒、置信度 93%。

这篇把方案完整打开来讲。不只在说它准，更在说它怎么做到可审计——两条独立证据通道、一份把分歧写进规则的结构化裁决、以及每一步都可被回溯的推理记录。

一份保单和一份宣誓书，为什么单模型分不准

分类任务难在哪，得先看清楚。保险单据里 POLICY（保单、批单、声明、承保文件）、AFFIDAVIT（宣誓陈述、公证文书、监管报送）、MISCELLANEOUS（其余）这三类，术语大量重叠。一份保单的“批单”（endorsement）和一份监管“宣誓书”（affidavit），可能都写着被保险人、条款、生效日期，但法律用途天差地别：批单是保单的变更，宣誓书是带有法律效力和合规义务的陈述。把批单错分到宣誓书，就意味着它会被送进错误的后续流程。

难点在于，单模型很难同时把两件事都做对。一类判断看“写了什么”——条款措辞、法律语义、责任结构，这靠读文本；另一类判断看“长什么样”——表单布局、表格结构、版式惯例，很多单据即便文字不同，版式却高度雷同（同公司的保单模板、同监管的报送表格）。只看文本，会被相似措辞带偏；只看版式，又会在“同一模板套不同内容”时失灵。

单模型方案通常只能强化其中一个维度。而 AWS 这个方案的出发点，就是把这两个维度拆给两个各司其职的 agent，再用第三个 agent 当裁判，把两边的判据摆到一起比。这不是“堆更多参数”，而是把任务结构本身拆开。

把三个专家塞进一个编排器：Strands的agents-as-tools

这个方案跑在 Strands Agents SDK 上，用的是一个叫 agents-as-tools（把智能体当工具）的模式。先说清楚这个模式在解决什么：它让一个编排器 agent 能在“不把整件事交出去”的前提下，动态咨询几个专精 agent，最后自己综合出结论。

Strands 是一个 model-driven 的 SDK，起一个 agent 只需要给定模型、系统提示和工具这三样东西，几行就能跑起来。agents-as-tools 模式的关键在于：把每个专精 agent 包成一个带工具装饰器的函数，SDK 会从函数的类型注解自动生成 JSON Schema、从文档字符串提取工具描述，于是编排器眼里的“专家”和“计算器工具”在调用形式上没有区别，都是可被模型选择的工具。

这里有个容易混的点：Strands 1.0（2025 年 7 月发布）其实给了四种多智能体原语——agents-as-tools、handoffs、graph、workflow，还带 A2A（agent 间跨进程通信）协议。那为什么这个方案选 agents-as-tools，而不是 handoffs？

差别在控制权。handoffs 是“把控制权整个交给专家”，编排器退场，专家（或人）接着干；A2A 是让不同进程、不同框架的 agent 互相发现、互相调用。而文档分类要的是另一件事：同时调两个专家、拿到两边的判断、自己再比一遍。用 handoffs 的话，控制权一旦交出去就回不来，没法让“文本专家”和“版式专家”各自出一份证据再汇总。agents-as-tools 恰好是“编排器始终在场上、专家只是被调用的工具”，这正好匹配“两个通道并行取证 + 一个裁判综合”的结构。Kiro、Amazon Q、AWS Glue 这些生产系统都在用 Strands，方案选它有工程可信度上的依据。

还有一处细节值得提：两个专家 agent 在定义时都挂了 NullConversationManager 这个对话管理器。它是一个 no-op，不会修改对话历史。在这里的语义是，编排器每次调用专家都喂一条全新的提示（“分类这份文档”），不需要在多次调用之间累积历史——每次调用都是一次独立、无状态的查询。历史由外层编排器管理，专家自己不记前账。这个选择很克制，也避免了把无关上下文带进专家推理。

文本通道：用Claude Haiku 4.5做法律语义推理

第一个 agent 是 Document Analysis Agent，负责“读文字、辨语义”。它跑在 Amazon Bedrock 上的 Claude Haiku 4.5，模型 ID 是 anthropic.claude-haiku-4-5-20251001-v1:0，temperature 设到 0.1、max_tokens 4096，取向是稳定、低随机。

它为什么用大模型而不是规则或传统分类器？因为要识别的是文本里“暗示文档类型的细微模式”：措辞上是“endorsement”还是“affidavit”，条款结构上是承保变更还是法律宣誓，责任表述上是保险公司义务还是被监管义务。这些不是关键词命中，而是法律语言的语义判断，正是 LLM 的强项。

关键是它输出的是结构化结果，不是一段自由文本。方案给这个 agent 定义了一个输出结构 TextualAnalysisOutput（基于 Pydantic），要求模型必须按这个结构吐出三样东西：分类（POLICY / AFFIDAVIT / MISCELLANEOUS 三选一）、置信度（0.0 到 1.0 之间）、以及“为什么这么分”的理由。其中的理由字段是后面整条审计链的起点——它让“文本侧凭什么这么判”变成可记录、可复核的文字，而不是黑箱里的一个标签。

版式通道：用 Titan 多模态嵌入 + FAISS 认“长相”

第二个 agent 看的是“长相”，不看文字。这是整套方案里最容易被忽略、却最巧妙的一环——它不读文档语义，而是把文档第一页的视觉版式编码成向量，去和已知模板库比对。

底座是 Amazon Titan Multimodal Embeddings G1（模型 ID amazon.titan-embed-image-v1）。这个模型把图像和文本编码进同一个语义空间，输出向量默认 1024 维（也可选 384 / 256），最大支持 2048×2048 的图像。它不生成文本，只出 embedding。正是这个“图文同空间”的特性，让一份文档的“版式长相”能被压成一个向量：表单的网格结构、表头位置、留白与分栏惯例，都落在向量里。

版式 agent 的做法是：把 PDF 转成 base64 图像后，只取第一页，调 Titan 的多模态嵌入接口得到它的视觉向量，然后用 FAISS 在预先建好的索引文件 hybrid_docs.vdb 上做相似度检索，取前 3 个最相近的命中。从每个命中结果携带的 label 元数据里取出类别，用多数投票得出分类——哪一类在 3 个命中里出现得最多，就判哪一类，置信度就是“命中数 / 3”。

FAISS 是 Meta 开源的向量检索库，这里做本地相似度比对，文档不用上外部向量库，私有化友好。案例里特意注明，加载索引时开启了 allow_dangerous_deserialization 这个反序列化开关，原因是 FAISS 内部用 pickle 序列化，而索引是“自己建的”才安全——这是官方案例里明确的前提。

这一通道补上的是文本通道的盲区：某些单据文字内容千变万化，但版式高度一致（同一公司、同一监管的制式表格）。即便读不出语义，看“长相”也能认出来。两个通道一横一纵，把“写了什么”和“长什么样”都覆盖了。

编排器怎么在两条证据间裁决

第三个 agent 是 Validation Agent，它同时是编排器。它手里握着前两个 agent 当工具——一个管文本分析、一个管向量检索——自己不亲自判类别，而是分别调两个专家、拿到两边的证据，再综合。

它输出的也是结构化结果，而且字段比两边都多，一共九个：文本侧分类（textual_analysis）与文本侧置信度（textual_confidence）、版式侧分类（vector_analysis）与版式侧置信度（vector_confidence）、最终分类（final_classification）、总置信度（confidence）、是否需要人工复核（requires_human_review）、决策简述（decision_logic），以及两侧专家的详细推理（justification）。

真正有意思的是决策逻辑放在哪。它没写成硬编码的 if-else 树，而是写在编排器的 system prompt 里，作为模型要遵循的规则：

• 两个通道一致 → 高置信（0.85–0.95）
• 分歧 → 内容丰富的听文本，视觉独特的听向量
• 文本短于 50 字符，或文本置信低于 0.3 → 听向量
• 批单（endorsement）一律算 POLICY
• 证据互相矛盾 → 转人工复核
• 裁决前必须两个工具都调用

这是个很关键的设计取向：交叉验证的逻辑是“模型驱动”的，存在 prompt 里，而不是埋在代码里。好处是改规则不用动代码、不用重新部署，调一句 prompt 就能改裁决偏好；代价是规则的最终执行依赖模型对 prompt 的遵循度，需要靠结构化输出和测试来兜底。它把“怎么在分歧里裁决”这件事，从工程逻辑挪到了可编辑、可解释的自然语言约束上。

requires_human_review 这道闸门是整套方案能不能“落地到合规场景”的命门。当两侧证据矛盾、或任何一侧置信不足时，样本被标给人工，而不是硬给一个可能错的标签。这把“机器能定的”和“必须人拍板的”切开了——前者吃自动化吞吐，后者进人工通道保底线。

为什么挑 Haiku 4.5 而不是更强的模型

方案在三个 agent 上都用了同一个模型 Claude Haiku 4.5，而不是更贵的 Sonnet 或 Opus。这不是偷工，是生产负载下的权衡。

文档分类是一个高吞吐、对“绝对正确”有要求、但对“推理深度”要求没到顶级难度的任务。Haiku 4.5 在这个工作负载上满足了准确率要求，同时把延迟和成本压下来：单文档平均 19.3 秒、置信度 93%。换成 Opus 当然可能在某些极端样本上更稳，但每文档的成本和耗时都会显著抬升，而分类任务并不需要那个量级的推理力。

成本结构也得算清楚：每处理一份文档，是编排器 + 两个专家共三次 Haiku 调用，外加一次 Titan 嵌入调用。也就是说成本大致是“3×Haiku + 1×Titan 嵌入”。在需要逐份处理的合规场景里，选 Haiku 直接决定了这套方案能不能规模化跑——用 Opus 跑同样三遍，账单和延迟都会劝退。19.3 秒/文档这个数字，本身就是“够准且够快够便宜”的综合结果。

100% 是怎么来的，又意味着什么

方案在基准测试里把多智能体系统和另外三种常见 AWS 做法摆到一起比：

Textract 和 Comprehend 本就是做文本抽取和实体识别的，不是为多类别分类（尤其是共享法律术语的类别）设计的，在这个测试集上只有 25%。Bedrock Data Automation（BDA）能正确处理多数宣誓书和杂项，但仍有近三分之一分错。多智能体是唯一在全部类别上都拿到 100% 的。

但“100%”要放到它该在的位置上看。它是 AWS 在自己保险单据测试集（policy / affidavit / miscellaneous 三类）上的结果，不等于随机生产流量的泛化率——文章没披露测试集规模和分布，不能外推成“任何单据都 100%”。更准确的解读是：在“语义相近、版式相似”这类最容易错的单据上，双通道 + 编排校验把错分几乎消灭了。

更要看清方案的几个边界，否则会误读它的适用面：

• 向量通道强依赖预先建好的 FAISS 模板库。Unknown 类型没进库，版式检索就退化；模板库要随新单据持续维护，这是持续的运维成本，不是一劳永逸。
• 视觉匹配只看第一页。版式检索只取 PDF 的第一页，多页文档后续页的版式差异不参与比对。长文档尾部换了版式，这一通道看不见。
• 延迟和成本随量线性增长。每份文档三次模型调用，19.3 秒在高吞吐下是硬约束，不是可以忽略。
• 对比的“公平性”要打个折扣。拿 Textract/Comprehend 的 25% 当基线，本质是“用抽取工具去硬做分类”的对照，目的是凸显“分类需要专门设计”，而不是说这两个工具不行。
• 人工复核的隐含成本没算进 100%。requires_human_review 把边界样本交人，真实生产里人工通道的吞吐和一致性是另一道工程题，方案本身不解决。

把这些边界摆出来，100% 才是一个可信的工程结论，而不是一句营销数字。

把推理留下：可审计这条线

回到标题里的“可审计推理”。这套方案在合规场景里最值钱的，不是 100%，而是每一步判断都能被留下、被回溯。

可审计性来自三处叠加。其一，每个 agent 都输出结构化结果，字段固定、机器可解析，reasoning 与 justification 字段把“为什么这么判”写成文字，不再是黑箱标签。其二，编排器的 OrchestratorOutput 把两侧证据（textual_analysis、vector_analysis 及各自置信度）和最终结论、决策逻辑、详细理由一并存档，等于给每份文档留了一份“双通道取证 + 裁判意见”的完整卷宗。其三，requires_human_review 明确标出哪些样本机器没敢拍板、交给了人，人工介入的边界清晰可查。

这对金融单据归类是直接对口的能力。监管要的从来不是“分对就行”，而是“分对了能解释、分错了能追溯、拿不准的有人兜底”。双通道独立取证提供交叉验证，结构化置信度提供“机器有多笃定”的量化，人工复核闸门提供底线——这三件套合起来，正好填满了“可解释 + 可审计”的合规要求。方案没额外造一套审计系统，而是把审计能力长在数据结构里。

这套打法能搬去哪里

把这个方案从保险单据里抽出来，剩下的是一组可迁移的模式：文本语义通道 + 版式视觉通道并行取证，编排器按规则交叉校验并输出带置信度的结论，边界样本交人工。这套结构不绑死在保险上。

凡是“文档长得像、类别要靠内容和版式共同判断、且错分有合规代价”的场景，都吃这一套——合同归类、内部单据分流、监管材料归档，逻辑同构。它和本项目里讨论过的另一些方法论走的是同一条脉络：用结构化或多通道的设计，去抬升金融 AI 的可信度，而不是靠单模型硬扛。

需要提醒的是，这套打法有它的前提：得先有可比对的知识库（FAISS 模板库），得接受多 agent 带来的延迟与成本，得把人工复核通道当成一等公民而非补丁。它解决的是“难分且分错代价高”的那类问题；对那些类别清晰、量极大的粗分，单模型或规则可能更划算。选不选中，看的是问题结构，不是方案多花哨。

把话说回来，AWS 这个方案真正值得记下的，不是“又多了个 100% 的基准”，而是它把“怎么在两条证据间裁决、怎么把推理留下、怎么在拿不准时退给人”这三件事，用三个 agent 和一套结构化 schema 钉成了可复刻的工程。准，是结果；可审计，才是它能进生产的原因。