6.2 KiB
6.2 KiB
title, type, tags, date
| title | type | tags | date | |||||
|---|---|---|---|---|---|---|---|---|
| Automation Governance Architect | source |
|
2026-05-01 |
Source File
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 中补充治理评估前置步骤。