【AI学习从零至壹】AI agent自动化工作流

AI agent自动化工作流

• • 📚 目录
  • 第一章：系统宏观架构 (System Architecture)
  • • 1.1 核心设计哲学：OMNE
    • 1.2 架构三支柱
    • 1.3 数据流向全景图
  • 第二章：统一内核实现 (Unified Kernel Implementation)
  • • 2.1 Mixin 模式的极致运用
    • 2.2 闭环控制流 (Closed-Loop FSM)
    • 2.3 知识边界感知 (Metacognition)
  • 第三章：群体智能编排 (Swarm Orchestration)
  • • 3.1 蜂群数据库设计 (Schema Design)
    • 3.2 Worker 协议与通信
    • 3.3 核心 Worker 解析：Backend Architect
  • 第四章：长期记忆系统 (Long-Term Memory System)
  • • 4.1 记忆的三层架构
    • 4.2 情感计算与重要性评估
    • 4.3 错误反向检索生成 (Error RAG)
  • 第五章：智能决策与路由 (Intelligence & Routing)
  • • 5.1 5场景决策树 (5-Scenario Decision Tree)
    • 5.2 增强型任务拆解 (Enhanced Decomposition)
    • 5.3 Skill 自动发现机制
  • 第六章：技术栈与关键算法 (Tech Stack & Algorithms)
  • • 6.1 核心技术栈
    • 6.2 关键算法实现
  • 第七章：整合与交付 (Integration & Delivery)
  • • 7.1 冲突检测与合并策略
    • 7.2 质量评分体系

📚 目录

第一章：系统宏观架构 (System Architecture)

1.1 核心设计哲学：OMNE

本系统的核心不仅仅是执行任务，而是进化。在 core/ltm/models.py 中，我发现了 OMNE (Open Mind for Networked Evolution) 的设计理念。这不仅是一个缩写，它代表了系统试图模仿人类大脑皮层柱状结构的野心。

• Open Mind: 系统对新工具（Skills）和新知识是开放的。
• Networked: 智能体之间通过 Swarm 协议互联。
• Evolution: 通过错误（Error RAG）和成功经验（Procedural Memory）不断自我优化。

1.2 架构三支柱

系统由三个相互独立又紧密耦合的子系统构成：

1.3 数据流向全景图

一个典型的任务流向如下：

渲染错误: Mermaid 渲染失败: No diagram type detected matching given configuration for text: User Prompt -> Intelligence (分析 & 场景选择) -> Knowledge Boundary (元认知判断: 快思考 vs 慢思考) -> Enhanced Decomposer (原子任务拆解 + LTM 检索) -> Unified Kernel (启动闭环) -> Swarm Orchestrator (分发任务) -> Worker A (Coding) -> Worker B (Testing) -> Worker C (Research) -> Integrator (合并产出 & 冲突解决) -> Validator (质量验证) -> (If Fail) -> Reflexion Loop (反思 & 修复) -> Delivery

第二章：统一内核实现 (Unified Kernel Implementation)

2.1 Mixin 模式的极致运用

UnifiedKernel 类本身几乎是空的，它完全通过继承五个 Mixin 来组合能力。这种设计极大地提高了代码的解耦性和可测试性。

• 代码位置: core/kernel/unified.py
• 继承链:class UnifiedKernel(
  KernelBaseMixin, # 基础状态管理
  KernelAnalysisMixin, # 意图分析
  KernelExecutionMixin, # 对接 Swarm
  KernelClosedLoopMixin, # 闭环逻辑
  KernelQualityMixin, # 质量控制
  KernelRepairMixin # 修复逻辑
  ):

亮点: 这种设计允许我们在未来轻松添加新的能力（比如 KernelEmotionMixin），而不需要修改核心类。

2.2 闭环控制流 (Closed-Loop FSM)

在 core/kernel/mixins/closed_loop.py 中，实现了一个复杂的有限状态机 (FSM)。

• 状态 (LoopState): PENDING, RUNNING, PAUSED, COMPLETED, FAILED
• 阶段 (LoopPhase):
• EXECUTE: 执行阶段，调用 Swarm。
• INTEGRATE: 整合阶段，调用 Integrator。
• VALIDATE: 验证阶段，运行测试。
• RESEARCH: (仅在失败时) 调研阶段，调用 Search Agent。
• FIX: (仅在失败时) 修复阶段，应用修复方案。
• DELIVER: 交付阶段。

核心逻辑:

while True:
if phase == VALIDATE and score < threshold:
next_phase = RESEARCH # 自动进入修复循环
elif phase == FIX:
next_phase = EXECUTE # 修复后重新执行

这种死循环保护机制是系统“自治”的关键。

2.3 知识边界感知 (Metacognition)

在 core/knowledge_boundary.py 中，系统实现了一个简单的元认知模块。

• 功能: 在执行任务前，先问自己“我知道怎么做吗？”
• 输出:
  • Thinking Mode: “Fast” (直接干) vs “Slow” (先调研)。
  • Confidence: 置信度分数 (0.0 – 1.0)。
• 实现: 如果置信度低于阈值，EnhancedDecomposer 会自动在任务列表头部插入 TaskType.RESEARCH 类型的任务。

第三章：群体智能编排 (Swarm Orchestration)

3.1 蜂群数据库设计 (Schema Design)

Swarm 不依赖内存状态，而是使用 SQLite (swarm_core.db) 进行持久化。这意味着即使进程崩溃，任务状态也不会丢失。

