一种基于 Agent 的需求规范化闭环实践：让合规与规范内建于流程

一、背景：治理复杂度与日俱增

企业级系统的演进，正在把"需求治理"推向前所未有的复杂度。业务迭代加速、合规要求收紧、领域知识分散------每一项变化，都在放大需求从提出到落地过程中的不确定性。

尤其在权限、安全、流程等强合规领域，一次含糊的需求，可能演化为一处越权漏洞、一条违规策略，甚至一次审计事故。规范化，已不再是锦上添花，而是系统治理的生命线。

二、痛点：传统研发工作流的三重困境

回看传统的需求交付链路，问题集中于三个环节：

┌─────────────┐   人工翻译   ┌─────────────┐   人工评审   ┌─────────────┐
│  业务需求    │ ───────────>│  策略配置    │ ───────────>│   上线运行   │
│ （自然语言） │   ❓ 易失真  │ （工程实现） │   ❓ 滞后    │ （事后补救） │
└─────────────┘              └─────────────┘              └─────────────┘
      │                            │                            │
      ▼                            ▼                            ▼
   表达模糊                    经验依赖                     问题晚发现

第一，需求表达与系统执行之间存在鸿沟。 业务方的表述是自然语言，模糊、跳跃、依赖上下文；而系统需要的是结构化、精确、可执行的规约。中间的翻译工作，长期依赖人工。

第二，规范化依赖个人经验，稳定性差。 同一份需求，交由不同的工程师处理，产出的策略可能截然不同。规范的执行强度，取决于人的责任心，而非流程的约束力。

第三，合规审查滞后，问题暴露晚。 传统流程中，审查往往发生在交付后期甚至上线之后。一旦发现违规，返工代价巨大，且难以追溯根因。

三重困境叠加，导致规范化沦为"事后补救"，而非"事前内建"。

三、传统方案的局限：修修补补，难破根本

面对上述痛点，业界曾提出多种改良方案：

• 模板化需求文档：约束表达格式，但无法约束语义歧义；
• 人工评审门禁：增加审查环节，但引入人力瓶颈与主观偏差；
• 静态规则引擎：预设规则校验，但难以应对开放式、多领域的需求场景。

这些方案的共同短板在于------它们都试图在既有流程上"打补丁"，而没有重构需求进入系统的方式本身。

四、Agent 解决方案：以闭环取代补丁

真正的破局点，是让规范化能力前置到需求进入系统的第一刻，并通过 Agent 构建一个具备判断、追问、验证能力的闭环。

整套方案的宏观视图如下：

             ┌───────────────────────────────────────────┐
             │              需求输入（自然语言）             │
             └───────────────────┬───────────────────────┘
                                 ▼
                    ┌────────────────────────┐
                    │   调度中枢 Agent        │  ← 意图识别、按需分派
                    └────────────┬───────────┘
                                 ▼
        ┌────────────────────────┼────────────────────────┐
        ▼                        ▼                        ▼
  ┌───────────┐           ┌───────────┐            ┌───────────┐
  │ 权限专家   │           │ 安全专家   │            │ 流程专家   │
  │  Agent    │           │  Agent    │            │  Agent    │
  └─────┬─────┘           └─────┬─────┘            └─────┬─────┘
        └────────────────────────┼────────────────────────┘
                                 ▼
                    ┌────────────────────────┐
                    │  澄清交互（消歧义）      │
                    └────────────┬───────────┘
                                 ▼
                    ┌────────────────────────┐
                    │  自检验证（脚本+清单）    │
                    └────────────┬───────────┘
                                 ▼
                    ┌────────────────────────┐
                    │  PolicyRuntime 编译     │
                    │  → schema.json          │
                    └────────────────────────┘

三类角色协同------调度中枢、领域专家、自动化验证层------构成一条自输入至输出、层层收敛的规范化流水线。

五、核心机制：四个环节支撑起整个闭环

机制一：领域识别，按需激活专家 Agent

调度中枢在接收到需求后，首先做的不是"处理"，而是"分类"。

                需求 ──► [ 意图识别 ] ──► 领域判定
                              │
             ┌────────────────┼────────────────┐
             ▼                ▼                ▼
        ✅ 权限领域       💤 安全领域       💤 流程领域
        （激活）          （沉默）          （沉默）

它通过意图识别与关键词特征提取，判断需求归属------权限？安全？流程？随后按需激活对应的领域专家 Agent。未被命中的 Agent 保持沉默，不消耗资源，也不介入判断。

这种"按需激活"的设计，带来两个关键好处：

• 专业性：每个 Agent 深耕一域，内置该领域的模型知识（如 RBAC、ABAC），判断更准；
• 可扩展性：新增领域只需注册新的专家 Agent，主干流程无需改动。

领域专家的可插拔，让整套架构既专业又开放。

机制二：结构化提取，语义对齐

