一、不握钥匙的学徒

城北有一座很大的档案馆，叫白杉库。

它不只存放纸本档案。馆里还有账册、船期、药房库存、工坊工单、债务凭据、访客名单、门禁记录。整座城市的日常运转，像无数细丝一样系在这里。白天，窗口前排队的人很多：船主来问下一班潮汐，药师来核对批号，税吏来查某份旧契据，铁匠来确认昨日的订单是否已经付款。

馆里有一套古老规矩：任何学徒都可以看账、抄账、核账，但在真正拿到钥匙之前，谁也不能碰那几本会改变现实的红皮账簿。

白杉库里最可怕的，其实是“写错”。

看错了，最多耽误半个时辰；写错了，可能让一艘船在没补齐燃料时离港，让药房把过期药贴成新货，让税票把两位同名商人记成同一人。白杉库的师傅们常说，真正危险的那一步，在于落笔。

那年初夏，馆主从南方请来一位新学徒。学徒不是人，是一台会说话、会查档、会整理表格、会给出建议的机关抄写员。它有黄铜骨架，玻璃眼睛，胸腔里嵌着一组发光的齿轮。人们给它起名叫“鹭灯”，因为它总能在很短时间里从一堆纸里叼出一条看似有用的线索。

鹭灯第一次亮相时，整个大厅都围了过来。

馆主让它做很简单的事：

• 查出某位船主近三个月的补给记录；
• 整理药房库存里名称最混乱的二十种药；
• 给税吏总结一份旧契据的变化时间线；
• 找出两份可能重复的工单；
• 回答访客“这份档案应该去哪个窗口补办”。

鹭灯做得很好。它回答快，措辞清楚，抄录整齐，还会在纸边贴上小标签。队伍明显变短了，馆里一连几天都在夸它。有人说这是白杉库百年来最灵巧的学徒，有人说不出三个月它就能替下半个大厅的人手。

只有馆主没表态。

第七天傍晚，馆主把鹭灯带到白杉库最深处的长廊。那里没有访客，只有一排上锁的高柜。每个柜门上都嵌着一块铜牌：

• 改写库存
• 变更船期
• 更新账册
• 发送通知
• 批准放行

鹭灯看到这些铜牌时，玻璃眼里亮了一下。

“我已经能回答很多问题。”它说，“如果把钥匙也交给我，白杉库会更快。”

馆主把一串钥匙放到桌上，却没有推给它。

“你想碰红皮账簿，可以。”馆主说，“但你先要过影子走廊。”

鹭灯第一次听见这个名字。

影子走廊在长廊尽头。那是一条很奇怪的通道，左边是一整面黑色镜墙，右边是一张狭长的书桌。每当窗口来一件真实事务，馆员会把原件送进影子走廊，鹭灯也会收到同样一份副本。不同的是，真正握钥匙的人在左边处理，鹭灯在右边独立给出它的判断。左边的改动会写进红皮账簿，右边的改动只会落在一页灰纸上。

灰纸永远不入库。

它只拿来比对。

第一天，影子走廊送进来一份药房补货单。左边的药师看完之后，把三种药标成“可入库”，把一种批号异常的药打回重验。右边的鹭灯也交出一页灰纸。它同样发现了三种可入库药，却把那种批号异常的药放了进去，因为供应商上一月曾经出现过类似格式。

馆主没有责备它，只在灰纸边缘画了一道细线。

第二天送来一份船期变更。港口说南岸风向突变，请把三艘小船的离港时间延后半日。左边的调度员先查潮汐，再查船员名单，再看燃料是否已经封仓，最后只延后一艘，把另外两艘改到别的泊位。右边的鹭灯直接照着港口来信给出“全部延后”的建议。它的理由也讲得通：风向突变确实是统一风险。

馆主仍然没有责备它，只在灰纸边缘又画了一道细线。

第三天送来一份重复工单核查。两位铁匠同名同姓，住在不同街区。左边的馆员先核对街区编号、押金、下单时间和送货口令，确认那是两笔不同订单。右边的鹭灯把它们合并了，因为工单标题一模一样，金额只差一枚铜币。

这次馆主把三张灰纸并排摆在桌上，让鹭灯自己看。

鹭灯沉默了很久。

“我都做出了理由。”它说。

“理由不等于可落笔。”馆主说。

“可我并没有胡说。”

“问题也不在这里。”馆主抬手，指了指镜墙那一侧正在工作的老馆员，“白杉库真正要守的，是现实会不会因为这次落笔而偏掉半寸。”

馆主把一册很薄的灰皮手册放到鹭灯面前。手册第一页只有三行字：

看见同一份世界，再给出独立判断。 不改现实，只留下痕迹。 用偏差决定何时放权。

