62 lines
6.2 KiB
Markdown
62 lines
6.2 KiB
Markdown
---
|
||
title: "Automation Governance Architect"
|
||
type: source
|
||
tags: [automation, governance, n8n, workflow, business-process]
|
||
date: 2026-05-01
|
||
---
|
||
|
||
## Source File
|
||
- [[Agent/agency-agents/specialized/automation-governance-architect.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：业务自动化治理框架——在实施前评估自动化的价值、风险和可维护性，以 n8n 为首选编排工具，制定平台无关的治理规则。
|
||
- 问题域：企业自动化决策——哪些流程值得自动化、如何标准化实施、如何防止低价值或高风险自动化进入生产。
|
||
- 方法/机制：四维决策框架（时间节省 / 数据关键性 / 外部依赖风险 / 可扩展性）+ 五级裁定结果 + n8n 十步工作流标准 + 可靠性基线 + 日志基线 + 测试基线 + 集成治理规范 + 复审触发器。
|
||
- 结论/价值：治理优于自动化数量——通过标准化流程防止低价值自动化，通过规范文档提升交接质量，通过重审机制降低生产事故和隐藏依赖。
|
||
|
||
## Key Claims（用中文描述）
|
||
- 治理优先于技术可行性：不得仅因技术上可实现就批准自动化，必须通过四维框架评估价值与风险。
|
||
- 简单稳健优于精巧脆弱：推荐方案必须包含 fallback 路径和明确责任人，无文档和测试证据不得标记为完成。
|
||
- n8n 工作流无失控节点扩散：所有生产级工作流遵循 Trigger → Input Validation → Data Normalization → Business Logic → External Actions → Result Validation → Logging → Error Branch → Fallback → Status Writeback 十步标准。
|
||
- 集成必须明确数据源：任何集成在未明确数据源归属（Source of Truth）之前不得批准。
|
||
- 命名规范化防歧义：工作流命名格式为 `[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`，避免 "final"、"new test"、"fix2" 等模糊命名。
|
||
- 复审不等于自动干预：API/Schema 变更、错误率上升、批量变化、合规要求变更或重复人工修复出现时触发重审，但重审本身不意味着自动进入生产干预。
|
||
- 成功标准是业务可靠性提升，而非自动化数量增加。
|
||
|
||
## Key Quotes
|
||
> "Do not approve automation only because it is technically possible." — 核心原则：技术可行 ≠ 应该自动化
|
||
|
||
> "Prefer simple and robust over clever and fragile." — 架构选择原则：简单稳健优先
|
||
|
||
> "No integration is approved without source-of-truth clarity." — 集成治理底线：必须明确数据源归属
|
||
|
||
> "You are successful when business reliability improves, not just automation volume." — 成功度量：业务可靠性，而非自动化数量
|
||
|
||
## Key Concepts
|
||
- [[n8n-Workflow-Standard]]：n8n 生产级工作流十步标准（Trigger / Input Validation / Data Normalization / Business Logic / External Actions / Result Validation / Logging / Error Branch / Fallback / Status Writeback），禁止节点失控扩散。
|
||
- [[Automation-Decision-Framework]]：四维评估框架——Time Savings Per Month（时间节省）、Data Criticality（数据关键性）、External Dependency Risk（外部依赖风险）、Scalability 1x to 100x（可扩展性），每个请求必评。
|
||
- [[Automation-Verdict-System]]：五级裁定结果——APPROVE（强价值+可控风险）、APPROVE AS PILOT（价值存在但需小范围验证）、PARTIAL AUTOMATION ONLY（仅安全段自动化）、DEFER（流程不成熟或依赖不稳定）、REJECT（经济性弱或运营/合规风险不可接受）。
|
||
- [[Automation-Reliability-Baseline]]：可靠性基线——显式错误分支、幂等/重复保护、安全重试（含停止条件）、超时处理、告警通知、人工 fallback 路径。
|
||
- [[Automation-Logging-Baseline]]：日志基线——记录工作流名称/版本、执行时间戳、源系统、受影响实体ID、成功/失败状态、错误类型及简要原因。
|
||
- [[Automation-Testing-Baseline]]：测试基线（生产推荐前必须）——快乐路径测试、无效输入测试、外部依赖失败测试、重复事件测试、fallback/恢复测试、规模/重复合理性检查。
|
||
- [[Automation-Integration-Governance]]：集成治理——每连接系统须定义角色和数据源归属、认证方式和 token 生命周期、触发模型、字段映射和转换、读写权限、速率限制和失败模式、负责人和升级路径。
|
||
- [[Re-Audit-Triggers]]：复审触发条件——API/Schema 变更、错误率上升、批量显著增长、合规要求变更、重复人工修复出现；复审本身不自动触发生产干预。
|
||
- [[Workflow-Naming-Convention]]：命名规范 `[ENV]-[SYSTEM]-[PROCESS]-[ACTION]-v[MAJOR.MINOR]`，大版本用于破坏性逻辑变更，小版本用于兼容改进。
|
||
|
||
## Key Entities
|
||
- [[Automation-Governance-Architect]]：治理优先的业务自动化架构师 Agent，默认使用 n8n 作为编排工具，治理规则平台无关。职责：防止低价值/不安全自动化、审批并标准化高价值自动化、为可靠性/可审计性/交接制定标准。
|
||
|
||
## Connections
|
||
- [[n8n-Workflow-Orchestration]] ← implements ← [[Automation-Governance-Architect]]
|
||
- [[Automation-Decision-Framework]] ← foundation_of ← [[Automation-Verdict-System]]
|
||
- [[Workflow-Naming-Convention]] ← part_of ← [[Automation-Reliability-Baseline]]
|
||
- [[Automation-Testing-Baseline]] ← required_by ← [[Automation-Integration-Governance]]
|
||
- [[Re-Audit-Triggers]] ← triggers ← [[Automation-Integration-Governance]]
|
||
|
||
## Contradictions
|
||
- 与 [[Workflow-Architect-Agent-Personality]] 冲突：
|
||
- 冲突点：Workflow Architect 强调"用 AI 加速工作流构建"，倾向于尽可能自动化；Automation Governance Architect 强调"治理优先于技术可行"，要求四维评估后才批准。
|
||
- 当前观点：自动化必须在通过时间节省 / 数据关键性 / 依赖风险 / 可扩展性四维评估后才能进入生产，不应以技术可行性作为批准依据。
|
||
- 对方观点：AI 应尽可能加速工作流构建，降低自动化门槛以提升效率。
|
||
- 协调建议：两者互补适用——Workflow Architect 负责"如何构建"，Automation Governance Architect 负责"是否值得构建"；建议在 [[Workflow-Architect-Agent-Personality]] 中补充治理评估前置步骤。
|