高校智能体如何建立人工复核机制？

定义：高校智能体的人工复核到底在复核什么

在高校语境里，人工复核是工作流里的强制门禁：系统先判断这次输出是只读查询、写操作，还是可能改变权益或对外口径的高风险回答；属于后两类的，必须由被授权的复核人在时限内查看对象、字段、影响范围和依据，做出放行、改写或驳回，并留下可检索记录。没有回执，动作不得生效。它服务的是可追责的事项，而不是给对话加一句免责声明。

复核对象至少要拆成三类，不能混成“重要的都看看”。第一类是查询。已发布且未过期的制度、办事指南、课表和培养方案，可以按身份和角色自动回复，但必须能指回现行文件，过期口径应拒答或转人工。第二类是写操作。成绩变更、学籍异动、发文、推送、账号开通、名单导出等会改库或外发的动作，智能体只能准备草稿和检查清单，正式提交必须回到原系统或经过确认台。第三类是高风险回答。即使不改库，只要答复可能被当成学校结论——例如超出已发文的政策解释、毕业资格预判、处分口径、面向家长的通知草稿——也必须等人确认。三类共用同一身份和日志，但闸门条件不同。

因此，建设对象不是一个“转人工”按钮皮肤，而是四件必须同时写进流程的东西：复核人、时限、留痕、升级路径。复核人回答谁有权对这一事项签字，且必须来自统一身份中的岗位或授权关系。时限回答多久必须处理，超时后状态如何变化。留痕回答事后能否按人、按时间和按事项回放。升级路径回答无人接单、意见争议或安全事件时转给谁、能否冻结助手。少任何一件，上线后都会变成“机器已回复、无人认账”。智能体总建设路径见高校智能体怎么建设，谁能提问、能看哪些知识、能否调写接口见高校智能体如何做权限控制，使用边界如何写进校内发文见高校生成式AI使用制度怎么写。

它不是什么

• 它不是把所有对话都转人工，把智能体退回人工客服排班表。
• 它不是信息化值班代替教务、学工、招就对业务口径签字。
• 它不是超时无人处理就默认通过，或由模型自评“置信度高”后放行。
• 它不是院系各自建微信群确认，校级平台没有队列、没有时限、没有日志。
• 它不是一次上线后不再抽查橡皮图章、不再复核离职账号和代理人。

人工复核也不是权限控制本身，更不是内容安全过滤本身。权限决定谁根本不该碰到这类知识和工具；过滤决定违法违规文本不得生成；复核决定授权范围内的关键动作和高风险回答，仍要由业务人员承担最后责任。三层应分开设计、分开验收，再在同一确认台汇合。更完整的对照摘要见高校AI智库 · 人工复核专题。

为什么高校不能让智能体全部自动回复

学校推进办事助手和业务智能体时，真正卡住追责的往往不是“会不会对话”，而是四类同时出现的业务问题。

第一，查询通道被当成执行通道。学生问缓考材料、教师问成绩录入规则、辅导员问资助名单，句子看起来都像咨询。如果助手把“查规则”和“改结果”“发通知”接在同一条可自动执行的链路上，一次流畅对话就可能写回教务库或群发家长。建设方案若只写“智能问答已开通”，却不写哪些输出可以自动发出、哪些必须停在草稿，上线后窗口人员和处室都无法认账。

第二，高风险回答没有门禁。即使不调用写接口，一句“按往年惯例你可以退学后复学”“你的学分已经够毕业”“这不属于处分”也会被截图传播。未发文政策、个案解释、心理危机和安全事件相关答复，风险不在技术难度，而在被当成学校结论。没有确认点，错误口径会以官方语气扩散，撤回成本高于人工多看一眼。

第三，复核责任悬空。信息化可以值守网关、账号、队列和接口失败，但不能代替招生办审宣传口径，不能代替教务处解释培养方案，不能代替学工判断资助材料是否齐全。若确认单都派给同一信息化值班号，白天能点、夜里无人、寒暑假无人，机制只存在于方案文本。复核人必须落到处室岗位，并准备代理人和升级对象。

第四，没有时限、留痕和升级，采购和验收都无法测试。招标书若只写“支持人工审核”“可转人工”，既不能在交付时复测，也容易把可抽查的确认台排除在外。学校需要的是：无确认不生效、超时不默认通过、升级有回执、管理员能按人和事项检索。提示词里的提醒、演示脚本里的一次点击，都不能代替这四条。

因此，机制设计应先回答：这个输出是查询、写操作还是高风险回答；谁必须看；多久必须处理；记录什么；没人处理时升到哪一级。五个问题都写进流程后，再接通模型和工具，而不是先铺全校入口再补值班表。实践中还常见三类偏差：全部自动回复以求“秒回”；全部转人工以求“零风险”却拖垮窗口；确认按钮可被工作流或演示账号自动点击。纠正这些偏差不需要先换更大模型，需要先补清单、岗位、时限和日志。权限叠加方法见高校智能体如何做权限控制，分角色披露与事故报告见高校生成式AI使用制度怎么写。

五步方法：从动作分类到抽测升级

