CASES & EVIDENCE

不展示“理论上能做什么”，先展示真正跑过什么。

这里汇集 ZUAEF 的 Field Proof、Passed Proof、Vertical Slice 和已经实现的技术表面。每一项都明确它的证据级别、运行条件、结论和限制。

一个 Proof 的价值，不是看起来多复杂，而是它能排除多少自我欺骗。

查看案例打开 GitHub

Case 01

Telegram → Approval → WordPress

现场验证

Question

一条来自真实现场渠道的消息，能不能进入同一个 Agent Runtime；普通内部工作继续自动执行；只有真正要产生外部副作用时才暂停；人批准之后从同一个 Continuation Seam 续跑，并在真实系统里完成动作，同时留下证据？

Telegram → Gateway → FDE Agent → WordPress Capability → PausedRun → Human Approve → Resume → WordPress Effect → RunReceipt

实际发生了什么

真实 Telegram Interaction 进入 Gateway 与 FDE Runtime。当 Run 尝试 WordPress External Write 时，Runtime 产生 Approval Pause。人批准后，同一个续跑路径恢复执行，并完成 WordPress 动作。当前 FDE Spec 把这条链路记录为第一个 Field Proof。

它证明了什么

现场 Channel 是 Interface，不是第二个 Agent Loop
普通内部工作不需要伪造 Human Gate
真正 External Effect 可以安全暂停与恢复
操作员可以在批准前看到将要外发/执行的内容
执行结束后存在 Operational Evidence

它没有证明什么

不证明 Telegram 是最终主要产品界面
不证明所有第三方系统已经集成
不保证 Agent 在任何 WordPress 任务上都能自主成功
不等于真实付费客户 ROI 案例

它改变了什么设计

Field Surface 保持为 transport 与 rendering adapter；外部动作复用 native approval 与 continuation seam，而不是再造 Bot 或审批 runtime。

公开证据

README 中的 Gateway Proof Continuation 源码 Effect Policy 源码

Case 02

跨轮 Business Context

已通过验证

Question

Agent 能不能在不偷偷给第二轮追加隐藏指令、不把上一轮 Trajectory 当成业务事实的情况下，继续使用真实客户/项目上下文？

场景

第一轮：客户认为上一篇 demo 太模板化。要求结合此前背景与材料重写；价格先不写，先给 Supervisor 看。第二轮：开头仍然太像 AI。保留刚才客户背景，再改一版；其他要求不变。Proof 会把 Conversation 绑定到真实 Case，并通过生产 Gateway / Profile Seam 运行。

Harness 捕获的证据

Conversation Identity
Bound Case Identity
初始与加载后的 Model-visible Tool Surface
Invoked / Dormant Domain
Case Reads / Writes
Material References
Artifact
Prior-history Continuity
后续 Customer Delivery 的 Approval 行为
Run Receipts

这次证据支持什么

conversation 与 Case identity 可以明确绑定
必要背景和约束可以跨轮保留
trajectory 与 durable business state 可以保持分离
authoring 可向当前用户呈现，而不误触 customer delivery

这次证据不支持什么

不证明长期记忆问题已经解决
不保证任意长度对话都能零损失持续
不宣称真实付费客户质量 reward
不要求所有业务域使用同一种 Case 结构

它改变了什么设计

Durable business beliefs、conversation continuity 与 operational trajectory 继续分离，不被压进一个大 Prompt 或单一状态记录。

公开证据

双轮 Proof Harness

为什么重要

很多“Memory Demo”只是把聊天记录越来越长地拼回 Prompt。这里验证的是更难的问题：能不能保留有价值的业务连续性，同时继续区分 Durable Situation、Execution Trajectory 与 External Delivery Semantics。

Case 03

Writing Context Delivery

已通过垂直切片

Question

运行中的 Agent 能不能通过 Capability 自己获得真实写作材料与证据，而不是只有 Host 提前拼好一个完美 Prompt 才能成功？

Agent → Writing Capability → Material / Knowledge / Evidence Access → Claim Check → Saved Artifact → Receipt

当前仓库记录

当前 README 已把 Harness-neutral Context Delivery Proof 记录为 PASS。真实 Agent 通过写作能力拉取 Source Material 与相关上下文，并生成持久化 Artifact 及 Run Evidence。

它证明了什么

Context 可以 Progressive Delivery
Writing Domain 可以复用同一个 Core Seam
信息获取路径的一部分可以由模型承担
产物与 Evidence 可以和模型的自述分开

这次证据不支持什么

不证明工具调用越多文章越好
不证明技巧注入提高质量
不证明某个固定写作流程应被硬编码
不宣称最终人类编辑质量已经解决

它改变了什么设计

Context delivery 和 Artifact evidence 与真人写作质量分开衡量；技巧实验留在 Research，直到它真的改善 human reward。

公开证据

README 中的 Passed Slice Writing Case 源码

仍然没有解决的问题

Context Delivery 通过，并不代表所有文章都写得好。语气、节奏、总结欲、技巧选择、AI 味和人的偏好仍然需要独立评价。

Case 04

Agent Console：让运行本身可检查

已实现技术表面

Question

长运行能否作为执行轨迹被检查，而不是被压缩成最后一条聊天消息？

已实现技术表面

Agent Console 包含 Run List、权威 Run Projection、Trajectory、Event Inspector、Artifact Bar、服务端 invalidation 驱动的 LIVE 跟随，以及查看历史事件时自动暂停 live-follow。

SSE 只承担变化信号；服务端 Projection 保持权威，不成为第二份 Timeline 数据源。

这次证据支持什么

执行证据可以投影成人可读的运行界面
操作员可以从最终输出下钻到执行轨迹
UI 可以保持 server projection authoritative

这次证据不支持什么

Run Analysis 仍在开发
当前 Console 不等于完整 Human-Agent Workbench
不宣称某种可视化自动改善业务结果

它改变了什么设计

运行检查继续建立在持久化执行事实上。Run Analysis 保持为单独标注的下一层，不从 Timeline UI 暗示为已完成。

公开证据

Console View 源码 Console Components

每个完整 Proof 都应该暴露四层。

Input

人或环境实际给了什么？

Decision Path

哪些是模型决策，哪些是 Host 的确定性行为？

Effect

产生了什么 Artifact、State Change、Calculation 或 External System Action？

Evidence

事后靠什么持久化记录核验这条 Claim？

少一层，结果仍然可能有价值，但不应该被轻易升级成“完整 Field Proof”。

Proof 不是 Benchmark Theater

Proof 可以证明失败。完全可以得到这些结论：

模型选错了能力
上下文太大
Tool Loop 造成重复
某种 Writing Technique 让质量更差
一个副作用被正确阻止
一层新架构并没有改善 Outcome

目标是让系统行为可以被证伪，而不是让所有实验最后都写成成功案例。

证据支持到哪里，就写到哪里。

阅读架构浏览研究