一份看似合理的合同分析为何漏掉 80 万美元

Natalia Connolly 介绍一家大型医疗企业收购较小专业公司的案例。采购团队面对数百家供应商、四万多份合同文件和彼此不相连的数据库。两位讲者使用真实项目的合成案例进行说明。

收购方希望了解合并后是否能谈到更好的条款、估算节省金额，并在续约截止前采取行动。分析必须能追溯到合同页面和发票行，让谈判人员能够为结论提供依据。

Claude Code 的第一份答案看起来完整合理。年度总支出、两家公司各自的支出以及合同数量都正确，但合同总价值相差约 80 万美元。

智能体还把通知截止日期算成 12 月 1 日，正确日期却是 11 月 1 日。在这个案例中，如果照它的答案等待，合同就会自动续约。

Connolly 解释，长合同可能在预处理时静默失败，从未进入数据库。修订文件也可能已被提取，却没有关联到原合同；案例中漏掉的 80 万美元就来自这样一份孤立的修订文件。

另一个陷阱是将合同和所有修订文件中的金额相加，即使每份修订文件都重新列出总额。在她的例子中，相加得到约 1700 万美元，而最新修订文件给出的正确总额是 700 万美元。

跨页表格也会造成问题：第二页可能没有列标题。系统需要整张表的上下文才能理解数字含义。

两人花了约两周建立处理流程，随后在一夜之间处理四万多份合同。Connolly 说，这些准备让结构化结果更容易检查，也便于用程序核对。

五个阶段包括预处理和文档识别、文件分类、提取条款费率与支出、将服务映射到支出类别，以及让分析智能体处理提取后的数据。

Kevin Madura 指出，合同中可能有图表和其他视觉内容，简单文字识别会漏掉其中信息。他们将页面图像交给 DSPy 获取结构化信息，而不是只保留图表标签。

当团队事先知道项目需要费率层级、返利或其他字段时，就先定义结构。随后 Claude Code 可以使用规范化的合同、支出和发票数据，构建或调用针对该交易的工具。

获取费率表页面、查询供应商支出等定制工具可以包含业务逻辑和已知例外。团队对部分规则更倾向于使用代码和数据库视图，而不是完全依赖提示词。

工具和配置可以让知识在整个项目期间得以保留，也能管理数据访问。Madura 介绍了允许一组明确操作、阻止其他调用的做法。

错误的续约截止日期说明了业务背景为何重要。智能体使用了解约条款中的日期，而问题需要根据续约条款计算。

合同管理数据库可能遗漏修订文件或关联错误。因此，团队读取原始文件，重建主服务协议、工作说明书和修订文件之间的关系，避免遗漏及重复计算。

访问控制带来了另一种失败模式：来自其中一家公司的数据源如果返回拒绝访问或格式错误，可能看起来像零。Madura 说，明确的错误反馈能让智能体停止、请求人工帮助或寻找其他权威来源。

团队派出多个智能体并行寻找不同的节省机会。之后必须核对它们的发现：两个有效分析可能指向同一家供应商或同一张发票，同一笔节省不能计算两次。

为完成核对，团队采用了更明确的流程，规定要比较哪些数据点以及下一步该做什么。这一结构化步骤接在智能体较开放的分析之后。

智能体还需要知道管理层已经开始做什么。一项建议单独看可能很有吸引力，但如果公司几个月前已经启动同样工作，它就不再相关。

Madura 建议通过记忆、工具或类似机制保留有用业务背景，让后续分析不必反复发现已知限制。两位讲者的主要结论是尽早整理数据，并在合适的时候提供正确业务背景。