微软解释Azure内容理解agentic模式：文档抽取何时需要多步工具循环

大多数文档抽取任务一次通过就能完成：读取内容，按schema找到对应值，返回结构化结果。微软Azure内容理解团队在设计之初就以此为默认路径。但首席产品经理Joe Filcik在11月9日的博文中指出，有一类任务无法用单次推理解决——答案散落在不同页面、需要先排除再归一化、涉及跨行计算，或者首次读取后需要换一种视角重新检查。

他以美国财政部数据为例说明这个边界。schema要求提取2003年1月的机构支出总额，但相关数据分布在一份137页公报中跨两页的表格里，并非该月行中的每个数字都应纳入——收据项和报告合计需要排除，修订标记需要去除，负号需要保留。最终计算器给出180,681百万美元。Filcik强调，一个模型单次通过必须同时处理页面关系、排除规则、符号标注和算术，这正是agentic模式介入的位置。

agentic模式的机制不是简单地增加对话轮次。Filcik将其描述为把语言模型包裹在一个文档原生harness中：一个推理循环，配备导航文档文本和表格、检查视觉证据、执行计算、验证结果的工具。模型先规划步骤，再调用对应工具，必要时回到源文档重新检查。输出仍然由schema定义，返回的仍然是结构化字段。

他给出两个额外示例来展示这个循环的适用范围。一组经济图表需要不同的解读策略——绘制的数值本身不够，副标题、坐标轴和周围文字共同决定含义，图表模糊时流程可以回到源文件重新验证。另一份19页的网络日志需要把同一张表合并为统一视图，忽略重复标题，然后按条件筛选行并计数或求和。Filcik特别指出一个常见陷阱：用首尾事件ID推断总数看似快捷，但ID有缺口，必须逐页计数。

标准模式与agentic模式不是新旧替代，而是价格-性能曲线上的两个点。agentic模式消耗更多token、通常耗时更长。Filcik的建议是先从标准模式开始，当任务涉及跨内容综合证据、计算或对账、长文档穷尽分析、复杂规则条件或困难视觉结构时，再尝试agentic模式，在代表性文件上对比两种模式，用质量提升是否值得额外成本和延迟来做决定。

需要指出的是，以上全部示例均为微软自报的演示，没有公布与标准模式或其他方案的准确率对比数据，也没有第三方独立复现。agentic模式目前处于预览阶段，API版本为2026-06-01-preview。