04 · 工程架构与工具栈

官网给出方法、产物和能力类别，但没有指定一套唯一厂商产品。下表把官网明确提到的 RAG、工具调用、MCP、HITL、评测、日志监控、安全等能力组织成可实施的平台无关参考栈；具体产品例子属于工程化补全，不应理解为官网推荐或采购清单。[S3][S4][S5][S6]

1. 工具栈不等于软件清单

FDE 的第一工具栈是“认知与交付工具”，其次才是工程软件：

层	核心工具/产物
现场	Account Brief、访谈提纲、Gemba Notes、Shadow Workflow、Stakeholder Map
价值	Value Stream Map、Baseline Sheet、KPI Tree、Opportunity Scorecard、Hypothesis Card
设计	Domain Model、Context Map、Agent PRD、HITL Map、Exception Matrix、Solution Canvas
验证	Experiment Card、黄金样本、Eval Set、Failure Taxonomy、Eval Report、Decision Log
生产	PRR、权限矩阵、审计策略、Runbook、回滚方案、SLO/SLA、告警面板
采纳	Sponsor Brief、Pilot Canvas、Adoption Funnel、Value Ledger、Review Cadence
复用	Portfolio、连接器、Agent/Skill 模板、评测集、实施 SOP、Industry Pack

没有这些产物，仅拥有模型平台和 Agent 框架，仍然容易停留在 Demo。

2. 平台无关工程栈

层次	必备能力	选型检查
体验层	对话、表单、工作台、通知、人工确认	能否嵌入原工作流；是否展示来源、置信和责任
编排层	Workflow/Agent、状态机、任务队列、超时重试	是否显式建模状态、补偿、异常升级和幂等
模型层	LLM/多模型路由、结构化输出、内容安全	能否版本化、降级、限流和记录模型配置
知识层	文档解析、检索、RAG、引用、知识版本	权限是否随检索继承；能否评测召回和答案依据
工具层	Tool Calling、MCP、API/数据库/消息连接器	输入输出 Schema、最小权限、审批、超时和回退是否明确
业务语义层	对象、关系、事件、状态、规则、Action	是否形成 LDO 最小切片，而非只复制源表结构
数据层	采集、CDC/事件、质量、血缘、主数据、特征/样本	来源、时间语义、用途授权和质量 SLA 是否可追溯
评测层	离线集、回放、红队、在线实验、失败分类	是否覆盖任务质量、业务、风险、采纳、成本和时延
安全治理层	IAM、密钥、策略、PII、防注入、审计	能否对 Agent Action 做逐步授权和不可抵赖记录
运行层	容器/函数、CI/CD、灰度、观测、告警、成本	是否支持可回滚发布、端到端 Trace 和 SLO
资产层	Registry、模板、版本、Portfolio、行业 Pack	可复用与客户定制边界是否清楚；是否有 Owner 和淘汰机制

3. 参考架构

flowchart LR
    U[一线用户 / Sponsor] --> UX[业务工作台与 HITL]
    UX --> WF[工作流 / Agent 编排]
    WF --> LLM[模型路由与结构化输出]
    WF --> RAG[知识检索 / RAG]
    WF --> TOOL[受控 Tool / MCP / API]
    TOOL --> SYS[ERP/CRM/工单/数据平台]
    SYS --> EVT[事件与状态]
    EVT --> ONT[LDO 最小本体切片]
    ONT --> WF
    WF --> AUDIT[轨迹、审计、成本、时延]
    AUDIT --> EVAL[离线/在线评测与失败分类]
    EVAL --> LEDGER[价值与采纳账本]
    LEDGER --> DECIDE{扩展 / 调整 / 停止}
    DECIDE --> WF

4. Action 合约

所有能改变业务世界的工具调用都应有显式合约：

action: create_purchase_order
business_owner: 供应链负责人
actor: procurement_agent
purpose: 经审批后创建补库订单
input_schema: {...}
preconditions:
  - inventory_gap > threshold
  - supplier_status == approved
authorization:
  scope: purchase_order:create
  data_purpose: replenishment
human_confirmation:
  required_when: amount >= 100000
writeback: ERP.purchase_order
idempotency_key: request_id
timeout_seconds: 15
rollback: cancel_purchase_order
audit_fields: [user, model_version, evidence, approver, result]

这正是“模型定行动”：输出必须进入受控、可审计、可回退的业务动作，而不是停留在回答文本。[S4]

5. 评测工具链

至少建立四层评测：

组件：解析、检索、结构化输出、工具参数准确性。
任务：端到端完成率、事实性、专家接受率、失败类别。
生产：时延、稳定性、成本、权限违规、回滚和人工接管。
业务/采纳：周期、等待、返工、质量、风险、活跃使用、覆盖率、采纳率。

工具能力应支持：数据集版本、Prompt/模型版本、Trace 回放、人工标注、红队样本、A/B 或灰度对照、失败聚类和结果归因。

6. AI Coding 在 FDE 中的位置

官网把 AI Coding 放在九能力域 D7，强调“速度属于 AI，质量属于工程体系”。[S6] 因此应当：

先有 Task Pack/Tech Scope，再生成代码。
小步提交，接口和权限先行。
自动测试覆盖正常、异常、越权、超时和回滚。
人工审查架构、安全、数据用途和业务责任。
代码、提示、工作流、评测集与部署配置共同版本化。

7. 选型顺序

先定价值、用户和任务。
再定工作流、HITL 与异常。
再定最小本体、数据和 Action 合约。
再用真实样本定义 Eval。
最后选择模型、Agent 框架、RAG、数据库和运行平台。

倒序选型（先买平台、再找场景）与 Lean-FDE 的逻辑相反。