首页 > 人工智能 >营口本地宝：餐饮住宿加油费电子发票开票指南

营口本地宝：餐饮住宿加油费电子发票开票指南

来源：互联网 2026-08-03 14:18:19

人工智能资讯合集

一场营销活动需在三个系统间手动填写四十多个字段，易出错。从AI辅助填表演进为“两阶段Agent+聚合工作台”，让工作流驱动流程，运营转为流程监督者。采用LangGraph编排，结合Workflow与Agent，在关键节点人工确认，实现确定性可控的自动化。

项目背景

一场营销活动从策划到上线，运营得在三个系统之间来回跳转十几次，手动填写四十多个字段。这活儿枯燥不说，还特别容易出错——字段一多，复制粘贴时漏掉一个空格或者多打一个字符，整个活动都可能出岔子。我们试着用AI重新设计了这个链路：从最初的“AI帮你填表单”，一路进化到“两阶段Agent + 聚合工作台”。这篇文章要聊的不是技术细节长什么样，而是这一路走来的选择、踩过的坑，以及关于“人机协作”这件事的一些反思。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

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

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

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

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

但上线后才发现，操作时间虽然缩短了，却远没有达到“质的飞跃”。核心问题在于，范式没变。运营仍然是流程的执行主体，AI只是预填了一部分字段——你还是得理解每个字段、按顺序走完五步、在三个系统间跳转、自己判断AI预填得对不对。更具体的问题接踵而至：文档解析错了就得从头再来；AI调用需要等5到15秒，过程中没有任何反馈；组件是硬编码的，只支持一个模板、五个组件；没有持久化，刷新浏览器进度就丢了。

第一版给了我们一个重要认知：如果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机制可以持久化每个会话的完整状态，支持中断后恢复。

营口本地宝：餐饮住宿加油费电子发票开票指南