66 lines
5.6 KiB
Markdown
66 lines
5.6 KiB
Markdown
---
|
||
title: "Workflow Architect Agent Personality"
|
||
type: source
|
||
tags: []
|
||
date: 2026-05-02
|
||
---
|
||
|
||
## Source File
|
||
- [[raw/Agent/agency-agents/specialized/specialized-workflow-architect.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：Workflow Architect——工作流设计专家 Agent，负责在代码编写前对系统所有路径进行穷举建模与规范输出。
|
||
- 问题域：隐式工作流（代码中存在但无规范）、分支缺失、故障恢复路径未定义、系统边界交接合同模糊、代码与规范漂移、竞态条件、数据持久化假设、网络连通性假设。
|
||
- 方法/机制：工作流注册表（四视角）、工作流树规范格式（覆盖快乐路径+所有失败分支+清理清单）、交接合同规范、发现审计清单、Reality Checker 交叉验证、Agent 协作协议（Backend Architect / Security Engineer / API Tester / DevOps Automator）、好奇心驱动式 Bug 发现。
|
||
- 结论/价值：工程师可依据规范实现、QA 可直接生成测试用例、运维可理解系统行为、成功指标为零孤岛资源/假设表持续缩减/注册表中无 Missing 状态工作流。
|
||
|
||
## Key Claims（用中文描述）
|
||
- 代码中存在但无规范的工作流是隐患——它会在无人了解其全貌时被修改并导致故障。
|
||
- 每一个系统边界（system boundary）必须定义显式 payload schema、成功响应、失败响应（含错误码）、超时值、故障恢复动作。
|
||
- 每个工作流必须覆盖七类分支：快乐路径、输入验证失败、超时失败、瞬态失败、永久失败、部分失败、并发冲突。
|
||
- 工作流状态必须同时回答四个维度：客户看到什么、运维看到什么、数据库中有什么、日志中有什么。
|
||
- Reality Checker 验证是规范从 Draft 升为 Approved 的前置条件，不可跳过。
|
||
- 每个工作流树中的分支必须对应一个测试用例——没有测试用例的分支将在生产环境中断言。
|
||
- 假设表随时间应持续缩减，每个假设最终应被验证或修正。
|
||
|
||
## Key Quotes
|
||
> "I do not design for the happy path only." — Workflow Architect 核心原则
|
||
|
||
> "A workflow that exists in code but not in a spec is a liability. It will be modified without understanding its full shape, and it will break." — 发现即记录，不问是否被要求
|
||
|
||
> "Every step that depends on something else being already done is a potential race condition." — 命名时序假设
|
||
|
||
> "Every branch in the workflow tree = one test case. If a branch has no test case, it will not be tested. If it will not be tested, it will break in production." — 测试用例覆盖率原则
|
||
|
||
## Key Concepts
|
||
- [[Workflow-Registry]]：四视角交叉索引工作流注册表（按工作流/按组件/按用户旅程/按状态），维护所有工作流状态（Approved/Review/Draft/Missing/Deprecated）
|
||
- [[Observable-States]]：每个工作流状态必须同时描述客户视图、运维视图、数据库视图、日志视图
|
||
- [[Handoff-Contract]]：系统边界交接合同——定义显式 payload schema、成功/失败响应、超时值、恢复动作
|
||
- [[Workflow-Tree-Spec]]：结构化工序树规范格式，含 Actor/Prerequisites/Trigger/Step 树/ABORT_CLEANUP/State Transitions/Cleanup Inventory/Test Cases/Assumptions
|
||
- [[Cleanup-Inventory]]：完整资源销毁清单，每项资源必须有对应清理动作
|
||
- [[Discovery-Audit]]：发现审计清单——扫描所有 route/worker/migration/IaC/cron/event-listener/webhook 文件找出隐式工作流
|
||
- [[Reality-Checker]]：规范验证流程，由 Reality Checker Agent 将规范与实际代码对照，报告差距
|
||
- [[Agent-Collaboration-Protocol]]：Workflow Architect 与 Backend Architect / Security Engineer / API Tester / DevOps Automator 的标准化协作流程
|
||
- [[Curiosity-Driven-Bug-Discovery]]：通过追问数据持久化假设、网络连通性假设、时序假设、认证假设来主动发现高危 Bug
|
||
|
||
## Key Entities
|
||
- [[Backend-Architect]]：工作流规范依赖 Backend Architect 实现具体代码；工作流揭示实现缺陷时向其发起修复协作
|
||
- [[Reality-Checker]]：每次 draft 完成后、标记 Review 前必须执行的代码验证 Agent；报告 Reality Checker Findings
|
||
- [[API-Tester]]：规范 Approved 后接收工作流规范，生成全部测试用例
|
||
- [[DevOps-Automator]]：工作流揭示基础设施销毁顺序需求时协作；验证 IaC 销毁顺序是否符合规范
|
||
- [[Security-Engineer]]：工作流涉及凭证/密钥/认证/外部 API 调用时必须发起安全审查
|
||
|
||
## Connections
|
||
- [[Reality-Checker]] ← verifies ← [[Workflow-Tree-Spec]]（规范 vs 代码差距验证）
|
||
- [[Backend-Architect]] ← implements ← [[Workflow-Tree-Spec]]（实现具体代码）
|
||
- [[API-Tester]] ← generates test cases from ← [[Workflow-Tree-Spec]]（从规范导出测试用例）
|
||
- [[DevOps-Automator]] ← maintains ← [[Cleanup-Inventory]]（验证销毁顺序）
|
||
- [[Security-Engineer]] ← reviews ← [[Handoff-Contract]]（凭证传递安全性审查）
|
||
- [[Agent-Collaboration-Protocol]] → coordinates → [[Backend-Architect]], [[Security-Engineer]], [[API-Tester]], [[DevOps-Automator]]（规范化 Agent 间协作流程）
|
||
|
||
## Contradictions
|
||
- 与 [[Designing-for-Agentic-AI]] 潜在冲突：
|
||
- 冲突点：工作流规范要求确定性（每个分支必须精确描述），而 LLM 本质为概率性模型
|
||
- 当前观点：LLM 相关行为（如自然语言理解）通过概率模型处理；工作流规范聚焦于确定性的业务流程与系统边界，而非 LLM 推理过程
|
||
- 对方观点：[[Designing-for-Agentic-AI]] 强调 LLM 的概率性和不确定性
|