# 候选研发方向：业务流程的人工智能执行与验证框架 > 本文独立成篇，可单独送交评审阅读。文中所有背景、事实、方案与验收方法均已自含，不需要查阅其他材料。 > 本文只说明**要做什么、为什么这么做**，以及如何在十二个月内做完并验收。 --- ## 一、这个方向要做什么 研发一套**可独立部署、可配置、可验收的技术组件**，让人工智能的输出能够安全地变成业务系统里真实发生过的动作，并且事后能证明这个动作确实发生了、由谁负责、依据什么规则。 问题的起点是两种东西性质不同：人工智能给出的是概率性的文字，它不保存状态，不知道谁有权限，也不会因为自己说过「已处理」就真的改动了数据库；而业务流程要求结论确定、状态可查、责任到人、每一步有凭证。要把前者的能力用进后者，中间必须有一层明确的约束。本项目研发的正是这一层，包括四件事： 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. 独立评测样本的人工标注与复核安排。