Marico's space
最近折腾了一个挺有意思的问题：企业里文档改来改去，但一线员工还是按老办法干活。这个Gap怎么填？我把答案做成了一个叫 DRIFTZERO 的系统，这篇把背景和实现说清楚。
大企业对改文档这事很熟练。
新政策审批过了。
标准操作规程更新了。
工作流调整了。
培训邮件发出去了。
新版本正式生效了。
但问题是：第二天干活的人，可能执行的还是昨天的流程。
这个Gap，我称之为运营变革的最后一公里，也是 DRIFTZERO 要解决的核心问题。
本文是为 All Things Agentic Hackathon 创作的作品。
在线体验：
https://driftzero-web-eepb64ze2q-uc.a.run.app
演示视频：
https://youtu.be/d10dqIPcFHE
源码仓库：
https://github.com/jpablortiz96/driftzero
大多数企业变更系统能回答的问题都是：
这些当然重要。但这些都不是我最想知道的那个答案：
实际操作到底变了没有？
举个例子，包装工序的标签位置从左边改到了右上角：
LEFT
改成：
TOP_RIGHT
改文档容易，发通知也容易。但万一下一个包裹的标签还在左边呢？
变更在系统里存在了，但在现实世界里还没有。
这个区别，就是 DRIFTZERO 的出发点。
DRIFTZERO 是运营变革最后一公里的自主化执行系统。
核心工作流是这样的：
SOURCE CHANGE ↓
IMPACT ↓
ACTION ↓
FRONTLINE VERIFICATION ↓
CHANGE PROOF
文档变了不算完，DRIFTZERO 会追踪这个变更，直到拿到实际工作已经改变的证据。
公开 Pilot 用了一个简单但很物理的场景。
包装 SOP 变更了：
label_position LEFT → TOP_RIGHT
一个新的 DRIFTZERO 执行流程随即启动。
Gemini 3.5 Flash 解读新旧流程之间的语义差异。
Change Intelligence 提出哪些运营工件可能受影响。
这里有个重要的架构原则：
代理负责提议，真实引擎负责决策
语言模型不拥有运营真相。
它只负责提议。
一个确定性的 Truth Engine 验证这个提议的影响是否可以继续执行。
在 Pilot 中，只有一个授权目标被选中。
影响被验证后，DRIFTZERO 应用授权的修复措施。
工人不需要重新看一遍整个流程。
前线体验只传达变更的部分——Delta：
YOUR WORK HAS CHANGED Label position Was:
LEFT Now:
TOP RIGHT
这引出了产品另一个重要理念：
教 Delta，而不是教整个流程。
对于频繁变更运营的组织，反复培训整个流程会造成不必要的认知负担和运营开销。
DRIFTZERO 只关注实际变了什么。
这是 DRIFTZERO 和标准工作流自动化或 AI 聊天机器人真正不同的地方。
工人提交物理证据。
在公开 Pilot 中，我从电脑里手动选一张实物照片。
这张图片通过在线应用发送到私有后端。
Gemma 通过 Vertex AI MaaS 运行，执行新的推理。
第一张照片显示标签还在：
LEFT
Gemma 报告：
Observation: LEFT
但 Gemma 仍然不决定变更是否通过。
确定性的 Truth Engine 把观察结果和要求的运营状态做比较。
结果：
FAIL
工人看到：
Not done yet
关键点来了：
没有生成变更证明。
系统拒绝称这个变更为"已部署"。
现在工人去修正实际操作。
第二张不同的图片被选中并上传。
这不是重放。
不是缓存的通过。
不是特殊成功端点。
它触发了一次真实的 Gemma 推理，使用不同字节的图片。
Gemma 观察到：
TOP_RIGHT
Truth Engine 评估它。
结果：
PASS
工作流现在包含完整的时间线：
FAIL → PASS
失败的尝试仍然是历史的一部分。
DRIFTZERO 不会因为最终状态成功就重写现实。
修正后的物理状态通过验证后，Truth Engine 评估完整的完成契约。
在当前 Pilot 中：
7 / 7 conditions satisfied
只有这时 DRIFTZERO 才转换到：
PROOF_COMPLETE
然后生成新的变更证明。
变更证明把运营部署串联在一起。
它包含：
Source change Affected artifact Previous state → Current state Frontline delivery Verification chronology FAIL → PASS Completion timestamp Proof ID Content hash
这意味着最终结果不是简单地说：
"AI 说成功了。"
而是一条确定性的记录，把"什么变了"、"执行了什么"、"交付了什么"、"观察到了什么"、"为什么系统认为部署完成了"全部串联起来。
证明包含一个 SHA-256 内容哈希，是在对标准化的证明 JSON 计算得出的。
浏览器独立重新计算这个哈希，可以显示：
Content hash matches
这里有个精度问题需要说明。
这提供的是内容身份和完整性。
它不是：
精确说明技术不能证明什么，和描述它能证明什么同样重要。
DRIFTZERO 有意把语义智能和决策权威分开。
系统包含四个专门的代理职责：
Change Intelligence │ ▼
Remediation │ ▼
Frontline Enablement │ ▼
Field Verification
但权威性决策会跨越到一个确定性边界。
概念上：
┌─────────────────────┐ │ SOURCE CHANGE │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ Change Intelligence │ │ Gemini │ └──────────┬──────────┘ │ proposal ▼ ┌─────────────────────┐ │ TRUTH ENGINE │ │ deterministic │ └──────────┬──────────┘ │ ┌─────────────┴─────────────┐ ▼ ▼ Remediation Frontline Delta │ │ └─────────────┬─────────────┘ ▼ Physical Evidence │ ▼ ┌─────────────────────┐ │ Gemma │ │ physical observation│ └──────────┬──────────┘ │ observation ▼ ┌─────────────────────┐ │ TRUTH ENGINE │ │ FAIL / PASS │ └──────────┬──────────┘ │ ▼ CHANGE PROOF
架构原则是：
在存在模糊的地方用模型。
在需要权威的地方用确定性代码。
因为语言模型在解读模糊信息时非常有用。
但它不是我想要放置不可逆运营权威的地方。
在 DRIFTZERO 中，模型不能直接决定：
PASS
FAIL
PROOF_COMPLETE
authorization
workflow state
idempotency
supersession
proof generation
代理返回受限的观察和建议。
Truth Engine 拥有权威的状态转换。
这极大地缩小了幻觉的影响范围。
DRIFTZERO 运行在两个 Cloud Run 服务上：
PUBLIC INTERNET │ ▼
┌─────────────────────┐
│ driftzero-web │
│ Cloud Run PUBLIC │
└──────────┬──────────┘ │ │ Google-signed identity token │ ▼
┌─────────────────────┐
│ driftzero-api │
│ Cloud Run PRIVATE │
└──────────┬──────────┘ │ ┌─────┼──────────────┐ ▼ ▼ ▼ Firestore Pub/Sub Gemini / Gemma
公开的浏览器永远不会收到后端凭证。
driftzero-web 使用 Google 服务身份向 driftzero-api 认证。
运营 API 受到 Cloud Run IAM 保护。
用于代理编排和代理执行模型。
Change Intelligence 用它理解语义的流程变更。
用于多模态物理世界的观察。
Gemma 报告它看到了什么。
它不拥有判断权。
双服务部署：
driftzero-web → public experience
driftzero-api → private operational API
存储持久化的工作流和会话状态。
支持认证的事件摄入和有界的死信处理。
保持运营后端私有，提供服务器到服务器的身份认证。
托管的应用不是截图展示。
从未认证的浏览器，访问者可以：
RUN LIVE PILOT ↓
real Gemini inference ↓
receive the real delta ↓
upload a physical image ↓
real Gemma inference ↓
FAIL ↓
upload a second image ↓
new Gemma inference ↓
PASS ↓
7 / 7 ↓
new Change Proof
上传的两张 Pilot 图片包含不同字节，产生不同的验证事件，生成两次独立的模型调用。
最终工作流保留了：
verification #1 → FAIL
verification #2 → PASS
在同一个持久化工作流里。
可以试试：https://driftzero-web-eepb64ze2q-uc.a.run.app
让 Pilot 公开可访问不意味着让后端公开。
浏览器不能提供：
arbitrary prompts
model parameters
expected observations
PASS / FAIL
workflow IDs as mutation authority
proof results
源变更是服务端控制的。
上传有边界限制。
图片 MIME 类型从实际字节检测。
短期能力绑定到一个工作流。
后端保持私有。
这创造了一个狭窄的公开操作面，而不是暴露一个通用的 AI API。
构建 DRIFTZERO 过程中一个有趣的教训：真正持久化的代理系统需要的远不止"记忆"。
对于真实的运营工作流，持久化必须包含：
business state
agent session state
invocation identity
action execution identity
idempotency
verification chronology
proof conditions
否则，重启一个流程可能导致重复工作或不一致的真相。
DRIFTZERO 把失败和恢复作为架构的一部分，而不是事后添加的异常处理。
产品立意不是说 AI 神奇地消除了变更管理成本。
机会更具体。
DRIFTZERO 针对的是：
不必要的完整流程再培训
手动变更跟进
过期流程返工
运营采纳缓慢
现场漂移
审计证据收集
运营风险暴露
一个示例运营模型：
10,000 名员工
× 每年 8 次运营变更
× 20 分钟不必要的完整再培训 = 26,667 个工时暴露在再培训中
这只是一个建模练习，不是实测客户结果。
更大的价值方程式：
年度价值机会
=
避免的再培训
+ 避免的返工
+ 减少的跟进
+ 避免的变更事故
+ 审计效率
核心立意更简单：
教 Delta。验证现实。证明部署。
有三个教训比较突出。
当代理的权威边界明确时，它会变得更有用。
目标不是不惜代价追求自主。
目标是安全、有用的自主。
Gemma 可以解读一张物理图片。
Truth Engine 可以判断那个观察是否满足运营要求。
把这两个职责分开，系统更容易推理和审计。
执行身份、幂等性、动作状态和验证时间线同样重要。
代理架构需要能在进程替换后存活，而不盲目重复副作用。
DRIFTZERO 是一个可工作的云端 Pilot。
当前公开版本包括：
real Gemini inference
real Gemma multimodal inference
Google ADK
Cloud Run deployment
private operational backend
durable Firestore state
authenticated Pub/Sub
manual physical evidence upload
FAIL → PASS retry chronology
Change Proof
public source code
reproducible setup
1,999 passing automated tests
项目明确没有声称达到完整企业生产就绪。
一些企业平台能力需要组织级的前提条件，在 Hackathon 环境中无法获得。
与其模拟，我把这些限制公开记录了下来。
大多数企业系统能告诉你：
"流程改了。"
我想做的是回答一个更难的问题：
"实际操作变了没有？"
这就是 DRIFTZERO。
运营变革的自主化最后一公里。
本文是为 All Things Agentic Hackathon 创作的作品。
AllThingsAgenticHackathon