# 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. 参考架构

```mermaid
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 合约

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

```yaml
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. 评测工具链

至少建立四层评测：

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

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

## 6. AI Coding 在 FDE 中的位置

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

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

## 7. 选型顺序

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

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