被激活的专家 Agent 依托领域模型，将自然语言转化为结构化规约（Spec）：

  "运营同学需要看订单数据，但不能改"
                │
                ▼  （权限专家 Agent · 基于 RBAC 模型）
  ┌────────────────────────────────┐
  │  role: operator                 │
  │  resource: order                │
  │  actions: [read]                │
  │  deny: [write, delete]          │
  └────────────────────────────────┘

领域模型的内嵌，保证了提取过程不是通用型的"猜意图"，而是基于专业语义的"精翻译"。

机制三：澄清交互，消除歧义

架构中最具巧思的一环，是澄清判断节点：

       ┌──────────────┐
       │  Spec 草稿    │
       └───────┬──────┘
               ▼
       ┌──────────────┐
       │ 是否存在歧义？│
       └───┬──────┬───┘
       是 │      │ 否
           ▼      ▼
    ┌─────────┐  ┌─────────┐
    │ 反问用户 │  │ 进入自检 │
    └────┬────┘  └─────────┘
         │
         ▼（用户补充）
      回到 Spec 草稿

当 Agent 检测到需求存在歧义、缺失或冲突，不会盲目生成，而是主动向用户发起追问，直至意图对齐。这一机制把"猜测执行"变成了"确认执行"。

合规的第一原则是意图清晰。澄清闭环，正是这一原则的工程化落地。

机制四：自检验证，规范兜底

生成的 Spec 不直接交付，而是进入自检环节------这也是整个闭环最能体现"内建规范"思想的一步。

   ┌─────────────────┐
   │   Spec 待检验    │
   └────────┬────────┘
            ▼
   ┌────────────────────────────────┐
   │  self_review scripts（脚本扫描）│  语法 · 字段 · 引用
   └────────┬───────────────────────┘
            ▼
   ┌────────────────────────────────┐
   │  checklist（清单核对）           │  覆盖率 · 合规性 · 安全性
   └────────┬───────────────────────┘
            ▼
      ✅ 全部通过 → 编译交付
      ❌ 任一失败 → 阻断 + 回溯

只有通过全部自检项的 Spec，才会进入 PolicyRuntime，最终编译为附带版本号、安全基线、审计日志级别的 schema.json。

自检的本质，是让 Agent 自己审查自己的产出------把审查能力从人转移到流程，把合规判断从事后转移到事中。

六、内部实现：自检机制与"三分法"架构

要让上述闭环真正落地，仅有理念是不够的，还需要一套清晰的内部架构支撑。我们采用的是 Orchestrator / Workflow / Policy 三分法------将调度、编排、策略三层职责彻底解耦，各司其职。

6.1 三分法：职责边界的一次清晰切割

┌──────────────────────────────────────────────────────────┐
│                    Orchestrator（调度层）                  │
│           意图识别 · 领域分派 · Agent 生命周期管理           │
│                       [ 通用 · 稳定 ]                       │
└────────────────────────────┬─────────────────────────────┘
                             ▼
┌──────────────────────────────────────────────────────────┐
│                    Workflow（编排层）                      │
│              流水线节点 · 流转规则 · 可配置编排             │
│                    [ 可编排 · 领域无关 ]                    │
└────────────────────────────┬─────────────────────────────┘
                             ▼
┌──────────────────────────────────────────────────────────┐
│                    Policy（策略层）  ⭐                    │
│         自检脚本 · 合规清单 · 领域模型 · 安全基线           │
│                [ 可插拔 · 可定制 · 企业专属 ]                │
└──────────────────────────────────────────────────────────┘

层次	职责	关键特征
Orchestrator	意图识别、领域分派、Agent 生命周期管理	无状态、轻量、通用
Workflow	定义规范化流水线的执行步骤与流转规则	可配置、可编排、领域无关
Policy	承载具体规范规则、合规基线、企业定制逻辑	可插拔、可版本化、企业专属

三层之间通过标准接口通信，任何一层的变更都不会污染其他层次。这种切割看似简单，却是整套架构能长期演进的根本保证。

6.2 Orchestrator：调度即路由

Orchestrator 的角色近似于"交通指挥中心"。它不理解具体的领域规则，只负责三件事：

• 识别------判断需求归属哪个领域；
• 激活------按需唤起对应的专家 Agent；
• 回收------任务完成后释放资源，保持系统轻量。

这一层刻意保持"薄"，任何领域知识都不下沉到 Orchestrator，以确保其通用性与稳定性。

6.3 Workflow：把流程沉淀为可编排的资产

Workflow 层定义了"需求如何流经系统"：

  [ 领域识别 ] → [ 结构化提取 ] → [ 澄清交互 ] → [ 自检验证 ] → [ 运行时编译 ]
        │              │              │              │              │
      节点1          节点2          节点3          节点4          节点5
        └──────────────┴───── 配置化流转规则 ──────┴──────────────┘

