企业工作流与生产架构

企业 AI 五层架构与横向治理

企业 AI 可以用五层理解：底层算力与基础资源，数据与知识，模型服务，Agent 与工作流，最终的业务应用。身份权限、安全、日志、监控和运营治理横穿每一层。

FDE 的任务不是重建所有平台，而是明确当前场景使用哪些已有能力、缺少哪些连接、哪些风险必须在架构层处理。

• 基础资源：云、私有环境、算力与网络
• 数据知识：数据库、文档、规则、案例与权限
• 模型服务：通用模型、专用模型、路由与成本
• Agent 协作：工作流、工具、状态、评估与生命周期
• 业务应用：用户入口、岗位任务、流程与结果

MVD、MVW、MVR 与 RACI、Human Gate

MVD 限定真实用户、真实数据、真实流程和短周期，使方案尽快接受现场检验。它还要写明价值指标、POC 毕业条件、停止条件与运行责任。

原型在开发者电脑上成功不等于部署。只有进入受控的真实环境，用户能独立完成任务并留下日志与反馈，项目才获得下一步证据。

To-Be 从业务目标倒推，保留必要判断，减少无价值交接。MVW 不是功能最少，而是包含能够完成一次业务结果验证的最短完整工作。

设计时要明确 AI 在哪里生成、抽取、检索、建议或执行，人在哪些地方确认、纠错、批准和承担最终责任。

RACI 用于明确负责执行、最终负责、提供咨询和被告知的角色。AI 可以承担任务，但不能成为法律或管理意义上的最终责任人。

Human Gate 应放在高风险、不可逆、低置信或需要价值判断的节点。人工检查不是装饰，需要说明检查什么、依据什么、如何记录。

MVR 说明 AI 接走哪些确定性任务，人获得哪些时间，又新增什么判断、责任、创造和能力要求。只让员工审核更多机器输出，不算角色向上移动。

受影响人员要参与设计新工作。项目至少提供一个可以在当前周期内尝试的新职责，例如定义质量标准、维护异常样本、设计新场景或承担跨岗位判断。

资料缺失、规则冲突、系统超时、权限不足和模型不确定时，工作流必须能够拒绝、降级、重试或升级。

首轮接入优先读取现有数据、保留原系统记录和人工出口，谨慎写入真实业务状态。先读旧、后写新，可以降低一次性改造与锁定风险。

RAG、上下文包、权限与版本

RAG 质量由文档处理、切分、元数据、Embedding、检索、重排、上下文组合和生成共同决定。答案错误时，要先判断问题发生在哪一层，而不是反复改 Prompt。

重要答案应显示来源，必要时保留原文片段和版本，帮助用户验证并反馈。

上下文包可以包含任务目标、用户角色、业务规则、权威知识、正反样例、工具、实时状态、输出格式、禁止事项和失败处理。

稳定内容可以版本化管理，实时状态通过工具查询，敏感信息按用户权限动态加载。把所有内容硬塞进一个 Prompt，既难维护也难审计。

上下文必须遵循最小权限。用户能看到什么，Agent 就只能调用相应范围的资料与工具。知识更新要记录版本、生效时间和审批者。

未经授权，不把企业敏感材料发送到公共模型；项目结束时还要明确材料的保留、删除与归还规则。

Agent PRD、输入输出契约与失败控制

规则明确、步骤稳定的任务优先使用固定 Workflow；需要在多种工具与路径中动态选择时，才考虑 Agent。很多可靠系统其实是“固定骨架＋局部 Agent 判断”。

不要把多 Agent 当作先进程度。每增加一个 Agent，就增加一次理解偏差、通信、成本与治理难度。

输入契约说明来源、格式、必填项、权限与完整性；输出契约说明结构、使用者、后续动作和质量要求。

缺少关键输入时，系统应主动询问、拒绝或转人工，而不是猜测补齐。结构化输出可以减少后续系统解析错误。

Skill 是可复用的业务动作，例如检索制度、计算指标、查询库存、生成草稿或创建工单。每个工具都要定义参数、权限、返回结果和失败方式。

查询、建议、写入和外部发送具有不同风险。高风险工具需要更严格的身份、审批、范围和审计。

工作流需要知道任务进行到哪里、哪些信息已经确认、哪个版本正在运行。记忆应服务当前任务，不应无边界保存所有对话和敏感资料。

重试要有上限，超时要能降级，不确定要能转人工，不可逆动作要有确认。失败控制是 Agent 设计的一部分。

一份 Agent PRD 包含用户与场景、业务价值、流程、人机分工、输入输出、上下文、工具、状态、评估、风险、日志、成本和维护责任。

PRD 的目的不是写得厚，而是让业务、技术与治理角色对同一系统形成可执行共识。

从 Demo 到生产：阶段门、集成、日志、告警与回滚

Demo 展示一个想法；原型验证最大不确定性；PoC 证明关键技术与质量可以成立；试点让限定用户在真实任务中运行；生产要求稳定、可支持、可审计并有持续责任。

前一阶段成功不能自动证明后一阶段已经就绪。项目汇报必须写清当前阶段和仍未证明的部分。

进入下一阶段前检查真实数据、用户、接口、质量、权限、日志、回退和负责人。PoC 毕业进入试点，需要关键质量、代表性样本、真实用户与业务流程都具备。

试点进入生产，还要补齐容量、稳定性、告警、故障响应、发布和维护责任。

原型范围由最可能让项目失败的假设决定，例如知识是否足够、模型能否处理异常、用户是否理解输出，或系统接口能否取得关键数据。

如果只选择理想样本、由开发者代操作并隐藏人工修正，它只能证明演示能够完成。

身份、API、数据库、事件、文件、旧系统与人工操作都需要输入输出契约、权限和失败处理。首轮连接可以优先只读或建议模式，写入真实业务状态需要审批、幂等与回退。

明确测试与生产环境、数据范围、超时、重试和依赖方，避免把系统问题误判成模型问题。

生产交付需要版本控制、测试、配置与密钥管理、发布记录、Trace、日志、业务指标、告警和回滚。每次运行保留模型、Prompt、知识、输入、输出、人工干预、时延和成本。

生产代码硬边界保证系统可被定位、修复和恢复。它不能在项目后期临时补齐。

上线前明确谁响应故障、谁批准变更、谁更新知识、谁判断业务影响、谁与用户沟通。外部 FDE 还要说明支持范围、响应时限、升级路径和退出条件。

客户接管不等于外部团队立即离场。责任应通过共同运行、演练和逐步移交完成。