早期 ZUAEF 探索过 Supervisor、Domain Agents、ToolRegistry / ToolManager、agent.md Auto-discovery 与更大的 Platform Abstraction。这些实验解决了一部分代码组织问题，但也让我们更容易把“架构完整”误认为“智能更强”。
当前系统使用更严格的问题：这一层有没有改善模型的 Context、Decision、Action 或 Verifiable Outcome？如果没有，就不应该因为它看起来像 Enterprise Platform 而保留。
Planned note
《我们删掉了“虚拟组织”：为什么 ZUAEF 回到一个 Outcome Owner》
解释为什么多个 Agent Identity、Registry 与 Orchestration Layer 最终收敛成一个 FDE Agent + Explicit Capability Composition。
Agent Quality 经常被描述成“模型够不够强”的问题。但真实 Run 可能被 Host 预选材料、隐藏 Policy、大型 Tool Result、上一轮残留历史主导。ZUAEF 正在把 Context Construction 当成必须测量的 Causal Variable。
Planned note
《模型并不是“自己知道”的：Host Context Selection 如何改变 Agent 行为》
写作实验已经说明：增加更多 Editorial Technique Text，并不会单调提升质量。Host-selected Technique 可能一轮获胜、下一轮失败；Model 也可能完全不选择 Technique Catalog；一份技术上“都对”的 Prompt 仍然可能写出总结欲过强、AI 味明显的文章。
baseline → engineering patch → fresh run → blind/human reward → keep or revertHuman Reward 决定 Patch 是否留下。同一次 Production Run 不热修改自己。
Planned note
《别再教 Prompt 了：什么时候应该直接修改 Writing Capability》
Agent Console 能展示 Run。Run Analysis 应该解释 Run。
Planned note
《Timeline 不是解释：为 Engineering Agent 构建 Run Analysis》
深入探讨 Z-UAEF V3.0 的两层架构设计：LangGraph Supervisor 作为战略层，PydanticAI Agents 作为战术层。了解如何通过 Command + Skill 双轨模型实现确定性与智能性的完美平衡。
探索 agent.md 如何成为智能体的声明式契约。从 YAML frontmatter 到工具规范，从依赖注入到自动化发现，全面了解声明式智能体开发的核心理念。
详细介绍 finance_agent_v2 的 DDD 重构过程：Domain 层的计算器、Application 层的服务编排、Infrastructure 层的数据加载。学习如何通过分层架构提升代码质量和可维护性。
深入了解 ToolRegistry 如何通过扫描 agent.md 实现智能体的自动发现和注册。新智能体实现零配置自动集成，无需手动修改编排代码，大幅提升开发效率。
探讨如何将 Team Topologies 的理念应用到 Z-UAEF 架构中。Platform Team、Enabling Team、Stream-Aligned Teams 的映射与协作模式。
了解 Skill 如何使用内部 LangGraph ReAct Loop 实现 Thought-Action-Observation 循环。通过多轮推理和命令调用，Skill 能够自主完成复杂的目标导向任务。
深入探讨 RunContext 如何通过依赖注入模式提供 trace_id、配置、LLM 客户端等上下文信息。学习如何通过 DI 实现智能体的可测试性和可维护性。
介绍如何将 Graphiti 知识图谱集成到 knowledge_agent 中。通过 add_episode 和 search 接口，实现知识资产的结构化存储和智能检索，构建组织级知识记忆。
探索两阶段分析模式如何平衡性能和智能性。第一阶段使用 pandas/duckdb 进行确定性预计算，第二阶段使用单次 LLM 调用生成洞察报告。
历史研究——不是当前 ZUAEF 架构。本页记录早期设计阶段。请查看 Current Architecture 了解现在实际存在的系统。
因为路径本身就是研究结果。一个有价值的工程项目应该公开“哪些想法被删除、为什么”，而不是每次改架构之后悄悄重写历史。
Research Note 完全可以得出：
只有保持这个标准，Research 才能继续和 Field Proofs 相连，而不是重新滑回 Marketing。