Host / Platform 具备这个 Primitive。
例如 Tool Search、Memory、Conversation Search、Web Access、Sub-agent 或某个 Domain Toolset。
当前 Deployment Policy 允许这次 Run / Profile 使用它。
Host Ceiling 在模型控制之外。
当前 Step 里，这个 Capability 对模型可见。
Deferred Domain 可以一直隐藏，直到模型发现它真的相关。
模型最终真的调用了其中的 Tool / Operation。
分析一次 Run 时，这个集合最小，也最值得关注。
平台支持一个能力，不代表每一轮模型请求都要携带它的 Schema、Instruction 与“顺手调用一下”的诱惑。
Purpose: 给 Agent 一个受控、可解释的真实业务现场。
它把“回答这句话”变成“继续处理这个客户现场”。
Purpose: 把真实客户/来源材料变成工作产物，同时保持材料访问与 Evidence 显式可查。
Writing Capability 并不意味着 Technique Catalog、Exemplar Library 或 Editorial Rule 应该永远注入。它们都必须靠实验决定是否有用。
Purpose: 帮助 FDE Agent 结合真实客户背景，判断客户问题、约束、下一步行动、谈判位置或回复策略。
这个能力应该服务同一个 Outcome-owning Loop，而不是发展成一个拥有独立世界模型的“客服 Agent”。它真正有价值的前提，是能看到 Bound Case 与真实客户材料，而不是只拿到一条“帮我回复客户”的 Prompt。
Purpose: 让确定性财务计算继续保持确定性，让模型负责业务解释与 Decision Support。
Structured Input → Deterministic Calculation → Model Interpretation / Decision Support → Artifact / Result它体现一个更普遍的原则：一个任务整体是 Agentic，不代表每一步都应该交给 LLM。
Purpose: 让 FDE Agent 在明确 Side-effect Policy 下操作真实外部系统，包括 Create / Update / Publish。
External Write 不和普通内部写作混为一谈。它可以在 Human Approval 处暂停，并通过共享 Continuation Seam 继续。WordPress 是一个 Capability，不是“WordPress Agent”。
Purpose: 让 Agent Progressive Retrieve Information，而不是把整套 Knowledge Base 预加载进 Prompt。
Purpose: 把同一个 FDE Agent 放进工作真正发生的沟通入口。
Field Interface 负责 Transport、Identity、Routing 与 Interaction Rendering；它不负责另一个 Agent Loop。Telegram 是当前已验证的现场 Surface。
未来 Feishu、Slack、WeCom 等 Adapter，只有在可以继续复用同一个 Decision Loop、Case Semantics、Approval Boundary 与 Evidence Model 时才值得接入。
Purpose: 把“模型想做什么”和“系统允许做什么”分开。
| Observe | 自动 |
| Local Write | 自动 |
| External Write | 默认按策略审批 |
| Destructive Action | 默认按策略审批 |
不同 Deployment 可以有不同 Policy，但架构边界不应该改变：Approval 属于 Effect Boundary，而不是每一次中间模型动作。
Purpose: 让长运行在执行中和执行后都能被理解。
下一层是 Run Analysis：把 Performance / Decision Path 问题解释给工程 Agent 或人类操作员。
Purpose: 从现有运行轨迹解释耗时、重复、上下文膨胀、无效工具路径与结果偏离。
这是正在推进的方向，不是已完成能力。仓库证据改变之前，状态必须保持为开发中。
ZUAEF 可以按需消费上游的 Tool Search、Memory、Conversation Search、Web Search / Fetch、Planning、Sub-agents 等 Primitive。项目不需要把每个 Primitive 都重新实现，才能对最终 FDE Outcome 负责。
默认问题应该是：这个额外 Primitive，正在修复哪个被测量出来的 Failure？
如果答案不清楚，就保持 Available 但不 Loaded，或者暂时关闭。
一个新 Capability 通常应该先回答：
如果这些问题都清楚，就不需要为了新增业务域，再造 Agent Class、Graph 或 Registry Layer。