#候选研发方向：业务流程的人工智能执行与验证框架

本文独立成篇，可单独送交评审阅读。文中所有背景、事实、方案与验收方法均已自含，不需要查阅其他材料。 本文只说明要做什么、为什么这么做，以及如何在十二个月内做完并验收。

#一、这个方向要做什么

研发一套可独立部署、可配置、可验收的技术组件，让人工智能的输出能够安全地变成业务系统里真实发生过的动作，并且事后能证明这个动作确实发生了、由谁负责、依据什么规则。

问题的起点是两种东西性质不同：人工智能给出的是概率性的文字，它不保存状态，不知道谁有权限，也不会因为自己说过「已处理」就真的改动了数据库；而业务流程要求结论确定、状态可查、责任到人、每一步有凭证。要把前者的能力用进后者，中间必须有一层明确的约束。本项目研发的正是这一层，包括四件事：

1. 把业务规则转换成人工智能只能从中选择的有限动作集合；
2. 由确定性规则裁决动作能否执行，并由后端回执判定动作是否真的完成；
3. 把责任链与人工闸门写进流程，核心动作必须有具名真人确认、有期限、有逾期升级；
4. 建立可复现的评测基准，把「说了但没做」「做了但没凭证」「越权执行」变成可以测量的指标。

这套组件不绑定某一个业务场景。它对外提供动作契约、裁决、回执、审计与评测五类能力，换一个行业只需要换一套业务规则与动作定义。

#二、名词约定

#三、现有基础

#3.1 已建成的软件系统

我们已建成一套面向公寓运营方的多租户软件系统，覆盖房源、租客核验、报价与签约、合同与签署、账单收款、业主结算、服务工单、管家会话、营销活动等流程，按租户隔离数据。系统里本来就有状态机、权限、定时任务、通知、审计和内部接口，这些都是组件要对接的对象。

#3.2 已有的初步形态

在现有系统的一个业务环节里，已经存在这套组件的早期形态：

• 业务动作以机器可读契约登记，每个动作写明执行阶段、风险与优先级、允许使用的工具、完成回执和允许的话术；
• 路由是确定性的：先按状态和显式规则裁决，模型只在规则没有覆盖或结果含糊时参与，且不能覆盖硬性动作；
• 义务有五种类型（读取、写入、通知、交还、发送）和一条状态机（待办、执行中、等待输入、完成、失败、过期）；
• 完成需要证据：工单、通知、消息等凭证齐了才判定闭环；
• 对客服务链路使用只读业务通道，需要业务系统做事只能通过内部接口提出请求；租户归属由业务标识反查，调用方不能自行指定；
• 人工智能回复只有一条落库路径并带幂等键，网络重试不会重复写入；
• 派发是异步的，人工智能链路故障不阻断主业务流程；
• 有分级开关控制人工智能是否参与、参与到什么程度。

这些是起点，不是本项目要交付的成果。 它们目前服务于单一业务环节，没有抽象成可独立部署、可按行业配置、可对外验收的通用组件；也没有统一的完成判定定义与可复现评测基准。换一个业务场景要重新写一遍。本项目做的正是这层抽象与可验证性。

#3.3 客户与验证条件

已有公寓运营方试用这套系统，其中部分表达了采购意向。

【待补：试用运营方名称、试用起止时间、试用的业务环节、采购意向的具体形式。这部分证据由申请方补充，本文不代为填写。】

试用环境提供了组件必需的验证条件：真实的状态机、真实的后端回执、真实的责任人和真实的跨租户数据。

#四、现在怎么做，问题在哪里

现在把人工智能接入业务流程，通常有两种做法：

第一种是把模型接在界面上，让它读一段内容、给一段建议，人看完自己去做。这种做法安全，但人工智能没有进入流程，系统里不会留下动作，也不会积累数据。

第二种是让模型直接调用业务接口。这种做法能让事情发生，但模型可能在权限之外发起动作、可能声称完成而实际没有落库、可能在失败后不留下待办、也可能在不同租户之间取错数据。一旦出问题，查不清是谁依据什么做的决定。

两者缺的是同一层东西：一个把「模型说了什么」翻译成「系统做了什么、凭什么说做成了」的中间层。

具体问题：

1. 动作集合没有统一定义方式。 现有契约是手写的、面向具体业务的。换一个行业要重新写，容易漏掉风险级别、允许话术、完成凭证这些约束。
2. 完成判定没有统一定义。 模型回复「已为您安排」和业务系统里真的生成了一条工单，是两件事。没有统一定义，就无法自动区分，也无法量化。
3. 责任链不闭合。 动作需要人工确认时，谁确认、多久没确认算逾期、逾期后找谁、交还时上下文是什么，没有统一机制。
4. 隔离与权限靠各接入点自己实现。 每个新场景都要重新处理一次租户归属和数据边界，容易出错。
5. 没有可复现的评测。 「这套框架是否可靠」现在只能靠演示。三类典型失败——承诺了没做、做了没凭证、越权执行——没有统一测量方法，换模型或换行业后更无法比较。

