01
Telegram → Approval → WordPress
现场验证真实现场消息进入 Gateway，进入同一个 FDE Runtime；当动作抵达外部写入边界时暂停，等待人类批准；批准后续跑，并在真实 WordPress 上产生副作用，同时留下 Run Receipt。
Proves:
- 现场渠道不是另一个 chatbot
- 普通思考和写作不需要伪造审批
- 真正的外部副作用可以暂停、批准、续跑
- 最终结果可以回到执行证据核验
ZUAEF · APPLIED AGENT ENGINEERING
真实运行，比宏大叙事更重要。
ZUAEF 是一个应用型 Agent 工程项目。我们记录智能体如何进入真实工作：它看到了什么上下文，做了什么判断，调用了哪些能力，什么时候把控制权交还给人，以及最后有什么证据能证明事情真的发生过。
这里不把架构图当成果，也不把模型的一句“完成了”当证据。你会看到真实链路、可复现的 Proof、Agent Console、工程实验、失败案例，以及因为没有改善结果而被删除的设计。
案例 · 系统 · 证据 · 研究
现场消息→CASE→决策→能力→人类边界→结果→执行证据
一条紧凑的证据链：现场输入、业务上下文、模型判断、能力、人类控制、结果与可检查证据。
站点职责
这不是一个销售站。
ZUAEF 负责证明“我们到底做过什么”。商业获客、Pilot、范围定义和客户交付属于 Stillevo AI。
这条边界是刻意的：ZUAEF 发布案例、当前系统、证据状态、失败与源码链接；Stillevo 负责服务、筛选、范围、报价和交付。
ZUAEF
案例 → 验证 → 系统 → 源码技术可信度、可复现性、限制与工程研究。
Stillevo AI
需求发现 → 范围 → Pilot → 交付在独立站点承接客户部署与商业工作。
先证明，再扩大叙事
先看真正跑过的链路。
架构图不是证据。模型说“完成了”也不是证据。ZUAEF 把最终产物、工具副作用、持久化 Step Facts 与 Run Receipt 当作“到底发生了什么”的执行记录。
02
跨轮业务上下文
已通过验证权威 proof harness 把一次对话绑定到真实 Case：第一轮要求根据此前客户背景和材料重写 demo，并暂不写价格；第二轮继续指出“开头还是太像 AI”，要求保留客户背景继续修改。
Proves:
- 下一轮可以继承必要业务上下文，不需要把所有历史重新塞进 prompt
- 上一轮 Agent 的行动轨迹不会被直接当成业务世界的事实
03
写作上下文真实传递
已通过垂直切片Writing vertical slice 已通过 Harness-neutral Context Delivery Proof：运行中的 Agent 会通过写作能力主动拉取真实材料与相关上下文，执行必要的 claim/evidence 检查，并保存真实产物及执行证据。
CAPABILITY PLANE
平台有这个能力，不代表模型每一轮都应该看到它。
ZUAEF 把经常被混在一起的四个状态拆开：
01
Available
平台具备这个原语或业务能力。
02
Authorized
当前部署被允许使用它。
03
Loaded
当前 step 里，它对模型可见。
04
Invoked
模型真的调用了它。
这个区分让业务能力可以持续扩展，而模型的初始 action space 不必同步膨胀。当前能力方向包括：
- Business Case 上下文
- 写作与编辑
- Research / Knowledge
- 客户服务与谈判判断
- 确定性预算分析
- WordPress 执行
- Telegram 现场交互
- Approval / Side Effect Control
- Run Evidence / Inspection
HUMAN ↔ AGENT
操作员需要的，不应该只是一个聊天气泡。
当一次 Agent 工作跨越多个 Request、Tool、Artifact、Approval 和客户上下文，仅有聊天窗口很难判断它到底做了什么、为什么变慢、哪里出了问题。
当前 ZUAEF Agent Console 已经提供：
- Run 列表
- 实时 Run Projection
- Trajectory 轨迹
- Event Inspector
- Artifact Bar
- 基于服务端 invalidation 的 LIVE 跟随
- 当人查看历史事件时自动暂停 live-follow，避免界面被不断拉走
下一层是 Run Analysis
把原始 Request / Tool / Context 轨迹变成可行动的解释——哪里最耗时、哪里重复、上下文在哪里膨胀、哪个能力加载了却没用、哪一步偏离了业务结果。这个方向最终指向更完整的 Human-Agent Workbench：对话、Case、材料、产物、批注、审批、Run Analysis 与人的纠正，在同一个工作面完成闭环。
Agent Console 已实现 · Run Analysis 开发中CONTROL WITHOUT FRICTION
内部工作自动完成，跨出边界之前再问人。
不是每一次“写入”都等同于高风险操作。读材料、思考、起草文章、改一个段落、保存工作产物、做预算分析，本身就是工作过程。如果这些动作都要求人逐项批准，Agent 最终只会变成一个自然语言表单。
ZUAEF 把审批放在真正有意义的地方：
内部工作
读取 · 研究 · 推理 · 起草 · 修改 · 分析 · 保存工作产物
默认自动执行
外部副作用
发送给客户 · 发布 · 修改生产数据 · 破坏性操作
按策略进入审批
这不是“完全自主”。它是一种更清楚的责任分工：模型负责判断行动，Host 负责确定性约束，人类负责关键边界上的授权。
工程原则
智能应该来自决策路径，而不是外围再叠几层系统。
ZUAEF 主动删除、拒绝过一批很诱人的抽象。
当前 Core 默认不需要：
- 每个业务域一个 Agent Class
- 自研 Graph Runtime
- 第二套 Checkpoint / Durable Runtime
- 自研长期 Memory Service
- 在 Retrieval Failure 发生之前就上 Vector DB
- 自研 Multi-Agent Orchestration Framework
- 第二套 Human Approval Engine
目标不是“仓库越小越好”，而是让一次运行结束后，我们仍能回答一个基本问题：哪些是模型的决定？哪些是 Host 的确定性约束？真实世界发生了什么？有什么证据能证明？