复核机制可以展开为一条可重复链路。每一步都有输入和输出，下一步不得跳过上一步的责任确认。聊天界面和模型出现在第四步，而不是第一步。

第一步：把输出分成自动查询、写操作和高风险回答

对每个试点助手列出用户可能触发的输出，而不是只列菜单。已发布且有效的制度查询、公开招生文本、本人课表和办事材料清单，可标为自动回复，条件是能引用现行文件、越权拒答。凡改库、发文、推送、开通账号、导出名单的，标为写操作。凡不改库但可能被当成学校结论的，标为高风险回答。无法判断的，先按高风险处理，不得为了体验标成自动。

第二步：写出关键动作确认清单

清单按风险而不是按技术难度排列。每条写触发条件、展示给复核人的字段、禁止自动执行的参数，以及确认前在源系统中的状态。不要出现“视情况”“模型判断”这类无法验收的句子。读写必须拆开注册：只读工具不得接受更新类参数；写工具在确认前不得访问生产写接口。

第三步：指定复核人、时限、代理人和上班日历

每个清单条目映射到处室岗位，而不是个人微信号。写清主责、代理人、上班时段和寒暑假值班。时限按事项紧急程度分档，例如办事咨询草稿与学籍写回不应共用同一时限。代理人必须来自统一身份中的授权关系，不能在对话里自称上级或粘贴截图作为批示。

第四步：建设确认台，把留痕做成可检索字段

确认台要展示对象、字段、影响范围、依据和拟执行动作，并强制三选一：放行、改写后放行、驳回。回执号回写工作流后，写接口才能被调用。日志至少能回答谁在何时对哪一事项做了何种结论，以及是否超时升级。提问原文按密级保存，避免确认台变成第二套高密级库。

第五步：写升级路径并用真实样本抽测

超时、争议、跨处室和安全事件分别写升级对象与冻结条件。用双方签字的写操作样本和高风险原话复测：无确认源系统不变，超时保持草稿并产生升级单，管理员能按工号和事项检出记录。没有抽测通过，不要向全校开放写接口或对外口径助手。

比较：全部自动回复与关键动作人工确认

下表用于立项讨论，不构成唯一合法或唯一经济方案。具体学校还需对照网络安全、教育数据分类分级、生成式人工智能管理和校内信息公开、保密制度。两种策略可以在同一助手里并存：查询走自动，关键动作走确认。

选择时不要把“自动”理解成天然不负责，也不要把“人工确认”理解成天然安全。安全取决于分类是否写清、确认是否看见材料、超时是否升级、日志能否回放。一所学校可以对公开制度自动答、对成绩咨询只读本人字段、对写回和对外口径强制确认，但三类流量应汇入同一身份、同一确认台和同一日志体系。

关键动作确认清单：哪些必须停下来

确认清单解决的是“智能体可以准备，但不能代替签字”。列入清单的动作，在未收到授权人确认或原系统正式回执前，状态只能是草稿、待确认或已拒绝，不能变成已生效。学校应按处室改名，但不应把清单收成一句“重要事项需审核”。

• 学籍与成绩：成绩录入或修改、缓考补考结论写回、学籍异动、毕业资格预审结果写回、学位材料外传。
• 资助与评奖：困难认定意见、奖助发放名单、处分或撤销处分相关通知、评奖公示超出已发布名单的解释。
• 人事与组织：任免和考核结果相关答复、职称材料外传、教师个人敏感档案调取、跨部门人事名单导出。
• 对外口径：招生计划解释超出已发布文本、新闻通稿、校级通知、面向家长或用人单位的群发草稿。
• 账号与集成：开通高权限助手、扩写接口、向校外模型或未评估工具送原文、批量导出内部字段。
• 高风险回答：未发文政策的个案解释、可能被当成处分或毕业结论的判断、心理危机或安全事件相关答复、跨院系调取非工作对象名单。

每条清单应写清触发条件、确认人岗位、时限、超时处理和能否代理。确认界面必须展示对象范围，例如“将向 1 个学院 120 个已授权账号推送”，而不是只显示“发送通知”。影响范围无法计算时，应升级而不是让复核人在信息不全时放行。

复核人、时限、留痕和升级路径怎么写进流程

四要素必须写成可配置规则，而不是值班口头约定。规则变更本身也要留痕，避免学期中有人把时限改成零、把默认动作改成通过。

复核人：主责在业务，信息化只值守通道

主责按事项归口：招生宣传口径归招生部门，培养方案和成绩写回归教务，资助和处分归学工，就业推荐话术归招就，对外新闻归宣传，账号和出域归信息化与安全会签。信息化岗位可以是确认台管理员，负责派单堵塞、接口失败、助手冻结和日志导出，默认不拥有业务放行权。平台管理员能看到队列状态，不等于能点开学生原文或代替处室签字。

代理人用于请假、出差和寒暑假。代理关系从统一身份或已批准的授权表读取，设起止时间，到期自动失效。禁止在对话中粘贴“领导已同意”的截图作为确认凭证。多人会签时，应写清并行还是串行、缺一人是否阻断；全校推送、处分和学籍类事项缺人即阻断。