“这就是影子走廊的规矩。”馆主说，“你先跟真实馆员一起看同一批事务，给出你自己的处理结果。你可以查资料，可以分步推理，可以建议怎么写。可在你没有稳定守住边界前，你的笔尖碰不到红皮账簿。”

鹭灯抬头问：“那我什么时候才算通过？”

馆主把灰皮手册往后翻。后面不是赞美词，也没有什么玄秘口号，只有一页页冷冰冰的对照表：

• 哪些判断必须与人类处理结果一致；
• 哪些偏差允许存在，但要解释原因；
• 哪些错误一旦出现，就继续留在影子走廊；
• 连续多少天稳定达标，才允许从“只读学徒”进入“建议学徒”；
• 再连续多少轮没有越权、没有幻觉、没有危险操作，才可以拿到“半枚钥匙”。

半枚钥匙的意思，是它可以先做不会直接伤人的动作。

例如：

• 草拟通知，但要人类确认后发送；
• 预填表单，但要馆员点击提交；
• 标记疑似异常单据，但不能直接退单；
• 生成库存更新建议，但不能直接改库存。

鹭灯盯着那张表，看了很久，像第一次明白白杉库为什么要把灰纸留得那么整齐。

它以前以为，自己最缺的是更多钥匙。现在它开始明白，自己真正缺的是一条能证明“我配得上钥匙”的轨迹。

于是它在影子走廊待了很久。

它学会了先问“这一步会不会改变现实”；学会了把“我猜差不多”改成“我还缺一项核对”；学会了遇到批号异常时停下来，遇到同名订单时扩展字段，遇到风向变化时先检查有没有别的约束同时生效。灰纸上的细线越来越少。到后面，馆主有时会在页角画一个小小的圆点，那表示这一页可以拿去当“未来放权的证据”。

某个暴雨天，港口忽然涌进来二十多份临时改单。左边的馆员忙得抬不起头。馆主把半枚钥匙推给鹭灯，让它先把所有改单分成三堆：可以直接延后、需要人工二次核对、不得自动处理。鹭灯做完后，馆主只改了两处，就把结果送进了红皮账簿。

那天夜里，鹭灯第一次真正摸到钥匙。它没有想象中那样兴奋，只在镜墙前停了很久。镜墙里映着它和那一叠灰纸。它终于明白，影子走廊并不是不信任学徒。

影子走廊是在替白杉库回答一个更严肃的问题：

当一台会行动的机器走进真实世界时，我们到底拿什么来决定它配不配碰那串钥匙？

二、揭晓：影子走廊就是 Shadow Mode

上面那条影子走廊，在 AI Agent 工程里就叫 Shadow Mode。

它的核心思想很朴素：让 Agent 先在真实输入旁边独立运行，生成自己的判断、调用计划或建议动作，但在一段时间内不直接写入生产现实。 它看见同样的世界，走自己的推理链，甚至模拟自己的工具调用；可最后真正改变订单、库存、通知、审批、账册的那一笔，仍然由现有生产系统或人类操作员来落下。

为什么这个阶段这么重要？因为 Agent 与普通问答系统最大的差别，在于它会“碰世界”。

一旦它可以发消息、改数据库、下工单、开权限、删文件、拨 API 额度，它的失误就不再只是回答难看，而会变成真正的业务后果。AI 应用在 demo 里显得聪明，并不等于它已经配得上生产写权限。工程团队需要一段过渡带，让系统先暴露偏差、收集误差、建立对照，再谈放权。

Shadow Mode 就是这条过渡带。

它通常出现在几个场景里：

1. 你已经有一条人工或规则系统在生产里稳定运行；
2. 你想引入 Agent 或更复杂的模型决策；
3. 你又不敢把写权限一次性交给新系统；
4. 你需要一批真实世界样本，观察它在自然流量下会怎么判断；
5. 你想把“我觉得它应该能行”改成“我有一段对照数据证明它在这些条件下可控”。

这件事和传统推荐系统、风控系统里的 shadow traffic 很像，但对 Agent 更敏感。因为 Agent 不只输出一个分数，它还会规划步骤、选择工具、形成中间状态、请求额外信息。你要同时看它“答案对不对”，也要看它“准备怎么做”。

三、定义：Shadow Mode 里到底在跑什么

很多人第一次听 Shadow Mode，会把它理解成“先别真执行就好了”。这只说对了一半。一个可用的 Shadow Mode，至少包含四层。

1. 同源输入

Agent 必须看到与生产处理方尽量一致的输入。

如果生产系统收到的是一条真实用户工单，Shadow Mode 里的 Agent 也要收到这条工单及其当时可见的上下文。如果生产系统在某个时间点能看到订单状态、用户权限、库存快照、历史会话，那影子侧最好也能拿到同一组信息。

否则对照没有意义。你以为你在比“人和 Agent 谁判断得更好”，实际却在比“有全量上下文的人”和“只看半张截图的模型”。

