Workflow 系列（02）：设计范式——四层架构、三种 Context 传递模式与确认门设计

📅 2026/6/30 1:41:44 👁️ 次浏览

从脚本到工程一个工作流的早期形态往往是单一文件：一个 Markdown 描述全部逻辑，所有配置硬编码其中。这在小规模时能用，随着工作流增长会出现三个问题：修改执行参数（如超时时长）需要找到并修改多处不同子 Agent 的 task prompt 散落在工作流定义里，难以独立测试安全策略和业务逻辑混在一起，合规审查困难四层架构解决这三个问题。四层架构Policy Layer policy.md 执行原则，全局约束 → 谁能做什么，高风险操作的授权规则 Workflow Layer workflow.md Phase / Step 结构，路由逻辑 → 工作流的骨架，不包含具体任务内容 TaskSpec Layer templates/ 子 Agent 的 task prompt 模板 → 每个子任务的详细指令和输出契约 Tool/Skill Layer skills/ 原子能力 → 可跨工作流复用的 Skill 定义每层只改自己的事，不跨层。# ✅ 正确：修改分析的超时时间 → 改 workflow.md 的配置 phase_3_analyze: timeout: 30m ← 在 Workflow Layer 修改 # ✅ 正确：修改分析的输出格式 → 改 templates/analyze.md ## Output Contract {"confidence": float, "root_cause": str, ...} ← 在 TaskSpec Layer 修改 # ❌ 错误：在 task prompt 里写权限规则（权限属于 Policy Layer） # ❌ 错误：在 workflow.md 里写具体的分析步骤（步骤属于 TaskSpec Layer）工作流修改的安全性由分层保证：改 templates/ 只影响对应子 Agent 的输出，改 policy.md 不会意外破坏路由逻辑。Context 传递模式子 Agent 需要"知道什么"，是工作流设计里最容易犯错的地方。把主 Agent 的全部历史传给每个子 Agent 是最常见的错误。Context 爆炸，子 Agent 处理变慢，输出质量下降，Token 成本翻倍。根据子 Agent 的实际需要选择传递模式，有三种：accumulate（汇总传递）定义：传递工作流到目前为止的所有相关输出。适用：子 Agent 需要对整个工作流的多个阶段结论做汇总或报告。# Phase 7：写结案通知，需要整个工作流的结论phase_7_notify:context_mode:accumulatecontext_inputs:-phases.phase3.root_cause_summary-phases.phase4.fix_summary-phases.phase5.commit_result-phases.phase6.review_statusPhase 7 的子 Agent 需要根因、修复摘要、提交结果、Review 状态，缺少任何一个都写不出完整的通知。last_only（仅上一步）定义：只传递上一个 Pha

相关新闻