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

Ne0inhk

— 10 min read

AI agent自动化工作流

📚 目录

  1. 第一章：系统宏观架构 (System Architecture)
    • 1.1 核心设计哲学：OMNE
    • 1.2 架构三支柱：Kernel, Swarm, Memory
    • 1.3 数据流向全景图
  2. 第二章：统一内核实现 (Unified Kernel Implementation)
    • 2.1 Mixin 模式的极致运用
    • 2.2 闭环控制流 (Closed-Loop Finite State Machine)
    • 2.3 知识边界感知 (Metacognition)
  3. 第三章：群体智能编排 (Swarm Orchestration)
    • 3.1 蜂群数据库设计 (Schema Design)
    • 3.2 Worker 协议与通信
    • 3.3 核心 Worker 解析：Backend Architect
  4. 第四章：长期记忆系统 (Long-Term Memory System)
    • 4.1 记忆的三层架构 (Episodic, Semantic, Procedural)
    • 4.2 情感计算与重要性评估
    • 4.3 错误反向检索生成 (Error RAG)
  5. 第五章：智能决策与路由 (Intelligence & Routing)
    • 5.1 5场景决策树 (5-Scenario Decision Tree)
    • 5.2 增强型任务拆解 (Enhanced Decomposition)
    • 5.3 Skill 自动发现机制
  6. 第六章：技术栈与关键算法 (Tech Stack & Algorithms)
    • 6.1 核心技术栈
    • 6.2 关键算法实现
  7. 第七章：整合与交付 (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. Unified Kernel (统一内核): 位于 core/kernel/unified.py。它是系统的“前额叶皮层”，负责高级决策、计划和反思。它不直接干脏活，而是指挥 Swarm。
  2. Swarm Orchestrator (蜂群编排器): 位于 core/swarm.py。它是系统的“运动皮层”和“脊髓”，负责将内核的指令转化为具体的 Worker 动作，并管理并行执行的状态。
  3. LTM System (长期记忆系统): 位于 core/ltm/。它是系统的“海马体”，负责存储经历、提取知识、固化技能。

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

继承链:

classUnifiedKernel( 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):
    1. EXECUTE: 执行阶段，调用 Swarm。
    2. INTEGRATE: 整合阶段，调用 Integrator。
    3. VALIDATE: 验证阶段，运行测试。
    4. RESEARCH: (仅在失败时) 调研阶段，调用 Search Agent。
    5. FIX: (仅在失败时) 修复阶段，应用修复方案。
    6. DELIVER: 交付阶段。

核心逻辑:

whileTrue: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 中，系统实现了一个类脑的记忆结构：

  1. Episodic Memory (情景记忆): 记录每一次交互的流水账。
    • 包含：时间戳、用户指令、执行结果、情感效价。
  2. Semantic Memory (语义记忆): 从情景记忆中抽象出的知识点。
    • 例如：多次在 Python 中使用 FastAPI 成功，就会形成一条关于 FastAPI 的语义记忆。
    • Consolidation (固化): 当某类情景记忆重复出现（阈值默认 3 次），系统会自动将其转化为语义记忆。
  3. Procedural Memory (程序记忆): 针对特定任务的最佳实践步骤（SOP）。

4.2 情感计算与重要性评估

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

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

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

在 core/memory.py 中实现。

  • 工作流:
    1. 遇到报错 -> 生成签名 -> 存入 errors/ 目录。
    2. 修复报错 -> 记录修复方案 -> 关联到该签名。
    3. 下次遇到同签名错误 -> 直接读取修复方案 -> 自动修复。

Error Signature (错误签名):

def_extract_error_signature(self, error_message):# 去除行号和文件路径的差异，只保留核心堆栈信息 clean = re.sub(r'line \d+','line N', clean)return md5(clean)

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

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

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

  1. Prompt Enhancement (复杂度 1-2): 简单的改名、润色。不启动 Swarm，直接 LLM 返回。
  2. Skill Reuse (复杂度 3-5 + 有 Skill): 发现有现成工具（如 search），直接调用。
  3. Plan + Review (复杂度 3-5 + 无 Skill): 默认模式。先生成计划，用户确认，执行，最后 Review。
  4. Lead-Member (复杂度 6-10): 复杂的项目开发。指定一个 Leader Agent 负责协调，多个 Member Agent 并行开发。
  5. Composite (复杂度 10+): 复合模式，任务套任务。

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 关键算法实现

  1. 拓扑排序 (Topological Sort): 用于任务依赖解析，确保子任务执行顺序。
  2. MD5 Hashing: 用于生成一致性的错误签名和任务 ID。
  3. 加权评分算法:
    • 在 Integrator 中计算 quality_score。
    • 在 LTM 中计算 importance_score。
    • 公式示例: Score = Base + Weight_A * Factor_A + Weight_B * Factor_B。

第七章：整合与交付 (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

Read more

手把手教你开发“AI数据分析师”：利用IPIDEA + 智能体实现全网数据洞察

手把手教你开发“AI数据分析师”：利用IPIDEA + 智能体实现全网数据洞察

前言：为何需要构建一个更智能的数据助手 在当前人工智能的浪潮中，大语言模型（LLM）驱动的智能体（Agent）展现了巨大的潜力。理论上，它们可以自动化执行任务、分析数据，成为我们的得力助手。但在实际开发和使用中，我们常常会遇到一个瓶颈：智能体似乎“不够聪明”，无法获取最新、最真实的数据。这篇将记录并分享如何解决这一核心痛点，通过将智能体与专业的网络数据采集服务（IPIDEA）相结合，从零到一构建一个真正具备全网数据洞察能力的“AI数据分析师”。 第一章 为何我们的智能体“不够聪明” 在着手解决问题之前，首先需要清晰地界定问题本身。智能体在数据获取层面的“不聪明”主要源于两个相互关联的障碍：大模型自身的局限性和传统网络数据抓取的技术壁垒。 1.1 大模型的数据滞后与“幻觉”痛点 大语言模型的能力根植于其庞大的训练数据。然而，这些数据并非实时更新的。绝大多数模型的知识都存在一个“截止日期”，它们无法知晓在该日期之后发生的新闻、发布的财报、变化的商品价格或网络热点。当我们向智能体询问这些实时性要求高的问题时，它可能会坦白自己的知识局限，或者更糟糕地，它会根据已有的模式“

By Ne0inhk
Flutter for OpenHarmony：Flutter 三方库 dart_mcp — 开启鸿蒙端的 AI Agent 通信协议新纪元（适配鸿蒙 HarmonyOS Next ohos）

Flutter for OpenHarmony：Flutter 三方库 dart_mcp — 开启鸿蒙端的 AI Agent 通信协议新纪元（适配鸿蒙 HarmonyOS Next ohos）

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net。 Flutter for OpenHarmony：Flutter 三方库 dart_mcp — 开启鸿蒙端的 AI Agent 通信协议新纪元（适配鸿蒙 HarmonyOS Next ohos） 前言 随着生成式 AI 的爆发，Model Context Protocol (MCP) 正逐渐成为连接大型语言模型（LLM）与外部工具（Tools）、数据源（Resources）及上下（Context）的标准开放协议。它由 Anthropic 发起，旨在解决 AI 代理在获取现实世界信息时的碎片化问题。 在 Flutter for OpenHarmony 开发中，我们不仅关注 UI

By Ne0inhk
狂揽 10 万 + 星标！2026 本地 AI 顶流 OpenClaw 全攻略：小白 10 分钟零失败部署 + 免费一键文档

狂揽 10 万 + 星标！2026 本地 AI 顶流 OpenClaw 全攻略：小白 10 分钟零失败部署 + 免费一键文档

狂揽 10 万 + 星标！2026 本地 AI 顶流 OpenClaw 全攻略：小白 10 分钟零失败部署 + 免费一键文档 最近 AI 圈彻底被一款工具刷屏了 ——GitHub 星标 10 万 +、硅谷创业者称它 “24 小时待命的贾维斯”、国内用户实测 “办公效率翻倍”，它就是 OpenClaw！作为 2026 年最火的本地 AI 智能体，OpenClaw 从 Clawdbot、Moltbot 迭代升级而来，彻底解决了传统 AI “只能聊不能干”“数据泄密怕翻车” 的痛点。今天就带大家从 “是什么、怎么装、怎么用、怎么避坑” 全方位吃透它，重点附上

By Ne0inhk
Seedance 2.0 完整操作手册：AI 视频创作进入人人都是导演时代

Seedance 2.0 完整操作手册：AI 视频创作进入人人都是导演时代

这两天，字节的AI视频模型Seedance 2.0 彻底出圈了 到处都是 Seedance 2.0 的生成AI作品 有人用它做出了电影级的追逐戏，有人用它复刻了广告大片的运镜，还有人拿它做古装穿越剧和各种武打动作片，画面精致到让人分不清是AI生成的还是真人拍的。 不夸张地说，Seedance 2.0 这波更新，直接把AI视频生成的门槛踩到了地板上。 为什么这么火？因为它解决了一个所有创作者都头疼的问题：以前AI视频只能"生成"，现在终于能"控制"了。 用图片、视频、音频、文字自由组合，人人都能当导演   我们都知道，以前做 AI 视频，你只能打字描述想要什么画面，或者最多放一张图当起始帧。说实话，这种方式表达能力太有限了——你脑子里想的是电影级别的镜头感，打出来的却只是干巴巴的一段话。 现在不一样了。 它不再只是一个"文生视频&

By Ne0inhk