数字生产力，不该从工具清单开始

一台电脑、一个模型、一个 Agent 或一套协同软件都可能很强，但客户并不是为了拥有这些名词而付出时间和成本。客户真正需要的是一项工作被持续完成：输入有人接收，任务有人处理，结果可以检查，异常能够被发现。

因此，流马把数字团队而不是单一组件视为交付单位。底层组件可以根据任务、成本和可获得性替换，业务结果和责任边界则必须保持清楚。

把整个公司一次性自动化，听起来宏大，却很容易让范围、责任和验收全部失焦。更实际的起点，是选择一个重复发生、输入输出明确、结果可检查，并且在出错时能够暂停或交给人的工作流。

我们先描述现在怎样做、希望得到什么结果、哪些动作必须由人批准，再决定需要几个数字员工、怎样分工，以及使用怎样的模型、工具和计算环境。顺序不能反过来。

如果每个数字员工都要等待人逐一发消息、复制上下文和转述结果，那只是多个独立工具，并没有形成团队。团队需要能够接收共同目标、分派任务、交接上下文、汇总结果，并把例外升级给人。

这也是流马当前重点验证的能力之一。对外展示不应暴露底层组件的复杂性，但内部的任务状态、责任归属和人工门禁必须可观察。

有些数字员工需要真实桌面、应用和外设，因此需要专属节点；另一些只处理文件、命令、接口或有限的隔离自动化，可以使用共享工位。模型是数字员工的核心认知支撑，但也只是运行环境的一部分。

最终用户不应被迫管理这些内部结构。用户需要的是一个清楚入口，用来提出目标、查看结果、批准关键动作和处理升级；流马负责把背后的节点、模型、工具和协作机制组合起来。

一次成功演示不代表稳定交付。真正有价值的证据来自持续的真实任务：完成了什么、在哪里失败、需要多少人工介入、能否恢复，以及结果是否满足验收标准。

流马仍处于内部工程验证阶段。我们会清楚区分已经验证、正在验证和尚未开始的能力，不用流程图、文档数量或组件演示冒充业务结果。只有当一个工作流有足够证据，才讨论扩展更多岗位、任务和容量。