白皮书：为什么文档智能需要本地执行内核

摘要

同一份合同问两次，金额不应该变。这个要求看起来朴素，却正好打在通用推理的弱点上：推理擅长临场组织语言，不擅长每次给出同一个字段值，也不擅长说明这个值来自哪一页。

把文档处理交给通用大模型推理，会遇到三个结构性问题：结果不稳定、无法批量、过程不可追溯。本文说明为什么应当把「适合软件确定执行」的文档工作从推理中剥离，交给本地执行内核，并给出能力边界、契约设计与落地路径。

读完应能判断一件事：你现在卡住的，究竟是模型不够强，还是确定执行被放错了地方。

---

1. 三种常见的失败形态

1.1 结果不稳定

同一份文档、同一个问题，两次调用给出不同字段值。原因不是模型「不够聪明」，而是推理过程本身不具备确定性。文档处理需要的恰恰是确定性：同一份合同第 3.2 条的金额，每次都必须解析出相同结果。

1.2 无法批量

推理式处理的成本与延迟随文档页数线性甚至超线性增长，且难以并发。批量场景（数百份报表、上千张票据）在成本与时效上双双失控。

1.3 过程不可追溯

当结果被质疑时，无法回答「这个值是从哪一页、哪一个表格、按什么规则得出的」。缺乏来源定位与执行事实，就没有复核与审计的基础。

2. 拆分的依据：确定执行 vs 人工判断

判断标准不是「难不难」，而是结果能否由软件确定产生并可独立验收。

属于确定执行	属于人工判断
文档解析与格式转换	这份证据是否充分
字段、表格、段落抽取	结论是否可以被采纳
基于明确规则的比对	是否需要通过审批
Decimal 金额与日期计算	是否需要对外发送
模板应用与产物生成	风险是否可接受

把左列交给执行内核，右列留在人与流程中。这不是「AI 做得少」，而是让每一部分都由合适的主体负责。

3. 本地执行内核的四个特征

3.1 契约驱动

每个公共能力只有一个稳定动词、一个可独立消费的软件结果、封闭结构化的输入输出，以及明确的错误、资源成本、并发、取消、副作用与幂等语义。

3.2 入口等价

同一能力同时提供 MCP 与机器可读 CLI，由同一能力目录与同一契约投影产生。任意第三方技能无需修改内核代码、无需登记身份，即可发现并调用全部公共能力。

3.3 结果可预期

一次调用的结果只有四种：成功、已受理（长耗时任务已创建）、阻断（前置条件不足，执行尚未发生）、失败（执行失败且副作用明确）。

阻断不是等待状态——它明确表示本次执行尚未发生，调用方补齐事实后重新发起完整调用。这一条消除了大量「卡在某个中间态」的工程问题。

3.4 过程可审计

返回输入与规则版本、处理覆盖、输出完整性、稳定引用、来源位置、警告、跳过项、资源使用与副作用事实。项目给出技术事实，但不代替人判断业务是否达标。

4. 为什么是本地

维度	本地执行	远程服务
数据边界	文档不出本机	需上传
合规成本	低	需评估传输与留存
离线可用	是	否
批量成本	边际成本趋零	按次计费
身份锚点	操作系统主体	需自建账号体系

对合同、票据、身份材料、财务数据而言，「不出本机」往往不是偏好，而是前置条件。

5. 边界同样重要

执行内核明确不拥有：

• 用户交互、意图理解、补问、专业复核与确认
• 业务流程编排、跨能力自主调度与业务完成判断
• 行业结论、证据充分性、法律或财务采纳
• 业务审批、签署、发送、交付与归档
• 远程连接器、共享服务器、多租户、账号平台

这些职责属于外部桌面智能体、外部技能、人员或外部系统。边界不是能力不足，而是让每个主体对自己的结果负责。

6. 落地路径

1. 清点文档工作，区分确定执行与人工判断。
2. 为确定执行部分定义结构化输入输出与错误语义。
3. 接入执行内核（MCP 或命令行，按集成形态选择）。
4. 在智能体或流程中保留复核与确认节点。
5. 按正常、边界、失败、并发、重复调用五类用例验收。

接入细节见《如何把文档能力接入你的智能体》。

7. 结论

文档智能的瓶颈通常不在「模型够不够强」，而在「结果能不能被信任、能不能批量、能不能追溯」。把确定执行的部分交给本地执行内核，把判断的部分留给人与流程，是让文档智能真正进入生产的工程前提。