10 月 29 日，扣子团队发布了《扣子企业版下线公告》。对于有项目在扣子上的团队来说，又增加了工作量。

下线节奏

从公告中看，整个下载节奏分成了三个阶段：

第一阶段段是暂停新售。企业标准版和企业旗舰版从 2026 年 11 月 30 日起不再接受新客户购买。已经签了合同但还没下单的客户，需要找商务经理确认后续的购买和开通安排。

第二阶段是旧版套餐下线。在火山引擎购买的旧个人进阶版、旧企业版、旧团队版，2026 年 12 月 31 日全面下线，超过这个日期的未使用部分自动退款到火山引擎账户。想继续用的客户，要先退订旧套餐，再购买企业标准版或旗舰版。

第三阶段是新版企业套餐下线。企业标准版和旗舰版在 2027 年 12 月 31 日全面下线，新购、续费、增购席位的到期日都不能晚于这一天。套餐到期后 14 天内还可以续费，超过 14 天就只能按新购处理。

企业版下线后有哪些替代产品，这在公告中没有明确，原文的描述是「正在规划后续可供企业客户选择的产品和套餐方案」。另外，资源导出，涉及对话、记忆、文件、编程项目、低代码工作流，公告原文是「将在后续公告中明确相关安排」。

确定与不确定

工作流解决的核心问题，是在确定性和不确定性之间找了一个捷径。

大模型的输出天然带有不确定性。同一个输入跑十次，结构、措辞、调用哪个工具、调用顺序都可能不一样。工作流的做法是在控制流的位置替换了模型：哪一步先执行，什么条件下走哪条分支，失败了重试几次，全部由工程师写死，模型只负责某个节点内部的局部判断，比如抽取字段、分类、生成一段文本。

Agent 的做法反过来，把控制流交给模型。给它目标和一组工具，由它决定调用顺序和终止条件。

两种方式的代价不同：

工作流的流程是按设计时想到的情况画出来的，线上的输入一旦超出预设分支，要么落进兜底节点，要么直接报错。为了覆盖更多情况，就加分支、加条件、加路由节点，画布越来越大，到后期没人敢动。

Agent 的代价是不可控。单次任务的 token 消耗、耗时、调用次数都有方差，出问题时排查的对象是一条推理轨迹，很难像查日志那样定位到某一行。在需要审计的场景里，「模型当时这么想」写不进事故报告。

从工程的角度，可以是按「出错的代价」和「输入空间的开放程度」两个维度来分。出错代价高、输入空间收敛的任务，比如财务对账、工单流转、合规审核，用工作流。出错代价低、输入空间开放的任务，比如调研、探索式分析、草稿生成，用 Agent。剩下那部分中间地带，用工作流做骨架，在骨架的某几个节点里嵌入受约束的 Agent。

扣子这类平台早期的价值，在于让不写代码的人也能做出第一种选择。模型能力弱的时候，这种选择几乎是唯一可行的选择，因为放手让模型自己规划，成功率达不到业务的要求。

模型在吃掉什么

过去两年模型能力的变化，主要体现在长链路任务上：能连续调用更多工具，能在中途发现错误并回退，能读懂更长的上下文。这些变化直接冲击了工作流里的一类节点。

工作流里的节点大致可以分两类。一类编码的是「怎么做」：先搜索，再筛选，再总结，结果不满意就换关键词重搜。另一类编码的是「必须怎么做」：金额超过阈值要走审批，写操作前要校验权限，同一个请求不能重复扣款。

第一类节点正在被模型吸收。早期模型自己规划不出合理的步骤，人只能把步骤画出来；现在模型规划得比很多手画的流程更灵活，硬编码的步骤反而限制了它的发挥。我们去年画的几个「多轮检索 + 总结」流程，换成单个 Agent 加几个工具后，效果没有下降，维护成本降了不少。

第二类节点不会被吸收。这类约束来自组织、法规和系统的一致性要求，跟模型聪不聪明无关。模型再强，也不能由它决定这笔钱要不要走审批。

把这两类节点混在一张画布上，是很多存量工作流难以演进的根源。模型升级之后，第一类节点该删掉，但它和第二类节点交织在一起，删一个牵动一片。

封装与 token

我们自己有在做 Harness 的事情，产品叫 ArkWork，这个产品会下周上线。

在做这个产品的过程中，我们有一个优化点是：让同一个任务消耗的 token 更少。虽然有很多方式来做优化，包括但不限于大量使用缓存，优化系统提示词，但比较有效的是封装，即把原始的多个指令封装成一个操作指令。

一个 Agent 在原始工具集上完成任务，token 主要花在三个地方。第一是工具定义，每个工具的描述和参数 schema 都要放进上下文，工具一多，这部分就成了固定开销。第二是中间结果，每次工具调用的返回值都会回流到上下文里，模型只需要其中一个字段，也得把整段 JSON 读完。第三是推理轮次，每多一轮调用，就多一次完整的上下文读取。