• 代码位置: core/swarm.py
• 核心表结构:
  • swarm_sessions: 记录整个会话的状态，主任务，子任务总数。
  • tasks: 记录每个原子任务。
    • task_id: UUID
    • parent_id: 关联的 Session
    • worker_type: 指定需要的 Agent 类型 (e.g., ‘backend-architect’)
    • status: ‘pending’, ‘running’, ‘completed’, ‘failed’
    • priority: 优先级 (决定执行顺序)
    • payload: JSON 格式的具体指令

3.2 Worker 协议与通信

Worker 是独立的执行单元。所有的 Worker 都继承自 BaseWorker。

• 通信协议: JSON Payload。
  • Input: {"action": "…", "context": {…}}
  • Output: {"status": "success", "data": {…}}
• 并行机制: SwarmOrchestrator.get_parallel_subtasks() 方法会查询数据库，找出所有 status='pending' 且依赖已满足的任务，一次性返回给主进程并行调用工具执行。

3.3 核心 Worker 解析：Backend Architect

在 core/workers/worker_coder.py 中，CoderWorker (即 Backend Architect) 展现了惊人的细节。

• 静态分析能力: 它不仅仅是写文件。它有一个 analyze 动作，使用 Python 原生的 ast (Abstract Syntax Tree) 模块解析代码。tree = ast.parse(data)
  analysis = {
  "classes": [node.name for node in ...],
  "functions": [node.name for node in ...],
  "imports": [...]
  }
  这意味着它在修改代码前，真的“看懂”了代码结构，而不是盲目替换文本。

第四章：长期记忆系统 (Long-Term Memory System)

4.1 记忆的三层架构

在 core/ltm/models.py 和 manager.py 中，系统实现了一个类脑的记忆结构：

4.2 情感计算与重要性评估

这是最令人惊讶的部分。系统会计算“情感”。

• Emotional Valence (情感效价):
  • 成功且高质量的任务 = 正向情感 (+0.7 ~ +1.0)。
  • 失败或严重的错误 = 负向情感 (-0.5 ~ -1.0)。
• Importance Score (重要性):
  • 错误修复类任务、复杂任务会被标记为高重要性。
  • 系统会优先保留高重要性、高情感强度的记忆（模仿人类遗忘机制）。

4.3 错误反向检索生成 (Error RAG)

在 core/memory.py 中实现。

• Error Signature (错误签名):def _extract_error_signature(self, error_message):
  # 去除行号和文件路径的差异，只保留核心堆栈信息
  clean = re.sub(r'line \\d+', 'line N', clean)
  return md5(clean)
• 工作流:
• 遇到报错 -> 生成签名 -> 存入 errors/ 目录。
• 修复报错 -> 记录修复方案 -> 关联到该签名。
• 下次遇到同签名错误 -> 直接读取修复方案 -> 自动修复。

第五章：智能决策与路由 (Intelligence & Routing)

5.1 5场景决策树 (5-Scenario Decision Tree)

core/scenario_selector.py 定义了系统如何面对不同难度的任务。这避免了“杀鸡用牛刀”。

5.2 增强型任务拆解 (Enhanced Decomposition)

core/enhanced_decomposer.py 是任务的“粉碎机”。

• Prompt Patterns: 使用正则表达式匹配用户意图（如 r"创建|新建|编写" -> TaskType.CODE_WRITE）。
• Agent Mapping: 自动将任务类型映射到最合适的 Agent（如 CODE_WRITE -> backend-architect, RESEARCH -> search）。
• Dependency Graph: 构建任务依赖图，进行拓扑排序，确保执行顺序正确。

5.3 Skill 自动发现机制

core/skill_discovery.py 允许系统扩展能力。

• 它会扫描 .trae/skills/ 目录下的 skill.yaml。
• 如果发现本地安装了新 Skill（比如用户刚写了一个 NovelWriter），它会自动将其注册到能力列表中。
• 支持 Fallback Chain: Local Skill -> Built-in Agent -> General LLM。

第六章：技术栈与关键算法 (Tech Stack & Algorithms)

6.1 核心技术栈

• Language: Python 3.9+ (大量使用了 Type Hints, Dataclasses, Enum)。
• Storage:
  • SQLite: 结构化数据 (Swarm State)。
  • JSON: 配置文件与中间产物。
  • Markdown: 记忆存储 (便于人类阅读和 LLM 理解)。
• Code Analysis: ast (Python Abstract Syntax Tree)。
• Concurrency: 基于 subprocess 和数据库状态锁的伪并行（更安全，易于调试）。

6.2 关键算法实现

第七章：整合与交付 (Integration & Delivery)

7.1 冲突检测与合并策略

core/integrator.py 是最后一道防线。

• 它定义了 ConflictType: DUPLICATE_CONTENT, INCONSISTENT_INTERFACE 等。
• 合并策略 (Integration Rules):
  • Code: merge_with_imports (智能合并 import 语句)。
  • Docs: concatenate_with_toc (生成目录并拼接)。
  • Config: deep_merge (递归合并 JSON/YAML)。

7.2 质量评分体系

系统不会盲目交付。它会计算一个 Quality Score。

• 如果 Score < 0.7 (阈值)，系统会将状态标记为 FAILED，这会触发 KernelClosedLoopMixin 进入 RESEARCH -> FIX 流程。
• 评分维度包括：冲突数量、测试通过率、代码规范性（通过 AST 分析）。

https://gitee.com/nrflying/auto-workflow