ENGINEERING RESEARCH

科学研究的真谛,在于敢于接受客观事实推翻既有设计。

在 ZUAEF 的工程演进历程中,诸多最为深刻的跨越,往往不是“又堆砌了一个新功能”,而是在真实度量中发现某个看似合理的精巧设计并未改善最终成效,从而果断将其彻底删除、降级简化或重新定义。

“研究”板块完整记录了这一充满思辨的演进轨迹,涵盖具有重要启发价值的负面实验结果、尚未解决的开放课题,以及带有明确时代印记的历史架构剖析。

整个工程项目始终围绕具备高度可证伪性的硬核课题稳步推进。

决策闭环工程 (Agent Loop)

  • 哪些判断必须交由大模型自主推演?哪些边界必须由宿主代码确定性约束?
  • 一次高效扎实的有效任务运行,究竟需要经历多少次核心模型调用?
  • 工具调用(Tool Use)在何种情境下能够形成富有价值的决策闭环,而在何时仅仅带来了无谓的串行延迟?

上下文精准供给 (Context Delivery)

  • 哪些关键信息必须在首轮请求中即时呈现?
  • 哪些大体量素材应当严格按需动态检索调取?
  • 持久业务事实(Durable State)与智能体上一步的试错轨迹应当如何进行物理隔离?
  • 记忆机制在何时切实修复了业务断点,又在何时仅仅让上下文变得更加臃肿且不可归因?

专业能力演进 (Capability Engineering)

  • 一项具体的业务技法,究竟应该由宿主强行注入、交由模型动态权衡,还是沉淀为能力底层的确定性代码重构?
  • 工程调优智能体能否在两次纯净运行之间迭代修复能力代码,并交由人类专家的真实满意度裁决补丁去留,而非在生产线上让系统盲目自我热修改?

证据与可观测性 (Evidence & Observability)

  • 要深刻解释一次慢速运行或低质交付的深层根因,系统到底需要哪些一手事实依据?
  • 如何在不额外发明一套沉重遥测框架的前提下,清晰透视请求延迟、工具耗时、上下文膨胀及产物版本脉络?

人机协同工作面 (Human-Agent Work)

  • 人类专家的关键纠偏与战略批注,应当如何在系统中具备头等公民地位?
  • 如何将交互会话、业务案例、参考物料、过程产物、人工批注、执行时间线与工程交接,纳并在同一个真正高效的工作台中?
架构演进复盘 (ARCHITECTURE EVOLUTION)

告别虚幻的多智能体协同,回归全权承担结果的单一 FDE Agent

在早期探索阶段,ZUAEF 曾深入实践过中央 Supervisor、垂直领域 Agent 拆分、全局工具注册表、基于 agent.md 的自动发现以及更为庞杂的平台抽象层。这些探索在形式上满足了对“架构完备性”的追求,但也极易让团队产生一种“系统架构越宏大、模型智能便越强”的虚妄幻觉。

如今我们坚持用更为严酷客观的尺度审视每一层设计:这一层额外的系统设计,究竟有没有改善大模型的上下文纯净度、提升决策准确率、规范外部动作,并最终带来可独立复核的更佳成效?若不能,无论它看起来多么像教科书式的企业级平台,都应被毫不留情地彻底剔除。

Planned note

《我们删掉了“虚拟组织”:为什么 ZUAEF 全面回归单一 Outcome Owner》

深度剖析为何原本分散的多 Agent 身份、复杂注册中心与层层编排管道,最终优雅收敛为单一承担最终结果的 FDE Agent 与显式按需能力组合。

上下文因果变量 (CONTEXT DELIVERY)

上下文既是认知预算,更是左右推演结果的根本因果变量(Causal Variable)

业界往往将智能体的交付品质简单归结为“底层模型能力是否足够强悍”。然而在生产实践中,一次运行的成败往往被宿主预先挑选的物料偏见、隐蔽的安全提示词、超大体积的工具返回值以及过往残留的无效对话所严重左右。ZUAEF 正式将上下文构建机制提升为必须进行因果测量的核心变量。

  • 哪些关键材料在模型正式看到任务之前便已被宿主强行筛选?
  • 关键事实证据是模型通过能力自主探查得出的,还是宿主粗暴投喂的?
  • 单步请求中最大一次上下文的体积消耗究竟达到了何种量级?
  • 哪些历史对话片段被悄悄带入了后续决策轮次?
  • 究竟是哪一项工具的异常输出诱发了大模型额外陷入多余推演?

Planned note

《模型并非“未卜先知”:宿主上下文构建机制如何深刻改变智能体行为》

能力演进哲学 (CAPABILITY EVOLUTION)

提升写作等专业能力,绝不能盲目依赖向 Prompt 疯狂堆砌提示词

我们在写作场景下的大量对比实验清晰表明:单纯往 Prompt 里灌输长篇累牍的编辑修润技巧文本,不仅无法单调稳定地改善生成品质,反而常常适得其反。由宿主强行预设的技巧可能在某次偶有斩获,换一个情境便彻底失效;甚至即便拿到了一份看似无懈可击的完美提示词,模型依旧可能炮制出总结欲泛滥、行文呆板、充满浓厚 AI 机械味的平庸文本。

标准基线 (Baseline) → 针对性工程补丁 → 净室环境独立重跑 (Fresh Run) → 双盲人工专家裁决 → 确认沉淀或立即回滚

唯有人类专家的真实价值裁决,才能决定一项代码补丁的去留。正在进行中的生产运行,严禁动态自我热修改。

Planned note

