多 Agent 协同还是独立执行？AI 文档智能审查系统的架构设计实践

一、为什么需要 AI 文档智能审查？

随着大语言模型技术的发展，AI Agent 已经逐渐从简单的聊天问答工具，发展为能够执行具体业务任务的智能系统。

在企业实际工作中，存在大量需要人工审查的文档，例如：

• 工程施工方案
• 项目技术报告
• 合同与管理制度
• 安全生产管理文件
• 产品需求文档

这些文档通常具有三个特点：

1. 内容复杂：一份文档可能包含数十甚至数百页内容。
2. 审查标准多：不同文件需要遵循不同的业务规则。
3. 准确性要求高：不仅需要发现问题，还需要提供依据和定位信息。

传统人工审查需要投入大量时间，而直接将整份文档交给一个大语言模型，也可能出现遗漏、上下文干扰和结果不稳定等问题。

因此，可以考虑将复杂审查任务拆解为多个独立的 Agent 执行。

二、两种典型的多 Agent 架构

在设计文档审查系统时，常见的思路有两种。

方案一：协同式多 Agent

不同 Agent 承担不同角色，例如：

• 文档解析 Agent：负责理解文档结构。
• 规范检索 Agent：负责查询相关技术规范。
• 审查 Agent：负责判断是否存在问题。
• 复核 Agent：负责验证审查结果。
• 报告 Agent：负责生成审查报告。

这种方式强调多个 Agent 之间的任务交接与协作。

优势：

• 职责分工清晰。
• 适合多步骤复杂任务。
• 可以针对不同角色优化模型和提示词。

不足：

• Agent 之间存在信息传递成本。
• 前序错误可能影响后续判断。
• 调试复杂度较高。

方案二：基于规则的独立 Agent

另一种方式是将每条审查规则作为一个独立任务。

例如，一份施工方案需要执行以下审查：

系统为每条规则创建独立的 Agent 任务。

每个 Agent 只处理当前规则，不依赖其他规则的审查结果。

这样可以减少规则间的信息干扰。

不过，这种设计存在一个重要前提：单条规则必须具备独立完成判断所需要的全部信息。

如果某条规则依赖其他规则的执行结果，那么它就不适合直接采用完全隔离的架构。

三、独立 Agent 的核心设计原则

1. 规则必须自包含

每条审查规则都应当包含独立完成判断所需的信息。

例如：

不推荐的规则描述：

“按照 R003 的检查结果，进一步判断施工工艺是否合理。”

原因是独立 Agent 无法获得 R003 的审查结果。

推荐的规则描述：

“检查施工方案中与本规则适用范围对应的施工工艺内容，判断是否明确施工顺序、主要工艺步骤及相应技术控制要求，并指出具体缺失或矛盾内容。”

后一种方式不依赖其他规则，可以独立执行。

2. 规则与执行逻辑解耦

规则可以拆分为两个部分：

规则元数据：

• 规则编号
• 规则名称
• 所属业务类型
• 审查类别
• 依据文件
• 风险等级配置

规则执行内容：

• 检查对象
• 检查要求
• 判断条件
• 问题输出要求

这样能够将业务配置与大模型的自然语言判断分离。

例如，风险等级由业务系统的规则元数据进行管理，而不是让模型通过输出文字自行修改风险等级。

这样可以减少大模型生成结果对业务管理逻辑的影响。

3. 审查结果必须结构化

如果每个 Agent 都直接输出自由文本，系统很难对多个审查结果进行统一处理。

因此，建议设计统一的结果结构。

需要注意，模型生成的置信度不一定具有统计校准意义，不能直接作为审查结论正确率。

通过结构化输出，可以进一步实现问题汇总、定位展示、人工复核和报告生成。

四、如何优化执行效率？

如果一份文档需要执行 50 条规则，最直接的做法是依次执行 50 次模型请求。

但这种方式可能导致整体审查时间较长。

因此，可以考虑引入并行执行机制。

例如：

假设有 50 条审查规则，每条规则平均需要 20 秒完成推理。

完全串行执行时，理论总耗时约为：

50 × 20 = 1000 秒

如果系统能够稳定支持 10 个并发任务，并且每条规则耗时接近，则理想情况下可以分为 5 批执行：

5 × 20 = 100 秒

也就是说，理想耗时从约 16.7 分钟降低至约 1.7 分钟。

需要说明的是，这只是简化模型。

真实系统还会受到以下因素影响：

• 大模型推理服务的并发能力
• 输入上下文长度
• 请求队列与限流
• 文档检索耗时
• 不同规则的实际推理时长

因此，生产环境中应当进行压力测试，并根据模型服务能力设置并发上限。

五、如何解决审查问题的可追溯性？

AI 文档审查不同于普通聊天问答。

对于专业审查场景，仅仅输出“存在问题”通常是不够的。

例如：

不理想的输出：

“施工方案中的安全措施不完善。”

更合理的输出：

• 审查问题：未明确某项施工工序对应的安全控制措施。
• 文档位置：第五章第三节。
• 原文摘录：展示与问题相关的原始内容。
• 审查依据：提供适用的管理要求或技术规范。
• 修改建议：补充该施工工序对应的风险控制措施。

这样可以让用户快速判断 AI 的审查意见是否合理。

从产品设计角度，还可以进一步支持点击问题卡片后定位到对应的文档原文。

需要特别注意：原文引用和页码定位必须由文档解析结果进行校验，不能仅依赖大模型自行生成。

六、人工复核仍然不可缺少

对于专业性较强的审查任务，大模型可能存在以下问题：

1. 将建议性要求误判为强制性要求。
2. 未正确理解某项要求的适用条件。
3. 将引用的技术规范与实际工程场景错误匹配。
4. 忽略文档中的补充说明。
5. 将合理的技术差异误判为问题。

因此，AI 审查系统应该定位为专业人员的辅助工具。

可以设计以下人工复核流程：

AI 自动审查 → 问题分类展示 → 人工确认或驳回 → 编辑审查意见 → 导出报告

系统还可以记录人工修改情况，用于后续规则优化。

但需要区分人工反馈与真实标准答案：用户修改某项意见，并不必然意味着修改后的内容具有普遍适用性。

七、总结：多 Agent 并不是越复杂越好

多 Agent 架构的价值，不在于创建了多少个智能体，而在于是否能够有效拆解复杂业务。

对于文档智能审查场景，基于规则的独立 Agent 架构具有以下潜在优势：

• 审查任务能够独立执行。
• 单条规则可以单独维护。
• 多条规则可以并行处理。
• 审查结果容易进行结构化汇总。
• 单条规则的异常更容易定位。

当然，这种架构也存在重复处理文档、上下文成本较高、跨规则推理能力不足等限制。

因此，更合理的系统设计方式是根据任务性质选择架构：

规则独立、判断边界清晰的场景，可以优先采用独立 Agent；需要多步骤协作、复杂推理或共享中间状态的场景，可以考虑协同式多 Agent。

最终，企业 AI Agent 产品的核心竞争力不是架构有多复杂，而是能否在准确性、效率、可解释性和维护成本之间取得合理平衡。