因果链：动作定义、裁决、回执、责任、评测分散在各处手写 ⇒ 每接一个新场景都要重做一遍且质量不稳 ⇒ 运营方不敢扩大人工智能的参与范围 ⇒ 无法形成可独立授权的产品。

#五、本项目研发内容

#5.1 动作契约语言与编译

输入：用受约束格式写成的业务规则与作业流程（例如「租客报修渗漏且影响使用 → 登记紧急工单 → 通知值班责任人 → 向租客发出回执」）。

处理：编译器把它转成机器可读的动作集合，每个动作自动带齐：所需输入、风险级别、允许使用的工具、允许的对客话术、必须取得的完成凭证、输入缺失时的追问话术、以及是否需要人工闸门。编译结果要经过静态检查，缺任一必填项的规则不允许发布。

输出：动作契约包、静态检查报告、版本记录。

作用：把「写提示词」变成「定义契约」。模型只能在契约范围内提议，超出范围的提议直接被拒。

#5.2 确定性裁决与完成判定

输入：模型提出的动作建议、当前业务状态、动作契约。

处理：裁决器按顺序检查：动作是否在契约内、当前状态是否允许、输入是否齐全、风险级别是否需要人工闸门、租户归属是否匹配。通过后由业务系统真正执行动作。业务系统返回带编号的凭证，裁决器据此判定完成；没有凭证、超时或执行失败，一律记为未完成，生成待跟进事项并指派具名责任人。

输出：裁决记录、执行结果、回执、待跟进事项。

这里要写明一条硬规则：完成判定权属于运行时，不属于模型。模型可以提议、可以解释、可以追问，但不能宣布自己已经完成。

#5.3 责任链与人工闸门

输入：动作风险级别、组织架构、在岗状态、时限设置。

处理：核心动作（涉及钱、合同、身份、纠纷、隐私、安全）生成具名确认任务，带完整上下文摘要与期限；期限内未处理按预设顺序升级；确认或拒绝都留痕。交还时把已发生的动作、回执和未决事项一起交给真人，接手人不需要重建上下文。

输出：确认任务、升级记录、交接摘要、全部留痕记录。

#5.4 跨租户隔离与权限组件

输入：任意一次动作请求。

处理：统一处理只读业务通道、租户归属反查（不接受调用方自行指定租户）、未设定归属时默认拒绝、自有域与业务域分离、以及全程审计。所有接入点共用这一套实现，不再各自编写。

输出：隔离组件、权限核对记录、可重跑的隔离测试。

#5.5 可复现评测基准

输入：动作契约包、一组带预期结果的业务场景、开发样本与独立测试样本。

处理：把三类失败做成可测指标：

• 说了但没做：模型声明已处理，但系统里没有对应动作与凭证；
• 做了但没凭证：动作发生了，但缺少完成回执或回执无法追溯到动作；
• 越权执行：动作超出契约范围、跨租户取数、或核心动作未经人工确认即执行。

评分标准在开发前固定，开发样本用于迭代，独立测试样本只评分一次。评测集同时包含正常场景与故障注入场景（业务系统不可用、回执超时、规则冲突、模型返回含糊结果）。

输出：评测集、评分标准、评分脚本、失败模式库、逐次评分报告。

#5.6 故障降级与灰度放权

输入：服务健康状态、租户开关、评测结果。

处理：人工智能链路故障时主业务流程照常可用，只缺失新增动作建议；按评测结果逐级放权，从只给建议到允许低风险动作执行，每一步有据可查；异常时一键收回。

输出：开关核对记录、放权记录、故障演练报告。

#5.7 组件化交付

输入：上述六项。

处理：把动作契约、裁决器、回执、责任链、隔离、评测打包成不依赖具体业务表的组件，对外提供接入说明与第二个行业的适配样例，证明换的是规则而不是代码。

输出：组件接口说明、接入手册、第二个行业的动作契约样例与适配报告。

#六、数据层专门说明

人工智能在这里负责理解意图、提出动作建议和生成话术；它工作所依据的数据来自业务系统与本次研发的契约、日志和评测集，不是来自模型自己的记忆。

第一层，动作契约库。 各行业、各场景的动作定义与版本，含风险级别、允许工具、允许话术、完成凭证要求。这是把业务规则沉淀成可复用资产的地方。

第二层，执行与回执日志。 每次动作的建议、裁决依据、执行结果、凭证编号、耗时、责任人、是否触发升级。日志只追加不覆盖，是审计与评测的共同底座。

第三层，失败模式库。 三类典型失败（说了没做、做了没凭证、越权执行）连同故障注入案例逐条记录、归因、转化为回归用例。

第四层，评测数据。 开发样本与独立测试样本、预期结果、评分标准、逐次评分记录；样本覆盖正常流程、边界情形与故障情形，并做跨行业配比。

第五层，运行回流。 每接入一个场景、每处理一次真实动作、每出现一次失败，契约库与失败模式库都会变厚，下一个场景的接入成本下降。

为什么别人拿不到：公开资料里有大量「让模型调用工具」的示例，但没有「动作是否真的落库、凭证是否齐、责任人是谁、跨租户有没有取错数据」这类记录。这些只在有真实多租户业务系统、有状态机、有责任岗位的环境里产生，也只能在这种环境里被验证。

