企业官网建设流程全解析

如果影子运行结束时只剩一个总体一致率，团队仍然很难定位差异，也很难据此决定是否放权。

根据 OpenAI 官方文档，2026 年 8 月 18 日，OpenAI 介绍了针对前沿网络安全能力模型的监控方案，其中包括对训练、评测和工具推理的监控，以及异常后的告警与暂停。

它描述的是前沿模型研究环境，不是企业部署可以直接照搬的 SLA。但有一层意思非常值得借鉴：监控不是上线后放在角落里的看板，它必须能触发复核、暂停和接管。

这正是很多 Agent“影子期”最容易缺掉的东西。

团队常说：“先跟着真实流量跑一段时间看看。”结果跑完只留下一个总体一致率，谁也说不清差异为什么发生、该改哪里、能不能放权。

因此，本文建议影子期交付一份能推动下一步动作的差异账本，而不只是一张漂亮的总分表。

同一份输入，必须留下两条结果

影子运行的核心很简单：真实业务仍由人处理，Agent 同时处理同一份输入，但它的结果不直接产生外部后果。

人工结果继续生效；Agent 的结果、依据、工具调用和是否选择升级，都进入记录。两份结果随后由明确的负责人比对。

重点不是“并行跑了多久”，而是每一次差异有没有留下可复查的原因。

例如，人把一条请求交给财务队列，Agent 交给售后队列。账本不能只写“分类错误”，还要写：当时看到了哪些字段、缺了什么、为什么没有升级、谁确认了正确结果。下一轮才知道应该补数据、改规则，还是缩小权限。

一张差异账本，至少留七个字段

如果只记录“人工答案”和“Agent 答案”，复盘很快会陷入争论。

更实用的差异账本至少包含：

1. 输入标识：能回到原始业务请求；
2. 人工结果：真正生效的处理；
3. Agent 结果：包括建议、动作和升级选择；
4. 依据：引用、规则版本和关键输入字段；
5. 差异类型：表达不同、漏信息、来源外新增、工具错误、升级错误；
6. 处理动作：补数据、改规则、加守卫、退权限或转人工；
7. 负责人和复测状态：谁改、什么时候用同类样本再跑。

这七列的价值在于，每一种差异都能落到后续动作。账本里如果只有“对/错”，复盘最后只能得到“继续优化”这种空结论。

把评审问题落成可检查材料时，可以先对照生产就绪检查项逐项写清数据、工具、验收和人工接管，再决定是否扩大动作范围。

不是所有不一致，都该算同一种错

影子期最容易误导人的指标就是总体一致率。因为它把不同严重程度的问题压成了一个数。

• 表达不同但结论等价：通常不需要改系统，可以留作风格观察；
• 结果更完整或更简洁：由业务负责人判断是否纳入规范，不能自动当成“更好”；
• 漏掉关键信息：检查输入字段、检索结果和提示边界，必要时改成强制升级；
• 增加来源中没有的信息：暂停相关能力，检查知识和输出守卫；
• 升级路径错误：该交给人时没有交，或者把本可处理的任务全推给人，需要调整规则和接管容量。

这五类可以作为起点，团队可以按自己的业务调整；关键是每一种分类都要对应处理动作。

先写谁看账本，再决定跑多久

影子期到底跑几天、多少条才够，没有脱离场景的统一答案。输入变化多不多、错误后果多大、负责人每天能复核多少条，都会改变所需范围。

比天数更早要确定三件事：

• 谁每天看差异；
• 什么问题一出现就暂停；
• 什么证据允许扩大范围。

OpenAI 在那份说明里提到 30 分钟级的告警和暂停要求。企业不应该机械复制这个数字，但应该复制它背后的结构：异常出现后，有明确时钟、明确负责人和明确暂停条件。

如果没人负责复核，跑得越久，只会积累越多无人处理的记录。如果停止条件只写“效果不好”，真正出现问题时仍然会争论。

影子期结束，不只剩“上”或“不上”

更常见、也更稳妥的结论是分项放权：

• 表达差异已经稳定的部分可以保留；
• 容易漏关键信息的类型继续影子；
• 来源外信息涉及的动作退回人工；
• 审计和接管已经跑顺的低风险动作，进入人工确认阶段。

差异账本可以进一步沉淀为验收样本、回归用例和升级规则。下一次模型、知识库或流程变化时，团队可以拿同一批边界样本重新检查，而不是重新凭感觉判断。

可直接带进评审的材料

差异账本可以先落成一张最小状态表。下面是字段结构示例，字段名可以换，但从定位到复测的链路不能断：

createtableagent_shadow_diff(input_reftextnotnull,human_result jsonbnotnull,agent_result jsonbnotnull,evidence jsonbnotnull,diff_typetextnotnull,remediationtext,ownertext,retest_statustextnotnulldefault'pending');createindexonagent_shadow_diff(diff_type,retest_status);

diff_type决定进入哪条修复队列，retest_status阻止“改完但没复测”的问题被总分平均掉。查询报表时可以聚合，但放行判断必须能下钻到input_ref。

差异账本可以直接对应一张状态表。新差异先进入待归因，负责人补齐输入、人工结果、Agent 结果和依据后，才能进入已分类；修复动作完成后进入待复测；只有同类边界样本通过，才标记为已关闭。没有负责人或没有复测记录的差异，不能被总体一致率“平均掉”。

差异类型也要避免写成一个宽泛的 error。表达不同、遗漏信息、来源外新增、工具失败和升级错误，需要进入不同处理队列。前两类可能只改提示或样本，来源外新增可能要求暂停相关能力，工具失败要回到状态和补偿设计，升级错误还要检查人工队列容量。

影子期真正可复用的是账本 schema、边界样本和状态转换。下一次更换模型、知识库或规则时，复用同一套记录和复测路径，才能判断变化来自哪里。

影子期结束时，管理者需要的不是一个漂亮总分，而是哪些动作能放、哪些继续观察、哪些必须退回人工的逐项结论。

官方文档核对：OpenAI 2026-08-18 官方说明。