先说一个项目背景。一场营销活动从策划到上线，运营需要在三个系统间切换十几次，填写四十多个字段。我们用 AI 重新设计了这条链路——从最初的“AI 帮你填表单”，到后来的“两阶段 Agent + 聚合工作台”。这篇文章不打算详细记录技术细节，而是想聊聊这条路上的几个关键选择和对应的反思。

想象一下，你是得物社区运营，下周要上一场“夏季户外好物推荐”活动。你需要打开 A 系统创建话题，切换到 B 系统填写活动配置，再打开会场搭建系统配置组件，最后提交审核。三个系统各有独立逻辑，但字段之间高度耦合——活动名称改了一个字，A 系统和会场里都得跟着改，而其中大量工作都是重复录入。

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

让 AI 帮你填表——但人还是主角

最初的想法很直观：让 AI 来帮运营填写字段。具体做法是一个 5 步表单向导，AI 在第一步解析策划文档，随后在后续步骤中预填字段。AI 的能力来自两个 Dify Workflow（Dify 是一个开源的 LLM 应用开发平台）。第一个负责把策划文档解析成结构化字段，第二个负责把解析结果与系统的下拉选项做语义匹配。效果上，运营从“全部手填”变成了“AI 预填加人工校验”。

结果呢？上线后操作时间确实缩短了一些，但远没有达到“质的飞跃”。原因很直接：范式没有变。运营依然是流程的主体，AI 只是帮忙预填了一部分字段。运营依然需要理解每个字段、按顺序走完 5 步、在三个系统间来回跳转，还要自己判断 AI 填得对不对。更具体的问题包括：文档解析错了就得从头来，这是不可逆的；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 不是“决策者”，而是“节点内的执行者”——在明确定义的节点里做信息解析和文案生成，不参与流程路由。