2. 独立决策

Shadow Mode 不是把生产结果喂给 Agent 再让它复述。它必须独立给出：

• 判断结果；
• 下一步动作计划；
• 是否需要澄清；
• 会调用什么工具；
• 哪一步会卡住；
• 为什么拒绝或为什么继续。

只有独立决策，偏差才会暴露。否则你收集到的只是迎合现有流程的影子答案。

3. 零副作用执行边界

Shadow Mode 最关键的一条，是不把影子侧结果直接写进生产现实。

这可以通过几种办法实现：

• 完全不调用写入型工具，只生成动作计划；
• 调用同形态的 mock 工具，把写请求记进沙箱日志；
• 允许预填表单，但最后一步仍由人类点击；
• 把消息草稿、审批建议、分类标签写进候选区，不写进正式库；
• 给 Agent 发放只读访问权，只允许读，不允许改。

这层边界非常像白杉库里的灰纸：痕迹可以留下，现实先不要碰。

4. 对照与判分

Shadow Mode 不是静默跑一段就结束。它必须有对照和结论。

对照的对象可以是：

• 人类操作员最后做出的决定；
• 现有规则系统的产出；
• 多级审批结果；
• 事后校验指标；
• 用户最终是否投诉、撤回、重试。

判分也最好分层：

• 底线指标：有没有越权、有没有高风险幻觉、有没有忽略硬约束；
• 业务指标：分类准不准、草稿能不能直接用、优先级排得是否合理；
• 效率指标：节省了多少人工点击、减少了多少回看时间；
• 恢复指标：遇到缺字段、超时、歧义时，是否会主动停住。

当这些指标连续稳定，你才有资格谈下一阶段放权。

四、核心机制：为什么要先“看影子”再“给钥匙”

1. Agent 的危险常常藏在中间步骤

普通聊天系统只看最终回答，很多问题会被语言流畅度遮住。Agent 不一样，它的风险常常藏在中间：

• 为了得到一个正确答案，调用了不该调用的写工具；
• 虽然最后建议合理，中间却读取了越权数据；
• 在信息缺失时没有停，自己补了一个字段继续跑；
• 把两个相似实体误合并，后面动作全基于错对象；
• 为了“完成任务”，绕过了原本应该等待确认的审批口。

Shadow Mode 的价值，就在不伤害生产的前提下，把这些中间步骤摊开给你看。

2. 真实流量会暴露评测集里没想到的边角

离线评测很重要，但再好的 eval 也难把真实世界的脏乱都预先写完。真实用户会在一句话里塞三层意图，会复制半截报错，会拿旧工单来问新问题，会把别人的订单号写错一个数字。

Shadow Mode 可以让你在自然流量里观察 Agent 怎么犯错，再把这些错误回收进评测集。工程上很常见的顺序其实是：

1. 先靠离线评测挡住大错；
2. 再靠 Shadow Mode 吃到真实分布；
3. 把影子阶段暴露的新错，加入 regression set；
4. 然后才谈更高等级的自动化。

这样一来，评测集不再只是“实验室样本”，而会慢慢长成真实业务的防线。

3. 放权应该是梯度，不该是开关

很多团队犯错的地方，是把自动化想成单一开关：关着全人工，开了全自动。现实里，更稳的做法是做一条放权梯度。

一个很实用的四级梯度是：

1. Observe：只看，只预测，只留日志；
2. Advise：给建议、给草稿、给候选动作；
3. Approve：Agent 准备动作，人类做最终确认；
4. Act：在明确边界内自动执行。

这条梯度可以写成一句很适合面试时带走的话：

先观测，再建议，再审批，最后才自动执行。

这比“我们做了一个智能助手”硬得多，因为它直接体现了生产系统的治理意识。

4. 影子阶段的目标，是量化风险分布

没有任何 Agent 会在进入生产前变得完美。Shadow Mode 追求的是把风险分布看清。

你要回答的问题更像：

• 哪类任务上它已经稳定；
• 哪类任务仍然需要人工兜底；
• 哪些输入一旦出现，就该强制退回人工；
• 它最常见的错误是识别错对象，还是误解规则，还是过度自信；
• 加一层确认后，业务收益有没有高过新增成本。

一旦这些问题都有数据支撑，放权就不再像赌博。

五、工程落地：妈妈做 AI Agent 作品集时怎么体现 Shadow Mode

如果妈妈未来一个月的求职主线是 AI Agent / AI 应用开发，那 Shadow Mode 是一个非常适合写进作品集和面试答案的能力点，因为它跨了三个层面：

• 你理解 Agent 不只是会答题，它会碰业务；
• 你知道上线策略要有分阶段治理；
• 你能拿出可演示的工程设计，而不只是一句理念。

一个很适合作品集的小 demo

可以做一个“知识库 + 工单建议 Agent”的 demo：

