一、项目背景：一场营销活动背后的“跨系统数据整合痛点”
设想一下，你是一名活动运营，下周需上线“夏季户外好物推荐”主题活动。你必须在A系统创建话题，切换至B系统填写活动配置，再打开会场搭建系统配置组件，最后提交审核。这三个系统彼此独立，但字段高度耦合——活动名称修改一个字，所有系统均需同步更改，导致大量重复劳动。一场活动从策划到上线，运营需在多个系统间跳转十余次，手动填写超过40个字段。
针对这一痛点，我们利用AI技术重新设计了整个工作链路。从最初的“AI辅助表单填写”演变为“两阶段Agent与聚合工作台”。本文旨在记录这过程中的关键决策与深刻反思，而非单纯的技术细节。
二、第一版探索：AI协助填表，但人仍是主导者
初期的思路非常直接：利用AI协助运营填写字段。我们设计了一个包含5个步骤的表单向导，AI在第一步解析策划文档，并在后续步骤中进行字段预填。AI的能力基于两个Dify Workflow——一个负责将策划文档解析为结构化字段，另一个负责将解析结果与系统下拉选项进行语义匹配。最终效果是，运营从“完全手动填写”转变为“AI预填结合人工校验”。
上线后数据显示，操作时间确实有所缩减，但远未达到“质的飞跃”。关键在于底层范式并未改变：运营依然是流程的核心执行者，AI仅预填了部分字段。你仍需理解每个字段含义、按序完成5个步骤、在不同系统间切换，并自行判断AI填写的准确性。更具体的问题是：文档解析错误时需从头开始；每次调用需等待5-15秒，且过程缺乏实时反馈；组件采用硬编码，仅支持单一模板及5个组件；系统缺乏持久化能力，刷新浏览器后进度便会丢失。
第一版实践让我们获得一个关键认知：若AI仅扮演“字段填写助手”的角色，它永远无法带来质变。真正的变革在于——由AI驱动流程，而人只在关键节点进行确认。这一认知与AI产品领域的普遍规律一致：AI产品的价值跃升，几乎都发生在“AI从辅助工具转变为流程主体”的拐点。例如，GitHub Copilot从“行级代码补全”进化至Copilot Workspace，ChatGPT从“对话交互”发展到GPTs+Actions，均是这一拐点的不同体现。
Agent CLI方案的可行性评估
在决定进行架构重写前，我们评估了一个更为激进的方向：Agent CLI。类似OpenCode CLI、Cursor、Claude Code等工具展现了另一种可能——通过自然语言指令，让AI Agent自主完成整个开发流程。理论上，会场搭建也可采用类似方式：运营人员只需说“我要做一个夏季户外主题活动”，Agent即可自主完成话题创建、活动配置及组件搭建，完全无需结构化的UI界面。
这代表了未来趋势，但当前落地面临三个实质性障碍：第一，Agent对会场的业务约束缺乏“体感”；第二，Agent无法获取实时系统状态；第三，Agent的操作缺乏审计机制与可解释性。这使我们认识到：需要在“完全自主的Agent”与“纯人工操作”之间找到恰当的平衡点。
Anthropic提出的Agentic系统复杂度光谱恰好提供了这一理论框架——它将AI系统的自主性从低到高划分为多个层级。我们的工作流大致对应于光谱中段的Prompt Chaining、Routing与Human-in-the-loop组合。这并非光谱上最复杂的位置，但对于当前场景而言，却是最为合适的方案。
三、第二版实现：从“手动填表”到“审核卡片”的转型
第二版是一次架构层面的整体重写。核心理念可概括为一句话：将运营从“流程执行者”转变为“流程监督者”。运营所需完成的工作简化至两项：提供信息（粘贴一份飞书策划文档链接），以及关键确认（在AI生成的结构化卡片上进行校验与微调）。其余所有事项——包括抓取文档、解析字段、创建话题与活动、复制会场模板、配置组件——全部由工作流自动驱动完成。
在选定技术方案前，我们需要回答一个更根本的问题：我们需要的到底是Workflow（工作流）还是Agent（智能体）？
我们的会场搭建流程具有明确步骤（解析→选组件→补字段→确认→构建），每一步的完成条件都是确定的，且对正确率要求极高。这显然更适合Workflow模式。但这并不代表完全放弃Agent能力。在局部场景中——例如AI改写规则文案、理解自然语言修改组件配置——我们采用了Agent式的LLM调用方法（为LLM提供工具，让其自主决定如何完成这一局部任务）。
一个实用的经验法则：如果你的业务流程能够被绘制成一张有限状态机图，那么请使用Workflow；如果它更接近于“给定一个目标，让AI自行寻找达成路径”，那么请使用Agent。大多数企业级应用场景是两者的混合——宏观框架用Workflow保证可控性，局部节点用Agent提供灵活性。
这一区分正日益受到行业重视。LangChain创始人Harrison Chase在多个场合强调：当前大多数成功的AI应用本质上是Workflow而非Agent。例如，Klarna的AI客服系统被广泛报道为“Agent”，但从架构角度看，它更接近一个精心设计的Workflow——具备明确的意图分类路由、标准化的工具调用流程以及人工升级机制。真正在生产环境中运行“完全自主Agent”的成功案例依然极为罕见。
选择LangGraph作为编排引擎
在明确需要Workflow之后，我们评估了多个方案，最终选定LangGraph作为编排引擎。LangGraph由LangChain团队推出，是一款采用MIT开源协议的状态编排引擎。它通过有向图来定义AI工作流：每个节点代表一个处理步骤（可为LLM调用、工具调用或人工确认），边则定义了步骤间的流转条件。其内置的Checkpointer机制能够持久化每个会话的完整状态，并支持中断后恢复。
在我们的系统中，LLM并非“决策者”，而是“节点内的执行者”——在明确定义的节点中执行信息解析与文案生成任务，不参与流程路由。