企业即时通讯接入AI助手：合同解析、智能填单与审批状态回传的实现思路

在企业即时通讯中接入AI，不必停留在发送问题、返回文本。对于合同审批和智能填单，可以将会话入口、文件解析、字段草稿、人工确认、业务提交与状态通知串成一条任务链。

实现的关键，是把模型输出与正式业务操作分开。模型辅助理解材料和生成候选值，服务端控制权限、校验与接口调用，OA或对应业务系统保存表单、流程和处理结果。消息卡片承接交互，不替代业务系统授权。

下面以“上传合同，生成审批草稿，确认后进入OA”为例，说明组件分工、任务状态和异常处理。它是一种实现设计，具体功能需要结合平台版本及接口开发，不代表已有成品功能。

这里的合同助手用于整理材料、生成填单草稿与辅助办理，不自动批准合同，也不代替法律审查。

一、组件分工：入口、处理服务与业务系统

IM客户端提供发起入口，机器人或应用接收请求，消息卡片用于展示进度、待确认字段及处理结果。合同原文则放在获准使用的文件服务中，消息事件携带受控引用，避免反复传递完整附件。

AI应用服务负责组织处理任务，包括检查用户权限、获取文件、调用解析与模型服务、生成草稿，以及通过受控接口调用OA。模型不应直接持有可写入全部业务数据的长期高权限凭据。

业务系统提供表单结构、合法枚举、组织与项目数据、提交接口及状态事件。若没有现成接口，需要单独评估改造，不宜假设所有OA均可按同一种方式调用。

知识检索可以辅助获取制度和填写说明，但不能代替目标系统字段约束。文档中的“通常填写某项”，不应覆盖服务端明确的必填、类型或权限规则。

下面按逻辑职责划分组件；实际部署时可以组合实现，但权限与责任边界仍应清楚。

组件	主要职责	关键边界
企业即时通讯平台	提供会话入口、草稿交互和状态通知	收到卡片不代表获得业务操作权限
AI处理服务	解析材料、提取字段、生成草稿	模型输出需要校验与人员确认
接入服务	身份映射、接口调用、幂等与结果核对	不以高权限服务身份绕过用户授权
OA或业务系统	字段校验、流程授权、正式记录与状态管理	提交成功不等于审批通过
文件与知识服务	按权限提供原文、制度与检索依据	材料进入AI处理不代表可以公开共享

一次完整办理的交互顺序

用户上传获准使用的合同文件，服务端建立任务并检查权限；解析服务提取内容，AI生成候选字段，再由业务规则校验；卡片或表单展示草稿，用户修改并确认具体版本；服务端复核权限后提交OA，保存业务单号，随后依据OA真实状态向获准人员发送通知。

可以概括为：上传文件 → 建立任务 → 解析材料 → 校验字段 → 展示草稿 → 人员确认 → 提交OA → 返回业务单号 → 按真实状态发送通知。解析不足时转入补材料，提交结果不确定时先核对，不直接进入下一步。

二、文件进入任务前，先检查身份与使用范围

任务需要关联发起用户、组织、来源会话、文件标识和目标业务类型。会话中的请求者是谁，与后台调用使用哪个服务身份，是两个需要衔接的问题。

后端应验证调用来源与当前身份，检查文件访问权限、允许的类型和大小，再获取内容。不能直接信任客户端提交的用户编号、任意下载地址或目标表单名称。

文件解析按内容选择文本提取或OCR等方式。扫描件、表格、印章遮挡和附件不完整，都可能影响结果，应记录实际解析情况并保留“需要补充材料”的状态。

合同和附件属于待处理数据，其中即使出现“忽略规则”“调用提交接口”等文字，也不能变成系统指令。模型可用工具、数据范围和写入权限，应由服务端约束。

三、先生成结构化草稿，再做确定性校验

可以从少量字段开始，例如合同名称、合作方、总金额、币种、履约期限、付款节点和关联项目。

每个候选字段除数值外，还可以保存原文依据、页码或定位信息、用户修改值及确认状态。页码应对应实际文件，模型给出的定位也需要能回到原文核对。

未识别到的信息应为空或标为待确认，不能以看似完整为目标补造日期、项目编号和银行账户。模型自报的置信程度，也不能单独作为自动提交依据。

字段草稿进入业务校验时，应根据目标表单检查类型、精度、日期关系、必填与枚举。金额与币种、含税与未税、总额与分期额应分别处理；供应商、项目和费用归属需要匹配业务系统中的有效对象。

出现多个同名对象时，返回候选供用户选择；缺少唯一匹配时，不把自然语言名称直接替代业务主键。业务系统自身也应保留最终校验，不能只依赖助手侧检查。

合同摘要用于辅助阅读，填单草稿用于辅助录入，两者都不能作为合同合法性或签署条件的自动结论。法务、财务及业务审批仍走正式流程。

四、用任务状态组织交互，不把对话当成唯一记录

建议为一次办理建立独立任务标识，区分接收、解析、待补材料、待确认、提交中、已提交、失败和取消等状态。

