多智能体协作：让合规自动化更可靠

法务和合规团队做自动化，最常见的失败原因不是“模型不够聪明”，而是把太多不同性质的工作塞给同一个智能体。同一个助手既要读合同条款、做合规判断，又要登录门户、下载证明、填报表、追踪审批流——最后的结果通常是：上下文丢失、指令打架、工具越接越多、幻觉率升高，团队反而更不敢用。

我更认同一个务实的结论：复杂工作不是靠更长的提示词解决的，而是靠更好的分工。AWS 最近分享了一个很具体的实践：用 Amazon Nova 2 Lite 负责“规划与推理”，用 Amazon Nova Act 负责“浏览器交互”，再用 agent-to-agent（A2A）消息把多个专职智能体串成一条可控的流程。它的例子是旅行规划，但背后的架构思路，放到法律科技与合规（合同审查、证据留存、第三方尽调、监管报送）里更有价值。

这篇文章会把该思路翻译成法务/合规语境下的可落地做法：你应该怎么拆分智能体、如何设计 A2A 消息、哪些环节适合“推理型模型”，哪些环节必须交给“执行型浏览器自动化”，以及如何把可靠性、审计性、数据边界一起做对。

单智能体为什么在合规场景里更容易崩

答案先说：合规工作天然是“异构任务集合”，单智能体会被迫在不同执行模式间频繁切换，导致上下文混乱与错误叠加。

旅行规划里，“航班搜索”是结构化 API，“酒店搜索”是动态网页；合规世界同样如此，而且更难：

• 结构化任务：制裁名单/PEP 检索 API、工商信息接口、发票/付款数据拉取、合同条款库比对。
• 非结构化任务：PDF 合同抽取、邮件/会议纪要归档、政策文本解读。
• 强交互任务：登录监管门户、供应商网站下载证书、在企业内部门户提交流程、处理 cookie 弹窗与动态表单。
• 高风险决策任务：是否触发升级审查、是否属于高风险国家/行业、是否需要补充证明。

把这些任务都交给一个“全能助手”，很快会出现三类典型问题：

1. 工具过载：工具越多，选择路径越不稳定；一会儿走 API，一会儿走网页，一会儿走本地解析。
2. 指令纠缠：既要严谨引用条款，又要“立刻执行”；既要保留证据，又要避免采集敏感信息。
3. 幻觉的放大效应：在 UI 变化、缺少 API、页面加载不稳定时，模型最容易“编造它完成了”。

这也是为什么在法律科技产品里，我更推荐“多智能体协作 + 强约束消息格式”的路线：让每个智能体只做一种类型的事，并且让它们用可审计的消息来协作。

多智能体协作（A2A）的核心：分工不是为了酷，是为了可控

答案先说：多智能体系统把“规划”和“执行”拆开，能显著降低幻觉率，并提升可观测性与回放能力。

AWS 的方案里有三个角色：

• 协调/规划智能体（Travel Agent）：理解用户意图、拆解步骤、调用其他智能体、合并结果。
• 结构化数据智能体（Flight Agent）：专注 API 查询并返回干净 JSON。
• 浏览器执行智能体（Hotel Agent, Nova Act）：专注网页交互和信息提取。

翻译到“人工智能在法律科技与合规”的系列语境，我会把它改成下面这套更贴近业务的角色：

1）合规编排智能体（Orchestrator）

它只负责三件事：

• 把需求翻译成任务清单（例如：第三方尽调、合同条款核对、证据留存）
• 决定调用哪个专职智能体
• 把结果拼成“可交付”的合规包（结论 + 证据 + 风险点 + 后续动作）

关键点：编排智能体不直接抓网页、不直接跑外部系统。它要“聪明”，但不需要“手快”。

2）结构化核验智能体（API/Rules Agent）

它负责所有可预测的数据源：制裁/PEP API、企业信息、内部主数据、条款库、风险规则引擎。输出一定要结构化：

• 命中规则 ID
• 数据来源
• 证据字段
• 时间戳

3）证据采集智能体（Browser/Portal Agent，类似 Nova Act）

它处理最难也最真实的合规痛点：没有 API 的门户与网站。

• 下载供应商证书（ISO、SOC、保险证明）
• 在监管门户填报并截图/导出回执
• 在第三方网站查询并提取关键信息（同时做数据最小化）

这类任务如果你用传统爬虫写死 DOM，很快就会维护到崩溃；用“浏览器自动化 + 自然语言指令 + 结构化 schema 输出”，可维护性通常更好。

一句话概括：让一个智能体“想清楚”，让另一个智能体“把活干了”，再让第三个智能体“把证据带回来”。

用 Nova 2 Lite 做规划，用 Nova Act 做执行：合规自动化的黄金搭配

答案先说：推理模型适合拆解与决策，浏览器自动化适合处理“没有 API 的现实世界”。把两者硬塞进同一智能体，稳定性会明显下降。

