Agent 开发实践：从 Workflow 到可控智能体架构

做传统工业软件的智能化已经有一段时间了，最开始只是从 LLM 生成 json 数据，给到软件进行解析，到后面的完整业务流程都由 agent 完成，人在环做中间结果确认，再到 agent 完成完整任务的交付，中间经历了一些曲折，也消除了一些困惑。记录一下当前对 agent 的思考。

一、Agent 开发的核心范式：Workflow

个人理解：所有 agent 都是 workflow
在工程实践中，Agent 并不是“自由思考的黑盒”，而是由一系列受约束的流程节点（Executor）构成的有向图。

1.1 Naive Workflow（显式流程编排）

这是最常见、也是最稳定的一种 Agent 设计方式。

基本思想

• 将一个复杂目标拆解为固定顺序的子任务
• 每个子任务职责单一、输入输出明确
• 通过 Workflow 显式连接执行顺序

典型结构

宏观 Workflow：

需求输入
  → 任务分解
    → 结构化建模
      → 生成结果

嵌套子 Workflow（示例：任务分解）：

实体抽取
  → 实体补全
    → 实体关系识别
      → 场景归纳

优点

• 行为高度可预测
• 易于调试和回溯
• 非常适合高可靠性、强约束的业务场景

局限

• 灵活性有限
• 对未知问题的泛化能力较弱

---

1.2 Generic Workflow：ReACT 范式

当问题空间变得更开放，Naive Workflow 会显得僵硬，这时可以引入 ReACT（Reasoning + Acting） 架构。

ReACT 核心循环

Thought → Action → Observation → Thought

• Thought：分析当前状态，决定下一步
• Action：调用工具或子系统
• Observation：获取执行结果
• Judge：判断是否完成目标，或进入下一轮

优点

• 适应性强
• 能处理非结构化、动态问题
• 非常适合「探索型」任务

工程现实

在真实系统中，纯 ReACT 很少单独使用，更多是：

ReACT + Workflow 外壳

即：

• 外层是受控的 Workflow
• 内层某些节点具备 ReACT 能力

---

二、主流 Agent 开源框架的工程视角

从工程可维护性出发，而非 Demo 体验，几个常见框架的感受如下：

框架	工程评价
LangChain	抽象复杂，调试成本高
AutoGen / Agent Framework	代码结构直观，适合复杂 Agent
LlamaIndex	上手快，偏知识检索，Agent 能力较弱

经验结论：

Agent 框架不应“包办一切”，而应服务于你的 Workflow 设计。

---

三、复杂分析型 Agent 的 Workflow 设计实践

3.1 场景抽象

在某类仿真 / 决策 / 分析系统中，Agent 的目标是：

基于输入态势，自动完成多阶段分析，并生成结构化结果链路。

这类问题的特点是：

• 多实体
• 多约束
• 强逻辑顺序
• 需要反思与回溯能力

---

3.2 Workflow 拆解原则

（1）实体处理：Naive Workflow

实体相关任务非常适合顺序、确定性流程。

示例代码（已抽象）：

def build_entity_processing_workflow():
    """
    EntityExtractor -> CoreferenceResolver -> EquipmentQuery
      -> EntityClassifier -> MatrixBuilder
    """
    entity_extractor = EntityExtractorExecutor(id="entity_extractor")
    coreference_resolver = CoreferenceResolverExecutor(id="coreference_resolver")
    equipment_query = EquipmentQueryExecutor(id="equipment_query")
    entity_classifier = EntityClassifierExecutor(id="entity_classifier")
    matrix_builder = MatrixBuilderExecutor(id="matrix_builder")

    workflow = (
        WorkflowBuilder()
        .add_edge(entity_extractor, coreference_resolver)
        .add_edge(coreference_resolver, equipment_query)
        .add_edge(equipment_query, entity_classifier)
        .add_edge(entity_classifier, matrix_builder)
        .set_start_executor(entity_extractor)
        .build()
    )

    return workflow

设计要点：

• Executor 只做一件事
• 输出必须结构化
• 不允许“自由发挥”

---

（2）任务分解：带反思能力的 Workflow

任务分解是 Agent 最容易失控的部分，因此需要：

• 迭代上限
• 原子任务兜底
• 反思与中断机制

简化后的逻辑如下：

iteration = 0
max_iterations = 5

while current_tasks and iteration < max_iterations:
    iteration += 1
    new_tasks = []

    for task in current_tasks:
        is_atomic, method, sub_tasks, llm_result = decompose_task(task)

        if is_atomic:
            mark_as_atomic(task, llm_result)
        else:
            record_method(task, method)
            new_tasks.extend(sub_tasks)

    current_tasks = new_tasks

关键经验：

• 不要相信模型“会自己停下来”
• 每一轮必须有可量化的收敛条件
• 原子任务必须定义清晰

---

3.3 Agent 框架能力要求总结

在复杂 Workflow 中，Agent 框架至少需要支持：

• 顺序执行
• 并行执行
• 条件分支
• 结果反思 / 回滚
• 可观测的中间状态

否则，Agent 只会是一个“看起来很聪明，但无法上线的 Demo”。

---

四、总结：工程视角下的 Agent 设计原则

1. 确定性流程优先于自由推理
2. 反思能力必须被显式设计，千万不要指望 agent 框架自带的反思机制（本质上还是 prompt，且没有针对特定任务做优化）