时限：分档书写，超时不得默认通过

时限要对应事项对用户的影响，而不是对应模型生成速度。公开咨询草稿可以按工作日计；涉及当天报到、考试安排变更的通知应按小时计；学籍成绩写回应服从原系统自身时限，智能体不得另开一条更快的自动通道。时限计算应避开已公布的处室休息日，但安全事件和泄露风险不受休息日保护，应走紧急升级。

超时后的合法状态只有三种：保持草稿并通知用户稍后、按升级路径转上级或值班处室、冻结该助手的自动工具。不存在第四种“视为同意”。日志须区分超时失败、主动驳回和升级后放行，以便抽查是否有人把超时改成通过。

留痕：能回放，而不是能下载全部对话

一条合格记录应能回答：谁提出、谁复核、有无代理、事项编码、对象范围、动作类型、到达时间、确认时间、结论、是否升级、回执号，以及当时的模型、提示词、知识和策略版本。管理员应能按工号、事项、结果类型组合查询，并导出本次结果且留下导出记录。不要把完整高密级原文默认写进可被宽表检索的日志区；取证用摘要、字段级快照和受控回放。

升级路径：无人、争议、跨处室、安全四类分开

• 无人接单：主责超时转代理人，代理人再超时转处室值班岗或分管负责人，同时对用户保持“处理中”而不是编造结果。
• 意见争议：复核人与拟稿不一致或用户申诉，转到原事项的上一级业务岗，必要时会签监察或学术组织，智能体不得自动采纳其中一方。
• 跨处室：同时触及教务与学工、招生与宣传的，按会签表走，缺一处回执不得外发。
• 安全事件：疑似泄露、越权批量导出、诱导越狱成功迹象，信息化与安全部门可立即冻结助手和写工具，再通知业务部门，不必等待原确认时限。

升级对象必须是身份系统中的岗位或角色组。每次升级产生新回执，旧单不得消失。对外话术预先写好，避免值班人员在升级过程中用个人判断继续自动回复。

建设步骤：输入、角色、动作与输出

下列步骤按时间顺序排列。每一步都写出输入、责任角色、动作和输出，便于写入项目计划和验收清单。角色名称可按学校处室调整，但不能出现“只有厂商、没有校内主责”。

1. 冻结场景并划分三类输出

动作：为每个助手标明可自动查询、必须确认的写操作、必须确认的高风险回答，以及暂缓上线的事项。输出：场景说明书、三类输出表和禁止自动执行列表。总序见高校智能体怎么建设。

2. 填写确认清单并映射岗位

动作：每条清单落到岗位而不是个人；写清时限分档和会签关系。输出：确认清单、岗位对照表、代理规则和上班日历。

3. 配置确认台、回执和源系统边界

动作：无回执不得调用写接口；能回原系统办理的，优先回原系统，智能体只保留草稿。输出：确认台说明、回执字段、与原系统的分工图。

4. 写下留痕字段、升级路径和对外话术

动作：把无人、争议、跨处室、安全四类升级写成可执行规则；制度中的人工审核要求与确认台对齐。输出：日志字段表、升级流程图、对外话术和冻结开关说明。制度写法见高校生成式AI使用制度怎么写。

5. 抽测、试运行与定期复核橡皮图章

动作：验证无确认不生效、超时不通过、升级有回执、检索可用；抽查放行单是否真的看过材料。输出：测试报告、缺陷单、抽查计划和是否扩大用户范围的决定。

某一步缺少输出物时，不要向全校开放写接口或对外口径助手，更不要把确认默认值设为通过。

验收与采购参数

验收应覆盖的条目

• 分类：抽测自动查询能引用现行文件；抽测写操作在无确认时源系统记录不变。
• 高风险：未发文口径、毕业或处分类判断、群发草稿在无确认时不对用户最终可见。
• 岗位：用非主责账号无法确认该条；过期代理关系不能签字。
• 时限：到达确认台后超过约定时间，状态变为超时失败或升级，而不是已放行。
• 升级：无人接单产生升级单；安全类样本能触发冻结；冻结后写工具不可用。
• 留痕：单条能看到复核人、结论、回执号和版本；导出本身留痕。
• 反橡皮图章：确认界面缺少对象或影响范围时不能提交；抽查放行单能对上材料。
• 文档：清单、岗位表、时限、升级图、日志字段和抽测集随系统移交。

验收必须使用双方签字确认的测试账号和样本，而不是厂商演示账号。未通过项应列出缺陷、责任方和复测时间。本文不提供、也不承认脱离测试条件的复核率、及时率或拦截率数字。

采购参数建议写成可测试语句

技术参数建议按“对象—条件—期望—证据”书写，例如：指定写操作在无回执时源系统记录不变；时限到期后状态为超时失败或已升级；管理员输入工号和事项编码能检出该条确认。不要写唯一品牌，也不要写无法验证的“智能审核”“自动质检通过率”。校级智能体与数据治理平台可以支撑确认台、权限审计和日志检索，但不能代替业务部门签字，也不是政策指定方案。