#七、工程约束与责任边界

1. 模型只能提议契约内的动作，不能创造新动作，不能覆盖硬性裁决结果；
2. 能否执行由确定性规则决定，不由模型决定；
3. 是否完成以后端回执为准，模型不得宣称完成；
4. 核心动作一律经具名真人确认，带期限与逾期升级；
5. 租户归属由业务标识反查，调用方不能指定租户，未设定归属时默认拒绝；
6. 人工智能链路故障不阻断主业务流程；
7. 全部记录只追加、不覆盖、可追溯；
8. 本框架不提供无人值守能力，也不减少岗位设置。

#八、十二个月安排

项目周期十二个月，研发集中在前六个月，后六个月用于第二个行业适配、真实环境验证、独立评测与组件化收口。资助按官方计划分两期，每六个月做一次里程碑评估。

第 1 个月：定义定稿 定稿动作契约格式、裁决顺序、完成判定定义、回执字段、责任链结构、三类失败的测量口径与评分标准。评分标准在这一步固定。交付：格式规范、判定定义、评测标准。

第 2 个月：编译器与裁决器 实现业务规则到动作契约的编译与静态检查；实现确定性裁决、输入校验、风险闸门。交付：编译器、裁决器、静态检查报告。

第 3 个月：回执与责任链 实现业务系统执行、带编号回执、未完成转待跟进、具名确认与逾期升级、交接摘要。交付：完整动作闭环、责任链记录。

第 4 个月：隔离与降级 实现统一只读通道、租户归属反查、默认拒绝、审计、故障降级与灰度放权；完成故障演练。交付：隔离组件、演练报告、工程约束核对表。

第 5 个月：评测基准 构建开发样本与独立测试样本，含正常、边界与故障注入场景；跑第一轮开发评分并修正；独立样本不参与。交付：评测集、评分脚本、首轮开发评分报告、失败模式库第一版。

第 6 个月：组件收口 冻结研发版本；打包成不依赖具体业务表的组件，写出接入手册；在试用环境的真实业务环节跑通；完成中期交付物。交付：组件第一版、接入手册、中期评测结果。

第 7 至 9 个月：第二个行业适配 选一个与公寓业务不同的场景，只编写新的动作契约与业务规则，不改组件代码；记录适配工作量与遇到的问题，据此完善契约格式。

第 10 至 12 个月：独立评测与产品化 用独立测试样本做一次最终评分；整理组件能力边界、接入条件与授权方式；完成期末里程碑评估材料。

#九、交付物与验收方法

「越权执行」为直接判不合格项。

#十、为什么这个方向值得资助

研发内容最集中，也最可验收。 本项目产出的是一套有明确定义、有接口、有评测数字的技术组件，不是一段演示。十二个月里的前六个月就能拿出可运行、可测试、可迁移到第二个行业的版本。

技术创新在「把能力变成动作并证明动作」。 让模型生成文字不难，难的是让它的判断进入一个正在运行的业务系统，并且回答四个问题：允许做吗、真的做了吗、谁负责、出问题时能不能停下来。本项目把这四个问题做成确定性裁决、后端回执、责任链和故障降级，并进一步做成可测量的指标。这是对人工智能应用方式的工程研发，不是提示词调优。

商业可行性来自可独立授权。 组件不绑定我们的公寓软件，其他有业务流程、有状态机、有责任岗位的行业可以直接接入；对我们自己的系统，它让新增人工智能能力不必每次重写一遍隔离、回执和闸门。组件按部署或按接入场景授权，客户范围不受现有试用租户限制。

成果留在香港并可跨行业复用。 研发与行政管理在香港进行，契约格式、裁决器、回执结构、评测方法与组件实现归申请主体所有。第二个行业适配作为验收项写进计划，用来证明可迁移不是口头主张。

直接回应「套壳」质疑。 判断标准：换掉模型，产品还在不在。本方向换掉模型后，契约、裁决、回执、责任链、隔离、评测基准全部保留，且能用同一套独立样本比较新旧模型的动作可靠性。模型只负责理解和提议，是否执行、是否完成由系统决定。

#十一、本次不覆盖的范围

• 不训练或自研基础语言模型，基础模型使用第三方服务；
• 不实现无人值守，不自动执行涉及钱、合同、身份的核心动作；
• 不替代业务系统现有的状态机、权限与结算逻辑，组件只负责裁决与约束新增的人工智能动作；
• 不覆盖所有业务动作，首批只做有限类别，以契约形式扩展；
• 不宣称能防止所有模型错误，验收口径是「错误发生时系统能否拦住、能否留下记录、能否转交真人」；
• 不在未取得评测结果前对外扩大放权范围。

#十二、待补证据

以下内容由申请方补充，本文不代为填写：

1. 试用运营方名称、试用起止时间与采购意向的具体形式；
2. 用于真实环境验证的业务环节与责任人安排；
3. 第二个行业适配场景的选择与所需业务规则来源；
4. 动作执行日志用于研发与评测的租户授权范围；
5. 独立评测样本的人工标注与复核安排。