节点之间的流转规则以配置形式声明，而非硬编码。这意味着：

• 调整审查顺序，无需改代码；
• 新增审查步骤，只需注册新节点；
• 不同业务线，可以复用同一套 Workflow 骨架。

流程本身成为一种可管理的资产，而非散落在代码中的隐性逻辑。

6.4 Policy：整套架构最具创新的一层

如果说 Orchestrator 与 Workflow 是通用的骨架，那么 Policy 层就是可以千企千面的"血肉"。

Policy 可以按需定制企业化功能。 不同企业的合规诉求千差万别：

                    ┌──────────────────────┐
                    │   统一 Policy 引擎    │
                    │   （引擎稳定不变）     │
                    └──────────┬───────────┘
                               ▼
        ┌──────────────────────┼──────────────────────┐
        ▼                      ▼                      ▼
  ┌───────────┐         ┌───────────┐          ┌───────────┐
  │ 金融行业   │         │ 互联网企业 │          │ 政企客户   │
  │  Policy   │         │  Policy   │          │  Policy   │
  ├───────────┤         ├───────────┤          ├───────────┤
  │·数据分级   │         │·多租户隔离 │          │·等保合规   │
  │·最小权限   │         │·灰度发布   │          │·审计留痕   │
  │·反洗钱规则 │         │·限流策略   │          │·国密算法   │
  └───────────┘         └───────────┘          └───────────┘

三分法架构下，Policy 层作为可插拔组件，支持企业按需定制：

• 规则可扩展------企业可在标准 checklist 之外，注入专属合规项（如内部安全红线、行业监管条款）；
• 模型可替换------RBAC、ABAC、ReBAC 等权限模型可按需切换或叠加；
• 基线可配置------安全基线、审计粒度、日志级别，均以 Policy 形式声明；
• 版本可管理------每一份 Policy 都可版本化、可灰度、可回滚，与企业的合规审计天然对齐。

自检机制的强大之处，也正来源于 Policy 的可定制性------同一套自检引擎，加载不同的 Policy，就能服务不同企业、不同场景的合规诉求。

引擎稳定，策略灵活。这正是"策略即代码"思想在企业级场景下的最佳落地形态。

6.5 自检机制的内部实现：引擎 + 策略双轮驱动

回到自检本身，其内部实现遵循"引擎 + 策略"的双轮结构：

   ┌──────────────────────┐       ┌──────────────────────┐
   │    自检引擎           │◄─────►│    自检策略           │
   │  （由 Workflow 调度） │  加载  │  （由 Policy 提供）   │
   ├──────────────────────┤       ├──────────────────────┤
   │ ·加载策略             │       │ ·self_review scripts │
   │ ·执行扫描             │       │ ·checklist            │
   │ ·聚合结果             │       │ ·企业自定义规则       │
   │ ·放行 / 阻断          │       │ ·合规基线             │
   └──────────────────────┘       └──────────────────────┘
          稳定内核                        灵活外延

引擎不感知规则细节，规则不关心执行时机------两者通过标准契约协作。这种解耦，让自检能力既稳定可靠 ，又灵活可塑。

七、机制价值：规范与合规如何被"内建"

回看整条闭环，规范与合规并非依赖事后审计，而是通过机制内建于每一个环节：

环节	内建的规范/合规能力
领域识别	按需激活专家，分域治理，避免越界判断
结构化提取	强制对齐领域模型标准
澄清交互	保证意图无歧义，全程可追溯
自检验证	脚本+清单双重兜底，阻断违规上线
运行时编译	输出可审计、可回滚的规约产物

深层价值在于：合规不再是一道关卡，而是一条河床------需求顺流而下，天然被约束在规范的边界之内。

      传统模式                        Agent 闭环模式
   ┌─────────────┐                 ┌─────────────┐
   │   需求       │                 │   需求       │
   └──────┬──────┘                 └──────┬──────┘
          ▼                                ▼
   ┌─────────────┐                 ══════════════════
   │  人工处理    │                  规范化河床（内建）
   └──────┬──────┘                 ══════════════════
          ▼                                ▼
     ⚠️ 事后审查                       ✅ 天然合规

八、结语：从"人管流程"到"流程自管"

传统研发工作流依赖人的经验与责任心去守住规范；而基于 Agent 的闭环实践，把规范化能力沉淀为架构本身的属性。

领域专家的按需激活，保证了专业判断的深度；澄清交互的双向对齐，保证了意图传递的精度；自检机制的自动兜底，保证了交付产物的可靠性；三分法架构与可定制的 Policy 层，则让这套能力具备了服务不同企业、不同场景的普适性。

四者合力，完成了一次治理哲学的转变------让流程具备自我约束的能力，让合规成为系统的默认状态。

当每一次需求输入，都能自动经历识别、激活、提取、澄清、自检的完整闭环，规范便不再是口号，而是每一份交付物的底色。