从表单到 Agent：得物社区活动搭建的 AI 实践之旅
策划到落地上线，运营人员需要反复在多个系统切换、录入大量字段，现在我们借助AI重新设计了整个链条，从简单的表单填充进化到两阶段Agent协同工作台。这篇文章记录的并非技术细节，而是项目演进中的关键决策与深度反思。
假设你是一名社区运营，下周需要举办一场“夏季户外好物推荐”活动，你必须打开系统A创建话题，切换到系统B填写活动配置，再进入会场搭建系统配置组件，最后提交审核。这三个系统相互独立，但字段高度耦合，修改一次活动名称，需要同时在多个系统中跟进，造成大量重复操作。
一、项目背景
二、第一版探索与Agent CLI可行性评估
让 AI 帮你填表——但人还是主角
最初设计思路是让AI帮助运营填写字段，具体实现为一个包含5个步骤的表单向导。AI在第一步解析策划文档，后续步骤中预先填充字段，其能力源自两个Dify Workflow：第一个将策划文档解析为结构化字段，第二个将解析结果与系统的下拉选项进行语义匹配。实际效果是，运营的工作从“完全手动填写”转变为“AI预填加上人工校验”。
上线后数据显示，操作耗时有所缩短，但并未带来本质性的体验飞跃。核心原因在于：运营依然是被流程主导的主体，AI仅仅预处理部分字段，用户仍需理解每个字段含义、按既定顺序完成五个步骤、在三个系统间反复跳转，并自行判断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并非“决策者”，而是“节点内的执行者”，即在明确定义的节点中负责信息解析和文案生成，不参与流程路由。
Interrupt / Resume：前后端的交互语言
整个前后端的交互基于LangGraph的interrupt/resume机制。可以将Interrupt和Resume理解为“程序的暂停和继续”。当后端流程执行到需要人类输入的步骤时，会调用interrupt()来暂停整个图的执行，同时将一个结构化的数据包发送给前端。前端根据数据类型渲染对应的UI卡片。用户操作完成后，前端通过Command将结果返回，图从断点处继续执行。
结合LangGraph的interrupt机制和LangChain的Human-in-the-loop文档，人工介入通常覆盖以下几类动作：Approve/Reject，即审批或拒绝，适用于高风险操作前的确认；Edit，即编辑Agent的动作、状态或中间结果，适用于人工修正AI的输出；Respond/Input，即提供额外信息或补充反馈，适用于AI无法自行获取的数据。我们的6个中断点混合了这几类模式。
运营视角：一场活动怎么搭
以“夏季户外好物推荐”活动为例，整个操作流程如下：
整个活动搭建过程在同一个对话界面中完成，无需跳转到其他系统。
Capability Registry：一个壳装所有场景
前端并未将“会场场景”写死，而是通过一套能力注册表（Capability Registry）来动态挂载不同场景的UI。能力注册表类似于插件系统，每个业务场景作为一个“能力模块”，向统一的交互壳注册自己的UI贡献，包括欢迎态、中断卡片和结果展示等。交互壳不关心具体业务，只负责调度和渲染。新增场景时只需注册一个新模块，无需修改交互壳的代码。这个设计思路与微前端架构中的Module Federation有相似之处，即都实现了“壳”与“能力”的解耦，使新能力可以独立开发和注册。不同之处在于，我们的粒度更细，不是整个页面模块的联邦，而是UI贡献点级别的注册。
第二版将体验从“填表单”推进到了“审卡片”阶段：AI从“帮你填字段”升级为“驱动整个流程”，并支持中断恢复，即使用户关闭浏览器再打开也能继续操作。能力注册表的设计使系统具备了良好的扩展性，当前已接入会场搭建、动态筛选和通用聊天三个场景，未来新场景只需实现对应的能力模块即可。然而，第二版仍有一个前提假设：运营已经有一份策划文档。在众多真实的业务场景中，运营往往并没有现成的文档，只有一个初步的活动想法，这直接推动了第三版的诞生。
组件模块协议：把差异封进模块
为什么需要一套协议
在介绍第三版之前，有必要先阐述第二版中最为核心的设计——组件表单模块协议。它解决了业务扩展性这一核心问题。会场由多个组件构成，如头图、动态Feed、活动任务、规则说明、Banner和瓜分激励等，每个组件的配置逻辑差异巨大。
第一版的做法是在一个文件中通过条件判断进行分发，每增加一个组件就需要修改中心调度文件，导致组件的业务逻辑散落在各处。当组件数量只有5个时，这种做法尚可接受，但增加到16个以上时，就变得不可行了。
生命周期：每个组件的统一节奏
我们将每个组件抽象为独立模块，并定义了统一的生命周期：
最重要的一条规则是，初始化阶段不产生任何副作用，例如调用后端创建资源。真正执行写操作的动作必须放在“构建前”阶段，即用户明确点击“构建会场”之后。这条规则避免了曾经一个真实的Bug：有组件在初始化时偷偷调用了后端保存接口，导致用户只是打开卡片看了一眼，系统就已经创建了活动数据。
双轨注册：显式选择 + 条件注入
新增组件时，只需实现模块接口并注册到对应的轨道，无需修改任何调度逻辑。这是协议级设计的核心优势，即遵循开闭原则：对扩展开放，对修改关闭。这种“根据上下文自动注入，用户不感知”的模式在软件架构中很常见，它将“是否需要某个组件”的决策从使用者手中拿开，交给系统根据规则自动判断。这样做的好处是降低了使用者的心智负担，但坏处是系统行为可能变得更难预测。因此，我们的条件注入轨道会在工作台上展示“已自动注入”的提示，让运营了解系统替她做了什么决定。
声明式位置编排
组件不仅可以输出配置数据，还能声明位置意图，即“我希望被放在哪个组件的前面或后面”。以Feeds组件为例，一个活动可能包含多条Feed，其中某条“竖向”的Feed需要放置在页面底部。Feeds模块无需知道“底部”的具体位置，它只需声明“这条竖向Feed想放在页面末尾”。这种三层关注点分离的设计，使每一层只关心自己的职责。
四、第三版设计与工程实践
从"我有文档"到"帮我写文档"
第二版解决了“会场搭建流程如何被AI驱动”的问题，但它隐含了一个前提：运营已经有一份策划文档。在实际业务中，许多运营连文档都没有，只有一个模糊的想法，就被要求先写一份结构化的飞书文档，再粘贴到Agent中。策划生成和会场搭建是两种不同的范式：
这两种范式的差异，决定了我们需要一个两阶段架构来分别承载：第一阶段解决“从想法到策划文档”，第二阶段解决“从策划文档到会场配置”。
两阶段架构
Stage 1：活动方案生成 Skill
Stage 1 Skill的核心约束是只读不写——只查询候选数据，如预算池、类目、标签和历史会场，不做任何写操作。所有写操作，包括创建话题、创建活动、复制会场和提交审核，全部由Stage 2闭环。这个“只读”约束并非技术限制，而是权限模型的设计选择。在Agent系统中，一个反复出现的架构决策是：AI的能力边界应该在哪里？
- 读权限： AI可以查询任何数据，风险较低，最多只是查询到不相关的结果。
- 写权限： AI可以创建或修改数据，风险中等，可能产生脏数据。
- 发布/审批权限： AI可以影响线上环境，风险高，会直接影响真实用户。
Stage 1只赋予读权限，Stage 2逐步开放写权限，而发布权限则要求人工确认后才能触发。这种分级与AWS IAM的最小权限原则一脉相承，即每个主体只拥有完成当前任务所必需的最小权限集。引导策略采用渐进式方式，不要求一次性填写完整表单：
最低要求是三项内容：活动名称、活动时间以及至少一个话题，其他信息则根据对话进度逐步追问。这种“不一次问完所有问题，而是按对话进度逐步追问”的策略，在UX设计中被称为渐进式披露。核心思想是不一次给用户太多信息或太多选择，而是在用户需要的时候、以用户能理解的方式、提供恰好足够的信息。
Stage 2：聚合工作台
Stage 2是一个独立的页面，而非聊天壳中的一个面板，它承载了更偏向生产操作的密集交互。其中，中栏预览是一项核心升级，它复用了搭建器已有的H5编辑页面，并覆盖一层可交互的遮罩。运营可以点击预览中的任何组件，右侧会自动展示该组件的配置表单。这个设计的关键在于“不重新实现预览器”，搭建器本身已具备完整的会场渲染能力，我们只是在其外层增加了交互层。草稿实时同步功能确保操作不丢失：每次组件的增删改或属性修改都会即时更新预览，同时异步持久化到后端。
组件级AI改造包含两个层次：其一是显式AI辅助面板，部分组件支持在“AI辅助”和“原表单”之间切换，运营可以用自然语言描述想要的效果；其二是通用自然语言编辑，在工作台对话中输入修改需求，系统会将当前选中的组件上下文交给后端的编辑子流程处理。
工作台中“用自然语言修改组件”的能力，例如“把这个Banner的标题改成夏季清凉风格”，是当前AI辅助设计领域的一个缩影。该领域正在快速发展，出现了多个值得关注的产品和方向：Figma AI正在将AI能力嵌入设计工具，涵盖自动布局建议、文案生成和设计稿搜索，其做法与我们类似，即AI做建议，设计师做决定；Vercel v0通过自然语言描述生成React UI组件代码，走的是更激进的路，即AI直接生成完整代码，而非修改已有组件的属性；Adobe Firefly在Photoshop和Illustrator中嵌入生成式AI，走的是“AI在画布内局部生成，人工在全局把控”的路线。
这些产品的共同模式是：AI负责局部生成或修改，人负责全局决策。完全用AI替代设计师产品，如一些“AI自动建站”工具，目前还很难在专业场景中落地，这与我们的会场搭建面临同样的问题：对正确率和品牌一致性的要求过高。
表单托管runtime：一个务实的工程妥协
工作台右侧的组件表单运行在一个独立构建的子项目中，原因是搭建器的组件表单依赖特定的运行时环境和Formily表单引擎，与我们的前端技术栈不兼容。我们没有重新实现几十个组件表单，而是做了一个独立构建，复用搭建器原版的运行时，通过消息协议与主页面通信。这是一个“避免重复开发”的工程妥协，虽然增加了架构复杂度，但把有限的开发精力放在了真正新增的价值上，如预览交互、AI辅助和草稿同步，而不是重造已有的轮子。
五、架构全景
系统分层
六、实践中的取舍
- AI与人的分工边界
在当前阶段，“全AI控制”并不现实。会场的组件业务约束复杂，字段来自多个外部系统，规则有优先级，部分组件甚至会触发真实资源创建。最终的方案是AI负责信息提取、草稿生成、字段改写和推荐，而代码负责流程控制、结构验证、校验和副作用时机。
- 交互方式的选择
采用结构化UI并非因它“不够AI”，而是对运营认知负担的尊重。让运营在下拉列表中选择预算池，比用自然语言描述然后让AI猜测更高效准确。最终的交互方式是混合的：用自然语言描述意图，用结构化UI确认细节，再用可视化预览检查结果。
- 副作用控制的时机
组件模块协议中最重要的规则之一：初始化阶段不产生副作用，只有用户明确确认后才允许写操作。这是LangGraph的Edit Action保护机制，决定了系统是否会在用户未确认时产生脏数据。
- 工程妥协的边界
Form Host是一个工程妥协，但却是必要的。完全重写成本高且容易引入行为差异。复用旧生态使工作台能将有限的开发精力集中在真正新增的价值上。
- 信任建立的方式
虚假的进度条是一种过度承诺。AI产品的信任是慢慢建立的，每一个“假反馈”都在消耗信任。Microsoft的HAX设计指南建议让用户清楚系统为何会做出某个决策，我们的每张中断卡片都在践行这一点，不仅为运营提供一个表单，还解释了“为什么需要你填写这些字段”以及“AI已经做了什么、还缺什么”。
七、总结与展望
回顾这个项目的演进路径：在第一版中，AI辅助填写字段，但人仍是流程主角，效率虽提升但未产生质变；第二版转变为AI主导流程，人负责决策确认，运营从流程执行者变为流程监督者；到了第三版，AI不仅能主导流程，还能帮助规划路线，策划生成前置到Stage 1，会场搭建沉淀到Stage 2的聚合工作台，使运营从“必须先写文档”变为“AI帮我生成文档”。展望未来，可能是Agent CLI方案的成熟，让更多操作可通过自然语言完成；或是更多场景的接入，使同一套架构支撑更多业务；也可能是在LLM能力提升后，“组件全AI控制”变得可行。但无论技术如何演进，有三条基本原则不会改变：流程必须可控，不能让AI自由发挥到不可预测；正确率必须优先，会场配置错误会直接影响线上运营；运营负担必须更低，技术再酷，最终还是要让运营觉得好用。技术形态会不断变化，但业务约束始终如一。
往期回顾
- 从埋点需求到规则资产：Hermes Agent 重构数仓工作流
- 让 Claude Code 拥有自我进化和记忆系统
- 用 LLM Agent 重构告警排查流程
- HorizonVault 技术深潜：如何在 HDD 上做出 100GB/s+ 级大吞吐分布式存储
- Claude Code Harness 工程：数仓侧落地方案