六层解耦系统架构
现场业务接入层 (FIELD INTERFACE)
让智能体直接驻守在真实工作发生的第一线交互入口。
业务上下文管理层 (BUSINESS CONTEXT)
向智能体精准告知其当前所处的具体业务现场与硬性事实。
FDE 决策主循环 (FDE DECISION LOOP)
作为唯一责任主体，全权主导并承担最终业务结果。
动态能力平面 (CAPABILITY PLANE)
提供各垂直领域的专业动作原语，而无需凭空倍增多个 Agent 运行时。
动作与人工控制层 (ACTION & HUMAN CONTROL)
严密隔离内部推演探索与具有外部影响的真实系统副作用。
证据沉淀与复盘层 (EVIDENCE & LEARNING)
确保每一次任务交付皆有据可查，并为后续工程调优沉淀一手运行事实。
决策主循环是系统的绝对心脏。其余所有分层，皆是为了确保该循环看得清晰、做得扎实、守得住边界且结果经得起复核检验。
Layer 1 — 现场业务接入层 (Field Interface)
让智能体直接驻守在真实业务发生的第一线交互入口。
- 底层通信协议适配 (Transport)
- 调用方身份鉴权与白名单过滤 (Identity / Allowlist)
- 多租户会话与对话路由分发 (Session / Conversation Routing)
- 业务案例深度锚定绑定 (Case Binding)
- 入站原始数据标准化处理 (Inbound Normalization)
- 常规对话与生成内容的即时呈现
- 高危动作的人工审批交互界面
- 审批通过后的断点续跑回调调度 (Continuation Callback)
现场接入层严禁私自构建第二套 Agent 决策循环。
Telegram 是当前已在生产环境严密验证的现场切面。未来接入飞书、Slack、企业微信等外部平台时，若必须侵入修改核心决策循环、业务案例语义或审批边界才能跑通，便直接证明该接入切面的抽象设计是不合格的。
Layer 2 — 业务上下文管理层 (Business Context)
向智能体精准告知其当前所处的客观业务现场与约束边界。
业务案例（Case）负责承载经过严密校验的持久状态，例如：
- 客户画像与项目专属身份标识
- 核心交付目标与当前推进阶段现状
- 关联业务物料、参考素材与资产索引
- 来自现场操作员的即时纠偏与引导批注
- 特定租户的安全策略重载规则 (Policy Override)
- 其他经过客观检验的既定业务事实
根本性系统工程切分
持久业务信念 (Durable Business State) ≠ 瞬态执行轨迹 (Execution Trajectory)
系统绝不能因为“智能体在上一步曾尝试过操作 X”，就盲目假定“X 已成为不可动摇的客观事实”。底层轨迹是用于安全审计的证据链；持久上下文才是经过严格核验的业务世界真相投影。
Layer 3 — FDE 决策主循环 (FDE Decision Loop)
作为唯一责任主体，全权主导并承担最终业务交付成效。
Observe（观察） → Diagnose（诊断） → Decide（决断） → Act（行动） → Verify（核验） → Continue / Stop（流转）大模型的核心价值应当完全聚焦在此处：因为在多变的真实业务现场中，唯有面对充满未知变量的情境、自主研判“下一步最有价值的行动是什么”的推演过程，是固定分支条件无法提前穷尽的。而宿主环境（Host）则牢牢掌控所有外围确定性职责：身份认证、消息路由、策略边界硬锁定、副作用拦截、状态持久化与证据沉淀。
Layer 4 — 动态能力平面 (Capability Plane)
提供垂直领域的专业动作原语，而无需凭空引入多个分散的 Agent 运行时。
AVAILABLE (底层可用) → AUTHORIZED (环境授权) → LOADED (按需装载) → INVOKED (实际触发)因此，所有业务能力均支持按需渐进式披露（Progressive Disclosure）。平台拥有某项能力，绝不等于在每一步推演中都要强行把它塞进模型的视野之中。
Layer 5 — 动作与人工控制层 (Action & Human Control)
严密隔离日常推演探索工作与具有外部真实影响的系统副作用。
人工审批机制直接深度复用运行时原生的暂停（Pause）与断点续跑（Continuation）机制，坚决拒绝额外造轮子去拼装第二套脱节的人工网关引擎。
默认动作副作用等级模型
| Observe（内部资料查阅） | 全程自主高速执行 |
| Local Write / Working Artifact（内部草稿与中间成果生成） | 自主执行并安全持久化 |
| External Write（向外部系统写入正式数据） | 严格依策略触发人工审批挂起 |
| Destructive Action（敏感更迭与破坏性操作） | 严格依策略触发人工审批挂起 |
Layer 6 — 证据沉淀与工程复盘层 (Evidence & Learning)
确保每一次业务交付皆有据可查，并为后续系统调优留下第一手事实真相。
运行收据是底层执行事实的检索索引，绝非业务结果本身的替代品。真正的工程演进闭环，正是始于将这些一手证据转化为精准的代码改进，再通过纯净环境的重跑来严密验证系统表现是否切实提升。
单一核心运行时，清晰显式组合。
全景执行架构链路：
- 现场交互切面 (Field Surface)
- 接入网关与会话绑定 (Gateway / Session Binding)
- 环境配置文件组装 (Profile Composition)
- 单一主导的 PydanticAI Agent 决策核
- 按需延后装载的专业能力工具集 (Deferred Capabilities)
- 原生的审批挂起与断点续跑机制 (Native Approval + Continuation)
- 成果文件 / 单步事实 / 防篡改运行收据 (Artifacts / Step Facts / Receipts)
系统极其克制：坚决不在这条优雅精简的主干外围，再叠加任何第二套冗余的编排引擎。
上下文既是认知预算，更是直接影响推演的因果变量（Causal Variable）。
大模型的决策行为会被塞入单步请求中的具体内容直接左右。因此，ZUAEF 将上下文的精准裁切视作核心系统工程的一部分，坚决摒弃“无脑把所有历史信息简单拼接”的粗暴做法。
上下文治理准则：
- 默认仅向模型投影经过提炼的持久业务事实，而非把全量底层执行日志一股脑塞入
- 针对大体量外部原始素材，全面推行按需渐进式调取（Progressive Retrieve）
- 体积超标的工具返回数据，自动溢出保存至外部存储并以指针引用，杜绝污染下一轮 Prompt
- 非必选的领域能力默认采用延后装载策略，仅在模型研判确实相关时才动态呈现
- 当系统运行出现延迟瓶颈时，优先测量单步输入峰值与上下文体积的膨胀斜率
- 唯有在基础的词法检索与上下文传递确实遇到不可调和的瓶颈时，才审慎引入更复杂的向量检索体系
确定性的业务走代码工作流；真正的 FDE 工程挑战，恰恰始于“下一步走向未知”。
如果具体的业务流转完全是既定已知的，就应当使用确定性代码直接实现，毫无必要引入大模型猜概率。
唯有当系统面临动态变化、需要实时诊断复杂现场并决断下一步对策时，才应当交由大模型在受控循环内自主推演。
ZUAEF 坚决不把每一个微小的业务判断都强行硬编码进复杂的图节点（Graph Edge）网络中。那种做法仅仅是把复杂性从 Prompt 掩耳盗铃般转移到了图配置中，根本未能触及“如何做出更明智决策”的智能本质。
我们保持高度克制、坚决拒绝自研的架构清单
在当前项目中，我们坚决避免自行重复造轮子：
- 自研独立的 Agent 注册中心服务 (Agent Registry)
- 自研复杂的图计算编排运行时 (Graph Runtime)
- 自研第二套状态持久化检查点系统 (Checkpoint Engine)
- 脱离业务场景自研所谓的通用长期记忆服务 (Long-term Memory Service)
- 在未遇瓶颈前默认绑定重量级向量数据库
- 自研华而不实的多智能体角色扮演协作框架 (Multi-Agent Framework)
- 割裂于主工作流的第二套人工审批孤岛
- 在真实业务需求尚未浮现前盲目搭建的通用数据摄取管道
上游成熟的基础原语随时可以直接调配，前提是它能切实解决一个已被严密量化的真实痛点。这代表着一种成熟清醒的工程克制，绝非傲慢地否定这些基础设施的潜在价值。
历史探索沉淀为研究档案，以坦诚姿态昭示演进轨迹。
ZUAEF 在早期同样深入探索过多层 Supervisor 架构、领域 Agent 拆分、全局工具注册表、基于 agent.md 的自动发现机制以及更为庞大的企业级平台抽象。这些历史页面被完整归档在“历史研究”专区，因为试错过程本身具备极高的工程参考价值；但它们不再代表当前系统的实际实现。
当前架构的诞生，源自一个更加严苛而清醒的工程审视：编排层次越多，绝不意味着系统智能越强。我们唯一应当反复拷问的是：大模型究竟有没有获得更纯净精准的上下文？有没有做出更高明准确的决断？外部动作是否精准无误？最终是否切实交付了可经受严密复核的成果？在研究板块中查看完整架构演化史 →