Forward-Deployed 是一种工作方式，不是一个职位标签。
真正的 Forward Deployed Engineer 会进入客户现场，理解约束、诊断问题、调用现有工具推进任务、验证结果，再根据现场变化继续调整。
ZUAEF 把这种工作方式放进 Agent。一个 FDE Agent 应该能持续回答：
- 这次工作是为谁做？
- 当前业务目标是什么？
- 之前已经发生了什么？
- 哪些约束现在仍然有效？
- 还有什么 Unknown？
- 哪个能力与当前问题相关？
- 这个动作可以直接做，还是已经跨出授权边界？
- 真实动作到底成功了吗？
- 动作之后，业务现场发生了什么变化？
这和“从工具列表里选一个函数”不是同一个问题。
ONE OUTCOME-OWNING LOOP
Observe → Diagnose → Decide → Act → Verify
Observe
读取当前请求，以及这一次运行被允许看到的业务上下文。需要时主动读取材料，而不是假设初始 prompt 已包含一切。
Diagnose
识别目标与当前状态之间的差距。区分事实、约束、Unknown 与历史执行记录。
Decide
选择当前最有价值的下一步。模型真正有价值的地方就在这里：当行动无法被 Host 在运行前完全枚举时，模型必须进行判断。
Act
加载足以完成工作的最小能力面。内部工作继续执行；外部副作用遵守 Policy 与 Approval。
Verify
检查产物、工具副作用、外部系统状态或其他证据。“模型说已经完成”本身不构成核验。
Continue / Stop
根据更新后的 Situation 判断：结果是否完成？还需要下一步？还是需要人类做一个真正的业务决策？
业务域应该成为能力，而不是一堆“小组织”。
写作、谈判、预算分析、WordPress 操作解决的是不同问题，但这并不自动意味着每个领域都需要一个独立 Agent 身份、独立 Loop 和独立世界模型。
ZUAEF 让一个 Agent 对结果负责，把专业行为组合在它下面。
一次 Run 只有一个 Outcome Owner。Capability 帮它行动，但不会和它争夺业务问题的所有权。
这样也更容易分析失败：当 Run 变慢、反复、质量下降时，我们可以直接分析模型决策路径，而不是猜测“是不是某个 orchestrator 把任务交给了错误的 Agent”。
BUSINESS CONTEXT
Agent 需要现场，不需要每轮都吞掉全部历史。
Business Case 可以承载耐久的业务现场：客户/项目目标、当前状态、资源引用、人的纠正、Policy Override 与其他被验证过的业务信念。
但默认 Prompt 不应该把每一次历史动作都当成事实。ZUAEF 保持两个边界：
Durable Business State
系统现在认为真实业务世界是什么样：客户、项目、约束、资源、状态。
可以经过裁剪进入 Context Projection
Execution Trajectory
Agent 尝试了什么、调过哪些工具、失败过什么、发生过哪些审批。
默认用于审计与检查
这样可以避免一个错误动作，在下一轮里悄悄变成“既定事实”。
更小的 Action Space
Available 不等于 Loaded。
平台可能有很多 Primitive；部署只授权其中一部分；某次 Run 真正加载的更少；最后模型可能只调用一个。
这个区分很重要，因为模型看到的 Action Space 本身会改变它的行为。写作任务不应该因为平台拥有预算、WordPress 与其他业务能力，就在首轮 Request 里一次性看到所有 Tool Schema。发布动作真的相关时，再发现或加载执行能力。
系统因此可以扩展能力，而不要求每一个 Prompt 和 Tool Surface 同步膨胀。
在真正边界上监督
人不是一个负责不停点“批准”的流程节点。
操作员应该监督方向、纠正假设、检查产物，并决定什么时候允许 Agent 产生真实外部副作用。
“改写这篇文章。”
把改写结果直接呈现给当前 Supervisor，不触发外发审批。
“先给我看看草稿。”
在当前对话展示，不等于发客户。
“发给客户。”
准备外发内容，并在 External Effect 边界暂停。
“发布。”
调用对应执行能力，并按部署策略进入审批。
人审批的是重要动作，而不是导致这个动作之前的每一次内部工作。
能外部核验的完成，就不要只相信模型自述。
一个可靠的 Agent System 至少要区分三句话：
- 1模型打算做某件事。
- 2Runtime 允许并执行了某件事。
- 3业务结果真的发生了。
ZUAEF 保存 Operational Step Facts 与紧凑 Run Receipt，让第三句话可以被事后检查。不同任务的 Evidence 可以是：
Receipt 不是结果。它只是让项目证明实际发生过什么的方式。
ZUAEF 不再试图画一家公司出来。
它不以这些东西为核心：
- Supervisor 把任务分发给一支固定 Domain Agent 团队
- ToolRegistry 被当成业务智能
- 每个业务步骤都变成 Graph Node
- 在真实 Memory Failure 出现之前就先堆一套长期记忆系统
- 默认把 Multi-Agent 当成“高级功能”
- 给普通内部工作加一堆 Approval Field，只为了让流程看起来更可控
上游 Primitive 仍然可以用。规则只有一个：它必须解决一个被测量出来的问题。