封装对这三项都有作用。把「查用户、查订单、算退款金额」三个工具合成一个「计算退款」工具，工具定义从三份变成一份，中间的用户信息和订单明细不再进上下文，三轮调用变成一轮。模型看到的只有输入参数和最终金额。

工作流就是封装的一种。它把一串确定的步骤固化成一个可调用的单元，对调用方隐藏内部过程。从 Harness 的视角看，一个被暴露成工具的工作流，和一个被封装好的函数没有本质区别，都是在压缩模型需要「看见」和「决定」的东西。

封装的形式还有几种：

工具聚合：把多个原子工具合并成面向任务的粗粒度工具，主要节省工具定义和调用轮次。
脚本：让模型写一段代码一次性处理数据，中间结果留在执行环境里，只把结论带回上下文。
子 Agent：把一个子任务连同它自己的上下文隔离出去，主 Agent 只接收摘要。
技能：把某类任务的说明、参考资料、脚本打包，平时只在上下文里放一段简短描述，模型判断需要时才加载正文。

封装也有代价，主要是三个坑：

粒度切错：封得太粗，某一步失败时模型没有办法只重试那一步，只能整体重来，或者干脆放弃。封得太细，又回到了原子工具的开销。我们的经验是按「失败后的恢复方式」来切：如果某一步失败后，合理的处理方式需要模型参与判断，这一步就不该被封进去。
错误信息不可读：封装单元内部报错时，返回给模型的信息必须让模型能据此决定下一步。返回一个「内部错误」，模型只能盲猜；返回「订单号不存在，请确认是否为子订单号」，模型可以自己修正参数再调一次。这部分工作量经常被低估，我们有一半的封装改动是在改错误信息。
灵活性损失：封装等于替模型做了决定。被封进去的逻辑，模型就没法再优化了。模型能力上来以后，当初为了弥补能力不足而做的封装，会变成新的限制。所以每次换基座模型，我们都会重新评估一遍哪些封装该拆开。

工作流与技能

技能和工作流经常被放在一起比较，两者在约束的「硬度」上不同。

技能是软约束。它告诉模型这类任务通常怎么做、有哪些注意事项、可以用哪些脚本，执行权仍然在模型手里。模型可以跳过某一步，可以调整顺序，可以在说明没覆盖的情况下自行处理。

工作流是硬约束。执行权在引擎手里，模型只能在被分配的节点里发挥。

大模型在这两者之间扮演调度者。它读技能来决定怎么做，调工作流来完成必须按规矩做的部分。

三者可以嵌套。技能里可以附带一个脚本，脚本本身就是一段固化的流程；工作流的某个节点里可以放一个模型调用，处理局部的不确定性；模型在执行技能的过程中，可以把某个子步骤交给工作流。

按确定性从高到低排，大致是：代码、工作流、技能、自由 Agent。我们在设计一个任务时，会把它拆成若干子步骤，给每个子步骤在这条轴上选位置。选位置的依据就是前面说的两个维度：出错代价和输入开放程度。

技能在当前阶段吸引人的地方是它对模型升级友好。说明文档写的是意图和约束，模型变强以后，同一份技能能执行得更好，不需要改动。工作流对模型升级不敏感，模型变强以后，它的表现基本不变，那些编码「怎么做」的节点还会拖后腿。

AGI 之后

如果模型能力继续提升，到了能可靠完成长周期复杂任务的程度，工作流还有没有用？

我们的判断是有用，但它的位置会有所变化。

第一，约束类逻辑会一直存在。审批、权限、幂等、审计，这些要求来自模型之外，需要确定性的执行机制来保证。人类组织里能力再强的员工，也要按财务制度报销。

第二，封装的经济性会一直存在。一个已知的、固定的流程，每次都让模型从头推一遍，就是在重复支付推理成本。模型再便宜，确定性执行仍然比推理便宜几个数量级，延迟也低得多。只要还有人关心成本和延迟，把重复的模式固化下来就有收益。

会变的是工作流的生产方式。现在工作流由人来设计、在画布上拖出来。往后更可能的路径是模型在执行任务的过程中发现重复模式，自己把它固化成脚本或流程，下次直接调用。人负责审核这些固化物，而不是从零画它们。

照这个方向推理，拖拽式画布作为工作流的主要编写界面，生存空间会被压缩。它服务的对象是「不写代码但想定义流程的人」，当模型能替这些人写流程时，画布的价值就只剩可视化和审核了。

回到扣子这次下线，平台的商业决策有它自己的考量，我们不做揣测。对使用方来说，工作流这个概念还会长期存在，它在工程上的作用是为确定性做封装。会变的是它的载体，以及由谁来写它。存量资产里能带走的，是那些写成文本、讲清楚约束、能被模型或别的引擎重新解析的部分。

以上。