AWS 的做法是：Travel/Flight 用 Amazon Nova 2 Lite，Hotel 用 Amazon Nova Act。放到合规里也一样：

• Nova 2 Lite（规划/推理）适合：

  • 识别请求意图（例如“合同审查 + 反腐条款 + 数据出境”）
  • 生成步骤与检查清单
  • 决定升级路径（例如触发法务复核/合规官审批）
  • 把输出组织成可读报告

• Nova Act（浏览器执行）适合：

  • 登录、搜索、点击、下载、填报
  • 处理动态页面、滚动加载、弹窗
  • 按 schema 提取信息并返回 JSON

如果你的合规流程里存在“必须去某个门户拉取凭证/回执”的环节，那它天然属于 Nova Act 这一类执行能力。

A2A 消息怎么设计，才能兼顾可靠性与审计

答案先说：A2A 的价值在于把协作变成“可验证的交换”，不是聊天。消息里要明确输入、输出、证据与回传地址。

AWS 示例强调“小而结构化的消息对象”。在合规场景我会更进一步：把消息当作审计日志的原材料来设计。

建议你用类似下面的字段（不需要一次全上，但方向要对）：

• case_id：案件/事项编号（可追踪）
• task_type：例如 sanctions_screening、contract_clause_check、portal_evidence_download
• inputs：最小化输入（例如公司名 + 国家，不要整份合同全塞）
• constraints：
  • 不允许外传数据
  • 必须截图/导出回执
  • 只采集指定字段
• expected_output_schema：强约束输出结构
• evidence：来源、时间、页面 URL/文件哈希（能做就做）
• handoff_to：下一步要触发的 agent

合规版的端到端示例（把旅行换成尽调）

用户发起一个自然语言请求：

“请对供应商 A 做入驻尽调：制裁/PEP 检索、证书下载留存，并给出是否可入驻结论。”

1）编排智能体 → 核验智能体（API）

• 发消息：公司名、注册地、受益人（如有）、检查范围
• 回消息：命中/未命中、证据字段、数据源、时间戳

2）编排智能体 → 证据采集智能体（Browser）

• 发消息：供应商门户链接、需下载证书清单（SOC2/ISO/保险）
• 回消息：下载文件列表、关键字段、回执截图/导出文件的存储引用

3）编排智能体合并输出

• 结论：可入驻/需补充/需升级审查
• 风险点：命中规则、缺失材料
• 证据包：引用与校验信息（让审计能复核）

这种流程的好处是：任何一步出错，你都能定位是“规划错了”“API 数据不对”还是“门户交互失败”。单智能体模式往往只能得到一句含糊的“我已经完成了”。

把多智能体落到生产环境：我会坚持的 5 条硬规则

答案先说：合规自动化的关键不是让模型更自由，而是让系统更可控。

1. 最小权限与最小数据

   • 每个智能体只拿自己需要的凭证与数据。
   • Browser Agent 尤其要限制可访问域名白名单。

2. 输出必须结构化，结论必须可追溯

   • 任何“通过/不通过”都要带规则 ID、证据来源、时间。

3. 把“截图/回执/哈希”当成一等公民

   • 合规自动化不是写作文。证据链缺失等于没做。

4. 失败要可恢复：重试、降级、人工接管

   • API 不可用就走备用数据源；门户异常就生成“人工步骤卡”。

5. 把提示词当作代码管理

   • 版本控制、评审、回归测试。合规场景不适合“随手改一改”。

常见问题（People Also Ask）

多智能体是不是更贵、更慢？

一般会更贵一点，但通常更稳定、更可预测。对合规来说，“少一次返工/少一次错报”往往比 token 成本更关键。

什么时候不需要 Nova Act 这类浏览器智能体？

当你的关键数据源都有稳定 API，且页面交互不是必须步骤（例如不需要下载证书、提交回执），可以先不用。别为了炫技上浏览器自动化。

多智能体如何降低幻觉？

靠三件事：

• 专职智能体减少任务切换
• 强约束 schema 输出
• 证据与来源字段强制回传

让 AI 语音助手与自动化工作流真正“可交付”

多智能体协作并不是旅行规划专属。对法律科技与合规来说，它更像一种“工程化的自保”：把不可控的生成式能力，装进可验证、可审计、可回放的流程里。

如果你正在做 AI 语音助手与自动化工作流，我的建议很直接：**别急着把一个助手做成全能。先把流程拆开，把每个环节的输入输出钉死，再让它们通过 A2A 消息协作。**当系统能够稳定产出“结论 + 证据 + 下一步动作”，你就跨过了从 demo 到可用产品的最大鸿沟。

接下来值得思考的问题是：你团队当前最耗时、最容易出错的合规环节，究竟是“判断不清”，还是“执行太碎”？如果答案是后者，多智能体 + 浏览器执行，可能就是你该优先落地的那一步。