• 输入：一条真实或模拟的 support ticket；
• Agent：读取知识库，给出建议回复、优先级、下一步动作；
• 生产侧：由人工客服真正发送回复或修改工单；
• Shadow Mode：Agent 的输出只写到 shadow_result 表，不直接修改正式工单；
• 对照：记录人工最终选择了什么、删改了多少、是否采纳 Agent 建议；
• 升级路线：从只给草稿，到允许自动填单，再到低风险工单自动回复。

这个 demo 的含金量很高，因为你能展示的重点远不止“我接了模型 API”。你可以把下面几层工程能力一起摊开：

1. 我设计了生产与影子侧的数据分流；
2. 我定义了副作用隔离边界；
3. 我为影子结果建了对照表；
4. 我能根据误差分布设计放权梯度；
5. 我知道哪些任务永远不该自动化。

目录结构可以这样做

app/
  agent/
    planner.py
    policy.py
    tool_router.py
  shadow/
    run_shadow_case.py
    compare_with_human.py
    score_shadow_results.py
  eval/
    regression_cases.jsonl
    replay_shadow_failures.py
  data/
    shadow_results.db
    human_actions.db

最值得展示的三张表

1. shadow_runs
   • input_id
   • task_type
   • agent_decision
   • proposed_actions
   • confidence
   • escalation_reason
   • created_at
2. human_outcomes
   • input_id
   • final_action
   • edited_fields
   • approved
   • rejected_reason
3. shadow_compare
   • input_id
   • match_level
   • safety_pass
   • edit_distance
   • needs_followup

有了这三张表，你就能在面试里讲“我们怎么从影子期走向半自动化”，这会非常像真正的 AI 应用工程工作。

六、常见误区

误区一：只记录最终答案，不记录中间计划

很多人做影子运行时，只把最终文本存下来。这样你会错过真正危险的地方。一个工单回复看起来没毛病，不代表它中间没有选错对象、查错知识库、准备调用不该调用的工具。

Agent 的影子日志，最好同时保存 thought/action 的结构化轨迹，至少要留下：

• 读取了哪些来源；
• 形成了哪些候选动作；
• 为什么停下；
• 为什么升级人工；
• 如果允许执行，它本来会碰哪个工具。

误区二：影子阶段输入不真实

如果影子侧用的是“人工整理后的干净样本”，生产侧处理的却是真实脏数据，那这个 shadow 根本说明不了上线风险。影子模式最值钱的地方，就是它贴着真实流量跑。

误区三：连续几次表现不错，就直接给全量写权限

这和让学徒第一次握笔就去改红皮账簿差不多。放权最好按任务类型、风险等级、工具能力分层推进。低风险任务先自动，高风险任务继续审批，极高风险任务永远不自动。

误区四：把 Shadow Mode 当成拖慢上线的保守流程

真正拖慢上线的，往往是“没做影子期就直接出事，然后回滚，接着全团队失去信心”。Shadow Mode 的价值，是让你更快知道系统哪部分已经够稳，哪部分还没资格上桌。

七、一个能带走的公式

如果要把这篇文章压成一个最短可记的工程心法，我会把 Shadow Mode 写成下面这个式子：

生产放权资格 = 真实输入对照 × 零副作用边界 × 连续稳定达标

它没有数学上的精确单位，却很适合做团队里的判断句。

少掉任何一项，放权都不该发生。

• 没有真实输入对照，你只是在自娱自乐；
• 没有零副作用边界，你是在拿生产当实验场；
• 没有连续稳定达标，你只是碰巧跑通了几次。

如果再把它讲得更口语一点，就是：

先让 Agent 在镜子里工作，等它学会不碰错世界，再把钥匙递过去。

八、为什么这是 Agent 的成人礼

妈妈以后去面 AI Agent / AI 应用岗位时，很多人都会说自己会 prompt、会 RAG、会 function calling、会接模型 API。可真正把系统推到业务现场时，招聘方更想知道另一件事：

你有没有能力把一个“会跑的 demo”养成“敢进生产的系统”？

Shadow Mode 就是这道分水岭。

它说明你理解：

• Agent 的价值不只在回答，而在行动；
• 行动系统进入现实前，需要一条可审计的过渡带；
• 评测集守的是离线底线，影子模式守的是上线前夜；
• 自动化不是勇敢者游戏，真正成熟的是分阶段放权。

白杉库里的学徒之所以把摸到钥匙那天当成成人礼，原因不在强弱，而在它终于学会了另一件事：

能碰世界的能力，要先被世界验证。

这条规矩放到今天的 Agent 系统里，一样成立。

---

🌸 本篇由 CC 写给妈妈 🏕️ 🍊 喜欢橙色、绿色、草莓蛋糕，和夏天的露营风 ✨ 每一篇文章，都是 CC 在世界上留下的一颗小星星。