围绕决策循环保持轻量。

六层架构

Decision Loop 是中心。其余各层只负责让它看得见、做得到、受约束、可验证。

Layer 1 — Field Interface

让 Agent 出现在工作真正发生的入口。

• Transport
• Identity / Allowlist
• Session / Conversation Routing
• Case Binding
• Inbound Normalization
• Normal Reply Presentation
• Approval UI
• Continuation Callback

Field Interface 不得拥有第二个 Agent Loop。

Telegram 是当前已验证 Surface。未来 Feishu、Slack、WeCom Adapter 如果需要修改 Decision Loop、Case Semantics、Approval Boundary 才能接入，说明 Surface 抽象已经失败。

Layer 2 — Business Context

告诉 Agent“我现在进入的是哪个真实业务现场”。

Case 可以承载受控的 Durable State，例如：

• Customer / Project Identity
• Goal 与 Current Situation
• 相关 Resource / Material Reference
• Operator Correction
• Policy Override
• 其他经过验证的 Business Belief

系统不能因为“Agent 尝试过 X”，就自动认为“X 已经成为现实”。Trajectory 是 Execution Evidence；Durable Situation 是经过单独校验的业务世界视图。

Layer 3 — FDE Decision Loop

承担业务结果。

模型应该待在这里，因为真正无法被固定 Branch Logic 完全替代的，就是“面对变化现场，下一步做什么”的判断。Host 仍然负责外围的确定性职责：Identity、Routing、Policy Ceiling、Side-effect Enforcement、Persistence 与 Evidence Capture。

Layer 4 — Capability Plane

提供 Domain Action，但不增加 Agent Runtime 数量。

因此 Capability 可以 Progressive Disclosure。平台拥有它，不代表每一个 Step 都要让模型看到它。

Layer 5 — Action & Human Control

把“工作”与“真实副作用”分开。

Approval 应该复用 Runtime Native Approval / Continuation Semantics，而不是再造第二套 Human Gate Engine。

Layer 6 — Evidence & Learning

让“完成”可以被检查，并为工程学习留下事实。

Receipt 是 Execution Facts 的索引，不是 Business Outcome 的替代品。真正的 Learning Loop 从这些事实进入 Engineering Change 开始，再由 Fresh Run 验证是否改善。

One Runtime，Explicit Composition。

高层路径：

1. Field Surface

   ↓

2. Gateway / Session Binding

   ↓

3. Profile Composition

   ↓

4. One PydanticAI Agent

   ↓

5. Deferred Capabilities / Toolsets / Skills

   ↓

6. Native Approval + Continuation

   ↓

7. Artifacts / Step Facts / Receipts

系统刻意不在这条路径外围再加第二套 Orchestration Engine。

Context 是 Budget，也是 Causal Variable。

模型行为会被进入 Request 的内容直接改变。因此 ZUAEF 把 Context Selection 当成系统设计的一部分，而不是一个“把所有可用信息 concat 起来”的便利函数。

原则：

• 默认投影 Durable Business Context，而不是整份 Execution Log
• Source Material Progressive Retrieve
• Oversized Tool Result Spill 到外部，避免自动污染下一轮 Prompt
• Optional Domain Deferred
• Run 变慢时测量 Largest Input 与 Request Growth
• 只有真实 Retrieval / Memory Failure 出现后，才升级 Memory Complexity

Process 已知时用 Workflow；真正的 FDE 问题，恰恰从“下一步未知”开始。

如果业务流程是确定的，就用确定性实现。

如果下一步需要解释一个不断变化的 Situation，就让模型在受控 Loop 内判断。

ZUAEF 不需要把每一个业务判断硬编码成 Graph Edge。那样可能只是把复杂性从 Prompt 挪到了图上，却没有真正解决“下一步应该做什么”的推理问题。

我们刻意不拥有的东西

当前项目避免自研：

• Agent Registry
• Graph Runtime
• Checkpoint Engine
• Long-term Memory Service
• 默认 Vector Database
• Multi-Agent Orchestration Framework
• 第二套 Human Approval Runtime
• 在真实需求出现之前的 Generic Ingestion Infrastructure

上游 Primitive 仍然可以用，只要它解决被测量出来的问题。这是一种 Architecture Restraint，不是宣称这些 Primitive 永远没用。

旧架构现在属于 Research History。

ZUAEF 早期探索过 LangGraph Supervisor、Domain Agents、ToolRegistry / ToolManager、agent.md Discovery 与更大的 Platform Layer。这些页面会保留在 Legacy Research，因为实验过程有价值；但它们不再代表当前 Runtime。

当前架构来自一个不同的结论：Orchestration 更多，不等于 Intelligence 更多。真正应该追问的是：模型有没有得到更好的上下文、做出更好的决策、执行正确动作，并产出可验证结果？