《别再无脑给 Prompt 补课了:何时应当直接重构 Capability 核心代码》

工作台深度演进 · 积极研发中 (WORKBENCH IN PROGRESS)

Run Analysis:从静态时间线透视,跃升为智能解释与因果归因

当前的 Agent Console 已经能够高保真透视执行轨迹;而正在攻坚的 Run Analysis 旨在进一步穿透数据表面,深刻解释运行背后的因果机理。

  • 能否以毫秒级精度,秒级定位究竟是哪几次模型调用占据了整场任务绝大部分的实际耗时?
  • 能否以清晰的因果链条,揭示“某次特定的工具调用为何直接诱发了下一次额外的模型轮次”?
  • 能否在不引入沉重遥测框架的前提下,精准捕捉并预警上下文的非线性异常累积?
  • 分析引擎给出的诊断,能否直接精确定位至最可能改善下一轮运行表现的具体能力源码行?

Planned note

《时间线罗列不等于归因解释:专为工程智能体打造的 Run Analysis 体系》

历史探索架构保持公开透明,但必须标明时间,更必须附带醒目的警示标识。

归档的历史课题包括:

  • 基于 LangGraph 与 PydanticAI 的双层混编架构
  • 中心化 Supervisor 编排分发模式
  • 多垂直领域的专属 Domain Agent 拆分体系
  • 全局工具注册中心与管理层 (ToolRegistry / ToolManager)
  • 以 agent.md 自动发现机制作为核心扩展范式
  • Team Topologies 在智能体运行时的机械映射
  • 早期的 ReAct 与图网络编排探索实验
历史研究

Z-UAEF V3.0 架构深度解析:两层智能体协同模型

深入探讨 Z-UAEF V3.0 的两层架构设计:LangGraph Supervisor 作为战略层,PydanticAI Agents 作为战术层。了解如何通过 Command + Skill 双轨模型实现确定性与智能性的完美平衡。

历史研究

agent.md 蓝图:声明式智能体开发的最佳实践

探索 agent.md 如何成为智能体的声明式契约。从 YAML frontmatter 到工具规范,从依赖注入到自动化发现,全面了解声明式智能体开发的核心理念。

历史研究

Finance Agent V2:领域驱动设计在智能体中的实践

详细介绍 finance_agent_v2 的 DDD 重构过程:Domain 层的计算器、Application 层的服务编排、Infrastructure 层的数据加载。学习如何通过分层架构提升代码质量和可维护性。

历史研究

ToolRegistry 自动发现机制:零配置智能体集成

深入了解 ToolRegistry 如何通过扫描 agent.md 实现智能体的自动发现和注册。新智能体实现零配置自动集成,无需手动修改编排代码,大幅提升开发效率。

历史研究

Team Topologies 在 Z-UAEF 中的应用:组织架构与系统架构的一致性

探讨如何将 Team Topologies 的理念应用到 Z-UAEF 架构中。Platform Team、Enabling Team、Stream-Aligned Teams 的映射与协作模式。

历史研究

ReAct Loop:Skill 内部的智能编排引擎

了解 Skill 如何使用内部 LangGraph ReAct Loop 实现 Thought-Action-Observation 循环。通过多轮推理和命令调用,Skill 能够自主完成复杂的目标导向任务。

历史研究

RunContext 依赖注入:构建可测试的智能体系统

深入探讨 RunContext 如何通过依赖注入模式提供 trace_id、配置、LLM 客户端等上下文信息。学习如何通过 DI 实现智能体的可测试性和可维护性。

历史研究

Graphiti 知识图谱集成:赋能 Knowledge Agent 的智能记忆

介绍如何将 Graphiti 知识图谱集成到 knowledge_agent 中。通过 add_episode 和 search 接口,实现知识资产的结构化存储和智能检索,构建组织级知识记忆。

历史研究

两阶段分析模式:Pre-computation + LLM Insight 的最佳实践

探索两阶段分析模式如何平衡性能和智能性。第一阶段使用 pandas/duckdb 进行确定性预计算,第二阶段使用单次 LLM 调用生成洞察报告。

历史研究归档——非当前 ZUAEF 生产架构。本页真实记录了团队在早期的探索历程与设计取舍。请查阅“当前架构”以了解系统现行的真实实现。

为什么坚持公开保留这些被淘汰的方案?

因为探索的曲折路径本身就是极具价值的研究成果。一个成熟负责的工程开源项目,应当坦诚公开“哪些看似美好的设想被果断淘汰、背后的核心诱因究竟是什么”,而非在每一次架构重大迭代之后,悄无声息地篡改或掩盖既往的历史。

负面实验结果(Negative Results),同样是弥足珍贵的科研成果。

一篇严谨客观的工程研究笔记,完全可以得出以下结论:

  • 在严密量化下未观测到任何统计学意义上的质量改善
  • 显著增加了调用延迟,却未换来交付物水准的实质性跃升
  • 某项耗时打造的特定能力在当前场景下被证明毫无必要
  • 双盲评审中人类专家更青睐精简干净的基线版本输出
  • 宿主在环境预选物料时的隐性偏见干扰了实验的客观性
  • 新引入的复杂分层架构严重削弱了系统故障的可解释性与归因能力
  • 在得出确凿的产品级结论前,必须在更广阔的测试集上开展新一轮净室重跑

唯有坚守这种不自欺欺人的工程敬畏,Research 板块才能牢固扎根于实事求是的现场检验,而非再度滑向虚浮的市场公关宣发。

始终追随客观证据前行,即便事实要求我们果断退回并重构既有设计。