想象一下这样的场景：你负责一场“夏季户外好物推荐”活动的运营，需要在A系统里创建话题，切换到B系统配置活动参数，再跑去会场搭建系统设置组件，最后提交审核。三个系统各自独立，但字段之间高度耦合。活动名称改了一个字，就得在A系统和会场的配置里同步改动，其中大量工作是重复录入的机械劳动。

没错，这正是我们最初面临的问题——运营人员从策划到上线，要在多个系统间反复跳转数十次，填写超过40个字段。于是我们决定用AI来重塑这条链路，从一个朴素的“AI帮你填表”开始，最终演进为“两阶段Agent+聚合工作台”。这篇文章不是为了记录技术细节，而是想聊聊这一路上的关键选择与反思。

一、第一版探索与Agent CLI可行性评估

最初的思路其实很简单：让AI帮运营填好所有字段。设计了一个5步的表单向导，第一步由AI解析策划文档，后续步骤中预填字段。AI的能力来自两个独立的Dify工作流——一个负责将策划文档解析为结构化字段，另一个负责把这些字段与系统的下拉选项进行语义匹配。效果是运营从“全手动输入”变成了“AI预填加人工校验”。

但上线之后我们发现，操作时间确实缩短了，却远没有达到“质的飞跃”。原因其实不复杂：整个范式没有变。运营同学仍然是流程的执行主体，AI只是预填了一部分字段，你仍然需要理解每个字段的含义、按顺序完成5个步骤、在三个系统之间来回切换，还得自己判断AI填得是否正确。具体来说，问题集中在这几个方面：文档解析一旦出错，整个流程就得从头再来；每次调用AI需要等待5到15秒，过程完全是个黑箱，看不到任何中间反馈；组件是硬编码的，只支持单一模板和5个组件；另外浏览器刷新就会导致进度丢失，完全没有持久化。

这一版给了我们一个很重要的认知：如果AI的角色仅仅是“帮你填字段”，它永远无法带来真正的质变。真正的变化应该是——AI来驱动流程，人只在关键节点做确认。这个判断其实和AI产品领域的一条通用规律是一致的：AI产品的价值跃迁，几乎都发生在“AI从辅助工具变成流程主体”的那个拐点上。想想看，GitHub Copilot从“行级补全”进化到“Copilot Workspace”，ChatGPT从“对话”进化到“GPTs+Actions”，背后的逻辑都是如此。

在决定重写之前，我们还评估了一个更激进的方向：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”的案例，仍然是极少数。

明确了需要Workflow之后，我们评估了多个方案，最终选择了LangGraph作为编排引擎。LangGraph是LangChain团队推出的状态编排引擎，采用MIT开源协议。它用有向图来定义AI工作流：每个节点是一个处理步骤（可以是LLM调用、工具调用或人工确认），边定义了步骤之间的流转条件。内置的Checkpointer机制可以持久化每个会话的完整状态，支持中断后恢复。

在我们设计的系统里，LLM的角色不是“决策者”，而是“节点内的执行者”——在明确定义的节点里做信息解析和文案生成，不参与流程路由的判断。