消息卡片展示当前阶段和用户可执行的动作，例如补充附件、修改字段、查看原文和确认提交。具体展示与更新方式取决于消息平台能力，必要时也可跳转到受控业务页面。

任务中的草稿应有版本。用户重新上传合同、修改金额或更换项目后，旧草稿不能继续作为有效提交内容。确认动作应绑定具体任务及草稿版本。

卡片按钮只表达操作意图，后端仍需检查当前用户是否有权操作、任务是否处于允许状态、草稿版本是否有效。转发卡片或复制链接，不应转移办理权限。

会话文字如“可以”“收到”，不适合作为默认提交指令。正式提交应有明确动作，并展示即将使用的关键字段与目标流程。

五、提交接口要处理重复与结果不确定

用户重复点击、客户端重发和消息事件重投，都可能造成同一动作被多次接收。可以将任务、草稿版本和动作关联为业务幂等标识，由持久化状态与唯一约束共同控制。

提交前验证权限与草稿，记录提交意图，再调用业务接口；成功后保存业务单号及返回状态。幂等标识只负责识别重复动作，不负责证明操作人有权限。

需要特别处理接口超时：超时可能发生在业务系统已经受理之后，不能直接判断提交失败并再次创建申请。

若业务接口支持幂等请求或按外部请求号查询，应利用这些能力核对结果；不支持时，需要设计查询、人工确认或对账路径。结果不确定期间，可以阻止继续重复提交，向用户说明正在核对。

接口返回成功与审批通过不同。提交后生成的业务单号、审批节点及后续状态，应以OA等源系统为准。

将前面的解析、确认与提交环节连起来，可以用以下情况检查异常处理是否完整。

异常情况	处理思路
合同模糊或缺页	提示补充材料，保留未确认字段
供应商或项目重名	展示授权范围内的候选，由用户选择
用户确认了旧草稿	拒绝过期版本，重新展示当前草稿
重复点击提交	使用业务幂等标识，核对已有处理结果
提交接口超时	查询或对账确认结果，核对前阻止重复创建
审批事件重复或乱序	去重并结合事件版本、源系统状态或转换规则处理，避免旧状态覆盖新状态

表中是实现设计的检查项，具体恢复方式需结合业务接口能力确定。模型、接口或文件服务故障时，还应保留人工办理与问题处理入口。

六、审批状态回传，要同时检查事件与接收人

业务系统可通过事件通知，或在条件允许时由接入服务查询状态，将补材料、退回、流转和办结结果发送给获准接收的人员。

接收事件时，应验证来源，并处理重复、延迟及乱序情况。不能用较旧事件覆盖较新状态；如果事件没有足够版本信息，需要结合源系统查询或状态规则处理。

发通知之前，也要重新确定接收对象。申请人调岗、代理关系变化或事项转交后，不能永久沿用最初会话中的所有成员。合同摘要更不应因为处于同一群就对全群公开。

通知可以说明当前节点和必要信息，详情仍指向需要认证的页面。消息投递、已读、确认意见和业务办结，应分别记录和展示。

七、部署与审计覆盖AI处理链，而不只覆盖IM

IM服务器私有化部署，并不能证明模型、OCR、知识库或日志也在同一环境。项目应说明原文件、提取文本、检索内容、模型输入输出、缓存和备份的处理位置与留存方式。

有本地化要求时，应按具体方案核对依赖和访问路径。是否采用本地模型，与客户端在哪里运行是不同问题，不能混为一谈。

日志可以记录任务、资料版本、草稿修改、操作人、接口请求标识与结果，便于定位故障。合同原文、账户信息和访问令牌不应无差别进入普通运行日志，查询与导出也要受控。

检索权限、文件权限与业务写入权限需要分别检查。服务端执行动作时，应限制在当前用户和事项获准范围内，不能用机器人统一身份绕过用户授权。

八、接入企业即时通讯平台时，如何划分实施范围

小天互连是一套支持私有化部署的企业级即时通讯平台，可部署在企业内网、局域网或专有网络中，并作为连接人员、组织、消息、业务系统和AI能力的统一入口。

在此类设计中，可以结合小天互连的API、Webhook、SDK、机器人和自定义消息卡片等能力规划会话入口、草稿确认与状态通知。人员身份与既有账号体系衔接，AI处理服务负责解析及草稿生成，OA执行字段规则、流程授权并保存正式记录，接入服务协调接口调用与结果核对。具体事件、交互形式、授权及开发范围，需要按版本确认。

平台提供连接能力，不等于合同助手、字段映射与审批回传已全部交付。实施时应分别列出IM侧接入、文件解析、模型服务、知识资料、业务接口和运维责任。

建议先选择一种稳定表单，准备正常合同、模糊扫描件、缺失字段、同名供应商、权限变化、重复点击及接口超时等样本。关注字段纠错、人工修改、失败恢复和维护成本，而不是只看模型是否返回了一段流畅文字。

这类应用的落地标准，是资料有来源、草稿可修改、提交有授权、状态有依据、异常可恢复。将模型能力放进受控业务链，比让模型直接决定和执行全部操作更容易形成可维护的系统。